Caveats aside, I do think the proposal laid out here is a good thing. Being able to load scripts that are aware of their loading lifecycle as well as being written in a declarative manner are things I would personally like to see come out of an experiment like this. My only concern is that is scheme is very obvious about semantics of the grouping, for example, does that attribute define that a script loads *before* or *after* the given stage? Can that be customized? Intuitively I would think given an attribute value of "visuallyLoaded" that a script takes part in the execution leading up to visuallyLoaded, not afterwards, but that may not be logical for everyone.
Interested to see where this goes. Eli Perelman On Wed, Oct 28, 2015 at 12:56 AM, Tim Guan-tin Chien <[email protected]> wrote: > What build script, or webapps-optimize do at the stage you are describing, > is essentially "linking" -- a group of code to be lazily loaded is simply > dynamically linked. > > In an ideal world call dependencies should have been dealt > programmatically and computers can make the best decisions on what to > loaded with HTML and what to group into "DLL"s; but so far the lack of > dependency information between JS files and CSS and HTML has prevented a > tool like that from emerging (or there is one already out there, unaware to > me). > > The proposal here looks like a good improvement to the current > LazyLoad/webapps-optimize syntax, so I think you should just implement it > and use it if you are interested in keep developing the current toolchain > -- as long as we are happy with it's test coverage and we are confident > with the ease of migration to the next thing come up. > > > On Wed, Oct 28, 2015 at 2:44 AM, <[email protected]> wrote: > >> On Tuesday, October 27, 2015 at 10:56:12 AM UTC-7, James Burke wrote: >> > For apps that use a different HTML document for each view, it means a >> > few built files that contain some duplicate code, at least for the >> > common core of functionality (the stuff that is not view-specific but >> > which all views need). I expect to see an increase in app file size on >> > disk/in packaged format. Although perhaps that is already a known >> > thing for the separate view HTML files if they are already getting >> > gaia_build_*.js files. This new approach might reduce sizes from those >> > levels. >> >> We can be even smarter than that! >> >> We could allow for some naming convention shared between files. I can >> imagine sth like: >> >> <script role="shared-db" data-lazy-src="./foo1"></script> >> <script role="shared-db" data-lazy-src="./foo2"></script> >> >> >> And then in all HTML files it links to a single ./js-opt/shared-db.js. >> >> > It also seems to imply an extra layer of implicit dependency >> > knowledge: not only should you order the scripts based on what you >> > know of their dependencies, but also to make sure use the correct >> > attribute for load section. This is hopefully easy to spot though: the >> > common stuff probably all fits in a similar "role" name. >> >> That's true. But I believe that as we aim for good performance >> characteristic with our apps we do want our developers to make conscious >> decisions on when to load what JS to meet the performance budget. >> >> If you already have to think where to put performance.marks, it should >> actually help you to cluster JS code to meet those bootstrap stages. >> >> > Not sure how this works running in a debug/non-built state, if the >> > roles are used as loading keys, but those roles have not been >> > aggregated. Maybe they are just ignored in that case if it can detect >> > a non-built state. >> >> In debug/non-opt stage I believe it'll work the same way as it does right >> now - it'll just ignore the roles and load each script separately. >> >> > Anyway, just some things to consider during the experimentation. >> >> Thanks for that! >> >> > For the apps that are using a module system/alameda/r.js: you can get >> > a similar effect by using a dynamic `require(['module_id'])` inside >> > app bootstrap stages to dynamically load layers of code. Email does >> > this to delay loading the model layer/worker until the view has been >> > worked out. >> >> I think that for alameda module loader this doesn't change much at all. I >> can imagine that such code might be interested in bundling and then loading >> './js-opt/foo.js', but that will break for non-optimized code, so I'd >> prefer not to touch that. >> >> > Using a module system like the one used in some of the gaia apps today >> > will also translate well to the future when the ES module system is >> > fully functional. That one will also be an async-based loader. >> >> In that future I imagine we will want to bundle groups of files together >> or we may learn that with http2 and faster I/O on our zip reader we really >> don't need to bundle files at all anymore :) >> >> zb. >> _______________________________________________ >> dev-fxos mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-fxos >> > > > _______________________________________________ > dev-fxos mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-fxos > >
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
