Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
NGA JS aggregation/minification strategy proposal
37 views
Skip to first unread message
zbran...@mozilla.com
Oct 27, 2015, 12:45:17 PM10/27/15
to mozilla-...@lists.mozilla.org
I'd like to suggest new way of approaching minification and concatenation of our JS code.
Currently, our strategy at build time is to gather all synchronous <scripts> in ./{appname}/index.html and jsmin them into a single "gaia_build_index.js", then gather all deferred <scripts> and jsmin them into a single "gaia_build_defer_index.js". In result instead of:
<script src="/js/endpoint.js"></script>
<script src="/js/config.js"></script>
<script src="/js/app.js"></script>
<script defer src="/components/bridge/bridge.js"></script>
<script defer src="/shared/js/intl/l20n-service.js"></script>
<script defer src="/shared/js/intl/l20n-client.js"></script>
<script defer src="/shared/js/intl_helper.js"></script>
<script defer src="/components/gaia-header/dist/gaia-header.js"></script>
<script defer src="/components/gaia-toolbar/gaia-toolbar.js"></script>
<script defer src="/js/db.js"></script>
<script defer src="/shared/js/lazy_loader.js"></script>
<!-- to be lazy loaded:
<script defer src="/js/async_db.js"></script>
<script defer src="/js/thumbnails.js"></script>
<script defer src="/js/mediadb.js"></script>
<script defer src="/elements/music-overlay.js"></script>
<script defer src="/elements/music-scan-progress.js"></script>
<script defer src="/elements/music-tab-bar.js"></script>
<script defer src="/elements/music-view-stack.js"></script>
-->
we have this:
<script src="./gaia_build_index.js"></script>
<script src="./gaia_build_defer_index.js"></script>
and then some LazyLoader is loading the remaining files one by one.
That's not a bad strategy, but it means that we have a lot of JS code that is unnecessary during app startup that has to be loaded/parsed at the same time as the code required for startup.
That leads us to use a "third stage" code that is commented out in <head> and loaded using LazyLoader class inside JS.
=============== Proposal ==================
I'd like to suggest that we tie our JS code bundling to our bootstrap stages[0].
In that world, we assign a role="" to each <script> tag. That role allows us to group scripts that are needed together. It also allows us to bundle the lazyloaded groups of scripts and remove the need for LazyLoader completely.
Here's an example of how it might work (details to be decided):
<script role="navigationLoaded" src="/js/endpoint.js"></script>
<script role="navigationLoaded" src="/js/config.js"></script>
<script role="navigationLoaded" src="/js/app.js"></script>
<script role="visuallyLoaded" defer src="/components/bridge/bridge.js"></script>
<script role="visuallyLoaded" defer src="/shared/js/intl/l20n-service.js"></script>
<script role="visuallyLoaded" defer src="/shared/js/intl/l20n-client.js"></script>
<script role="visuallyLoaded" defer src="/shared/js/intl_helper.js"></script>
<script role="visuallyLoaded" defer src="/components/gaia-header/dist/gaia-header.js"></script>
<script role="visuallyLoaded" defer src="/components/gaia-toolbar/gaia-toolbar.js"></script>
<script role="visuallyLoaded" defer src="/js/db.js"></script>
<!-- to be lazy loaded:
<script role="editView" src="/js/async_db.js"></script>
<script role="editView" src="/js/thumbnails.js"></script>
<script role="editView" src="/js/mediadb.js"></script>
<script role="settingsView" src="/elements/music-overlay.js"></script>
<script role="settingsView" src="/elements/music-scan-progress.js"></script>
<script role="settingsView" src="/elements/music-tab-bar.js"></script>
<script role="albumView" src="/elements/music-view-stack.js"></script>
-->
results in:
<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>
And then the only thing you need in your code is:
scriptElement.addEventListener('load', () => {
console.log('My lazy loaded JS view is ready!');
});
if (scriptElement.dataset.lazySrc) {
scriptElement.setAttribute('src', scriptElement.dataset.lazySrc);
scriptElement.dataset.lazySrc = undefined;
}
or if we maintain some LazyLoader:
LazyLoader.load(['settings', 'editView']).then();
That enables pretty flexible per-app decisions on which scripts are loaded with each group, and how is that group loaded (maybe navigationLoaded should be deferred? Maybe it should be synchronous? maybe it should be async?).
You can go more granular, and have separate script group for navigationInteractive, or, if you don't need to alter HTML at all, only have navigationInteractive group for binding chrome to your glue code.
It would be easy to adjust webapp-optimize to handle that, and would allow us to load the right JS at the right time. It also degrades gracefully to work the way it does right now.
Thoughts? Opinions?
zb.
p.s.
1) We may still need some lazy_loader.js which would take the scripts with a given role from head comments and load them for non optimized scenario. But in the production code we could just remove it.
2) There may be lazy loaded scripts needed by multiple lazyloaded groups. In those cases we could separate them into their own group the way we would with shared CSS or L10n resources. In the worst case, each lazy loaded script would have its own group which is basically what we do now.
[0] https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines
Currently, our strategy at build time is to gather all synchronous <scripts> in ./{appname}/index.html and jsmin them into a single "gaia_build_index.js", then gather all deferred <scripts> and jsmin them into a single "gaia_build_defer_index.js". In result instead of:
<script src="/js/endpoint.js"></script>
<script src="/js/config.js"></script>
<script src="/js/app.js"></script>
<script defer src="/components/bridge/bridge.js"></script>
<script defer src="/shared/js/intl/l20n-service.js"></script>
<script defer src="/shared/js/intl/l20n-client.js"></script>
<script defer src="/shared/js/intl_helper.js"></script>
<script defer src="/components/gaia-header/dist/gaia-header.js"></script>
<script defer src="/components/gaia-toolbar/gaia-toolbar.js"></script>
<script defer src="/js/db.js"></script>
<script defer src="/shared/js/lazy_loader.js"></script>
<!-- to be lazy loaded:
<script defer src="/js/async_db.js"></script>
<script defer src="/js/thumbnails.js"></script>
<script defer src="/js/mediadb.js"></script>
<script defer src="/elements/music-overlay.js"></script>
<script defer src="/elements/music-scan-progress.js"></script>
<script defer src="/elements/music-tab-bar.js"></script>
<script defer src="/elements/music-view-stack.js"></script>
-->
we have this:
<script src="./gaia_build_index.js"></script>
<script src="./gaia_build_defer_index.js"></script>
and then some LazyLoader is loading the remaining files one by one.
That's not a bad strategy, but it means that we have a lot of JS code that is unnecessary during app startup that has to be loaded/parsed at the same time as the code required for startup.
That leads us to use a "third stage" code that is commented out in <head> and loaded using LazyLoader class inside JS.
=============== Proposal ==================
I'd like to suggest that we tie our JS code bundling to our bootstrap stages[0].
In that world, we assign a role="" to each <script> tag. That role allows us to group scripts that are needed together. It also allows us to bundle the lazyloaded groups of scripts and remove the need for LazyLoader completely.
Here's an example of how it might work (details to be decided):
<script role="navigationLoaded" src="/js/endpoint.js"></script>
<script role="navigationLoaded" src="/js/config.js"></script>
<script role="navigationLoaded" src="/js/app.js"></script>
<script role="visuallyLoaded" defer src="/components/bridge/bridge.js"></script>
<script role="visuallyLoaded" defer src="/shared/js/intl/l20n-service.js"></script>
<script role="visuallyLoaded" defer src="/shared/js/intl/l20n-client.js"></script>
<script role="visuallyLoaded" defer src="/shared/js/intl_helper.js"></script>
<script role="visuallyLoaded" defer src="/components/gaia-header/dist/gaia-header.js"></script>
<script role="visuallyLoaded" defer src="/components/gaia-toolbar/gaia-toolbar.js"></script>
<script role="visuallyLoaded" defer src="/js/db.js"></script>
<!-- to be lazy loaded:
<script role="editView" src="/js/async_db.js"></script>
<script role="editView" src="/js/thumbnails.js"></script>
<script role="editView" src="/js/mediadb.js"></script>
<script role="settingsView" src="/elements/music-overlay.js"></script>
<script role="settingsView" src="/elements/music-scan-progress.js"></script>
<script role="settingsView" src="/elements/music-tab-bar.js"></script>
<script role="albumView" src="/elements/music-view-stack.js"></script>
-->
results in:
<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>
And then the only thing you need in your code is:
scriptElement.addEventListener('load', () => {
console.log('My lazy loaded JS view is ready!');
});
if (scriptElement.dataset.lazySrc) {
scriptElement.setAttribute('src', scriptElement.dataset.lazySrc);
scriptElement.dataset.lazySrc = undefined;
}
or if we maintain some LazyLoader:
LazyLoader.load(['settings', 'editView']).then();
That enables pretty flexible per-app decisions on which scripts are loaded with each group, and how is that group loaded (maybe navigationLoaded should be deferred? Maybe it should be synchronous? maybe it should be async?).
You can go more granular, and have separate script group for navigationInteractive, or, if you don't need to alter HTML at all, only have navigationInteractive group for binding chrome to your glue code.
It would be easy to adjust webapp-optimize to handle that, and would allow us to load the right JS at the right time. It also degrades gracefully to work the way it does right now.
Thoughts? Opinions?
zb.
p.s.
1) We may still need some lazy_loader.js which would take the scripts with a given role from head comments and load them for non optimized scenario. But in the production code we could just remove it.
2) There may be lazy loaded scripts needed by multiple lazyloaded groups. In those cases we could separate them into their own group the way we would with shared CSS or L10n resources. In the worst case, each lazy loaded script would have its own group which is basically what we do now.
[0] https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines
Yura Zenevich
Oct 27, 2015, 12:58:50 PM10/27/15
to zbran...@mozilla.com, mozilla-...@lists.mozilla.org
I would suggest using a different attribute name than ‘role’ as it is reserved by ARIA and accessibility.
Yura
_______________________________________________
dev-fxos mailing list
dev-...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-fxos
Staś Małolepszy
Oct 27, 2015, 1:10:00 PM10/27/15
to Braniecki, Zbigniew, mozilla-...@lists.mozilla.org
On Tue, Oct 27, 2015 at 5:45 PM, <zbran...@mozilla.com> wrote:
<script role="navigationLoaded" src="./js-opt/index_navigationLoaded.js"></script>
<script role="visuallyLoaded" defer src="./js-opt/index_visuallyLoaded.js"></script>
How's that different from current gaia_build_index and gaia_build_index_defer?
<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>
In a real life example, wouldn't the view-specific files live in each of the views? That's probably one of the big advantages of NGA - instead of grouping scripts with script.role, you just put them in separate html files?
if (scriptElement.dataset.lazySrc) {
scriptElement.setAttribute('src', scriptElement.dataset.lazySrc);
scriptElement.dataset.lazySrc = undefined;
}
This looks interesting, especially if it was combined with some promise-based API like script.loaded or script.ready.
Another possibility would be to experiment with the async attribute which doesn't guarantee the order of loading and doesn't make any other scripts to wait for the loading to finish. Again, script.loaded.then() could help understand when the script actually loads.
I think you're proposing three separate things:
1) split hot-path scripts by perf marks (which I think is similar to the current gaia_build_* optimization, but more granular; do we need more granularity?),
2) group lazy loaded scripts by name (which sounds like it could be very useful),1) split hot-path scripts by perf marks (which I think is similar to the current gaia_build_* optimization, but more granular; do we need more granularity?),
Would it make sense to discuss them separately? I'm slightly afraid of making our build system even more magical and making our code and optimizations less-webby.
-stas
zbran...@mozilla.com
Oct 27, 2015, 1:20:57 PM10/27/15
to mozilla-...@lists.mozilla.org
On Tuesday, October 27, 2015 at 10:10:00 AM UTC-7, Staś Małolepszy wrote:
> How's that different from current gaia_build_index and gaia_build_index_defer?
Mainly, it's explicit, and it allows us to have more groups and do more with them.
> How's that different from current gaia_build_index and gaia_build_index_defer?
Once we have the meta information about which scripts are used where, we could experiment with delaying loading until we after previous bootstrap stage, or using different loading strategy depending on the stage we aim for.
It also allows us to instrument our code to test loading strategies by loading *only* up to a given stage, for debugging/performance measuring purposes.
Right now, we have an informal agreement, but we don't follow it at all. Many apps don't use sync scripts for code needed for chrome UI (Music defers everything), other apps load everything synchronously or everything lazily. There's no consistency in this and it's a lot of guessing.
> In a real life example, wouldn't the view-specific files live in each of the views? That's probably one of the big advantages of NGA - instead of grouping scripts with script.role, you just put them in separate html files?
And we also don't know which apps will separate views in which ways. This idea is parallel to the NGA effort.
> This looks interesting, especially if it was combined with some promise-based API like script.loaded or script.ready.
> 1) split hot-path scripts by perf marks (which I think is similar to the current gaia_build_* optimization, but more granular; do we need more granularity?),
> Would it make sense to discuss them separately? I'm slightly afraid of making our build system even more magical and making our code and optimizations less-webby.
What it does, is it allows us to introduce more A/B testing on which strategies gives us the best performance times which may lead in the future to better heuristics of loading those JS bundles.
I'm also not sure what magic are you talking about. How is setting "role" (or some other attribute) on <script> different from not doing that? Because for not-lazy loaded scripts that's exactly what my strategy boils down to initially. And what we'll do later depends on the results of performance tests that we will only be able to run once we have apps that provide that meta information.
zb.
p.s. I unfortunately am much less optimistic than you are that defer/non-defer currently has any relation to where the code is used in the app loading and I see a lot of mingled code that interpolate between scripts loaded in one and another. That's part of my incentive to give this proposal.
Staś Małolepszy
Oct 27, 2015, 1:37:18 PM10/27/15
to Braniecki, Zbigniew, mozilla-...@lists.mozilla.org
On Tue, Oct 27, 2015 at 6:20 PM, <zbran...@mozilla.com> wrote:
On Tuesday, October 27, 2015 at 10:10:00 AM UTC-7, Staś Małolepszy wrote:
> How's that different from current gaia_build_index and gaia_build_index_defer?
Mainly, it's explicit, and it allows us to have more groups and do more with them.
Aren't we still limited to what the platform gives us? It seems like we only have three options: sync, defer, async -- how is splitting the files into arbitrary buckets named after the perf marks work around that?
Once we have the meta information about which scripts are used where, we could experiment with delaying loading until we after previous bootstrap stage, or using different loading strategy depending on the stage we aim for.
It also allows us to instrument our code to test loading strategies by loading *only* up to a given stage, for debugging/performance measuring purposes.
I'm not sure how easy it would be to structure the files such that this was possible, but I know you've been thinking about this for much more than I, so I'm looking forward to being able to do this! :)
I'm also not sure what magic are you talking about. How is setting "role" (or some other attribute) on <script> different from not doing that? Because for not-lazy loaded scripts that's exactly what my strategy boils down to initially. And what we'll do later depends on the results of performance tests that we will only be able to run once we have apps that provide that meta information.
There's already magic in how scripts are bundled or the fact that we still put them in the HTML commented out for webapp-zip to pack them. That's why I really like the declarative API bit in your proposal which could help us find a better solution to the zip vs. lazy loading dilemma.
p.s. I unfortunately am much less optimistic than you are that defer/non-defer currently has any relation to where the code is used in the app loading and I see a lot of mingled code that interpolate between scripts loaded in one and another. That's part of my incentive to give this proposal.
My fear is that you're trying to clean this up by introducing another layer of entanglement. It's worth a try to see if it helps, but let's be careful not to increase the complexity of the build system by too much.
-stas
zbran...@mozilla.com
Oct 27, 2015, 1:47:58 PM10/27/15
to mozilla-...@lists.mozilla.org
On Tuesday, October 27, 2015 at 10:37:18 AM UTC-7, Staś Małolepszy wrote:
> Aren't we still limited to what the platform gives us?
Currently we are.
> Aren't we still limited to what the platform gives us?
> It seems like we only have three options: sync, defer, async -- how is splitting the files into arbitrary buckets named after the perf marks work around that?
That's very different goal :)
Second, it allows us to start playing with more meaningful tests - imagine A/B testing with navigationLoaded group loaded sync/async/defer.
Or imagine memory testing where we load only until visuallyLoaded and nothing more and then perform heap memory tests.
I can also imagine ability to load JS but delay execution until we need the group.
Or maybe in the future we will bind firstPaint to navigationLoaded which will load its JS first, and then delay execution of navigationInteractive until after firstPaint.
It allows us to play with granular code loading to hit the right stages as fast as possible.
As I said, in the current scenario, the change is just to provide more meta information and more explicitly state which JS is needed for which state. In the future we may want and be able to do more.
> My fear is that you're trying to clean this up by introducing another layer of entanglement. It's worth a try to see if it helps, but let's be careful not to increase the complexity of the build system by too much.
Fun fact - our current build system de-facto creates two groups already. It just names them "defer" and "normal". I suggest to separate semantics from heuristics and allow for more groups.
Thanks for the feedback! I'll keep in mind to keep it simple and I believe we can actually make it very webby thanks to declarative API and more semantic bootstrap.
zb.
[0] https://groups.google.com/forum/#!searchin/mozilla.dev.gaia/bootstrap/mozilla.dev.gaia/OBiGuysU_uM/JU-vFK_MW9oJ
James Burke
Oct 27, 2015, 1:56:12 PM10/27/15
to zbran...@mozilla.com, mozilla-...@lists.mozilla.org
On Tue, Oct 27, 2015 at 9:45 AM, <zbran...@mozilla.com> wrote:
> <script role="navigationLoaded" src="./js-opt/index_navigationLoaded.js"></script>
> <script role="visuallyLoaded" defer src="./js-opt/index_visuallyLoaded.js"></script>
> <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
> <script role="settingsView" data-lazy-src="./js-opt/index_settingsView.js"></script>
> <script role="albumView" data-lazy-src="./js-opt/index_albymView.js"></script>
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
zbran...@mozilla.com
Oct 27, 2015, 2:46:27 PM10/27/15
to mozilla-...@lists.mozilla.org
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!
> 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 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.
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.
> 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.
zb.
Tim Guan-tin Chien
Oct 28, 2015, 1:56:43 AM10/28/15
to Zbigniew Braniecki (Gandalf), mozilla-...@lists.mozilla.org
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, <zbran...@mozilla.com> 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.
Eli Perelman
Oct 28, 2015, 12:06:35 PM10/28/15
to Tim Guan-tin Chien, mozilla-...@lists.mozilla.org, Zbigniew Braniecki (Gandalf)
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.On Wed, Oct 28, 2015 at 12:56 AM, Tim Guan-tin Chien <timd...@mozilla.com> 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, <zbran...@mozilla.com> 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
dev-...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-fxos
0 new messages