Consider using code splitting for components

[skulptur]

Muban is structured by default with the concept of blocks and components. We could improve UX and SEO by splitting the code (and styles?) for either just blocks, or both blocks and components.

I assume this would have to be implemented in Muban's build system and initial setup, as well as in how muban-core instantiates and deals with components.

[ThaNarie]

Sorry, but i'm not understanding this issue and request fully :)

1. what are current UX and SEO issues?
2. what is the exact change going to look like? (split up what, how, in source, in output, in bundle?)
3. and how does that improve/fix the mentioned issue?

[skulptur]

1. UX and SEO as in faster page loads due to reduced bundle size and parsing time, since we ship code and styles for all blocks/components that we develop rather than only what we use in an a given page.

2. We would probably start here. The scope of the changes depend on what approach we go with. I assume this is something that is both build time as well as how we develop for Muban, and could span changes in muban-core as well. The split would be at the block/component level.

3. To quote webpack's docs, code splitting "can be used to achieve smaller bundles and control resource load prioritization which, if used correctly, can have a major impact on load time."

[ThaNarie]

Ah, webpack "code splitting" :D I totally missed that!

Let me entertain you with two other things related to this:

1. There is already a "standalone" build part, that compiles everything from a single page-yaml. But that would only be useful when it's not CMS controlled, and just statically rendered.

2. There has already been work started (by @jesse-mm) to have a more old fashioned traditional approach to this, for CMSes that want to be in control of bundling. This means we output JS and CSS files that expect certain information to be present on the window (loaded in an earlier script tag).

But basic code splitting might be a good option, which could make option 1 irrelevant, and could be used when option 2 isn't required for that project.

To make that work:

• The JS for blocks/components can only be loaded once the HTML is done rendering, and the main bundle has started parsing and executing, so could result in a smal delay (normally JS and HTML are loaded at the same time) - bandwidth would be less, but startup time might be similar-ish (depending on connection speed).
• for blocks, whenever looping over the HTML elements for which they need to be inited, the chunks need to be loaded before making them interactive.
• normally when initing, all blocks are already registered, so this reverses some things a bit
• doing the same for components could result in a lot of chunks and individual requests when doing a lot of nesting.
• and for components, since execution happens in a certain order (top-down, based on dom-tree nesting depth), the initing can only be done when the block and all its components are loaded.
• normally all blocks are interactive after init, and if communication between blocks is needed it can count on being there, with this async behaviour in place, we need to make sure there is an API available for this.