New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

It's nearing time for 3.0 #113

Open
getify opened this Issue Jan 22, 2016 · 27 comments

Comments

Projects
None yet
10 participants
@getify
Owner

getify commented Jan 22, 2016

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

This comment has been minimized.

devilking15292 commented Mar 25, 2016

@getify I'm interested in this

@dudesl

This comment has been minimized.

dudesl commented Apr 8, 2016

Maybe its time to CORS support?

@getify

This comment has been minimized.

Owner

getify commented Apr 9, 2016

@dudesl can you be more specific?

@pihvi

This comment has been minimized.

pihvi commented Jul 30, 2016

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

This comment has been minimized.

Owner

getify commented Jul 30, 2016

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

@pihvi

This comment has been minimized.

pihvi commented Jul 31, 2016

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

@getify

This comment has been minimized.

Owner

getify commented Jul 31, 2016

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

This comment has been minimized.

nyrosmith commented Sep 7, 2016

@getify is there anything I could help with?

@fatso83

This comment has been minimized.

fatso83 commented Sep 28, 2016

@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

This comment has been minimized.

artknight commented Oct 14, 2016

lets add local storage to cache the scripts!

@jbmonroe

This comment has been minimized.

jbmonroe commented Dec 24, 2016

@artknight How will you load scripts from local storage?

@artknight

This comment has been minimized.

artknight commented Dec 25, 2016

@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

This comment has been minimized.

fatso83 commented Dec 25, 2016

@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

This comment has been minimized.

kylebakerio commented Feb 19, 2017

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

This comment has been minimized.

Owner

getify commented Feb 20, 2017

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

This comment has been minimized.

Owner

getify commented Mar 23, 2017

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

This comment has been minimized.

ptomasroos commented Mar 23, 2017

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

@getify

This comment has been minimized.

Owner

getify commented Mar 23, 2017

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

This comment has been minimized.

Owner

getify commented Mar 23, 2017

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

This comment has been minimized.

Owner

getify commented Mar 26, 2017

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

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

@getify

This comment has been minimized.

Owner

getify commented Mar 29, 2017

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.

getify added a commit that referenced this issue Apr 4, 2017

@kylebakerio

This comment has been minimized.

kylebakerio commented Apr 8, 2017

that blending in scantree feature looks awesome.

@jbmonroe

This comment has been minimized.

jbmonroe commented Apr 8, 2017

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

This comment has been minimized.

Owner

getify commented Apr 8, 2017

@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

This comment has been minimized.

jbmonroe commented Apr 8, 2017

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

This comment has been minimized.

Owner

getify commented Apr 8, 2017

@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

This comment has been minimized.

artknight commented May 3, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment