Re: [w3c/webcomponents] Lazy Custom Element Definitions (#782)

@caridy That we have a lot of bundlers with improving capabilities and that interoperably do code-splitting based on dynamic import is one of the *motivators* for this proposal. That doesn't detract from this at all.

- We see from app and framework developers that route-base code splitting is insufficient. Some routes are content-driven: bundling all the components they _might_ use results in a bundle that's too large and each instance of the route uses too little of the code in the bundle.
- Bundlers handle dynamic import() very well, so other patterns that rely on dynamic import() are automatically supported by bundlers.
- Internal tools at large companies, and now some open tools (like guess.js) are enabling statistical bundling. They track what chunks are actually used and feed that back into the bundler to adjust the chunks. They augment current bundlers, not replace them.
- It's often quite cumbersome to have the app have correct logic for loading components in a content-driven app. The app has to control loading the content, then scan the content for unloaded components, then have a mapping from component name to module, and then dynamic import() the module. This is probably actually a bit harder to make work with bundlers, because you need to take care to leave dynamic imports in source with a string literal argument - ie the mapping becomes a big switch statement with import calls.

Please take a look at React.lazy() and Stencil.js for different approaches here. Stencil implements lazy loading, but only for Stencil components. React.lazy() just works for any React components. That's the ease-of-use I'd like to add here.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/782#issuecomment-455631669