But we're comparing against Angular, which has a router and the rest of the kitchen sink. If your React app is anything more than a toy, it will almost certainly require most of that sink and you'll suffer the version churn of a thousand ambiguously maintained components.
I'm not following your logic. React+ReactDom only has 3 dependencies, so I don't understand how that follows. How is React bloated because `create-react-app` gives you functionality to setup a PWA? If I don't care about PWAs, I don't need to use it, but `create-react-app` downloads it anyways.
The majority of the dependencies pulled in on create-react-app is from the `react-scripts` which helps entirely with scaffolding. Saying that React is bloated because the scaffolding generation tool downloads too much code sounds crazy.
> React alone and the tooling it requires already gives you about 1400 dependencies
When you throw around FUD like this, can you please also give us some credible sources? You can use cdnjs to get react and react-dom in exactly 2 .js files.
Can someone clarify what would happen in this scenario:
- My app requires React.
- My app also requires FooBarComponent whose dist is just a giant index.js which includes its own copy of React.
- Now I get a bunch of errors because FooBarComponent and MyApp can't share anything between themselves. React really doesn't like it when two copies are running.
According to the link in the comment, apparently React has a total dependency tree with only 7 nodes, which is the opposite of what you are describing.
I'm actually surprised, I thought React had many more dependencies.
Edit: Removed comment related to typo, no longer relevant.
The `react-dom` NPM package includes multiple different JS bundles that are used for different purposes. See that `unpkg` link I pasted in the parent comment.
There's 3 different flavors of `react-dom` for use in the client (dev, prod, profiling), and then several variations of `react-dom` for use _on the server_.
The client bundles don't include any of the server functionality.
_None_ of the bundles are treeshakeable at all, because A) they're shipped as CommonJS modules and not ESM, and B) the way the React library is written and architectured as a whole. All of the reconciler logic is intertwined and unshakeable, so even if React did suddenly switch to shipping ESM modules instead of CJS, it would still end up as the exact same bundle size.
React is not only 5.3kb because that’s not the only piece you will need to actually use it. Check out the bundle of CRA for a real-world example.
I agree with the general sentiment though. I think the issue is that it’s easy to just import the whole npm registry in a bundle and ship it — and it’s too hard to trim it down.
For you a 2MB bundle is ok, but for me it’s taking 30 seconds to open this site and I’m standing here. That’s not ok.
Frameworks like Next.js provide a sane base for this; Most others don’t.
That's pretty neat! I'd imagine it's that small because of minification too, but my experience with the React front end codebase at my work has left me rather scarred. So. Much. Bloat.
My biggest issue is with people pulling in dumb libraries on npm that seem to live on someone's self hosted server though, so some branches will CD just fine, while others don't, and then I have to troubleshoot why something completely out of my control isn't working. Ugh
I'm conflicted about this. Being able to use two versions of React on the same page has a very obvious practical benefit for developers, but man does it feel like bad practise. Yet more JS dependencies you're forcing users to download and parse before your site is usable.
I guess the overall argument with React and download/parse times is long since resolved (broadly, people don't care, those that do use Preact or similar) but for me personally it still feels like a downer for the industry at large.
This seems like a good way to exacerbate the npm problems.
reply