8 ms·

React is winning because its really good. Even if the cost is an extra few milliseconds of render time and few extra hours of dev time figuring out things like

by 827a 1y ago

React is winning because its really good. Even if the cost is an extra few milliseconds of render time and few extra hours of dev time figuring out things like hook dependencies. If React starts taking a backseat, it'll be because its no longer really good. And, to be fair: I've started to see this happen. Next & Vercel have totally taken over the React world, and they've proven to make quite poor architectural decisions. All great empires are destroyed from the inside, not out, and I think its possible Vercel could do this to React. But, also, even as Next seppukus itself, people will likely just fall back to React on Vite (or, there's Remix 3 that's I think still under development, but might end up being big).

apsurd 1y ago
+1 React DX is really great. It started really great and it got weird and bloated but it's still really great relative to the JS landscape hell. But, also yes, it's a pain in the ass and a frustrating kind of necessary evil. So there is room for improvements. Nextjs is a living hell. The ironic thing is AI makes it dramatically more tolerable to the point it's actually pretty good. But that can't be a good thing in terms of architectural design can it? We're in odd times. Of course, it's easy to be a hater on the sidelines. I am guilty. Nextjs likely just does too much in it's own made-from-scratch clever way. use-client vs server is just out-of-the gate ridiculous. But then I suppose the real question is "well if you want isomorphic environment, how else are you going to do it?". My answers is "I wouldn't!" but then vercel and the powers that be seem to have won the mindshare of the product crowd. At least for now.
- thomaslord 1y ago
  Honestly I think React DX kinda sucks, at least in some areas. Performance is one of the worst (`useMemo` and `componentShouldUpdate` are way to easy to ignore, constant re-renders are the norm and writing performant React code requires conscious effort to avoid footguns) but it's also just less self-explanatory than the alternatives I've tried. I started doing web dev before reactivity frameworks were a thing, and I found Vue to be the most intuitive of the frameworks available when I first needed reactivity. To me, Vue feels like HTML with superpowers while React feels like a whole new way of thinking about webapps. I'm honestly a bit surprised that the article doesn't mention Vue, since Vue is (and has been for a while) the most popular "not React or Angular" framework option. Newer versions of Vue even support the "disappearing framework" feature Svelte was built for, which I'm excited to take advantage of when my biggest work project finally moves to Vue 3.
  - apsurd 1y ago
    I think you've nailed it. It does come down to user preference. React _is_ a whole new way of thinking. Back in the days of jQuery it was very painful to stitch together web experience across HTML+CSS+JS. jquery provided much needed DX around utilities to navigate across these pieces. But it was still way too easy to treat HTML like your database and model user-state across a Frankenstein of server, json, html, and javascript. React was a paradigm shift. "Screw it, everything is javascript." The web depends on js runtime, we know we're going to need it. It starts to makes the best future-forward sense to use the only full programming runtime available. From DX pov this was spectacular to speed up prototyping. And you can finally truly model state purely from data. What followed was a huge a mess (redux), but I always say, what do we expect? The web is a mess, and it's great because it's useful. Humans are a mess! --- VUE: similar to angular I just don't align with "super-powered html attributes". It just doesn't make sense as a mental model. Because it's _not_ HTML spec and HTML is not a programming language. The more powerful the framework gets the more we reinvent a pseudo-programming language _through_ HTML. Angular was full-stop a no-go when I first saw it's for-loops in HTML.
    - recursive 1y ago
      Neither react's JSX nor vue's template language are HTML. But rejecting vue's template on grounds that it's not HTML seems odd. React's JSX deviates from HTML in many ways. Like class vs className. XML self-closing vs HTML self-closing. onchange vs oninput. On purely aesthetic grounds, I can't understand how the react idiom of array.map() would ever be preferable to an affordance in the (non-HTML) template language for handling this normal standard thing that always happens.
      - apsurd 1y ago
        it's not about feigning html purity it's the opposite. Why pretend we're using HTML when it's not? so with react it becomes a js flavor, jsx, which some people hate but it's very clear that it's a made up language IN real javascript. edit: the mental model is instant: it's just javascript for reals. do anything you want in javascript using real js primitives. it's not about looking pretty, jsx doesn't. it's about not relearning basic programming primitives in a made up _markup_ language. my issue with angular is it's neither real html nor any programming language. its made up pseudo-programming language for no other reason than it fools people into thinking "it's just HTML". that's my gripe.
- jjordan 1y ago
  I don't really recommend isomorphic environments, but if it's your cup of tea, Tanstack Start is making a lot of progress. It removes all of the magic and misdirection of Nextjs and just provides a good light alternative.
  - koakuma-chan 1y ago
    AFAIK "TanStack" doesn't support RSCs? That's a deal breaker for me. Also the guy named his framework after himself, it can't be good.
    - staminade 1y ago
      Linus named Linux after himself, it can't be good!
    - collingreen 1y ago
      Linux also sucks for this reason /s
    - presentation 1y ago
      They built a half baked version of it and then haven’t finished it for a while but maybe they’ll get back to it sometime.
    - Swizec 1y ago
      For the record, the TanStack name comes from the community. Eventually Tanner stopped fighting back and made it official
    - jjordan 1y ago
      What do you get from RSCs that you don't get from creating a proper backend?
      - koakuma-chan 1y ago
        Having to glue the front-end and the back-end together.
- AlexErrant 1y ago
  React DX is hot garbage. Words cannot express how much I LOATHE hook rules. Coming from a Solid JS background, where reactive primitives are just Javascript functions... I groan every single time I run into (yet another) hook rule. I have to conditionally render empty fragments because React can't handle conditional hooks. It's the stupidest thing ever. "Oh hey let me allocate memory for this hook that will almost certainly never be used except under edge conditions! Sure, React can do conditional components, but conditional hooks are just too much for us!"
  - dgfitz 1y ago
    I read things like this and think “I am so glad I don’t write JavaScript/ web-anything for a living”
    - collingreen 1y ago
      cries in ts backend, react frontend, react-mobile client
  - b_e_n_t_o_n 1y ago
    Hooks are also just JavaScript functions...?
    - thomasfromcdnjs 1y ago
      They kind of are not though, you can't call them out of order and other things which is checked at runtime by the React "engine" and will stop script execution. If they were regular functions you could call them anytime.
      - b_e_n_t_o_n 1y ago
        Many "regular" functions are context dependent.
        DangitBobby 1y ago
- 827a 1y ago
  Next initially jumped the shark when they went all-in on server-side rendering. The reason why Vercel did this is clear: client-side rendered apps can be hosted basically for free on Firebase, Cloudflare, or S3, so the only way they can raise their Vercel cloud revenue is by forcing their users into a dynamic-first world, pushing so much complexity and dynamism into the framework that only Vercel could disentangle how to host it effectively. The less-dystopic reasons they communicated as to why customers might want SSR; improved time-to-first-byte and a more PHP/Rails-like programming model; while well-intentioned, ultimately became of questionable value to customers given their choices during implementation. I do actually believe a more PHP/Rails-like programming model would be beneficial for React; Vercel just missed the extremely important detail in how Rails is so dang productive. Its not their decisions when it comes to HTML templating; its Active Record.
  - Seattle3503 1y ago
    I had a friend rave to me about Next because, to him, page load times were absolutely essential for good search engine placement. I wonder LLMs will make this sort of SEO less important.
- Nathanba 1y ago
  React DX is probably the worst DX of all frontend frameworks I've ever seen. All kinds of confusing concepts (hooks, memo, props passing, class style vs function style, an entire new "language" like JSX which you then first need to install an IDE extension for) and you cant even begin a react project most of the time without using some kind of react starter template because building this thing is so hugely complex that people just give up. Then you constantly run into issues of double rendering with reactjs which is quite hard to debug. I was hoping for something tiny like https://www.arrow-js.com/ https://www.arrow-js.com/ taking off but the creator doesn't really work on it.
sapiogram 1y ago
What is Vercel doing to React? I just know them as a simple hosting solution.
- CBLT 1y ago
  Vercel is anything but simple. Easy? Sure.
- postalrat 1y ago
  They developed next.js
  - sapiogram 1y ago
    Thank you, that's really all the context I needed.
- latchkey 1y ago
  At least in my own experience, I tried building a relatively simple static SPA NextJS React app with their router, and wanted to host it on CloudFlare Pages. It ran locally in dev mode just fine. Once I deployed it on CFP, the router broke. No errors in the console, it just didn't work. If I'm forced to use Vercel to make a simple SPA work, which then forced me into paying for their service, that's the problem.
  - byteCoder 1y ago
    OpenNext on Cloudflare is the only way I've successfully gotten NextJS to work in a Cloudflare Worker. https://opennext.js.org/cloudflare https://opennext.js.org/cloudflare
    - latchkey 1y ago
      Interesting. Yea, I didn't want a worker, just a static html page with my javascript.
      - 1y ago
timeon 1y ago
> Even if the cost is an extra few milliseconds of render time These things are adding up. Web would be much more pleasant without React. There are many better options out there.
- 827a 1y ago
  Maybe it would be, but I would also make a significant bet that the web would be noticeably less sophisticated without React. React is complicated, and builds complicated apps, and has its performance pitfalls, but it is also a driving force for how the web has been able to achieve native-class user experiences. Its the right programming model for building complicated things.
  - ricardobeat 1y ago
    Websites were much more varied and creative in the jQuery era, and even more so in the Flash era that came before. Different interaction paradigms, wild animations, full-screen effects, etc etc. Not necessarily "better", but React didn't really enable anything we couldn't have before - even today when real performance is required you will resort to canvas/webgl, alternative rendering approaches and skipping react's render cycle. React was never [1] fast [2] - that is one of the biggest misconceptions in frontend development in the last decade. [2] https://css-tricks.com/radeventlistener-a-tale-of-client-side-framework-performance/ https://css-tricks.com/radeventlistener-a-tale-of-client-sid... [1] https://www.zachleat.com/web/react-criticism/ https://www.zachleat.com/web/react-criticism/
    - scrollaway 1y ago
      I wrote websites in the jquery era. I wrote web apps back then. Gaming tools, databases, tons of dynamic stuff. When I used react for the first time I cried with “where has this been all my life? It would have saved me years of work”. Whenever I see claims like yours I always have hardcore doubts. React may not have “enabled” new things just like ai coding doesn’t “enable” new things … as long as you consider time to be in infinite supply. If you care about getting shit done, there is no comparison.
giveita 1y ago
Maybe us backenders help. If I need to do front end I learn as little as possible. React does the job. It could have been Angular that ended up being in the boring throne, and I would have said just use Angular. Just use what the world uses!
- ForHackernews 1y ago
  Angular is so much nicer and more batteries-included than React. React somehow manages to be massively yet incomplete: add a router, add state management, add react-hook-form...
  - cheesekunator 1y ago
    This is very true and almost nobody sees it...
    - spartanatreyu 1y ago
      Angular is used a lot in enterprise apps/services when they need a low risk one-way to do things (e.g. Apple's App Store developer portal). React is used in enterprise when teams need to move fast and break things (e.g. Microsoft Edge's UI after switching from Trident/Spartan/EdgeHTML to Chromium) and tend to be replaced with something else when dev teams / managers realise that they need to rebuild it anyway just to keep it maintained and/or gain more performance. (e.g. Edge "WebUI 2.0" moving their browser UI from react to web components) Vue is used a lot in Asian enterprise markets.
  - ChromaticPanic 1y ago
    That's why it's so good. You can pick what you want instead of being told what to do.
    - jiggawatts 1y ago
      https://en.wikipedia.org/wiki/The_Paradox_of_Choice https://en.wikipedia.org/wiki/The_Paradox_of_Choice In practice, at scale, in an ecosystem instead of a toy project, excessive choice is counterintuitively a bad thing. It's hugely beneficial to have common ground and shared interfaces when integrating code from third parties, or collaborating across multiple teams. > You can pick A golden rule of large enterprise is that there is no "you". As soon as there are two people working independently, not to mention different business units or teams, different choices will be made. Incompatible choices.
s1mplicissimus 1y ago
funny you should mention react on vite - i migrated a web-app to that setup ~3 years ago and never even considered looking back. react is still a trusty workhorse that assists me in getting things done, the ecosystem is rich (i'll take the varying quality as a given for one this size). I've been toying around with next a couple years ago, followed their development for some time, then decided they are not doing what I need. Isometric rendering turns out to sound way better than it actually is. The pain doesn't come from different programming languages on front- and backend, it comes from the difficulty of reconciling client state, server state, security etc. I actually find it helpful to have specialized languages for each side, rather than having to figure out for each piece of code wether its supposed to run on my server or in the browser.
ForHackernews 1y ago
How is it good? I've only had the misfortune of working on two React apps, but they were both a nightmare. It seems like React is great if you have multiple teams that hate each other all working on the same giant frontend app. https://medium.com/@fulalas/web-crap-has-taken-control-71c459df6e62 https://medium.com/@fulalas/web-crap-has-taken-control-71c45...
- the_gipsy 1y ago
  It's good because it's popular, which doesn't really mean it's good. See Java. It works and rakes in billions, but it still may be utter shit from an engineering viewpoint.
thinkxl 1y ago
If React implodes because of bad architectural decisions, Vite should fork it. It's crazy that the best React DX is provided through Vue's community projects.
- rTX5CMRXIfFG 1y ago
  Why don’t we just switch over to Vue? If DX is such a driver for deciding to use a web framework, Vue kicks React’s ass, and that’s just objectively speaking.
  - mythrwy 1y ago
    I did switch over to Vue. Well not technically switch, I never learned React properly because I didn't like it when it first came out and by the time I gave it a second look there were already a gazillion React devs so I just stuck with Vue. Vue just seems much more intuitive and sane to me. Sane is relative for front end frameworks of course. Don't get me started on Angular I got PTSD and couldn't code for a couple of months from a large Angular project with an offshore team. I do get the benefit of using these framework for teams, and they are nifty once you get what is happening, but I still scratch my head when I see all the steps and files to do simple things I used to bang out in a few dozen lines of jQuery.
  - thinkxl 1y ago
    One of the greatest things of the Vue community is that they are not dogmatic about a technology choice. They welcome everyone, and proof of that is that they are building tooling that benefit everyone not only their community. So, we can switch over to Vue whenever we want. I personally prefer React and I'm super grateful of Vite and their ecosystem.
ricardobeat 1y ago
> if the cost is an extra few milliseconds of render time and few extra hours of dev time That is very optimistic. Most React projects never get to the optimization stage, and end up with seconds of rendering and transition delays that significantly harm UX. And the amount of time spent battling hooks, re-renders, compatibility issues, etc amounts to hundreds of hours over the course of a medium-sized project, thousands for larger companies.
- alpinisme 1y ago
  “Most” react apps needing “seconds” definitely needs some citation or evidence. Even in fairly heavy and laggy react apps, it’s still usually network latency, waterfall requests, ad/tracking bloatware, large asset sizes, and the usual old classics that cause perceptible slowness in my experience.
  - nazgul17 1y ago
    In my humble (backender) opinion, if it's hard to use a tool right, that counts as a cons, and that must be accounted for when choosing which tool to use.
    - nosefurhairdo 1y ago
      It's hard to build non-trivial web UI with any technology—React is just what's familiar. If Angular had won (god forbid) we'd be seeing all the same articles written about how bad Angular is.
  - mmis1000 1y ago
    You probably never see what reddit like after it just get rewrite. https://www.reddit.com/r/bugs/comments/rj0u77/reddit_redesign_has_very_high_cpu_usage_during/ https://www.reddit.com/r/bugs/comments/rj0u77/reddit_redesig... I won't say most react apps performs like this. But it's what you will get if you ship a big react app without optimization at all. Other framework mostly have a much saner default (for example, component without argument change does not re-render). So it will work well (not best though) even in large scale. But in react they are all opt-in.
willsmith72 1y ago
Remix v3 isn't react though, the alternative is react router 7 React router have completely bungled their marketing and PR, but they still make the best web framework out there
sarchertech 1y ago
If react adds extra render time and extra dev time, what is it saving?
- ummonk 1y ago
  Time spent implementing features / components that don’t exist for the alternative framework of choice, or trying to figure out a framework bug in your own because there aren’t enough other developers using the framework to have surfaced and resolved all the bugs.
ern 1y ago
Maybe I'm stupid, but as I recall, React hooks were quite complicated. It's been a few years since I wrote production front-end code, but it felt like some kind of high IQ/elitist barrier.
LAC-Tech 1y ago
A front end web framework with global state management should be a last resort for a website. Coming out of the gate with it is just ridiculous IMO. Most peoples websites are just not that complex. There's like an escalation ladder in my mind: - just write HTML - statically generate the HTML - dynamically generate the HTML - dynamically generate the HTML at a smaller granularity (HTMX et all) - augment your HTML with custom web components that have client side behaviour. Only if you've exhausted that should you bother with something like React. And even then SolidJS does a much better job of it than react itself does. So yeah, I am just not seeing it. Former (and perhaps future!) React.JS dev btw.
- e_y_ 1y ago
  To be nitpicky, React itself does not specify that state management must be global. It was a popular pattern, starting with Facebook's blog post on Flux and made popular by Redux. And certain newer features like hydration/SSR and suspense more or less require a global store because their data can't be kept in the tree. But in many cases you can keep state local with useState and Recoil/Jotai and frameworks that keep global state/caches abstracted away like TanStack Query. For progressive enhancement, I like the island approach used by Astro. I do think that most developers are not just building static sites though. And if you're generating HTML on the server side and then updating it dynamically on the client, having two different languages (Java/Go/Python on the backend, JS on the frontend) becomes messy pretty quick. There are times where you should build the simplest solution that meets your needs, and times when you should think ahead to future use cases so you don't box yourself into a corner. And picking a framework is a big part of that process.
  - apsurd 1y ago
    fwiw i've never experienced the drawback of separate languages for server and client. nor did i ever experience the benefit of single language across server and client. being forced to use javascript on the server sounds like a cruel joke vs a benefit. I mean just simply from "i can literally pick anything for my controlled server env" vs "no we're a js shop cuz web" edit to add: is it one repo? or maybe shared types. typescript is probably the strongest argument. can enforce integrity truly across the stack. but i don't think that's worth being forced into js environment and packages. community is forced to reimplement everything in js. no good.
rtpg 1y ago
My main complaint about React is the sort of lackluster quality of loads of React-adjacent libraries, by people who seem obsessed with "we're doing Yet Another Rewrite and a major version bump". It's not that hard to maintain API stability folks! Try a bit harder!
hardwaregeek 1y ago
Remix 3 appears to not be based on React. The React Router/Remix people write great libraries. The problem is that they're constantly chasing the next great library. By the time you use their latest creation, they've already started making a new library that they'll tweet about
zachwill 1y ago
Super insightful. I hadn’t been able to articulate the same feelings. Even as Next seppukus itself, people will likely just fall back to React on Vite… This is my exact read on the situation, as well. I’m not sure if anything can meaningful affect React’s domination in the short-term or medium-term, even with the accumulation of poor choices.
- chamomeal 1y ago
  I haven’t tried tanstack-start, but I wouldn’t be surprised it becomes the defacto react framework instead of next. Everything by Tanner Linsley is just so well thought out and the DX is amazing. If his framework is the same level of quality, without any major gaps compared to next, it will probably blow next out of the water. And Tanner is already a huge name in the typescript/react world, so I think there is actually a chance.
  - tannerlinsley 1y ago
    Thank you for your kind words and support!
AcquiescentWolf 1y ago
React is popular in the modern days only because, well, it's popular. Developers use it because companies use it, and companies use it because developers use it. It's not popular because it's better than all the alternatives, it's just that it has reached critical mass, and it's now "too big to fail". It takes constant effort to avoid React's many footguns. Supporters often call this a “skill issue,” but even if that’s true, why wouldn’t you prefer a framework that does the same things with less code, faster, and with far less mental overhead?
overgard 1y ago
I'm not sure I'd say that React's DX is actually that great. I've watched C++ developers come over from using QT and the learning curve is massive. Plus almost all the bugs come from dealing with React's renders. I think React by default is weird because most things don't actually need that degree of reactivity. Like, if most of the time only one thing is displaying or updating a value React just adds a lot of headache. And the amount of useEffect I see? (By necessity mind you) with the need for linters in order to figure out if you missed something in a dependency list.. I just think it's the wrong model for most projects
iammrpayments 1y ago
Mcdonalds is really good. Even if the cost is an extra few pounds and increased chance of getting cancer. If Mcdonalds starts taking a backseat, it’ll because its no longer really good. And, to be fair: I’ve started to see this happen. Mcdonalds & Coca-Cola have totally taken over the food industry world, and they’ve proven to make quite poor nutritional decisions. All great empires are destroyed from the inside, not out, and I think its possible Coca cola could do this to Mcdonalds. But also even as Coca-Cola seppukus itself, people will likely just fallback to Mcdonalds on Pepsi (or, there’s Pepsi Zero Sugar that’s I think still under development, but might end up being big).

by 827a 1y ago

apsurd 1y ago

+1 React DX is really great. It started really great and it got weird and bloated but it's still really great relative to the JS landscape hell. But, also yes, it's a pain in the ass and a frustrating kind of necessary evil. So there is room for improvements. Nextjs is a living hell. The ironic thing is AI makes it dramatically more tolerable to the point it's actually pretty good. But that can't be a good thing in terms of architectural design can it? We're in odd times. Of course, it's easy to be a hater on the sidelines. I am guilty. Nextjs likely just does too much in it's own made-from-scratch clever way. use-client vs server is just out-of-the gate ridiculous. But then I suppose the real question is "well if you want isomorphic environment, how else are you going to do it?". My answers is "I wouldn't!" but then vercel and the powers that be seem to have won the mindshare of the product crowd. At least for now.

thomaslord 1y ago
Honestly I think React DX kinda sucks, at least in some areas. Performance is one of the worst (`useMemo` and `componentShouldUpdate` are way to easy to ignore, constant re-renders are the norm and writing performant React code requires conscious effort to avoid footguns) but it's also just less self-explanatory than the alternatives I've tried. I started doing web dev before reactivity frameworks were a thing, and I found Vue to be the most intuitive of the frameworks available when I first needed reactivity. To me, Vue feels like HTML with superpowers while React feels like a whole new way of thinking about webapps. I'm honestly a bit surprised that the article doesn't mention Vue, since Vue is (and has been for a while) the most popular "not React or Angular" framework option. Newer versions of Vue even support the "disappearing framework" feature Svelte was built for, which I'm excited to take advantage of when my biggest work project finally moves to Vue 3.
- apsurd 1y ago
  I think you've nailed it. It does come down to user preference. React _is_ a whole new way of thinking. Back in the days of jQuery it was very painful to stitch together web experience across HTML+CSS+JS. jquery provided much needed DX around utilities to navigate across these pieces. But it was still way too easy to treat HTML like your database and model user-state across a Frankenstein of server, json, html, and javascript. React was a paradigm shift. "Screw it, everything is javascript." The web depends on js runtime, we know we're going to need it. It starts to makes the best future-forward sense to use the only full programming runtime available. From DX pov this was spectacular to speed up prototyping. And you can finally truly model state purely from data. What followed was a huge a mess (redux), but I always say, what do we expect? The web is a mess, and it's great because it's useful. Humans are a mess! --- VUE: similar to angular I just don't align with "super-powered html attributes". It just doesn't make sense as a mental model. Because it's _not_ HTML spec and HTML is not a programming language. The more powerful the framework gets the more we reinvent a pseudo-programming language _through_ HTML. Angular was full-stop a no-go when I first saw it's for-loops in HTML.
  - recursive 1y ago
    Neither react's JSX nor vue's template language are HTML. But rejecting vue's template on grounds that it's not HTML seems odd. React's JSX deviates from HTML in many ways. Like class vs className. XML self-closing vs HTML self-closing. onchange vs oninput. On purely aesthetic grounds, I can't understand how the react idiom of array.map() would ever be preferable to an affordance in the (non-HTML) template language for handling this normal standard thing that always happens.
    - apsurd 1y ago
      it's not about feigning html purity it's the opposite. Why pretend we're using HTML when it's not? so with react it becomes a js flavor, jsx, which some people hate but it's very clear that it's a made up language IN real javascript. edit: the mental model is instant: it's just javascript for reals. do anything you want in javascript using real js primitives. it's not about looking pretty, jsx doesn't. it's about not relearning basic programming primitives in a made up _markup_ language. my issue with angular is it's neither real html nor any programming language. its made up pseudo-programming language for no other reason than it fools people into thinking "it's just HTML". that's my gripe.
jjordan 1y ago
I don't really recommend isomorphic environments, but if it's your cup of tea, Tanstack Start is making a lot of progress. It removes all of the magic and misdirection of Nextjs and just provides a good light alternative.
- koakuma-chan 1y ago
  AFAIK "TanStack" doesn't support RSCs? That's a deal breaker for me. Also the guy named his framework after himself, it can't be good.
  - staminade 1y ago
    Linus named Linux after himself, it can't be good!
  - collingreen 1y ago
    Linux also sucks for this reason /s
  - presentation 1y ago
    They built a half baked version of it and then haven’t finished it for a while but maybe they’ll get back to it sometime.
  - Swizec 1y ago
    For the record, the TanStack name comes from the community. Eventually Tanner stopped fighting back and made it official
  - jjordan 1y ago
    What do you get from RSCs that you don't get from creating a proper backend?
    - koakuma-chan 1y ago
      Having to glue the front-end and the back-end together.
AlexErrant 1y ago
React DX is hot garbage. Words cannot express how much I LOATHE hook rules. Coming from a Solid JS background, where reactive primitives are just Javascript functions... I groan every single time I run into (yet another) hook rule. I have to conditionally render empty fragments because React can't handle conditional hooks. It's the stupidest thing ever. "Oh hey let me allocate memory for this hook that will almost certainly never be used except under edge conditions! Sure, React can do conditional components, but conditional hooks are just too much for us!"
- dgfitz 1y ago
  I read things like this and think “I am so glad I don’t write JavaScript/ web-anything for a living”
  - collingreen 1y ago
    cries in ts backend, react frontend, react-mobile client
- b_e_n_t_o_n 1y ago
  Hooks are also just JavaScript functions...?
  - thomasfromcdnjs 1y ago
    They kind of are not though, you can't call them out of order and other things which is checked at runtime by the React "engine" and will stop script execution. If they were regular functions you could call them anytime.
    - b_e_n_t_o_n 1y ago
      Many "regular" functions are context dependent.
      - DangitBobby 1y ago
827a 1y ago
Next initially jumped the shark when they went all-in on server-side rendering. The reason why Vercel did this is clear: client-side rendered apps can be hosted basically for free on Firebase, Cloudflare, or S3, so the only way they can raise their Vercel cloud revenue is by forcing their users into a dynamic-first world, pushing so much complexity and dynamism into the framework that only Vercel could disentangle how to host it effectively. The less-dystopic reasons they communicated as to why customers might want SSR; improved time-to-first-byte and a more PHP/Rails-like programming model; while well-intentioned, ultimately became of questionable value to customers given their choices during implementation. I do actually believe a more PHP/Rails-like programming model would be beneficial for React; Vercel just missed the extremely important detail in how Rails is so dang productive. Its not their decisions when it comes to HTML templating; its Active Record.
- Seattle3503 1y ago
  I had a friend rave to me about Next because, to him, page load times were absolutely essential for good search engine placement. I wonder LLMs will make this sort of SEO less important.
Nathanba 1y ago
React DX is probably the worst DX of all frontend frameworks I've ever seen. All kinds of confusing concepts (hooks, memo, props passing, class style vs function style, an entire new "language" like JSX which you then first need to install an IDE extension for) and you cant even begin a react project most of the time without using some kind of react starter template because building this thing is so hugely complex that people just give up. Then you constantly run into issues of double rendering with reactjs which is quite hard to debug. I was hoping for something tiny like https://www.arrow-js.com/ https://www.arrow-js.com/ taking off but the creator doesn't really work on it.

sapiogram 1y ago

What is Vercel doing to React? I just know them as a simple hosting solution.

CBLT 1y ago
Vercel is anything but simple. Easy? Sure.
postalrat 1y ago
They developed next.js
- sapiogram 1y ago
  Thank you, that's really all the context I needed.
latchkey 1y ago
At least in my own experience, I tried building a relatively simple static SPA NextJS React app with their router, and wanted to host it on CloudFlare Pages. It ran locally in dev mode just fine. Once I deployed it on CFP, the router broke. No errors in the console, it just didn't work. If I'm forced to use Vercel to make a simple SPA work, which then forced me into paying for their service, that's the problem.
- byteCoder 1y ago
  OpenNext on Cloudflare is the only way I've successfully gotten NextJS to work in a Cloudflare Worker. https://opennext.js.org/cloudflare https://opennext.js.org/cloudflare
  - latchkey 1y ago
    Interesting. Yea, I didn't want a worker, just a static html page with my javascript.
    - 1y ago

timeon 1y ago

> Even if the cost is an extra few milliseconds of render time These things are adding up. Web would be much more pleasant without React. There are many better options out there.

827a 1y ago
Maybe it would be, but I would also make a significant bet that the web would be noticeably less sophisticated without React. React is complicated, and builds complicated apps, and has its performance pitfalls, but it is also a driving force for how the web has been able to achieve native-class user experiences. Its the right programming model for building complicated things.
- ricardobeat 1y ago
  Websites were much more varied and creative in the jQuery era, and even more so in the Flash era that came before. Different interaction paradigms, wild animations, full-screen effects, etc etc. Not necessarily "better", but React didn't really enable anything we couldn't have before - even today when real performance is required you will resort to canvas/webgl, alternative rendering approaches and skipping react's render cycle. React was never [1] fast [2] - that is one of the biggest misconceptions in frontend development in the last decade. [2] https://css-tricks.com/radeventlistener-a-tale-of-client-side-framework-performance/ https://css-tricks.com/radeventlistener-a-tale-of-client-sid... [1] https://www.zachleat.com/web/react-criticism/ https://www.zachleat.com/web/react-criticism/
  - scrollaway 1y ago
    I wrote websites in the jquery era. I wrote web apps back then. Gaming tools, databases, tons of dynamic stuff. When I used react for the first time I cried with “where has this been all my life? It would have saved me years of work”. Whenever I see claims like yours I always have hardcore doubts. React may not have “enabled” new things just like ai coding doesn’t “enable” new things … as long as you consider time to be in infinite supply. If you care about getting shit done, there is no comparison.

giveita 1y ago

Maybe us backenders help. If I need to do front end I learn as little as possible. React does the job. It could have been Angular that ended up being in the boring throne, and I would have said just use Angular. Just use what the world uses!

ForHackernews 1y ago
Angular is so much nicer and more batteries-included than React. React somehow manages to be massively yet incomplete: add a router, add state management, add react-hook-form...
- cheesekunator 1y ago
  This is very true and almost nobody sees it...
  - spartanatreyu 1y ago
    Angular is used a lot in enterprise apps/services when they need a low risk one-way to do things (e.g. Apple's App Store developer portal). React is used in enterprise when teams need to move fast and break things (e.g. Microsoft Edge's UI after switching from Trident/Spartan/EdgeHTML to Chromium) and tend to be replaced with something else when dev teams / managers realise that they need to rebuild it anyway just to keep it maintained and/or gain more performance. (e.g. Edge "WebUI 2.0" moving their browser UI from react to web components) Vue is used a lot in Asian enterprise markets.
- ChromaticPanic 1y ago
  That's why it's so good. You can pick what you want instead of being told what to do.
  - jiggawatts 1y ago
    https://en.wikipedia.org/wiki/The_Paradox_of_Choice https://en.wikipedia.org/wiki/The_Paradox_of_Choice In practice, at scale, in an ecosystem instead of a toy project, excessive choice is counterintuitively a bad thing. It's hugely beneficial to have common ground and shared interfaces when integrating code from third parties, or collaborating across multiple teams. > You can pick A golden rule of large enterprise is that there is no "you". As soon as there are two people working independently, not to mention different business units or teams, different choices will be made. Incompatible choices.

s1mplicissimus 1y ago

funny you should mention react on vite - i migrated a web-app to that setup ~3 years ago and never even considered looking back. react is still a trusty workhorse that assists me in getting things done, the ecosystem is rich (i'll take the varying quality as a given for one this size). I've been toying around with next a couple years ago, followed their development for some time, then decided they are not doing what I need. Isometric rendering turns out to sound way better than it actually is. The pain doesn't come from different programming languages on front- and backend, it comes from the difficulty of reconciling client state, server state, security etc. I actually find it helpful to have specialized languages for each side, rather than having to figure out for each piece of code wether its supposed to run on my server or in the browser.

ForHackernews 1y ago

How is it good? I've only had the misfortune of working on two React apps, but they were both a nightmare. It seems like React is great if you have multiple teams that hate each other all working on the same giant frontend app. https://medium.com/@fulalas/web-crap-has-taken-control-71c459df6e62 https://medium.com/@fulalas/web-crap-has-taken-control-71c45...

the_gipsy 1y ago
It's good because it's popular, which doesn't really mean it's good. See Java. It works and rakes in billions, but it still may be utter shit from an engineering viewpoint.

thinkxl 1y ago

If React implodes because of bad architectural decisions, Vite should fork it. It's crazy that the best React DX is provided through Vue's community projects.

rTX5CMRXIfFG 1y ago
Why don’t we just switch over to Vue? If DX is such a driver for deciding to use a web framework, Vue kicks React’s ass, and that’s just objectively speaking.
- mythrwy 1y ago
  I did switch over to Vue. Well not technically switch, I never learned React properly because I didn't like it when it first came out and by the time I gave it a second look there were already a gazillion React devs so I just stuck with Vue. Vue just seems much more intuitive and sane to me. Sane is relative for front end frameworks of course. Don't get me started on Angular I got PTSD and couldn't code for a couple of months from a large Angular project with an offshore team. I do get the benefit of using these framework for teams, and they are nifty once you get what is happening, but I still scratch my head when I see all the steps and files to do simple things I used to bang out in a few dozen lines of jQuery.
- thinkxl 1y ago
  One of the greatest things of the Vue community is that they are not dogmatic about a technology choice. They welcome everyone, and proof of that is that they are building tooling that benefit everyone not only their community. So, we can switch over to Vue whenever we want. I personally prefer React and I'm super grateful of Vite and their ecosystem.

ricardobeat 1y ago

> if the cost is an extra few milliseconds of render time and few extra hours of dev time That is very optimistic. Most React projects never get to the optimization stage, and end up with seconds of rendering and transition delays that significantly harm UX. And the amount of time spent battling hooks, re-renders, compatibility issues, etc amounts to hundreds of hours over the course of a medium-sized project, thousands for larger companies.

alpinisme 1y ago
“Most” react apps needing “seconds” definitely needs some citation or evidence. Even in fairly heavy and laggy react apps, it’s still usually network latency, waterfall requests, ad/tracking bloatware, large asset sizes, and the usual old classics that cause perceptible slowness in my experience.
- nazgul17 1y ago
  In my humble (backender) opinion, if it's hard to use a tool right, that counts as a cons, and that must be accounted for when choosing which tool to use.
  - nosefurhairdo 1y ago
    It's hard to build non-trivial web UI with any technology—React is just what's familiar. If Angular had won (god forbid) we'd be seeing all the same articles written about how bad Angular is.
- mmis1000 1y ago
  You probably never see what reddit like after it just get rewrite. https://www.reddit.com/r/bugs/comments/rj0u77/reddit_redesign_has_very_high_cpu_usage_during/ https://www.reddit.com/r/bugs/comments/rj0u77/reddit_redesig... I won't say most react apps performs like this. But it's what you will get if you ship a big react app without optimization at all. Other framework mostly have a much saner default (for example, component without argument change does not re-render). So it will work well (not best though) even in large scale. But in react they are all opt-in.

willsmith72 1y ago

Remix v3 isn't react though, the alternative is react router 7 React router have completely bungled their marketing and PR, but they still make the best web framework out there

sarchertech 1y ago

If react adds extra render time and extra dev time, what is it saving?

ummonk 1y ago
Time spent implementing features / components that don’t exist for the alternative framework of choice, or trying to figure out a framework bug in your own because there aren’t enough other developers using the framework to have surfaced and resolved all the bugs.

ern 1y ago

Maybe I'm stupid, but as I recall, React hooks were quite complicated. It's been a few years since I wrote production front-end code, but it felt like some kind of high IQ/elitist barrier.

LAC-Tech 1y ago

A front end web framework with global state management should be a last resort for a website. Coming out of the gate with it is just ridiculous IMO. Most peoples websites are just not that complex. There's like an escalation ladder in my mind: - just write HTML - statically generate the HTML - dynamically generate the HTML - dynamically generate the HTML at a smaller granularity (HTMX et all) - augment your HTML with custom web components that have client side behaviour. Only if you've exhausted that should you bother with something like React. And even then SolidJS does a much better job of it than react itself does. So yeah, I am just not seeing it. Former (and perhaps future!) React.JS dev btw.

e_y_ 1y ago
To be nitpicky, React itself does not specify that state management must be global. It was a popular pattern, starting with Facebook's blog post on Flux and made popular by Redux. And certain newer features like hydration/SSR and suspense more or less require a global store because their data can't be kept in the tree. But in many cases you can keep state local with useState and Recoil/Jotai and frameworks that keep global state/caches abstracted away like TanStack Query. For progressive enhancement, I like the island approach used by Astro. I do think that most developers are not just building static sites though. And if you're generating HTML on the server side and then updating it dynamically on the client, having two different languages (Java/Go/Python on the backend, JS on the frontend) becomes messy pretty quick. There are times where you should build the simplest solution that meets your needs, and times when you should think ahead to future use cases so you don't box yourself into a corner. And picking a framework is a big part of that process.
- apsurd 1y ago
  fwiw i've never experienced the drawback of separate languages for server and client. nor did i ever experience the benefit of single language across server and client. being forced to use javascript on the server sounds like a cruel joke vs a benefit. I mean just simply from "i can literally pick anything for my controlled server env" vs "no we're a js shop cuz web" edit to add: is it one repo? or maybe shared types. typescript is probably the strongest argument. can enforce integrity truly across the stack. but i don't think that's worth being forced into js environment and packages. community is forced to reimplement everything in js. no good.

rtpg 1y ago

My main complaint about React is the sort of lackluster quality of loads of React-adjacent libraries, by people who seem obsessed with "we're doing Yet Another Rewrite and a major version bump". It's not that hard to maintain API stability folks! Try a bit harder!

hardwaregeek 1y ago

Remix 3 appears to not be based on React. The React Router/Remix people write great libraries. The problem is that they're constantly chasing the next great library. By the time you use their latest creation, they've already started making a new library that they'll tweet about

zachwill 1y ago

Super insightful. I hadn’t been able to articulate the same feelings. Even as Next seppukus itself, people will likely just fall back to React on Vite… This is my exact read on the situation, as well. I’m not sure if anything can meaningful affect React’s domination in the short-term or medium-term, even with the accumulation of poor choices.

chamomeal 1y ago
I haven’t tried tanstack-start, but I wouldn’t be surprised it becomes the defacto react framework instead of next. Everything by Tanner Linsley is just so well thought out and the DX is amazing. If his framework is the same level of quality, without any major gaps compared to next, it will probably blow next out of the water. And Tanner is already a huge name in the typescript/react world, so I think there is actually a chance.
- tannerlinsley 1y ago
  Thank you for your kind words and support!

AcquiescentWolf 1y ago

React is popular in the modern days only because, well, it's popular. Developers use it because companies use it, and companies use it because developers use it. It's not popular because it's better than all the alternatives, it's just that it has reached critical mass, and it's now "too big to fail". It takes constant effort to avoid React's many footguns. Supporters often call this a “skill issue,” but even if that’s true, why wouldn’t you prefer a framework that does the same things with less code, faster, and with far less mental overhead?

overgard 1y ago

I'm not sure I'd say that React's DX is actually that great. I've watched C++ developers come over from using QT and the learning curve is massive. Plus almost all the bugs come from dealing with React's renders. I think React by default is weird because most things don't actually need that degree of reactivity. Like, if most of the time only one thing is displaying or updating a value React just adds a lot of headache. And the amount of useEffect I see? (By necessity mind you) with the need for linters in order to figure out if you missed something in a dependency list.. I just think it's the wrong model for most projects

iammrpayments 1y ago

Mcdonalds is really good. Even if the cost is an extra few pounds and increased chance of getting cancer. If Mcdonalds starts taking a backseat, it’ll because its no longer really good. And, to be fair: I’ve started to see this happen. Mcdonalds & Coca-Cola have totally taken over the food industry world, and they’ve proven to make quite poor nutritional decisions. All great empires are destroyed from the inside, not out, and I think its possible Coca cola could do this to Mcdonalds. But also even as Coca-Cola seppukus itself, people will likely just fallback to Mcdonalds on Pepsi (or, there’s Pepsi Zero Sugar that’s I think still under development, but might end up being big).