Ask HN: Why does React need 1484 dependencies by default?
52 comments
That's not _React_, that's `create-react-app`, which was built long ago, and isn't really used so much today for starting new projects (for obvious reasons). (In fact, it's considered deprecated)
Check out Vite: https://vitejs.dev/
`npm create vite@latest`
run through the process
--> `added 217 packages`
Check out Vite: https://vitejs.dev/
`npm create vite@latest`
run through the process
--> `added 217 packages`
The ecosystem sounds no less insane with this answer. I run into "<X> is deprecated, use <Y>" constantly at a dependency level, at a framework level, and at a paradigm level.
Also, what's Vite? The React docs mention Next.js, Remix, or Gatsby. At what point would any of these become deprecated?
To be clear, I'm just complaining, but you could change the OP's question to read as "How in the world can this number of <dependencies/frameworks/paradigms/languages> be considered sane and normal, and most of all, necessary?" and it would still make sense
Also, what's Vite? The React docs mention Next.js, Remix, or Gatsby. At what point would any of these become deprecated?
To be clear, I'm just complaining, but you could change the OP's question to read as "How in the world can this number of <dependencies/frameworks/paradigms/languages> be considered sane and normal, and most of all, necessary?" and it would still make sense
As a JS dev, the situation annoys me too, but I'll say at least it's a lot better than it used to be. We've gone from "manually clobbering together 30 different libraries to make an app" to "choosing one of 3-5 major frameworks".
Yes, those frameworks themselves still have hundreds of sub-dependencies, but usually they're managed by the upstream framework maintainers and upgraded at once. Like you upgrade your Next/Remix/Vite version and then rest of it should take care of itself, with (usually) the framework vendor providing detailed changelogs and code migration tools if necessary. It's not a perfect system but it's a heck of a lot easier than it used to be.
And once you build for production, those hundreds of libs just get tree-shaken and bundled into a few much smaller minified and compressed JS files, and often rehydrated only after the important HTML loads. Done right, it can be better UX than the old SPA days -- at a cost of increased slightly increased mental complexity for developers, but not much more than having to work full-stack in different languages.
The ecosystem is very slowly maturing. IMHO we're probably post-peak now. The last 5-7 years had a huge explosion of JS frameworks because, well, that's the language of the web, and we saw a ton of startup activity. But now that the industry is moving towards AI instead, the web is no longer cool, and probably we'll see a lot less competition/innovation and more consolidation/stagnation. I doubt many of these frameworks will survive long term. My personal guess (only) is that we'll probably only be left with Next and Vite(*) after a few years, with the others fading into history the way Ember, Backbone, Angular, etc. did.
> At what point would any of these become deprecated?
Probably 2-4 years, if history is any indication. They just get less popular and less maintained over time, but there'll always be a long tail of older unmaintained projects running on life support with vulnerable versions, etc. But most projects will move on. In my career as a web dev, I've never seen production frontend code last more than a couple years without drastic changes anyway, so I doubt it really matters. Good excuse for the next generation to rewrite everything from scratch for the nth time, lol. Management's visions and priorities rarely last that long to begin with, so it all just kinda works out... shrug.
I wouldn't build a time capsule in JS, but for websites that by their nature are ephemeral... sure, why not?
--------
* Vite is just a simple frontend processor and bundler: https://vitejs.dev/guide/features.html
It includes things like TypeScript, JSX, hot module replacement... etc., that used to be a bunch of separate libs. It's heavier than vanilla JS, but much lighter than Next.js. Great for simple SPAs, but if you need more batteries included, Next can get you (much) further before you start having to add in more third-party packages again.
Think of these like a Venn diagram. Vite is a small circle that has a lot of overlap with Next's much bigger circle.
Yes, those frameworks themselves still have hundreds of sub-dependencies, but usually they're managed by the upstream framework maintainers and upgraded at once. Like you upgrade your Next/Remix/Vite version and then rest of it should take care of itself, with (usually) the framework vendor providing detailed changelogs and code migration tools if necessary. It's not a perfect system but it's a heck of a lot easier than it used to be.
And once you build for production, those hundreds of libs just get tree-shaken and bundled into a few much smaller minified and compressed JS files, and often rehydrated only after the important HTML loads. Done right, it can be better UX than the old SPA days -- at a cost of increased slightly increased mental complexity for developers, but not much more than having to work full-stack in different languages.
The ecosystem is very slowly maturing. IMHO we're probably post-peak now. The last 5-7 years had a huge explosion of JS frameworks because, well, that's the language of the web, and we saw a ton of startup activity. But now that the industry is moving towards AI instead, the web is no longer cool, and probably we'll see a lot less competition/innovation and more consolidation/stagnation. I doubt many of these frameworks will survive long term. My personal guess (only) is that we'll probably only be left with Next and Vite(*) after a few years, with the others fading into history the way Ember, Backbone, Angular, etc. did.
> At what point would any of these become deprecated?
Probably 2-4 years, if history is any indication. They just get less popular and less maintained over time, but there'll always be a long tail of older unmaintained projects running on life support with vulnerable versions, etc. But most projects will move on. In my career as a web dev, I've never seen production frontend code last more than a couple years without drastic changes anyway, so I doubt it really matters. Good excuse for the next generation to rewrite everything from scratch for the nth time, lol. Management's visions and priorities rarely last that long to begin with, so it all just kinda works out... shrug.
I wouldn't build a time capsule in JS, but for websites that by their nature are ephemeral... sure, why not?
--------
* Vite is just a simple frontend processor and bundler: https://vitejs.dev/guide/features.html
It includes things like TypeScript, JSX, hot module replacement... etc., that used to be a bunch of separate libs. It's heavier than vanilla JS, but much lighter than Next.js. Great for simple SPAs, but if you need more batteries included, Next can get you (much) further before you start having to add in more third-party packages again.
Think of these like a Venn diagram. Vite is a small circle that has a lot of overlap with Next's much bigger circle.
> (In fact, it’s considered deprecated)
That’s not true. https://react.dev/learn/start-a-new-react-project
Vite fans recommend Vite, but that doesn’t change the official documentation.
That’s not true. https://react.dev/learn/start-a-new-react-project
Vite fans recommend Vite, but that doesn’t change the official documentation.
I'm not sure what you are seeing on that page that makes you think create-react-app is not deprecated. It isn't listed on that page at all - there are more modern choices listed.
this evan you guys always could simplify things that made complicated by front end folks
Completely unparseable sentence if you don’t know Evan You is a person. Capital letters are not just for cosmetics
I'm sorry, I'm having trouble parsing this sentence. Could you rephrase it more clearly?
Evan You, creator of Vue and Vite.
Really interesting guy. Good podcast here: https://corecursive.com/vue-with-evan-you/ and very, very much worth a listen.
His background isn't even software engineering but he has come to spearhead (at least?) two very major projects that have shaped modern web development: Vue and Vite. Both Vue and Vite are notably "simple" and fast relative to their contemporaries.
Vue really stands out as one of the few, pure community driven front-end frameworks that has achieved major uptake (both React and Angular came from the commercial space).
Really interesting guy. Good podcast here: https://corecursive.com/vue-with-evan-you/ and very, very much worth a listen.
His background isn't even software engineering but he has come to spearhead (at least?) two very major projects that have shaped modern web development: Vue and Vite. Both Vue and Vite are notably "simple" and fast relative to their contemporaries.
Vue really stands out as one of the few, pure community driven front-end frameworks that has achieved major uptake (both React and Angular came from the commercial space).
This Evan You guy always could simplify things that were made complicated by frontend folks
Not really on topic but
I mean I would usually go with NextJS since it just works so well with Vercel, providing a really convincing, complete solution.
But I will check out Vite nonetheless, curious how it fares against it...
I mean I would usually go with NextJS since it just works so well with Vercel, providing a really convincing, complete solution.
But I will check out Vite nonetheless, curious how it fares against it...
> But I will check out Vite nonetheless, curious how it fares against it...
It is 100x better. :)
It is 100x better. :)
IMO Vite isn't better or worse, it just has a different use case. Next has more bolts included (like robust SSR + fetching/caching strategies, routing, middleware, etc.)
If you're just building a SPA, using Next is overkill (and will often get in the way, actually). But for some other websites, having all of that included and supported by a single source/vendor is very valuable and beats trying to Frankenstein a project out of 30 other libs like the bad old initial days of React.
For simpler or client-only sites, Vite is actually wonderful. But it's not automatically the best choice for every project.
If you're just building a SPA, using Next is overkill (and will often get in the way, actually). But for some other websites, having all of that included and supported by a single source/vendor is very valuable and beats trying to Frankenstein a project out of 30 other libs like the bad old initial days of React.
For simpler or client-only sites, Vite is actually wonderful. But it's not automatically the best choice for every project.
It's best to compare it to Webpack - both are pretty good. Vite is intuitive with fast build times and has HMR that's easy to configure. Webpack takes effort to configure but will likely have a well supported plugin for any edge case.
Wait upon quick glance Vite doesn't come with SSR support ... ?
Yea guess I'll stick with NextJS
Yea guess I'll stick with NextJS
I built a React SSR app on Vite using Vike (https://vike.dev), it worked well enough for my simple needs. Best part was I was able to easily reuse a bunch of components from the primary React SPA app that lives side-by-side in the same project without needing to buy into the "Next.js way".
SSR support is only needed for public-facing websites that will undergo some kind of search engine indexation. For most apps this is not necessary since most apps are not accessible publicly.
NextJS does more than SSR, like determining routing based on directories and making React Server Components and Actions so simple it's hard to not choose NextJS
They've removed a ton of pain from full stack React/JS/TS
They've removed a ton of pain from full stack React/JS/TS
OK, but on the other hand I've heard from someone who worked at a startup that unnecessarily chose NextJS despite no requirement, and it really held back the organization for the rest of its existence, limiting velocity. Simple things like fetching queries become harder due to the split lifecycle. Relevant HN thread: https://news.ycombinator.com/item?id=36472166
Yeah, you definitely buy into a paradigm and ecosystem that has its own flaws. It's all tradeoffs and right for for sure.
My new project requirements for well with NextJS. I was mainly pointing out that there are a number of benefits for the drawbacks.
My new project requirements for well with NextJS. I was mainly pointing out that there are a number of benefits for the drawbacks.
While dependencies can provide convenient functionality, the JS ecosystem has tended towards excessive granularity. Many packages contain limited code yet still require a large number of dependencies .. sometimes because of tooling (as in the example in the post here), but quite often out of convenience!
Rather than hastily installing the latest shiny package, we should refactor and build reusable minimal utilities tailored to our domain.
Rather than hastily installing the latest shiny package, we should refactor and build reusable minimal utilities tailored to our domain.
Create-react-app has a whole bunch of extra stuff, like a testing library, various styling engines, HMR and other build tools that aren't included in your deployed code anyway.
Production React, on the other hand, appears to only have 2 deps: js-tokens and loose-envify
Production React, on the other hand, appears to only have 2 deps: js-tokens and loose-envify
That's not React. The stuff you need for "displaying some rectangles and glyphs in a browser" is "react" and "react-dom".
Those 1484 packages are simply for the build step. And having a lot of dependencies in a build tool isn't necessary "insane".
Those 1484 packages are simply for the build step. And having a lot of dependencies in a build tool isn't necessary "insane".
According to the latest Stackoverflow developer survey, 40% of developers use React, well above any other web framework. (42% for "professional developers").
It doesn't answer to your question, but it does answer to mine on these flexes in HN around niche frameworks and the difficulty of putting them into context.
I'm glad people are working on alternative solutions, and maybe ten years from now everyone will be using something else. But right now, 235 MB is an awfully small price to pay for something that just works, especially as a lot of it doesn't actually show up in deployment.
It doesn't answer to your question, but it does answer to mine on these flexes in HN around niche frameworks and the difficulty of putting them into context.
I'm glad people are working on alternative solutions, and maybe ten years from now everyone will be using something else. But right now, 235 MB is an awfully small price to pay for something that just works, especially as a lot of it doesn't actually show up in deployment.
It does seem insane. Lots of small dependencies upon dependencies exponentially multipy
Yea, I just simply can't fathom how this can be considered necessary...
Surely half of the stuff is not required for the basic react dev tooling to work?
Surely half of the stuff is not required for the basic react dev tooling to work?
It isn't required, but create-react-app (CRA) is designed as a kind of kitchen sink toolkit that includes a lot of things that you might not need now, but could need later. For example, while it doesn't include Typescript directly, it includes a lot of the tooling you'd need to get started with Typescript if you wanted to. Similarly with Progressive Web Apps, i.e. apps that run in the browser rather than natively, it includes most of the tools you'll need for that, and then allows you to opt in at any time.
This makes CRA a good choice for someone trying to be particularly flexible, for example building an MVP or prototype where new features are going to be thrown in fairly randomly. But the cost is maintainability, particularly in terms of tending dependencies and keeping them up to date.
A more lightweight version might be Vite. Vite does a similar job of bundling different tools together into a single toolkit, but takes a simpler approach using more modern technology.
In my experience, you can get a long way just by installing Vite as a development dependency and React as a runtime dependency and going from there. This won't give you anything fancy like server-side rendering or routing, but it works for a simple application, and allows you to add in the extra tools when you need them.
This makes CRA a good choice for someone trying to be particularly flexible, for example building an MVP or prototype where new features are going to be thrown in fairly randomly. But the cost is maintainability, particularly in terms of tending dependencies and keeping them up to date.
A more lightweight version might be Vite. Vite does a similar job of bundling different tools together into a single toolkit, but takes a simpler approach using more modern technology.
In my experience, you can get a long way just by installing Vite as a development dependency and React as a runtime dependency and going from there. This won't give you anything fancy like server-side rendering or routing, but it works for a simple application, and allows you to add in the extra tools when you need them.
Hate to say it but I get the impression (having learnt "hardcore" programming first then learnt react recently) that web dev struggles a lot from having smart-but-tasteless amateurs who don't know when to stop.
That and npm has gamified the package registry so one is incentive to funnel as much shit as possible if one cares about these things.
That and npm has gamified the package registry so one is incentive to funnel as much shit as possible if one cares about these things.
I'd probably start with vite or parcel, vitest and biome. This is for build, test, formatting and linting.
Otherwise,. Just use HTMX if you want to minimize your JS footprint.
Otherwise,. Just use HTMX if you want to minimize your JS footprint.
That is create-react-app not react itself but I agree webdev has reached a point of schizophrenia regarding dependencies and performance.
Because react (and create-react-app, nextjs and alike) is terrible, old, badly maintained.
How in the world can this number of dependencies be considered
sane and normal, and most of all, necessary?
Or even just a house or bridge. Completely trivial-seeming things are just very complex.
The javascript ecosystem is unnecessarily complex. What would be a single library in any other language (including javascript, prior to NPM) is hundreds of separate single-line modules in JS, each likely with its own bespoke testing framework and toolchain. You have a package to test if a number is even that depends on a package to test if a number is odd that depends on a package to test if a number is an integer that depends on a package to test if a number is a number. And there's probably a whole-ass C compiler in there somewhere because why not?
Whereas any other developer in any other language will just use a modulus and call it a day.
Comparing that to the complexity inherent to an internal combustion engine or a house or a bridge is an insult to engineering.
Whereas any other developer in any other language will just use a modulus and call it a day.
Comparing that to the complexity inherent to an internal combustion engine or a house or a bridge is an insult to engineering.
> You have a package to test if a number is even that depends on a package to test if a number is odd that depends on a package to test if a number is an integer that depends on a package to test if a number is a number.
LOL, perfect summary of the SOTA npm ecosystem.
LOL, perfect summary of the SOTA npm ecosystem.
That makes for a great caricature, but React does not depend on `is-even`. As for the small modules, this is just the Unix philosophy lived out, "do one thing well," which is ironically what a lot of hardcore systems people used to preach.
Doing one thing well doesn't require doing only one thing per library, you won't find any C code that takes the Unix philosophy to such an extreme. And one could easily argue the excessive granularity of packages in JS causes it to do a lot of things badly.
> you won't find any C code that takes the Unix philosophy to such an extreme
Challenge accepted: https://github.com/coreutils/coreutils/blob/master/src/true.... [1]
> one could easily argue the excessive granularity of packages in JS causes it to do a lot of things badly
Yes, easily. The same argument can be extended, and even by the same virtue, to Bash programs and the Unix stack.
[1] See also: http://trillian.mit.edu/~jc/humor/ATT_Copyright_true.html
Challenge accepted: https://github.com/coreutils/coreutils/blob/master/src/true.... [1]
> one could easily argue the excessive granularity of packages in JS causes it to do a lot of things badly
Yes, easily. The same argument can be extended, and even by the same virtue, to Bash programs and the Unix stack.
[1] See also: http://trillian.mit.edu/~jc/humor/ATT_Copyright_true.html
Bash is barely even a language. No one (sane) is writing an entire application in it. And no one (sane) is writing an OS kernel in Javascript. The context in which a language is run and the kinds of programs written with it matter. You can't compare Javascript to C or Bash or anything running close to the metal, a better comparison would be to Python or Lua - other high level dynamic languages.
There is no technical reason why Javascript packages need to be as small as they are. The strongest argument for it would be that smaller packages travel faster over the wire, and save bandwidth, but that doesn't apply when hundreds or thousands of dependencies are involved. Which is why everyone just uses webpack. And yet the web is still bloated to the point of morbidity. So what even is the point?
There is no technical reason why Javascript packages need to be as small as they are. The strongest argument for it would be that smaller packages travel faster over the wire, and save bandwidth, but that doesn't apply when hundreds or thousands of dependencies are involved. Which is why everyone just uses webpack. And yet the web is still bloated to the point of morbidity. So what even is the point?
> You can't compare Javascript to C or Bash
I'll remind you that you are the one who mentioned C. I just mentioned the Unix philosophy, which really should be language-agnostic.
> So what even is the point?
There actually is a reason, which is bundle size. There is no standard library in JavaScript, or at least any standard library present may not match the version you expect, due to different browser versions. The target platform also has no pre-downloaded dynamically linkable libraries, so everything must be bundled statically. If many of your dependencies can use some common logic, that reduces the bundle size. The fact that they aren't is too bad, but reflects mismanagement more than nature of the system, since the system enables sharing.
But regardless, what's the point of having small dependencies at all? I think there is a pretty strong reason to do that and it's to make the dependencies easy to think about, their scope limited, the chances for bugs small. In Python, it is quite trivial to end up with two incompatible dependencies, since you cannot reconcile versions easily. Recently this has gotten better with Poetry, but NPM has had a long head start on it in this aspect.
I'll remind you that you are the one who mentioned C. I just mentioned the Unix philosophy, which really should be language-agnostic.
> So what even is the point?
There actually is a reason, which is bundle size. There is no standard library in JavaScript, or at least any standard library present may not match the version you expect, due to different browser versions. The target platform also has no pre-downloaded dynamically linkable libraries, so everything must be bundled statically. If many of your dependencies can use some common logic, that reduces the bundle size. The fact that they aren't is too bad, but reflects mismanagement more than nature of the system, since the system enables sharing.
But regardless, what's the point of having small dependencies at all? I think there is a pretty strong reason to do that and it's to make the dependencies easy to think about, their scope limited, the chances for bugs small. In Python, it is quite trivial to end up with two incompatible dependencies, since you cannot reconcile versions easily. Recently this has gotten better with Poetry, but NPM has had a long head start on it in this aspect.
There's JS tooling for bundling so the code over the wire will only include the files and modules referenced.
Much like a function in a C source for doesn't output two files, the bundled and monitored output is only one file much of the time. The browser doesn't download 1400 separate files or even all the code in those dependencies.
For React in particular there are development and production versions of the library.
Not that bundles can't or don't get huge. Not that they aren't often excessive. Only in that they aren't nearly as bad at first glance.
Much like a function in a C source for doesn't output two files, the bundled and monitored output is only one file much of the time. The browser doesn't download 1400 separate files or even all the code in those dependencies.
For React in particular there are development and production versions of the library.
Not that bundles can't or don't get huge. Not that they aren't often excessive. Only in that they aren't nearly as bad at first glance.
Not the greatest analogy I've ever come across.
Take a bicycle instead, and watch in awe how simple it is designed, yet how far it gets you ...
Take a bicycle instead, and watch in awe how simple it is designed, yet how far it gets you ...
A bike still contains many complex parts and if you start taking into account what’s needed to build it, it becomes very extensive and rely on a long supply chain.
Even if you reduced it to only the minimum parts necessary for it to function as a bicycle?
Because my point was about what's necessary, not fancy add-ons.
Because my point was about what's necessary, not fancy add-ons.
It's the same reason as why it's so slow: the shadow DOM. The shadow DOM consumes 80% of that disk space. 49% is dedicated to box-shadow alone.
and watch how it says
How in the world can this number of dependencies be considered sane and normal, and most of all, necessary?
What's more is that this barebone source code already takes up 235 MB (!)
What the ...? Is this what it takes to display some rectangles and glyphs in a browser?