Ask HN: Why does React need 1484 dependencies by default?

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.

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.

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?

> But I will check out Vite nonetheless, curious how it fares against it...

It is 100x better. :)

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.

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.

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.

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.

Are you including the human-rider power source?

I think that was some misguided satire