On Tue, Oct 27, 2015 at 6:20 PM, <[email protected]> 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
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
