On Tue, Oct 27, 2015 at 9:45 AM, <[email protected]> wrote: > <script role="navigationLoaded" > src="./js-opt/index_navigationLoaded.js"></script> > <script role="visuallyLoaded" defer > src="./js-opt/index_visuallyLoaded.js"></script> > <script role="editView" data-lazy-src="./js-opt/index_editView.js"></script> > <script role="settingsView" > data-lazy-src="./js-opt/index_settingsView.js"></script> > <script role="albumView" data-lazy-src="./js-opt/index_albymView.js"></script>
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. 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. 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. Anyway, just some things to consider during the experimentation. --- 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. 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. James _______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
