Hacker News Reader

Comment by lsbehe | Hacker News Reader

That treemap looks neat. Knowing which dependencies pull in a lot of code is very useful.

What confuses me though is how much space these libraries take.

321kb for a router? 3.4mb for material ui? 1mb for jquery?

Remember that that's source code so it includes comments and such. Node libraries don't typically strip these for publishing.

I'm on a long-term project and we're slowing shifting away from Material UI. So much bloat for not much utility.

Are you shifting to another component library or rolling your own?

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.

[1] https://github.com/material-components/material-web

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.

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.

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.

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.

> tear out everything you aren't using

I was under the impression that production builds often include tree-shaking/dead-code-elimination as one of the steps?

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:

https://www.smashingmagazine.com/2021/05/tree-shaking-refere...

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.

Doesn't this mean you can't ever easily upgrade again? You have to re-fork and re-strip-out-the-things every time there's an upstream update?

i assume these are not bundle sizes?

the bundle size of my Nuxt 3 app + server is only 1.2mb and bundled node_modules for the server are 9.6mb, while my dev node_modules are about 100mb

probably because Vue tools handle tree-shaking incredibly well

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.

Reply on news.ycombinator.com