React 19 | Hacker News Reader

React 19

github.com

307 pointsgajus499 comments

Why do a lot of people here hate react so much? I started my eng career with Laravel and plain JS. After working with React, I've never seen anything like it. I feel like building scalable apps is achievable and front end is fun with it. Even when moving between different tech companies, working with React again is such a breeze and easy to pick up. On top of that, with the TS support, huge community libraries, I feel like I can build and scale anything quite easily. why are these new features "scaring" people away? we can still build with SPA or the old ways. I don't think anyone complaints when NoSQL DB was released or when spring boot was released in 2014? what about when Kotlin was released? we don't have to use them if you don't want it.

Weren't jetpack compose and swift UI inspired by React? I saw it somewhere in the android docs and now its probably deleted, I can't find it anymore.

But then again, I don't have "decade" of experience in tech, yet. I have no idea if building huge web apps (i.e airbnb) using jquery or plain js with large teams is as enjoyable back then? My thought process is changed, I can't even think on how to solve the state management, dom manipulation, side effects etc with plain js anymore.

Nowadays I just built on what I'm familiar with and focus on what I want to build. who knows, maybe in the future I will also complaint about new frameworks and mention how good React was :)

HN has long had a huge anti-Facebook bias, I wonder if it's just that.

I don't think so. Comments about PyTorch or llama are always extremely positive.

I didn't even know they were Facebook. Do they actually get used in Facebook-the-product in a user-facing way?

You seem to speak as if the only choices are React and jQuery style DOM manipulation. React isn't the only framework you can use to build scalable web apps.

Oh i agree, but I never said those are the only choices. I was only exposed to React and a bit of Vue and Angular after Jquery so I'm speaking from my own experience. I am planning to stick with my choice that's all. My argument was mostly towards the hatred of react.

as for why I personally choose React was due to the job market, community support, debugging exp, TS support, and JSX just felt much more natural to me. I don't go everywhere hating other frameworks though. I think its good that we're tackling the same problem with different solutions, we have more choices.

> I am planning to stick with my choice that's all.

>as for why I personally choose React was due to the job market

From my experience, this is the problem, and I don't know that anyone is to blame for it. React's success has created skill drift away from the web platform. When I first started as a web team manager, my new hires knew the fundamentals of web standards: html, css, js, and some libraries to make those easier to work with.

Now, most entry level web devs know some flavor of React, full stop. These aren't Bay area web engineers, these are the web mechanics that need to get into whatever is thrown at them and keep it working, or make it start working again. I know losing grip of the platform is short-sighted in principle, and for the purposes of my team is immediately impractical.

but i did start with vanilla JS, then Jquery.. also at work I'm not only maintaining react but also Angular V1.

Choosing react is not necessarily drifting away from the web platform. I choose it as my main stack when starting new projects.

jQuery fell apart HARD when you started to build larger/more complex apps with it. I don't think there is anyone actually nostalgic for that time that actually went through it. For a while SPAs had their own disadvantages vs MPAs but newer web standards and SPA frameworks adopting SSR have basically solved those problems nowadays.

I have built large and complex front-end applications with jQuery. It worked great, no complaints.

I spent last 3 decades building web sites and web apps - and I agree with you. I don’t find alternatives as appealing as react.

Many have experienced horrible React projects - after Angular fell out of fashion with the enterprisey crowd, React became the default framework so a bunch of bicycle brain teams adopted it. React actually has a bunch of unintuitive footguns so without adequate care, working on it becomes pretty disgusting and results in emotional trauma.

And anyway... the weird parts about React are kind of weird... some people just like Svelte more ;)

I hate it because when I take it, instead of UI programming I now have to satisfy some absurd ideas about how functional async meta higher effect bullshit should work. All I need is to process events and update MY model (not some convoluted async representation of it smeared across visual elements and their lifetimes), from which something would update control values and text blocks. That's not literally all I need, obviously, but I don't need react nonsense in my way. In case anyone curious what I'm using, see mithril.js.

Also react uses (or promotes) web-hostile anti-features like document level event handling and virtual scrolling, which are PITA from a devtools tinkerer perspective.

useActionState: is a new hook to order Actions inside of a Transition with access to the state of the action, and the pending state. It accepts a reducer that can call Actions, and the initial state used for first render. It also accepts an optional string that is used if the action is passed to a form action prop to support progressive enhancement in forms.

Delusional gobbledygook.

> I now have to satisfy some absurd ideas about how functional async meta higher effect bullshit should work. All I need is to process events and update MY model (not some convoluted async representation of it smeared across visual elements and their lifetimes), from which something would update control values and text blocks

Could you elaborate on this? I'm not sure what an "async meta higher effect" is.

Reading in between the lines though, I suspect you're talking about state management. You might benefit from one of many state management solutions out there - redux, mobx, legend-state etc. Keeping and passing around local state spread out across lots of components can get unwieldy pretty quickly.

State solutions solve a self-imposed problem. With mithril I just do whatever I want cause it doesn't dictate shape or behavior to my data. I don't have to pass it around (except naturally) and event-ize up-and-down, cause it's easily accessible and lives outside of a vnode/element tree. Although data can be put into vnode, if it really belongs to its graphical state which would make no sense in its absence, e.g. current 'uncommitted' value in an input.

benefit from ... Redux

>_< had a good laugh, thanks! I imagine writing a hierarchical reducer every time I have to update x in {a:{b:[...,x,...],c:{{{...}}}}}-like structure. Mobx is close, but in the same "unengineering of overengineering" category.

(Edit: I don't think that parent comment deserves graying out, I'm always happy to elaborate on subj)

There's a whole thing between global state and local states and that usually comes with doing frontend routing on something that should have been an MPA (and maybe powered by something like liveview). React should have been what it was initially designed for, just a UI library for when you need lots of interaction on a single page. But the whole ecosystem is a mess right now.

FWIW, with modern Redux Toolkit you _don't_ write handwritten nested immutable update logic - you write normal "mutating" code in a reducer and it becomes an immutable update thanks to the Immer library:

- https://redux.js.org/tutorials/essentials/part-2-app-structu...

I also really don't get the apparent hate for react, usually from people who haven't used it all that much.

I've interacted with a not insignificant number of people who seem to hold this opinion. Usually their arguments boil down to one of:

* Frontend engineering is always chasing the next shiny thing, and react is one of them. There's probably some truth to this historically, but react has been a thing since 2013, and pretty 'mainstream' since 2015 or so.

* Frameworks and libraries add 'complexity'. I almost never hear anything specific when I ask about what complexity they're referring to. IMO if you work on a non trivial application without a framework, you'll just end up inventing your own poorly maintained, poorly tested and poorly documented framework. This might be fine for a weekend project, but rarely something you should do at a company.

* People also often complain about the compilation/bundling step. This might've been harder to manage historically, but now with battle tested frameworks like expo, nextjs, meteor etc, there are very few reasons to write a webpack configuration or build pipeline by hand.

> I also really don't get the apparent hate for react, usually from people who haven't used it all that much.

Same for people that have never used Angular, or only used the old AngularJS 1.x

I have more experience with Angular, but I don't hate any of the other frameworks, I've built apps with React, Svelte and tried out Vue.

> I also really don't get the apparent hate for react, usually from people who haven't used it all that much

In defence of the haters, I think we’ve all seen our share of horrendously organized React SPAs. Dependency hell, (seemingly) infinite prop drilling, components thousands of lines long, the list goes on.

Some people think they hate React, when in reality they hate a specific implementation of it.

I contracted on a few different projects over a few years, with React involved in all of them. Each team had their way of doing something, and goodness me... each team I joined was way different than the previous one with respect to approach, style, testing, etc. And anything I did that was "wrong" (meaning, not to their particular approach), I was ... belittled or talked down to as if I was some imbecile. In a couple cases, I used an approach with company B that they'd discarded a year before, but 6 months earlier, my work with company A's team led us down adopting that same approach, with decent results. But company B knew better, saying that approach was 'crap' (but... looking at their own internal docs, 2 years earlier, it was the hottest approach).

I was shocked at how much time some teams spent on reinventing wheels rather than using some off the shelf components. "We need everything to be done in house so we can document it and have full control". But... designing all your own widgets is going to take months. "React makes it easy though, so don't worry - we know what we're doing' Yet... they didn't - untestable components that couldn't support what the original requirements called for months earlier, etc.

You know how people crap on PHP because there's so much 'bad' PHP out there? But others say "it's just how you use it - frameworks XYZ are great!". I feel the same way about React. There's probably some great examples out there, but I somehow tend to see a lot of lesser quality stuff.

Most of the use cases I've seen up close... there wasn't any real magic or benefit to React vs something else, but everyone was jacked to get more React experience on their resume for their next gig. It didn't really matter if the resulting output was good or not, just that they used React.

I don't hate React - it's a library. I'm tired of much of the B-team players requiring it to be considered "professional" (while simultaneously) eschewing testing and documentation).

For people who have chosen it, and get to stay on the same project for several years, honing their skills on one codebase and iteratively improving, great. Enjoy.

I feel like the frontend community is suffering from the "eternal september" problem. Like PHP, it is very easy to get started so you get a lot of inexperienced developers writing very opinionated blogs that are shared with other inexperienced people who can't see the flaws. Interestingly it seems that the PHP community has matured and now consist of very reasonable and experienced "leaders", while the JS/TS community as a whole is still a long way from maturity. Don't get me wrong, there are many excellent JS/TS developers, but they face an endless stream of adversity.

In my previous startup the frontend developers decided to develop their own design library from scratch. My suggestion was to start with an established library and just adjust the style to match our look, but they wanted full control and ownership of the code. 3 years later, most of them left for new jobs and the library only contains a very basic set of components. Apparently accessibility and the rest of the "remaining 80%" part of the "80% completed" components were more difficult than they assumed. At least they had fun and could pad their resumes when they applied for new jobs, leaving others to maintain their m

This mindset was so different from the backend teams in the same startup. They preferred stable and known frameworks and libraries, and focused on the business logic. I had a feeling that the backend teams just got stuff down with little drama, while the frontend team was engaged in endless debates and rewrites. They had their own issues of course, but once they had fought the battle of choosing which language and stack to use, they stuck with it.

I worked with both and tried to stay away from most of the discussions, but it is clear to me that autonomy only works when you have a good balance of senior and junior developers that can have a discussion with the others without needing to "win" every time. As a senior developer myself, I have often learned new approaches from junior developers who have found a problem and dug in deep. Unfortunately I have seen too many senior developers and junior developers not listening to good advice from each other. The juniors think the seniors are outdated, while the seniors think the juniors are not capable.

Most of these sound like team/people problems, not technology problems.

Like most problems in IT in general :-)

> Most of these sound like team/people problems, not technology problems.

I wonder what are the frameworks or libraries that have exactly one widely accepted, idiomatic and correct way of doing most things, where the technology itself discourages anything else? Angular, maybe, at least with how batteries included it is?

Show me one performant and nice react app. Even the creator can’t.

How are you measuring 'nice'? How are you measuring 'performant'?

My assumption would be that if you haven't seen anything, even from the creator, then you just have different expectations to the people who do get value from React

It’s interesting I’ve asked this question several times and no one can point me to one. Performant meaning when react is used it’s not at the bottom in speed and latency[1].

[1]: https://infrequently.org/#e-commerce

Every single React app has to ability to be nice and performant.

The issue (and this isn’t React’s fault) is that every single web app is so obsessed with measuring analytics and engagement metrics and loading multiple ad containers and and and…

Whether Vite, or Svelte, or Vanilla JS, when you start stuffing a site with all these tracking pixels and other junk, they are all horrible.

There is likely a bit of observer bias going on with your comment, as many popular sites these days run React and they happen to run like crap due to the reasons I listed above.

You don’t think Amazon is tracking tons? And their site blows Walmart, target etc out of the water. Google?

https://infrequently.org/#e-commerce

I’m not sure how that refutes my point. Of course they are.

That probably explains why the Amazon website just took 5 seconds to load on my phone while on a gigabit connection at home.

The point is clear. Amazon is far more performant and does tracking so that’s not to blame.

I don’t know how accurate this is. I just loaded up Walmart and Targets sites and they load very quickly and navigating between pages is snappy as well. What’s your metric for performance?

Are you in a fast and wired connection? The link I posted above has data:

https://infrequently.org/#e-commerce

Whether Vite, or Svelte, or Vanilla JS, when you start stuffing a site with all these tracking pixels and other junk, they are all horrible.

They're definitely horrible from a moral standpoint, but if you look at the flamechart of JS activity in your browser you can easily see that they sit idle 99% of the time and only send events to an API as low priority background work when the browser does things. They aren't what makes websites slow.

React is also incredibly behind the rest of the industry in terms of performance and has been for a long time. What you’re saying isn’t wrong but it’s a different problem on top of React.

Yes but in 6 months react will release a compiler to catch it up by a lot. Performance has diminishing returns and at some point, things just need to be fast enough (see vscode) and the industry will continue on as the switching cost is way too high.

True. But if the sites performed well (big if) and feel responsive, look nice, don’t break middle click and other browser functions - well I don’t see the problem, then. I don’t think the “hate” is irrational.

Which is why I think react (and other SPA frameworks) are now pointing beginners to full stack frameworks like nextjs, remix etc where those best practices are baked in. It took the JS frameworks a bit to find their path there but I think they are there now.

What are your thoughts on things like HTMX though, which with a small payload allow lots of SPA-like features and part of the content language itself. The other hatred I have is the need for all of this crap on top of a crappy language.

It's a big step back

HTMX has a ceiling on how interactive/complex you can make your site [1]. If you know you will never need to exceed those sure. However I like to use nextjs as it gives me the peace of mind I will always be able to pivot or implement whatever the customer wants.

[1] https://htmx.org/essays/why-gumroad-didnt-choose-htmx/

that's true[1] but there is also the programmer dictum "You Aren't Gonna Need It" (YAGNI)[2]

it very much depends on the type of app you are building, but I think many web applications could at least start with htmx and then, when more complex user interactions present themselves, use an island of interactivity approach that localizes the complexity.

this keeps overall system complexity as low as possible for as long as possible, and you may never need to go beyond htmx, which can lead to a much less complicated codebase [3]

[1] - https://htmx.org/essays/when-to-use-hypermedia/

[2] - https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it

[3] - https://htmx.org/essays/a-real-world-react-to-htmx-port/

I think nextjs does lead to a very simple codebase at every step of the interactivity gradient. You can have pure server side rendered HTML all the way up to full blown SPA and everything inbetween with just one tool rather than having...

1. HTMX itself

2. Your backend language Go/Java/whatever

3. Whatever JS framework for your interactivity islands

But yes we are all on the same team here of reducing complexity in the codebase and if HTMX works for you go for it.

Pretty much every React app I’ve worked on (and I’ve been using it for 10 years) has been nice and performant.

I’m sure every dev thinks that including the ones at Facebook, Target, and Walmart but they’re not. Show the data.

Drawing canvas: https://excalidraw.com/

Drawing canvas: https://www.tldraw.com/

Code playground: https://replit.com/

Supabase dashboard: https://supabase.com/

Vercel dashboard: https://vercel.com/

Workout tracking: https://workout.lol/

Chatbot: https://chatgpt.com

Note-taking: https://www.usememos.com/

Tax filing: https://ustaxes.org/start

Python notebook: https://marimo.io/

LoL info: https://www.op.gg/

Sports matches: https://www.sofascore.com/

Trading news: https://seekingalpha.com/

Website builder: https://mmm.page/

Podcast maker: https://podcastle.ai/

Dang you’re not wrong. I didn’t check all of them but in my phone those drawing ones are super responsive. If only most PWAs worked like that there’d be more goodwill for them. I personally feel most React apps and their abysmal performance (starting with facebook’s attempt) really hurt the PWA movement on mobile.

I dont think people are actually against PWA or React per se. In those examples above yes 80% of them should be using React. What most people have problems with are things like SeekingAlpha which doesn't need to be with React at all but is using it anyway. While I dont visit "SeekingAlpha" but most of the time these site will have one or two problems that makes it feel not a web page but a web apps.

airbnb, retool, sentry, datadog, snowflake..

refine: https://github.com/refinedev/refine appsmith: https://github.com/appsmithorg/appsmith

there are heaps what are you talking about!

not according to https://pagespeed.web.dev though (I stopped testing after Sentry)

I'm definitely a React hater personally, but Linear (https://linear.app) is built with React and is impressively fast and responsive.

I hesitate to admit this, but for me it's simply because I still don't know the right pattern to use. I'm a longtime backend developer that knows several useful and usable patterns on how to organize layers of code into files and functions and conventions, that work very well. I've spent quite an amount of time on the frontend, to the point where I feel like I should have been able to identify a decent pattern by now, and I just haven't. And it's to the point that I started doubting whether the problem was really me, or if it's a problem with the framework. I've read the revised React 18 docs backwards and forwards, and all the stuff about how you might not need useEffect, and I've read countless articles about outer components and inner components and view components and higher order components, and when to use context and when not to, and there's a point at which all the patterns start to collide and feel self-contradictory. Meanwhile my team has a massive snarl of very large react components with all kinds of awful practices like nested contexts and useEffect for state management, stuff I tried to counsel against for a while until I got promoted away from the team... I just couldn't find the best practice that the community actually agrees upon regarding how to refactor and design a complex website with many components with deep functionality.

I actually agree with this being / having been a problem.

I think the root cause of this is react not really being a framework, rather just a library that allows you to write declarative code involving state that in the end, outputs a DOM tree. IMO it does that quite well.

It doesn't have very many opinions on how you should structure your code, how you should organize your state, how your routing logic should work etc. I think that's where frameworks come in. React was quite popular long before frameworks like nextjs, meteor, remix, ... became 'mainstream', causing lots of developers to invent their own (poorly maintained) frameworks.

I feel this. I think it's a consequence of react being a fairly unopinionated collection of tools.

Coming from a Rails background, it's pretty jarring. It's like the difference between being told, "Here's how you build a house" and "Here's how you use the tools in this toolkit".

React offers more freedom at the expense of guidance, and you get much less standardization as a result.

This is exactly why I love it because it's not opinionated. I've been doing frontend interfaces for 30 years and it's one of the few times I've felt that I can write things the way I want and not be forced down some preconstructed path.

I get why some wouldn't like this but for me it's a breath of fresh air and why I continue to love working with it.

Agreed. On re-read, my prior comment sounds almost negative towards React's lack of opinions.

That couldn't be further from the truth! While I appreciated having a path laid out for me when I stated out, 10 years end I much prefer forging a path myself.

Mastering these tools, and leveraging my own creativity in how I use them, is much more enjoyable.

Thanks both; you've inspired me to push on with learning React (Native)! Gonna be a fun weekend

It was pushed upon me by management. I would have opted for Svelte or Lit. So I hate it, I hate writing code in it, I hate that it wants to control all your DOM, I hate how they "re-invented" HTML with JSX components and how the code now looks like PHP, as JS wasn't annoying enough by itself. I hate how it makes accompishing even simple things a PITA. At least I can use Vite and not bother with their opinionated tooling. There you have it, these are some reasons for all the hate if you had to ask.

> I also really don't get the apparent hate for react,

The hoops I have to jump through to get the back button working.

I don't personally hate React, I use it for all my personal projects.

But I try to stay away from it at work and I would rather push Vue 3.

There's few reasons:

- React does not really have a framework as good as Nuxt, which is light years ahead of the terrible mess of Next, and much more solid than Remix (which oddly comes also out with questionable stuff baked in)

- React is easy and funny to learn, but it's tough to master properly when it comes to few several key aspects like..There could be a PhD in hooks complexity, and all of that to avoid using class based lifecycle which was uglier but...much easier to manage

- Performance. It's just not good as on alternatives. At some point you scale, SEO and performance matter, React bites you back. There's many issues I could list from server to client side rendering and this will never be fixed due to how React's rendering works. Not only that but on React alternatives like Nuxt you end up thinking about performance way later

- DX on aspects like styling. I've tried everything and the DX of authoring and maintaining the style of react components is just meh

I hate it because of announcements like this; we are, as a small team, just getting to terms with react 18; a lot of libraries still are not working well with it and there is 19 already. It sucks.

So yeah nothing wrong with the concept of react, just the usual and terrible javascript ecosystem churn with stuff we don't need, but now everyone will have to update and so do we. Nice if you have a dedicated frontend team for every of your apps, not so nice for a small team that has to manage many apps across many clients.

I like major (potentially) compatibility breaking updates every 10 years or so, not every 3 weeks.

So yeah, we went off react to vanilla js, htmx and liveview type stuff which makes this all far simpler. Dev is also far simpler for us; all the pitfalls are no longer there. There might be some advantages to react in some cases; we won't look back; we never had a more relaxed team especially since we ditched nextjs and react; the trying out of other tech for frontend made us realize react was wrong for us all along anyway. ymmv of course.

React 18 was released in March 2022 though. It’s been over 2 years, not 3 weeks. I’ve also actually thought the React team is pretty careful about breaking changes. Their 19 breaking changes doc is mostly about removing already-deprecated APIs.

how many libraries does your project depend on?

I guarantee rebuilding your whole site in htmx was more effort than installing React 18 when it came out three years ago.

I'd also venture that this was a backend dominated decision to take control of the full-stack.

> ...just the usual and terrible javascript ecosystem churn with stuff we don't need, but now everyone will have to update and so do we

I don't think that there are many good options for front end that are maximally stable out there:

https://endoflife.date/react

https://endoflife.date/vue

https://endoflife.date/angular

Unless you want to look at something way more niche, you probably won't find something that has a main version supported for 5-10 years without major changes. Then again, that's usually not even the case with back end frameworks either, the closest you can get is either language runtimes like JDK (2014-2030, albeit the open source versions seem to end support in 2026), or maybe OSes like RHEL (e.g. 8 has a support timeframe of 2019-2029 or the extended option is until 2032).

In short, there is churn everywhere and I don't think you can simply pick any stack that is used for web development and will get exposed to the world (and therefore needs security patches), that will still work okay with no breaking changes along the way in 5-10 years or so. The only difference is how bad the individual choices will be.

The vast majority of websites don't need to be 'apps' at all. A few do, but these generally need to be tailor-made anyway.

The trend to shove web frameworks into everything has ushered in a nightmarish decade of slow, dysfunctional websites, that - despite being over-engineered to high heaven - hardly deliver an improved user experience compared to what we had in 2008.

There's a class of frontend dev for whom - no matter the question - the answer is always some unholy combination of React / Node / Vite / Angular / Vue / Nuxt / Next / Bun / Deno / Svelte / SvelteKit / etc - preferably running across two dozen Docker swarms, ruled by the Red Queen (kubernetes). "Oh, you want to put your CV online? Sure, let's spend the next three weeks plotting out the state flow diagram for your 'app'... "

The reason React is particularly disparaged, imho, is because the framework fashionistas have moved on to chase the new shiny thing, and everyone else has always hated all these frameworks to begin with, so there's no one left to defend this particular hot mess. The same fate awaits the rest of the frameworks, in time.

Yep. A simple shopping site or tweet site doesn’t need to be an “app”. These devs are up their own asses thinking they need an app for their stupid (and simple) idea because it’s easy for them and they are “engineers” and we’re all stuck with delayed reactions, missed/double clicks, and broken middle clicks (X, Target) on every click now. Some app.

I think I despise throbers and spinners more than slow page loads at this point.

At least the throbbers and spinners are real. The true evil is "optimistic rendering".

"Our framework is so slow that we can't possibly manipulate data in a reasonable time frame, so we'll just lie to the user and say we did! What could possibly go wrong?"

Also in the running: giving absolutely no indication whatsoever to the user that anything succeeded or failed or is in progress at all (aka the Apple approach).

This reads like the perspective of someone who really doesn't understand nor appreciate the real world complexity and technical trade offs involved in building something like twitter or a shopping site

> This reads like the perspective of someone who really doesn't understand nor appreciate the real world complexity and technical trade offs involved in building something like twitter or a shopping site

You're describing websites simple enough that they're often used in beginner tutorials for web development.

Online shopping and text-based social networking absolutely and emphatically do not require a spaghetti soup of JavaScript frameworks. These were relatively simple websites to build for decades before web frameworks ever came along.

Compilers are a common project for university CS students. That doesn't mean GCC is overly complicated.

There's a huge difference between making a simple prototype of a concept and making an actual production app that fulfills a myriad of requirements that help you run a successful business.

Agreed, but not even a battle-hardened production compiler requires a particle accelerator or an optical fibre cable to the Webb space telescope. Similarly, a shopping site or text-based social media does not require a soup of web frameworks. It just doesn't - it's not a solution commensurate with the scale of the problem. Complexity is expense, and this doesn't remove complexity, it introduces it, reams of it, and totally needlessly.

No one has ever sat in front of a shopping site and thought - 'you know what this needs? A dozen extra mb of JavaScript that introduce no actual new customer-facing features, but that put a noticeable delay in every interaction, break the user's scrollbars and screen readers, and dramatically complicate maintenance.'

> soup of web frameworks

What a beautiful Straw man. What are these social media sites with more than one framework?

> ever sat in front of a shopping site and thought

But do you know what actually think? That they want to have products filtering, they want to have more products loaded with a simple button click, they want to add reviews and comments, they want to see product photos (or maybe even 3D models) - all fast without unnecessary page reloads. It's your problem you can't build it without breaking user experience.

All of the things you list can be achieved with minimal or no JavaScript, and many are completely trivial (filtering? adding reviews and comments?).

In general, if a prospective employee told me they needed React to implement website comments, I would not walk away with a very high opinion of that dev's abilities.

They cannot be achieved without JavaScript and still be fast (good luck having product filtering with full-page reloads, your users will flee) - that was the whole point. And I didn't say you have to use React specifically. But without framework you in the end just create a custom one (as was said multiple times by other commenters).

As I said, minimal to no JS. Something like HTMX or Turbo* is more than sufficient to solve this fictitious full page reload aversion that users supposedly have (they don't, they have much more of an aversion to endless spinners and websites that break their browser's scrollbars and back buttons). Ask the average person whether websites have gotten better or worse since 2014. That's their opinion of SPAs.

> But without framework you in the end just create a custom one

Only if you've only ever written React-style webpages, and can't imagine any other way a website may work. Which, needless to say, would reflect a very limited experience of the web.

* Or just a plain XMLHttpRequest call? Dynamic loading is exceedingly simple, and certainly doesn't require a convoluted web framework.

But we're not talking about SPAs, we're talking about e-commerce websites.

> full page reload aversion that users supposedly have (they don't, they have much more of an aversion to endless spinners and websites that break their browser's scrollbars and back buttons)

I'm simply saying user wants performant websites. You're basically saying the same. Full-page reloads are, ceteris paribus, always slower than some JSON payload. And when you're saying to use HTMX, I then don't understand what you mean by "minimal to no JS".

> Only if you've only ever written React-style webpages

Again, I'm not saying anything about using React specifically.

> convoluted web framework

Yet another straw man.

ceteris is rarely paribus: JSON-based APIs have to make a choice between being general purpose, in which case a web app written against them may end up chatty with multiple requests per page, or they end up application specific, in which case they can be churney and a bad general purpose API.

I wrote an essay about this here:

https://htmx.org/essays/splitting-your-apis/

Also, producing JSON often involves reflection and can be more CPU intensive than straight templating (w/ fixed properly lookups) depending on your technology. Finally, the size delta between JSON and hypermedia is lower than most people think, particularly with compression:

https://github.com/1cg/html-json-size-comparison

in most real world systems i expect data store access to be the dominant latency issue

some people have had good success w/htmx from a performance perspective (2x+ speed, 1/2 memory consumption):

https://htmx.org/essays/a-real-world-react-to-htmx-port/

but of course it depends on your use case.

I think htmx would be excellent for an e-commerce site, which is mostly text and images and relatively simple, coarse-grained user interactions.

As I said, using HTMX isn't "minimal to no JS". I agree that HTMX can be fast - but that's not what we're talking about. Even in the video of converting a React app to HTMX you linked the presenter literally says - "no JavaScript, just HTMX" - but HTMX is written in guess what? Very dishonest.

i think it's reasonable to call htmx "minimal JS" in that it is relatively small, dependency free, can be used without a typical javascript build chain (npm, etc.) and frees the end user of writing javascript in many cases

the speaker is referring to them not needing to write javascript for a specific feature, which is true, but they do use scripting for some aspects of the application, which is perfectly acceptable in hypermedia-driven applications:

https://htmx.org/essays/hypermedia-friendly-scripting/

regardless, the wins are obvious

> call htmx "minimal JS"

"Minimal", maybe, "small to no", nay :D

> "Minimal", maybe, "small to no", nay :D

Considering the original phrase was 'minimal or no', I am glad that you now agree.

> you linked the presenter literally says - "no JavaScript, just HTMX" - but HTMX is written in guess what? Very dishonest.

It's difficult to take this seriously. Just wait until you find out most of Python is written in C! Very dishonest!

On the contrary, you are still wrong. HTMX is simply using JavaScript and looking at it, it isn't minimal (it's still 15 kB min+gzip).

> It's difficult to take this seriously. Just wait until you find out most of Python is written in C! Very dishonest!

Now I understand, you're just obtuse.

> Now I understand, you're just obtuse.

This seems like an exceedingly mean-spirited and unconstructive type of response to have to people who have been giving up their time trying to explain a different point of view to you. I would also gently point out the HN guidelines at this point.

I note you haven't responded to my more substantive reply here,[0] so I am unsure you saw it. I would encourage you to read it with less of a zero-sum 'I-win-you-lose' mentality. I won't be engaging with you further though.

[0] https://news.ycombinator.com/item?id=42386090

> Full-page reloads are, ceteris paribus, always slower than some JSON payload

That must explain why websites are so fast and responsive these days! /s

If you're wedded to the idea of dynamic reloads, which - imho - you ought not be, HTMX or Turbo are ways of achieving that without needing to write any JS. HTMX is designed to complete HTML as a hypermedia language, which it does using JS, but it itself does not require any additional JS to use. I'm sure the authors would dearly love it if HTMX's ideas were taken directly into HTML5, and they could scrap the JS library altogether. Its use of JS is an implementation detail borne of necessity.

If you're coming from SPAs and can't imagine websites working any other way, I highly recommend reading something like Hypermedia Systems (https://hypermedia.systems/). Come with an open mind, let it be your gateway drug. HTMX builds on a very old tradition of hypermedia, all the way back to Computer Lib/Dream Machines, through systems like HyperCard, to the actual, original definition of RESTfulness (that modern Ajax SPAs generally do not meet). It draws deep from the hacker ethos (you know, that thing that this website is about!).

Personally, I don't even think HTMX is all that necessary. What I feel like you're missing is that the overwhelming majority of websites are technically very simple, and their value to their users is in their contents, not in their stack. Did you notice the full page reload when you hit Reply on your comment, here on HN? Were you terribly put out by it? Would HN be an improved website were it full of spinners and Ajax? I would respectfully suggest it would not. It delivers amazing value running as a Lisp program on a machine under someone's desk.

> This seems like an exceedingly mean-spirited and unconstructive

It's not, it's precise.

Sorry you wasted time writing all this, because I don't care about hypermedia systems - it's not that it's bad technology, I simply don't want to write yet another awful templating language. But that's just an aside, because once again you're talking about something else. But okay, let's switch to debating HTMX. My point then still stands: you simply need JavaScript. Now instead of this useless arguing, go find/build some big e-commerce website with this hypermedia stuff (or truly with no JavaScript) and then we'll see.

https://www.amazon.com uses hypermedia for most navigation

they are pretty big

Wow, most navigation - what a feat! /s

ikr!

My bank website uses very old js and no react. Yet middle click doesn’t work (as well as back button). These problems have nothing to do with framework/library.

It’s what’s encouraged. The react way for links that’s easiest and used in tutorials is one that breaks middle click.

React (and similar frameworks) make the code much more maintainable. You basically define your state and how that state should look like. You don't manually change your UI, it just re-renders when your state changes.

Compare it with the nightmare of JQuery, where any line of code can affect any UI for whatever reason.

I understand what React does. My point is that what it does is unnecessary for the vast majority of websites, and I stand by this.

> Compare it with the nightmare of JQuery, where any line of code can affect any UI for whatever reason.

False dichotomy, and a somewhat strange one, given jQuery and React aren't even remotely aimed at solving the same problem?

You're free to stick to a functional paradigm in JS without requiring the overhead of React (and all the cruft that tends to pile up around React - build systems, compile times, masses of dependencies, the inevitable CVEs for those dependencies, etc.)

But more importantly, I'd respectfully note that you're pre-supposing that UI state rightly lives in JavaScript, which is a point of view already limited by framework-centric assumptions.

It's not unnecessary if you don't want to write and maintain a backend. Single page apps are easily statically hosted on a CDN. They don't run, they can't go down. They can use a server less platform API like Firebase and Supabase. They can be hosted for free at low traffic. Compare with rolling, monitoring and maintaining your own server, ssh-ing if it goes down, dealing with auth, containers, VMs etc.

I think it's time to question what "necessary" means for a product/service delivered online.

If it's unnecessary to use React et al, why is it necessary to complicate your application server with UI concerns so that it can build a big html UI string that is sent over the wire? And this only works for web browsers and no other clients?

Instead, it could be a simple API server that doesn't need to know about the UI at all.

There are obviously trade-offs in either direction, but to talk about necessary vs unnecessary doesn't seem to reflect that. There is nothing more necessary about one set of them over the other.

Simple problems call for simple solutions. The vast, overwhelming majority of webpages are simple problems, solved by a server serving HTML.

A 'simple API server' sounds lovely, but it's not getting your website to anybody without a frontend - and the complexity of the frontend offsets any savings made by simplifying the backend. I'd also very respectfully push back on this 'simple API server' business - serving /fie/fo/fum.json really isn't very much simpler than serving /fie/fo/fum.html; you have identical business logic, plus you've now got messy bi-directional JSON objects and hundreds of Ajax calls over unreliable end-user connections to contend with. It's the voluntary introduction of hundreds of unnecessary failure points. For most 'simple API servers' there's an alternative, and much simpler, much safer, much saner HTML server.

For that tiny number of websites that do require accompanying apps (mobile, etc), 97% of these could be solved with a thinly wrapped web-view. Those that cannot generally have special needs, and therefore cannot be solved by simply serving the same API endpoints across web and app anyway. If you're already separating your web and app APIs, plus now you've got a tangled web frontend to contend with, I'm really not seeing the benefits of reorienting your backend around APIs to begin with. A backend serving HTML to web, and a custom API to mobile is much more elegant and flexible (and doesn't actually require a soup of Javascript anywhere).

But we're already in the 3% of the 3% here - truly unusual applications. The vast, vast, vast majority of use cases were already solved by a server serving HTML.

> given jQuery and React aren't even remotely aimed at solving the same problem?

Both are used for rich UI experiences.

> Both are used for rich UI experiences.

So is Microsoft Frontpage, or Figma, or wgpu over wasm, or my friend John, the UI designer. Are these all directly comparable tools? Does John lose marks for not being downloadable over npm? (I can get him to compile TypeScript, but I can't seem to get him to compile into TypeScript)

I was talking to my classmate from x10, and he said to have shipped one page app with WP backend, React frontend in Azure VM :|

Incurred a bill of $800, and reached out to me. Gobsmacked!!

> The reason React is particularly disparaged, imho, is because the framework fashionistas have moved on to chase the new shiny thing, and everyone else has always hated all these frameworks to begin with, so there's no one left to defend this particular hot mess.

I think you're projecting here. Its fine not to like trends in tech, but tech will change whether you like it or not. The people who jump on every new thing and stress about having to learn it all will keep doing it. That doesn't mean that anyone else hated it all to begin with. That's a pretty weird assumption to make. Even this thread is full of people who enjoy using React. Meanwhile, React is pretty stable and boring if you ask me. Your nightmarish decade will be extended. I'll light a candle for you.

the vast majority static "sites" don't need to exist at all, how about that?

It's the apps with unique requirements that need to be coded, not some pages that present some info in some way that's slightly different, stylistically, and not standard at all.

> I don't think anyone complaints when NoSQL DB

A lot of us complained, very vocally, about how bad MongoDB was.

https://www.youtube.com/watch?v=b2F-DItXtZs

Yeah I agree with you and I have been around for a while. I do feel that there is a lot of elitism from those who hate React. The same as you get in any industry.

When I was doing audio engineering professionally you would find a bunch of engineers who had the same sort of mentality about outboard equipment. Specifically modern outboard which uses switching power supplies and the like in order to reduce power consumption and, ultimately, the cost of the gear.

You can’t help but feel a lot of people feel threatened by advances in technology as their ability to gatekeep diminishes with every iteration. In the audio example you’d no longer have to spend thousands of pounds on a Neve preamp to get a professional sound. You can buy a focusrite interface for a couple hundred and have decent sounding recordings.

Likewise with React/Vercel/NextJS. With those advancements a person (I don’t say dev as the docs make it so most people can fumble their way around) can deploy a simple website in a week or less depending on their personal ability to learn. As such those who made a living overcharging to make a simple site for a local business are seeing their income diminish.

Just my theory, anyway.

I think the class era is a decent, normal, boring and useful UI framework, however hooks are very difficult to use:

- How things actually work are very hidden and unintuitive

- Very easy to make mistakes, easy to write low performance UI

- High cognitive load, constantly thinking about how many times things run, what's in dependency arrays, what should go in useCallbacks and useEffect etc

- Overused, part of community sometimes encourage people to use React and some dependencies that's unnecessary for the project, only adding overhead and complexity

- Easy to mix business logic with UI logic

Yep. One thing I noticed that how intuitive it was to implement setInterval in class. However, in hooks, you probably need a guide for that.

https://overreacted.io/making-setinterval-declarative-with-r...

> easy to write low performance UI

I agree with this. Luckily there's some work being done on this - check out the new React Compiler[1]

> what's in dependency arrays, what should go in useCallbacks and useEffect

This lint plugin[2] from the react team helps quite a bit with this

[1] https://react.dev/learn/react-compiler [2] https://github.com/facebook/react/tree/main/packages/eslint-...

This is the whole thing right here in this comment.

I work with mobx at work which just does a better job of letting us focus on business logic. Components observe computed models directly, no prop drilling, no context. The `createTransformer` map function is the key to mapping dynamic collections to computed models, handles GC in cases where you want to go from computed model to another computed model so you don't manage a bunch of WeakMaps yourself.

The React maintainers and community buy into complexity too readily. Probably why SolidJS (which unlike mobx also provides the view layer) is gaining traction.

So glad to hear I'm not the only one doing this. I built and manage a very large and complex internal tool that we started building in 2019 before the full switch to functional components and Hooks happened. We use MobX and it has been great for us. Somewhat recently I was considering refactoring to use functional components just to be forward thinking. I was realizing that useEffect and other hooks could almost completely and entirely be avoided if you simply used MobX stores (like we already do), and local component scoped MobX stores where necessary. It keeps state management consistent throughout the app, and avoids the complexity of useEffect and other hooks. Like you said, components just observe. I started wondering why I didn't see this pattern more often out in the wild. It just seemed to be very straight forward.

What's surprising to me is that React 19 seems to be doubling down on hooks, adding more cognitive load by increasing the number of hooks you need to be aware of and their particular behaviors and requirements. Doing that instead of moving toward the more universal reactivity model that MobX, SolidJS and even frameworks like Svelte 5 are starting to adopt.

It's framework exhaustion: when you want to nail something to the wall, you don't want to have to spend hours figuring out what's the latest magic formula needed to get Hammer to work, especially when you had to do it so so so many times already and the new way isn't fundamentally improving things and concerns are dismissed.

That's exactly how React changes pushed by Vercel broke it and had the tipping point for the react fatigue we are discussing now

This is why I find this discussion so paradoxical. People, who are tired by the rapid change in Frontend-Dev, are surprisibgly eager to jump away from the most stable and backwards-compatible framework in this space, for which all the problems are known and mapped out.

I think React receives a lot of negative sentiment that is really directed more at SPAs in general.

SPA hate is mainly from backend developers who don't want to learn the intricacies of ui development. I get it, at least from their POV, but that doesn't make it justified.

SPAs might be a good idea even for simple / low traffic apps, if you don't want to write and maintain a backend. SPAs are easy to statically host on a CDN. They don't technically "run" 24/7, they can't "go down" unless the CDN does. They can use a serverless platform API like Firebase and Supabase. They can be hosted for free at low traffic. Compare with rolling, monitoring and maintaining your own server, ssh-ing if it goes down, dealing with auth, containers, VMs etc. If you want to prototype, it makes much more sense to write a SPA.

Your second paragraph is entirely developer work.

At no point do you change your focus to what works best for the user. Who is the user; what kind of devices does he use; what does he want to accomplish on your website; what does he need to accomplish that; etc.

Why do you think that choosing an SPA hurts my users? If I'm selling a service, it's in my best interest to give my users the best service possible; it's entirely possible to write accessible SPAs with great UX, as it's entirely possible to do that with server-rendered applications (and vice-versa). If I'm not selling a service and I'm prototyping or giving something away for free, I obviously tend to give more importance to my DX and time - if it means a worse experience for users because I'm cutting corners, so be it. They're still getting stuff for free.

Additionally, there is an entire class of web apps that I wouldn't have written if they weren't SPAs. The luxury of uploading some files for free to an industry-grade CDN and using a ready-made backend of which I'm not the admin on its free tier allows me to write stuff that I wouldn't have even started if I had to rent a machine and spawn a server somewhere, with all the admin / maintenance costs attached.

Of course there is a class of people who don't want to run Javascript on their devices. I understand that and I respect that. I might be one of them in certain cases. But unless I'm writing life-saving software or I'm running a monopoly (which is generally not the case), their importance in my audience will be evaluated on a cost/benefit basis.

As a solo developer, especially when you are building free stuff to scratch your itch, of course you are free to pick whatever tech works best for you. My complaint is that this kind of mindset extends beyond solo developers to dev teams in commercial companies, and even worse, in the public sector.

I tend to not understand that mindset as well: unless they're writing life saving software or they're running a de facto (like Google) or de jure (like .gov) monopoly(+), which means you're forced to use them even if you don't want, the technology they decide to use is entirely their choice. If they provide a worse experience, don't use their services / use an alternative that provides a better experience. If they provide a good experience at the cost of running Javascript on your device, you still have the choice of not using their service, or of making an exception for them and running their code. Someone can even write an alternative and market it to anti-SPA folks.

(+) If they are a monopoly, I would say that the problem are not SPAs, but the existence of monopolies itself.

> unless they're writing life saving software or ... you're forced to use them even if you don't want, the technology they decide to use is entirely their choice

The technology is always (or almost always?) their choice. However, if it is a public sector organisation, it owes it to the public to care about them, to be informed about devices they are using and the conditions they are using them in; and to strive to provide its services in the most accessible way. "How fast does a page load", "how fast does the page perform on users' devices once it's loaded", and "how gracefully it degrades under unfavorable conditions" should be important parts of the conversation.

Businesses in the private sector have fewer responsibilities to the public, and are primarily controlled by market forces; but still, it would probably benefit them to have similar considerations.

SPA hate is mainly because there are so many broken (navigation etc) SPAs that would have been much better as regular websites.

> Why do a lot of people here hate react so much?

It's not a pleasure to work with.

I know quite a few programming languages, ~20 years of software development career. And React is the worst tech.

Don't get me wrong, but I wrote a lot of React code at work, and used it for personal projects (for example: make210.com)

But every time you touch React you're getting this distinctive "meh" flavor that tells you - oh yea, baby, it's because you're dealing with React.

Probably because there's a lot of codebases out there that use react that are in a pretty bad state - that are a few versions behind and can't be updated easily due to breaking changes, have a mix of various old and new libraries and patterns for doing similar things, that don't use typescript, or that do but use `any` everywhere. It's a great ecosystem but it's evolved so much and there's my so much variety of ways to do things that it takes a lot of discipline to keep your codebase in good shape if your team is over a certain size.

Eeeeeasy, here is the whole journey for you:

0. People are coming to React after doing X years of that other thing, which was was not necessary related to user interfaces at all, was not procedural or reactive

1. People are super confused by something reactive and procedural, it feels too "complex" and something messy usually comes out of their fingertips

2. People think what if they sign for React, they automatically sign for react-router react-video-player react-redux react-custom-div-tag react-img and so on, bringing a ton of unnecessary dependencies to the project and crying out loud that this "whole React framework" is too complicated and nuanced

3. People don't bother going through official react handbook thoroughly and understanding that react is nothing more than a handful of hooks, which can solve every user interface problem in an effective way. Instead they watch 10-minute video on 2x speed which tells them to npm react-router, react-redux and react-custom-div-tag

4. People end up with a monster, which makes them cringe every time they are looking at it, and they can never ship it

5. People go and produce a big rant post to spread the hate with the title "How/Why I quit React and went back to Laravel, then finally shipped", sharing it here on HN

> People don't bother going through official react handbook thoroughly and understanding that react is nothing more than a handful of hooks

React is 10+ years old. Hooks are about five years old. There was react before hooks; and people who hate react don't always do so because they failed to learn the hooks api...

Also, the official react documentation is, predictably, a living document that keeps changing. I guarantee you that when react hooks were introduced in 2019, they were presented as a more convenient alternative to lifecycle methods, with a near-direct correspondence between the component lifecycle methods api and the hooks api. The useEffect hook was presented as a better and more powerful componentDidMount + componentDidUpdate combo. There was no talk of "you might not need an effect", which came out of several conference talks and culminated into a separate article in the docs. The first version of that "you might not need an effect" article appeared, according to github history, in 2022, three years after the early adopters had started using hooks including the useEffect. You were never supposed to update the state during render; now you are. You were always allowed to read component class properties during render; now with useRef, you aren't. And after all these years, react still seems to be in denial that sometimes you want some actions to happen only once over component's lifetime, upon its mounting; and you have to fight with the strongly encouraged StrictMode component for that privilege...

>There was react before hooks;

React pre and post 16.8 are two completely different libraries. I remember 2019, hooks we presented as a replacement to lifecycle methods and class-based components at all, not as alternative. The useEffect hook was presented as something which let's you split your code based on logic instead of component lifecycle, and few examples were there showing how the new effect concept better splits the async logic which was previously a solid mess inside the componentDidMount/Update.

>in 2019, they were presented as a more convenient alternative to lifecycle methods

Again, no one presented hooks as an alternative, it was strictly a replacement for class-based components which were obsoleted.

From the rest of it I see you have a very big problem with react, "you might not need an effect" article was written for folks like you. Update the state during render? what? if you need to read something during render you need to use State, and if you need a reference to a variable outside of React you use Ref; there is a clear way to make a side-effect happen only once over component's lifetime, which is to use Effect without dependencies. StrictMode component has no use other than debugging.

> React pre and post 16.8 are two completely different libraries.

The two apis still coexist within the same library.

> The useEffect hook was presented as something which let's you split your code based on logic instead of component lifecycle, and few examples were there showing how the new effect concept better splits the async logic which was previously a solid mess inside the componentDidMount/Update.

That is exactly what I mean by the word "alternative". As in, previously, you achieved certain results by calling componentDidMount/DidUpdate methods; now, in order to achieve same results, you would use the useEffect in a certain way.

> Update the state during render? what?

See "Adjusting some state when a prop changes" section of "You Might Not Need an Effect"

> if you need to read something during render you need to use State, and if you need a reference to a variable outside of React you use Ref

Sure. But what if during a render you want to check something in the DOM (geometry of a DOM node or something). I do not think that pre-2019 there were any guidelines that you mustn't. There weren't any such recommendations after the hooks were released either, when all we had to go by was the hooks api documentation in what now is the legacy documentation site [0]. The caution against doing this only appeared in the new react docs in 2022. My point here is that the docs change, and the patterns of usage of the library change, and what was considered ok once no longer is. This might be why some folks are complaining, even if they don't fit the "don't bother reading the docs" profile that you proposed.

> there is a clear way to make a side-effect happen only once over component's lifetime, which is to use Effect without dependencies. StrictMode component has no use other than debugging.

StrictMode unmounts and remounts every component causing every useEffect to fire at least twice. Which means a useEffect with an empty array of dependencies will execute twice, unlike in production build in which it will indeed execute just once. This makes the code in the development mode behave differently than in production mode. This also makes useEffect with an empty dependency array incapable of guaranteeing that it will execute only once.

As for the empty array of dependencies to emulate the previous componentDidMount method, this was indeed the original message in 2019. I am almost certain — though I can't find this online now — that Dan Abramov subsequently tweeted to not rely on the empty dependencies array as a guarantee that the useEffect only fires once per component's lifetime.

[0] - https://legacy.reactjs.org/docs/hooks-reference.html#useref

> As for the empty array of dependencies to emulate the previous componentDidMount method, this was indeed the original message in 2019. I am almost certain — though I can't find this online now — that Dan Abramov subsequently tweeted to not rely on the empty dependencies array as a guarantee that the useEffect only fires once per component's lifetime.

This is one of the big reasons why I personally dislike React and the community around it. They seem to envision at the start certain ways to do things, and push them to the point of being "this is how you do X". Then, after not very long at all, the old way is discovered to be bad and inefficient and buggy and hard to reason about or whatever, now do it this other way. Repeat three or four times until a new API is created or something.

This also means that going from project to project can feel very whiplash-inducing. The code you find is not even dependant on the version of React that's installed, but on how the community was feeling about the "best practices" around the time that particular project was started.

I remember when render props were a thing. Then I remember when they stopped being considered a thing and now the new thing to do was HOCs.

Things like React Router also being wildly different between versions, or at least v3 -> v4. I remember needing to find out how to achieve certain behaviour with v3, only to then try to find that the docs only existed for v4 (which was the newest at the time), and addons that helped me with my original problem also only existed for v4. (Then React Router was no longer the Best Thing, so let's all switch to Reach Router... then back to React Router when it was again considered the new hotness. I may have forgotten one or two others in there, I just stopped paying attention around that point.)

Another example is CSS scoping, which is a complete non-issue with vanilla Vue and Svelte. But in React land you have styled-components, emotion, styled-jsx, and who knows what else in which you don't write CSS, but JS that looks like CSS but not quite, enough to throw me off every single time.

The whole periodic shifting of opinions about useEffect from "this is your componentDidUpdate replacement" to "use a linter to warn you about the footguns that we can no longer fix, also use one of these hooks instead" is just one more thing that adds to the frustration of having to work with a React-based project.

I'm actually starting to wonder if Facebook isn't so much "writing" React, but "discovering" it. Much like how we didn't quite invent fire, and we had to figure out how to use it properly over many, many thousands of years.

I understand react is not easy for some, and this article is made for those who are finding a hard time with it. "Adjusting state when prop changes" only means your dataflow is a whack and your logic is a mess, and article explains it well. I have shipped quite a few React interfaces to production and never in my life I had to adjust the state when prop changes, this even sounds like nonsense and smells of bad react code. StrictMode mounts components twice specifically to find bugs where an effect is lacking a clean-up, good react UI means an effect can be ran 100 times with the same effect, and StrictMode helps to ensure that.

>Dan Abramov subsequently tweeted to not rely on the empty dependencies array as a guarantee that the useEffect only fires once per component's lifetime

It is very strange that you can't find online such a non-sensical tweet from Dan, because in case of effect there is no component, and it's lifetime is non-existent, there is only function, and it can be called, and it might call a side-effect or not in it's execution, depending on X or nothing. He was probably explaining that a useEffect is not equal to a lifecycle method componentDidMount – and empty dependencies mean actual side-effect of your render function without dependencies, which you still need to clean-up properly – not the shortcut to the old "component lifecycle". After 2019 the whole concept of "mounting" and "unmounting" the "component" was obsoleted and replaced with just a function and it's side-effect, which was a dramatic shift towards procedural and functional react which does work at scale from the class-based lifecycle concept which failed at scale. For some people it is harder to grasp something procedural and functional, especially if they are used to think inside some other concept or paradigm, they mess up their one-way data flow, immutability, function composition and end up in pain using react, and it can be hated for that, i agree.

I worked with AngularJS, Angular, Vue, Svelte and now React. I tried React time and again but found it to be too complicated and ineffective. I like Vue best. But lately I have completed a few React projects, because of a graphql package that's only available for React. The current state of React is pretty good IMHO. There are some things you need to get used to, but that's the case in every framework, when in Rome. The SPA side is great, it also ranks well. But the SSR side is awful. Absolute nightmare. And it's moving too fast. Vue is vue and code from v2 even works with v3. React will now stop being easily embeddable without a compilation step.

Awesome release.

I feel sorry though for someone getting into frontend dev now.

> is a new hook to order Actions inside of a Transition with access to the state of the action, and the pending state. It accepts a reducer that can call Actions, and the initial state used for first render. It also accepts an optional string that is used if the action is passed to a form action prop to support progressive enhancement in forms.

I’m pretty sure it’s a cool feature but, what a mouthful. Imagine you decided to start developing websites today, how do you even start?

EDIT: React is still an exceptional framework and this release is certainly an improvement.

My criticism is more FE development in general not just React.

Maybe not with react

My tip: you start by avoiding React altogether.

It sounds bad, but if you can, do oldschool SSR with HTMX or the like.

It's sooooo much better. I was paid to develop frontends in React for 4 years, I wrote my first website in 2005... I am currently migrating one client project from React to HMTX and it's sooooooooo incredibly much better.

There are less bugs, less footguns with wrongly applied hooks...

If you need to do CSR, use Solid or Vue, but don't do React.

If you have no say in it: good luck!

HTMX is certainly easier, but it's the worse if you want to actually learn FE

As someone who isn't a web developer, what do you mean by that?

HTMX abstracts functionality into pseudo-HTML attributes, allowing you to handle tasks like event binding and DOM/content manipulation that would typically require JavaScript. By using HTMX, you primarily focus on learning HTML and its attributes, with minimal need to learn JavaScript.

Not sure how to interpret what you're saying.

HTMX allows you to learn the very basics: the HTML which is almost verbatim turned into DOM which the browser renders. It's the FE. Everything else is layers upon layers of abstraction which ultimately compile down to the DOM representation of HTML.

...or to put it differently, quoting HTMX's author: using HTTP to transfer HTML? How queer!

Sounds like you don't know anything about FE except htmx...

He has a point though

Strong disagree, it would be a great way to learn vanilla html/CSS/js without kneecapping yourself.

How do you learn JS by using htmx exactly ?

Because htmx is limited in scope. And it's encouraged to use JS for the parts of your app that would benefit from it. But it's encouraged to do so in a way that fits with web standards. Eg https://dev.to/yawaramin/handling-form-errors-in-htmx-3ncg

Couldn't one say the same thing about using any framework that provides capabilities that otherwise would have to be learned?

Is discussing React vs. HTMX like comparing apples to oranges?

Maybe, but it may be reasonable to do that sometimes. What fruit should we bring to the picnic?

Or what goes well with milk.

Yes, my comment was not pedantic at all it is great to discuss intersections and symmetric differences. In this specific case. Just I thought that the intersection was small while the symmetric difference is much bigger.

The picnic example would be more like mixing them up though ;-)

Yes. Something HTMX evangelists always forget to mention is that HTMX is not a replacement for React -- HTMX + a backend is. This introduces a whole new layer of complexity; it's a total tradeoff. That is to say there are probably React apps that would be better as HTMX apps.

Also, does that currently mean that the backend will be Javascript?

In the browser we have no choice, but I prefer to prevent that accident from spreading to my servers.

No. Backend can be anything.

> HTMX is not a replacement for React -- HTMX + a backend is

Most React apps need a backend too.

Wouldn't the equivalent be more like server components in react? Or do people literally let their backend render presentational html (including tailwind css or whatever)? Like do htmlx people render html from database resultsets in their backends?

Why is it surprising that a backend returns HTML when it receives an HTTP request? That is the web

> Why is it surprising that a backend returns HTML when it receives an HTTP request? That is the web

We did that for a long time with Perl/PHP/ASP/JSP

I wonder why we stopped doing that? I'll just wait a few decades of your FE with this until you figure it out scnr

I don't understand what you are trying to say here. Serving HTML directly from the backend works wonderfully for almost all websites and web apps. The growing popularity of solutions like HTMX, Hotwire, and Phoenix LiveView is proof that React is not the panacea that was promised. Why prepare JSON on the backend, send it over the wire, and have the frontend transform that data into HTML when the backend could just send HTML in the first place?

> The growing popularity of solutions like HTMX, Hotwire, and Phoenix LiveView is proof that React is not the panacea that was promised.

Does it? To me, it seems more proof that software development trends are cyclical. It's also just not all that apparent that things like HTMX are all that popular. React is much more popular than any of them, and then JQuery remains even more popular than React, at least in terms of finding it on the web.

Working with XHR sending full HTML responses, it's pretty clear to me that there's some major tradeoffs to this approach. The payload sizes are larger and interactivity is dependent on round trips to the server. so you're increasing server load and are increasing payload sizes to save on client side processing.

If your views are data driven, then there's plenty of cases where you may want to have interactivity. filtering or sorting results, for example. So you click a column header, then you're sending another request to the server, asking for a new table with the newly sorted rows, it renders it, sends it back to the client, and then replaced the entirety of the table contents with the new contents. and then htmx does some magic to make it behave closer to native HTML (like enabling css transitions on replaced elements, for example).

Storing the state client side, you can perform a lot of these transformations without talking to the server again until you want to actually change data.

I'm all for sending plain html from the server. If your views are static and largely unchanging, then sure, by all means, send it over. You don't need a JSON response to render a blog post on the frontend. But as soon as you want any sort of interactivity in your forms or data views, then you probably don't want to make every interaction a round trip to the server and then you're back at having to think about state on the client, at which point objects in JS are just going to facilitate your needs better than html elements.

> If your views are data driven, then there's plenty of cases where you may want to have interactivity. filtering or sorting results

> Storing the state client side, you can perform a lot of these transformations without talking to the server again until you want to actually change data.

Only if you're only working with a tiny amount of data...

For example, say you have a dataset with 10k records. You're not going to want to send that all to the client so it can sort it locally. Much more efficient to send just the first 100 or whatever results. Then when the user clicks the sort button, ask the backend to re-sort it and give you the first 100 results again.

Bonus: those 100 results are already formatted as html table rows and htmx easily slots them right into the correct spot on the page.

It depends on the sort of data you're looking at, but definitely agree that you will need to hit the server sometimes, depending on the number of records you're looking at. Though even 10k row dataset can actually be handled quite easily with modest computers/phones. I'm not saying you should be doing that, but that would have more to do with usability than the client not being able to handle it.

But even with a modest 100 rows being retrieved, the payload size of fully rendered HTML is generally going to be substantially larger than JSON. These add up quickly when you're making round trip requests to the server for interactivity, especially if it's something like reordering tables.

This is a clear tradeoff and it's why we see trends like this oscillate between client-side and server-side.

I think React is seeing the downsides of being entirely client-side, which is why there's so much development into server side components. Conversely, things like HTMX are tackling problems of handling local state, client/server side caching, and well, payload sizes.

That's true but if you're concerned about payload sizes then 10k records is way too much to pre-send, and in general I think it's safer to depend on the server sending a known max size of html than it is to pre-send all the json every time.

Unless you're using tailwind or some other variation of inline styles, I don't think a typical formatted <tr> is going to be much bigger than a json record anyway. It might even be smaller if the json includes extra attributes that don't make it out to the html.

But I agree that if you know you have a tiny amount of data and you don't want to involve a server then it would be better to do the entire interaction client side. But nothing prevents you from plugging in a small client side lib (not react) and using server-side for everything you can.

> the payload size of fully rendered HTML is generally going to be substantially larger than JSON.

Substantially larger? No, I don't think so. Maybe slightly larger, but if you are compressing your responses (a best practice), there should not be a significant difference between them. And, while in a theoretical perfect world you send exactly the JSON needed for each response, in real-world conditions JSON APIs are quite often overfetching and making too many calls in the first place. Evidence: just look at any typical React-based webapp accessible to the public.

Meanwhile with htmx you can render and send the exact HTML you need for the response, and any overfetching is immediately obvious because it's all shown on the page.

> No, I don't think so. Maybe slightly larger, but if you are compressing your responses (a best practice), there should not be a significant difference between them.

Are we talking about this in an absolute sense? because an html payload whether you compress it or not is generally going to be larger. It obviously depends on what your html looks like, but even if you only are using minimal class names and aria properties, it's still going to be larger than JSON in almost all cases. As in conservatively 50% larger but realistically even more than that, just based on admittedly rudimentary experiments. That's after minification/gzipping and tabulated data is best case scenario for HTML with the small element names (tr, td).

Does that actually matter? Maybe, maybe not. As you said, plenty of real world cases of JSON APIs that are sending excessive data or making calls to the server too much.

...but with things like HTMX, you're either hitting the server or you're using client-side processing of some sort (at which point we're back at why aren't we using something that effectively handles other frontend problems?). I also still think there's rather large downsides to having part of your frontend being handled by the responses from the backend, even if you're using only using full stack developers.

See for yourself: https://github.com/1cg/html-json-size-comparison

False equivalence, and a disingenous one at that.

You can build single-page applications with React, you cannot with HTMX.

> You can build single-page applications with React, you cannot with HTMX.

Irrelevant to the conversation.

GP said:

HTMX is not a replacement for React -- HTMX + a backend is

So if you think that's not true because React can build SPAs and HTMX cannot, take it up with them (maybe you replied to the wrong comment?).

GP was from me :)

You stated: "Most React apps need a backend too."

But in reality this is irrelevant to the conversation, because the top post was asking if comparing HTMX to React is like apples to oranges, which it is, because both tools accomplish different things with completely different feature-sets.

A good example of this is the implementation of TodoMVC. [1] React's implementation can live completely in the browser, and even be stateful. [2] An implementation with HTMX requires a server to handle templating/rendering. [3]

[1] https://todomvc.com/

[2] https://github.com/tastejs/todomvc/tree/master/examples/reac...

[3] https://github.com/rajasegar/todomvc-htmx

the vast majority of (non-native) react applications require a back-end, at the very least to deliver them to users

htmx-powered applications can be local-only via service workers[1]

i think there is a sense in which htmx vs. react is apples to apples, in that in the common case they are used to build web applications that talk in some manner to a back-end system. On the other hand, it is true that react does require additional support code in order to do that communication.

Regardless of that latter fact, and the fact that htmx does not require a server, there is a large overlap in practical applications that might be built with either, so it is good to know the strengths and weaknesses of both for comparison.

[1] - https://developer.mozilla.org/en-US/docs/Web/API/Service_Wor...

> the vast majority of (non-native) react applications require a back-end, at the very least to deliver them to users

I mean, I guess if you consider me opening an index.html file in my browser requiring a backend in that my desktop operating system is the "backend server", then yes, but that's not what I was referring to. I don't think most folks would consider a CDN to serve static assets to mean "your React app requires a backend" in the traditional sense -- but that's a game of semantics.

> htmx-powered applications can be local-only via service workers

Do you have any examples of an HTMX app running completely client-side using service workers? Funny enough, the only example I found online ends up using Preact to render templates in the SW, but as a whole, this looks less ergonomic than simply using <insert JS library here> to build a SPA: https://joshi.monster/posts/serverless-htmx/

> there is a large overlap in practical applications that might be built with either, so it is good to know the strengths and weaknesses of both for comparison.

I could agree with this. I only care that people understand there are tradeoffs.

Correct. HTMX doesn’t deal with client-side state and updating UI in response to client-side interactions. React, on the other hand, is all about that stuff.

Still no good component or UI libraries for HTMX.

This is the sticking point for me. I get so many gains in Rails but I quickly sink into time-consuming component research/building. My eyes are always open for HTML/JS component libraries along the lines of react-aria.

I've had a great experience using Golang + HTMX + DaisyUI using the tailwind-cli-extra standalone tool, negating the requirement for npm at all.

Can webcomponents be trivially used with HTMX?

Like for example: https://shoelace.style/

Shoelace is great, but not robust. No data table, no date/time picker, no pagination, no sidebar.

Anything that can be loaded as a stylesheet or a script tag works great with htmx. These are not htmx-branded libraries... because they're just web libraries.

Right, but then you are glueing things together and mixing and trying to match CSS so they all play together. AirDatepicker here, tomselect there, datatables here, popper there. All of sudden you lost a lot of time trying to make things look like one cohesive unit, when you should be doing your app.

Meanwhile, I have v0 generate the whole skeleton for me, with composable reusable components, and just got the API done.

Interestingly I did something similar with Claude, asking it to generate tailwind/HTML components instead. And copy/pasting them as Thymeleaf fragments for a java/springboot + htmx project.

Yeah maybe, if you are using all these ready-made components. But with htmx...maybe you won't need to. Maybe you'll just end up using basic HTML widgets and the result will be simple and fast.

That is exactly the point of HTMX. Use your backend stack and sprinkle some hx tags.

Excuse me - do you understand what a component library is? It's a whole framework from element wrappers, styling, animations to pre-made pages, filtering and sorting functions on tables etc. Think MUI, Bootstrap or PrimeNG.

HTMX is just "replace this with response", you'll still have to write all the CSS classes, manually add them to all the elements, do animations yourself etc. I like HTMX, but I am tired of backend and hobby programmers shilling it at every opportunity. Try to write a reasonably complex website with it and give it your friend to maintain and improve. You'll understand why frontend frameworks exist. HTMX sends you back to the HTML-in-PHP ages with homebrew ORMs and what not, because there's no unified way of doing things.

Then something like DaisyUI/HyperUI + HTMX? And depending on the backend you can do components (eg: For Django there is django-cotton and others that help).

Yes, I could use those. But I gotta ask myself:

- will my client have problems finding someone that speaks Czech/Slovak and also knows DaisyUI/HyperUI/HTMX/Django? - are those techs gonna be maintained in 5 years? - what's the bus factor on the techs? Is it several people's project or a one (wo)man show?

All while there's React+<one of the big component libraries> right at your disposal...

Yes, there is a 'unified' way of doing things. In a single backend stack at least. And that way is...make a component library. Using your backend stack. It doesn't have to be HTML-in-PHP era. There are embedded HTML generation libraries for every mainstream language nowadays. You can just use whatever CSS you like and write any components you need. Eg I used Bulma, copy-pasted their HTML examples, and just wrapped them up as components.

If you are bemoaning the lack of prefab component libraries, well that's how backend development goes. Everybody and their dog has a backend stack and HTML generation system they like, and then eventually maybe some component libraries will emerge for the popular ones. That's the tradeoff for the freedom htmx gives you to work in any backend. You write some components yourself. Not the end of the world.

Your first paragraph highlights the issue perfectly. You mentioned Bulma—how many developers have even heard of it, let alone use it regularly? It’s even worse when one app uses Bulma because someone wanted to try it out, another uses Tailwind because it came along a year later, and then there’s a 10-year-old PHP project still stuck on Bootstrap 3.

With something like MUI, everything is where I expect it to be. That consistency lets me focus on learning the business logic, addressing critical bugs, and thus making meaningful contributions.

Sure, you use MUI, someone else uses Ant Design, yet another person uses Tailwind UI, where does it end?! Sheer insanity. So of course, this is a problem only when it happens in the server-driven approach, but not in the client-driven approach :shrug:

Weeeeell debating whether to use one of those 3 UI component libraries you mentioned is IMO pointless, you are gonna be fine with any of them. I was thinking more along the lines of Django vs Rails vs ASP.NET and someone suddenly coming in and yelling "LET'S DO CLOJURE".

In that case someone is gonna come in and yell 'LET'S DO ELM WITH ELM-UI'? No?

True :D

Probably there will never be, that's like saying "Still no good component or UI libraries for HTML".

HTMX philosophy is to be timeless and agnostic as HTML is, is just a nice extension on top.

The problem I have with many of such advice: 1) what do you precisely mean and 2) why do you think so.

Do you mean the whole field, so from B2B SPA apps to personal blogs? "If you want to replace jquery, use Vue!" would be more helpful to understand.

The problem is that we don´t know if the advice comes from a "bootcamper" that has only learned Javascript. You know, some people manage to build low-interaction sites that will render a blank page when Javascript is disabled.

The "why" is also of interest to see if the advice is applicable. If not react, then why not preact for instance?

My main dislike for React is that I'm constantly learning React, its intricacies and idiosyncracies.

Disproportionate amount of energy I would rather spend learning JavaScript, something that would last.

Using React since 2013. Each release is an excitement, until I realise some chunk of concepts which altogether took months to fully grasp, are gone. Some even needed to be unlearned.

A lot of abstractions.

React doesn't make you a better developer, it makes you a better React developer.

I don't feel that with Vue. I don't feel that with most libraries I use.

> React doesn't make you a better developer, it makes you a better React developer.

React's pure component functional style translates really well to nearly every other type of software development.

It doesn't necessarily mean that React does it right. When building React apps, developers spend too much time on designing architecture for many things that should have been taken care of by the tools they are using. The more I am in web development, be it backend or frontend, the more I'm disappointed that declarative programming is still not a thing. One too many hours wasted on reducing boilerplate, replacing big boilerplate with smaller boilerplate, optimizing boilerplate and writing that boilerplate. While still being far from perfect, other frameworks like Vue and Svelte do great job at making the developer write less boilerplate and more business logic.

I agree with that, that's not so specific to react. So I kept it to narrating the main problem I and others have with react, which is that feeling that I keep learning the framework for a variety of reasons that I believe are frustrating developers, those who want to be more than react developers.

The non declarative aspect is a problem though, with v19 it now means unbelievably large PRs and time spent to refactor will take place for migrators. Declarative would at least reduce reduce that pain.

Practically every frontend framework uses components. The problem with React is that so many of its abstractions are leaky and forces a lot of accidental complexity on the developer.

Which abstractions are leaky? State is complex. There’s not really a way to get around that.

Dependency arrays are leaky.

How do they leak? Are they even an abstraction?

One example where it's leaky is when you want to memoize something, and now you need to memoize all its dependencies, recursively, and you end up with a 30 file PR.

I say this as a big fan of React, and I'm hoping the compiler turns out a success.

Well, they're part of the effects abstraction. And they are leaking because you have to manually track them. You are already using the dependency variables inside the hook function. And now you need to duplicate them into an array and keep the array updated as your effect hook changes. This is leaky.

There are better deaigned frameworks than React. Solid for example, the api surface area is smaller, there are less things to learn and less chance for bugs.

If I look at an article like this, I have the impression that Solid is in the early process of discovering their own gotchas:

https://vladislav-lipatov.medium.com/solidjs-pain-points-and...

It's nowhere close to pure, in the FP sense. Everything in React is an act around side effects of rendering.

So it's gotta be something else that makes it so popular.

Hooks do a nice job of encapsulating the impurity. Not the only way to do it, but it’s pretty slick.

React keeps changing its abstractions, idioms and best-practices every 2 years. The bootcamps and consultancies LOVE it - it keeps the churn going and the $$ coming in.

> React doesn't make you a better developer, it makes you a better React developer.

React's goal isn't to make you a better developer though. It's goal is to make it easier to build non trivial, stateful applications

which you can also do easily without react and 16Gb node_modules folder :)

Developers' goal is to become better developers.

I think most people arguing against react are against "advanced" ui libs at all. simple dom + a thin porcelain like htmx does help you finish most work duties without having to add a whole paradigme over.

And anecdotally, if your team is not ready/willing to dig in react, all its benefits will fail to materialize, you'll have a bunch of patched up libs and components trying to do what htmx or similar seem to offer (async actions over REST) for just a few lines in your html template.

No bootcamp, university, albeit only a BSc, because I didn't feel like academia afterwards with a full time job and now I've moved on.

9 years of professional experience.

Having worked and paid to do so with Java, Scala, Kotlin, Python, JavaScript, Typescript, Python

Been working with Rust since 2015, have prior experience with C++, had to work with C, Haskell and logic programming (not prolog) at University.

Also did C#, Golang, Lua, Zig and many more.

Does that give more authority to my statement? I sincerely hope not!

Why is this attitude so pervasive? It's akin to writing backend and saying you should avoid Postgres altogether and use text files saved on the hard disk.

How are these two scenarios comparable?

Because both are ubiquitous to the point they basically dominate a large part of a usecase's toolspace.

Sql syntax does not change every month

JSX syntax doesn't change every month either. React itself, as a library, has a great deal of backwards compatibility.

What does churn is the tooling (e.g. abandoning Webpack for Vite). But the actual API and syntax has remained virtually unchanged. You can still write and use class components today. Hooks themselves are nearly 7 years old at this point, with no sign of changing. You are not required to use "server components" or any of the new features in React.

Meanwhile people in this thread recommend "simple" alternatives like Vue that produce breaking changes so massive it splits their ecosystem in half.

I stopped writing React for probably 2 years and now the whole framework is different and I have to relearn the entire thing. Defining a component is completely changed, changing state is completely changed, and the component lifecycle is completely replaced and it feels like the complexity of the framework has gone through the roof. At least for me this is the type of churn that makes me not want to do it anymore.

React is 11 years old (older now than jQuery was when React was first released).

For whatever reason, backend devs can be incredibly precious about their tech stack and rightly or wrongly believe that frontend devs make "silly" choices by not using their preferred stack.

It's a form of technical smugness that pervades this site for any frontend JS thread.

You rarely see frontend devs criticise backend devs on their tech stack.

No it's because I have to maintain the frontend stack and it rots faster than raspberries left on the counter. If you write your frontend like it's 2008 it will continue to function unmodified until the heat death of the universe. And you wouldn't believe how many apps fit into that feature-set.

If you use just React I'll support you until the end of time but haven't seen a shop yet that does. I'm not saying use HTMX, if you have the choice go with just React over HTMX because it's still in flux.

Just React << HTMX < React with Friends.

It's the advice from POODR that's stuck with me forever, an objects dependencies should change less often than the object itself.

There you go, claiming another silly choice by frontend for using something built in the last 15 years will rot.

It's just not true in my experience.

It's not a silly choice, it's a trade-off. One which becomes frustrating the moment the code isn't being actively developed anymore. People choose to use unstable technology all the time for various reasons, it's valid for evergreen codebases where you're continuously updating deps. I argue it's bad if you expect your codebase to be "done."

An unmodified frontend will also function the same exact way until the heat death of the universe.

This isn't really much of an argument. The defining characteristic of a non-rotting codebase is one in which you can update your dependencies and language version every six months or on CVEs with only minor changes.

If you think rotting sounds too negative how about "maintenance unfriendly."

Your argument was about unmodified code, not mine.

If you only want minor changes, don’t install new major versions.

How does that work in an ecosystem which is constantly releasing new major versions and not backporting security fixes to old majors?

For one big reason that complex JS interfaces in the browser aren't needed nearly as much as they are used. Probably only about 10% of the time people reach for React. While databases solve a predictable problem (up to a certain scale).

FE tooling is never a one-size fits all thing like Postgres, but people want it to be (god help you if you have 2 different FE libraries that serve different usecases, even though 90% of the time you just need simple tooltips or a multi-select box that play nice with static server HTML) and the cost is giant, unmanageable, extremely expensive piles of JS where the entire frontend is pushed inside of it.

Definitely agree that a good database solves far more problems than it introduces.

I think the web technology and the kits that sit on it are rather obtuse because they really are swimming against the tide. I commented about VB a few weeks ago and how much better the paradigm was some 30 years ago. But that was a purpose-built tool for programming a purpose-built GUI API. React et al. are still contending with turning typesetting into general purpose software. Despite that, react does a pretty good job.

It's also about know-how. I can go get a programmer literally anywhere that can built something with react, so even problems that can be solved without are going to be solved with it.

No complaints from me, really. Everything is a little excessive. I just came across an app to order ice. I can't imagine that's really making anyone's life easier, except for maybe its developer.

I have 3 complementing theories:

1. Beyond self-learning, there's two types of education. Formal, college education that delves deep to both the CPU level and mathematical proofs of correctness, and coding bootcamps which teach how to do things, but little about how things work.

Frontend isn't taught in formal college education, so there's a big void in industry knowledge. Some people learn about compilers, interpreters, have used GDB and implemented malloc for school, but they aren't the ones doing frontend. Others are doing frontend but never think about memory usage, closure scopes, or garbage collection.

This leads to bad frontend code, that misuses resources.

2. JavaScript long had fame for being a "toy" or "joke" language. I noticed the tide slowly change by the mid 2010s— that's not that long ago.

Proportionally and compared to other technologies, how many engineers have had time to develop long careers, learn from mistakes, and become that serious, dress-shirt wearing, super-senior engineer sitting at the back of the room making sure young developers don't get too unhinged? This proportion is probably especially stark if you consider just how in-demand web development is.

This leads to bad frontend code, that misuses resources.

3. Finally, with the two above in mind, re-writes. Unexperienced teams are the first to opt for re-writes. It's a story as old as time; "we don't know how to fix A, so let's instead build a brand new thing B, which works differently to A and thus won't have its problems".

Re-writes always go well at first, because the fresh codebase will be smaller, faster, nicer and because everyone is especially cognisant of the problems A had, which are very much not present in B since it works differently.

Eventually of course, B grows bigger, and gets permanent hot-fixes, its requirements change, and bugs start to surface that nobody bothers understanding. A is also far enough in the past that nobody is thing about the problems A had anymore, and has more mind-space to notice the problems that are unique to B.

But before that happens, you get this sort of comments.

One of the major mistakes that are made in re-writes is that the developers writing the new code are not always the ones who created the original code. They see complexity, but don't know if it is accidental complexity ("tech debt"), or necessary complexity.

One example from my own experience was a team that inherited a service that had already seen a major rewrite/refactoring to be prepared for requirements that the old team knew with certainty was coming. The new team created a new service that barely covered the needs that the company had at the time, and claimed that the new architecture was flexible to cover any future need (without actually investigating the needs that were already known). When they were tasked with supporting the new requirements, the end result was more complicated and less capable than the old service.

indeed you should avoid postgres if all you need is saving files on a disk. that's exactly the point. people reach for complex client side frameworks when all they need is to render some markup.

If postgres were worse than the alternatives I wouldn't use it.

And React is worse than the alternatives. All it has going for it is the huge ecosystem.

Just use Vue lol.

I've avoided React as much as possible. Dabbled (positive experiences) with Vue. What's your recommendation w.r.t. "Components"? I've tried doing web-components from scratch (frameworkless) but nested web components have nasty gotchas.

eg: <todo-list><%for...><todo-item .../></for%></todo-list>

I've poked at `lit`, read through `htmx`, but really what I want is "custom elements" (including visual styling) on the front-end that I can map back to JSON on the backend.

The CSS side nudges towards tailwind (or similar), and modern (raw) CSS has undergone so many feature extensions and new capabilities, it's tough to find a good "modern" guide for building with it.

It just feels like there's a missing piece in-between: `let contact = new LdapContact(...)` and `<contact-summary .../> ; <contact-detail .../> ; <contact-search-result .../>`.

Vue has come closest, and setting aside a super-complicated "WebApp/SPA" with a ton of interactivity... what's a comfortable, modern, low-ceremony way to get to that?

React/NextJS user here. I can easily make a case that you should avoid HTMX and go with Elixir LiveView because it’s sooooooo incredibly much better. What you’re not understanding is that “better” is contextual.

> My tip: you start by avoiding React altogether.

Avoiding the most popular front-end tech (or any tech) is a good tip for those who want to play Finding a Job in hard mode.

on a flip side, you have an opening for a high 6-figure front end position with an amazing team doing amazing shit - and you see CVs of “React Developers” and you go “uf tough luck, these gals/guys would be PERFECT here except of course we don’t use React” (speaking from personal experiences…)

I'm saying knowledge of React is a good to have, even when you prefer something else. In the sense, avoiding it is not a good idea - know the enemy.

In my experience React (only) devs make very shitty everything-else devs, because they try to squeeze the broken React patterns in places where they don't make sense and don't work. And since every single React codebase does its own thing, with its own set of libraries and state management and routing and even CSS management, 2 React devs will try squeezing 2 completely different broken solutions into a Vue codebase where they could've accomplished the same thing with a single `v-model` in a single 20-line component.

yup, exactly same experience here...

> If you need to do CSR, use Solid or Vue, but don't do React.

Easier said than done.

There're still many high quality libs for React that are not available for vanilla JS or other frameworks. E.g. https://reactflow.dev/ (yes, they have a Svelte version, but not as feature rich).

Vue comes very close, though.

Just start.

I don’t get how people get so paralyzed of making the most optimal decisions all the time that they end up doing nothing or procrastinating by convincing themselves they need to learn some other basic framework instead.

It helps to know that the basic tutorials still apply. You don't need these advanced features. Certainly not for basic projects, and possibly not ever. After all, people successfully wrote React apps without it.

One mark of a framework with a future is that it supports its past. A framework with a lot of breaking changes is one that is not mature, and may never be mature.

Even with the substantial shift in React from classes to functions and hooks, old code still works. You probably don't want to start writing class-based React, so you want a tutorial written in the last 5 years, but those are hardly new and certainly not specific to React 19.

hooks was the beginning of the end imho. it replaced nicely encapsulated OO, with unmaintainable functional cruft. runtime footprint of react has vastly increased, and code has gotten harder to debug.

When I wanted to make a SPA for a project, I also wanted to avoid analysis paralysis. So I looked at Vue and React.

Getting started with Vue was so much easier, I never looked back to React.

Do you ever wonder about the road not taken?

Let me rephrase. I never looked back at React as the default option for any greenfield project.

I still have to deal with React codebases, and every time I do I dread it.

Life is a never ending series of forking roads not taken, you take some and you leave others unexplored, there's an near infinite amount of things to learn and we only have so much time to learn them. It's not feasible to worry about it.

I presume most people learn to deal with that when they're like, twelve, or something. Otherwise you just live with constant regret and FOMO.

The rest of react still works. It’s not like it’s a primary entry point or required. Looks like an advanced feature.

> I feel sorry though for someone getting into frontend dev now.

Yeah. For the last decade or so frontend has felt like standing on shifting sands.

In part it's the ecosystem and entangled deps but also because JS frameworks are really still figuring it out. A couple of years ago I was hoping we'd reach some sort of stable plateau but it just keeps going...

"the DOM is slow we need a VDOM!"

"the VDOM wasn't such a good idea... signals with fine-grained reactivity is really the solution for DOM udpates!"

"oh wait but we now need a compiler!"

"oh wait there's too much JS now... we better move stuff to the server and do SSR with full page hydration!"

"maybe full page hydration wasn't such a good idea... we now need islands!"

Etc.

Don't get me wrong, each of these steps makes total sense. But we're getting into this uber complex solution that involves so much stuff across the whole stack... and it's not even clear to me that running JS in our servers was such a good idea to begin with.

SSR was essential and the motivation was stuff like SEO. For people who care that was uncompromisable. For people who only care about SPA the conversation has been frozen for almost a decade; almost all the innovative fury has been on the SSR/MPA/hybrid side.

> For people who only care about SPA the conversation has been frozen for almost a decade

I don't know, there's been a lot of stuff since 2014.

In client-side React we've seen stuff like react-query, mobx, etc which weren't there a decade ago. Back in 2014 everyone was still using redux (ugh).

Or Svelte and SolidJS which have brought massive improvements in performance and reducing JS with signals, compiler, etc.

FWIW, both Redux and Mobx were invented in 2015.

Thanks for the clarification. It was a long time ago!

And if you're still using React with Redux you're doing just fine for SPA development, as in you're actually still modern and not merely fine. React Query is the only new development you listed that SPA professionals may want to think about, and even then only a little. It's a life convenience tool for making async calls to foreign APIs easier (for internal APIs you probably want RPC-like experiences with type and client generation).

Meanwhile MPA people are redefining the boundaries of work by marrying the frontend to the backend. They are doing some big re-architecture type stuff, and it is very interesting, far more interesting than React Query being the better Axios. If I had to lead with an argument about interesting changes on the SPA side, I would've lead with the ongoing improvements to CRDT libraries. It's niche but there really isn't much of a revolution going on otherwise on the SPA side.

> as in you're actually still modern and not merely fine

Not sure what you mean by "fine".

There's nothing modern about client-side React. To get some perspective consider that more time has passed since today to the release of React in 2013 than from React to jQuery in 2007.

> To get some perspective consider that more time has passed since today to the release of React in 2013 than from React to jQuery in 2007.

Oh my God! That just sent me into a mid life existential crisis for a moment.

Quite a good number of React apps are offline-first. I build offline-first software for emergency services. That means one should maximize app usefulness despite temporary disconnection to peers or server.

The ROI proposition of MPA/hybrid becomes really meh.

"screw it, lets compile it into a WASM blob that renders it all on a canvas"

That'd be unironically simpler than the current state of things.

Nah. There's so much stuff that would need to be implemented.

Just think of all the functionality related to text that browsers give you in HTML: styles, spellchecking, selection, accessibility features, etc. And that's just text.

Most people would just use the most popular framework that did all that for them, while the remainder would complain loudly about the shortcomings of that framework, and we’d be right back where we started.

It would be significantly worse, unless there is a very good reason for that (e.g. some app like Photoshop could work that way).

You lose any form of accessibility, inspectability, AdBlocking won't work, in many cases even mouse select/copy-paste won't work..

I didn't say it'd be better. Just it would be simpler.

No need to learn html, css, JavaScript, bundlers, etc, etc.

You will inadvertently reinvent the browser inside a browser but worse.

Seriously, I think there is a possible future where a macOS-like reactive UI toolkit is developed that compiles and deploys to the web via WASM. Maybe even a compiler that takes something like Xcode's Interface Builder's .nib files (and associated code). Microsoft tried something like that with Blazor WebAssembly. It works really well, but I think a fully data-reactive model like Apple's could be even more successful when applied to web apps.

Whatever the case, I think very few companies have reached the excellence of native macOS interface design in the context of a web app. Figma is a lone exception; for anyone else to achieve what they have, they'd have to reinvent the wheel yet again in so many small ways. (Have you noticed in Figma how moving the mouse down and to the right diagonally from a menu item to its associated submenu does not cause the menu item and submenu to be deselected? That detail, and so many others, are straight-up macOS-inspired UI craftsmanship.)

We need a reusable toolkit that lets ordinary developers achieve Figma-level UI excellence in web apps.

Dreamweaver existed even earlier. I hope something like what you mention (flutter) does not become popular because of accessibility.

> Maybe even a compiler that takes something like Xcode's Interface Builder's .nib files

Please never let this happen.

I don't agree but if you're looking for something that renderers everything in a canvas it's called Flutter https://flutter.dev/, and strangely it's made by Google, even though Flutter's success means the end of scraping the web for search.

Parent speaks the truth.

The amount of fiddling and tweaking required for web UI feels substantially higher than any GUI toolkit I’ve ever used. And I’ve used a lot of them!

I suspect this isn’t seen as a problem because Vite and friends do an amazing job of hot reload. But it is still a helluva brick wall to shipping things.

A11y enters the chat with their buddy "compliance"

It's hard not to use Next.js and React due to the insane amount of building blocks to built on top of. Not to mention design libraries and component libraries, such as Radix and shadcn. If you don't have the design skills, or the time, nothing beats that.

Have you tried using v0 to generate a layout and a barebones application? It saves so much time. No more hunting for templates/themes, no more mocking.

I went down this path very recently as a React newbie, for the exact reasons you stated. It looked like I'd be able to save a bunch of time, and I'm sure I did.

But I also _spent_ a bunch of time as soon as I needed something slightly different to OOTB (or sometimes just wanted to understand how a thing worked better). At that point I ended up digging through Radix code, React library documentation where there were frequently multiple ways of doing the same thing and I had no idea which was "best". I had to delve into some of the more complex (to me, as a newbie) patterns like forwardRef. And this was all for a very trivial site/app that needed some form interactions.

My takeaway at the end was, I'd learnt a bunch of new stuff, which was the point, but that was all workarounds for dealing with the complexities introduced by the tools which were meant to simplyfy my life.

Perhaps for large projects with multiple devs, they bring efficiencies of scale. I think for my next solo project I'm trying Rails or Django with htmx.

I understand that sentiment, although in an opposite away: for large projects with multiple devs, I'd prefer something like Rails or Django, precisely because they are battle-tested with a lot of official documentation. Things are done in one specific way and the team can just agree to whatever the framework recommends. And there are clear guidelines for pretty much everything.

However, in solo projects, I want to spin something up quickly. I don't want to spend my scarce weekend time designing yet another date time picker. Or having to write hackish CSS to try and make whatever time picker library I chose to match the CSS of Bootstrap. And then everything falls apart because some other library does not fit into the overall style (looking at you DataTables). In React land, I don't have to worry about this. I just throw components together, link it to my API where the show real is, and call it a day.

UIs are just UIs. They should be plug and play. So much time is wasted redesining data grids and data tables and pickers and filters for the 1000th time.

> I feel sorry though for someone getting into frontend dev now.

I most certainly don’t.

As someone who has mostly done low level coding and used to generally dislike my few interactions with web frontend development, I was extremely surprised when I picked up React a few years ago for a personal project.

The whole thing feels like actual proper development. What a breath of fresh air compared to the situation before.

> personal project

In professional projects with teams of developers contributing and PMs wanting feature flags, tracing, complex behavioral logic, it gets crazy.

I’d say even more so for professional projects you’re better off with React.

Been there and done that with and without. Junior (and Senior) devs fundamentally don’t read the docs. That and requirements churn are the problems.

Given that, it ends up so much better with React.

How did you learn? I'm an embedded dev and when I tried to learn basic web dev, all the resources were a mess of importing unnecessary libraries

With the official doc. The react doc is well written. You have a quick start section, a good tutorial and the API is fully covered.

I liked redux, but its vocabulary was the last thing core React should have adopted from it.

I maintain Redux, and I don't think Redux inspired this particular term usage (which came from the "Flux Architecture" pattern.)

As far as I know this usage ultimately derives from HTML `<form action={}>`.

Ah, different “action”, then? The presence of “reducer” had me assuming the action was also analogous.

FWIW I liked Redux enough that I once half-reimplemented it for Brightscript so the UI guys would have something familiar to work with when they had to touch Roku apps. I always taught Redux initially using different terminology, though, because I found that most of my time learning it (which, mercifully, still wasn’t that long, because it’s small and pretty sensible) was figuring out the vocabulary (“do… do they just mean ‘event’? Well if so surely they’d write ‘event’, so I must be wrong…”)

Hmm, that is a good point that `useActionState` accepts a reducer-like function (although I think it's async in this case?).

And yeah, half of Redux's terminology is simply because the existing Flux Architecture libraries from the prior year all used those terms. There were several debates in the issues about whether to name them "actions", "events", or something else, and the conclusion was "let's just stick with the existing Flux terminology":

- https://github.com/reduxjs/redux/issues/891#issuecomment-147...

FWIW, as I've revamped the Redux docs over the years, I have specifically made sure we describe the "actions === events" aspect:

- https://redux.js.org/style-guide/#model-actions-as-events-no...

- https://redux.js.org/tutorials/essentials/part-1-overview-co...

That’s great—my experience is years out of date, so my gripes may well be obsolete :-)

Thanks for the work on a project that I got good use out of, and happen to personally like more than I do most software.

Redux is the most over-engineered invention/perception in the history of software development.

I love website design for personal projects, but it is the least attractive of all development fields due to this complexity. I'm sure some people like it, but I found website dev a lot more fun 20 years ago...

Same with backend dev imho.

What? You don't agree, or are you angry at me for reminding you?

> Imagine you decided to start developing websites today, how do you even start?

You learn vanilla HTML/CSS/JS (I think Mozilla has good courses on those). After making a few websites that way, you learn Svelte and you live happily ever after.

Avoid React, NextJS at all cost especially since many of these new frameworks actively try to screw over new developers with PaaS.

I get NextJS but how does React itself try to screw devs with PaaS?

The Getting Started docs recommend against using vanilla React and nudge you towards NextJS and similar frameworks because you're gonna end up needing that stuff eventually https://react.dev/learn/start-a-new-react-project

So new projects have to actively not follow the recommended approach in the docs if they want to use vanilla React.

It's funny to think back now that JSX had such a strong negative reaction on launch. That's the one thing from React I love - having a declarative and strongly typed markup for HTML in my JS/TS code.

I think React peaked with hooks around 2019. I write most of my front-end with the smallest 'React-like' library possible (Preact) using only functional components, and with as little 'magic' from useEffect etc. as possible.

I like to stay close to 'raw' HTML/CSS/JS when possible, but the web platform APIs are just a little to clunky and verbose for me without the JSX abstraction.

You can use JSX syntax without using React. You can stay close to raw HTML/CSS/JS too. See here: https://github.com/wisercoder/uibuilder And here's a complete app example: https://github.com/wisercoder/eureka/tree/master/webapp/Clie...

I learn Svelte has a template language.

It is not very different from mustache, or other older template engines and it's really needed because there is no conditional html rendering, loops etc in the HTML spec itself, I like that more than how Vue does.

But otherwise, Svelte has a very low surface, everything else is just standard vanilla JS/Html, also one thing that Svelte has over other frameworks is that vanilla JS libraries just work, no need for a wrapper any.

Some devs point at Svelte and say, “not many libraries, it can’t be very good!” What they don’t realize is it doesn’t need a cottage industry of tiny adapter libraries, JS stuff works fine.

I'd hoped this release would have added a compiler and drastically simplified the syntax to something close to a modern framework. I know React is eventually going to do that, but it feels like React has been drowning in overly complex DX for at least the last 5 years.

The React Compiler is currently in beta:

https://react.dev/blog/2024/10/21/react-compiler-beta-releas...

That said, it doesn't change the APIs included in React itself, or the overall usage patterns. Ultimately it rewrites your component code to add a lot of conditional comparisons to see if props or state values changed, and uses that to trigger React's existing rendering optimization behaviors.

Long-term, I expect that the React Compiler _will_ result in a significant change in the DX for using React. React's default behavior has always been "re-render recursively regardless of props changes" [0], but people often assume it's "only re-render the child if the props changed". React Compiler actually makes flips React's default behavior to make that a reality.

[0] https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...

Yeah I'm getting kubernetes vibes from all the abstractions mentioned in a single sentence. I'm sure the abstractions are needed and/or powerful to accomplish React's goals, but it's just a bunch of extra stuff added to the learning curve which makes it harder for outsiders to understand and contribute to the code.

It's insane that the total complexity of the ecosystem has only grown in the past decade, despite the amount of time and tools trying to contain it. I have a hard time seeing that expectations rose accordingly alongside this. I'm half-convinced it is tolerated as a collective subconscious gatekeeping/total employment mechanism.

My response has been to avoid SPAs as much as possible. YAGNI! Just use boring forms and server responses. Some component libraries can be server-rendered, minimizing the JS payload while giving you some primitives to build off of. Components are a really nice abstraction even in a pure server context. You can contain the goopy Tailwind code a bit.

It's not all bad. Astro seems pretty nice so far!

"My criticism is more FE development in general not just React"

No, it is not. Your criticism is very specific to React.

Why is state management so complicate in React?

React is the only major FE lib/framework that basically re-renders each (affected) component and sub-tree on update cycles.

The model they've chosen is the opposite of what one would intuit and because of this model, it is necessary to manage state a bit differently in React compared to Vue or Svelte.

I, for one, would intuit that exact process flow. If my UI is a function of my state, I expect state changes to re-render my UI. How else would you handle it, except for imperatively?

This is genuine question; I've not used Vue or Svelte.

It re-invokes the entire render function of the component so that the state in the component (meaning not externalized to a hook or declared outside of the component) is effectively wiped out.

Vue and Svelte don't work that way.

In a Vue SFC, this is fine:

    <script setup>
    let counter = 0           <-- This code only runs once
    
    watch (someRef, () => {   <-- Only this code runs when someRef changes
      counter++
      console.log(counter)
    })

    const fn = () => { ... }  <-- Normal functions are stable
    function fn2 () { ... }   <-- Stable as well
    </script>

Basically, it behaves like you would expect normal JS closures to behave because the `setup` function is invoked only once. When `someRef` changes, only the `watch` function is executed (this is also why Vue and Svelte perform better because they can execute a smaller subset of code on updates).

JS and DOM itself work with the same conceptual model, right?

    <button onclick="handler()">...</button>

    <script>
    let counter = 0           <-- Allocated once

    function handler() { }    <-- Only this code is executed

    const fn = () => { ... }  <-- Allocated once
    </script>

In React, this (obviously trivial example) doesn't work:

   export const App = () => {
     let counter = 0          <-- New allocation on each render

     const fn = () => { ... } <-- New allocation on each render

     // ...
   }

Because the entire `App()` function gets invoked again. So you have to use hooks to move state out of the path of the component function because the entire component function is re-invoked. Imagine if React, instead of invoking the entire `App()` function, only invoked the code affected by the change as captured in the dependency array. That's how Vue and Svelte work; the same way that a handler function via `addEventListener()` only executes the designated handler function. React does not work this way. Think hard about that and how React is conceptually opposite of how events work in DOM itself.

This difference in design means that in Vue, there is -- in practice -- almost never a need to do manual memoization and never really a thought of "where should I put this"?

It might seem obvious here, right? if `fn` has no dependencies on the component state, then it can just be moved out of the `App()` function. But this is a common mistake and it ends up with excess stack allocations (also why React is generally the poorest performer when it comes to memory usage).

React's model is a bit of an outlier for UIs which generally assume state encapsulated by a component is stable. React says "no, the component function is going to be invoked on every change so you cannot have state in the component."

A different way to think about this is to go look at game engines or desktop UI frameworks which render stateful objects onto a canvas and see how many game engines or UI engines assume that your object is recreated each time. This is certainly true of the underlying render buffer of the graphics card, right? But generally the developer builds on top of stateful abstractions. React has, in fact, moved the complexity onto the developer to properly place and manage state (while not being faster nor more memory efficient than Vue or Svelte).

I believe that a lot of React's expanding complexity flows from this design decision to model inherently stateful UIs in a "pretend everything is a stateless function" way because it is fundamentally playing opposite day against the underlying JavaScript and DOM.

Thanks for the detail explanation. That's what I understand how React works.

Another thing I found un-intuitive with React is the state of multiple instances of the same component. The useState() hook basically references some global state in the global context. When the component is used in multiple places, i.e. <my-comp></my-comp> <my-comp></my-comp>, the useState() hook inside is called twice and somehow they get a different copy of the global state. I know the magic of the global array to track the states. It just feels a bit too magically.

I chuckle it's claimed that React component is functional. And cringe whenever people put out the UI=F(props) statement, as if calling F with the same props multiple times getting a different set of state values not the anti-thesis of being functional.

React is definitely not functional, see https://mckoder.medium.com/why-react-is-not-functional-b1ed1...

lol, I added this comment to favorites remembering I once did add some other comment explaining well some React rendering behavior pitfalls, and it looks it was you too :D

https://news.ycombinator.com/item?id=37349286

great explanations, thanks!

I know this is a few days old, but I appreciate the excellent response and explanation of the differences. I still love React, but that's likely bred out of familiarity. I'll have to look at some of these other libs/frameworks to see what I've been missing.

If rendering or not can change the state, then your UI is not a function of your state.

It’s not.

The attitude I've heard from many frontend devs is that they acknowledge that AI will do most of the work. v0 and Bolt will do most of the work. Not because it does a better job, but because there will be a race to the bottom where employers don't want to pay for anything else. So this might mainly be a problem for the AI to learn.

I generally feel the opposite way. React was changing every few weeks when I started using it, the docs and API are much more stable and consistent now. In general web standards are more stable then ever also. People younger then myself won't have learn 100s of layout hacks to get their pages displaying properly cross browser, or sometimes even in just one browser. This is just my perspective, although I also understand JavaScript fatigue, I feel it is actually one of the best times to start learning.

It’s not that bad. I started basically from zero about a year ago, have been doing react maybe 20% of my work time since then, and I would say I now understand and can use most concepts/features in react.

I'm trying to parse that sentence and as it turns out... probably nothing is relevant to me that just writes end user front-end stuff. Most React development is in the backend / rendering or for specialists that write libraries, feels like.

My main approach, when it is something I control, I stay as much on .NET and Java solutions for Web development, with minimal JavaScript.

When not, I focus on backend and devops instead.

Although some SaaS products make our life harder, with React only SDKs.

> Imagine you decided to start developing websites today, how do you even start?

You'd slap together a Jenkins/Jekyll site and host it on github for free. It's easier now to set up a website than ever. But yeah that React sentence is pretty difficult to gronk.

> I’m pretty sure it’s a cool feature but, what a mouthful. Imagine you decided to start developing websites today, how do you even start?

Easy: By not using that optional feature.

If you’re like 99% of developers you really don’t need stuff like that until your app reaches a certain stage of growth, if ever - and React doesn’t force it on you.

Huge +1 to this. Looking at python 3.13 release notes [1]:

> asyncio.as_completed() now returns an object that is both an asynchronous iterator and a plain iterator of awaitables. The awaitables yielded by asynchronous iteration include original task or future objects that were passed in, making it easier to associate results with the tasks being completed. (Contributed by Justin Arthur in gh-77714.)

"I’m pretty sure it’s a cool feature but, what a mouthful. Imagine you decided to start developing python scripts today, how do you even start?"

[1] https://docs.python.org/3/whatsnew/3.13.html#asyncio

Not sure if those are the same though?

Async, await, iterators, futures etc. are pretty much standard constructs in almost all programming languages / concurrency frameworks.

Whereas Actions, Transitions, Pending State, Reducers etc. are React-specific idiosyncrasies.

I guess that's the main issue people have with React, when you learn it you have to spend so much time to learn all these React-specific constructs and idiosyncrasies that are not transferable anywhere else.

When one is learning to program, one doesn't jump straight into learning coroutine management.

Similarly, wether they are React-specific idiosyncrasies or not, one shouldn't assume people need to jump straight into Actions, Transitions, etc when first learning React.

Yeah, but if you're like 95% of developers you really don't need React either, but 'something' forces it on you.

In my experience, React was an interesting take, but it had certain flawed red-flags that were ignored from the start. I wrote posts about it, but was doomed as a skeptic. The original fundamental premise: let's do one-way binding with virtual DOM, re-render, diff – did not make fundamental sense. Double the memory in browser, complete re-render & diff for every interaction? The answer was: Make it reliable, then make it fast. Now, it's full of hacked-up constructs attempting to make it fast – but it's neither fast nor reliable. At least with honest two-way binding frameworks, fast is guaranteed, and reliability comes from my experience. With React it's just a mess. I pity all the frontend engineers who's first intro has been with React, because unlearning is much more difficult than learning.

Being mindful of the never-ending-nirvana frontend spirit of churn, and after doing web development in VBScript, JS, JQuery, Mootools, Applets, Actionscript, YUI/Ext/Sencha, Backbone, Knockout, Angular1, Angular2, React, Vue1 – I'd say try Flutter. It's genuinely a breath of fresh air.

Except... Dart. If only Flutter was in Typescript it might have been a bit closer to nirvana. The Dart part is still keeping the frontend spirit of churn alive.

Virtual DOM is not inherently an issue. Many libraries use it and are much faster than React.

The main issue is React forces you to tell it which components to re-render. This causes a bloat of ceremony that makes it endlessly annoying (in comparison to global redraws) to write in.

> React forces you to tell it which components to re-render

That's a really weird statement, do you keep your application state in a mutable data structure instead of immutable? Do you know what a pure component is?

So you don't use hooks at all? The one great unification of state management that comes included?

What are y'all doing with it that apparently makes it slow? I've been developing a massive react application for the past two years, and it's plenty fast and very responsive even on my mid-2019 middle of the range Android phone. And I'm saying that as someone who refuses to use Electron and trims down Linux desktops to bare essentials to save as much memory and CPU cycles as possible.

It's an interactive business analytics, one of those use cases where an SPA makes sense — 15 years ago it would have been a native desktop application.

We just follow the usual guidelines, no extraordinary optimization techniques or anything like that.

Have you don't nothing to optimize it? One pattern we've had to adopt is wrapping every component in react.memo

Why is fast guaranteed with two way binding frameworks?

Just use mithril and never look back. You can learn the API in one day and move on with your life creating compact and performant apps.

React is unbelievably overengineered, classic case of creating solutions to self-invented problems.

Shameless self-promotion, but anyone reading this who is just getting into front-end and doesn't want to deal with that ^, check out Joystick [1].

It's a full-stack JS framework with its own components library that uses plain HTML, CSS, and JS (and has dead-simple, obvious APIs for implementing more advanced logic like state and event handlers). It's a logical next step from learning web dev fundamentals to building full apps.

[1] https://cheatcode.co/joystick

port 2600 huh ;)

Yes! You're the first person to catch that. Check out the test port.

Judging by your front page demo, your component stack is built on simple string concatenation (via untagged template strings), with nothing about escaping of any form, for any format. That's a very bad sign, you're just begging for injection attacks. There's absolutely no chance of me using a framework with a demo like that, even if it actually had decent tools for handling the situation.

That's all mitigated on the server. You also have access to additional escaping tools for handling user-generated data on the server, too.

> That's all mitigated on the server.

How? Please be specific, because unless you're altering the source (which I'd be very unpleasantly shocked by), your use of untagged template strings makes it fundamentally impossible to mitigate such stuff, short of forbidding characters like & and < and " from data, which would be insanity. You're mixing template and data willy-nilly.

The source isn't altered (I take the component HTML, parse it, build it into a DOM, and render it). The data from the API is compiled separately (where sanitization can happen if you have untrusted user data). The two are combined together during SSR by passing the sanitized data to the component.

Developer controlled code at the component-level is assumed trusted, however, there are three mechanisms for handling escaping/sanitizing on the server:

1. There are helpers built in to the API (you can conditionally enable sanitization depending on need) to handle sanitization and helper functions built-in to the server-side to do one-off escaping/sanitization for HTML.

2. Query params are sanitized automatically to prevent injection.

3. To prevent unescaped HTML in data from breaking renders, I base64 encode it before sending it to the browser.

This approach to escaping is by design as some use cases call for sanitization (they're rendering user-generated data) while others do not.

You're welcome to audit the source and see if I missed something or make suggestions on improvements.

I wrote something much longer and more detailed, but I haven’t the heart to post it in the end.

This is a phenomenally bad idea. By escaping things willy-nilly you’re making life much harder, and vastly more error-prone. You can only even vaguely sanely do such things with the support of a better type system than you have available to you. You’re encouraging storing escaped HTML in the database; exposing an API that HTML-encodes all strings; you’re misusing the term “sanitise” (sanitising is fairly consistently used to mean stripping control sequences, not escaping). This is a disaster. Given that you’re working in JavaScript, you need to use something like JSX or equivalent functions or tagged template strings, so you can escape only as appropriate. As it stands, I would genuinely expect to be able to find trivial functionality and/or security bugs in practically every decent-sized Joystick site involving user input.

One specific technical bug: https://github.com/cheatcode/joystick/blob/canary/node/src/l... tries to escape &<>"'`= but will replace backticks and equals signs with “undefined”. Defining HTML_ENTITY_MAP in a separate file was a mistake; you’ll hopefully never refer to it anywhere else, and separating it made such an error easier to make. (Incidentally, backtick and equals sign have never been useful things to escape in HTML. Truthfully, & and < are all you need in HTML text, and & and " in double-quoted attribute value. If you want to support XML, then escape < and > everywhere as well. But nothing beyond that is useful.)

I updated the escape_html() method to cover the missing characters/cases and centralized the entity map to the function definition. Appreciate you pointing that out. I went beyond what you suggested in terms of characters which should cover most (if not all) problem cases.

Here's an example repo: https://github.com/cheatcode/escape_test

And example text I used to test: https://gist.github.com/rglover/c75e37b526d864313b461d38195b...

> You’re encouraging storing escaped HTML in the database

You can store unescaped HTML in the database and upon retrieval, escape it (see the linked demo repo above). You hypothetically could store escaped HTML, but you'd have to show me where I'm encouraging it (I think what you're saying is that because you can do it, I'm encouraging it).

> As it stands, I would genuinely expect to be able to find trivial functionality and/or security bugs in practically every decent-sized Joystick site involving user input.

You're welcome to audit it, but please, actually test it by building something and then provide an example repo. Make sure to use the canary release as that has the latest changes. If you email me (ryan.glover@cheatcode.co) I can give specifics on how to get set up.

---

FWIW, this isn't a productive way to point out issues with a project. A PR with comments is preferred.

Sorry, but it’s like the reaction to https://news.ycombinator.com/item?id=42359067: “this is neither a new idea nor a good one”. Ad-hoc escaping for serialisation is just fundamentally a really bad approach, and although it used to be how almost everything did it, nothing serious has tried working that way for at least a decade, probably closer to two by this point, because as an industry we’ve actually learned things.

Your particular angle on it might be novel, I’m not certain, but only because it’s an even worse idea. Formerly, there was a simple rule: remember to escape data when emitting HTML. You’ve replaced that with something complex: some things will be entity-encoded, and others won’t; and often you won’t want things entity-encoded. (You’re inappropriately tying API to HTML, by the looks of it.) This is just a bad abstraction that makes errors sure, and errors will lead to some mangled text in all cases, and security bugs in some cases.

It’s very similar to how the consensus is now well-established (though it’ll take plenty more time to be fully applied) in memory safety, a related security field: avoid languages like C, they’re too dangerous, use memory-safe languages instead.

Another well-established principle: parse at input, let your system deal with data, and serialise at output. Your approach instead serialises at input—and that only most of the time—and hopes you never need to parse.

I’m certain that I’ve upset you, and I’m sorry about that, but the approach really, truly is that bad, and I did just want to appeal to you to think it over. Look, if you can find someone experienced in web security and frontend framework design and things like that, preferably who’s been doing this for fifteen or twenty years, present the whole design to them, and see what they say. I genuinely expect horror.

As for your changes to escape_html, I’ll just ask why? because you’ve compounded the error. There is no plausible purpose for all the additions you’ve made. By encoding, you declare intent to feed the value to an HTML or XML parser in data state, single-quoted attribute state or double-quoted attribute state. In none of those states do any of these additions achieve anything. And if you’re making them for some other purpose, then you don’t want the HTML escaping in the first place.

Fifteen years ago, I would encounter both double-escaped HTML and entity-encoding in non-HTML contexts, far too often. Now, I feel like it’s years since I’ve seen such a thing, outside of text/plain parts of emails (but developers and marketers are frequently awful about text/plain parts).

The only advantage I can see in entity-encoding more characters, especially all normal punctuation, is that bad escaping is going to be caught earlier. But I say, if you reckon those worth escaping, why not go the whole hog and .replace(/./ug, s => '&#' + s.codePointAt(0) + ';')?

I’m not sure what your experience is, but the impression I’m getting is that you’ve been largely just JavaScript. A lot of the problems you’re producing were best-known through PHP, and better type systems are a large part of the best solutions to these things. If I’m sounding you out correctly, I’d recommend that you look into and learn some strong statically-typed language, preferably one with algebraic data types (also called sum types). Rust has been my own preference for the last decade, but there are plenty of others that would guide you in similar lessons, like (in no particular order) C♯, Swift, Elixir, Kotlin, Scala, Haskell. (I don’t include TypeScript in this list, although it could definitely help with some of the lessons, because it’s too compromised by JavaScript limitations.) If you haven’t had any of this sort of experience, getting it will help you to write better JavaScript, and make better systems.

—⁂—

Now, for a specific matter:

> You hypothetically could store escaped HTML, but you'd have to show me where I'm encouraging it

<https://docs.cheatcode.co/joystick/node/escape_html#:~:text=...>

(And if you unconditionally entity-encode query string parameters… I don’t even want to think about the implications of that.)

I would also point out that https://docs.cheatcode.co/joystick/node/app/api/sanitization says:

> Sanitization is the process of scrubbing unexpected or unwanted HTML tags from the values returned by your API.

But this is not what you’ve implemented. You don’t actually scrub, you entity-encode.

After all of this, it's not terribly clear what I'm doing (aside from making escaping only through a one-off function) that's "bad." You mention "a lot of the problems you're producing" but then fail to give a what or why those things are problems.

If there's something specific that you can point me toward, I'll take a look and work on improvements. But honestly, the majority of the above reads like you just want me to feel bad and quit (and again, doesn't provide a clear answer to "what to do instead"). If you can succinctly explain why my approach is bad and offer examples of fixes (in relation to the current design of the component system), I'm all ears.

After doing a bit of digging and back-and-forth with an LLM, I think I understand the problem now.

By doing escaping solely on the server, it creates two problems:

1. You're leaving escaping up to good behavior which will inevitably lead to some value that needs escaping being missed.

2. You create a double-escape problem on the client as you may need to render the raw output (e.g., rich text) and a server-escaped value would require an "unwinding" on the client.

Beyond this, I also corrected what you pointed out in the docs as that was the opposite of what I intended for that function.

I think the approach will be to do some automatic escaping on the client and then pass some special functions to the render() method on components to allow rendering raw, unescaped user data (i.e., a dangerouslySetInnerHTML equivalent).

If there's anything else specific that you'd add, let me know.

---

You seem like you have a lot of knowledge, but in the future, if you want someone to listen and comprehend what you're saying, avoid the fatalistic, theatrical language and emphasis.

Your point is incredibly helpful and showed me something I wasn't thinking about, but the way you communicated it almost made me ignore it.

If the above isn't correct (or misguided), it'd be best if you just plainly explain why and what should be done instead (and not a wholesale "this could never work, burn it down" response).

htmx and python

> Imagine you decided to start developing websites today, how do you even start?

Probably with something simpler like Alpine.js, or even JQuery. No beginner is going to be building the kind of web app that requires such a heavyweight framework like React. Don't bother with it until you know you need it.

Reading changelogs certainly isn't the right place to start learning. A changelogs is a quite condensed view on changes from an implementation point of view. Some projects are good in promoting highlights from user perspective, but still a tutorial and manual are better places to start.

I think its all tech jobs at this point. People used to be a good sysadmin with just some bash, but now there are so many complex frameworks and best practices.

The quality expected of apps over the last 20 years has skyrocketed, and the tools to handle those requirements have gotten increasingly complex.

The HN hate boner for React is unreal. They've added a new hook to allow you to provide a more optimized implementation for a particular special case. It sounds like it's in the obvious place to find it if you need it, and does what you would want it to do. Why would you care about this unless you needed it? And if you needed it you'd know what it does.

> And if you needed it you’d know what it does.

Why would that be true? Often people don’t know what they need to solve a particular problem.

I meant the description quoted is the right description for someone who needs this to understand.

Why would a web dev learner need to know about this feature?

I don’t think beginners are beginning by reading the release notes. Note that the wonderful learning guide doesn’t even discuss these advanced hooks.

https://react.dev/learn

Even the reference section of the site makes clear how far down the priority list the advanced hooks are.

https://react.dev/reference/react/hooks

React has a dizzying number of concepts now. I don't love the direction it's taken the past few years; it used to be a really minimal and elegant core, but these days it's hard to keep up with all the abstractions

I read the updates and I know we will never need this stuff and we will never use it. However, we cannot not update to it for the clients that use it as other libraries will start using it. It is why we left react; this churn is just mental for things that have no value to most dev users. Even if it has potential value, many will just skip it as so many things from previous versions are not used in many codebases we see (and we see a lot in different large corp repositories).

By that logic beginners can never get into programming (or really any other field) because there's some complexity on the deep end.

> I’m pretty sure it’s a cool feature but, what a mouthful. Imagine you decided to start developing websites today, how do you even start?

You start where the docs say to start, https://react.dev/learn which wouldn't be mentioning this advanced feature, just like pretty much any tech. Reading postgres, python, etc release notes will have a bunch of scary sounding new features to a beginner, but those won't be making their way into the "Get started" section

> Imagine you decided to start developing websites today, how do you even start

I'm an embedded dev so I've so far removed from web dev, but recently started looking into learning web dev for some personal projects. My god what a mess.

Any learning resource for a single topic , like javascript, Flask, CSS can't seem to stick to what it's trying to teach and insist that you start importing other libraries and frameworks. Most of the time they're not needed and the author just assumes that you understand this other library in order to continue following their examples

So you google how to use that library, but the learning resources assume knowledge of a different library...

When all the resources of just plain javascript and plain HTML/CSS. I don't want bootstrap or react, I just want to learn the fundamentals to build upon

> Imagine you decided to start developing websites today, how do you even start?

Not with React?

Seriously, if you are starting developing websites today, the first thing you need to do is learn the web platform: html, css, javascript (probably typescript as well while you are at it), svg; and some basic server-side stuff. React is for when you get pretty comfy with those.

> Imagine you decided to start developing websites today, how do you even start?

With HTML and CSS. And you don't touch JS until you understand the fundamentals of those. And only after those three do you touch a FE framework.

I'm not even kidding either. Whether its React, Angular or any back-end driven templating, those things are all abstractions over fundamentals.

Nothing new to what I am going to say and not strictly related to React 19.

I once loved client-side frameworks like React.

Then I realized: Great, we managed to add complexity wherever possible. In the backend, in the front-end, in the DevOps stack, EVERYWHERE. And more layers will be introduced to keep all that distributed complexity in sync.

sigh

Frontend frameworks really do make things simpler once you go beyond small applications though. Automatically re-rendering when the data/model changes is the right thing to do.

We can argue over the specifics for sure, but simply imperatively changing your UI whenever your data changes doesn't scale very far, neither in term of codebase nor in terms of team.

I think there are assumptions here that are not shared?

First, there is an implication that the HTTP model is benign in the complications that we see in web applications. I don't think it would take a lot of arguments to bust this? Trying to hide it, also leads to several problems of its own.

Second, that the rest of the abstractions in a browser are benign in the complications most people complain about. The DOM, CORS, general document structure, CSS(!), and all of the extra APIs that browsers have added through the years are building on some rather awkward layers. I don't think it is hard to argue that the biggest reason that browsers have had the success and development that they have had, is the privilege that we have given port 80 in the world.

Now. I think an area we would have solid agreement on, is that I don't necessarily think we had better options along the way?

Bringing this back to frameworks, though, tooling is tough to ignore. The tooling that people used to have in easy application creation is tough to scoff at. I think it is safe to say that Dreamweaver was also not that bad, looking back. We had some odd purity tests on whether or not it should use tables for layout. Hard to really keep that complaint top of mind when I look at the absurd amount of markup that is in so many sites, nowadays.

tables with layout wasn't really an issue of purity, but they were another layer of the cruft you described where we were abusing things not built to actually do that.

grid and flexbox are probably closer to actually being a one-stop easy-to-use paradigm with less nasty edge cases than tables, but all the table code stuff is still there if you really want to do it.

---

> I don't think it is hard to argue that the biggest reason that browsers have had the success and development that they have had, is the privilege that we have given port 80 in the world.

I actually think this is orthogonal. The power of frameworks like React is that nobody wants to write the same app five times (windows/mac/linux/ios/android) using sometimes wildly different native coding paradigms, and coordinating feature development across native platforms is like herding cats.

You can really only hang a claim on "abusing things not build to actually do that" on the same peg that "purity" hangs on, though?

I mostly agree with the point that this is orthogonal to frameworks. I'm just putting that in here for why people disagree with many common web frameworks. A lot of the complaints that many of us have, are ultimately rooted in what they are building on top of. CSS, in particular, is remarkably ill suited for interface design.

Yeah, but it's the same thing as the "built on top of awkward layers" problem that you describe as a problem. it either is or isn't a problem, and then today you can still write it if you want.

People were doing things like making rounded buttons using tables, using things self-described as "clever hacks", and they mostly stopped working because as things like new viewport dimensions showed up you needed to paper over that too.

at least from what i've seen, the other strength of CSS is that it gets used for literally everything and so it's possible to build most conceivable layouts. A lot of the other layout frameworks either just use CSS, or you might run into edge cases because of the sheer amount of things in CSS that may not be well supported elsewhere or do not have a clear parallel.

CSS is easy to hate on, if only because of how much easier form builders were with VBA and such. Flash was also amazing, for content creation.

But I don't want to belabor examples. Fitting everything to the DOM is probably a worse part of the problem. Especially with how people insist on trying to rube Goldberg the layout on the regular behavior, which is clearly for a much more linear document. (Incidentally, no complaints on it to represent a document...)

Then you try to make things stateless for the HTTP nature. As well as largely pretending that the URLs are file system paths.

Both of those land you with frameworks on the frontend that are easy to complain about. We then add to the pain by trying to use the same framework for native.

We always had better options than CSS. The whole industry went in the wrong direction for years. But React is the opposite of that, it's someone finally bringing some sanity to the web.

I never hated css. I would struggle to really defend it, though. And looking back, I cannot understand how we wound up here.

You must have found a way to add more components, actions, properties, etc. automatically when your data models change. Otherwise, you are changing your UI every time those change. Except that now you have to maintain DTOs, models, actions, APIs, schemas, etc. in many places and across many teams.

Sorry, I have been around the block so many times, there’s now a moat around the block.

That's because VC funded software development is a welfare program for smart people that also want to have fun. It's okay.

> we managed to add complexity wherever possible

Sure you can centralize your complexity. But that doesn't necessarily get rid of this.

You can put database queries, business logic, UI interactions, etc all in one place.

> we managed to add complexity wherever possible

Did you? You can always opt for a simpler framework and you can avoid server orchestation. If you are not in the position to choose then you could work on starting your own project if you think you will have a efficiency edge over the rest with your simpler stack.

React was my reason to distance myself from Web frontend. Huge complexity just to make the web browser render boxes in a way it’s not intended to do. Huge loss of productivity and tooling in the name of changing a coding paradigm. Some cool ideas and implementations, sure but was it worth it? Maybe it was a job security stunt or something of that sort?

Well it wasn’t just ReactJS, the whole JavaScript ecosystem went mad with its libraries and tooling for all these libraries but React was particularly annoying to get started so they built create react app so you can have a hello world app in a reasonable time.

What is your alternative to the problems that React supposedly solves?

I no longer have an idea for the web, I do native mobile apps now. SwiftUI for example shares many ideas with react, like being declarative.

The difference is, in SwiftUI you fire up Xcode and you are up and ready to build the thing you intend to. No tooling setup, no intermediate steps to transpile the code into something you can’t recognize and the “backend” that deals with the logic is the same language with the same paradigms. Mind you, SwiftUI is considered a downgrade when it comes to tooling. Yet everything fits and you didn’t spend mental energy to try to make the tools work as intended.

My mantra now is to use the tool that is built to do the things I want to do and stop trying to make make it work in ways it’s not intended to. That’s why when I want to have a web interface I simply work with DOM directly. That’s how the creators of the web browser intended:) No virtual DOM, no libraries doing magic and managing the DOM for me. I'm sure there's place for ReactJS too, it's just that its not for most use cases.

All I want is tools that I can fully fit in my working memory and don’t spend time trying to make things work so I can do the work I care about. Simplicity and robustness is the paramount.

I'm kind of the same with that. At some point quite a long time ago doing the front-end side of webdev became a chore for me so I stopped. I'm finding SwiftUI attractive because I feel like I make a decent frontend experience for free which allows me to focus on the functionality.

SwiftUI is to UIKit what React is to the DOM.

I think the big difference right now is React has been released for 10 years vs SwiftUI's 5, so people had had the time to shoot themselves in the foot much more with React. IMO it doesn't take away from it still being much better than what it replaced.

> you fire up Xcode and you are up and ready to build the thing you intend to. No tooling setup

> no intermediate steps to transpile the code

Sorry, but how is Xcode not "tooling"? And how is there no compilation step?

It should be obvious to us all that the frontend world needs more stable and reliable tooling. But pretending that native or mobile apps somehow don't need tooling is not a serious position.

> I simply work with DOM directly

Do you care to show us any apps that you've built with this approach?

So much of this debate is people talking past each other about what they need. Some people are building a glorified blog CMS, and jQuery is fine. Some people are building Figma, and think the former camp are insane for suggesting jQuery is fine.

> That’s how the creators of the web browser intended:)

The web is the best application delivery platform we currently have, so people will ship apps on it whether or not that's what Tim Berners-Lee thought they should be doing.

I didn’t say there’s no toooling, it’s just that these tools work great and are mostly transparent. There’s no part where you setup or manage the tool. Even the deployment is just a few clicks.

The overhead is so low compared to the web tech, it’s no comparison.

If you want to do something weird you can complicate things if you like but the defaults are great so most of the time you don’t have to.

You know how on web tech there's many tools like packers, linters etc? Those are all tools you need only because you want to pretend that JS is not JS and you end up putting a distance between yourself and the actual thing that runs so you loose your ability to understand what's actually going on because it's actually not your code that's running in the browser and you had to do the chores to achieve it.

On native development these things also exists(the CPU doesn't understand human readable code, right? However the abstraction layers are straightforward), the packer equivalent would be linker I guess(not exactly but...) but you don't have to even know about that unless you are doing something that explicitly requires you to control how modules need to be connected. These tools are mature and simple, they daisy chain, you don't go through huge configuration files and its usually just a flag you add when you want to do something non-default(which you wouldn't if you are doing something like building UI). For huge projects things can get quite complex but the complexity isn't the default, unlike React & similar.

>in a way it’s not intended to do

Yeah that just isn't true. No matter how much you want it, the days of html pages with anchor tags and <table> elements centering content are gone.

Move on man.

I moved on. To native apps.

It’s great.

Btw the web tech has come a long way since. Native browser API is amazing, CSS is wonderful and I’m particularly excited for Web assembly. Drop the virtual DOM stuff and all other Frankenstein BS and working on the browser is actually fun again.

Html, anchor tags, and tables are definitely not gone. Now we center with CSS. I suspect these things will be staying around longer than react will.

I just rsynced my php files over. ci/cd done. php does html/css ui done. I am not sure what all the js trend is about.

You just havent worked on an app that is heavy on client state.

React and similar frameworks have made it easier to manage a given level of complexity. The complexity of app features have adjusted and will continue to adjust to the new frontier enabled by said frameworks.

I like React but since hooks (v16.8), React’s changes are nothing but skill bragging.

I stopped hoping for the reason behind changing the class components API to hooks.

One of the best parts of this release:

    ref as a prop: Refs can now be used as props, removing the need for forwardRef.

Being able to <Context value={1}> instead of <Context.Provider value={1}> is also a nice, albeit small, QOL change. Feels like they are really honing down the API. Esp once they kill off useMemo and related hooks with the compiler.

Very nice, something I actually care about!

The blog post is an easier read: https://react.dev/blog/2024/12/05/react-19

    const error = await updateName(newName);

Why would updateName return an error? Why not just throw an Error like JS/TS?

It's just an example async call, it could be anything. It's not the important part of that code example, it's only purpose is to show that an async call is happening. It could be written as a try/catch, or it could be written how they wrote it. I guess they chose that way because it's short and to the point.

Good example code is otherwise uninteresting apart from the concept that is meant to be shown.

updateName is a call to the backend/server to update the database...

Some guesses:

- People really like Result structures

- People who wrote the API believe in the "operational issues and business issues should not be comingled" philosophy (so this function might raise on a connection error, but it _won't_ raise when there's simply an error like a name conflict)

- People who wrote the example write Too Much(TM) Go

There are 45 comments so far and 7 references to "redux". I'm just gonna rep for the Recoil clones here and mention Jotai, which likely already works with React 19 without any necessary changes.

With enough front-end complexity, other state managers get in the way more than should. So, to anyone who might be tempted to hate on React, but really has just grown weary of endless walls of action constants, or plumbing props, or fighting nested providers/contexts, or resorting to pub-sub; give something like Jotai a shot.

I’ve used it in a largeish project and I liked it a lot.

I rally hope I never have to deal again with redux or sagas

When I go to Jotai npm docs page (https://www.npmjs.com/package/jotai) I don't really get the impression of how this helps get away from using a lot of different context providers or Redux. The nice thing about context hooks is they are composable, combined with cached queries you can have a decently maintainable pattern. How does Jotai provide a tangible improvement on this?

The benefits would depends on how your code is structured, which dependencies you use, and overall complexity. Contexts provide and elegant developer experience, up until they don't. Have you ever implemented nested SplitView components under Dockview? It can be brutal on contexts.

As a developer, I value solutions that never fail me. I wasn't driven to Jotai out of good taste. Simplicity and reliability are the benefits I find the most tangible. But Jotai's atomicity brings renderer optimizations as code splitting advantages that I haven't seen from the flux/redux clones before either.

https://github.com/KidkArolis/kinfolk - recoil/jotai, but simpler

Everyone should try https://starfx.bower.sh which is a fresh take on state and more importantly, side effect management.

I don't understand why state management is filled with so much weird terminology. When I started working on a React app years ago every state management package I saw was filled with it - and they still are.

I ended up rolling my own solution [1] to escape all that so I could focus on getting things done. It's been working great for me in production. Too bad there's no popular option that works similarly.

[1] https://github.com/facepunch/react-class-model

Looking at how CounterDisplay and CounterControls work at the bottom of the README, the idea behind this is similar to Valtio (direct updates and changes are pushed on update), except with a lot more manual work. Valtio uses proxies and hooks to get the effect of CounterModel, CounterModelProvider, and useCounterModel automatically, without having to write them yourself.

For comparison, Valtio has the same kind of "counter" example at the top of their README (first and third code blocks): https://github.com/pmndrs/valtio?tab=readme-ov-file#wrap-you...

That looks pretty similar but I like the use of classes in react-class-model to encourage keeping logic out of components. It's not shown in the readme but using context is optional - you can similarly achieve global state by storing it in a variable and then using `watchCounterModel` (the third return value from `defineModel`) to subscribe to updates on it. Both hooks also return proxies to re-render only when the referenced fields change.

The people behind Jotai also made Zustand and Valtio:

https://github.com/pmndrs/zustand

https://github.com/pmndrs/valtio

To me it feels like Jotai has too much manual boilerplate and Valtio has a lot of proxy "magic" that while I do like it I don't feel like it would be a good idea for a team. Zustand sits right in the middle of boilerplate-vs-magic, and is what I chose for a large project we're doing now.

I used Valtio for a guitar pedal librarian program recently and it's fantastic. Had zero issues with proxy state, it all "just worked".

maybe the apps that I've worked on are not complex enough, but I found that Relay + Context API combo solves the state management problem for us. We have not had to use any state managers yet.

I don't like most of the new features introduced. Actions, and the useActionState/useOptimistic hooks seem like massive complexity pitfalls. The 'use' hook has a very uninformative name. It doesn't handle promises created inside the component. While I assume there are very good reasons for that, my impression is that passing promises as props and handling them with the use hook will create more complexity - more than current workarounds.

Server Components also look fairly complex, and I'm glad I haven't had to deal with them so far.

The improved error messages on hydration errors are welcomed. The <Context> as a provider and ref as a prop changes are nice QoL changes.

Overall, I like React/Preact as far as building SPAs go. Using it with a feature-rich component library (say, MUI) and a simple state management solution (like Preact Signals) makes it very straightforward to build SPAs, as far as I'm concerned. But I worry about the complexity creep. The descriptions for the new hooks in those release notes put a massive cognitive load on me just by reading them.

The React Compiler, on the other hand, is a much needed tool. It should result in components that are less complex, as the programmer won't have to write typical optimizations by hand, as part of the component itself. I'm looking forward to its release and eventual integrations with Vite and etc. From what I heard, Preact will support it too.

I wish they rename "use" API to something else other than the common prefix for hooks. I imagine someone new to React hooks might be confused when they see that `use` can be called conditionally, while hooks can't.

Really glad they delayed the release to (hopefully) solve the parallel suspense issue. Haven’t tried it yet but high hopes, and great release overall.

They did solve it (from the guy that originally reported the suspense issue): https://bsky.app/profile/tkdodo.eu/post/3layw6wk5bs2b

Yeah, it would have been horrible if they broke React-Three-Fiber, that is one amazing library: https://r3f.docs.pmnd.rs/getting-started/introduction

Breaking news - full support for custom elements. Web components that is.

Does react use semantic versioning?

I’d hate to have to deal with incompatible versions at the rate they release major versions.

If you try to stick with one version do you soon get stuck because you need to take a bug fix or security fix that’s only available in a later major release (but updating breaks other things)?

I want to build software on a stable platform so I can spend time on improving the software or writing something new, not keeping up with updates.

Yes, React uses semver. React 19 has been in development for over 2+ years - React 18.2 (the last meaningful minor release) came out in June 2022, so the release pace has been slow enough people have complained that it's _too_ slow:

- https://macwright.com/2024/01/03/miffed-about-react

(looks like the author may have an HN-specific redirect, so you might need to copy-paste that URL)

The numbers are high because they jumped directly from 0.14 to 15.0, but the cadence is not particularly high: 18.0 was released early 2022, 17.0 late 2020 and 16.0 late 2017. That’s three major releases in seven years.

React is stable, upgrading it is painless as long as you don’t ignore deprecation warnings. What can be annoying is other (abandoned) dependencies holding you back from upgrading.

upgrading is far from painless. If you're using any 3rd party solutions and they aren't compatible with the latest React you're going to have a bad time.

Yeah, as I said above I don't disagree. The ecosystem has lots of issues but React gets all the hate, unfairly in my opinion. It's a pretty well maintained piece of software.

That's a problem any popular library will have.

What's the solution?

I cant imagine saying upgrading is painless considering the way how React deprecated class components.

What specifically are you referring to?

The original `createClass` API was indeed deprecated and removed all the way back in 2017 [0]. You can still use them today with the separated `create-react-class` package.

ES6 class components still work as-is even in React 19 - it's just the legacy context feature that's been removed. They're generally discouraged, in that function components are now the standard way to use React, but they're still not "deprecated" in the sense of a warning or removal.

[0] https://legacy.reactjs.org/blog/2017/09/26/react-v16.0.html#...

They deprecated AFAIR 3 methods on class components and the docs about class components under "Legacy React APIs" say that it's a pitfall to use class components.

Yeah they deprecated those three methods a long time around (sometime around 16.3 I think) yet they are still around in 19.0 (with an UNSAFE_ prefix).

Regarding class components in general, what is the problem with maintainers choosing to encourage devs to use their new APIs while keeping the old APIs working?

The react team have done an incredible job maintaining backwards compatibility across versions over the years. They’ve even fought for bug parity when doing major internal rewrites.

Good thing class components are not deprecated. Where’d you get that from?

> upgrading it is painless as long as you don’t ignore deprecation warnings

Maybe if you have a small app. React is as bad as going from angular to angular 2

Yeah I'm just going to choose to not take you seriously if you claim that any React version bump is as bad as moving to a completely new framework (which is effectively what angular 1->2 was).

You just can't migrate with React too. The dependencies are always in the middle of a major refactoring that is released for the new react version so you need to change all code. This happens too often for too many packages

> Maybe if you have a small app. React is as bad as going from angular to angular 2

You have no idea what you are talking about.

lol having worked through 3 large projects going from 0.14 to 15 - pain.

15 to 16 - pain.

16 to 17 - pain.

If you disagree you haven’t worked on anything even slightly complex.

Thankfully I’m on my 2nd project of ripping react out for htmx. The last one was a huge success. No doubt this one will be too.

I see people complaining a lot about React, why is it? What are the alternatives?

PS: I'm not a frontend engineer but I find this topic interesting.

Thanks!

Using a scripting or templating language on the server to form and send HTML and CSS to the client as $DEITY intended

Django is still there and is still better than Phoenix by the way. I didn't really touch it in about 10 years, but ... nothing changed. It's amazing!

> and is still better than Phoenix by the way.

What aspects of Django do you think still stand out compared to Phoenix? It seems like a very solid framework, specially with the recent release of Phoenix LiveView 1.0, which seems like a pretty solid approach to frontend. For context, I’ve worked with Django before but didn’t particularly enjoy the experience—not because of the framework itself (its documentation, ORM, and admin tooling are excellent) but because I’m not a fan of Python, particularly its packaging ecosystem and approach to async, which I find lacking. I haven’t used Phoenix or Elixir before, so I’m curious to hear from someone who has experience with both.

Django is really thought out and polished in terms of devx.

Take ORM for example. You write a model and you get out of the box:

- migrations to create the model and to apply schema changes; - form validation for crud; - admin with permissions to edit it; - helpers to get model by id or throw 404.

Phoenix kinda is in the same market, but you write your migrations yourself, admin panel is a package somebody slapped on top, etc.

It’s not that Phoenix isn’t usable, but getting on that level takes time and effort

Unironically this. The fastest “web apps” I’ve seen that weren’t absolutely required to be javascript-heavy to operate by virtue of what they do, have been mostly or entirely rendered server-side and have just sent entire pages for most interactions. Still performed better than 99% of webapps.

Svelte. Rather than

    const [name, setName] = useState('blastonico')
    ...
    setName('nailer')

You do:

   let name = 'blastonico'
   ...
   name = 'nailer'

Also a single .svelte file includes everything you need for a component (HTML, JS, CSS), so it's easier to manage.

Vue is also nice.

Yep. Svelte's SFC was inspired by Vue. If you like Vue you'll like Svelte which is familiar but adds a compiler for simpler syntax.

I honestly don't feel like Svelte makes things simpler. And I'm saying this as a "fan" of Svelte and think its compiler is very cool.

It just feels a bit weird that there's special .svelte specific rules.

Runes kinda fix this, but it's still a bit weird.

I think Solid or Vue are much simpler (but only did small projects in them) and have a simpler mental model. I've not yet used Preact, but heard good things about it

Yeah I like Svelte a lot, but I can't help but feel Rich feels the need to be different, and not necessarily always in a good way. SvelteKit routing[1] is an example that pops out at me as being genuinely bafflingly bad to the point of comedy.

[1] https://svelte.dev/docs/kit/routing

let name = $state('blastonico')

I know some people didn't like this change. I think it works well to help make it clear and obvious to reactive vs non reaction changes.

`setName` makes sure that state changes are queued up for the next render, allowing you to treat all state and props as constant within the current render. If you are just assigning variables directly, then your state is changing within the same render cycle, which can lead to all sorts of nasty bugs that are difficult to replicate.

I get that assigning variables is easier to understand, but it's way, way harder to actually scale and maintain. Check out flux architecture.

Just curious. How does that work on changes between depending states within a cycle? E.g.

   [foo, setFoo] = useState(1);
   [bar, setBar] = useState();
   setFoo(10);
   setBar(foo * 2);  // Is bar 2 or 20 at this point?

It’s 2. We’re just running a js function here with nothing magical going on.

It might seem that there’s a chance that people will be confused about what bar is, but in practice all the changes are happening in handlers and bar will be a const anyway so you have no plans to mutate it directly.

Thanks for the clarification. I'm trying to understand the rationals behind React's design decision. Why state changes within the same render cycle would lead to all sorts of bugs? And why is it not a problem with other frameworks like Vue or Svelte?

Just a follow up. If foo and bar are expected to be constant in the rendering code, what's the point of the setXXX() functions? Why not just make them constant explicitly and say mutating them elsewhere like in the handlers/controllers?

If you have state changes within your render cycle, then you can't write pure functions anymore, you have a stateful class. And if you have a stateful class, then React can't control when you render, because it can't know when you update a variable. So the onus is on you to decide when your component needs to re-render. This is extremely easy to screw up. You will end up in scenarios where the UI does not match the underlying state, just because the two have gone out of sync.

React inverts the MVC paradigm and says "no, you don't get to decide when to render." So if you want to update state, React will manage that for you and queue up the render. With React, your UI and state literally cannot go out of sync (except for refs), and all the data dependencies are managed for you.

Facebook gave a great talk on Flux architecture vs MVC ten years ago that you should check out here: https://www.youtube.com/watch?v=nYkdrAPrdcw

> what's the point of the setXXX() functions? Why not just make them constant explicitly

Look at the code again: it is explicitly constant! `const [myState, setMyState] = useState(0)`. `myState` is a const, and will literally not change its value for the entire render cycle. There is no mutable state to manage, no race conditions. You just tell React what to render based on what the value is now, and React injects the current value for you. The first time, `myState` is 0 since that's the initial value. Every subsequent render, React will give you the latest value. You can pretend everything is constant, because it is.

I'm glad someone who's expert in React can answer these questions. I got several thoughts.

First of all, I don't believe React component is pure functional with the state hooks embedded inside the component with side effects. Calling UI=F(props) twice with the same props would not produce the same result given the different sets of states embedded in them.

Second, the local variable myState is const but the state is mutable; the variable myState is an alias snapshot of the state. Otherwise what's the purpose of handing out setMyState? setMyState is for mutating the state, right? It seems the need to keep myState constant is due to React's inability to detect changes to the variable to sync up the UI. It uses setXXX() to trigger the UI re-rendering. However, whether setXXX() queuing up re-rendering and causing re-rending loop is inconsequential to the programmers. It's React's implementation detail.

Third, I'm interesting in learning what kind of bugs mutable state would cause in React, so that we can design better systems down the road.

> Calling UI=F(props) twice with the same props would not produce the same result given the different sets of states embedded in them.

Correct, but you as the component writer don't care. From your perspective, you are writing a purely functional component because you have no control over the injected state. So your function is "pure" with respect to the props that are passed in and the state that is injected by React. It's actually UI = F(props, state)

React can (and will) run your component function multiple times with different values before rendering, so it is extremely important that you have no actual side effects. Otherwise, these "intermediate renders" will affect the final render, which breaks the contract that your function return the same values for the same inputs.

> the local variable myState is const but the state is mutable

It is "mutable" in the sense that it changes between invocations of your function. But no, it is immutable within a single render of your function. The fact that you can treat all state as constant is one of the massive advantages of using React. You literally don't have to think about state mutating within a render cycle. You just write a function that spits out JSX given props and state.

> Third, I'm interesting in learning what kind of bugs mutable state would cause in React

You're going to run into issues where:

* the order that your function is called somehow affects the final render. Now you need to worry about how your function is called, and with what values. Not an issue with React.

* the underlying state is out of sync with the UI, because you changed it but didn't trigger a re-render. Not possible in React (except for refs).

* the internal state of the component ends up in an invalid state because of the ordering of set-state calls and renders. Again, not possible in React because all set-states are batched together and applied consistently to the next render cycle. There's no such thing as a "partial render".

> Correct, but you as the component writer don't care. From your perspective, you are writing a purely functional component because you have no control over the injected state. So your function is "pure" with respect to the props that are passed in and the state that is injected by React. It's actually UI = F(props, state)

This is like calling the constructor of an OO class a pure function. The class constructor takes in parameters (props) and the created instances don't interfere with each other's states. With all due respect, this stretching of the definition of pure function is beyond recognition.

> * the order that your function is called somehow affects the final render. Now you need to worry about how your function is called, and with what values. Not an issue with React.

The order of the function invocations calling setXX() matters anyway in React or non-React libraries. The queued up setXX() calls pending state updates in React has an order. There's no difference in handling state update ordering between React and others.

> * the underlying state is out of sync with the UI, because you changed it but didn't trigger a re-render. Not possible in React (except for refs).

> * the internal state of the component ends up in an invalid state because of the ordering of set-state calls and renders. Again, not possible in React because all set-states are batched together and applied consistently to the next render cycle. There's no such thing as a "partial render".

Both of these are because React's inability to detect changes to state updates in a comprehensive and fine grained way.

> This is like calling the constructor of an OO class a pure function.

No, because again I must stress that you cannot control the injected state. You merely ask React to set state in the next render. The next call to your function may not have the new state! React can and will call your component function multiple times with different values of state, so you must assume it could be anything. This is why component functions must be written without any side effects, because there is no way for you to know which invocation React will actually persist to the DOM. For this reason, you really are writing a pure function with respect to props and state. It's a requirement in React!

> There's no difference in handling state update ordering between React and others.

The huge difference is that because state is fixed within a render cycle, it is not possible to read an intermediate value. You can't get in a situation where one handler updates a state value, and another (or the same) handler reads that new value within the same render cycle. That's the sort of order-dependent nonsense that can make a component very buggy and fall into an inconsistent state.

> Both of these are because React's inability to detect changes to state updates in a comprehensive and fine grained way.

That's because React is built in a way to provide a set of very specific guarantees when it comes to managing state and rendering it. You are free to come up with "simpler" solutions, but you are going to have to sacrifice some of these guarantees for that simplicity. React component functions have no side effects, and are defined completely declaratively. That is extremely powerful with a lot of advantages, such as being trivially composable. It is extremely easy to extract functionality out of a component and turn it into a reusable hook, because everything is already stateless.

If you ditch all that just so you can use variables, you lose all of those benefits. You'll have to deal with truly stateful components, ones that are path dependent and difficult to reproduce for debugging. By contrast, you can reproduce any React component's UI by passing in the same props and state. This is only possible because state is external to the component and out of your control.

Thank you for the thoughtful replies. It helps a lot in understanding the kinds of problems React was facing.

With all due respect,

> For this reason, you really are writing a pure function with respect to props and state.

A pure function by definition is one which returns the same output for the same input. The output (html) of the React functional component with the same props can be different based on the changed state. It is not a pure function. It's really no different from an OO object with internal state.

> There's no difference in handling state update ordering between React and others.

> > it is not possible to read an intermediate value.

There is no intermediate value. All value changes are in the final form as there is no multi-threads reading and mutating the state. The block of code mutating the value is executed fully before another block of code can read it.

As for multiple handlers reading and rendering the state and some might miss the change by another handler, again it's a problem of React's inability to detect change for each handler. If every handler can detect change by any other code (other handlers included), there's no problem.

> That's because React is built in a way to provide a set of very specific guarantees when it comes to managing state and rendering it.

React requires that set of guarantees because its design decision - its use of diff to detect changes. It's a non-issue in other frameworks and solutions.

> A pure function by definition is one which returns the same output for the same input.

Yes, and the input includes state. React manages it and sets it before your function runs; your function then reads those values when it calls the hooks, and it is read-only. If I adjusted the React syntax to pass in state as a function argument instead, wouldn't you agree that it is pure? It's the same! Just because it's not passed in via arguments does not mean it is not an input. And a pure function is still pure even if the caller is stateful.

Consider the "rules of hooks" in React: you cannot conditionally use a hook, and hooks must be used in the same order every time. That's exactly the same as regular arguments, making them functionally identical but with better dev ergonomics. That's on purpose: state is an input, but having it passed via function arguments would suck to use.

Question: have you written any React components? This is a basic rule that is one of the first things you learn: components should be pure functions with respect to props and state. They're not even allowed to set state as a side-effect. If you're still convinced it's not pure, can you tell me how a component function's output can change given the same props and state?

> The block of code mutating the value is executed fully before another block of code can read it.

And that's the problem: with arbitrary code, there is no such thing as a distinct "block of code". One function can read value A, set it to B, then call another function, which sees value B, does something as a result, and then it renders. But that's wrong: value B has not been persisted to the DOM yet, so it should not have been read by the second function. Now you're in trouble, because your component is behaving as if both A and B are true at the same time.

This is not possible with React. But to pull that off, they had to externalize state and make it read-only to your component.

> Yes, and the input includes state. ... state is an input.

This is the same argument that the member variables of an OO object are additional input to its member method and the method is "pure."

> how a component function's output can change given the same props and state?

This is the same argument that given the same values of the member variables of an OO object and the same method arguments to its member method, the method returns the same value.

All these are just twisting the meaning of words and concepts to fit the square React into a functional round hole.

> a basic rule that is one of the first things you learn: components should be pure functions with respect to props and state.

You can certainly mutate the state in a React component; otherwise, what's the purpose of [.., setXX] = useState()? If such a "rule" is so important, why don't React remove the ability?

BTW, the "rules of hooks" are another set of extra burdens. All these rules imposed on the programmers are there due to React's weak design.

> And that's the problem: with arbitrary code, there is no such thing as a distinct "block of code". One function can read value A, set it to B, then call another function, which sees value B, does something as a result, and then it renders. But that's wrong: value B has not been persisted to the DOM yet, so it should not have been read by the second function. Now you're in trouble, because your component is behaving as if both A and B are true at the same time.

If every renderer can detect every single update of a variable/state, the above is a non-issue. Function1 can set v1 to A. The renderer detects the change to v1 and renders it as A. Function2 set v1 to B; the renderer detects it and renders it to B. Function1 and Function2 can be called in any order; the rendering output is consistent with the state. The renderer might be called twice but who cares the eventual outcome is the same (certainly there're memorizing optimization to avoid re-rendering). It's really React's weak design causing all the out-of-sync rendering problems.

`bar` is 2 because `setFoo` does not update the value of `foo` until the next render

Will bar become 20 eventually? In the next cycle perhaps?

So there will be 3 cycles?

   1: foo = 1, next(foo = 10)
      bar = undef, next(bar = 2)
   2: foo = 10
      bar = 2, next(bar = 20)
   3: foo = 10
      bar = 20

Does the above sound right?

You would not write this code for a very simple reason: all `setState` calls queue up a new render. Since you're setting the state every time the component is rendered, it will loop infinitely.

Let's say you instead did the `setFoo` and `setBar` in a click handler. In that case, when you click the button it would tell React "Hey, in the next render set `foo = 10` and `bar = 2` (since `foo = 1)`. Then React goes ahead and runs your function again, and `foo` and `bar` will both be updated.

The value of `foo` does not change within a render cycle, you literally don't have to worry about state.

Bar is 2.

> If you are just assigning variables directly

We’re not just assigning variables directly, current JavaScript frameworks use a compiler.

setName() vs name= are just syntax. None of those have anything to do with how state changes. If you have control over the compiler (which they do) there's no reason it can't do the right thing (case in point, svelte).

This is not true at all. `setName` queues up a state change for the next render cycle, and has no effect on the current render. You cannot actually edit state directly, so that multiple handlers will all read the same state value regardless of state changes queued up for the next render.

    const [state, setState] = useState(0)
    const func = () => {
      console.log(state) // 0
      setState(40)
      console.log(state) // 0
    }

Overriding standard language constructs with magic behaviors is a giant no-no and a recipe for disaster.

Vue is infinitely better in pretty much every way other than available libraries (specifically UI libraries and some stuff like Motion, though that's soon-to-be framework independent), but to be honest I've never felt that problem in my 6 years working with both, and especially in more recent times pretty much everything is framework agnostic anyways, even the big popular ones like TanStack Query.

The one real edge I'll give React is much better Typescript support due to tsx essentially being a superlanguage of TS. Vue's composables are very good, but it falls apart a bit in actual template usage. Tooling is also better, but that's also because it's simply used much more so has had more investment into making the tooling good compared to Volar for Vue.

But in my opinion everything else surrounding Vue makes it superior. Signals are a better state management pattern, there aren't all the insane footguns that React comes with, performance is better out-of-the-box and is practically impossible to fuck up compared to React where it's hilariously easy to make even the simplest of apps be performance monstrosities, the documentation is (IMO, I find React's docs (yes I've seen the new ones) terrible) best-in-class, the gilded libraries like Pinia, Vue Router, VueUse are far superior to anything in the React ecosystem...

I could keep going, but having worked with both more or less equally, I'd choose Vue 10/10 times over React, no questions asked. I can throw a junior at the codebase and be 100% confident they'll make something that's more-or-less idiomatic Vue code, even with the Composition API which is less stringent than the old Options API, whereas with React they'll always need hand holding and I'll always need to explain why things are rerendering twice or running terribly or what useMemo does or what useEffect does (or doesn't) do...

Another vote for Vue.

It's harder to do poorly and even when you do, it doesn't punish you the same way that React does.

> specifically UI libraries

There are certainly more UI libraries available for React than any other framework [1]. But do you think that these are also clearly better? What would be your go to framework for React? To me, it seems that the trend is going to framework-agnostic or multi-framework libraries anyway (e.g. Ark UI or Zag).

[1] https://frontaid.ch/web/ui/libraries.html

I personally completely avoid UI libraries as we have our own that we built in-house, so I wouldn't know, I just know there's more of them and they're more mature in React land.

But gun to my head, Shadcn would probably be my choice. For Vue it'd be PrimeVue. Those are the two highest quality ones I've tried in small projects, so no clue how they scale in real-world projects.

> having worked with both more or less equally, I'd choose Vue 10/10 times over React

I have the exact opposite experience, I find Vue hilariously bad to the point of being repulsive. Now what?

Using both I think it comes down to personal preferences. One learns to appreciate their approaches to the complexity of FE dev. I do think ultimately it comes down to support , tooling and job opportunities. I was an advocate for Vue and now unfortunately I recommend React. Native mobile development is too important to disregard.

I mean that's fine, these are all just opinions of randoms on the internet at the end of the day. I find jsx "repulsive", you probably find SFC's "repulsive", and the nice thing is we each have a choice in what we want to use.

I used vue 2 for work during the switch to vue 3. It was horrific to watch as the vue community had to relearn the worst parts of the class components and the massive shortcomings of both the template library type checking and the other parts that basically can't ever support typescript like class mixins. If you want to use vue with a .tsx file you might as well use react.

Today, 33% of vue downloads in the last 7 days are for vue 2.

There was a lot of things that were nice in the vue world like vite and vuex, but I'd never recommend vue to anyone, especially anyone that wants a good typescript experience.

here's an example library button using .tsx in vue https://github.com/vuetifyjs/vuetify/blob/master/packages/vu...

I feel like your experience is a bit jaded by the 2 -> 3 transition which is understandable because it wasn't the smoothest, but these days things are very stable, and you can even use the CompositionAPI in Vue 2.7 as it's been backported if you can't upgrade from 2 -> 3. Typescript support is also great because composables are just regular JS/TS files now rather than a Vue-specific thing, the only part that is a bit wonky is in templates sometimes, though for the majority of code out there even template type checking works just as you'd expect, I very rarely have issues even with huge components.

Pinia is Vuex, it was made by the same people specifically for Vue 3 due to otherwise having to introduce a lot of breaking changes and is a lot simpler than VueX was, as it leverages the composable pattern and gets rid of the need to do things like `mapGetters`/`mapActions`. And VueX 4 is still an option for those that prefer that approach.

> ... class mixins

Those were a pain point, but no longer relevant in Vue 3 as mixins have been deprecated. Again, composition takes its place and is in general much more powerful while being simpler. For a great example of what composables can achieve, I'd recommend taking a look at VueUse (https://vueuse.org/)

> Today, 33% of vue downloads in the last 7 days are for vue 2.

Another way to look at that is that the majority of the community is on Vue 3 :)

> If you want to use vue with a .tsx file you might as well use react.

`.tsx` is very much a personal preference thing and isn't really considered idiomatic despite Vue having support for it (unless you're a library author like Vuetify that you linked). I personally can't stand working with `jsx` and find Vue SFC's superior, and again, typechecking these days is much better than it ever was and will work just fine in 95% of situations. Especially with things like component generics being introduced, it's only gotten better and actively getting better.

I'd highly recommend you give Vue 3 a try with an open mind, because things have only gotten more powerful while getting simpler since the Vue 2 days.

> other than available libraries

That's doing a *lot* of heavy lifting here. That's like saying "D is infinitely better than C++, except for available libraries".

While my current Electron personal project will probably use Vue because I want to learn it, the change in libraries (and lack of plug-and-play support for whole companies' provided frameworks) is a real barrier to entry for a lot of work.

Sure, all I said was that I personally never felt the pain there because everything I ever needed was available for Vue, especially these days with so many libraries and stuff like that being framework-agnostic. I've never worked on Native/Electron projects, so there might very well be a huge gap there that is unfilled by Vue, I wouldn't know, though I suspect from experience with both that the gap here is greatly exaggerated (except for Native/Mobile for sure, React Native is basically on its own there) for the large majority of projects.

Nice opinion. I started with Vue2/3 and now I’m learning react. Vue is designed better but react is further in development and more widely supported. Native mobile performance was the deal breaker. Ultimately you’ll find it easier to get a job using react vs vue.

Indeed React unfortunately wins over in terms of quantity of jobs, I'd argue mostly due to network effects. Hopefully that changes some day!

Native development is definitely a pain point, unfortunately there's few options other than React Native there. Problem being that React is backed by Meta, so obviously it has a lot more money being thrown at it compared to competitors like Vue or Svelte.

Solid.js is the real alternative to React

You don't need a complex framework like React. Check out this SPA app: https://github.com/wisercoder/eureka/tree/master/webapp/Clie...

It uses a 500-line router and a 500-line UI component lib.

I feel like most of the issues devs have with react are the community surrounding it. Lots of churn and burn libraries with breaking issues and changing APIs, NodeJS issues that effect the ecosystem (like node-sass vs dart-sass), and a snake oil aspect from charlatans that you see on social media (granted this is not limited to react, but it feels like react has the most of them).

My experience

1. Write some solution with out a UI

2. Decide you want a UI

3. Add React

4. Be forced to re-architect your solution because react wants control of all of your state.

React is supposed to be the V (View) in MVC but it requires full control of the M (model) in MVC and bleeds into the C (controller) as well.

Someone will likely chime in that you can just tell React to re-render the entire UI every frame or write lots of custom functions to monitor your model but that's not really the point. No other UI paradigm requires this.

When you say "write a solution without ui", do you mean "write a frontend solution without a ui"? What's a frontend solution without ui? I thought all of UI code was intended to serve the frontend.

Are you referring to Electron apps or something?

The way you can avoid this:

- design "UI struct" for what you want to display

- Have React fire off events when doing actions

- Those actions get piped into your UI-less solution

- Your UI-less solution updates the "UI struct"

- React updates the parts of the tree that was using part of your struct

if you design this struct in the right way, you can have the updates be _very_ targetted (like, React doing basically no extra work). But your UI struct needs to be really carefully set up so you're not firing things off all over the place.

I think it's still an easier problem than keeping your DOM in sync entirely, but it's unfortunately very easy to accidentally over-render still.

Hacker News is a bunch of older grumpy folks that want to keep using jQuery. Also some had a bad time with classic redux patterns that were a terrible atrocity - but also not reacts fault, however they have a strong association with each other. Modern react w/ modern state management patterns is a joy to use.

Remember too, that the loudest minority is not always right.

There are millions of developers happily using react every day. They just don't come onto HN to complain about the "woeful state" of frontend.

What is considered "modern state management" these days?

If building a SSR site with nextjs use react server components and react context

If building a SPA site with vite use tanstack/react-query and react context. There are other great libraries like zustand and jotai that can make sense in certain kinds of more complex applications.

Great to see this--there are some nice features that encourage using standard web technologies like forms, and some solid quality of life improvements.

However, I'm disappointed (but not surprised, this was listed as out of scope for 19) that triggering Suspense is still basically "use a framework that supports it." I have not been able to find any documentation or blog posts about the mechanism. I've tried to figure out how it works by looking at TanStack Query, but I've had limited success so far. I've found they're copying React's twist on Promises [1], but I haven't gotten this to work yet.

I know the general idea is you throw Promises, but Suspense explicitly forbids using promises created during rendering. This means you can't just interrupt the component's initial render to load some data, and then restart it when its data is available. This means the component needs to deal with null data somehow, instead of, e.g., being able to call a custom `useSomeData` hook and rely on it to first suspend and then return the loaded data. Not having to deal directly with loading states in individual components could simplify things quite a bit.

Has anyone explored this side of Suspense?

[1]: https://github.com/TanStack/query/blob/main/packages/query-c...

Yeah, _we library maintainers_ are feeling the same way :)

- https://bsky.app/profile/acemarke.dev/post/3lcitbmmfss2i

Big picture as I understand it:

The legacy and always-undocumented-but-everyone-knew-about-it approach was throwing a promise while rendering.

`use` still actually does the same thing, but it also attaches some extra status fields to that promise, _and_ checks to see if you're consistently passing in the _same_ promise reference.

In other words, it's the job of an external data fetching library to keep track of what query entry is being asked for, create and save a promise per cache entry _outside_ of the React component tree, and then return that promise somehow so the app developer can pass it to the `use` hook. In a sense, it's an async `Map`.

As another example of this, my former teammate Brian Vaughn (previously on the React core team) ended up building his own implementation of that behavior in the conveniently-named `suspense` package:

- https://suspense.vercel.app/

Ultimately, the `use` hook and Suspense _does_ do exactly what you're asking for - the rest of the component gets to assume the data _does_ exist, since `use` will only let the execution continue once the promise has resolved.

Oh awesome, thank you! I'll have to investigate this and play with it, but that makes sense.

here's what really matters: https://endoflife.date/react

PRs are welcome to add the new release (and merge all the 18 minor releases).

Imagine if HTML5 had an EoL.

Some day

React is very backwards compatible, so the eol is much less impactful than for say, vuejs

Is it possible to build useActionState hook based on existing built-in hooks ? If yes, why does that hook have to be built in ?

The same reason useMemo exists

Curious, has anyone tried to use React without bundler like webpack, esbuild etc?

Updates like this are exactly why React sucks.

If you're going to add something to the main project, it should be well-designed, clear, and in good taste. React won over things like Angular because the latter had poorly designed abstractions. It was supposed to be "just javascript" (which was always more of a vibe being actually true).

Just look at wtf actions are. In their blogpost[0], the old way of doing things is only a few lines more, but is much clearer. The 'useTransition' still has to update the error state - but at least it saves you from typing the pending state!

But of course, you're not supposed to use this directly, you're supposed to use useActionState. And this blog post makes it's usage very clear by just returning null to show something that's supposed to update state. So very clear, and intuitive /s

Stuff like this really should've been in a separate library. It baffles my mind that core behavior like state management is left to external solutions, but then random crap like this makes it into the main project.

[0]https://react.dev/blog/2024/12/05/react-19#actions

It would have been a different story if these features had shipped a few years ago but react query is definitely the elephant in the room here.

> the old way of doing things is only a few lines more, but is much clearer

A description fit for React itself.

Reply on news.ycombinator.com