How is JavaScript library bloat mitigated with Web Components?

Question

As someone who has tried to find a way to help content authors develop and maintain big web sites by creating (HTML) components for years, I\'m really excited to see web compone

Answer 1

We just try and keep our web component javascript to a bare minimal, keeping their footprint down very low. So instead of using underscore for whatever, we'd just use the native ES6 equivalents (considering the existing use web components, this isn't much of a stretch).

We then package our web components with one html file, one css file, and one js file. They can actually be made up of multiple files, but our build process takes care of that. Our javascript file is bundled with Browserify, allowing us to use npm modules, while have them nicely packaged within our web app.

This offers really nice tiny, but blackbloxed web components, that can share common modules without any conflicts, and without having to worry about AMD overhead, just simple commonjs for everything.

If we ever do need to bundle a heavy library across multiple components, we would either make that library external and pass it in, leaving the inclusion up the application (this is how you have to do it with backbone.js, due to backbone.js using instanceof instead of duck typing, making multiple backbone.js instances talking to each other impossible), or have the web components bundle it in using a browserify cdn server like wzrd.in — however, much better for the parent web app to handle large deps, as if the web components use different cdns, then you have a issue.