Shifting to a combination of rolling our own and using headless component libraries, which focus strictly on functionality and let you handle all styling. So much of the original bloat comes from the libraries' built-in styles that you then have to override creating a mess of styles; this is totally avoided with headless libraries.
That matches my experience working with component libraries. Great to throw something together that looks like Bootstrap or MaterialUI, horrible when you have a designer on staff who wants the site to look like something :-)
How've you found the experience so far? IME, making good components that handle everything you'd expect (keyboard shortcuts, a11y, responsiveness, various CSS contexts) is more complicated than you'd expect, so the codebase gets filled with half-assed and duplicated components that don't work that well. Do headless components (never used them) help that significantly?
Yup, headless components/libraries are perfect for keyboard, a11y, focus handling, state handling, etc. Usually they don't render anything at all, they just give you html attributes, event handlers, etc that you apply to your own markup. This way you can let these battle-tested libraries handle the hard stuff and you can focus on what's actually unique to your project, usually just styling.
Not to shamelessly plug, but if you check what I’m working on in my profile it should be relevant. Mostly headless, dramatically more modern, and focused on performance.
There is a new “official” one in the works here [1] that uses lots of the “latest and greatest stuff” and should be very fast when it’s finished (later this year). As far as I know it’s set to become the new default company wide implementation of Material on web.
I think when javascript is used to build html styles you end up with lots of files full of strings and boilerplate. I noticed a similar thing when I was using pixi.js for a small 3d scene. The build output was dominated by massive strings containing all of the shader code. I think once you decide on a style for your project its a good time to fork these libraries and tear out everything you aren't using.
There's a lot of "gotchas" when it comes to tree shaking in the JS ecosystem (not using the correct export style, having to do commonjs vs esm, what browser target you want like es3 vs es5 vs es2018 vs esnext), it also depends on the libraries you are pulling and if they're following practices to minimize outputs as well.
This is a decent article that discusses the basic strategies:
But basically tree shaking and dead code elimination can only be effective as the code you write. If you make it hard to parse with ASTs, it's going to hard to tree shake.
This is the size of the type declarations files (.d.ts files) that `tsc` pulls in when compiling your code. This is distinct from bundle size.
Tree shaking is a big win for bundle size. One of my big takeaways from looking at these visualizations is that we badly need an equivalent for type declaration files.