Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Reading over the authors primary reasons to not use React, they strike me as fundamentally misguided - mostly solving problems that most people don’t have.

One 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.



> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds.

I disagree. Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device. It can take multiple seconds before the page is fully loaded. Even once the libraries are loaded, React sites often involve parsing a giant lump of JSON before you can do anything, that’s particularly CPU intensive and takes time on low end devices.

> Yes, there are a few specialized domains where this will matter. No, you probably don’t work in one.

Again: I beg to differ. Anyone hoping that their site will rank well on Google needs to factor in site performance via core web vitals. Time and time again I’ve seen React-based sites perform horribly and it’s very difficult to dig your way out of the hole after the fact.

I actually think most of the problem isn’t React itself, it’s the ecosystem and the philosophy that surrounds it so often. You’ll have React, you’ll have some extra state management library on top, you’ll have some hideous CSS in JS bulk on top because no one wants to actually learn CSS… it’s all prioritisation of developer experience over user experience. And it’s industry standard these days.


> I disagree. Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device. It can take multiple seconds before the page is fully loaded. Even once the libraries are loaded, React sites often involve parsing a giant lump of JSON before you can do anything, that’s particularly CPU intensive and takes time on low-end devices.

The entire site may take multiple seconds to load, sure, but it's quite rare that this is a React issue. Typically, the real issue is something like the website making a bunch of API requests in serial rather than parallel. For instance, the issue of JSON parsing that you cited is actually an SSR issue; that's entirely orthogonal to React, and you can make the same error in any other popular web framework.

> I actually think most of the problem isn’t React itself, it’s the ecosystem and the philosophy that surrounds it so often. You’ll have React, you’ll have some extra state management library on top, you’ll have some hideous CSS in JS bulk on top because no one wants to actually learn CSS… it’s all prioritisation of developer experience over user experience. And it’s industry standard these days.

I think you're saying "React is slow" when you mean to say "the entire frontend ecosystem is slow". To which I respond... sure? None of this is React-specific. If you don't use React, you'll still have to use state management (or manage it yourself; have fun!), figure out something to do with CSS, etc, etc.


I worked at New Relic and focused specifically on improving page load performance for one of the products using our RUM data. Even after combining/parallelizing API calls then embedding the data into the page, I found there was still an average 3-6 second average page load cost using React vs an already rendered HTML page which was nearly instant. Not huge but frustrating to discover the constraint when it was my task to improve it and our company was trying to be an example of great performance.


If your page is taking 3-6 seconds to load, you are either doing something wrong, or not understanding where the problem is and blaming React incorrectly.

My React app is statically exported and cached by the browser. There is only a single graphql call that fetches all necessary data. Backend is my only bottleneck. Everything else happens in less than 10ms.

And yes it is entirely possible to shoot yourself in the foot with any language and any framework. Including React.


That depends heavily on the device and network being used for testing. In my experience 3-6 seconds isn't out of the question by any means for a decent sized react SPA loaded on an older device and mobile network.

That isn't necessarily specific to react, any client-side rendered framework will have issues. React tends to be noticeably worse in my comparisons though, and any client rendering is going to be worse than server rendering your HTML.


You measured that after a warm cache, or did you measure loading all the JS bonanza vs loading an ssr html?

I would think that using React as an SPA application makes sense, but not if you want to sprinkle some interactivity inside some html pages.


API requests at page-load are definitely going to lower the page speed score. No API requests should happen at all, ideally, and all script and CSS to render everything "above the fold" should be loaded in-line. Nothing that is visible "below the fold" should ever run or load until the page is scrolled down by the site visitor. Only the bare-minimum script parsing that is required for the content "above the fold" should happen. Sure you can load scripts in-line for stuff below the fold, but make sure it doesn't actually get parsed by the browser until that feature is likely to be visible on the screen.

It doesn't matter what library or framework is used - even jQuery can score 100% page speeds on Google Lighthouse. It really only depends on following every single nitpicky thing that Google Lighthouse recommends, and finding a solution for it. I took a site (actually a few thousand sites) that was scoring about 5 to 35 out of 100 on Google Lighthouse (depending on the customiztions), up to 100/100 on Google Lighthouse. It took a lot of work, but the clients are happy now.

Where React doesn't do well is with lots of DOM elements. In another project I created a complex web application that had about 3000 div elements with drag-and-drop interface and all kinds of stuff going on. Well React couldn't handle it. The browser started crashing due to memory issues if the page was open longer than 20 minutes or so, it slowed to a crawl and eventually froze. I ended up switching that one component to a canvas based solution (Konva) and it solved the problem completely. I still use React for all the other simple UI stuff, but I learned my lesson about what React is really good at and what it's not.


> Nothing that is visible "below the fold" should ever run or load until the page is scrolled down by the site visitor.

On the other extreme, completely deferring any loading of 'below-the-fold' content until it's visible can also have horrendous consequences, if that loading involves downloading any external resources. Not every visitor can just make further requests near-instantly, and it's those RTTs that really slow pages down, in my experience. Excess API calls are just one (very common) source of excess RTTs.

The obvious compromise would be to load 'below-the-fold' content ASAP once all 'above-the-fold' content is finished, unless it's unacceptably heavy for the target device. (Then again, some people still won't be happy: I recently talked to one person who derided the load times of a certain blog, but I found that all of its meaningful content was loaded and visible very quickly: they were only taking issue with the Disqus comment widget at the bottom at the page.)


> Not every visitor can just make further requests near-instantly

We use a "loading" spinner. People know they have a shitty computer, and they'll wait an extra second instead of spending $1000 on a new computer. That kind of page speed problem isn't one we could ever fix, and it's something the user is typically well aware of being on their end, because every site is slow, not just ours.

> completely deferring any loading of 'below-the-fold' content until it's visible can also have horrendous consequences

We use a combination of lazy loading and SSR (not React SSR, it's hosted on a custom CMS). Content is SSR to maximize SEO. In some places we'll only render the first 3 or 4 items and then lazy-load the rest if it's a lot of data. Too many DOM elements at page load is also bad for the page speed score. Javascript is lazy-parsed, meaning the text of the script can be loaded in-line, but not parsed until the page is scrolled and the content is in view. Loading the text of a script isn't what slows the page down, it's the parsing of larger scripts that causes page speed issues. When the page scripts can be parsed in smaller chunks, the scrolling experience can be more fluid and the page speed test is satisfied. All images below the fold are lazy loaded. All 3rd party widgets are lazy loaded where possible, because they all suck and they mess with page speed pretty badly. There are lots of other tricks to get to a perfect 100 score on Google Lighthouse. Fortunately for us, "below the fold" is generally easy to accomplish across all of our sites, by the nature of the type of sites we are building. It doesn't work for all kinds of sites, but for ours it works very well.


I generate a report in our software and 70.000 cells work like a breeze (1000 rows, 70 columns). React just can’t handle adding an input to a cell.

It’s unacceptable. React touts its shadow-dom “because it’s much more efficient than updating the DOM directly”, well, that’s a big lie.

React is better than all predecessors, but it’s still the wrong abstraction.


What about AG Grid? We have apps at work with 1M+ cells. I am pretty sure that AG Grid has React support.


> Nothing that is visible "below the fold" should ever run or load until the page is scrolled down by the site visitor.

I really hope nobody takes this "advice". What are you trying to save me from?


I'm not trying to save you from anything. Stop being dramatic. I honestly don't care what you do or what advice you take.


I'm with albedoa on this one. Loading things only when you scroll to them makes for a terrible scrolling experience.


You obviously didn't read what I wrote or understand it. I specifically said this:

>Sure you can load scripts in-line for stuff below the fold, but make sure it doesn't actually get parsed by the browser until that feature is likely to be visible on the screen."

I specifically said you could load a script in-line for stuff "below the fold" as long as the browser doesn't parse it until it's used. That's very different than doing an HTTP request for a script file while scrolling.

But you know what? Forget it. I'm done trying to explain things to people who think they already know it all and didn't even understand my original comment.


You also said

> We use a "loading" spinner

> users can wait an extra second [every time they scroll to load new content]

which is exactly the bad experience the commenters above are talking about.

They understood your comment, and they disagree. This is not the good advice you think it is, unless your main goal is to score 100 on lighthouse for SEO purposes, not UX.


The loading spinner is specifically for people with shitty internet connections when loading dynamic data after the initial page load. And you're completely misunderstanding practically everything I wrote and replacing what I wrote with your assumptions. Go ahead, it's the internet, bash away all you want. But I know what I did, I know it works, and I know it's not janky at all - it's your assumptions that are wrong. The advice is good, your understanding of it is not. You don't need to reply, I won't be trying to explain any of this any further just so you can misunderstand everything I wrote, again.


People scroll pages to skim. This also sounds like it might break CTRL-F.

If I can't skim your page instantly I will more than likely churn my visit.

Doesn't matter that I have a good computer on a 1Gbps connection, you ruined my experience. I'd rather wait 1 sec for the full page to load, than wait a series of 100msecs on what should've been a fully loaded page to actually load at an arbitrary point in time.


Maybe you missed the part where I said we're using SSR for content? That solves the CTRL-F problem easily.

You (and a lot of others here) are making a ton of wrong assumptions, imagining things I never said, and making up your own problems that don't exist in my code just to try to bash me, without even really understanding anything that I wrote in my comment. This entire thread sucks and is full of low-quality trolls. I've been doing front-end for ~30 years, I know what I'm doing. Don't bother replying, I won't be responding to further wrong assumptions and bashing.


It's increasingly difficult to believe that you don't care lol.


It's increasingly difficult to believe this thread isn't full of trolls.


How do you know that was a React issue and not a memory leak, or an error in your own code perhaps?

This smells of a memory leak, particularly if you forgot to add a dependency to a hook for example, but there is plenty of non react related code that could go wrong with drag and drop interfaces too


Not using any hooks, it's simple old-school react started from create-react-app, then converted over to Preact, and then updated to use latest webpack and all libs updated to latest versions, so this project has gone through many changes and I have no doubt if I started it new today from the ground up things would be different. I think the problem was with the drag-drop library, react-dnd I think. But the point is that switching from DOM to a canvas solution fixed all the problems I was having.


>it’s all prioritisation of developer experience over user experience.

And I have been saying this for well over a decade. Hopefully it catches on.

I have always asked for example of sites done in React where I couldn't tell it is done in React or other JS Front End. The "at worst, hundreds of milliseconds" is precisely why Web Apps never felt as good as native apps. And if we collectively cant make web apps good, why not go back to Interactive Web Pages that is mostly Jank Free. I say mostly because it is still not Native Apps level.

Recently submitted, [1] why does liking a tweet re-render the entire screen? done using [2] React-scan.

[1] https://x.com/aidenybai/status/1862529226727121366

[2] https://github.com/aidenybai/react-scan


> why does liking a tweet re-render the entire screen?

They're probably using Redux, which has been the go-to for state management in React for nearly a decade. I've always been averse to it because it's implemented using contexts and triggers those full re-renders - it was designed during the class-based components era and relied on people actually implementing shouldComponentUpdate(), which isn't really a thing with modern function-based components.

If they were using modern hook-based state management like Zustand or Valtio, full rerenders wouldn't happen.


Redux uses context but does not do full re-renders except if you are using it wrong. It does a shallow compare on the object resulting from your selector to decide whether or not to re-render a component.

That being said, none of the React projects I've had the chance of working on in the last 5 or 6 years has used Redux, so stating that it's been the go-to state management library for nearly a decade kind of sounds weird to me.


> on an old or cheap Android device.

My Core-i5 24GB of RAM desktop PC that's 8 years old can pretty much do anything I used to do in 2016, except smoothly run React websites, some of which are verging on becoming unusable.

This is nuts. People should stop using their M3 Pro Macbook as a benchmark for what's 'fast enough.'


“Works on my machine” in general is a huge problem in dev culture.

I understand the desire to work on machines with lots of power and memory with a nice high res display and fiber connection. It makes the experience a great deal nicer. Even so, we should be keeping old and/or thoroughly mediocre devices around and testing on them periodically so we don’t succumb to illusions of good performance.


It’s just embarrassing any image scrolling site will eventually just eat all the memory and crash and you lose your place. Used to kill me back in the Tumblr days and React perpetuates it.


That is an implementation issue, not a framework issue.

There are plenty of easy to use virtual scrolling libraries for React and vanilla JS. There is also `content-visibility` with CSS Containment now.


I’d love to see how those new options perform these days by replicating a large tumblr blog or instagram feed. Might be a fun project.


>Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device.

that was the case in 2015 when entry level android devices were quite slow, nowdays a cheap $200 android phone has at least 4-6GB of RAM and an eight core processor.

if that isn't enough for your react powered site, you are doing something very wrong.


Multiple times daily I encounter sites that are brutally slow not just on my beefy Android phone, but on my 3GHz+ 8-core 64GB desktop machine.

You need to take performance seriously or it will just be bad. Most of the industry has chosen to be bad.


Well, tracking and advertisement will be doing it, not react.


Keep in mind that React is very single threaded (as is nearly everything in javascript). These phones might have 8 cores; but they tend to have the same single thread performance as 10+ year old iPhones.


That assumes that the bottleneck is JS parsing/execution. The browser itself is not single-threaded and can load/parse resources in parallel.

And I don't buy that most websites would have react as the bottleneck, over the million other js libs, ads and tracking.


No one is asking you to buy it, there is tons of empirical data you can analyze for yourself.


The performance of client-side web applications asymptotically approaches load times of "at most a few hundred milliseconds" on the high end phone models owned by developers.


React sites still feel janky on my 24cores and 48gigs or ram. Which is impressive for all the wrong reasons.


Which react sites? Are you sure you are not a victim of confirmation bias? How often do you check what framework does a smooth and performance website uses?

Because demo sites are snappy on even low-end devices. It's not react itself that causes slowness, but all the other libraries/tracking/ads.



Which (correctly) doesn't even have react listed, only frameworks that (may) use react as a library.

So at least be specific what is problematic, is it a particular framework, a particular library, the whole idea behind react (v=f(s)) or what? Anything can be proven against something non-concrete.


Yes.


I largely agree with your points, but wish it’d be easier to have server side rendering that’s not as tightly coupled to the rest of the system.

What almost always happens is that with a SPA the core business logic is more or less separate from the bits that are shown in the browser, so that if AngularJS gets deprecated you still have an API that you can use for your Vue/React/Angular rewrite.

However, if JSF becomes too much of a maintenance burden, the chances of me migrating to HTMX or a similar technology, even a full on SPA are pretty close to 0% when I have only a similar amount of time as in the case above.

Why? Because the previous implementation is going to be in the same codebase and like it or not, as more time passes and as more people work on the codebase, there will be coupling. Those technologies will intertwine to such a degree, that a clear cut replacement will be really difficult.

I guess what I’m pondering is why we don’t have an RPC/IPC component as a central part of Django, Rails, Laravel, JSF and all the others - so I could have server side rendering but separate repos (with separately managed dependencies) for the back end and the front end.

Maybe even deploy them as separate containers that talk to one another and have resources managed separately, so the old JSF permission check logic for rendering components in a deep tree cannot eat the CPU time that’s needed for some scheduled processes in the back end.


> I disagree. Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device. It can take multiple seconds before the page is fully loaded. Even once the libraries are loaded, React sites often involve parsing a giant lump of JSON before you can do anything, that’s particularly CPU intensive and takes time on low end devices.

Try doing it on a flagship handset like a Pixel 8 Pro, and it's still a slow and miserable experience.

m.facebook.com, as an example.


These disagreements almost always boil down to one side saying "some people use React to build content-oriented websites" and the other side saying "but most of us are building web applications".

In a typical web application use case (yes, there are exceptions) you're only rarely looking at usage from old or cheap Android devices. Occasionally you'll see a tablet, but even that's rare. The vast majority of the time your users are on either Chrome or Safari on a relatively modern Mac or Windows machine. In many cases the application loads once at the start of at least 10+ minutes of work, so initial load times rarely matter much.

If you're building a website that needs SEO, then yeah, React is completely the wrong tool, and you should just make a proper static site or hook your marketing team up with WordPress (or whatever takes its place once Matt is finished blowing it up). But those use cases, while common, represent a tiny fraction of total engineering effort across the industry, so most web developers here don't have the design constraints that make React a bad choice.


I would also add that even in that last scenario React can be a great tool, there are many solutions that use React but make fully static exports (Nextjs/astro/gatsby/etc).

Pre-rendering everything has downsides of course, but it doesn't get much faster than that.

I think it's also a misconception that there is such a clear divide between app and content-oriented websites. Even the most content heavy websites, news sites for example, are highly interactive these days. Show me a popular content heavy site that doesn't have some sort of log in, interactive content, comment section, filtering, live blogs, alerts, notifications, search, and similar.

You also have to take into account the advantages of pre-fetching links, and only fetching and replacing the content instead of doing full page re-renders. All of these great things you can do easily with React and a React framework of your choice. You can even go further and have a hybrid of statically exported pages, SSR, and some SPA like highly interactive parts, reusing the same exact components in all these strategies.

All to say: React can be a great choice for a lot of use cases, also for content heavy websites.


The top sites using react are all e-commerce or social sites. I would bet the majority of react sites and devs that use them are not building apps that require SPA or something like React. Which is the problem.


> I would bet the majority of react sites and devs that use them are [n]ot building apps that require SPA or something like React. [edited to restore what I assume is the ended meaning]

On what basis do you bet this, though?

Sure, you see sites that bug you by being slow in contexts where you'd choose something else, but most devs are working on sites and apps that you will never see, because you're not the target demographic.

I don't have survey data one way or the other, but anecdotally everywhere I've worked on an SPA has been a clear case where trying to do it in backend+JQuery would have been a huge failure.


But there is a wide gulf between backend + JQuery and SPA. The frustration often shown is people treating the extremes as the only options available. Having a use case for which backend + jQuery doesn't cut it doesn't require reinventing navigation state and history in JS, or loading every stat on the page via JSON. There are middle grounds.


What middle ground do you propose that's as efficient to get rolling as React in 2024? You talk about not reinventing state and history in JS, but at this point the reinvention is already done and React is the pragmatic choice that you pick when you don't want to reinvent the frontend.

There are a bunch of stacks that I prefer to work in for my own projects, but what I need at work is almost always the standard option that everyone is already used to.


Here is one middle ground https://hotwired.dev/


Reacting to assertions of broad averages with specific counter examples doesn't necessarily invalidate their point.


OK, let me restate something from my previous component explicitly: a site that’s concerned with SEO is not a “specialized domain”. It is very, very common.


So are web applications that are completely behind auth and never need to care about SEO.

They're quite different and it's a shame they're usually mixed up in these discussions.


Many sites have a two tier application with a CMS SEO “landing page” abd conversion funnel run by the marketing department and a user-login that takes you to a separate website that is SEO irrelevant.

So… a site that doesnt care about SEO and is not indexed and is purely for logged in users is also very common.


I don’t really understand the disagreement here. I didn’t claim those sites are rare. I was specifically refuting the OPs claim that page load time only matters in a small number of specialized domains. I am saying it is very common for it to matter. It’s also very common for it to not matter, you’ll get no argument from me there.


With React Server Components, you can have your cake and eat it too, by sending only the necessary HTML to the browser (thereby having good performance and SEO) but also hydrating with more interactivity if necessary. And I'm not sure where you think CSS in JS means you don't learn CSS, I'm not sure how you'd use it otherwise... Either way, there are CSS in JS (TypeScript) libraries that compile down to regular CSS classes, like PandaCSS, so again, you can have your cake and eat it too.


React Server Components strikes me as React solving a React-caused problem with yet more React. Which is fine, I guess, if you’re already locked into the React ecosystem. But as someone that isn’t, looking at the whole proposition from the outside, it just screams vendor lock-in to me. There are too many devs out there only expert in the way React does things and can’t step outside of it. RSC is an additional crutch that allows this to continue but that doesn’t mean it’s healthy.

My main contention with the OP’s point was the assertion that React is almost always the right answer. One of my biggest bugbears about any web dev discussion (particularly on HN) is that everyone treats it as a one size fits all argument and it isn’t.

If you’re making a webapp with interactivity levels like Gmail has then React is a sensible choice. The page reloads very irregularly. But if you’re making something like a blog with lots of drive by visits and only small islands of reactive content IMO it’s the wrong choice.


Perhaps it is vendor lock in, but the concept as a whole is not that difficult to generalize, as other frontend frameworks have their own sorts of implementations of the concept. Phoenix in the Elixir world has LiveView, for example. It's just that React's is more seamless, especially with TypeScript, as you can run JS (TypeScript) on both the client and server, so that you have greater control over exactly which components you want to be on the client versus the server without having to do so manually if you were to use something like Rails or Django. Therefore, even if you are making something like blogs, you can still use React as essentially a templating language via JSX and also use React for interactivity, for example a comment form component.


> React Server Components strikes me as React solving a React-caused problem with yet more React.

This is not the case. RSC solves the hydration problem, in which hydration is profoundly expensive (larger bundle sizes, more client JS to parse and execute, and slower time to interactive), when most of the UI on any website can be non-hydrated. This also gives you the ability to write server only code (which as it would turn out, reduces sending third party deps to the client even more) for free with beautiful composability to client side hydration when you need it.

Everyone hydrates at some point. Maybe you write isomorphic javascript or maybe you render a rails or python app and sprinkle in some JS. RSC enables you to do this with complete composition and re-usability.

I'll put my money where my mouth is: RSC will continue to grow in adoption and its patterns will be adopted across many UI frameworks and libraries. This wasn't a solution in search of a problem, this was a large step forward in giving us more optionality as to how we architect websites.

> There are too many devs out there only expert in the way React does things and can’t step outside of it.

This is a weird ad hominem, attacking developers' skill instead of the actual technology. There are millions upon millions of React developers, and many of us have been building successful software for a long time and step outside of React every day.

> But if you’re making something like a blog with lots of drive by visits and only small islands of reactive content IMO it’s the wrong choice.

For some use-cases it is not the best choice, and for others it's the correct one. No one is hailing React as a one-size-fits-all solution, rather it remains a great balance that scales remarkably well to many needs.


> Maybe you write isomorphic javascript

I’m surprised to see people still misusing the word isomorphic.


it's been a term of art for a long time


That's technically true. Indeed, "isomorphism" has been a term of art for about 200 years.

More recently though — over the past decade or so — JavaScript enthusiasts have been using this word to describe code sharing, which isn't quite right.


It's been used to describe code that does A on server and B on client side, where A and B are deeply related but definitely not the same. It's not just code sharing, that's just a small part of it.


My argument is that it's a forced and silly misuse of the word.

I'm struggling to understand also how it came to be [ab]used in this context. To take an old Greek mathematics word and use it to mean something that it doesn't really mean? Why? Isn't that silly? Isn't it pretentious?


Yeah, that's why everyone switched to "universal" after a year or two. But some people are not as up to date and some libraries kept their old names.


I wasn't aware that the favoured term had changed. I do think universal is clearer and much less silly.


The original problem was caused by PHP (see XHP) and this is just bringing the solution to full feature parity.


You literally cannot. You can bake two cakes. You can’t have your cake and eat it too.

Server and client rendering? You must concern yourself with both. The best frameworks will not perfect abstract this for you. They can’t, it’s leaky. When the cracks show, it will be painful.

CSS-in-JS? I’ve used it and fought for it. Have you ever looked at the css output? That’s not a cake I’d want to eat. Compare it to a codebase with a well architected set of css and the markup and css actually do work for you. They are clarifying and reinforce structure. There are levels of productivity you gain based solely on things being clear and not convoluted that many people in our industry cannot recognize because they are fixated on the wrong thing. Whether that be what other people are using, or what gives dopamine hits (hot reloading, cool tech, etc)


One of the ways you know a project is going wrong is when it's using JS to do things that HTML and CSS should be doing.


> You literally cannot. You can bake two cakes. You can’t have your cake and eat it too.

It is a common saying, not to be taken "literally."

> The best frameworks will not perfect abstract this for you. They can’t, it’s leaky. When the cracks show, it will be painful.

Better than before with pure server side solutions like Rails or Django, however. I use RSCs and they work just fine, because you are using TypeScript on both the client and the server, meaning there are greater abstractions that can be leveraged.

> Have you ever looked at the css output?

Not sure what CSS in JS library you used but with something like Typestyle or PandaCSS, you write CSS but in JS objects, so the generated CSS is simply turning those objects into the CSS you already wrote, not sure why it would be any different.


I know what analogies are. I was extending yours. I was just saying that there are tradeoffs. You don’t think there are, and that’s fine. I can see them and I make my choices accordingly.


I never said there weren't tradeoffs, just that RSCs enable greater functionality than before, such that one can "have their cake and eat it too," but it's not meant to mean that there are only two cakes in this entire analogical universe. Other frameworks (ie, cakes) have their own tradeoffs.


Ironically the first question you ask is the question people should be asking about React. Specifically, what problem does it solve, and do I have that problem? The problem most teams tend to face, and I believe part of the authors argument is that people reach for React out of an almost superstitious or orthodoxy-based belief.

Likely many developers don’t even know how to build something without React. They don’t know the first thing about html, server-side rendering, progressive enhancement or any of the things we used to use to build forms over data applications before React came along and its siren song drew away many developers, and, worse, created an entire generation that fits the criteria I’m describing.

The author doesn’t need to describe an alternative any more than he did, because the alternative is supposed to be self-evident. If it’s not, the person is supposed to take the plethora of breadcrumbs in the article and figure out how we used to do things before bloated, convoluted, and typically unnecessary frameworks.

When you look at something like Remix and Next you see people trying go back to the simple (forms, server rendering) by adding additional complexity. It’s doubling down on complexity, rather than finding simplicity.


> Specifically, what problem does it solve, and do I have that problem? The problem most teams tend to face, and I believe part of the authors argument is that people reach for React out of an almost superstitious or orthodoxy-based belief.

The problem is building a front-end UI with compositional components (essentially the only way to build anything substantial), with sane handling of state, and with acceptable performance for interactive use (which means not round-tripping to the server every time, sadly, otherwise I'd keep using Wicket). Almost everyone doing front-end work has that problem, which is why React is a good "best practice". It's rightly the orthodoxy.

> They don’t know the first thing about html, server-side rendering, progressive enhancement or any of the things we used to use to build forms over data applications before React came along

Which is smart of them. That stuff is an overcomplicated waste of time. I mean, occasionally you need to debug some HTML, just as occasionally you need to read the disassembly of a binary, but most of the time there are more valuable things to learn.


> The problem is building a front-end UI with compositional components (essentially the only way to build anything substantial)

Server-rendered front end frameworks (like Rails) have units of composition as well (partials, helpers).

> with sane handling of state, and with acceptable performance for interactive use (which means not round-tripping to the server every time, sadly, otherwise I'd keep using Wicket)

What "state" one needs to handle is app dependent. Some do need client-side interactivity and some don't. Obviously, if you need it, you need it. Saying "almost everyone doing front-end work has that problem" is something you'd have a hard time proving. Historically, most things people have built on the web have had relatively low levels of interactivity. There are brochure sites (read-only) and there are forms-over-data (read, with data entry) that both lend themselves well to a server-rendered approach. There are even more interactive applications like hey.com (a full-on email client) that is server rendered.

My team maintains 30 or so Rails applications complete with collaborative two-way sync form entry and real-time (enough) commenting with server rendering and Rails. The first app we built used React. I can tell you with absolute certainty (because I've done it) that the React version is still more expensive to maintain, still the place that the devs prefer to work the least, still the most expensive to extend.

> Which is smart of them. That stuff is an overcomplicated waste of time. I mean, occasionally you need to debug some HTML, just as occasionally you need to read the disassembly of a binary, but most of the time there are more valuable things to learn.

Are you trolling? The things I listed are "over-complicated"? HTML is what React renders. You need to write something like it when you write your JSX. Sorry, you gotta know that. Server-side rendering is necessary if you want anything resembling reasonable time-to-interactive or SEO. Progressive enhancement is something every web developer has to at least be aware of when it comes to CSS.

And, "debug some HTML"?


> What "state" one needs to handle is app dependent. Some do need client-side interactivity and some don't. Obviously, if you need it, you need it. Saying "almost everyone doing front-end work has that problem" is something you'd have a hard time proving. Historically, most things people have built on the web have had relatively low levels of interactivity. There are brochure sites (read-only) and there are forms-over-data (read, with data entry) that both lend themselves well to a server-rendered approach.

As soon as you have any kind of interactive UI, either you do sever roundtrips for everything (which is usually unacceptably slow) or you have client-side state. Tabbed form section? State. Two-level dropdown? State. Radio button enabling different parts of your form? State.

Theoretically it's conceivable that someone might have a website that needed only flat forms with zero dynamism. But I've found that everyone thinks their website is like that, and they're always wrong. Every Rails/Django/Wicket/etc. site ends up needing one little piece of unmanaged JavaScript somewhere (unless you're lucky enough for a server roundtrip to be acceptable latency-wise). And then one more piece. And then you have a state management problem.

> My team maintains 30 or so Rails applications complete with collaborative two-way sync form entry and real-time (enough) commenting with server rendering and Rails. The first app we built used React. I can tell you with absolute certainty (because I've done it) that the React version is still more expensive to maintain, still the place that the devs prefer to work the least, still the most expensive to extend.

You must see that your experience is unusual - perhaps you're using React badly (understandable in a first app), or your team has spent more learning time on Rails. There are scenarios where Rails might beat React on a level playing field, but this shouldn't be one of them. Apart from anything else, how do you do handle the client-side state in the Rails case?

> HTML is what React renders. You need to write something like it when you write your JSX.

Right, just as your Ruby runs via a C interpreter that ultimately executes as machine code, is the analogy I was drawing. Having a bit of familiarity with C and your processor's assembly might be helpful for some kinds of debugging occasionally, but it probably shouldn't be a priority.

> Server-side rendering is necessary if you want anything resembling reasonable time-to-interactive

I assure you it isn't. In some use scenarios it might be, but I've worked on sites that were very fast without it.

> or SEO.

Perhaps - but not everyone needs SEO.

> Progressive enhancement is something every web developer has to at least be aware of when it comes to CSS.

It really isn't these days. Even a very inclusive baseline of browser support still gives you plenty to work with - e.g. flexbox is 12 years old at this point. It's entirely practical to set a reasonable baseline and just not do progressive enhancement (particularly since often the "worst" browser you're targeting - iOS Safari - is also the one that most of your customer base by value uses, so there's little to gain from progressive enhancement).


> As soon as you have any kind of interactive UI, either you do sever roundtrips for everything (which is usually unacceptably slow) or you have client-side state. Tabbed form section? State. Two-level dropdown? State. Radio button enabling different parts of your form? State.

Yep, we have all this. Server round-trip is acceptably fast. Perhaps we are lucky because most users are in the US.

The interesting question here is, what is unacceptably slow? Why is it slow? If you really don't need any new data from the server, i.e., you are just hiding or showing something, you can use JavaScript. But I'm just here to say that it's more than possible to be "fast enough" for a forms-over-data application. Usually when developers tell me (and yes I'm a developer) that something is not fast enough it's because it's "human perceptible". That may be the measure for certain applications, but more often than not, it's a developer that's fixated on the wrong thing. They only see that, and they don't see the long-term productivity cost of using a SPA framework. You may tell me it's not there, but it is.

> You must see that your experience is unusual - perhaps you're using React badly (understandable in a first app), or your team has spent more learning time on Rails. There are scenarios where Rails might beat React on a level playing field, but this shouldn't be one of them.

It wasn't our first app. We're actually very well versed in it. I just looked it up and the first app I worked on w/ React was in 2014. I worked in it exclusively for 7 years or so before making what I thought at the time was a the very risky switch, mid-stream with my current client to server rendering. Almost the whole team knew React better. Using Rails wasn't just a little bit more productive, or a little better, it was night and day.

> Apart from anything else, how do you do handle the client-side state in the Rails case?

There's almost none. Some I can think of are persistent scroll (in a navigation panel or comments feed that persists through page navigation) and persistent comment drafts. Persistent scroll is about 100 line stimulus controller that stores the scroll position in session storage. Comment draft is also in about 100 line stimulus controller (only about 50 lines or so are concerned with it). It's all very simple. Event hook, write to session storage. On load, read from session storage.

For everything else, it's a server round trip.

Have you used hey.com? It's an email client built with server rendered rails. From what you describe, this should be impossible. Yet, it's not.

> Right, just as your Ruby runs via a C interpreter that ultimately executes as machine code, is the analogy I was drawing. Having a bit of familiarity with C and your processor's assembly might be helpful for some kinds of debugging occasionally, but it probably shouldn't be a priority.

It's a flippant analogy here because you can't get away from the HTML. Sure, if you never look at the dev tools, or you always use the React dev tools, you always see your HTML wrapped in React components, but uhm, it's HTML wrapped in React components. You don't write assembly and give it a C function header. Yes, I recognize JSX isn't HTML, className made very sure of that. But... it's practically HTML in terms of what you need to know to use it. Oh, just remember to layer on the additional cognitive load that some attributes are slightly different.

> I assure you it isn't. In some use scenarios it might be, but I've worked on sites that were very fast without it.

Anything is possible. We would have to define fast, however. I mentioned TTI. The article you are posting comments about has a whole table dedicated to how even with server rendering and React most apps fail to achieve good performance numbers. Furthermore, in order to get reasonable TTI, you either need a small app, or you need bundling, code splitting, tree shaking, all additional complexity. Look -- I rode the Babel (né 6to5), webpack, to esbuild, to vite, to whatever else wave. I was the guy that built the webpack configs for my teams and handled all the upgrades. I actually KNOW the cost.

> It really isn't these days.

Ok. Keep in mind it's always changing. Container queries? Clamp? Various things over the years have been useful to be able to use and worth doing progressively. I agree though that the gap is reducing. We hardly do any progressive enhancement. We are also not targeting markets that would benefit from it. We can luckily mandate an evergreen browser because of who our users are. Not everyone is in that situation.


> The interesting question here is, what is unacceptably slow? Why is it slow? If you really don't need any new data from the server, i.e., you are just hiding or showing something, you can use JavaScript. But I'm just here to say that it's more than possible to be "fast enough" for a forms-over-data application. Usually when developers tell me (and yes I'm a developer) that something is not fast enough it's because it's "human perceptible". That may be the measure for certain applications, but more often than not, it's a developer that's fixated on the wrong thing.

If you're making something users don't have much choice about using - either an internal business app (the article has a box about those), or a professional tool that adds major capabilities - then you can get away with it, just as you can get away with quite bad UI in general. But if you're making something that has to appeal to users, perceptible and even imperceptible latency when they click drives them away. I'm not claiming it's rational, but developers "fixate" on it because it matters to users; I wish I could just keep writing Wicket, but I can't argue with the numbers or even just my own experience of what using these UIs feels like.

> they don't see the long-term productivity cost of using a SPA framework. You may tell me it's not there, but it is.

Why though? Like, there might be specific things React does wrong (and I know that Rails is very productive for some people, much as I hate it), but there's nothing fundamental about using an SPA framework rather than a server-side framework that should make it less productive. If I want a form with 2 dropdowns and 3 text fields, that's the same question in either context, and should take the same amount of code to answer.

> There's almost none. Some I can think of are persistent scroll (in a navigation panel or comments feed that persists through page navigation) and persistent comment drafts. Persistent scroll is about 100 line stimulus controller that stores the scroll position in session storage. Comment draft is also in about 100 line stimulus controller (only about 50 lines or so are concerned with it). It's all very simple.

Fair enough - you made it sound like there was a lot of client-server state that was relevant. If you haven't got state that affects the UI, maybe you're the unicorn. I've found that websites always need that kind of thing (tabs, radios, nested dropdowns) and once you have something like that you either have the state only on the server and the latency is high enough to bother users, you have state on the client in an unmanaged way and get horrible glitches when the server and client disagree (e.g. client is on one tab of the form but server thinks it's on another tab), or you have state on the client in a managed way and use an SPA framework (or something indistinguishable from one).

> Have you used hey.com? It's an email client built with server rendered rails. From what you describe, this should be impossible.

No, but I've used similar systems. Yes you can make them. Yes they feel fast enough, if you haven't used the alternative (especially if you happen to be located close to the server). But they're clunky enough that they can't succeed in the market.

> Yes, I recognize JSX isn't HTML, className made very sure of that. But... it's practically HTML in terms of what you need to know to use it. Oh, just remember to layer on the additional cognitive load that some attributes are slightly different.

The edge cases are what take the time when learning though. Like, yes, you probably do need to be able to read HTML-like syntax without getting confused. But you don't need to know the list of tags or attributes or the escaping rules or the rules about which tags are self-closing and which aren't or ... . You just use React components and follow their documentation.

> The article you are posting comments about has a whole table dedicated to how even with server rendering and React most apps fail to achieve good performance numbers.

Most apps full stop fail to achieve good performance numbers. It always takes effort. I suspect the average React app probably is slower, partly because React sites are generally newer and mostly because React lowers the bar for developer quality needed to get anything to work at all, but that doesn't mean there's a problem with the tool.

> you need bundling, code splitting, tree shaking, all additional complexity. Look -- I rode the Babel (né 6to5), webpack, to esbuild, to vite, to whatever else wave. I was the guy that built the webpack configs for my teams and handled all the upgrades. I actually KNOW the cost.

It's O(1) work though, or very close to it. I was the guy that used the existing build that someone else had come up with before I started working on that codebase. It continued to work, and be fast - I think maybe one time in a couple of years we got alerted that we'd done something that messed up the code splitting and we fixed it. Maybe it is complexity, but it's not complexity that imposes any real overhead in actual day-to-day development.


> but developers "fixate" on it because it matters to users

Then it's not a fixation. If, for your application, the difference between a 1-50ms interaction and a 150-400ms interaction matters, then you have reason to for that interaction optimize the performance. If your entire app is like that, then you're probably a particular type of app (superhuman, miro, linear, etc.). Don't get me wrong, I pay for superhuman because it feels like a native app and gets many things right. I would not pay for hey.com. But hey.com is actually relatively successful out there despite its sometimes-perceptible latency. Oh, and superhuman has perceptible latency too. Any time something needs to come from the server it takes that round trip time regardless whether or not that thing is JSON or HTML. The delta between those two is pretty small now-a-days, and typically not perceivable.

> If you haven't got state that affects the UI, maybe you're the unicorn. I've found that websites always need that kind of thing (tabs, radios, nested dropdowns) and once you have something like that you either have the state only on the server and the latency is high enough to bother users

I mean, we do. Our forms are pretty sophisticated. Things add/remove show/hide, and they update live as others make changes. The state just doesn't need to be on the client. You say maybe we're a unicorn, I say maybe people should consider whether or not they are a unicorn too, and maybe those unicorns are just horses developers think are unicorns. They may just be a lot more common than you (and others) think. We all like to think that latency matters to our app because we all read that article saying that Xms in latency cost $Y, but none of us stopped to ask if that article was about our app.

> But you don't need to know the list of tags or attributes or the escaping rules or the rules about which tags are self-closing and which aren't or ... . You just use React components and follow their documentation.

I'm not sure how to say this... but literally none of this is typically significant and certainly not any more significant than it is in React. In React you still need to know the tags and the attributes. Escaping rules? Yea, you need to know those too -- just the JavaScript ones. Self-closing tags? Just don't use them, or do if you know them, or use something like HAML/Slim/any other templating language to do away with those nuances. I'm not sure that arguing that HTML is hard to learn is a very effective platform. It's the thing that grade school kids learn to make web pages. Sure, there's edge cases, and understanding semantics is hard, but you don't need any of that.

> I suspect the average React app probably is slower, partly because React sites are generally newer...

This isn't why. It's because it requires a significant amount of JavaScript to load and evaluate before you see anything. That amount can get larger with time.

> It's O(1) work though, or very close to it. I was the guy that used the existing build that someone else had come up with before I started working on that codebase...

Right. That stuff is O(1)-ish, and maybe it's stabilized some, but having gone through the various transitions, I can say it's not free. Nothing is though, upgrading Rails took us a couple hours this time around because of a breaking change for our 30 apps. React comes with, as a baseline, significant complexity that is O(n): Client/server separation (APIs or phantom-APIs like Next.JS has), state entangled with presentation (See the whole smart vs dumb components for an attempt to address this), massive asynchronous concerns that cannot be fully abstracted away (suspense and the like), and probably more.

Folks can't see it until they step away from it and look back. I've done that for the last 3 years. Unless a person has done it, I wouldn't expect my arguments to land. Folks see things or they don't. Again, I'm only here to say: there's something to see that you may not see yet. I'm sorry I don't have anything more convincing.


> If, for your application, the difference between a 1-50ms interaction and a 150-400ms interaction matters, then you have reason to for that interaction optimize the performance. If your entire app is like that, then you're probably a particular type of app (superhuman, miro, linear, etc.).

> We all like to think that latency matters to our app because we all read that article saying that Xms in latency cost $Y, but none of us stopped to ask if that article was about our app.

Disagree, I've found that even if the page is, like, tax forms, latency changes the feel of it and affects how the user feels about your site, even if they wouldn't consciously say anything about the speed. I used to be similarly sceptical about a lot of design work - I felt like designers were just messing with the visuals for no reason - but once I'd seen the before-and-after with a good designer I realised how much difference it makes.

> Any time something needs to come from the server it takes that round trip time regardless whether or not that thing is JSON or HTML.

Sure. So e.g. one thing that shocked me is how important it is to have a loading state for your form submit buttons, even though it only shows for a couple of hundred milliseconds and you'd think it wouldn't matter. But it does, and that's the sort of thing that React-based UIs tend to nudge you towards doing by default, whereas with server-side rendering often it's a bit more of an extra step.

(A server-side rendering framework will probably have a nice loading state for basic happy path form submit buttons where they've put time and effort into polishing. But it will be ad-hoc rather than idiomatic, because that kind of detailed client-side state is fundamentally cutting against the grain of a server-side framework. Once you go slightly off the beaten path, into image buttons or custom button components or what have you, it becomes harder and harder).

> Escaping rules? Yea, you need to know those too -- just the JavaScript ones.

You always need to know the JavaScript ones. So the choice is between learning the JavaScript ones or learning the JavaScript ones plus some other ones as well.

> Just don't use them, or do if you know them, or use something like HAML/Slim/any other templating language to do away with those nuances.

Then you've got another language with its own syntax that you're learning. Writing everything in the same language really does help (admittedly I don't know how many other people stay away from JSX and do everything programmatically, but doing React and never writing HTML is a genuine option, easier than doing e.g. Rails and never writing JavaScript IME).

> I'm not sure that arguing that HTML is hard to learn is a very effective platform. It's the thing that grade school kids learn to make web pages. Sure, there's edge cases, and understanding semantics is hard, but you don't need any of that.

Well, we started this conversation with you complaining about React devs who "don't know the first thing about html". I don't know how literally you meant that, but my position is that learning just enough to get by is just fine, and putting more time into studying the intricacies of HTML does not generally have a good return these days. To the extent that React (or Rails, or anything) allows you to dodge learning those details, I consider that a point in its favour rather than against.

> it requires a significant amount of JavaScript to load and evaluate before you see anything.

It doesn't though. Like, I don't know how much effort it took to get the right build config etc. to make it work in my case, but it absolutely can be very fast. I'm happy to believe it's easy to make a React site that's slow, but it certainly doesn't require any superhuman effort to make one that's fast. I genuinely don't know what you have to do differently, because it didn't feel like I was doing anything special.

(At a guess I'd say committing full-throatedly to React and doing everything their way, rather than trying to half-ass things with useEffect etc. - just because that's the main thing we possibly did differently from "usual", and because most of the people who have a bad time with React seem to be the people who don't want to dive all the way in - but that really is just a guess)


> I've found that even if the page is, like, tax forms, latency changes the feel of it and affects how the user feels about your site, even if they wouldn't consciously say anything about the speed.

I agree with this, but probably wouldn't about specific numbers or use cases. By the way, one of the forms on our app round trips in 75ms when selecting a radio button that controls which set of fields is visible below it. On the "Slow 4G" throttling setting in Chrome, the time increases to 620ms or so, which is noticeable enough for the interaction to not feel good. Our particular forms-over-data application is not typically used on mobile (there's too much data to enter), so this isn't an issue for us. It's all contextual. If it were an issue, we'd either use an SPA-like library for our forms, or we would send all the HTML to the client and use JavaScript rules to control visibility. It's one part of our app. We wouldn't let that singular use-case dictate our entire stack.

> A server-side rendering framework will probably have a nice loading state... Once you go slightly off the beaten path... it becomes harder and harder

Indeed, this is effectively built in to Turbo. There's nothing special about it, you add CSS rules (turbo adds and removes classes). That'd apply to image buttons or anything else you want to throw at it. You're making assertions here about it getting more challenging, but I can't tell if that's from personal experience or if it's hypothesis.

If a person started their career doing React and is still doing React, that person would have certain beliefs about things that wouldn't be true. I get the impression that most people I'm engaging with here haven't actually done what we're doing but they are somehow convinced it cannot work or that our use case (line of business forms over data) is so special that it can't possibly apply to anyone else.

> Then you've got another language with its own syntax that you're learning

Yes, HAML is a new language. Our designers can work with it. It's not much more complicated than, say, markdown. Learning new things is what we do, every day. There are certain developers that prefer to hone their skills in the one thing they know how to do. They're the ones that put "React Developer" in their twitter or LinkedIn profile. That's fine. That's a career path. I don't work with those people by choice.

> Well, we started this conversation with you complaining about React devs who "don't know the first thing about html". I don't know how literally you meant that...

Got it. It was somewhat flippant, I admit that. They probably know the first thing, but the concerns you're raising about tags and escaping and that sort of thing honestly somewhat reinforce my flippant assertion. If those are the things we are concerned about our developers having to know then I wouldn't want them anywhere near anything our users would touch. I think we may be used to working with different calibers of developers. I get that they're all over the map now, so this is just a another contextual difference most likely.

> ...studying the intricacies of HTML...

It's not sanskrit. I'm rather confounded by the FUD around HTML here.

> It doesn't though.

Ok. I've done it, so I know exactly what it takes, at least in the 4 or 5 different apps I built with various versions of React and friends. I also know that aside from the fastest machines on the fastest networks, there's not much you can do aside from server rendering to address the first paint issue/LCP issue. But yes, once you have the initial JS bundle, the rest of the site is generally faster. By the way, one of our 30 or so web apps we have composed into a single application with nginx/SSI still uses React. LCP is 1.2s on my M4 Max and on a page with slightly more data that doesn't have React, the LCP is 0.7s. Yes, the bundle is optimized. These aren't awful numbers at all, but I'm on the fastest machine there is pretty much. There's no loading shimmer stuff like AirBNB does. Speaking of user experience, that stuff is absolute garbage and I can't wait until folks realize it. Of course, they'd have to embrace server-side rendering though... :)

Just to be reiterate: I think there are plenty of good use cases for React like libraries/frameworks. I just think there are fewer than people think.


> It's one part of our app. We wouldn't let that singular use-case dictate our entire stack.

Well sure, but in that case it's no longer "it's solving a problem we don't have". It's solving a problem that may be low on your priority list, that you maybe choose to tolerate, or solve in a more cumbersome way, but it's still an undeniable pain point.

And if you flip the question, I just haven't seen the compelling case for server side rendering. If you have a specific case where something else does something you can't do with React, or does something a lot better than React, then of course do that something else, and if that something else happens to use server-side rendering then maybe it will be a tolerable tradeoff. But I honestly think that if React or similar had come first, we'd never have invented server-side frameworks as we know them (which is not to say that we wouldn't have e.g. a Ruby based convention-over-configuration framework - but I think it would have a state model closer to React's).

> You're making assertions here about it getting more challenging, but I can't tell if that's from personal experience or if it's hypothesis.

It's personal experience, but perhaps outdated, and I never was hugely into Rails specifically. The last time I checked in was several years into wailing and gnashing teeth about people fleeing to React, but only really offering a smattering of ad-hoc fixes to specific pain points. Maybe they've found themselves a good unified state abstraction now, but I think it would be a real struggle especially for a framework that isn't really component-oriented in the way I see it (and indeed prides itself on embracing HTTP and having routes corresponding to pages).

> Yes, HAML is a new language. Our designers can work with it. It's not much more complicated than, say, markdown. Learning new things is what we do, every day. There are certain developers that prefer to hone their skills in the one thing they know how to do. They're the ones that put "React Developer" in their twitter or LinkedIn profile. That's fine. That's a career path. I don't work with those people by choice.

I used to pride myself on knowing dozens of languages, but I've come to see much of that as superficial and pointless. Learning new things that expand the way you think is worthwhile. Learning new tools that you can apply generally is too. Learning yet another slightly different templating syntax or curly brace programming language usually isn't. And some tools have enough depth to them that you can spend years and still learn new, useful things. I don't know that React is one of them - I don't know it as well as I'd like - but these days I generally find it more rewarding to learn a deeper corner of something that I can use a lot, than a new standalone thing that doesn't have any general lessons to impart.


> Well sure, but in that case it's no longer "it's solving a problem we don't have". It's solving a problem that may be low on your priority list, that you maybe choose to tolerate, or solve in a more cumbersome way, but it's still an undeniable pain point.

Yes, in that case, i.e., if it were a problem we had. It's NOT a problem we have though. That's my point. Not currently. Not in our context.

> But I honestly think that if React or similar had come first, we'd never have invented server-side frameworks as we know them

Not exactly React, but there was ActiveX, Flash, and Java Applets. Thick clients came first. It wasn't until IE6 where there some AJAX was viable. React came later to address additional shortcomings: procedurally updating the state of the document via jquery got complicated, and large organizations with poor development practices (e.g., facebook) struggled to maintain control of their application. They came up with React to help with this, and it did, but it brought its own host of problems. Declarative UI was what we always had with server rendering. They just allowed it to update. Btw, this isn't a new idea. We had something like this with ASP.NET as well, but that included the server.

Meanwhile, people like Chris McCord had already built a syncing library for Rails to solve these problems and, being fed up with the performance at that point, went to Elixir where he eventually built Phoenix LiveView. By then, React already had significant market share. Turbo's previous incarnation came out before then and its current one came out around that time or slightly after. Combined with Ruby's performance improvements over time, it was quite viable for many apps.

Also, note what's happening in React -- it's moving towards more server rendering. People realized they lost something by doing client only and they're trying to get back to it. Remix is an ode to the simplicity of old (which is really the simplicity of now, but they don't want to give up their React Components). I can't blame them in a way, React is a lot of fun to write a lot of the times.

> Maybe they've found themselves a good unified state abstraction now...

We've always had the database. That's insufficient for highly interactive applications where you need client-side state, which is likely what you mean by "unified". So yes, if you need "unified" state, and specifically the ability to change your UI based on changes to that state, React is great, or any of the other libs. The author was specifically concerned about React's current state (e.g. legacy IE6 support) and I'm specifically concerned about people reaching for React when they don't need it. That's because I've done it, I've seen people do it, and I see people continuing to preach the React orthodoxy which will lead to more people doing it. This thread is full of it.

Whether or not a person recognizes it, HTMX, Turbo, LiveView and its kind have greatly narrowed that gap. They've made server rendering just as capable at highly-interactive UIs in many more cases than many people think.

> I used to pride myself on knowing dozens of languages, but I've come to see much of that as superficial and pointless.

Sure, I can relate to this. But this is different than spreading FUD about having to learn a new language. That's easy. That's the easiest thing we have to do. I'm not suggesting to do it flippantly. I'm suggesting that sometimes it's worth it. When it's worth it, you do it and it's not a big deal.


Not really surprising that a rails shop is going to have a easier time with rails than react.


Not a Rails shop. We did React and Node almost exclusively for 6 or more years. My first React project started in 2014 or so. I mentioned this in several comments. We had done Rails in the distant past, but using Rails was actually a risk for us because there were things we knew how to do with React from recent experience we would have to learn for Rails server rendering.


Meh. What is that self-evident alternative supposed to be? I ask as someone who crafted HTML with my father's lisp parens on computers running linux kernels which were still delivered with the pl suffix, and as someone who occasionally still occasionally tries to deliver frontend code, much to my dismay.

I've made websites in so many stacks and varieties that it would be intensely boring to list or read them, and I have NO IDEA what he thinks is better, or even if he is able to disambiguate the React architecture from the React library/stack, or which one he is talking about.

It's a tome, a full tome, without a clear position.

Mine is this: a truly state based rendering and eventing engine for frontends is a dream, a beautiful dream, not unlike the beautiful dream of a purely functional language based on the lambda (or rho?) calculus. The dream giveth and it taketh away, and it is always a fundamentalist dream; where that fundamentalism hits the cracks of reality is where engineers have to make tradeoffs.

The React architecture stack (well, the stack without prop drilling) stays somewhat beautiful as a dream in my opinion, which is to say it provides guide- and guard-rails to stay relatively productive delivering mid size applications across millions of devices without a ton of moments where I'm like "what the fuck is the rule of hooks, and how did I break it here?"

The react library stack, and by extension the node stack: sucks balls, full stop. I'm happy to get some other framework which has write/compile-time type safety, modularity and an eventing/rendering system that abstracts away most of my concerns for delivering over the web and is lighter weight, has less dependencies, etc. However, if the author wants me to change my ill-begotten ways, it would probably be more effective to explain how it is that each of the items in his list: "Preact, Stencil, Svelte, Lit, FAST, Qwik, or any of a dozen faster, smaller, reactive client-side systems" provide a better world.

In this area, I believe I'm a journeyman, reading a senior / master engineer's writing -- fine. But he is not informing me at all. I don't want to go learn the recommended 18 (12 unnamed) smaller client-side systems that apparently require less mental bookkeeping of me. I'm not even sure what that means -- I code tsx in vim, and do not feel like I have to do a lot of bookkeeping.

So, back to you -- what's your recommendation? I'm genuinely curious what you think would be better. Or the author, if he wants to butt in here. I just don't understand what you (or the author) thinks should be done. The forms processing and server rendering (say with Perl 5 and tcl were two early langauges for me) were not that great.


Same here. I’ve been through old and new frameworks on both client and server end, since before javascript was even on the map, from cgi, php, aspnet, django, angular, vue, lit, jquery, you name it.

Basically, I know how to build a server side rendered application, I still reach for React, I know it sucks in so many ways, accessibility, performance, complexity, and so on. I just don’t know what to pick instead. It’s the first time a framework allows seamless refactoring into composable components. Powerful, terse and type safe templating language. Clear separation between state and presentation. The developer experience is just easier, even accounting for the additional rpc needed between client and server and the hook footguns.

Do I wish there was a better way to do server side rendering. Of course. For server side rendering to take off, the story for how to gradually add interaction need to be better. Not everything is static text. The moment you need something interactive, even the most fundamental thing: date picker, form validation, expand/collpase, selection, reordering, lazy loading... sprinkling in a bit of js in a server side language become an unmanageable mess. Trust me, I’ve done it with jquery, it can get the job done but it will be a compromise, nowhere near the ease and accuracy that react gives.


I hear you. I reached for React for 6 year or so. I built the first application for the client I've been working for for the last 4 years with React. We built the next 20+ w/ server rendered Rails. The interactivity was the same. It's forms-over-data, but the forms have a relatively unique collaborative nature -- you and others can be editing them simultaneously and you'll see each other's field changes in (relatively) real time. The forms can also be massive and have fully dynamic sections. We did it with React (using react-query) and then did it again with Rails, turbo, and stimulus.

The JavaScript code that manages the collaborative form I mentioned is around 300 lines. Every new form we build is just Rails partials with helpers. No APIs, all server-rendered. It works very well. It loads faster than the React version and it has observably less maintenance cost.

> For server side rendering to take off...

> date picker

A reasonable one is built into most browsers now. You don't tend to anything more unless you need something specialized, and then there are libraries you can use (or you could reach for vue/preact/etc w/ the so called "islands" technique)

> form validation

On the server with Turbo/LiveWire/HTMX

> expand/collpase

This can be done with just CSS and a hidden checkmark. The JavaScript version is lines of code.

> selection

Not sure what this means

> reordering

There are libraries for this. By the way, I built a Trello plugin that effectively re-implements Trello within Trello including drag-and-drop reordering and I used Preact and one of the React DND style libraries (don't recall which now). There was nothing easy about it, but it was likely easier for my specific use case to use those technologies. That's one feature in most apps though (for us it was basically the whole thing), so if I needed it in this app, even if I reached for React/Preact, it would be isolated to that one feature. I'd try very hard to avoid it though.

> lazy loading

Turbo/HTMX make this trivial. Note that we use SSI (server-side-include) to compose web applications. This is all done on the server. Our apps are fast enough that we don't need lazy loading to maintain a very low response time even when hitting multiple servers in a request.

> Trust me, I’ve done it with jquery, it can get the job done but it will be a compromise, nowhere near the ease and accuracy that react gives.

So have I. Then I did it with React for over 6 years (including the transition to and from Redux and to hooks). I championed React and CSS-in-JS at my agency. Now I've done it with server-rendering again and different front end libraries (turbo/stimulus) for 3 years most recently. The difference is night and day. I have 15 other devs on my team that would tell you which stack they are observably more productive with. I'm just some guy on the internet, so take everything I say with a grain of salt, but I am uniquely positioned to be able to speak on this with practical experience on all 3 topics in this discussion (how server rendering was, how React is, and how server rendering is now).

Honestly, much of it comes down to what we let our "designers" force us into. If it's just the type of things that you described, it's server rendering all day. If it's random/unnecessary interaction/fluff/flare, the appropriate countermeasure is saying "no". Again, if it's Miro, Linear, Superhuman, etc, then sure -- reach for a full-fledged SPA framework/library.


I really appreciate this comment. You've very eloquently put into words how I feel about React and the ecosystem, and also my exhaustion towards these "anti-React" posts, which stoke an angry mob without offering obvious alternatives.

And I think the crux of the problem is that there is no obvious alternative. That isn't to say it can't, or shouldn't exist. I'm not a React loyalist. I was a working frontend developer when React came out and I remember how it took the web community by storm, because it was an obvious step forward.

When the alternative exists, it will be as purely obvious.


To be fair, 4 years ago I would have too. The cracks started to show with Phoenix LiveView and turbo and I took a leap of faith on the alternative I describe in my other comments. I haven’t looked back.

I’m not sure I would rely on obviousness. Things are only obvious to the late majority after the innovators and early adopters have moved on. The thing to pay attention to is when people who have extensive experience doing the exact thing you are doing say there’s another way.

The really tricky part here is that that “other way” in this case looks similar to the “old way” and thus is easy to dismiss. It also doesn’t come with any of the dopamine inducing things like hot reloading and really cool tech like virtual dom diffing, etc. in other words, it doesn’t speak to the parts of us that are drawn to the “cool” factor. It’s simple, it’s basic, it’s sometimes tedious, but it’s productive — in the long run.


I can't speak for other people; I can only speak for myself. I was an early adopter of React (around 0.12) and wasn't particularly interested in, or technical enough, to understand the "cool" things. I wasn't swayed by "hot reloading" or "virtual dom diffing" -- I didn't have a build setup that could hot reload, and I also did not even understand what the virtual dom was. But when I looked at its code samples, React answered my three basic concerns very clearly, in an obvious way:

1. Component based architecture

2. The ability to express view as a pure function of state

3. The ability to express HTML and code together in a neat and ergonomic way

This is what I mean by obvious -- all experienced frontend engineers I knew at the time immediately got it, they got that React nailed these three things, and why they were important. Surprisingly, even new frameworks don't always lead with these three principles, which makes me less likely to believe that they resolve the particular concerns that I find of most importance.


Right on. I definitely resonate with the first two. The third is somewhat arguable for me, but I've historically appreciated it and probably did much more when React first came to my attention.

And yes, I ended up falling for React for these reasons and more. When we moved to Rails server rendering, I even experimented with rendering React components from the Rails server. It worked, but the rube-goldberg contraption wasn't worth it.

Instead, we opted for helpers and view partials. The limited behavior we needed on the client would be in a separate Stimulus controller. The helper would typically reference it. Then, the declaration in the view would look more or less like a React component invocation, albeit with a totally different syntax.

There may very well be room for improvement here, but it certainly works "well enough". As I've mentioned, the main thing that is different now is that we can render updates to views on the server. This allows us to have "The ability to express view as a pure function of state" on the server and not have to be concerned about everything else that comes with owning and operating a React implementation.

I think React really helped move things forward and I don't regret my time using it. I may even use it again if I worked on an application where it was warranted.

I wish I could spend time with every commenter on here showing them our code, working with them on it, and helping them see the way that we do it so that my words don't just sound crazy or anathema. Unfortunately, that just doesn't work out in practice. I appreciate the discussion all the same.


I'm definitely a fan of LiveView and Turbo. I think they present reasonable choices for applications that are more complicated than a static site and less complicated than a full application. I would like to see their interop story with React improve, however, since I think a lot of impetus towards React comes from the fact that the core business product, which has high application/interactivity requirements, is (understandably) in React, so the cost of build is significantly lower staying within the ecosystem.

This is actually something I think a lot about, because in my company I am the TL of all the setting pages. We don't have high interactivity requirements, and it's reasonable to explore a different path. But the core product is in React, and there's basically no justification to rebuild it in something else just to build out settings pages.


Indeed. I think an important concern is what constitutes a "full application". I think that's where the community (I've even seen this at my own agency) has lost the plot a bit.

> I am the TL of all the setting pages

Ok, now I'm intrigued. If you're interested, I'd love to hear more about this. As someone who has (aside from a 2 year stint at Microsoft) only worked on relatively small teams (15 max) I'd love to hear more about what it's like to work on a team that's responsible for the settings pages. If you're interested, I'd be happy to connect for a chat. I just added my contact info to my profile here. If not, no worries! Cheers.


Meh, indeed :) Thank you for your response, it's a fair question and critique.

It'd be rather challenging to write guidance on which technology to use to build an application. Thorough guidance would need to consider far too much. You wouldn't have a tome, you'd have an anthology. You'd have to consider what is being built and by whom at the very least.

It becomes "self-evident" when you have enough knowledge and experience to make the selection and you successfully de-bias yourself from the "shiny" or the "common" (Which React was and is now respectively).

So, what would I recommend? Aside from the pat, "it depends" answer, I would recommend starting with a server-rendering based framework. I prefer Rails, personally, because Ruby works well for me and my team, but many others would do just fine.

Then, fight all superfluous interactivity for interactivity's sake in your applications. Stick to server rendering and form submissions until you need something more elaborate. Then, look for something you can use to augment behavior. I use Turbo/Stimulus, with which we are able to do a lot with very little. Others like HTMX. If one really needed the interactivity and declarative nature of something like React, then the list that the author mentioned would be good to explore. Most folks don't, and I think that's the main point that's lost on many.

Oh, and if you're building Google Maps, Miro, Linear or the like then disregard the above suggestions, they don't apply. Etc. (again, it depends)

As an aside, I was historically a huge React fan. I used it for quite a while. I'm still a fan of the declarative nature and one-way data flow. It's super powerful stuff. We actually get something somewhat similar with Turbo and the much more sophisticated Phoenix LiveView (can't recommend this one personally, haven't used it in anger). Procedural-based UI code for complex, highly interactive applications is a fool's errand in my opinion. For the basics though? Totally fine.


Appreciate these thoughts back - Every maybe eight to ten years I pick up a server-side rendering framework. Last one was go templates based, (significant impedance mismatch between go and html/json as you might expect), before that was rails (2010-era: too much magic, pre-declarative UI era), before that was tcl/aolserver. I thought tcl on aolserver did a great job, and of course HTML5 browsers are vastly more capable than IE4 was. It probably still is pretty nice, I imagine.

I think as a practical matter, when I've picked a language that has good synchronicity and impedance matching with the needs of the web, (arbitrary JSON and text processing and injection, along with keeping some sort of structured idea of the DOM), I'm usually at typescript, which I...hate...but I hate it less than writing type structs in go or, dealing with erlang, or, etc. etc.

Once I'm at typescript, I'm using react as a path of least resistance. I'll check out turbo/stimulus though, thanks for the reference. It looks promising, and a little more bare to the wire which I appreciate.


So now you have two, entirely separate worlds that don't compose in any way, and you have to create "DTO"s to convert from one to the other and back.

Don't get me wrong, I would much prefer coding in a single language for both backend and frontend, and I would not choose JS/TS for that. But your choice is that, only a decent choice. Just like react is. There are so many ways to do web development, and neither of these are fundamentally bad.

Specific applications of these architecture/designs on the other hand can be catastrophic in both cases, and I'm sure most of us has been burnt by these (e.g. for SSR, I have seen code that sent back HTML segments that reused IDs. With dynamic JS it was a pain to hunt down these errors. But there is an entire field dedicated to all the vulnerabilities that have historically been opened up by careless backend devs).


> So now you have two, entirely separate worlds that don't compose in any way, and you have to create "DTO"s to convert from one to the other and back.

"Now" being what specifically? The technologies I mentioned allow everything to happen on the server. We've got a relatively complex set of applications: 30 deployed apps, composition using SSI (server-side include), collaborative form entry for complex form including sections that appear/disappear, etc, near-real-time comments, etc. We have on the order of 100s of lines of JavaScript and I don't think there is a single JSON API (so no DTOs).

> But there is an entire field dedicated to all the vulnerabilities that have historically been opened up by careless backend devs

This may be part of your problem. The people returning the HTML are front end devs. Rails and the like are front end frameworks. The server is just the server of the front end. This notion that "front end" is just React/HMTL/CSS is a new thing that can be problematic as you describe. It's all front end stuff, always will be. You can tell because of what's happening with React with server-rendered components, NextJS trying to blur the line, etc.

I'm suggesting that if your perspective includes this kind of dichotomy and you see different teams of developers working on client-side than on server-side, you have to first address that as a problem.


Then every significant (you can get away a lot with very tiny js and/or css, like menus) user interaction will necessarily cause a server round-trip, which is definitely perceptible by humans, no matter how fast your internet is - so it's a bit dishonest to claim that React is "slow".

As I said, this is definitely a viable approach, but so is react. Both would fit like 80% of all websites just fine, given that they are developed by decent developers.


Human perceptibility is only relevant in certain contexts. Are you in one? Ok, maybe you need client side interactivity. This is what I mean by "highly interactive" applications like Linear, Miro, Superhuman, etc. Having to wait for a server round trip in those wouldn't be good and I would build one of those using an SPA framework/library. This isn't in question.

A forms over data application can be built with React. That's "valid", but what is the cost? The latency in showing/hiding things can be seen with slower internet connections, but so what. What is the cost of that? Have you ever used an air travel booking site? Many of those interactions are painfully slow but you still booked your travel, right? Now take those slow interactions and make them so they are actually just on the edge of human perceptibility (which is easy with server rendering) and you've got a perfectly great experience for your users. If your users are captive (it's their work application, or they need to book travel, etc) then you have even more (but we wouldn't need it) leeway.

If you're a shopping site where revenue is tied latency, maybe it's necessary? But have you used Amazon? There's all sorts of server loading there and they do pretty well.

I'm not claiming that React is "slow". It's slowER on time-to-interactive on average. It can be slower to develop applications. It is certainly more costly from a maintenance perspective due to the unstable nature of JavaScript dependencies.

I'm not going to be able to convince you of any of this. I'm only here holding a sign saying that things aren't as straightforward as they seem. There are costs and costs and costs to this stuff that many see as a normal day in the office.

I'm just saying there's more productivity beyond the horizon, and you're not going to find it by embracing and extending complexity. React is complexity. All the things that come with it to compensate for its complexity are more complexity.

Teams go faster permanently by embracing simplicity. Using React for a forms over data application is the opposite of that. You can do it. You can get your first version out "quick" but over time, that complexity will rear its head and you will slow down.

Have you ever been on a team that wasn't as fast as it was on the first day of a project?


> But front end performance issues are almost never the most pressing issue to deal with.

Maybe not to you, but it's by far and away the biggest complaint with any website or app that uses React/Angular under the hood in my experience. On any computer older than a few years, the sheer amount of JavaScript being demanded to be run creates serious system bottlenecks.

This is literally why I cancelled Spotify, because it's fucking absurd to me that I need a (then anyway) 700 MB app to stream music.


Is it? On Hacker News it probably is, and I agree that it can drive engineers nuts to know that apps are more bloated than they have to be, but I think we’re a relatively small percentage of the population. Among my less technically/inclined friends and family I haven’t heard one complaint about, say, Spotify being slow, and certainly never any complaints about its size.


> Among my less technically/inclined friends and family I haven’t heard one complaint about, say, Spotify being slow, and certainly never any complaints about its size.

They don't say "modern software is slow", they say "my computer is slow, I need to buy a new one" and they do.

Let's be honest: for what the vast majority of people do on their computer, there is absolutely no need for a Macbook M3. The only reason is that the websites are developed by people who buy (or get from their company) a Macbook M3 and therefore don't see how much their website sucks on a reasonable machine.

I can track it very well on my father's homepage which has been the same for 25 years. He has a 4 years old desktop mac and the webpage takes more than 20s to load. On an M3 it takes 2s. This homepage is still loading exactly the same kind of information than 25 years ago, yet it is almost unbearable on a 4 years old desktop computer. Does my father say that this webpage is slow? No, because all software goes like this. My father says that his computer is now old and considers buying a new one.


> the same for 25 years. He has a 4 years old desktop mac and the webpage takes more than 20s to load

How long did it take to load 20 years ago, on a 20 year old PC/Mac ? - seems like a very big page?


A few seconds. It's a news webpage, that has mostly text, links and images.

And of course now it loads a ton of useless widgets, probably much bigger images (sometimes they load a video to serve the same purpose, just because they can), and a whole lot more code. And that's with uBlock origins; if I disable it it's a lot worse.

Objectively, in 25 years they have been paying people to make it an order of magnitude worse. And it's not only them: the vast majority of websites have followed that trend.


There is supporting data that webpages have become bigger faster than the bandwidth even increased. This is like, very bad. https://www.nngroup.com/articles/the-need-for-speed/


People just stopped complaining and search for workarounds on themselves or just suffer silently.


They don't say "I'm sick of React websites," they just say "Wow websites are getting slower and slower." or they complain about specific tabs or just the browser in general sucking up tons of RAM and CPU.


I’m also aware they won’t make the direct references and I’m willing to bet the OP is too.

There are very few instances I can think of for the last 4 years where I heard anyone complaining like this about the general state of these things. There’s a few offenders I can think of, like Salesforce, but I haven’t heard from any non technical users especially about things like Gmail being slow or their browsers being too slow.

Whet I often hear instead to be honest is people widely seem surprised when they have 200 tabs open in Chrome and everything still feels fast to them

That’s not to say performance isn’t important, it really is, in fact I’m the performance czar where I work, I spend along time on optimizations and performance.

However the acceptable performance threshold is dependent on the activity more than anything I’ve found. That’s why it’s such a big deal in e-commerce but people don’t seem to care as much for longer lived apps, otherwise Jira might actually be snappy

Now of course there is a threshold regardless of app where it will things negatively, losing customers etc. and thus it shouldn’t be ignore either


Then you are in a bubble. I was recently asked by my elderly parents why they are paying for 5g internet when the internet resources they use are so slow, slower than what they remember from 1997.

They ask me to call our ISP because it makes no sense that the sites they have used for decades feel so slow

All I could say was that there was nothing I could do.


Every time I use Facebook (which isn't many but still) I am re-shocked at how fucking SLOW it is. How many times I end up refreshing the page because some damn thing didn't connect quick enough, or maybe too quick and it wasn't ready, I'm not sure.

YouTube is also great for this, like, 1/50 navigation clicks just results in a blank page with no error message. Ctrl-R to the rescue.

Or the number of times Reddit's infinite scroll just... dies. Somewhere in the background, I don't know where.

Like I can't think of any of these major platform websites where shit isn't just constantly tripping over it's own dick and breaking in often humorous but also just ridiculous ways.


Insulated market forces allow certain platforms to operate like this with very few overall repercussions.

They also don’t represent the overall web. I think it would be more far to take a sum of websites used, as opposed to number of users.


That is a bit of an uncommon situation. Given the prevalence of things like 5G internet is typical in more rural or underdeveloped areas, the vast majority of the population of which don’t live.

It’s a valid concern (as I think performance always is to be clear) but the majority are not on higher latency / limited bandwidth connections like 5G internet service as their primary ISP delivery tech.

Vast majority are in cable or fiber at this point, given urban saturation



> because it's fucking absurd to me that I need a (then anyway) 700 MB app to stream music.

You only know that factoid because you're an engineer and you looked it up. Users have absolutely no clue, and literally do not care.


> Users have absolutely no clue, and literally do not care

When their smartphone is 3 years old and has no more storage space, they say "the smartphone is old, I need a new one".

Because they don't know that this is a problem of the software industry being extremely bad doesn't mean that it has no impact on them.


Since when are engineers not users too?


When they make up a fraction of a percentage of users. If there was any pressure from users to make smaller apps, Spotify would have done it.


Phones are literally sold at different prices when they have more storage. People are familiar with being unable to install more apps or take more pictures. Happens all the time.

Get out of your bubble.


You are in the HN bubble. Layman users do not notice. They only care if the app works or not. A 700MB app on a phone with at minimum 128GB is nothing.


If you use your phone for just 1 app… sure.

I've never encountered anyone at all doing that though.


I hate what "modern" web development has done to my UI experience.

Eg. There's a delay between an Amazon.ca results page loading and it populating the search text box with the phrase you just searched for. As a result when I do two searches in rapid succession, it consistently interrupts my typing at exactly the right time to batter in incomprehensible text.

AirCanada and WestJet are two other websites that became awful to use after adopting React-ey style UI's.


There's no React-ey style UI. Seriously. It's a UI framework not a collection of prebuilt UI components. You cannot tell if a site is using React or not without opening dev tools.


Vast majority of the comments on this story complaining about React are actually complaints about some bad UI library or a poorly designed and architected website that happens to use React.


I might not be able to tell if it's using React specifically, but I can tell it's using a React-like framework trivially because it feels like the entire website is covered in glue


No. You are just dealing with bad code. There are highly performant web apps written in React. It's all about craftsmanship. React gives you many tools to skip unnecessary work and reduce latency, such as shouldComponentUpdate, and assigning keys to elements in a collection. Or architectural decisions like splitting your UI into components correctly. It's up to the individual developers to use them. Bad developers write bad code in any framework.

But one thing I've noticed is that because frontend code runs on users' computers, fewer businesses and engineers have the incentive to really optimize that performance. If one writes bad backend code, it shows up as increased AWS bill; if one writes bad frontend code, well the cost is diffuse and many don't notice it.


> No. You are just dealing with bad code. There are highly performant web apps written in React.

cool maybe I'll see one one day

> React gives you many tools to skip unnecessary work and reduce latency, such as shouldComponentUpdate, and assigning keys to elements in a collection

but do people use these outside of demos

I have an high end CPU with 32GB of RAM and almost every single website I use gives me a worse experience than I got 20 years ago

> if one writes bad frontend code, well the cost is diffuse and many don't notice it.

exactly, and that's why we are where we are today - surrounded on all sides by websites covered in glue, because bad experience has been completely normalised, all for what? Some abstract notion of developer convenience that results in almost every case in a significantly worse experience by almost any metric.


> hundreds of milliseconds. Yes, there are a few specialized domains where this will matter. No, you probably don’t work in one.

This is funny to me, because I would think that for hundreds of milliseconds, anything user-facing is impacted. It's on the order of the human reaction time (~200ms). That's noticeable delay.

I do not work in frontend, so perhaps I am misguided. But I have had bad user experience using apps with even 100ms delay that require a lot of input (for example using excel or something in a streaming VM).


You are not misguided. Physiology is mostly intangible but consistent. Many of the comments here willingly ignore that “yes but my use case is different and my users are patient”. Their brain will still disconnect quickly and be frustrated.


> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds.

Many years ago I worked at a wonderful company that made the terrible decision to rebuild the frontend in React. We had a performance dashboard permanently displayed on a TV in the office, prominently showing the p99 time-to-interactive of our home page. It sat at TWENTY SECONDS for at least 2 years. No progress was ever made, to the best of my knowledge.

This was an e-commerce site, more or less. As per the author's reasoning, it absolutely should not have been an SPA.


E-commerce sites are a pretty good fit for SPAs. Sounds like a bad rewrite, nothing more, nothing less.


Why do you think that?

The only client side component of interest would be filtering and sorting, (although the server could render the new state too). I would choose traditional server side + a little bit of client side code here.


To your third point - the author would recommend doing research and prototyping with all the options you might consider based on your use-cases. He actively avoids being prescriptive in generic contexts like this because he wants to avoid arbitrary dogmatic solutions (like React tends to be).

Source: I work closely with him and have been frustrated with this stance until I saw people using Next and Remix for things like landing or contact pages.


(Sorry, somewhat copying this, since I responded to a similar point elsewhere.)

This is not practical advice for the vast majority of software engineering teams.

Most teams do not have the privilege of being able to do research and prototypes across multiple options, at least in a way representative of what their final product will look like. Most teams - at least those in small to mid-size startups - will start out building A, route through A' and A'' and end up building B once they land on PMF. If you were to run 5 different prototypes on A, you're going to be a bit upset when you end up at A' and you're likely to run horribly technically aground when you truly find the right thing to build.

Yes, if at the point when you discover B you have the latitude to rewrite your entire codebase to fit your new criteria, then by all means, go ahead. That will definitely outperform React. I think the teams with that kind of latitude is an exceptionally small fraction of all teams, and the number of teams with the technical chops to do it correctly will be an even smaller fraction of that. The rest of us will use React, which is roughly 80% as good as the optimal solution.


My experiences don’t really align with yours - most people are playing “follow the leader” with tech - “X uses Y, so we should to” and that’s it.

To your point though - use the platform. Vanilla HTML, CSS, and JS. All of that will be reusable no matter where you pivot and not lock you in to a pattern that might not work well for where you land.


> Vanilla HTML, CSS, and JS

This is a non-answer. It only really is an admissible solution if you're just working by yourself. React solves real problems when building web applications. If you use vanilla HTML, CSS and JS, you're going to have to solve those same problems. How are you going to do it? How are you going to manage state? How are you going to synchronize your state with the DOM? How are you going to organize your components?

Teams that use vanilla HTML, CSS, and JS end up eventually building an internal, buggy, half-implemented, undocumented version of React.


I didn’t say don’t use libraries at all. There’s a wide spectrum between rolling your own everything and putting a massive abstraction layer framework between you and the platform.


This is a really good article that puts very clearly some of the WTF moments I've had since having to take over a React project. However, if the title is "If not React, then what?", then the author should've answered that question.

I did find some recommendations for other reactive front-ends buried in the article, but I didn't see anything that set them apart aside from the fact that they are smaller projects. Now, if I want to follow the article's advice and get off of React I have a ton of research to do, research that the article's title didn't hint that I'd have to get going on.


> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds.

Try opening facebook.com; click the messenger, (+1 second) Click one of your chat groups (~2 seconds)

This is merely just to show something

From what I have seen, its quite easy to have performance issues with React


So easy in fact that even the company that makes React can’t use it in a way that makes their site fast.


That doesn't say much about React, though. Indeed, you can open the network panel and watch requests go by over the seconds that it takes to open, suggesting that the issue likely resides on the backend.


So the company that invented it does not know how to properly use it?

Or are you implying that React does not fit FB use case?


He's literally saying the front end technology doesn't matter at all in this.

Are you just going to defend React to the bitter end? Or do you just enjoy imaginary binary choices?


I think I was not clear in my question:

I don't defend React. My question was almost the opposite and I was trying to ask:

So if even Facebook has a problem with using React then who has a better examplea about why and how to use it?


Like I said, React has nothing to do with the slowness issues of messenger.com.


but i think the reason for +1s, +2s feeling comes not from the client side aka react, render is fast, but they do make two requests to backend which takes ~230ms (for me in EU) and one request of ~130ms every other click on already visited chat/group chat.


> 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.

This is fine for solving random business integration concerns, but for application software we have to use on a daily basis, it really sucks.

Modern web applications sometimes feel incredibly shitty to use. Gmail, YouTube, YouTube Music, Reddit, Twitter -- these are all bloated, hulking, beastly things.

I'm really hoping Rust becomes popular for specifically web application development. It'll need to overcome the awkward WASM/DOM bridge, but then it'll sing.

Heavy software that users spend hours within are where those hundreds of milliseconds per action really add up. We should be angry about anything worse than single digit milliseconds with these tools.

We need an engineering culture of excellence in these domains. Channel the Steve Jobs energy to say this isn't good enough.


Why would you think rust will make the web sing? Their HTML documentation generator uses 571+ dependencies. So, hello more bloat! If the core rust team can't avoid it why would you think any other rust project would?


Why would an HTML generator need to slim down on dependencies? It's designed to run in CI, not respond in real time to user requests. It very infrequently runs and generates production artifacts with humans out of the loop.

This is a bad argument against Rust in the frontend.

Web frontend development is very nascent in Rust, but there's already cool stuff taking shape:

- https://www.egui.rs/

- https://leptos.dev/


You’re both right. It’s not as important that a documentation generator be blazing fast, but it’s a bad sign. If the core team finds themselves using 571 dependencies for something as simple as a documentation generator, how many thousands of dependencies will the average small business, trying to deliver value to customers quickly, end up using to create a line-of-business web app?


> This is fine for solving random business integration concerns, but for application software we have to use on a daily basis, it really sucks.

And more than it just sucking, it is unnecessary. We have mature, well documented, cost effective solutions for developing software that have been around from years to decades. We know how to develop software. The problem is people trying to develop software with web tools.


> Heavy software users spend hours within are where those hundreds of milliseconds per action really add up. We should be angry about anything worse than single digit milliseconds with these tools.

I think in the article writers mind here we are talking hundreds of milliseconds on first load and the majority of actions are instantaneous after that.

This can be achieved, but it takes some diligence and product mind focus to optimize what you can how you can and even big companies like Google don’t always prioritize this the way they should


> Rust becomes popular for specifically web application development. It'll need to overcome the awkward WASM/DOM bridge, but then it'll sing.

Colour me doubtful. As long as the DOM is accessible in JavaScript, it can't be a first-class object in WASM. And no one is going to transfer the DOM into WASM and break every JavaScript app out there.


> As long as the DOM is accessible in JavaScript, it can't be a first-class object in WASM.

I'm curious, why?


For the same reason that it's not now. It needs to be native on one side and bridged on the other.


I urge you to read Alex's Reckoning series.

> performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds.

I think outside of the privilege bubble where a significant percentage of the world is in, these concerns are measured in the tens of seconds.

> it doesn’t create issues visible to my users

What do your users look like? What kind of devices are they on? Is it mostly mobile or desktop? Are they mostly accessing your service on cellular networks or not? Based on that, what does your INP look like? IMO you'll see the impact of React's legacy synthetic event system by looking at your INP because it's reinventing in userland what the platform already does well. This impact on INP is amplified on mobile and moreso on low-end mobile. See CRUX data visualised by desktop or mobile below:

https://infrequently.org/2022/12/performance-baseline-2023/#...

> Finally, the author doesn’t actually give a prescription as to what to use instead of React.

I think he does and that's a big part of this article. It's almost literally everything from the "OK, But What, Then?" section. The TLDR is there isn't a one-size-fits-all.



Yes, that's the one! Thank you for linking it.


thanks back, i never saw his blog and he seems deeply knowledgeable


> I think he does and that's a big part of this article. It's almost literally everything from the "OK, But What, Then?" section.

I did read it. I didn't want to go into depth debunking every single sentence OP wrote because I thought it would be obnoxious, but I'll write a bit more.

> The TLDR is there isn't a one-size-fits-all.

That's what I mean - the author gives no prescription. Saying there is no one-size-fits-all is not a prescription. I'll respond to a specific quote the author said, which I believe to be the crux of his suggestion:

> Teams that have grounded their product decisions appropriately can productively work through the narrow form by running truly objective bakeoffs.

Most teams do not have the privilege of being able to "ground their product decisions appropriately". Most teams - at least those in small to mid-size startups - will start out building A, route through A' and A'' and end up building B once they land on PMF. If you ran a "bakeoff" on A, you're going to be a bit upset when you end up at A' and probably run horribly technically aground when you truly find the right thing to build.

Yes, if at the point when you discover B you have the latitude to rewrite your entire codebase to fit your new criteria, then by all means, go ahead. That will definitely outperform React. I think the teams with that kind of latitude is an exceptionally small fraction of all teams, and the number of teams with the technical chops to do it correctly will be an even smaller fraction of that. The rest of us will use React, which is roughly 80% as good as the optimal solution.

Oh and, yes, if you work at a huge company who has found PMF and has the latitude to rewrite your code into whatever the optimal solution is, don't let me stop you. That is what Google and Facebook did, after all. I just don't think many of us are Google or Facebook.


> That's what I mean - the author gives no prescription.

Are you expecting a prescription? If so, what could that look like? Specific technologies? When specific technologies are appropriate?

> Most teams do not have the privilege of being able to "ground their product decisions appropriately". Most teams - at least those in small to mid-size startups - will start out building A, route through A' and A'' and end up building B once they land on PMF.

I don't quite understand this. A bakeoff is meant to give you space to figure out what technologies are appropriate for the service you're building for your users and taking into consideration what your developers like. It's a collection of proof-of-concepts so it's a quick and lean way to get data on what's more likely to succeed for you. I can accept that the technology doesn't make a product, so focusing PMF is important, but you also don't want to pick something complex that you can't afford to manage as you scale.

The worst thing I see happening is you reach PMF and need to continuing scaling, but you hit a high complexity wall that you can't move past till you manage it. All that unnecessary complexity you took on and didn't invest your already limited resources is now tech debt that's oppressing your forward momentum. Bakeoffs can steer you towards the simplest tool you need to deliver your product so that it can stay out of your way so you can focus on iterating and developing your product.

> The rest of us will use React, which is roughly 80% as good as the optimal solution.

How are you measuring this? A lot of the evidence for using a technology and running with it without managing the complexity turns out badly (see The Reckoning series by Alex). And React is a high complexity tool that requires a lot of continued management investment.

The thing that appeals to me about doing bakeoffs to find the simplest thing for my product is not that it'll be the most optimal; it'll be the cheapest to maintain. The less complexity you have, the less you have to invest in managing it.

> I just don't think many of us are Google or Facebook.

I agree. That's why I think it's best to pick the simplest tools we can afford to manage so we can get on with building our products. Facebook or Bluesky or Airbnb can afford to build their products many times from scratch and they can pay to maintain whatever complexity they take on.


> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds.

This is not my experience on real react sites. Loading the pages on mobile (say 4G) takes seconds to load with a partially rendered page which is slowly constructed. Loading the equivalent pages in HTML rendered server side would reliably be under 100ms (excluding assets). This is somewhat disguised by better connections and large images taking up, but all that js and json does have a cost.

You're probably trying to talk about the overhead of the framework, but what is the true overhead of a framework which encourages you to introduce bloat and create a separate component file and sometimes a separate network connection for every single component on your web page?

Here is a real case study with comparison of approaches from this author: https://infrequently.org/2024/08/object-lesson/

>The second reason the author says is that it’s based on a legacy eventing system which supports IE.

There are lots of horrible bits of react which are based on solving problems which aren't really a problem on the web any more - from manipulating the dom (pretty easy without react) to dealing with IE polyfills, and lots of bits that you really don't need the client to concern itself with (i.e. routing code). You may not care about that code but you are importing it and forcing your users to download it. It all adds to overhead.

There are also a ton of other points in the article which you've elided, which go into the multiple failings of React as a tool, and primary among them is that it encourages you to use react and only react, the ultimate in lock-in.

> Finally, the author doesn’t actually give a prescription as to what to use instead of React.

You want them to choose one framework instead of react, they're explicitly rejecting that choice and saying you don't have to become a follower of react or any other religion, instead they're advocating choosing tools based on the evidence they have presented, so they are IMO presenting a clear choice:

Server side rendering with a bit of js as required to load dynamic data

React or similar frameworks which try to push everything to the client


They’re not problems most people have because they shouldn’t be using React or maybe even a SPA-type site in the first place! I think that’s one of the big points regardless. Just using react and it’s bloat to be hip and it not actually doing anything better or more performant for the use case of a shopping site. It’s not a CAD app or web office suite.


> 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.

I'm guessing you're one of those developers who never browses the web on anything but the latest Macbook Pro and iPhone. I implore you to restrict yourself to some lower end devices for a few weeks and let us know if you still feel the same way.


I generally agree with you, but I have a budget cell phone (~$100) and I can run StackBlitz on it without it even blinking. I think budget cell phones have gotten a lot better than most people think.


There really are only a handful of things you could do that should passably take "hundreds of milliseconds" and loading a web page is not among them. Neither is displaying a few hundred thousand things on a screen, least of all what are essentially rects in 2D.

The only reason any of the above sounds fine to take this long is because the standards of web development are so incredibly low.


sure if you have the access directly to drawing those rects in 2D, but if you are using a library to do drawing of the rects you may have a small tradeoff of time (obviously not 100s of milliseconds) and if you are using a library that abstracts away writing to the DOM for you and then the browser takes the DOM and essentially figures out how to draw a hundred thousand things on the screen you might get in the hundred milliseconds area - depending on a whole bunch of things that are varying from time to time.

The only reason that 100s of milliseconds might sound fine is because there are multiple layers of abstraction between levels, but as you can see from all the other responses here the 100s of milliseconds evidently does not sound fine.


> But front end performance issues are almost never the most pressing issue

Tell me your websites are unbearably slow without telling me your websites are unbearably slow :D


I've spent plenty of time optimizing performance. It almost always comes down to a backend issue, unless the frontend is doing something profoundly stupid, like making multiple API requests in serial when they could be batched or parallelized.


Yes because loading 500 different css and js files is not a problem for performance.


They literally just said "unless the frontend is doing something profoundly stupid".


That's the norm in the React world nowadays. You should take a look at https://infrequently.org/2024/08/object-lesson/


This article is better, but has very little to do with React. The major issues I see are 1) loading a 2.5 MB AWS library (not React), 2) not doing SSR (not React) and 3) not tree shaking (not React). I agree these are all problems. But shouting to the skies about React is not going to solve them.


'React' is really just a stand-in for the excesses of client-rendered apps. Do you really think Alex Russell, after writing all these blog posts about the general problem, thinks that React specifically is to blame? Of course not. He is picking it as an example that often causes higher complexity.


I think his definition of profoundly stupid probably differs from other people's.


In 2024. React is probably the worst choice you could make when creating a new web application.


For static web page, it would be tough to beat html/css. But if you are building a web application of some complexity, it would be tough to beat React.

You can totally shoot yourself in the foot with any language or framework. And you can most certainly do that with React as well. As we so often see.


...and the best would be?


Yeah, poor performance is possible in any system using any tech. Being able to diagnose it and fix it is what matters.

I've never had a performance issue I couldn't fix in React.


I think the question that we are discussing here is:

What amount of performance issues you will not need to fix if you were not using React to begin 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.

Respectfully, I disagree on all of these points.


Care to elaborate?


Other commenters have elaborated as well, but to summmarize: hundreds of Ms on a dev machine a) does matter and b) is likely much much more in less than ideal computing environments, I disagree that the backend usually is where more time is spent (at least in maaaaany apps I have worked on) And re: specialized domains, I think most users of most software appreciate speed even if it isn’t a stated objective




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: