FRESH
Hacker News
Hacker News Hacker NewsOne reason it says that React is a poor choice is performance issues. But front end performance issues are almost never the most pressing issue to deal with. React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. Yes, there are a few specialized domains where this will matter. No, you probably don’t work in one. Greater leverage can almost always be derived from improving the backend.
The second reason the author says is that it’s based on a legacy eventing system which supports IE. The author goes on for quite a while to say how bad this is, but I question the assumption it’s predicated on: the legacy eventing system never bothers me, and it doesn’t create issues visible to my users. As far as it seems to me, this argument is akin to saying that React hasn’t bothered refactoring an old part of the code base. Yes, that’s not great, but it hardly strikes me as a reason to drop a framework entirely.
Finally, the author doesn’t actually give a prescription as to what to use instead of React. This is, personally, where the argument really falls apart. React does make a set of tradeoffs, I don’t deny that, but most alternatives I’ve seen make a worse set of tradeoffs that shift more work onto the engineer. Of course, since the author doesn’t actually highlight any alternative, we can’t have a discussion about what you’re trading away, but I suspect that the author makes no proposal because he knows that any alternative would immediately be shot down as obviously worse than React.
It's because when you write code using these libraries, your code looks nice.
I cannot say that for a LOT of libraries, especially MOST frameworks. Sorry for calling AngularJS out but look at a code sample from early Angular: https://stackoverflow.com/questions/42823436/angularjs-error... (It looks terrible.)
React will be unseated like jQuery got unseated when someone makes something that looks nicer. Every time you write a library (or even API at work), make sure to look at your code samples and you better be 100% be able to say "this is pretty."
People love complaining about React, but I don't know if they remember the pre-React world where you had to write the code to manage O(n^2) UI state transitions via recursive mutating callbacks. Simple things like "have a the list of photos shown always kept in sync with a label showning count of photos" was incredibly error prone, and the complexity of implementation went up quadratically with the complexity of your app (due to the n^2 state transitions you needed to worry about!)
Today React is not the only one to do this O(^2) to O(n) complexity reduction, but it was the first to go mainstream, and very much deserves its success in spite of its various shortcomings
Most of the people commenting on this piece won't have read this whole article (it's long, and internet attention spans are short). As a result, you'll find plenty of the comments here were exactly predicted by his writing.
I see him as something of a Cassandra at this point, doomed to see the truth about web performance based on many years of research... and then to have nobody believe him. https://en.wikipedia.org/wiki/Cassandra
“Most sites” sit in the world of marketing, ecommerce, blogs. True, they don’t need an SPA.
Then there are businesses that “require” highly dynamic websites with tons of data funneling through them. I use require here in the sense of business requirements set by the various Product teams.
These products benefit from being an SPA. Preload and fetch is such an incredible paradigm for speed and interactivity that every company I’ve worked for has appreciated. Company employees are not trying to run their work browsers without JS nor do they even have to particularly worry about mobile support. It’s a very predictable environment: office, work laptop, internet that can support video calls, and a modern browser. That’s the operational stack that many businesses require.
> The predictable consequence are NPM-algamated bundles full of redundancies like core-js, lodash, underscore, polyfills for browsers that no longer exist, userland ECC libraries, moment.js, and a hundred other horrors.
People really love to hate on npm without trying to understand the reason why it exists in its current form: https://bower.sh/my-love-letter-to-front-end-web-development
As a semantic aside, I wince when people call React a framework. If we think of an SPA in terms of an MVC framework, it primarily handles the V. So really it’s a view library since developers can use whatever M and C they want. Next.js is a react framework and as a React expert it’s something I have zero interest in using.
I could keep going but these arguments have been argued and counter-argued before. For a different spin on the success of react: https://bower.sh/react-is-bad-because-its-great
This has felt increasingly untrue recently. I hope I'm just experiencing the peak of the bell curve but I've been bumping into more and more devs who only have experience in SPA React and associated styling frameworks. Ask them to actually style something and they flake out.
I was used to some tribalism in backends (everyone thinks theirs in the best and equally hates PHP devs and Wordpress) but can all publish a static page if asked.
It's a self fulfilling issue. Mid-managers want React because Facebook and pre-juniors train to meet job postings. Not enough question it.
• A large portion of the cost of maintaining a code repository goes toward maintaining the build.
• Multiple builds per repo create significant costs.
• Any web application with a UI _requires_ a frontend build for CSS/JS. Anyone around from the JQuery/pre-SASS days will recall the mess that lack of things like dependency management and ability to control import order caused.
• If the frontend build is already baked into the process, you can save costs by _only_ using a frontend build.
• SPA patterns are the easiest to use with a frontend build, have the most examples/comprehensive documentation.
Also, website aren't slow because of React, they are slow because of shitty developers or insufficient budgets.
Over the years, I'm seeing more and more unlearning of fundamental web from new frontend devs forged in boot camps.
Blazor static rendering provides a great UX for rendering static content, Streaming Rendering is great for pages that needing to dynamically update and any pages requiring client interactivity I just progressively enhance Blazor's static content with Vue - avoiding any npm node_modules dependencies or client build tools.
The only point I can agree with is that React is stupidly hard to learn. It feels like a tool made for aliens, though once you master it, it can be pretty efficient.
Sorry to be the bearer of bad news, but the JS-free web isn't coming back. And if you're using modern JS, you might as well use React (or a similar tool). The user won't be able to tell the difference.
Good thing we’re mostly keeping the attitude to hobby projects.
Can’t imagine hundreds of artisans™ bikeshedding over what the hell this even means.
And I can’t read with a straight face an article talking about complexity of React while suggesting Vue (sic!) as an alternative. Lol!
- a web site -- which has low interactivity requirements. Blogs, documentation sites, etc, go here. A vast majority of websites are in this bucket
- a web application -- which has high interactivity requirements. Things like Gmail, Linear, Google Calendar, and an enormous amount of SaaS apps fit in this bucket of things.
React is better at anything else at making the second. React developers happily pay the weird tradeoffs that come with it in order to efficiently develop the second.
React is pretty reasonably good at making the first, but the negative costs are more obvious.
As someone who has worked on one of the most consumed React apps in the world (Discord), I think the concerns with React are overstated. People want a good product, they don't care about the framework and it's costs. React is one of the most efficient (in terms of developer productivity) ways to get there.
I'm not a React loyalist; I would love to see someone dethrone React. My ears are always to the ground for new developments in technology. In my opinion it hasn't happened yet, but I would be surprised if it never happens.
The React API is way nicer to construct DOM trees than using Fragments, creating and appending children elements, concatenating strings to produce HTML, etc.
Imagine being able to do this without importing any 3rd party code:
const content = html`<h1 id=hello>Hello world!</h1>`; // New API: html Tagged templates [1].
console.log(content);
// Outputs: { type: 'h1', props: { id: 'hello' }, children: ['Hello world!'] }
document.querySelector("#container").patch(content); // New API: HTMLElement.patch.
I’m not aware of any initiatives like this currently. WebComponents could also benefit, as building a DOM tree within a class extending HTMLElement is still cumbersome: the WebComponents API doesn't really add anything to simplify DOM handling, which is why libraries like Lit exist.
--
1: Inspired by https://github.com/developit/htm
Unfortunately, it seems essentially impossible to get get traction in my country so I'm unsure what to do with it. I use it for my own projects. See https://saasufy.com/
I'm inclined to think this is one of the areas that GenAI can massively reduce cost. Claude will even iterate wireframes (in React).
As for performance, that's not going to ever be a framework problem. That's a deployment and scaling and architecture problem.
I once was told to make a product "cool" and after struggling to understand what "cool" even meant, I came to an idea. Things are cool if they make it so you never see the world the same way again. react-three/{drei,fiber} and threejs are cool. [For example https://r3f.docs.pmnd.rs/getting-started/examples]
It isn't? I find React to be great to work with.
I'm also glad that the local-first movement got some traction.
One reason for the mess seems to me is the coexistence of many paradigms for achieving similar functionality (for example you can draw many different boundaries between client and server).
Combine this with the many distinct use cases (form factors, application types etc.) and the various non-interoperable platforms and you have a serious combinatorial optimization problem.
Depending on what one wants to do there might be a sweet spot of the 80%/20% type. Alpine.js seems to one such, which if it was developed many years ago it may have saved a lot of wasted complexity.
GridWhale runs your code entirely on the server and then remotes the UI to the browser via a platform layer.
The advantage is that you can program a web app as if it were an old-style GUI app on a PC: your program has full and direct control over the UI. For example, imagine you need to disable a button due to permissions. In GridWhale, you just check the permissions and set .disabled = true on the control. This automatically propagates the setting to the UI. And because the .disabled property is on the server, it stays disabled even if you hack the client.
In contrast, with React or any framework-based UI, you need to write code in two places: on the server (at the API level) and on the client to show the proper UI. And if you're not careful, these two can get out of sync.
Of course, GridWhale is just a different trade-off. It works great for traditional business apps, but would not be appropriate for low-latency video games (at least not yet).
I really wish these people would pick up a history book. Unlike back-end developers, whose worth is intrinsically recognized as necessary, front-end development was lowly micro-managed job that must simultaneously keep up with customer expectations in a variety of formats while also rendering whatever slop passes for a REST API. React’s adoption was a combination of talented marketing and a genuine empathy for the frustrations of a 2010s web developer. They gave us a white-lie to pitch the idea to our managers: “It’s just the ‘V’ in ‘MVC’!”
JSX freed us from the jQuery-Rails template spaghetti. A quiet revolution soon followed and everyone’s been butthurt ever since.
Look — Server-side templates, especially the “stringly” typed variety, are a demonic chimera suitable only for depraved alchemists. There’s no type-safety, no IDE references. You’re in Hokey Pokey Hell — we start with a string, now we’re interpolating, back again, now once more deeper and let’s really put your editor’s syntax highlighter to the test!
It’s no surprise that stringly typed tools like HTMX and Tailwind are so deeply admired by mid-career developers who are frustrated by their lack of experience and eager to prove their talent. That’s all very normal and healthy, but the problem isn’t that React is too complex. Building software as team is a complex task of communication, and pretending to be illiterate doesn’t make the hard words any less difficult to read.
There’s most definitely room for improvement in React, and the team at Svelte demonstrated that you could have your state and skip the boilerplate too. Svelte’s compiler is a genius move and unfortunately for them, React’s upcoming v19 will commodify their complement.
It’s never been about replacing React — it’s about empathizing with developers and making it easier to work together.
Re-Render the full page server side, app takes response, applies only the changes needed. Preserves scrolling state, etc.
Super simple pattern for building dynamic sites.
I think react native is always a better choice than tools like cordova while the best choice is native development. every time i use a cordova app it is painful and you just know something is off. react-native apps are a lot nearer to native experience. you can differ them if your really trying to though. but if your just want a good native ios and android app react-native is a good choice. and you can slowly learn native development from there and shift to native if you like.
React is reported to be used by 39.5% of developers worldwide, while Vue.js is at 15.4%. The number of "apps" using just HTML+CSS is precisely zero, because those aren't "apps" they're documents.
Correct. The reason is not the frameworks but the languages. What is needed is a much more high-level and feature-powerful language.
Just look at react. Passing down dependencies/values is a pain. So what did react do? It introduced contexts. Similar, other react addons try to solve this problem. But they all sacrifice type-safety in the process.
They simply cannot solve this problem; only a better language can. Typescript maybe could, but they restrict themselves to not generate code (or at least very limited, I think for enums they do it).
Without a change here, nothing can ever improve.
It is well architected, yet only uses a 500-line component lib and a 500-line router.
Things that generate html on the server side need to pay for the higher bandwidth costs that are hard to cache well.
In the other hand with spa, a well configured cdn can have a short ttl on index.html and cache the unique per deployment js bundles forever.
The only server bandwidth cost is the actual api data
Yes it’s hard to learn the mental model but worth the effort.
My one tip to make your life with react easier …. don’t use state except within a component, instead send document events …… makes react 10X easier.
Having said the above I don’t do any SSR and not a fan of it.
If I've ever come close to something like a natural law in software development, it's Conway's law. Therefore, this strikes me as saying: Design your airplane according to what the pilot needs, not aerodynamics or gravity.
Something not JS, or even TS. So it has to compile to JS or WASM or both.
Rust is cool. Dioxus looks really promising. https://dioxuslabs.com/
Elm is great. Actually quite mature in my experience. (Sure there are talks about the development model and release cadence, but still...)
Same $LANG as on the backend, as many langs compile to JS and/or WASM nowadays. But then how do you feed the browser a DOM? You still need something: HTMX, or... React?
And if you squint your eyes, isn't Elm also doing the DOM-feeding in a React-like manner? (I dont know for Dioxus).
Possibly the idea of React is really good, just Elm has implemented nicer? (and provides a good story for how to structure the rest of the application: state-mgmt, API calling, etc.
While it _can_ be super fast, in practice, it requires quite advanced knowledge of React-isms to get it there. Those React-isms require more code with increasing complexity, combine that with contributions from developers that have varying levels of experience and you end up with spaghetti code.
Consequently, I have yet to walk into a new role where the React code isn't a dumpster fire.
In a way, React feels very much like writing raw C - it has a lot of power to be fast but most developers aren't as smart as you (joking, sarcasm) so unless you're the only contributor; you're better off using a higher level language with fewer footguns.
Modern Angular, for instance, is amazingly ergonomic and the opinionated approach makes it difficult to drag the project too far down the unmaintainable rabbit hole. The compiler handles optimizations for you so you don't need to worry about render cycles or how a functional component loops around - making it friendly (in theory) to developers with varying levels of experience.
These ergonomics fall apart when developers try to make Angular projects "React-y" with tools like ngrx but for me; the biggest downside is that you have no control over the tooling (test runner, TypeScript version, bundler, etc). That is the only reason I avoid it in personal projects.
Svelte and Vue on the other hand suffer from similar problems in that they are fantastically ergonomic, but use custom file formats with bespoke compilers that are difficult to integrate with other established tools (TypeScript, linting, formatting, testing).
One thing that saddens me is that toolmakers (specifically TypeScript) sleep on opportunities to have much better front end frameworks because they don't provide the capability to extend the LSP and transpiler.
For instance the inclusion of Rust-like compiler macros in TypeScript could enable projects like Vue, Svelte and Angular to integrate directly into the language without the need for bespoke compilers and adapters to connect to tooling.
That way, much like how TypeScript has a built in compiler for JSX, Vue could integrate their template compiler within TypeScript rather than using external tooling that targets .vue files - example:
export const HelloComponent = {
tag: 'app-hello',
template: vue!(<div>Hello {{name}})</div>),
data: () => ({
name: "World"
})
}
class AppComponent {
static tag = 'app-component'
static template = angular!(<div>Hello {{ name }}</div>)
#[model]
name = 'world'
}
So ultimately, while React isn't really a great choice for web applications, it's attained a jquery-like status where it's not really good but the alternatives are worse so you kinda have to use it.
Oh, and the author would like to kindly point out that React is legacy now. Because they said so. In case you didn't know.
Use something like Leptos and be happy: