20 ms·

React 19 almost made the internet slower

202 points by henriqueinonhe 2y ago

0xblinq 2y ago
I'm so done with React. Since Vercel kidnapped it everything is done for/because of their platform and their interests. Most evil company I've seen in a long time.
- Capricorn2481 2y ago
  What's a negative development in React that was only for Vercel?
- hipadev23 2y ago
  An innocent dev was just overcharged $5k by Vercel while reading your comment.
- STRiDEX 2y ago
  driven by facebook in this case https://x.com/sophiebits/status/1800966114048147495 https://x.com/sophiebits/status/1800966114048147495
  - MBCook 2y ago
    So they made the choice that worked well in the mega-scale application they tested with and performed worse with the pattern they didn’t think was too widely used/would be much of a problem. And it would make planned future features easier. That sounds 100% reasonable. Someone noticed it, pointed out it was a big problem for them and enough others it got reverted. That seems 100% reasonable too.
- realusername 2y ago
  The whole js ecosystem is insanity, React isn't even the worst offender, it's a machine to generate complexity. My controversial opinion is still the same, the less front-end you have in your stack, the easiest you'll be able to scale.
  - rglover 2y ago
    Yargh, there still be some sanity left on these seas [1]. [1] https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick
  - whoknowsidont 2y ago
    >The whole js ecosystem is insanity This is such a lazy, grandstandy, unoriginal take. >My controversial opinion is still the same It's not controversial it's just tired and ignorant.
    - realusername 2y ago
      > It's not controversial it's just tired and ignorant Tired maybe but not ignorant since I helped to maintain two React SPAs for 6 years now so I'm pretty aware how bad it is.
      - theultdev 2y ago
        Well, still a subjective take. Heavy use of interactivity is hard. React makes it maintainable. It was hell before. I've been working with React (and RN) since it came out and I've had nothing but good experiences, especially compared to the previous decade before React. My motto is local-first, the more stuff the client does, the cheaper it is to scale and less bridging between the server you have to do. Move everything to the client, especially the database. Let the database do the syncing. Plus you get offline and undo/redo basically for free. Pagination? Fuggetaboutit.
        MBCook 2y ago
        (Not a GP). Yeah. I use and like React. I don’t have an issue with it. It’s not tiny but it does a lot of work and makes my life easy. My general complaint is the JS ecosystem in general and its tooling.
        apsurd 2y ago
        > Heavy use of interactivity is hard. React makes it maintainable. It was hell before. Agree, React is great for UI interactivity. > ...the more stuff the client does, the cheaper it is to scale and less bridging between the server you have to do. Disagree. The most costly form of scaling is people. UI + business-logic + data-modeling + data access (ACL) all held in async client concepts is a complexity nightmare in my experience. Even for my team-of-one side-projects. Server <-> client bridge is a feature for managing complexity over time. I may agree that added ceremony could make 95% tile app experiences default harder. But for anything that's not a toy, the #1 risk is always team/people/communication complexity.
- deleted 2y ago
  [deleted]
- johnfn 2y ago
  The article says that React was about to make a change, the community pointed out it had bad trade-offs, and React backed off. What does that have to do with Vercel? Where's the problem with React here?
  - tmpz22 2y ago
    Vercel is a (more?) opinionated ecosystem that influences higher adoption of Server-Side-Rendering and other features. This encourages projects to use more niche APIs like Suspense, and due to the capital, marketing, and bearish adoption of Vercel products by vocal parties (startups) - will influence React's developers to cater to them. I'm agnostic because I quit full stack web development ~6 months ago. I think the product development story sucks and combined with the market economics of the current tech industry is just not fun or profitable to invest my career in. It's -probably- a good thing that stuff like SSR becomes mainstream/required. But I really don't like that one of the main entities behind it, Vercel, has raised $563M as of their latest Series E as they steam towards an IPO of their Framework/Cloud offerings.
    - mglikesbikes 2y ago
      What are you doing after quitting full stack web dev?
  - agos 2y ago
    Vercel both made the change and approved the PR
- epolanski 2y ago
  I don't mind writing react but Vue and Nuxt are saner choices if you want great out of the box performance.
  - sesm 2y ago
    Which Next are you talking about here?
    - epolanski 2y ago
      Edited, meant Nuxt
- madeofpalk 2y ago
  " Most evil company " is quite the statement about some silly javascript library.
  - deleted 2y ago
    [deleted]
  - Volt 2y ago
    Yeah, imagine if it was about some toy operating system.
- sergiotapia 2y ago
  This is precisely what happened and is still happening today. And remember, this company pays a lot of money for tech influencers as well.
vlaaad 2y ago
Ugh, this post is so much drama, while the actual events are pretty boring and happen all the time. React team changes something, there are unintended consequences, the change is reverted.
- Capricorn2481 2y ago
  There will never be more FUD on HN than a React article
  - dylan604 2y ago
    I think you're entirely forgetting about Rust, AI/ML/whatevs, or any of the other myriad topics delivered daily. It's what happens when you open up comments from anyone anywhere at anytime.
    - Capricorn2481 2y ago
      ? I have never seen a bad comment about Rust on here. Seems like there's lots of certainty about it.
      - randomdata 2y ago
        It was time for the regularly scheduled Rust advertisement again.
        Capricorn2481 2y ago
        That's not an advertisement from me, but pointing out that people hype Rust on here.
        randomdata 2y ago
        The comment you originally replied to was the advertisement.
      - deleted 2y ago
deleted 2y ago
[deleted]
terandle 2y ago
"This gives us the best performance characteristics when you're following best practices (i.e. hoist data fetches to Server Components or route loaders), at the expense of making an already bad pattern a bit worse." [1] Their rational was pretty solid in the PR, but seems they overestimated how ready the community is to embrace newer best practices and they are back tracking. [1] https://github.com/facebook/react/pull/26380 https://github.com/facebook/react/pull/26380
- fabian2k 2y ago
  My impression from the later responses was that they underestimated how often this particular pattern for parallel loading with React Suspense is used. The people that are slow to embrace the newer patterns would likely not have used Suspense at all, so nothing would have changed for them. This would have affected a specific subset of people that used Suspense for parallel loading, but didn't switch to route loaders.
  - diob 2y ago
    I hadn't heard of route loaders till all this. What are they, in plain terms? Is it just manually hoisting what you know a route needs all the way to the top of the tree? Or is it some compile time magic that analyzes your components used, making the decision for you on what to fetch for a route?
    - fabian2k 2y ago
      Haven't used them myself yet. As far as I understand it's essentially moving the data loading into the router. The router has an API for the loaders so the rest will work automatically like loading states. So yes, this means you have to define what to load at the top where you define the routes. Though I think this also works with nested routes, but I don't have any experience with them.
      - marcins 2y ago
        > So yes, this means you have to define what to load at the top where you define the routes. And Meta's way of doing this is with Relay, so you are still defining component data requirements with the components and query fragments, but there's a compile step that produces those route level queries.. so you still get "co-location of a component's data requirements with the component", and "top level early data fetch" for the render-as-you-fetch pattern. This change breaks the fetch-as-you-render pattern where components make individual data requests for their data, because that pattern is considered bad for performance (for Meta's use case).
ssahoo 2y ago
Shutout for Svelte. It took the best of VUE and react. It's fast and very lightweight when compared to Vue, which has a largish ecosystem. https://svelte.dev/ https://svelte.dev/
- sertraline 2y ago
  I come to think that corporate people love React because if you stop following the news and not be constantly reminded about the direction React is currently heading, you will fall out of the loop and your projects will stop working in 1 year or so. Which is beneficial for the employees, as they will never run out of work to do, maintaining the framework itself rather than their actual project. And the framework gets more complex with each year, too, so you can pretend that you are doing some complex work without actually doing it.
  - buremba 2y ago
    ^ Exactly my feelings about React. The sad truth is that React is still viable for startups as the ecosystem has the most extensive librarie.
- _puk 2y ago
  I love svelte, and is what I reach for personally, but it's still early enough in its lifecycle that there's constant changes / new paradigms being introduced, especially if you include svelte-kit (originally it used sapper). If I had a team that had gone all in on Svelte I'd be bemoaning the need to upgrade recent code already.
  - Capricorn2481 2y ago
    There's literally more churn in Svelte than there is in the React library
- moffkalast 2y ago
  Hot take time: React is the most corporate framework to have ever corporated in the history of corporate, designed for one thing first and foremost: To make high turnover easier so they can fire you at any time and replace you with the next guy in line who'll already know how the entire thing works... because there is only one stupid way to do things in React. You either like it or it feels like pulling teeth. I'm up for cheering for literally any alternative. Any.
lominming 2y ago
I did an evaluation on the various frameworks 2 years ago, and it largely came down to only these 2 choices: - React (if you want the largest support, packages, community, but sacrifice on performance) - SolidJS [1] (best performance, composability, low-level primitives, but sacrifice on packages/community) Every other choice like Angular, Vue, Svelte are just somewhere in between these 2 spectrums which I felt was not worth it. Either choose the one with the largest ecosystem or one which has the best primitives & performance. - React (vdom, slow) (largest ecosystem) - Vue (vdom, faster than react) (large community) - Svelte (fine-grain, faster) (best dx pre-v5) (composability is still not as flexible in v5 compared to SolidJS) (small ecosystem) - SolidJS (fine-grain, fastest, most consistent) (dx similar to react) (small ecosystem) [1] https://www.solidjs.com/ https://www.solidjs.com/
- Etheryte 2y ago
  In all honesty, I think neither one of those are the main measurement you should be using from a business point of view. React has a huge ecosystem, but many packages are out of date or poorly maintained. This means you either still roll your own or you take on the pain of working with the bugs or compat mismatches you inevitably get (looking at you, React 18). On the other end, I would say for the majority of modern web apps, performance doesn't matter too much, so long as it isn't absolutely abysmal. So what are the right metrics, in my subjective opinion? Readability, and by extension refactorability, and ease of iteration. In other words, developer experience, because that will literally save your business actual time and money.
  - otabdeveloper4 2y ago
    Never met a corporate SPA that didn't have abysmal performance. That said, framework choice isn't the problem, frontend devs having no clue how to design and use API's is.
    - zdragnar 2y ago
      Corporations fill their ranks with junior developers, more breaking news at 11. I remember plenty of multi page applications from big corp that ran like a dead dog too, back in the day. Or ASP sites that wrapped the ENTIRE page in a form, with all of the frustrating complications that entailed.
windowshopping 2y ago
I feel like the percent of people using suspend is a tiny tiny fraction of the percent of people using react. I think this title is massively sensationalized.
- remixff2400 2y ago
  The unfortunate part of this is that a large percentage of that small percentage is library maintainers, so it matters a lot more overall because of their role in the React space, even if users aren't necessarily using those features.
- crubier 2y ago
  I think you're wrong, without knowing it. And in a way this kind of subjective judgment call "people must be using react like me I guess" is the entire cause of this misshap. Don't assume usage patterns. Measure them, or you know nothing.
  - Capricorn2481 2y ago
    But you just did the same thing by saying they were wrong. Did you measure it?
  - windowshopping 2y ago
    Okay, here you go. Github search for "import react", 56M results: https://github.com/search?q=%22import+react%22&type=code https://github.com/search?q=%22import+react%22&type=code Github search for "</Suspense>", 220k results: https://github.com/search?q=%22%3C%2FSuspense%3E%22&type=code https://github.com/search?q=%22%3C%2FSuspense%3E%22&type=cod... Thanks for the mildly condescending attempt to give me your earthly wisdom, though. Believe it or not, common sense can occasionally be just as useful as hard data. Maybe this can be a learning opportunity for you instead.
    - crubier 2y ago
      This is almost as biased as a personal anecdotal opinion: - You're looking at open source projects only (Most users of Suspense are going to be commercial closed source) - You're looking at all versions of React over the last 12 years (Suspense is fairly recent) - You're not weighing by number of stars, users, contributors, activity (E.g. you're probably 5M "React getting started" projects in there) So, no. Still not. Anyway, by now the React team acknowledged that their initial decision was biased and decided to not ship React 19 without a solution, so we're good!
refulgentis 2y ago
The change occurred in [March 2023](https://github.com/facebook/react/pull/26380 https://github.com/facebook/react/pull/26380) [^1^], and it became a hot topic 15 months later? [^2^] Are React release cycles that long? What's up with the title that it "almost" was slower if it was released? I assume I'm missing some context here. [^1^]: grep "This happens because of the following PR:" [^2^]: article publication date is June 17, 2024, tweet screenshots are dated between June 10th and that date
- Uvix 2y ago
  Yes, the release cycles between major versions are that long; v18 was released March 2022.
  - refulgentis 2y ago
    Wow. 2y3m and counting (presumably, given article title). It's very straightforward, yet a complete surprise to me. I guess I'm just replying to invite someone else to give me a long-winded explanation of how the JS ecosystem works. ex. now I'm flummoxed as to how Vercel/next.js exists/releases new features, if they're based on React. Seems you'd either get stuck living on React top of tree, unreleased, or have an unholy merge to do.
    - Uvix 2y ago
      React in particular puts out a point release with breaking change warnings, along with an upgrade guide, several months before the next major version so that developers have plenty of time to prepare for any required changes. (For React 19, this was the 18.3 release at the end of April 2024.) They also try to provide scripted code updates ("codemods") to ease the upgrade process. This is admittedly rare in the JS ecosystem.
    - SahAssar 2y ago
      > now I'm flummoxed as to how Vercel/next.js exists/releases new features They run on canary react releases. It's a not that hidden dirty "secret".
- 2y ago
breadwinner 2y ago
The first problem here is putting a UI widget in charge of fetching data. React was originally designed to be the V in MVC. Had we left it as the V in MVC we'd be loading data in controllers, like we do in every other framework. Having a React component be the model, view and controller is a mistake, and we can still reverse course.
- 0xblinq 2y ago
  That’s why I think the most sane way to use React (or Vue) nowadays is through Inertia.js. Have a proper backend doing all the backend stuff and just render page components as if they where just the views of the framework. All this server components nonsense is solving a problem that maybe Facebook has but almost no one else does. But people think they do, so a lot of complexity is added for no real reason.
- diob 2y ago
  I've never seen a MVC codebase that wasn't a nightmare to work in.
  - sky2224 2y ago
    Yeah, MVC (and MVVM for that matter), seem like architectural approaches that are great in theory, but with the reality of constraints, requirements, timelines, and ultimately many engineers' misunderstanding of things (frankly I'm probably included in that group as well), it just leads to a mess of interdependency and tight coupling among functionalities. Now granted, this is pretty much a given for any architecture (nothing is perfect): so maybe my expectations of what things should be needs to be reeled in a bit.
    - breadwinner 2y ago
      > it just leads to a mess of interdependency and tight coupling among functionalities Disagree with that. Most UI frameworks, including ASP.NET Core, JSP and JSF (Java based frameworks), Ruby on Rails, and Django (Python) are all based on MVC. That's no accident. MVC works very well.
maliker 2y ago
"almost made the internet slower"... uh, pretty sure it's been making things slower since inception when it replaced html + a few ajax requests. I know, I know, I'm old. Get off my lawn.
- WolfOliver 2y ago
  HN should have a like button for comments
  - wizzwizz4 2y ago
    It does: the favourite feature.
    - spartanatreyu 2y ago
      In case anyone reading the above is confused... You have to click the timestamp on the comment first, then you're sent to a new page that only shows that one comment and a favorite button. Sometimes the favorite button doesn't appear so you have to click the timestamp again.
- thanatos519 2y ago
  Turing-complete content is an abomination.
- vundercind 2y ago
  I remember when AJAX made things faster. Then we stopped sending html to insert into the DOM, and started sending JSON with a bunch of extra steps in between. The fastest sites I see these days usually just reload the whole page pretty often.
  - tracker1 2y ago
    HTMX for the win!
    - 2y ago
scoot 2y ago
Since the author doesn't appear to understand the difference between the Internet and the Web, and thinks that React handles internet traffic, I think it's fair to assume that the rest of the article is going to be a hot mess.
verbalstoner 2y ago
JS frameworks were a terrible mistake
- voat 2y ago
  You're either using a framework, or unintentionally writing your own
  - mickael-kerjean 2y ago
    I rewrote one of my apps in vanilla JS to get the most performance possible, the wheel I had to reinvent is under 150 line of code [1], definitely worst the small cost [2] [1] framework code: https://github.com/mickael-kerjean/filestash/tree/master/public/assets/lib/skeleton https://github.com/mickael-kerjean/filestash/tree/master/pub... [2] example: https://github.com/mickael-kerjean/filestash/blob/master/public/index.backoffice.html https://github.com/mickael-kerjean/filestash/blob/master/pub...
- rglover 2y ago
  The frameworks aren't the problem, it's their authors. There's a virus in the JavaScript world that makes people think ever-more complex solutions make tools better. After years asking "why is it like this" (I'm a JS dev/framework author), I realized this is likely due to an inferiority complex because hearing "real programmers don't use JavaScript" makes people feel bad so they try to compensate with complexity and end up creating messes. That and complexity pays well.
jmeyer2k 2y ago
React server actions also have this limitation. No way to call two server actions in parallel.
throw_that_away 2y ago
React is the UI Java
ravetcofx 2y ago
I've noticed the internet becoming generally slow and laggy over the last few years for older computers and devices. Things from around and before 2015 to 2017 are becoming pretty unusable for doing basic web app tasks.
- Foreignborn 2y ago
  I use a 2013 MacBook running Ubuntu to code in. It works totally fine UNLESS you load something like a crazy landing page with animations. I always end up having to kill Firefox and prevent that site from opening. One unexpected benefit of LLMs is they’re more performance friendly, I can query the docs of what I’m working on without loading the docs themselves.
zogrodea 2y ago
Unrelated, but I'm impressed by how fast browsers can be in some cases. I once created a HTML file with just a start/end HTML tag and 50k (unstyled) button elements in between, curious to see how it performs. I tried the same in Flutter on a release build (using Material widgets so they are styled) and the HTML was much faster. I was able to tab through (changing focus by holding tab) the buttons in both Chrome and Firefox at a consistent frame rate with no signs of any lag, while FLutter struggled and lagged quite a bit with the same. Would anyone know why that is? Are web browsers hyper-optimised for static documents (beating a "native" GUI toolkit for static documents)? Is Flutter just comparatively slow compared to Qt, GTK and so on? Does the styling have that much of an impact on performance? I am aware that updating DOM elements is uniquely slow for browsers but this experiment was a surprise for me and I'm curious for an explanation.
- l5870uoo9y 2y ago
  If you want performant styling stick to CSS.
  - ComputerGuru 2y ago
    CSS can certainly be performant but you need to be aware of what can trigger reflows, which will absolutely destroy your performance. Cascading reflows are horrible.
- Jabbles 2y ago
  Can you share your code?
  - zogrodea 2y ago
    I will in a bit hopefully. It was a few months ago and I don't have Flutter installed on this computer but I'm doing it now. Edit: I was coding it up now, but my storage is full (having trouble copying text to my clipboard and unable to save files) so I don't think I will be able to deliver on what I intended. Sorry about that. On the HTML side, I had a code generator (in Javascript) that output `<html> <button /> <15000 more buttons.../> </html>` and wrote it to a file. On the Flutter side, I used the default Flutter sample app (`flutter create .`) and I just used a similar code generator to put 15000 buttons in a Column widget. I don't think I'll be able to do much else to help with reproducibility sadly. If others try the same, I would be interested in if their results are any better than mine (with Chrome/Firefox being faster).
d0100 2y ago
Shoutout to the devs from pmndrs reminding the react core team that not all async is fetching crud data
bob1029 2y ago
I knew we were going off a cliff the moment GitHub did their big client-side rendering rework and made it effectively impossible to review large PRs in the web UI. This has all become too complicated as is traditional. Every JS framework I have ever used ultimately suffered the same fate. The only web framework that works long-term is whatever is documented on MDN. Something approximating PHP + AJAX has always been the correct path. If you are doing things like shipping DOM across websockets, I think you may have missed an important step somewhere along the way.
- lovethevoid 2y ago
  React, vue, and svelte all have MDN docs. So not sure that’s the best way of determining a better route for JS frameworks.
  - 38 2y ago
    no, they dont.
    - Jowsey 2y ago
      https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks https://developer.mozilla.org/en-US/docs/Learn/Tools_and_tes... ?
      - deleted 2y ago
        [deleted]
      - 38 2y ago
        https://wikipedia.org/wiki/Ward_Cunningham#%22Cunningham's_Law%22 https://wikipedia.org/wiki/Ward_Cunningham#%22Cunningham's_L...
- graypegg 2y ago
  I would like to see a “framework of opinions” somewhere. 0 actual software, just documentation for standard JS and browser APIs organized in a way resembling framework documentation. The current style of web platform documentation tends to resemble a big list of objects, or the most basic and slowest introduction to web development possible. Something in-between, with chapters like “templating” or “data fetching” that focused on some opinionated but framework less structure, would be nice.
voat 2y ago
TLDR: Don't do data fetching in your components if your care about performance. Hoist it up to the route, so you don't have to wait for deeply nested components to render serially.
- willsmith72 2y ago
  IF they shipped this change, and you used suspending components, yes. That's a big if. (In case people see this tldr and actually start changing their apps)
gumby 2y ago
Only the web sites…and all that latency will leave extra bandwidth for all the other use of the Internet.
prinny_ 2y ago
“We care a lot about SPAs, team misjudged how many people rely on this today”. This comment worries me because I was under the impression that RSCs are an option for a specific use case and not the one approach to rule them all. SPAs should be supported and expanded because they do serve a valuable purpose not only based on their use cases but also for developers. React being SPA friendly means people can spin up hobby projects, small applications and big non SEO reliant apps with ease. Going all in with RSC and ditching SPAs means that many will be discouraged from entering the react scene due to the sheer amount for things that used to be optional and now suddenly just became mandatory. I liked react and I still like it. But I believe it’s on a path to alienate its user base.
ramesh31 2y ago
>"In React 19, we’re adding support for rendering document metadata tags in components natively: function BlogPost({post}) { return ( <article> <h1>{post.title}</h1> <title>{post.title}</title> <meta name="author" content="Josh" /> <link rel="author" href="https://twitter.com/joshcstory/" /> <meta name="keywords" content={post.keywords} /> <p>Eee equals em-see-squared...</p> </article> ); } When React 19 renders this component, it will see the <title> <link> and <meta> tags, and automatically hoist them to the <head> section of document." This is one of the most brutally stupid things I've ever seen, and has pretty much sealed the deal on me dumping React at this point.
- MBCook 2y ago
  Why? It fixes a serious pain point React has had necessitating things like the helmet library. This seems like a perfectly reasonable of way of doing it. How is this “brutally stupid”?
  - recursive 2y ago
    Why is this not useEffect(() => document.title = 'whatever'); What's the pain point exactly? It does seem pretty weird to put it inline with the jsx. There's no indication it has a non-local effect on the DOM. Feels a bit magic for my taste. Very little of what react does seems reasonable to me though.
    - MBCook 2y ago
      While that’s basically what all this stuff really does under the covers, it doesn’t feel “react-y” to me. Using JSX does. Especially for stuff like meta tags where there can be a couple in force at once. I’m not going to argue it’s perfect but it seems like it fits in to me. It’s basically acting like the restrictions on where the title and meta tags can go no longer apply so you can just sprinkle them wherever they hopefully belong in your app. And react takes care of putting them in the right spot. > Very little of what react does seems reasonable to me though. So are you someone who dislikes it in general and just using this as one more argument? I’d be very curious to see the opinion of someone who likes react who thinks this is a bad idea.
busterarm 2y ago
As a former fullstack developer who has been fulltime on infrastructure for a decade now and reading these comments, not only can I barely follow half of the conversations but they're so far removed from the fundamentals of sending data between two places over the wire that I'm extremely satisfied with the career choices I've made. Y'all are inventing your own problems to solve.
- downrightmike 2y ago
  #BillableHours
  - busterarm 2y ago
    To a certain degree that is true, but they're also much more replaceable. Not only have I seen multiple organizations lay off entire frontend groups, but as time goes on I work with more and more people who specialize in only this end of the stack and need people like me to wade in and solve actual problems for them. Under the hood I know how things actually work and I can quickly get up to speed on their issues, whereas it's not always so easy going the other way. Also if I had a dollar for every time I had to help web engineers "figure out" why the Sentry p95s are so high when sending large binary blobs on multiple round trips between Eastern US and Japan, I'd be a rich man.
- willsmith72 2y ago
  Not really. The whole point of ssr alongside react 19/rsc is exactly abstracting the idea of "sending data between two places". You're sending html and removing waterfalls by moving data fetches to be as early as possible If you don't want an interactive website, sure, just do everything on the server. That's a fine decision. Most of us work on apps where interactivity is a must
  - craftkiller 2y ago
    > If you don't want an interactive website This is a false dichotomy. Gmail launched in 2004, React launched in 2013. Clearly interactive websites are possible without React.
troad 2y ago
I stopped paying attention to web dev for a few years, and those were the years when everything went from hand-written HTML + JS (+ PHP/ASP on the server side) to the likes of Node and React etc. You can imagine my confusion when I checked back in. I'm dipping my toes in now for the first time since then, and I gotta say - I don't hate it as much as I thought I would. Yes, you can end up with library soup if you're not careful, but a lot of what used to be difficult is now quite easy. There's been genuine forward progress, and it's really nice to see. (Though there does appear to be some kind of allergy in the web dev space to describing things intelligibly. It's never "XYZ is a stateless UI library built in TypeScript", it's always "XYZ lets you build bleeding-edge shardable solutions in the Web 3.7 space using YAML elem-nodes called 'qooms'. Let our bosomy anime mascot walk you through our getting started guide by simply piping this Discord link into a superuser shell")
- throwup238 2y ago
  You're dipping your toes back in at the right time. IMO a lot of criticism aimed at frontend development is latent cPTSD from a bygone era but things have really come together over the last half decade. NextJS and friends are bloated, but that's nothing to the shit-show that was Webpack et al. Now that that's mostly over, next-gen tooling like Vite make the development process a lot easier. CSS especially is a lot better than it was a decade ago.
- toldyouso2022 2y ago
  You skipped the worst part. Things are great now. I wonder how big corps are gonna ruin them this time.
- deleted 2y ago
  [deleted]
enlightenedfool 2y ago
Looked into React for one of my webapps. It felt too complex. I found lemonade js and happy with it. Just a few concepts that serve the purpose.
1vuio0pswjnm7 2y ago
Internet is more than the web. Can the web make the rest of the internet slower.
- shermantanktop 2y ago
  Let’s hope nobody invents React for Gopher.
synergy20 2y ago
which is why I switched back to vue.js, who so far is much simpler and get the job done if you need a true SPA with SSR only as an option instead of being the "new" primary focus(which made things much more difficult to use, and slower)
deleted 2y ago
[deleted]

I'm so done with React. Since Vercel kidnapped it everything is done for/because of their platform and their interests. Most evil company I've seen in a long time.

Capricorn2481 2y ago
What's a negative development in React that was only for Vercel?
hipadev23 2y ago
An innocent dev was just overcharged $5k by Vercel while reading your comment.
STRiDEX 2y ago
driven by facebook in this case https://x.com/sophiebits/status/1800966114048147495 https://x.com/sophiebits/status/1800966114048147495
- MBCook 2y ago
  So they made the choice that worked well in the mega-scale application they tested with and performed worse with the pattern they didn’t think was too widely used/would be much of a problem. And it would make planned future features easier. That sounds 100% reasonable. Someone noticed it, pointed out it was a big problem for them and enough others it got reverted. That seems 100% reasonable too.
realusername 2y ago
The whole js ecosystem is insanity, React isn't even the worst offender, it's a machine to generate complexity. My controversial opinion is still the same, the less front-end you have in your stack, the easiest you'll be able to scale.
- rglover 2y ago
  Yargh, there still be some sanity left on these seas [1]. [1] https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick
- whoknowsidont 2y ago
  >The whole js ecosystem is insanity This is such a lazy, grandstandy, unoriginal take. >My controversial opinion is still the same It's not controversial it's just tired and ignorant.
  - realusername 2y ago
    > It's not controversial it's just tired and ignorant Tired maybe but not ignorant since I helped to maintain two React SPAs for 6 years now so I'm pretty aware how bad it is.
    - theultdev 2y ago
      Well, still a subjective take. Heavy use of interactivity is hard. React makes it maintainable. It was hell before. I've been working with React (and RN) since it came out and I've had nothing but good experiences, especially compared to the previous decade before React. My motto is local-first, the more stuff the client does, the cheaper it is to scale and less bridging between the server you have to do. Move everything to the client, especially the database. Let the database do the syncing. Plus you get offline and undo/redo basically for free. Pagination? Fuggetaboutit.
      - MBCook 2y ago
        (Not a GP). Yeah. I use and like React. I don’t have an issue with it. It’s not tiny but it does a lot of work and makes my life easy. My general complaint is the JS ecosystem in general and its tooling.
      - apsurd 2y ago
        > Heavy use of interactivity is hard. React makes it maintainable. It was hell before. Agree, React is great for UI interactivity. > ...the more stuff the client does, the cheaper it is to scale and less bridging between the server you have to do. Disagree. The most costly form of scaling is people. UI + business-logic + data-modeling + data access (ACL) all held in async client concepts is a complexity nightmare in my experience. Even for my team-of-one side-projects. Server <-> client bridge is a feature for managing complexity over time. I may agree that added ceremony could make 95% tile app experiences default harder. But for anything that's not a toy, the #1 risk is always team/people/communication complexity.
deleted 2y ago
[deleted]
johnfn 2y ago
The article says that React was about to make a change, the community pointed out it had bad trade-offs, and React backed off. What does that have to do with Vercel? Where's the problem with React here?
- tmpz22 2y ago
  Vercel is a (more?) opinionated ecosystem that influences higher adoption of Server-Side-Rendering and other features. This encourages projects to use more niche APIs like Suspense, and due to the capital, marketing, and bearish adoption of Vercel products by vocal parties (startups) - will influence React's developers to cater to them. I'm agnostic because I quit full stack web development ~6 months ago. I think the product development story sucks and combined with the market economics of the current tech industry is just not fun or profitable to invest my career in. It's -probably- a good thing that stuff like SSR becomes mainstream/required. But I really don't like that one of the main entities behind it, Vercel, has raised $563M as of their latest Series E as they steam towards an IPO of their Framework/Cloud offerings.
  - mglikesbikes 2y ago
    What are you doing after quitting full stack web dev?
- agos 2y ago
  Vercel both made the change and approved the PR
epolanski 2y ago
I don't mind writing react but Vue and Nuxt are saner choices if you want great out of the box performance.
- sesm 2y ago
  Which Next are you talking about here?
  - epolanski 2y ago
    Edited, meant Nuxt
madeofpalk 2y ago
" Most evil company " is quite the statement about some silly javascript library.
- deleted 2y ago
  [deleted]
- Volt 2y ago
  Yeah, imagine if it was about some toy operating system.
sergiotapia 2y ago
This is precisely what happened and is still happening today. And remember, this company pays a lot of money for tech influencers as well.

vlaaad 2y ago

Ugh, this post is so much drama, while the actual events are pretty boring and happen all the time. React team changes something, there are unintended consequences, the change is reverted.

Capricorn2481 2y ago
There will never be more FUD on HN than a React article
- dylan604 2y ago
  I think you're entirely forgetting about Rust, AI/ML/whatevs, or any of the other myriad topics delivered daily. It's what happens when you open up comments from anyone anywhere at anytime.
  - Capricorn2481 2y ago
    ? I have never seen a bad comment about Rust on here. Seems like there's lots of certainty about it.
    - randomdata 2y ago
      It was time for the regularly scheduled Rust advertisement again.
      - Capricorn2481 2y ago
        That's not an advertisement from me, but pointing out that people hype Rust on here.
        randomdata 2y ago
        The comment you originally replied to was the advertisement.
    - deleted 2y ago

deleted 2y ago

[deleted]

terandle 2y ago

"This gives us the best performance characteristics when you're following best practices (i.e. hoist data fetches to Server Components or route loaders), at the expense of making an already bad pattern a bit worse." [1] Their rational was pretty solid in the PR, but seems they overestimated how ready the community is to embrace newer best practices and they are back tracking. [1] https://github.com/facebook/react/pull/26380 https://github.com/facebook/react/pull/26380

fabian2k 2y ago
My impression from the later responses was that they underestimated how often this particular pattern for parallel loading with React Suspense is used. The people that are slow to embrace the newer patterns would likely not have used Suspense at all, so nothing would have changed for them. This would have affected a specific subset of people that used Suspense for parallel loading, but didn't switch to route loaders.
- diob 2y ago
  I hadn't heard of route loaders till all this. What are they, in plain terms? Is it just manually hoisting what you know a route needs all the way to the top of the tree? Or is it some compile time magic that analyzes your components used, making the decision for you on what to fetch for a route?
  - fabian2k 2y ago
    Haven't used them myself yet. As far as I understand it's essentially moving the data loading into the router. The router has an API for the loaders so the rest will work automatically like loading states. So yes, this means you have to define what to load at the top where you define the routes. Though I think this also works with nested routes, but I don't have any experience with them.
    - marcins 2y ago
      > So yes, this means you have to define what to load at the top where you define the routes. And Meta's way of doing this is with Relay, so you are still defining component data requirements with the components and query fragments, but there's a compile step that produces those route level queries.. so you still get "co-location of a component's data requirements with the component", and "top level early data fetch" for the render-as-you-fetch pattern. This change breaks the fetch-as-you-render pattern where components make individual data requests for their data, because that pattern is considered bad for performance (for Meta's use case).

ssahoo 2y ago

Shutout for Svelte. It took the best of VUE and react. It's fast and very lightweight when compared to Vue, which has a largish ecosystem. https://svelte.dev/ https://svelte.dev/

sertraline 2y ago
I come to think that corporate people love React because if you stop following the news and not be constantly reminded about the direction React is currently heading, you will fall out of the loop and your projects will stop working in 1 year or so. Which is beneficial for the employees, as they will never run out of work to do, maintaining the framework itself rather than their actual project. And the framework gets more complex with each year, too, so you can pretend that you are doing some complex work without actually doing it.
- buremba 2y ago
  ^ Exactly my feelings about React. The sad truth is that React is still viable for startups as the ecosystem has the most extensive librarie.
_puk 2y ago
I love svelte, and is what I reach for personally, but it's still early enough in its lifecycle that there's constant changes / new paradigms being introduced, especially if you include svelte-kit (originally it used sapper). If I had a team that had gone all in on Svelte I'd be bemoaning the need to upgrade recent code already.
- Capricorn2481 2y ago
  There's literally more churn in Svelte than there is in the React library
moffkalast 2y ago
Hot take time: React is the most corporate framework to have ever corporated in the history of corporate, designed for one thing first and foremost: To make high turnover easier so they can fire you at any time and replace you with the next guy in line who'll already know how the entire thing works... because there is only one stupid way to do things in React. You either like it or it feels like pulling teeth. I'm up for cheering for literally any alternative. Any.

lominming 2y ago

I did an evaluation on the various frameworks 2 years ago, and it largely came down to only these 2 choices: - React (if you want the largest support, packages, community, but sacrifice on performance) - SolidJS [1] (best performance, composability, low-level primitives, but sacrifice on packages/community) Every other choice like Angular, Vue, Svelte are just somewhere in between these 2 spectrums which I felt was not worth it. Either choose the one with the largest ecosystem or one which has the best primitives & performance. - React (vdom, slow) (largest ecosystem) - Vue (vdom, faster than react) (large community) - Svelte (fine-grain, faster) (best dx pre-v5) (composability is still not as flexible in v5 compared to SolidJS) (small ecosystem) - SolidJS (fine-grain, fastest, most consistent) (dx similar to react) (small ecosystem) [1] https://www.solidjs.com/ https://www.solidjs.com/

Etheryte 2y ago
In all honesty, I think neither one of those are the main measurement you should be using from a business point of view. React has a huge ecosystem, but many packages are out of date or poorly maintained. This means you either still roll your own or you take on the pain of working with the bugs or compat mismatches you inevitably get (looking at you, React 18). On the other end, I would say for the majority of modern web apps, performance doesn't matter too much, so long as it isn't absolutely abysmal. So what are the right metrics, in my subjective opinion? Readability, and by extension refactorability, and ease of iteration. In other words, developer experience, because that will literally save your business actual time and money.
- otabdeveloper4 2y ago
  Never met a corporate SPA that didn't have abysmal performance. That said, framework choice isn't the problem, frontend devs having no clue how to design and use API's is.
  - zdragnar 2y ago
    Corporations fill their ranks with junior developers, more breaking news at 11. I remember plenty of multi page applications from big corp that ran like a dead dog too, back in the day. Or ASP sites that wrapped the ENTIRE page in a form, with all of the frustrating complications that entailed.

windowshopping 2y ago

I feel like the percent of people using suspend is a tiny tiny fraction of the percent of people using react. I think this title is massively sensationalized.

remixff2400 2y ago
The unfortunate part of this is that a large percentage of that small percentage is library maintainers, so it matters a lot more overall because of their role in the React space, even if users aren't necessarily using those features.
crubier 2y ago
I think you're wrong, without knowing it. And in a way this kind of subjective judgment call "people must be using react like me I guess" is the entire cause of this misshap. Don't assume usage patterns. Measure them, or you know nothing.
- Capricorn2481 2y ago
  But you just did the same thing by saying they were wrong. Did you measure it?
- windowshopping 2y ago
  Okay, here you go. Github search for "import react", 56M results: https://github.com/search?q=%22import+react%22&type=code https://github.com/search?q=%22import+react%22&type=code Github search for "</Suspense>", 220k results: https://github.com/search?q=%22%3C%2FSuspense%3E%22&type=code https://github.com/search?q=%22%3C%2FSuspense%3E%22&type=cod... Thanks for the mildly condescending attempt to give me your earthly wisdom, though. Believe it or not, common sense can occasionally be just as useful as hard data. Maybe this can be a learning opportunity for you instead.
  - crubier 2y ago
    This is almost as biased as a personal anecdotal opinion: - You're looking at open source projects only (Most users of Suspense are going to be commercial closed source) - You're looking at all versions of React over the last 12 years (Suspense is fairly recent) - You're not weighing by number of stars, users, contributors, activity (E.g. you're probably 5M "React getting started" projects in there) So, no. Still not. Anyway, by now the React team acknowledged that their initial decision was biased and decided to not ship React 19 without a solution, so we're good!

refulgentis 2y ago

The change occurred in [March 2023](https://github.com/facebook/react/pull/26380 https://github.com/facebook/react/pull/26380) [^1^], and it became a hot topic 15 months later? [^2^] Are React release cycles that long? What's up with the title that it "almost" was slower if it was released? I assume I'm missing some context here. [^1^]: grep "This happens because of the following PR:" [^2^]: article publication date is June 17, 2024, tweet screenshots are dated between June 10th and that date

Uvix 2y ago
Yes, the release cycles between major versions are that long; v18 was released March 2022.
- refulgentis 2y ago
  Wow. 2y3m and counting (presumably, given article title). It's very straightforward, yet a complete surprise to me. I guess I'm just replying to invite someone else to give me a long-winded explanation of how the JS ecosystem works. ex. now I'm flummoxed as to how Vercel/next.js exists/releases new features, if they're based on React. Seems you'd either get stuck living on React top of tree, unreleased, or have an unholy merge to do.
  - Uvix 2y ago
    React in particular puts out a point release with breaking change warnings, along with an upgrade guide, several months before the next major version so that developers have plenty of time to prepare for any required changes. (For React 19, this was the 18.3 release at the end of April 2024.) They also try to provide scripted code updates ("codemods") to ease the upgrade process. This is admittedly rare in the JS ecosystem.
  - SahAssar 2y ago
    > now I'm flummoxed as to how Vercel/next.js exists/releases new features They run on canary react releases. It's a not that hidden dirty "secret".
2y ago

breadwinner 2y ago

The first problem here is putting a UI widget in charge of fetching data. React was originally designed to be the V in MVC. Had we left it as the V in MVC we'd be loading data in controllers, like we do in every other framework. Having a React component be the model, view and controller is a mistake, and we can still reverse course.

0xblinq 2y ago
That’s why I think the most sane way to use React (or Vue) nowadays is through Inertia.js. Have a proper backend doing all the backend stuff and just render page components as if they where just the views of the framework. All this server components nonsense is solving a problem that maybe Facebook has but almost no one else does. But people think they do, so a lot of complexity is added for no real reason.
diob 2y ago
I've never seen a MVC codebase that wasn't a nightmare to work in.
- sky2224 2y ago
  Yeah, MVC (and MVVM for that matter), seem like architectural approaches that are great in theory, but with the reality of constraints, requirements, timelines, and ultimately many engineers' misunderstanding of things (frankly I'm probably included in that group as well), it just leads to a mess of interdependency and tight coupling among functionalities. Now granted, this is pretty much a given for any architecture (nothing is perfect): so maybe my expectations of what things should be needs to be reeled in a bit.
  - breadwinner 2y ago
    > it just leads to a mess of interdependency and tight coupling among functionalities Disagree with that. Most UI frameworks, including ASP.NET Core, JSP and JSF (Java based frameworks), Ruby on Rails, and Django (Python) are all based on MVC. That's no accident. MVC works very well.

maliker 2y ago

"almost made the internet slower"... uh, pretty sure it's been making things slower since inception when it replaced html + a few ajax requests. I know, I know, I'm old. Get off my lawn.

WolfOliver 2y ago
HN should have a like button for comments
- wizzwizz4 2y ago
  It does: the favourite feature.
  - spartanatreyu 2y ago
    In case anyone reading the above is confused... You have to click the timestamp on the comment first, then you're sent to a new page that only shows that one comment and a favorite button. Sometimes the favorite button doesn't appear so you have to click the timestamp again.
thanatos519 2y ago
Turing-complete content is an abomination.
vundercind 2y ago
I remember when AJAX made things faster. Then we stopped sending html to insert into the DOM, and started sending JSON with a bunch of extra steps in between. The fastest sites I see these days usually just reload the whole page pretty often.
- tracker1 2y ago
  HTMX for the win!
  - 2y ago

scoot 2y ago

Since the author doesn't appear to understand the difference between the Internet and the Web, and thinks that React handles internet traffic, I think it's fair to assume that the rest of the article is going to be a hot mess.

verbalstoner 2y ago

JS frameworks were a terrible mistake

voat 2y ago
You're either using a framework, or unintentionally writing your own
- mickael-kerjean 2y ago
  I rewrote one of my apps in vanilla JS to get the most performance possible, the wheel I had to reinvent is under 150 line of code [1], definitely worst the small cost [2] [1] framework code: https://github.com/mickael-kerjean/filestash/tree/master/public/assets/lib/skeleton https://github.com/mickael-kerjean/filestash/tree/master/pub... [2] example: https://github.com/mickael-kerjean/filestash/blob/master/public/index.backoffice.html https://github.com/mickael-kerjean/filestash/blob/master/pub...
rglover 2y ago
The frameworks aren't the problem, it's their authors. There's a virus in the JavaScript world that makes people think ever-more complex solutions make tools better. After years asking "why is it like this" (I'm a JS dev/framework author), I realized this is likely due to an inferiority complex because hearing "real programmers don't use JavaScript" makes people feel bad so they try to compensate with complexity and end up creating messes. That and complexity pays well.

jmeyer2k 2y ago

React server actions also have this limitation. No way to call two server actions in parallel.

throw_that_away 2y ago

React is the UI Java

ravetcofx 2y ago

I've noticed the internet becoming generally slow and laggy over the last few years for older computers and devices. Things from around and before 2015 to 2017 are becoming pretty unusable for doing basic web app tasks.

Foreignborn 2y ago
I use a 2013 MacBook running Ubuntu to code in. It works totally fine UNLESS you load something like a crazy landing page with animations. I always end up having to kill Firefox and prevent that site from opening. One unexpected benefit of LLMs is they’re more performance friendly, I can query the docs of what I’m working on without loading the docs themselves.

zogrodea 2y ago

Unrelated, but I'm impressed by how fast browsers can be in some cases. I once created a HTML file with just a start/end HTML tag and 50k (unstyled) button elements in between, curious to see how it performs. I tried the same in Flutter on a release build (using Material widgets so they are styled) and the HTML was much faster. I was able to tab through (changing focus by holding tab) the buttons in both Chrome and Firefox at a consistent frame rate with no signs of any lag, while FLutter struggled and lagged quite a bit with the same. Would anyone know why that is? Are web browsers hyper-optimised for static documents (beating a "native" GUI toolkit for static documents)? Is Flutter just comparatively slow compared to Qt, GTK and so on? Does the styling have that much of an impact on performance? I am aware that updating DOM elements is uniquely slow for browsers but this experiment was a surprise for me and I'm curious for an explanation.

l5870uoo9y 2y ago
If you want performant styling stick to CSS.
- ComputerGuru 2y ago
  CSS can certainly be performant but you need to be aware of what can trigger reflows, which will absolutely destroy your performance. Cascading reflows are horrible.
Jabbles 2y ago
Can you share your code?
- zogrodea 2y ago
  I will in a bit hopefully. It was a few months ago and I don't have Flutter installed on this computer but I'm doing it now. Edit: I was coding it up now, but my storage is full (having trouble copying text to my clipboard and unable to save files) so I don't think I will be able to deliver on what I intended. Sorry about that. On the HTML side, I had a code generator (in Javascript) that output `<html> <button /> <15000 more buttons.../> </html>` and wrote it to a file. On the Flutter side, I used the default Flutter sample app (`flutter create .`) and I just used a similar code generator to put 15000 buttons in a Column widget. I don't think I'll be able to do much else to help with reproducibility sadly. If others try the same, I would be interested in if their results are any better than mine (with Chrome/Firefox being faster).

d0100 2y ago

Shoutout to the devs from pmndrs reminding the react core team that not all async is fetching crud data

bob1029 2y ago

I knew we were going off a cliff the moment GitHub did their big client-side rendering rework and made it effectively impossible to review large PRs in the web UI. This has all become too complicated as is traditional. Every JS framework I have ever used ultimately suffered the same fate. The only web framework that works long-term is whatever is documented on MDN. Something approximating PHP + AJAX has always been the correct path. If you are doing things like shipping DOM across websockets, I think you may have missed an important step somewhere along the way.

lovethevoid 2y ago
React, vue, and svelte all have MDN docs. So not sure that’s the best way of determining a better route for JS frameworks.
- 38 2y ago
  no, they dont.
  - Jowsey 2y ago
    https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks https://developer.mozilla.org/en-US/docs/Learn/Tools_and_tes... ?
    - deleted 2y ago
      [deleted]
    - 38 2y ago
      https://wikipedia.org/wiki/Ward_Cunningham#%22Cunningham's_Law%22 https://wikipedia.org/wiki/Ward_Cunningham#%22Cunningham's_L...
graypegg 2y ago
I would like to see a “framework of opinions” somewhere. 0 actual software, just documentation for standard JS and browser APIs organized in a way resembling framework documentation. The current style of web platform documentation tends to resemble a big list of objects, or the most basic and slowest introduction to web development possible. Something in-between, with chapters like “templating” or “data fetching” that focused on some opinionated but framework less structure, would be nice.

voat 2y ago

TLDR: Don't do data fetching in your components if your care about performance. Hoist it up to the route, so you don't have to wait for deeply nested components to render serially.

willsmith72 2y ago
IF they shipped this change, and you used suspending components, yes. That's a big if. (In case people see this tldr and actually start changing their apps)

gumby 2y ago

Only the web sites…and all that latency will leave extra bandwidth for all the other use of the Internet.

prinny_ 2y ago

“We care a lot about SPAs, team misjudged how many people rely on this today”. This comment worries me because I was under the impression that RSCs are an option for a specific use case and not the one approach to rule them all. SPAs should be supported and expanded because they do serve a valuable purpose not only based on their use cases but also for developers. React being SPA friendly means people can spin up hobby projects, small applications and big non SEO reliant apps with ease. Going all in with RSC and ditching SPAs means that many will be discouraged from entering the react scene due to the sheer amount for things that used to be optional and now suddenly just became mandatory. I liked react and I still like it. But I believe it’s on a path to alienate its user base.

ramesh31 2y ago

>"In React 19, we’re adding support for rendering document metadata tags in components natively: function BlogPost({post}) { return ( <article> <h1>{post.title}</h1> <title>{post.title}</title> <meta name="author" content="Josh" /> <link rel="author" href="https://twitter.com/joshcstory/" /> <meta name="keywords" content={post.keywords} /> <p>Eee equals em-see-squared...</p> </article> ); } When React 19 renders this component, it will see the <title> <link> and <meta> tags, and automatically hoist them to the <head> section of document." This is one of the most brutally stupid things I've ever seen, and has pretty much sealed the deal on me dumping React at this point.

MBCook 2y ago
Why? It fixes a serious pain point React has had necessitating things like the helmet library. This seems like a perfectly reasonable of way of doing it. How is this “brutally stupid”?
- recursive 2y ago
  Why is this not useEffect(() => document.title = 'whatever'); What's the pain point exactly? It does seem pretty weird to put it inline with the jsx. There's no indication it has a non-local effect on the DOM. Feels a bit magic for my taste. Very little of what react does seems reasonable to me though.
  - MBCook 2y ago
    While that’s basically what all this stuff really does under the covers, it doesn’t feel “react-y” to me. Using JSX does. Especially for stuff like meta tags where there can be a couple in force at once. I’m not going to argue it’s perfect but it seems like it fits in to me. It’s basically acting like the restrictions on where the title and meta tags can go no longer apply so you can just sprinkle them wherever they hopefully belong in your app. And react takes care of putting them in the right spot. > Very little of what react does seems reasonable to me though. So are you someone who dislikes it in general and just using this as one more argument? I’d be very curious to see the opinion of someone who likes react who thinks this is a bad idea.

busterarm 2y ago

As a former fullstack developer who has been fulltime on infrastructure for a decade now and reading these comments, not only can I barely follow half of the conversations but they're so far removed from the fundamentals of sending data between two places over the wire that I'm extremely satisfied with the career choices I've made. Y'all are inventing your own problems to solve.

downrightmike 2y ago
#BillableHours
- busterarm 2y ago
  To a certain degree that is true, but they're also much more replaceable. Not only have I seen multiple organizations lay off entire frontend groups, but as time goes on I work with more and more people who specialize in only this end of the stack and need people like me to wade in and solve actual problems for them. Under the hood I know how things actually work and I can quickly get up to speed on their issues, whereas it's not always so easy going the other way. Also if I had a dollar for every time I had to help web engineers "figure out" why the Sentry p95s are so high when sending large binary blobs on multiple round trips between Eastern US and Japan, I'd be a rich man.
willsmith72 2y ago
Not really. The whole point of ssr alongside react 19/rsc is exactly abstracting the idea of "sending data between two places". You're sending html and removing waterfalls by moving data fetches to be as early as possible If you don't want an interactive website, sure, just do everything on the server. That's a fine decision. Most of us work on apps where interactivity is a must
- craftkiller 2y ago
  > If you don't want an interactive website This is a false dichotomy. Gmail launched in 2004, React launched in 2013. Clearly interactive websites are possible without React.

troad 2y ago

I stopped paying attention to web dev for a few years, and those were the years when everything went from hand-written HTML + JS (+ PHP/ASP on the server side) to the likes of Node and React etc. You can imagine my confusion when I checked back in. I'm dipping my toes in now for the first time since then, and I gotta say - I don't hate it as much as I thought I would. Yes, you can end up with library soup if you're not careful, but a lot of what used to be difficult is now quite easy. There's been genuine forward progress, and it's really nice to see. (Though there does appear to be some kind of allergy in the web dev space to describing things intelligibly. It's never "XYZ is a stateless UI library built in TypeScript", it's always "XYZ lets you build bleeding-edge shardable solutions in the Web 3.7 space using YAML elem-nodes called 'qooms'. Let our bosomy anime mascot walk you through our getting started guide by simply piping this Discord link into a superuser shell")

throwup238 2y ago
You're dipping your toes back in at the right time. IMO a lot of criticism aimed at frontend development is latent cPTSD from a bygone era but things have really come together over the last half decade. NextJS and friends are bloated, but that's nothing to the shit-show that was Webpack et al. Now that that's mostly over, next-gen tooling like Vite make the development process a lot easier. CSS especially is a lot better than it was a decade ago.
toldyouso2022 2y ago
You skipped the worst part. Things are great now. I wonder how big corps are gonna ruin them this time.
deleted 2y ago
[deleted]

enlightenedfool 2y ago

Looked into React for one of my webapps. It felt too complex. I found lemonade js and happy with it. Just a few concepts that serve the purpose.

1vuio0pswjnm7 2y ago

Internet is more than the web. Can the web make the rest of the internet slower.

shermantanktop 2y ago
Let’s hope nobody invents React for Gopher.

synergy20 2y ago

which is why I switched back to vue.js, who so far is much simpler and get the job done if you need a true SPA with SSR only as an option instead of being the "new" primary focus(which made things much more difficult to use, and slower)

deleted 2y ago

[deleted]