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 :)
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 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 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.
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 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.
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?
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.
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.
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.
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.
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?
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.
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.
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]
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.
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].
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.
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.
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.
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.
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)
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.
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.'
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.
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.
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:
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:
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.
> 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.
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.
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).
> 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 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
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.
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.
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.
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 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.
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.
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.
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.
> 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:
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.
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.
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
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.
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.
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.
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 ;)
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...
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.
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.
> 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.
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 :)