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. 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? That's true for separate views, my example is very arbitrary, you shouldn't read too much from file names. But within views we still have lazyloading groups. See Music app for examples. 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. Yeah, I used eventlistener because we have it now, but promise would be even better. > 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?), Yes, we need more granularity and we need more consistency and we need more explicit bindings. Right now it's very chaotic. > 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. I don't believe see a difference between grouping scripts for one stage from another. As I said, my proposal does not introduce any necessity for difference in behavior for current two first stages of bootstrapping except of giving them names and making it more explicit. 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. _______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
