It's nearing time for 3.0

[getify]

Specifically:

1. link rel=preload is becoming a reality.
2. Also, IE is dead now
3. There's several small feature requests that have built up over time that should be rolled in (if anyone even still cares)

[devilking15292]

@getify I'm interested in this

[dudesl]

Maybe its time to CORS support?

[getify]

@dudesl can you be more specific?

[pihvi]

I'd like to help, what could I do?

I'd like to see LABjs in NPM as I'm using it for version management. Should I just add it there or would you like to be the owner of that?

[getify]

The goal is the 3.x launch will be on npm

[pihvi]

Great, what should happen next to get things started? How can I help?

[getify]

it's started... there's a separate branch for the 3.0 work. it's in progress. just haven't had much time lately.

[nyrosmith]

@getify is there anything I could help with?

[fatso83]

@getify To get some help on this you should make it easy to contribute. Make a list of issues that you need help with, possible from a overview issue "3.0 release", and mark them with "help wanted". As this thread shows there are many folks who would like to help out, but don't know where to start.

[artknight]

lets add local storage to cache the scripts!

[jbmonroe]

@artknight How will you load scripts from local storage?

[artknight]

@jbmonroe I recently wrote a script to use localStorage to cache JS & CSS scripts. The way it works is to store the JS/CSS content as a STRING and inject it into the header on subsequent page loads. I added a cache buster to force cache reloads when needed ( version changes, etc... ). The performance is amazing but I do realize that it has some drawbacks as mentioned in the comments.

[fatso83]

@artknight, you don't link to to any script and there are no comments in this issue that mentions anything about drawbacks. mind elaborating?

[kylebakerio]

What's the word on this, @getify?

Also, I can't seem to find any comprehensive 'how-to' on using this library. I can derive most of it from the examples, but there are mention of features in the README.md regarding e.g. queuing, where there is no code example and no illustration. Are we just expected to look through the source, or am I missing some obvious file?

[getify]

I appreciate that several people have interest in this project. I do definitely want to complete the 3.0 rewrite (I'm about 1/3 of the way through that). However, the project is lower on my priority list. I have several other projects that are more pressing.

@finetype the site (http://labjs.com) is down, but it's up on http://archive.org so you can consult the docs there. They should have the info you're inquiring about. Part of the rewrite will be to migrate all that documentation over to this repo.

[getify]

I've just pushed up my long-in-progress work on the 3.0 rewrite. It's at bare minimum functioning status. Still very much pre/alpha, but at least it's coming along finally. :)

[ptomasroos]

Awesome! Do you need a hand with anything @getify ?

[getify]

See below for a checklist. Theoretically, others can help with this coding.

TBH, I still expect most likely to be the one to do (most of) the code for the core library. It's not a particularly simple flow control to fully understand, and it's not documented anywhere, so I'm not expecting other contributors to fully understand what I'm juggling in my head. :)

But there's several extra projects (like the server util, the mock DOM, etc) that definitely are good for others to tackle. Definitely will also appreciate help eventually with docs and tests. :)

For now, please take a look at the code and see if you spot anything or have any suggestions. That much I'm happy to have help with, for sure!

[getify]

Gonna start a checklist here (in no particular order) for the rest of the stuff I think will need to be done for 3.0... expect this list to grow significantly:

• fix script(..) and wait(..) to also take arrays of arguments

• add methods (similar to script(..)) for loading other resources besides scripts (like stylesheets, images, etc)

• add back in the queue*(..) / runQueue(..) mechanism from 2.x

• explore adding back in the "AllowDuplicates" mechanism from 2.x -- not sure if possible, nor even worth it

• modules (https://jakearchibald.com/2017/es-modules-in-browsers/)

• figure out correct handling for "CacheBust" (especially as it relates to <link rel=preload> preloading)

• figure out which additional options make sense for script(..) (and/or other resource loading types), such as a whitelist of attributes to be added to the element, etc

• add error event handling for script/link elements

• address all the TODO comments in the code

• rebuild a whole new test suite

  NOTE: this is particularly challenging because to avoid needing a test server to load resources from, we need to build a mock of (some parts of) the DOM. We can't really just use an existing virtual/mock DOM for this purpose, because we need to actually control it (what APIs are present, how they behave, etc) for our different test simulations.

  • affected DOM APIs / properties:
    • getElementsByTagName(..)
    • createElement(..)
    • head
    • appendChild(..)
    • removeChild(..)
    • baseURI
    • setAttribute(..)
    • getAttribute(..)
    • addEventListener(..)
    • removeEventListener(..)
    • relList
    • supports(..)
    • performance.getEntriesByName(..)
  • we need to be able to simulate a variety of different browser environment scenarios by changing the behavior of these APIs, for example:
    • preloading vs no-preloading
    • script ordered-async vs not
    • <link rel=preload> tags already present in the page vs not
    • "random" server/network timing variations (and errors!)

• rebuild the docs

• revisit feature requests from the last N number of years of issue threads, examine feasibility

• explore Debug mode and what that means for 3.0+ -- is there a debug build with extra code, what changes in debug mode, etc?

• explore replacing canonicalURL(..) with URL(..), probably with some sort of polyfill-fallback (for older browsers)

• change the usages of timers (setTimeout(..)) to a scheduling queue (like this one), backed by one of these async timing mechanisms (in order of precedence): requestIdleCallback(..), setImmediate(..), process.nextTick(..), or setTimeout(..)

• using getify/ScanTree, build a server-side LABjs utility that can scan a code base and compile a list of resources to be loaded, and produce not only the $LAB code chain to load it, but also produce the <link rel=preload> markup to inject into an HTML page to start the preloading early (parser stage)

  NOTE: this utility needs to (eventually) be able to parse ES6 modules import syntax as well, something that ScanTree doesn't currently support. That may mean needing to extend ScanTree in some way.

[getify]

FYI: I've moved the mock-DOM thing to its own separate project:

https://github.com/getify/mock-DOM-resources

[getify]

Mock-DOM-Resources is now capable (enough) to sit at 1.0.0. It's ready to use for a LABjs test suite.

Edit: it's matured to 7.0.0 now and has a full test suite of its own, so it's definitely reliable enough now for LABjs to use.

[kylebakerio]

that blending in scantree feature looks awesome.

[jbmonroe]

This is sort of a mix of ES5 and ES6. I don't know if support for IE11 is required, but if it is, some of the property definitions will have to be downgraded to the ES5 style.

[getify]

@jbmonroe Pretty sure the src/index.js file doesn't have any ES6 in it. My goal is definitely to target ES5. The test suite does require ES6 at the moment.

[jbmonroe]

Dunno about that. Mock-DOM index.js has some ES6-looking get/set code in Object.addProperty:

get() { return thing; },

vs

get() : function () { return thing; },

Also in an obj = {} setup as well.

JSHint also wasn't happy here:

function setupLocation(location) {
	var loc = {
		toString() {  // <<---
			return location;
		},
		get href() {    // <<---
			return location;
		},
		set href(val) {  // <<---
			location = val;
			parseLocation();
		},
		assign: function assign(val){
			this.href = val;
		},
		reload: function(){},
		replace: function replace(val){
			this.href = val;
		}
	};

Those look very ES-sixy to me, too.

[getify]

@jbmonroe

Ah, I thought you were talking about LABjs since that's this repo and the main topic of the thread.

Yes, "Mock-DOM-Resources" uses ES6 because it's primarily designed to be run in node. It's only used by LABjs' test suite, so again the tests are ES6 but LABjs itself should be ES5.

ES6-looking get/set code

BTW, getters/setters are ES5 not ES6. But there are a few other ES6 features in Mock-DOM-Resources, indeed, such as concise properties in object literals.

[artknight]

@getify Thank you all for the awesome work!!! Just curious when this might be released?

[getify]

https://jasonformat.com/modern-script-loading/

[fatso83]

@artknight I am wondering if @getify is hinting that there won't be a version 3 as it's no longer needed when using the module/nomodule and typical bundler workflows of today.

[getify]

No I am not hinting that. 3.0.will definitely eventually happen (once I can write a sufficient test suite).

However, the landacape of this stuff is shifting, and 3.0 needs to eventually "catch up", including handling ES6 modules. The article has some useful hints/tricks I want to remember and use.

Also, 3.0 will likely also include my thoughts on using service workers client-side to improve loading behavior. Lots more still to explore here, exciting potential.

Unfortunately, lower priority since very few people care about loaders any more.

[getify]

https://www.filamentgroup.com/lab/load-css-simpler/