App load tweaks

[t3chguy]

This PR pulls some of the simpler stuff out of my larger changeset and paves the work for code-splitting by grouping loading code better. It also converts some stuff to TypeScript. This set of changes does not yet impact bundle size.

Fundamentally (but not yet split):

• index.js should be as safe and as small as possible
• init.ts should be as light as possible but if it crashes, index.js will show an error
• app.js will load the rest of the app.

The app will later be as preloaded as possible to make the best use of HTTP/2 fetch parallelism.

[bwindels]

The code looks good, just one suggestion. I'm not entirely sure how code-splitting will benefit us though, as I suspect that the big bundles will still change every release? What are the chunks we want to eventually end up with? Perhaps this is related to Travis' Jitsi work? I'm not really aware of the details of that.

Would also be great to document this, but I can imagine you've already got that planned in the follow-up PRs.

[bwindels]

I guess you return rather than throw the error here to receive the error without a try/catch in app.js:190. Returning errors from a promise is rather non-idiomatic though. Can I suggest to do it the more straight-forward way and throw and catch?

[t3chguy]

I mean that's exactly what this code did previously as per Travis' doing except it was returning an error and a boolean

[bwindels]

Ah, yeah, missed that it was already there. Not sure how returning rather than throwing will allow first paint sooner but not too big of a deal, I'm fine either way.

[t3chguy]

commented that in the wrong place

[t3chguy]

I'm not entirely sure how code-splitting will benefit us though, as I suspect that the big bundles will still change every release?

Possibly but reusable chunks between entrypoints and also just the sanity of loading, so we can not import code which uses things like localStorage until we have ran modernizr etc.

[t3chguy]

it just gives a better progression to the app load, means first paint is sooner.

[bwindels]

I'm not entirely sure how code-splitting will benefit us though, as I suspect that the big bundles will still change every release?

Possibly but reusable chunks between entrypoints and also just the sanity of loading, so we can not import code which uses things like localStorage until we have ran modernizr etc.

I see, ok 👍

[bwindels]

I guess I'm just a bit worried of further complicating our webpack setup, but given we already have async components, this doesn't add much complexity? Wdyt?

[t3chguy]

It doesn't add any webpack-level complexity, its just the use of dynamic-imports and webpack optimizes where the splits happen