Hacker News Reader

Comment by ugjka | Hacker News Reader

I've seen a lot of bad React websites that are slow because the developer was a half-assed React developer or just learning and didn't notice on his 4Ghz i9 machine that something is making rerender every component on scroll event or something

View on HN

This. When someone needs to solve some particular problem, they reach for the most convenient npm package called "react-something-something" that works great until, a month later, there is more data or complexity in the application that the performance issues introduced by the component become apparent.

Funny, another commenter below made that exact comment - "I love how fast I am able to deliver features by just bringing in a few libraries"

This does not mean that you’re bringing in dead weight or security black holes. The statement remains true if you bring just a couple libraries like Material UI, an SDK or two for key API interactions, and maybe a state management lib if the situation calls for it.

The other day I pruned unused dependencies from a medium sized app we’re about to launch and package.json was not much more than the above.

Bringing in Material-UI actually feels like a good example - the last time I used that framework, it felt fairly large. I guess it was ~3mb as of their last publish (0.20?). Now, it's large enough that they've split it into ~4/5 packages, although it appears you would want to take the @material-ui/core to get started? This is 6mb alone, and the other pieces that are just material bring in another couple of megabytes, and then there are additional dependencies. So, a fairly sizable starting point, and then you've got your own code, and then you've got whatever additional components you want to pull in (more widgets, a drag-n-drop, etc), and suddenly you're looking at what the GPs were saying. The package file is probably still pretty clean, but pop open node_modules or the network tab when the page is loading. Even a small number of dependencies pretty quickly bloats up size

Material UI core is around ~100kb bundled.

If you’re doing some kind of code-splitting or SSR you can probably serve a fraction of that.

Unless you’re developing for a very particular use case like embedded, I fail to see how the raw size of the package is any concern given how much MaterialUI brings to the table in terms of interaction design capabilities and dev speed.

Regarding your comment on the network tab, that’s really got me scratching my head… I’ve done a lot of profiling of React apps and when they’re bundled you don’t see a network call explosion because you’re just downloading a couple of JS bundles at worst… I can guarantee that a React app with the dependencies you describe would have anywhere between good and excellent network performance in 3G and above.

Or, that npm package

a) is deprecated

b) has security issue, with no patch

c) web framework has major changes, making it challenging to upgrade, so you need help from framework maintainers for upgrading

Any code that you have not written yourself has pontential to break. It's same for every programming language.

And, that npm package brings 200 MB of dependencies, even though it actually requires only 10 files total.

Reply on news.ycombinator.com