Comment by debacle | Hacker News Reader

Comment by debacle | Hacker News Reader

Parent Full thread

This sentiment is trendy (and a bit edgy among people who still refuse to learn modern JavaScript), but it's missing the point. React is the first JavaScript platform that feels well engineered for the web.

"React suffers churn" -> goes on to talk about a lot of things that aren't React.

"React should stay in its lane" -> React has a router to better manage lifecycle state. And it's simple and flexible and easy to work with.

"React's talent pool is diluted" -> lol

"React is not fast" -> This is true if you are comparing to e.g. htmx, but except for a bulky first load, React is just as fast as anything else.

"React is overengineered" -> React is simple. It's good because it's simple. The data flow and rendering flow are intuitive once you understand them, and once you think in React, things become so nice that working with plugins that aren't React-y becomes kind of frustrating.

React is a great framework for app dev. It has nice conventions, a simple learning curve, a good ecoystem, and good corporate support. I don't need React, but I use it because I like it.

> React is a great framework for app dev.

But not every site is an app.

People detest Word because not every file is a document. Perhaps you are too old to remember, some hopeless folk writing their code in a word document like it was a good thing... (it had macros and viruses even! What a fabulous program)

> React is simple.

Its not simple, though. Js is a bloated nuclear wasteland at this point, so it might not look half bad compared to the other mutated monstrosities lumbering about, but that's it.

> manage lifecycle state

As soon as you have to say that, you aren't in simple land anymore. You're in "I have 10 features and 100 states and OMG don't break production" state.

The point about "dilution" is especially salient. Call it elitism, or whatever, the popular framework/language attracts the lowest common denominator - unpopular languages don't necessarily save you from this issue, but they make it more likely that someone took time and effort to care about being a good developer, not just an employed one.

> But not every site is an app.

That's what he said. He said it's good for app dev. Sites that aren't an app (or web app, or SPA, or whatever we call those things these days) should not use react as it makes no sense as a choice for that case

This is something I see people criticize react a lot and it makes no sense to me; "React isn't good at a static site/fast HTML page/non-stateful and complex app!!" It's not supposed to be! It's not for that. It's not a criticism of the framework. I'd love to read a criticism of the framework for what the framework is used for: complex stateful web applications.

> React suffers churn

This one in particular always seems to be pulled out by people advocating for yet another new framework. I don't do much frontend these days...for like a decade now, but as a mostly outsider who occasionally dabbles, React has been a constant for a long time now. The latest stuff in Next looks fantastic, in the real world we were never able to build anything nearly as nice as what is possible these days. There's a lot of historical revisionism and rose-colored glasses being worn these days, but the truth is that most web apps have always been garbage, and that will probably never change either.

The library API itself might be stable, but the ecosystem is not. And that ecosystem has vulnerable libraries that should be updated.

And that's not even going into using a big component library, like Material UI, which might be its own nightmare.

This is something I've dealt with a lot personally, and I've made a good attempt to avoid unnecessary 3rd-party dependencies. But the huge churn continues in the build tooling, testing, linting, etc.

>React is just as fast as anything else

React rendering can get very very slow. A classical example are inputs that update very slowly when you type something. "Best practices" lead us many times to this when we round-trip the whole state from input change event, to global store object, immutable changes and back to the input. You can fight it with React.memo and by just mutating the state in-place.

Recently, I found valtio helpful as it allows to hook React components to rendering for parts of the global state.

Also all this useEffect(), useLayoutEffect(), and when it's not enough useEffectEvent() [1] and useEvent().

[1] https://react.dev/reference/react/experimental_useEffectEven...

I don’t know about simple learning curve I feel like it’s quite a different paradigm especially compared to vanilla. Not necessarily difficult just different.

Reply on news.ycombinator.com