Why I Like React (even in 2024) | Hacker News Reader

Why I Like React (even in 2024)

ejosh.co

25 pointsjohanan15 comments

> One way data binding that is immutable and has explicit functions for each state transition is a major feature.

> <Tag a="b" x={y+z}>{valid JS expression}</Tag> > is > React.createElement(Tag, { a: "b", x: y + z }, [<valid JS expression>])

If you take the main reasons React is criticized and claim it is a feature, surely you have refute the criticism more thoroughly than "This seems so simple, yet do not underestimate it." or "That is powerful. Do not underestimate this."

Modern frameworks (Svelte / Vue / Astro) are about using the platform. They are performant, efficient, easier to read, easier to write, and easier to understand.

I don't see any reason I would pick React for a greenfield project anymore.

I get that if YOU don't want to use a modern framework and want to stick with what you know, sure, by all means, pick React. But writing even a semi complex application in both React and Svelte should make it immediately obvious that React is antiquated, if you give both frameworks a fair shake.

>They are performant, efficient, easier to read, easier to write, and easier to understand.

Proof? Source?

>I don't see any reason I would pick React for a greenfield project anymore.

I don't see why you wouldn't. It's stable, performs well, works in every browser, easy to find answers for problems you run into, and almost every knows it (or should, it's 2024, you don't have an excuse anymore).

>I get that if YOU don't want to use a modern framework

React is the modern framework. It's nimble, concise. The other frameworks are regressive -- they make mistakes that older frameworks already highlighted as being problematic over time.

You should read this article, it was quite good, even if you do continue to use React after. It's good to understand the alternatives, even if you never use them.

https://joshcollinsworth.com/blog/self-fulfilling-prophecy-o...

It's been a few months since I read it, but I recall the main thing I took away from this was: React isn't necessarily the best choice, other frameworks provide better performance, development experience and tooling that should also be considered

Of course these are just opinions. Everyone should consider all the facts and come to their own conclusions about what they use and don't use.

Companies will continue to use React of course. But I'm not sure if I would use vanilla React for anything I have complete control of.

> It's good to understand the alternatives, even if you never use them.

I understand them quite well. I would say I probably understand them better than OP.

I’ve done exactly this. Can confirm you are correct. Svelte is also much more performant in the client. But react is great in its own ways and I particularly like the way it tends to point developers towards composition of small components.

> But react is great in its own ways and I particularly like the way it tends to point developers towards composition of small components.

But this is so table stakes nowadays it's like saying your restaurant has a bathroom.

I remember thinking I’d like to pick up react for some changes we were planning at work. I spent a weekend with Road to React making a simple web app. I was amazed how overly complicated it seemed and that I was being told “there’s no DSL” but JSX sure seemed like one. I’m a moron and not some special coder so maybe that’s why. I was also using rails 6 at work at the time, but 7 seems to have eliminated any need we thought were were going to have for react so that’s been nice.

Each person that I’ve come across who likes react is super smart and I can’t follow what they are trying to say is so great. So maybe don’t listen to me anyway.

React and MaterialUI enabled me, a great backend dev and terrible front end dev, to create the early versions of a front end for a product I’m working on.

It made front end approachable and for that I’m grateful.

I like React because I remember life before React. Bringing functional programming to front end was a huge deal.

For me Reacts problems are a confusing API (useEffect is too easy to cause invisible infinite render loops, contexts tend to cause massive rerender chains) and slow hydration performance, these are both hard issues that the article doesn’t really touch on.

JSX != react

if you just like templating in JavaScript do so, that doesn't mean you want react

Yeah Preact provides you with most of the benefits of React without the massive bundle size of react-dom (react-dom is roughly 130kb minified, whereas Preact is about 11kb minified) [1][2].

The author even mentions Solid, so presumably he's aware that there are other frameworks utilizing JSX.

[1] https://bundlephobia.com/package/react-dom@18.2.0

[2] https://bundlephobia.com/package/preact@10.20.0

I always forget to compare to react-dom, rather than react. Easy to forget that react-dom is a peer-dependency rather than a direct dependency.

My JSX-based but not React framework has one large direct dependency (RxJS), but still comes in less than react-dom and comparable to preact:

https://bundlephobia.com/package/butterfloat@1.4.0

Similarly, I have to keep remembering that when trying to argue for web component embedding that it isn't competing with just lit, but generally lit and lit-html together:

https://bundlephobia.com/package/lit@3.1.2 https://bundlephobia.com/package/lit-html@3.1.2

I wonder if bundlephobia needs more of "peer dependency" mode.

It's definitely easy to forget about peer dependencies, which is why I'll often just spin up a Vite project and examine the actual build output to be certain about bundle sizes. To be fair to React though, in any production Preact app you'll probably end up pulling in either Preact Hooks or Preact Signals, which will add a few kb (unless you're using class components), but Preact Hooks is still only 3.7kb [1].

In the case of lit, I think lit-html actually is a direct dependency of lit (unless I'm reading it wrong)? In the composition section at the bottom of lit's Bundlephobia page it says lit-hmtl makes up 46.1% of lit's bundle size.

The one thing you do have to remember about lit though is that if you're server side rendering you'll also need the @webcomponents/template-shadowroot polyfill, and @lit-labs/ssr-client/lit-element-hydrate-support.js [2].

I agree that Bundlephobia needs a peer dependencies mode. It still might be tough to be exhaustive about these things because react-dom depends on react as a peer, but confusingly the reverse is not true, because even though almost everyone is using react with react-dom, you could technically render to a different target (e.g. Ink uses react to render terminal UIs). Bundlephobia would need to be aware of packages that are so commonly used together that they're de facto peer dependencies, even if they're not de jure peer dependencies.

[1] https://unpkg.com/browse/preact@10.19.3/hooks/dist/

[2] https://lit.dev/docs/ssr/client-usage/

Yup, that's a great thing to highlight.

I tried out Deno+Fresh and Astro. Both are JSX based, but they're not React. And JSX-based things are now starting to offer really compelling features you'd have to glue together yourself or can't do in React directly. The single biggest thing I've really liked about Fresh and Astro is the both allow you to ship vanilla HTML with 0 JS without any effort, as well as easily enabling dynamic island functionality for areas where you do want it without going full blown SPA.

Reply on news.ycombinator.com