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
