Hacker News Reader

Comment by mhoad | Hacker News Reader

Genuinely confused why someone would reach for React in a 2022 rewrite scenario.

It is on a bad path in terms of integrating with the web platform and doesn’t seem to have any clear signs to resolving that technical debt.

View on HN

I chose React in 2022 for a new app. I looked at the alternatives, and the only ones that seem mature enough are Vue and Svelte. Vue honestly doesn't really seem that different to me. Svelte is great, but the ecosystem is a fraction of react's and I don't want to waste time looking for libraries. The one alternative that looked amazing was htmx. I would honestly love to use that but my app is too dynamic and making it in htmx would be a fun puzzle, but a puzzle nonetheless.

React is still a safe bet, there’s an enormous quantity of engineers who know how to use it.

The performance you can achieve is respectable, especially as your application grows.

> It is on a bad path in terms of integrating with the web platform

What do you mean?

Scaling development efforts is a challenge. Reaching for the most popular thing out there is a solution.

Does "most" popular thing actually matter? Or is it mostly choosing X because everyone else choose X as well?

I mean we aren't talking about a rewrite in Mithril.js here. It's not hard to find people that want to work in vue, svelte, or solid. These three also seem to beat react at every benchmark (also nearly everything is better than react performance wise it seems).

https://krausest.github.io/js-framework-benchmark/current.ht...

I honestly wonder how much bloat and loss of performance we're wasting on hundreds of millions of clients because companies and teams and orgs are no longer opting for better experiences thru experimentation or choosing better tools but simply chasing after wrong KPIs set by people that don't care about tech.

What would your suggestions be in place of React?

Solid. It will be a smooth transition DX-wise. And it's better in every angle. Except of course so called "big community", "lots of library", "easier to hire" .. poor excuse for technology advancement.

> It is on a bad path in terms of integrating with the web platform

This is some unsubstantiated claim

It’s lack of proper support for both the DOM and native browser events are both giant holes that immediately come to mind and have the unfortunate side effect of making React integrate with anything that wasn’t specifically designed for React a giant PITA.

> It’s lack of proper support for both the DOM and native browser events

What

I’m not sure what YOU are on about here. They are both well known gaps that make integrations a pain in the ass. Not sure if you’ve ONLY used React or never used React.

> They are both well known gaps that make integrations a pain in the ass.

Funny how you keep not saying what you mean across two threads. While accusing others of being ignorant, partisan, or never using something, it looks like you're just describing yourself.

So what would you recommend instead?

Probably something like Lit.dev seems exceptionally well positioned to stay aligned with the platform and give the same developer experience and a much faster user experience.

Literally everything that runs in the browser is "aligned with the platform" since there's nothing but the platform that is running in the browser.

Meanwhile, "the aligned with platform" lit.dev is busy reinventing React, but poorly:

- uses non-standard syntax like `<div ?hidden=xxx .value=yyy .@click=zzz`

- special functions of the form "this particular function call even though it looks like a regular function call will actually throw an exception if used outside a very specific place inside a string". See "built-in directives"

- as a part of the mess that is Web Components in general is now busy reinventing React Context

and so on and so forth.

But yeah, sure, "more aligned something something"

You seem kind of confused about what people are referring to here and I don’t know if it’s out of ignorance or partisanship but I mean using options that don’t have to reimplement entire core parts of the web platform that already exist but in JavaScript and in a way that doesn’t work with anything else.

I’m making the argument that would be a bad choice to make in 2022 but totally understand why it made sense a decade ago.

> You seem kind of confused about what people are referring to here and I don’t know if it’s out of ignorance or partisanship

Ah yes. Go directly for ad hominem attacks without ever telling what exactly you mean. That will definitely help you win an argument.

> I mean using options that don’t have to reimplement entire core parts of the web platform that already exist

Again: what the hell are you talking about.

Reply on news.ycombinator.com