I learnt the basic web technologies 20 years ago, and have kept mostly up to date with the subset of improvements to browser APIs that are actually important. This knowledge has served me well, and I don't have to re-learn the latest thing every year because something new is trendy.
The less unnecessary complexity between me and the browser, the better. I can spend my time being productive instead of wasting it learning about how to migrate from version 15 to version 16 of some overhyped framework.
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
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.
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
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.
Same story here. I have around 50ish web applications that I run for customers. There is hardly any time spent on maintenance and is recurring revenue for me, and I can spend most of my work time on creating new business opportunities. Some of the web applications are from 2005 and display real-time information about available items in their inventory, real time customer support chat, real time sensor data from oil rigs offshore.
1. Browser APIs have subtle differences, or don't always exist in every browser you need to support (e.g, https://caniuse.com/)
2. You'll need at least a transpiler (if writing anything above ES5) and polyfills to solve #1, and if you're diving that far into the JavaScript tooling chain (bundler + babel), might as well choose to use a framework.
I have a hard time learning react, because the 'language' used is so divorced from the concepts or actions of what it is the code does... If that makes sense. So I memorize some language chunks in react that does something and this is supposed to be 'programming?' How can I ever know what this stuff does? And why I'm supposed to use it. I just get frustrated with all these frameworks.
But you do have a point - the browser itself can sort of be considered a framework (some might say runtime), in the sense that it's a layer of abstraction. Certainly an imperfect one, but an extremely mature and stable framework with excellent backwards compatibility.
I learnt the basic web technologies 20 years ago, and have kept mostly up to date with the subset of improvements to browser APIs that are actually important. This knowledge has served me well, and I don't have to re-learn the latest thing every year because something new is trendy.
The less unnecessary complexity between me and the browser, the better. I can spend my time being productive instead of wasting it learning about how to migrate from version 15 to version 16 of some overhyped framework.