22 ms·

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

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 :)

RexFactorem 2y ago
[dead]
lakomen 2y ago
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.
lmm 2y ago
HN has long had a huge anti-Facebook bias, I wonder if it's just that.
- alephxyz 2y ago
  I don't think so. Comments about PyTorch or llama are always extremely positive.
  - lmm 2y ago
    I didn't even know they were Facebook. Do they actually get used in Facebook-the-product in a user-facing way?
roflmuffin 2y ago
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.
- robertwt7 2y ago
  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.
  - 1shooner 2y ago
    > 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.
    - robertwt7 2y ago
      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.
terandle 2y ago
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.
- olavgg 2y ago
  I have built large and complex front-end applications with jQuery. It worked great, no complaints.
bromuro 2y ago
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.
plaguuuuuu 2y ago
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 ;)
wruza 2y ago
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.
- gejose 2y ago
  > 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.
  - wruza 2y ago
    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)
gejose 2y ago
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.
- baq 2y ago
  > I also really don't get the apparent hate for react, The hoops I have to jump through to get the back button working.
- Bilal_io 2y ago
  > 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.
- dansiemens 2y ago
  > 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.
epolanski 2y ago
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
anonzzzies 2y ago
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.
- KronisLV 2y ago
  > ...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/react https://endoflife.date/vue https://endoflife.date/vue https://endoflife.date/angular 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.
- mephitix 2y ago
  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.
deleted 2y ago
[deleted]
troad 2y ago
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.
- absqueued 2y ago
  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!!
- notapenny 2y ago
  > 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.
- nsonha 2y ago
  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.
hipadev23 2y ago
> 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 https://www.youtube.com/watch?v=b2F-DItXtZs
makingstuffs 2y ago
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.
slmjkdbtl 2y ago
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
- imbnwa 2y ago
  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.
  - craigdev 2y ago
    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.
wildpeaks 2y ago
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.
- meiraleal 2y ago
  That's exactly how React changes pushed by Vercel broke it and had the tipping point for the react fatigue we are discussing now
  - SebastianKra 2y ago
    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.
int_19h 2y ago
I think React receives a lot of negative sentiment that is really directed more at SPAs in general.
- curtisblaine 2y ago
  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.
  - azangru 2y ago
    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.
    - curtisblaine 2y ago
      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.
RomanPushkin 2y ago
> 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.
subarctic 2y ago
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.
gloosx 2y ago
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
- azangru 2y ago
  > 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...

RexFactorem 2y ago

[dead]

lakomen 2y ago

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.

lmm 2y ago

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

alephxyz 2y ago
I don't think so. Comments about PyTorch or llama are always extremely positive.
- lmm 2y ago
  I didn't even know they were Facebook. Do they actually get used in Facebook-the-product in a user-facing way?

roflmuffin 2y ago

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.

robertwt7 2y ago
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.
- 1shooner 2y ago
  > 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.
  - robertwt7 2y ago
    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.

terandle 2y ago

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.

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

bromuro 2y ago

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.

plaguuuuuu 2y ago

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 ;)

wruza 2y ago

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.

gejose 2y ago
> 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.
- wruza 2y ago
  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)

gejose 2y ago

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.

baq 2y ago
> I also really don't get the apparent hate for react, The hoops I have to jump through to get the back button working.
Bilal_io 2y ago
> 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.
dansiemens 2y ago
> 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.

epolanski 2y ago

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

anonzzzies 2y ago

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.

KronisLV 2y ago
> ...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/react https://endoflife.date/vue https://endoflife.date/vue https://endoflife.date/angular 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.
mephitix 2y ago
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.

deleted 2y ago

[deleted]

troad 2y ago

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.

absqueued 2y ago
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!!
notapenny 2y ago
> 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.
nsonha 2y ago
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.

hipadev23 2y ago

> 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 https://www.youtube.com/watch?v=b2F-DItXtZs

makingstuffs 2y ago

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.

slmjkdbtl 2y ago

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

imbnwa 2y ago
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.
- craigdev 2y ago
  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.

wildpeaks 2y ago

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.

meiraleal 2y ago
That's exactly how React changes pushed by Vercel broke it and had the tipping point for the react fatigue we are discussing now
- SebastianKra 2y ago
  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.

int_19h 2y ago

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

curtisblaine 2y ago
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.
- azangru 2y ago
  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.
  - curtisblaine 2y ago
    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.

RomanPushkin 2y ago

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

subarctic 2y ago

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.

gloosx 2y ago

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

azangru 2y ago
> 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...