21 ms·

If not React, then what?

• 4ntiq 2y ago
  I read through this to hopefully save all of you the clickbait and mid-way through nonsensical philosophical diatribe. It's a bit ranty and devoid of technically-caloric content. The author is advocating for use of plain HTML/SSR patterns and avoiding SPAs and complicated frameworks/libraries ala Angular/React/etc. It's an old thought that lines up with the "you don't need JS" crowd. Oh, and the author would like to kindly point out that React is legacy now. Because they said so. In case you didn't know.
  • refulgentis 2y ago
    Heartily concur. It's a classic of an essay written by one of those tortured souls who cannot understand why everyone so blithely moves past the incisive, obvious, truths they share. With a topping of how this is all just solved by "giving a toss about the user", followed by a cloying apology for being vulgar I'm not in web and am amenable to a good web dev hot take but this simply isn't worth the time, it's an array of generic wisdom delivered as if it's specific, written with the effort of someone who is proud of themselves when you disagree.
    • Spivak 2y ago
      I mean the graph in the article of Amazon vs Target vs Wayfair is pretty damning. And honestly you don't even need the graph, just go to their sites. Target is dog slow while Amazon loads instantly.
      • rafaelmn 2y ago
        > And honestly you don't even need the graph, just go to their sites. Target is dog slow while Amazon loads instantly. I was not able to notice any difference between them
        • simonw 2y ago
          Were you using a ~$2000 laptop on a broadband connection?
          • rafaelmn 2y ago
            Out of curiosity I checked on iPhone 14/4g and 2018 Intel MBP. I don't get what the point of these comments is ? If you're using RPI with a 2g connection you'll have a bad experience shopping at the site ? And somehow that's supposed to factor in to my tech stack decisions ?
            • xcrunner529 2y ago
              And it doesn’t even have to be that. Just someone at the wrong end from a cell phone tower or in a clogged one from a sports event or something.
            • simonw 2y ago
              Alex's position is that the average consumer is on a cheap Android phone, which has severe CPU weaknesses compared to any iPhone from the last ~five years: https://infrequently.org/2024/01/performance-inequality-gap-2024/#device-performance https://infrequently.org/2024/01/performance-inequality-gap-... Software engineers tend not to experience the web on the same class of device as most of their users.
              • ecosystem 2y ago
                But is the average Target shopper on a cheap Android phone accessing over non-broadband? Wayfair? It's a fair point to note devs and users might have different devices, but in some cases they don't and the decision to use React might be well-founded with that fact.
            • jmye 2y ago
              Do you not care about most of your potential customers, or do you only cater to high net worth people? If so, then sure, substandard devices and connections can be ignored. If you’re Target, on the other hand, you probably shouldn’t ignore them. I find it extremely odd that this was even a question on this site. Do you think the problem you’re solving should impact your tech stack at all, or is your tech stack more important than the problem?
      • xcrunner529 2y ago
        Yep! Made me remember my bad target experiences as well. Love how that’s all ignored by some.
  • ganksalot 2y ago
    o7 thanks, people like this who do not work in contexts with problems that React solves yet insist React is not solving problems are profoundly boring.
    • hu3 2y ago
      No need for personal attacks. And there's also the other side: people who insist in overusing React. Perhaps that's what the author refers to. I for one have see HTMX eat React for breakfast in a few of my clients during consulting.
      • synergy20 2y ago
        Really? HTMX for me brings spaghetti code on the server side. Fine for small projects but not so for large ones. I would prefer the clear separation between frontend and backend beyond small scale projects.
        • wordofx 2y ago
          React does not create a clear separation. Anyone who claims that hasn’t worked on any react bigger than a todo list. If you struggle with backend code then you’re just not a good backend developer. Maybe just stick to HTML/CSS.
      • ganksalot 2y ago
        > No need for personal attacks. i don't know about all that, but this is an incredibly tired diatribe. > Perhaps that's what the author refers to. they are clearly not.
        • sakesun 2y ago
          They are clearly not. "In short, nobody should start a new project in the 2020s based on React. Full stop."
      • wiseowise 2y ago
        > I for one have see HTMX eat React for breakfast in a few of my clients during consulting. What about the rest of them?
  • xcrunner529 2y ago
    You can read it that way if you ignore the rest of the article, I guess. They simply are saying many (most?) sites do not need to be SPAs and the baggage that entails with load times and latency. Follow a process to determine what is really needed based on objective requirements and then use objective measures to ensure it does not degrade the experience. In most cases later frameworks are slow and bulky. I certainly hate using sites like X or Target on mobile. Random delayed loading of things, loss of scrolling position when going back, things just not loading the first time it delayed reactions. It sucks.
    • wiseowise 2y ago
      > Follow a process to determine what is really needed based on objective requirements and then use objective measures to ensure it does not degrade the experience. This is how you end up with an amalgam of legacy crap that no one wants to touch. I can’t read guarantee you that outside of big tech and a couple of unicorns started by experienced devs this will NEVER work reliably.
    • x0x0 2y ago
      Nah, the rest of the article is not insightful either. eg React Native is dismissed in 5 sentences, with no real solution at all given to the basic problem of wanting to have a website and mobile apps without writing your app 3 times. Let alone a website + mobile apps + windows + mac clients. The suggested solutions do not address this need -- eg there's some Apache crap that no one I've heard of uses (it's renamed Adobe Phonegap crap that Adobe bailed on and tossed over to Apache); some random link to a 5 year old google i/o presentation; etc. As far as I know, there's basically 3 toolkits that offer this: React + derivates; Rails with Hotwire; and Flutter, which means trusting Google (fools only), and which has recently deprioritized desktop... so that's a rock solid foundation to pour millions of dollars of eng time into. And I guess Xamarin, if anyone is using that.
      • xcrunner529 2y ago
        I think sadly to that point there’s no solution given because there isn’t one. And the ones that promise it (RN) still has you doing tons of platform specific code and in some cases supporting even more platforms than just going native.
  • msoad 2y ago
    React works because I can hire engineers that can be productive quickly. A lot of tech conversations leave the talent pool aside as if it's easy to find good engineers in all of the options you might have. The ecosystem is another aspect. You have so many great options for off the shelf components and libraries with React that you might not have with other frameworks. Before anyone mentions Custom Elements and Web Components, I must say I tried it. Gave it a lot of effort to be a solution but it is not!
    • simonw 2y ago
      "React works because I can hire engineers that can be productive quickly. A lot of tech conversations leave the talent pool aside as if it's easy to find good engineers in all of the options you might have." That's covered in this section: https://infrequently.org/2024/11/if-not-react-then-what/#%22...we-need-to-be-able-to-hire-easily%22 https://infrequently.org/2024/11/if-not-react-then-what/#%22... "The ecosystem is another aspect. You have so many great options for off the shelf components and libraries with React that you might not have with other frameworks." That's covered here: https://infrequently.org/2024/11/if-not-react-then-what/#%22...the-ecosystem...%22 https://infrequently.org/2024/11/if-not-react-then-what/#%22...
      • sakesun 2y ago
        I think people prefer ecosystem with many resourceful components https://github.com/brillout/awesome-react-components https://github.com/brillout/awesome-react-components This point is not directly covered in the article.
  • deleted 2y ago
    [deleted]
• adzm 2y ago
  React is not even a framework, really. It is a great starting point for simpler sites. Honestly still one of the best solutions out there.
  • klysm 2y ago
    Completely agree. People regularly conflate react core libraries with stuff like next
  • Sankozi 2y ago
    How do you define a framework if React is not one? It is one of more clear examples of a framework: - calls your code - heavily affects how the code is written - requires significant build configuration (could even be argued it is something more than a framework, but definitely not a library)
    • gerardnico 2y ago
      A framework is declarative. You declare what you want. Generally in a configuration file and you get an app. A library does not impose any configuration. I don’t see any required configuration with React. You can use it wherever you want in your code as an addition. My piece on that: https://datacadamia.com/code/design/library_vs_framework https://datacadamia.com/code/design/library_vs_framework
      • thraxil 2y ago
        Genuinely curious if you could point to some examples of actual "frameworks" by your definition then. Because from your description, Rails, Django, Laravel, Phoenix, Vue.js, and basically every other "framework" I've encountered aren't actually frameworks.
  • hasanhaja 2y ago
    Why wouldn't simple HTML be a great starting point for simpler sites? What's it missing that React solves, in your opinion?
• dimgl 2y ago
  > Frameworkism isn't delivering. It isn't? I find React to be great to work with.
  • xcrunner529 2y ago
    Yes, you the developer. I think that’s his point. The performance if react sites is another thing and that’s what the user cares about. It also doesn’t work on mobile. React native was worshipped and now is thrown out.
    • alex_smart 2y ago
      Is it even working for the developer though? Last I checked the server-side rendering performance for react based frameworks was somewhere like 200 pages per second? Is that something to be proud of as a developer?
    • robertoandred 2y ago
      React is absolutely performant. A developer who makes a slow React site would make a slow site with something else.
      • xcrunner529 2y ago
        Tell that to all the former PHP developers. Where are these performant React sites? The largest and best tech companies out there certainly can’t do it.
        • robertoandred 2y ago
          The same former PHP developers responsible for all those slow WordPress sites?
          • xcrunner529 2y ago
            The ones who made react.
• QuiDortDine 2y ago
  WOW this is a long article! Still waiting for the substance though... The only point I can agree with is that React is stupidly hard to learn. It feels like a tool made for aliens, though once you master it, it can be pretty efficient. Sorry to be the bearer of bad news, but the JS-free web isn't coming back. And if you're using modern JS, you might as well use React (or a similar tool). The user won't be able to tell the difference.
  • thepasswordis 2y ago
    What do you find hard to learn about react? I think a lot of tutorials are really bad, might be the problem.
    • 000ooo000 2y ago
      Not GP. Started using React at work around 2017. The hooks API is just awful. Those complaints are extremely well-trodden ground at this point so I won't rehash. I'm using Lit.js for personal stuff instead these days. Shadow DOM isn't perfect but web components with Lit has been pretty low-surprise so far, which I can't say for Hooks React.
      • lucsky 2y ago
        > The hooks API is just awful Hard disagree. Hooks are 100% what is best about React these days and custom hooks make organizing or encapsulating and sharing behaviors between components a total breeze.
        • halflife 2y ago
          This is something that I just don’t get, in the olden days, when you wanted to encapsulate logic and state and share it between instances you would just use a singleton service. But now when classes are “bad” for some reason (when the whole point of a class is encapsulation of state and logic) you get weird stateful functions that makes everything hard to track with complicated API.
• valenterry 2y ago
  > Frameworkism isn't delivering. Correct. The reason is not the frameworks but the languages. What is needed is a much more high-level and feature-powerful language. Just look at react. Passing down dependencies/values is a pain. So what did react do? It introduced contexts. Similar, other react addons try to solve this problem. But they all sacrifice type-safety in the process. They simply cannot solve this problem; only a better language can. Typescript maybe could, but they restrict themselves to not generate code (or at least very limited, I think for enums they do it). Without a change here, nothing can ever improve.
  • klysm 2y ago
    This is straight up not true. React state management is very flexible and requires you to think about what your problem is and the nature of state. There is absolutely nothing preventing you from keeping those safety - I’m not sure what you mean by that. The typescript type system is very advanced, maybe even too advanced! I disagree that more sophisticated languages are required.
    • valenterry 2y ago
      See what Peter Kelly wrote. For example.
  • peterkelly 2y ago
    The React team should have done their own language, rather than making it a framework/library. Then they could ensure the absence of side effects in rendering code, and had a better way of detecting updates. The knowledge about how to do this was already out there for many years before they started: https://en.wikipedia.org/wiki/Functional_reactive_programming https://en.wikipedia.org/wiki/Functional_reactive_programmin...
    • CityOfThrowaway 2y ago
      Yes, but if they did their own language it would have almost certainly died in obscurity. React won because it solved a real pain point for a group of people, using the techniques they were already using... but better! Having built large apps in angular, handlebars, and jquery... it was (and still is) a godsend for building highly interactive, stateful web applications. I am deeply skeptical of some of the stuff that people are doing now wrt. putting backend logic into React components, but the fundamentals of React are still very reasonable to me.
• Aeolun 2y ago
  [flagged]
  • lucsky 2y ago
    Painfully so.
• Aeolun 2y ago
  The only part of this whole thing I agree with is that you shouldn’t start a new project in React. Switch to SolidJS, and gain all the benefits (aside from the huge ecosystem) but with a speed to match plain HTML/JS.
  • fastball 2y ago
    > aside from the huge ecosystem
    • croes 2y ago
      Sometimes less is more
• quantadev 2y ago
  The people who don't think React (or Vue) is important are the same ones who have never worked on a large project with lots of screen updates and state changes that absolutely cannot be avoided. React is still #1 in popularity, and the most crucial tool for almost any web developer (aside from using TypeScript, instead of plain JS which is also critical for large projects) React is reported to be used by 39.5% of developers worldwide, while Vue.js is at 15.4%. The number of "apps" using just HTML+CSS is precisely zero, because those aren't "apps" they're documents.
  • xcrunner529 2y ago
    Ha and jquery was pretty high too. How is that an argument?
    • quantadev 2y ago
      I'll happily ditch React once something better emerges. I've been doing web development since 1998, so I'm used to change.
  • goosejuice 2y ago
    Generalizing much? React is as popular as it is because of inertia. React holds an important space but its hardly the only tool that can succeed in a "large project with lots of screen updates and state changes". That's ridiculous.
    • quantadev 2y ago
      The reason I said "(or Vue)" was specifically to say that there are other leading frameworks. I didn't say "or Angluar" because in my opinion it's a race between React and Vue at this point. But if you think there's a third contender, let me know. I'm always looking to learn. My main point was to compare "frameworks" v.s. "no frameworks", rather than to say that React is best, but if you want my opinion then yes I do say React is indeed the best, and I admit it's an opinion not a fact. lol.
      • 2y ago
• wiseowise 2y ago
  > It's the rewarding side of real engineering, trying out new materials under well-understood constraints to improve user outcomes. Good thing we’re mostly keeping the attitude to hobby projects. Can’t imagine hundreds of artisans™ bikeshedding over what the hell this even means. And I can’t read with a straight face an article talking about complexity of React while suggesting Vue (sic!) as an alternative. Lol!
  • em-bee 2y ago
    what is wrong with vuejs?
    • wiseowise 2y ago
      Nothing is wrong with Vue.js, but saying that it is less complex than React is just false.
      • em-bee 2y ago
        are you talking about the internal or about the websites built with them? i have used neither, but what i gather from many discussions and articles is that vuejs makes for less complex websites.
• cannibalXxx 2y ago
  I still think you can build good tools using just html, css and pure js if you have the right knowledge. For example, this social network was built without any frameworks and has the performance it has https://chat-to.dev https://chat-to.dev
• deleted 2y ago
  [deleted]
• simonw 2y ago
  A fun thing about reading Alex is that you can tell he's had the same arguments over and over again for a decade now and he's frustrated with having to keep on making the same points and getting the exact same responses. Most of the people commenting on this piece won't have read this whole article (it's long, and internet attention spans are short). As a result, you'll find plenty of the comments here were exactly predicted by his writing. I see him as something of a Cassandra at this point, doomed to see the truth about web performance based on many years of research... and then to have nobody believe him. https://en.wikipedia.org/wiki/Cassandra https://en.wikipedia.org/wiki/Cassandra
  • 4ntiq 2y ago
    [flagged]
    • deleted 2y ago
      [deleted]
    • dang 2y ago
      No personal attacks, please. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html Edit: since you've been doing this a lot already, I've banned the account. If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future.
      • 4ntiq 2y ago
        [flagged]
  • goosejuice 2y ago
    Maybe because they start with this tldr: > In short, nobody should start a new project in the 2020s based on React. Full stop. Good arguments here but the dogma doesn't help.
    • andybak 2y ago
• pyrolistical 2y ago
  One of the under appreciated reason why spa took off is it exploits the lower cdn cost. Things that generate html on the server side need to pay for the higher bandwidth costs that are hard to cache well. In the other hand with spa, a well configured cdn can have a short ttl on index.html and cache the unique per deployment js bundles forever. The only server bandwidth cost is the actual api data
  • hasanhaja 2y ago
    I don't think so. You can still generate a significant amount of your static HTML at build before pushing that to a CDN, and load dynamic content using JS; JAM Stack.
• aantix 2y ago
  Turbo morphing. It’s part of Hotwire. Re-Render the full page server side, app takes response, applies only the changes needed. Preserves scrolling state, etc. Super simple pattern for building dynamic sites. https://turbo.hotwired.dev/handbook/page_refreshes#morphing https://turbo.hotwired.dev/handbook/page_refreshes#morphing
  • ericb 2y ago
    This is the way. It achieves 95% of the effect, and you maintain one implementation, not two.
• shepherdjerred 2y ago
  You can build a good website in React and you can build a bad website in React. It's easier to build a bad website in React than it is to build a bad website with just plain HTML/CSS.
  • teruakohatu 2y ago
    > It's easier to build a bad website in React than it is to build a bad website with just plain HTML/CSS. I think many people would argue that it is easier to build a good web app in React than plain HTML/CSS/JS.
    • shepherdjerred 2y ago
      Sure, but most people think they’re building a webapp when they’re really building a website.
      • teruakohatu 2y ago
        No arguments there. Nothing worse than one-page website that seems to be a overly complicated SPA instead!
• emmanueloga_ 2y ago
  I think React is fine, especially when using it mainly for rendering, keeping async stuff out of the components as much as possible. The React API is way nicer to construct DOM trees than using Fragments, creating and appending children elements, concatenating strings to produce HTML, etc. Imagine being able to do this without importing any 3rd party code: const content = html`<h1 id=hello>Hello world!</h1>`; // New API: html Tagged templates [1]. console.log(content); // Outputs: { type: 'h1', props: { id: 'hello' }, children: ['Hello world!'] } document.querySelector("#container").patch(content); // New API: HTMLElement.patch. I'm sure there are a few more details involved but it sounds like a relatively small addition to the current DOM APIs. I’m not aware of any initiatives like this currently. WebComponents could also benefit, as building a DOM tree within a class extending HTMLElement is still cumbersome: the WebComponents API doesn't really add anything to simplify DOM handling, which is why libraries like Lit exist. -- 1: Inspired by https://github.com/developit/htm https://github.com/developit/htm
  • emmanueloga_ 2y ago
    ... also TFA conflates web application architecture with frontend frameworks, creating a false dichotomy. For instance, I’m building a site that serves static HTML but still benefits greatly from Preact for the dynamic parts. The critique seems focused on SPA architectures heavily based on React, as seen in frameworks like Next.js and Remix. To be clear, I also lean away from that style of web application architecture, but I’m not sure this 20-page article effectively makes the case for simpler alternatives.
    • floydnoel 2y ago
      I thought Next.js and Remix were SSR-based frameworks, both created as alternatives to building a SPA. After the initial "SPA fever" died down, these frameworks cropped up to address the shortcomings of SPAs such as a lack of SEO-compatibility.
      • emmanueloga_ 2y ago
        Next.js and similar tools redefine server-side rendering (SSR) to mean generating HTML on the server using the same code that runs on the frontend, requiring server-side JavaScript and what they call "hydrating" on the client. Next.js and friends are very much SPA frameworks, they just try to address the shortcomings of SPA architecture and in the process introduce a lot of complicated layers. Since the term SSR has been... "repurposed" now, what I was talking about a simpler CGI-style approach—no JavaScript, no async complications like Suspense. Rendering React components server-side often requires special tricks, especially when components interact with DOM APIs or make HTTP calls. As an example, Templ has a detailed guide on using React in a traditional architecture without server-side rendering React components [1]. --- 1: https://templ.guide/syntax-and-usage/using-react-with-templ/ https://templ.guide/syntax-and-usage/using-react-with-templ/
• recursivedoubts 2y ago
  If not react(ive, of some flavor), which is appropriate for some things, then hypermedia, which is appropriate for a different but overlapping set of things: https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/when-to-use-hypermedia/
  • pier25 2y ago
    React is not reactive. That's why it re-renders the whole vdom when you store state at root.
• tasuki 2y ago
  If not React, then Elm!
  • bbkane 2y ago
    There's a lot to like about Elm, but the tradeoff is that the BDFL (Evan) has essentially abandoned public work on it [0, 1], and the community seems to be shrinking [2]. I personally wouldn't choose it for new projects, and I consider it essentially a brilliant research language (it's inspired a LOT of other UI work). 0: https://elmcraft.org/lore/elm-core-development/ https://elmcraft.org/lore/elm-core-development/ 1: https://podcasts.apple.com/us/podcast/elm-the-future-of-open-source-with-evan-czaplicki/id1687271887?i=1000678536838 https://podcasts.apple.com/us/podcast/elm-the-future-of-open... 2: https://reasonableapproximation.net/2024/11/02/elm-community-not-very-active.html https://reasonableapproximation.net/2024/11/02/elm-community...
  • yakshaving_jgt 2y ago
    If I needed to build a Single Page Application, personally, Elm is the only tech I would use.
• lilalomoslama 2y ago
  In reality these few ms more do not hurt these companies. it is sad but true. I think react native is always a better choice than tools like cordova while the best choice is native development. every time i use a cordova app it is painful and you just know something is off. react-native apps are a lot nearer to native experience. you can differ them if your really trying to though. but if your just want a good native ios and android app react-native is a good choice. and you can slowly learn native development from there and shift to native if you like.
• peutetre 2y ago
  The only sure cure for the JavaScript blues is WebAssembly. Use something like Leptos and be happy: https://www.leptos.dev/ https://www.leptos.dev/
  • Rohansi 2y ago
    The treadmill continues.
    • peutetre 2y ago
      Well, it's more like graduating from a kid's tricycle to a mountain bike. Sure the tricycle had streamers on the handlebars and the little basket on the front was cute, but you can get more places with a mountain bike.
  • pier25 2y ago
    Leptos is even worse than React in memory consumption and startup metrics. https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht...
    • peutetre 2y ago
      But faster overall, one code base front and back, and it will only improve as new WebAssembly features roll out (js-string-builtins, Memory64, eventually component model DOM access). And any high performance functions you need on the front end will be higher performance than JavaScript. Like bloom filters for example: https://nuenki.app/blog/bloom_filters_optimisation https://nuenki.app/blog/bloom_filters_optimisation
      • pier25 2y ago
        > But faster overall Only in further updates to the DOM. There are very few use cases where you need to continually update thousands of DOM elements. For most use cases, start up time and memory usage are really the most important metric.
  • 2y ago
• oliwarner 2y ago
  > React developers are web developers. This has felt increasingly untrue recently. I hope I'm just experiencing the peak of the bell curve but I've been bumping into more and more devs who only have experience in SPA React and associated styling frameworks. Ask them to actually style something and they flake out. I was used to some tribalism in backends (everyone thinks theirs in the best and equally hates PHP devs and Wordpress) but can all publish a static page if asked. It's a self fulfilling issue. Mid-managers want React because Facebook and pre-juniors train to meet job postings. Not enough question it.
  • pier25 2y ago
    It's not recent. We've had memes for years about React devs using divs with click events instead of using links.
    • oliwarner 2y ago
      No, but five, ten years ago that wasn't the average "junior web dev" outlook. There was diversity in experience and education. Big money FAANG posts have really distilled the market down. Maybe I'm just an oldfart. When I started a quarter of a century ago, people were crowing about Frontpage experience. I'm fairly sure I'd boasted about Macromedia Dreamweaver 3 expertise. And there was an explosion of technologies being thrown around between different devs. But now you don't get to discriminate against bad technology if the market demands it.
    • claytongulick 2y ago
      What's the beef with clickable divs? Are you referring to just the case where they're misused for top level navigation? Or more generically? It's pretty common to not want the default behavior of an A tag, so instead of the e.preventDefault(); e.stopImmediatePropagation(); dance, a clickable div works great. Non deep-linked sub-nav (tabs, etc...) come to mind. Or maybe I'm hooked into a router and I need to pass some additional state, or control a transition direction, or maybe I want a navigation to happen after some async action completes, etc... Also, not all clicks are navigation actions. BTW, I'm not a react guy, just vanilla web components here, but genuinely curious why you see clickable divs as a bad thing?
• cushpush 2y ago
  Surprised nobody has mentioned Electric Clojure yet, with client and serverside blocks nested in _one file_.
• dr_dshiv 2y ago
  “Think, do, observe” — that’s over?
• flimsypremise 2y ago
  I don't think the author of this article actually understands the pressures that increasingly drive all frontend development into javascript frameworks, but those pressures are actually very straightforward: • A large portion of the cost of maintaining a code repository goes toward maintaining the build. • Multiple builds per repo create significant costs. • Any web application with a UI _requires_ a frontend build for CSS/JS. Anyone around from the JQuery/pre-SASS days will recall the mess that lack of things like dependency management and ability to control import order caused. • If the frontend build is already baked into the process, you can save costs by _only_ using a frontend build. • SPA patterns are the easiest to use with a frontend build, have the most examples/comprehensive documentation.
  • baggy_trough 2y ago
    I write web apps with UI using ES6 native modules and https://stimulus.hotwired.dev https://stimulus.hotwired.dev. It's very simple, and life is good. No-build is the way.
  • deergomoo 2y ago
    I think the author understands that just fine (I follow him on Mastodon and this is something he is very passionate about). To me his argument is that this shouldn't—and doesn't need to—be the case. The vast majority of sites out there would be just fine, and in many cases much better, as traditional server-rendered pages with a thin layer of JS on top for enhancements and for islands of interactivity. That massively reduces the complexity and cost of creating and maintaining a build. Most of us aren't working on anything that requires the entirety of every page and the entire navigation model to be implemented on the client.
    • lucsky 2y ago
      So he's basically publishing a 20 pages philosophical logorrhea to make the simple point that developers should pay more attention to the difference between a web SITE and a web APP and choose their stack accordingly, which is a totally fair point to which I 100% agree with. What I fail to see is how React is responsible for any of this because this sort of reads like his wife left him for one of the React engineer or some shit.
• lopatin 2y ago
  I'll continue using vanilla React, for the same reason I use Java: it's reached the coveted "boring technology" status where it's mature, stable, fast enough, and has a huge community, resources, and ecosystem. I won't let go of that easily. However, this is a pretty epic rant nonetheless.
  • MarcelOlsz 2y ago
    You're going to love Vue. Took me about half an hour to switch and be productive and never looked back. I've switched multiple teams/devs to it as well. If not just for the devtools experience. I switched right before all the messy React stuff started getting released.
    • aerhardt 2y ago
      But why would OP or I switch away from React when we believe it's mature, stable, fast enough, and has a huge community, resources, and ecosystem? And perhaps most important of all: it's the tool we know.
      • MarcelOlsz 2y ago
        I only responded because they said they're using vanilla React which for some reason in my head instantly translated to "old version of React before it started sucking", and replied accordingly. >But why would OP or I switch away from React when we believe it's mature, stable, fast enough, and has a huge community, resources, and ecosystem? Yeah fair enough.
        • lopatin 2y ago
          By vanilla React I meant that I don't use the new Next.js / SSR stuff and instead build a JS file.
          • MarcelOlsz 2y ago
            Yeah I only realized that later :P
• draw_down 2y ago
  [dead]
• whalesalad 2y ago
  [flagged]
• k__ 2y ago
  So glad I work in an ecosystem that doesn't even support SSR. I'm also glad that the local-first movement got some traction.
• andrewstuart 2y ago
  I love react and don’t feel the pain that people talk about. Yes it’s hard to learn the mental model but worth the effort. My one tip to make your life with react easier …. don’t use state except within a component, instead send document events …… makes react 10X easier. Having said the above I don’t do any SSR and not a fan of it.
• eawgewag 2y ago
  I honestly think this conversation gets overly complex because we fail to define the kind of websites we are talking about. These are my definitions, so I'll just share them upfront: - a web site -- which has low interactivity requirements. Blogs, documentation sites, etc, go here. A vast majority of websites are in this bucket - a web application -- which has high interactivity requirements. Things like Gmail, Linear, Google Calendar, and an enormous amount of SaaS apps fit in this bucket of things. React is better at anything else at making the second. React developers happily pay the weird tradeoffs that come with it in order to efficiently develop the second. React is pretty reasonably good at making the first, but the negative costs are more obvious. As someone who has worked on one of the most consumed React apps in the world (Discord), I think the concerns with React are overstated. People want a good product, they don't care about the framework and it's costs. React is one of the most efficient (in terms of developer productivity) ways to get there. I'm not a React loyalist; I would love to see someone dethrone React. My ears are always to the ground for new developments in technology. In my opinion it hasn't happened yet, but I would be surprised if it never happens.
  • chimpanzee 2y ago
    > React is better at anything else at making [a web application] Mithril.js beats it in my opinion. I’m sure many developers would argue in favor of other libraries over React. React is simply the most popular.
    • danjl 2y ago
      Being the most popular comes with big benefits. There are far more articles about how to support issues that you run into, and many more libraries available for your use. While other libraries maybe "better"in some cases, giving up the support of the large community is a big cost.
      • chimpanzee 2y ago
        No argument there. But “better at” implies something inherent to React’s design rather than to its community.
• fridder 2y ago
  Well, LiveView is great
• johnfn 2y ago
  Reading over the authors primary reasons to not use React, they strike me as fundamentally misguided - mostly solving problems that most people don’t have. One reason it says that React is a poor choice is performance issues. But front end performance issues are almost never the most pressing issue to deal with. React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. Yes, there are a few specialized domains where this will matter. No, you probably don’t work in one. Greater leverage can almost always be derived from improving the backend. The second reason the author says is that it’s based on a legacy eventing system which supports IE. The author goes on for quite a while to say how bad this is, but I question the assumption it’s predicated on: the legacy eventing system never bothers me, and it doesn’t create issues visible to my users. As far as it seems to me, this argument is akin to saying that React hasn’t bothered refactoring an old part of the code base. Yes, that’s not great, but it hardly strikes me as a reason to drop a framework entirely. Finally, the author doesn’t actually give a prescription as to what to use instead of React. This is, personally, where the argument really falls apart. React does make a set of tradeoffs, I don’t deny that, but most alternatives I’ve seen make a worse set of tradeoffs that shift more work onto the engineer. Of course, since the author doesn’t actually highlight any alternative, we can’t have a discussion about what you’re trading away, but I suspect that the author makes no proposal because he knows that any alternative would immediately be shot down as obviously worse than React.
  • aaronblohowiak 2y ago
    >React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. Yes, there are a few specialized domains where this will matter. No, you probably don’t work in one. Greater leverage can almost always be derived from improving the backend. Respectfully, I disagree on all of these points.
    • Tronno 2y ago
      Care to elaborate?
      • 2y ago
• itronitron 2y ago
  then anything else?
• qudat 2y ago
  > The choice isn’t between JavaScript frameworks, it’s whether SPA-oriented tools should be entertained at all. For most sites, the answer is a clearly “no”. “Most sites” sit in the world of marketing, ecommerce, blogs. True, they don’t need an SPA. Then there are businesses that “require” highly dynamic websites with tons of data funneling through them. I use require here in the sense of business requirements set by the various Product teams. These products benefit from being an SPA. Preload and fetch is such an incredible paradigm for speed and interactivity that every company I’ve worked for has appreciated. Company employees are not trying to run their work browsers without JS nor do they even have to particularly worry about mobile support. It’s a very predictable environment: office, work laptop, internet that can support video calls, and a modern browser. That’s the operational stack that many businesses require. > The predictable consequence are NPM-algamated bundles full of redundancies like core-js, lodash, underscore, polyfills for browsers that no longer exist, userland ECC libraries, moment.js, and a hundred other horrors. People really love to hate on npm without trying to understand the reason why it exists in its current form: https://bower.sh/my-love-letter-to-front-end-web-development https://bower.sh/my-love-letter-to-front-end-web-development As a semantic aside, I wince when people call React a framework. If we think of an SPA in terms of an MVC framework, it primarily handles the V. So really it’s a view library since developers can use whatever M and C they want. Next.js is a react framework and as a React expert it’s something I have zero interest in using. I could keep going but these arguments have been argued and counter-argued before. For a different spin on the success of react: https://bower.sh/react-is-bad-because-its-great https://bower.sh/react-is-bad-because-its-great
  • johnfn 2y ago
    I agree with most of what you said. As a minor nit, my understanding is that you call into a library, whereas a framework calls into you. Since React typically does most of the calling into my components I think it’s fair enough to call it a framework.
    • qudat 2y ago
      That’s a nice description but it is not perfect. React does one thing well: view = func(state) It doesn’t have a great story for virtually anything outside of that single function which means for many large apps it is never enough.
• lerp-io 2y ago
  the irony is that the website javascript/css is broken atm
• talkingtab 2y ago
  I think almost any technology gets to the "this is stupid" point. Not it "was" stupid, but it is. We understand something so well, we know that despite being useful it is fundamentally flawed. This is not usually verbal knowing, but initially more from an intuition and understanding a pattern. I have used react, it was certainly a better choice than the alternatives. I like it. But it is now "stupid", at least for me. And why? Because my whole web paradigm has been changed by "mobile first". What is mobile, and here I am talking iPhone and "good" Android? It is a good processor with tiny screen and really good graphics processor. You can run pretty good games on many/most phones. So why not use that 3D technology instead of html, css? Or at least in addition to. If you play around for react-three/{fiber,drei} for a little bit it feels like you have burst out of a straitjacket. I once was told to make a product "cool" and after struggling to understand what "cool" even meant, I came to an idea. Things are cool if they make it so you never see the world the same way again. react-three/{drei,fiber} and threejs are cool. [For example https://r3f.docs.pmnd.rs/getting-started/examples https://r3f.docs.pmnd.rs/getting-started/examples]
  • Etheryte 2y ago
    These are cool demos, I agree, and they definitely show a glimpse of what the future of the web could look like. Right now though, pretty much all of them take ages to load, then spin my fans up as they run at low fps. And this is on a dev laptop, can't imagine what they're like on mobile or an older device.
    • nomdep 2y ago
      My iPhone 12 just crash the page while loading
• icedchai 2y ago
  I never liked React. I'm primarily a backend developer, and preferred server generated HTML with a sprinkling of Javascript. It may sound ridiculous to some, but I miss the JQuery days. For newer projects I'm looking at Elixir / Phoenix / LiveView and HTMX.
  • ilrwbwrkhv 2y ago
    Look at Imba. If you are strong enough to avoid cargo culting and try things which aren't popular, they are some of the best ways to build frontend apps out there: https://imba.io/ https://imba.io/
    • icedchai 2y ago
      Thanks. It looks interesting and I will check it out.
  • YetAnotherNick 2y ago
    No need to miss jquery days. If you want jquery you can use it now. I know at least some companies use it even for greenfield projects.
    • icedchai 2y ago
      I'm fine with using it for personal projects. For anything with a larger team, they'd probably look at me like I was crazy if I suggest anything that didn't involve React, at least in these parts.
    • cies 2y ago
      Hasn't JS caught up with jQuery mostly? * x-platform (that was a big thing in jQuery in the beginning): solved in JS * DOM selection (not as elegant w/o some aliassing, but still): solved in JS * making XHR: solved in JS * building plugins: solved in JS * method().chaining().style().of().programming(): not in JS That's mostly I think.
• deleted 2y ago
  [deleted]
• openrisk 2y ago
  The overall landscape for developing applications is a mess but this article does not help much with clearing it up. One reason for the mess seems to me is the coexistence of many paradigms for achieving similar functionality (for example you can draw many different boundaries between client and server). Combine this with the many distinct use cases (form factors, application types etc.) and the various non-interoperable platforms and you have a serious combinatorial optimization problem. Depending on what one wants to do there might be a sweet spot of the 80%/20% type. Alpine.js seems to one such, which if it was developed many years ago it may have saved a lot of wasted complexity.
• omani 2y ago
  https://www.leptos.dev/ https://www.leptos.dev/
• luxuryballs 2y ago
  *Blazor enters the chat*
• breadwinner 2y ago
  Here's proof that you don't need a big fat framework: Take a look at this SPA app: https://github.com/wisercoder/eureka/tree/master/webapp/ClientApp https://github.com/wisercoder/eureka/tree/master/webapp/Clie... It is well architected, yet only uses a 500-line component lib and a 500-line router.
• lihaoyi 2y ago
  The fundamental magic of react is that it lets you write code that renders O(n) UI states in a functional manner (i.e. by returning the HTML you want) rather than O(n^2) UI state transitions in a mutable manner (by mutating the page via nested callbacks), and somehow makes it kind of fast-ish People love complaining about React, but I don't know if they remember the pre-React world where you had to write the code to manage O(n^2) UI state transitions via recursive mutating callbacks. Simple things like "have a the list of photos shown always kept in sync with a label showning count of photos" was incredibly error prone, and the complexity of implementation went up quadratically with the complexity of your app (due to the n^2 state transitions you needed to worry about!) Today React is not the only one to do this O(^2) to O(n) complexity reduction, but it was the first to go mainstream, and very much deserves its success in spite of its various shortcomings
  • hasanhaja 2y ago
    How are you getting to O(n)? Is that in terms of the logic you need to read and keep in your mind? Or is it the actual computational complexity?
    • teddarific 2y ago
      Am curious on the O(n) calculation as well haha — I get what OP is saying, but would love to know if there's some deeper technical details here.
      • lihaoyi 2y ago
        The basic idea is if you have n ways your page can display, with the old PHP/CGI whole page refresh model you needed to write n endpoints, but every interaction required a slow and disruptive whole page refresh With pre-react single page apps, if you had O(n) ways your webpage could display, you needed to write code to account for n^2 ways that each of those n states could transition into another one of those n states With react, you write code to render n pages, and get the fine grained interactivity for free with good (enough) performance. It basically removed a tradeoff/dilemma that had been facing web developers since time immemorial, so no surprise it was a big hit
• throwaway284534 2y ago
  I hope that I’m not the only one who feels the anger emanating from these sort of blog posts. It’s stuff like the Qwik developers claiming things like “Hydration is pure overhead” as if it’s the mathematical proof that keeps their reality from crumbling. It’s the same thing on YouTube with people like Theo, gnashing their teeth at how Tailwind is incredible; You’re objectively stupid for not liking what I like; You’re using it wrong; You’re a not as smart as me; I drew you as the Soyjak and me as the Chad. Please won’t somebody tell me that I’m cutting edge?! I really wish these people would pick up a history book. Unlike back-end developers, whose worth is intrinsically recognized as necessary, front-end development was lowly micro-managed job that must simultaneously keep up with customer expectations in a variety of formats while also rendering whatever slop passes for a REST API. React’s adoption was a combination of talented marketing and a genuine empathy for the frustrations of a 2010s web developer. They gave us a white-lie to pitch the idea to our managers: “It’s just the ‘V’ in ‘MVC’!” JSX freed us from the jQuery-Rails template spaghetti. A quiet revolution soon followed and everyone’s been butthurt ever since. Look — Server-side templates, especially the “stringly” typed variety, are a demonic chimera suitable only for depraved alchemists. There’s no type-safety, no IDE references. You’re in Hokey Pokey Hell — we start with a string, now we’re interpolating, back again, now once more deeper and let’s really put your editor’s syntax highlighter to the test! It’s no surprise that stringly typed tools like HTMX and Tailwind are so deeply admired by mid-career developers who are frustrated by their lack of experience and eager to prove their talent. That’s all very normal and healthy, but the problem isn’t that React is too complex. Building software as team is a complex task of communication, and pretending to be illiterate doesn’t make the hard words any less difficult to read. There’s most definitely room for improvement in React, and the team at Svelte demonstrated that you could have your state and skip the boilerplate too. Svelte’s compiler is a genius move and unfortunately for them, React’s upcoming v19 will commodify their complement. It’s never been about replacing React — it’s about empathizing with developers and making it easier to work together.
  • jakubmazanec 2y ago
    I generally agree (that the React isn't the main culprit), but what does Tailwind have to do with templating? It's still just CSS classes, but with specific names. Also, I bet you could have strongly typed class name strings using TypeScript's template literal type somehow.
• firefoxd 2y ago
  The fundamental problem with React and the like, is that it forced developers to unlearn the anchor tag. If you can change the url via js why use an actual hyperlink tag? Over the years, I'm seeing more and more unlearning of fundamental web from new frontend devs forged in boot camps.
  • teddarific 2y ago
    The entire disappearance of semantic HTML tags has been sad to see. It's just all <divs> inside of <divs> inside of <divs> these days.
    • beeflet 2y ago
      To be honest, as someone who like semantic HTML, it's a pain to search for an appropriate tag and then try to figure out how to undo all its quirks and re-style it.
    • lmm 2y ago
      Semantic HTML was always a wrong half-solution to the problem. A website is always going to need custom semantics, the random grab-bag of whatever ideas people had back in 1993 is not a good set to base anything on.
  • quectophoton 2y ago
    But anchors and hyperlinks mean I make a new HTTP request to download the full page content, and make the browser re-draw only the parts that changed[1]. On the other hand, with something like react-router you can now just download the full page content[2] but without <head> [3], and then make the browser re-draw only the parts that changed. Only half-joking though. People can build things whatever way they like, and these frameworks can have good trade-offs. But sometimes the justifications devs give[4] just sound like they're reluctant to say "because I already know it, so I'm more efficient with it" or something like that. [1]: "Paint holding". [2]: Code splitting. [3]: These savings are probably offset by the library's 19kB, anyway. Or with that small icon that was inlined as base64. [4]: Which they don't need to give to anyone, unless it's for a situation like an employer asking for it.
• jakubmazanec 2y ago
  Great, another misinformed rant about React; meanwhile React developers get stuff done without inventing yet another template language. Also, website aren't slow because of React, they are slow because of shitty developers or insufficient budgets.
  • hasanhaja 2y ago
    Why do you think bad developers or teams without sufficient budget may produce bad experiences when using React? What should those teams be caring about that React doesn't solve for them?
    • hombre_fatal 2y ago
      Interactive UI development just isn't easy nor simple regardless of the platform and framework. A tool like React can shrink the space you need to be vigilant about to ensure performance (not just speed but also UX), but you still need vigilance and attention to detail to make sure you're not making mistakes like running something on every re-render that you meant to do just once. And it has its own idiosyncrasies that you need to be vigilant about. Like if you write a hook `const x = useMyHook({ optionA, optionB })` then you need to handle the cases (either at the call site or inside the hook) where the options object is new one every render and when optionA or optionB are non-primitives that change every render.
  • sabbaticaldev 2y ago
    COBOL developers also get stuff done
    • cheema33 2y ago
      Yes, but is COBOL increasing in popularity with devs year after year?
      • sabbaticaldev 2y ago
        not anymore. React, I have the impression as a long time developer, might have peaked too
• spintin 2y ago
  [dead]
• atum47 2y ago
  > if not React, then what? TinyJS?! http://github.com/victorqribeiro/tinyjs http://github.com/victorqribeiro/tinyjs
• throwaway0123_5 2y ago
  I'm not a web dev at all, but when I need some web UI ClojureScript/Reagent works pretty well. I get all the pretty React components while being able to avoid JavaScript and JSX entirely (all XML-style DSLs that have closing tags I find incredibly verbose and ugly).
  • matesz 2y ago
    People don’t understand the beauty of closure!
• harrall 2y ago
  I've been building sites since the 2000s and I'll let you know why React or jQuery "won." It's because when you write code using these libraries, your code looks nice. I cannot say that for a LOT of libraries, especially MOST frameworks. Sorry for calling AngularJS out but look at a code sample from early Angular: https://stackoverflow.com/questions/42823436/angularjs-error-controllerctrlreg-controller-is-not-registered https://stackoverflow.com/questions/42823436/angularjs-error... (It looks terrible.) React will be unseated like jQuery got unseated when someone makes something that looks nicer. Every time you write a library (or even API at work), make sure to look at your code samples and you better be 100% be able to say "this is pretty."
  • Null-Set 2y ago
    A more generous way to say this is that the code is more readable, which is in fact important in a growing codebase.
    • jes5199 2y ago
      plenty of react code looks nice but is still unreadable
    • yakshaving_jgt 2y ago
      The code samples in Hackers Delight are awfully pretty, but by no means readable. Pretty definitely does not mean readable.
  • agumonkey 2y ago
    To me it goes beyond the looks. Angular terminology and semantics were always very alien. React is no angel either, but it seems influenced by older, more tested concepts (FP and such). That said, I think client side UI/UX is about to see yet another large wave of change. Hearing chats from solidjs devs make me feel that there's a whole new and saner space to describe simple and fast programmable interactions.
    • cies 2y ago
      React does very little. You still need other libs to go with it before you can compare the set of them to Angular.
• cutler 2y ago
  React also gives you React Native, that's why.
  • hasanhaja 2y ago
    https://infrequently.org/2024/11/if-not-react-then-what/#%22...react-native!%22 https://infrequently.org/2024/11/if-not-react-then-what/#%22...
    • d0100 2y ago
      His response to native code and plug and play native plug-ins is using webviews?
    • cutler 2y ago
      Bluesky is built with React Native. Case closed.
• incrudible 2y ago
  "design for user needs, not organisational convenience" If I've ever come close to something like a natural law in software development, it's Conway's law. Therefore, this strikes me as saying: Design your airplane according to what the pilot needs, not aerodynamics or gravity.
• GMoromisato 2y ago
  My answer to this is https://gridwhale.com https://gridwhale.com. GridWhale runs your code entirely on the server and then remotes the UI to the browser via a platform layer. The advantage is that you can program a web app as if it were an old-style GUI app on a PC: your program has full and direct control over the UI. For example, imagine you need to disable a button due to permissions. In GridWhale, you just check the permissions and set .disabled = true on the control. This automatically propagates the setting to the UI. And because the .disabled property is on the server, it stays disabled even if you hack the client. In contrast, with React or any framework-based UI, you need to write code in two places: on the server (at the API level) and on the client to show the proper UI. And if you're not careful, these two can get out of sync. Of course, GridWhale is just a different trade-off. It works great for traditional business apps, but would not be appropriate for low-latency video games (at least not yet).
• cies 2y ago
  My answer: Something not JS, or even TS. So it has to compile to JS or WASM or both. Rust is cool. Dioxus looks really promising. https://dioxuslabs.com/ https://dioxuslabs.com/ Elm is great. Actually quite mature in my experience. (Sure there are talks about the development model and release cadence, but still...) Same $LANG as on the backend, as many langs compile to JS and/or WASM nowadays. But then how do you feed the browser a DOM? You still need something: HTMX, or... React? And if you squint your eyes, isn't Elm also doing the DOM-feeding in a React-like manner? (I dont know for Dioxus). Possibly the idea of React is really good, just Elm has implemented nicer? (and provides a good story for how to structure the rest of the application: state-mgmt, API calling, etc.
  • peutetre 2y ago
    > Rust is cool. Dioxus looks really promising. And Leptos: https://www.leptos.dev/ https://www.leptos.dev/ And Sycamore: https://sycamore.dev/ https://sycamore.dev/ And Yew: https://yew.rs/ https://yew.rs/
• ekvintroj 2y ago
  Rails? SSR?
• socketcluster 2y ago
  I created a serverless platform and some generic Web Components which let me build highly maintainable applications (which update in realtime) very quickly. It's more versatile than just CRUD as it supports complex views and serverless querying capabilities including fast search with indexing. Unfortunately, it seems essentially impossible to get get traction in my country so I'm unsure what to do with it. I use it for my own projects. See https://saasufy.com/ https://saasufy.com/
• ChicagoDave 2y ago
  I'm not a front-end developer by any stretch (though I did do web apps in the beginning), and I have to say, using GenAI and describing a web app to Claude or ChatGPT gets amazing results. I'm inclined to think this is one of the areas that GenAI can massively reduce cost. Claude will even iterate wireframes (in React). As for performance, that's not going to ever be a framework problem. That's a deployment and scaling and architecture problem.
• kabes 2y ago
  Everytime I see a question like this, the answer is mobx.
• mythz 2y ago
  My preferred Technology for non-SSG Web Apps is Blazor + Vue [1]. Where Blazor's Enhanced Navigation still gives you SPA-like navigation without any heavy client state, no client-side routing, no client build tools, no large download bundles in SPAs, etc. Blazor static rendering provides a great UX for rendering static content, Streaming Rendering is great for pages that needing to dynamically update and any pages requiring client interactivity I just progressively enhance Blazor's static content with Vue - avoiding any npm node_modules dependencies or client build tools. [1] https://servicestack.net/posts/net8-best-blazor https://servicestack.net/posts/net8-best-blazor
• apatheticonion 2y ago
  In my travels I have found React to be, generally, a poor choice for most applications - particularly in projects that have contributions from many developers with varying levels of experience. While it _can_ be super fast, in practice, it requires quite advanced knowledge of React-isms to get it there. Those React-isms require more code with increasing complexity, combine that with contributions from developers that have varying levels of experience and you end up with spaghetti code. Consequently, I have yet to walk into a new role where the React code isn't a dumpster fire. In a way, React feels very much like writing raw C - it has a lot of power to be fast but most developers aren't as smart as you (joking, sarcasm) so unless you're the only contributor; you're better off using a higher level language with fewer footguns. Modern Angular, for instance, is amazingly ergonomic and the opinionated approach makes it difficult to drag the project too far down the unmaintainable rabbit hole. The compiler handles optimizations for you so you don't need to worry about render cycles or how a functional component loops around - making it friendly (in theory) to developers with varying levels of experience. These ergonomics fall apart when developers try to make Angular projects "React-y" with tools like ngrx but for me; the biggest downside is that you have no control over the tooling (test runner, TypeScript version, bundler, etc). That is the only reason I avoid it in personal projects. Svelte and Vue on the other hand suffer from similar problems in that they are fantastically ergonomic, but use custom file formats with bespoke compilers that are difficult to integrate with other established tools (TypeScript, linting, formatting, testing). One thing that saddens me is that toolmakers (specifically TypeScript) sleep on opportunities to have much better front end frameworks because they don't provide the capability to extend the LSP and transpiler. For instance the inclusion of Rust-like compiler macros in TypeScript could enable projects like Vue, Svelte and Angular to integrate directly into the language without the need for bespoke compilers and adapters to connect to tooling. That way, much like how TypeScript has a built in compiler for JSX, Vue could integrate their template compiler within TypeScript rather than using external tooling that targets .vue files - example: export const HelloComponent = { tag: 'app-hello', template: vue!(<div>Hello {{name}})</div>), data: () => ({ name: "World" }) } And Angular class AppComponent { static tag = 'app-component' static template = angular!(<div>Hello {{ name }}</div>) #[model] name = 'world' } Alternatively, the completion of wasm would enable the use of languages with the appropriate feature-set required to build maintainable, multi-threaded & performant web applications - but at this point that seems like a distant pipe dream. So ultimately, while React isn't really a great choice for web applications, it's attained a jquery-like status where it's not really good but the alternatives are worse so you kinda have to use it.
• indieofone 2y ago
  solidJS?
• sublinear 2y ago
  writing your own goddamn javascript and not being a failure nobody wants in this industry
• fud101 2y ago
  I wonder if the author would be interested in writing 'React the good parts' - i think some things are still good even if the whole is bad.
• indulona 2y ago
  It's the JavaScript, stupid. The world needs to move on already from this horrible thing into which we've invested gazillions of development hours and unfathomable amount of money. It's a non-deterministic crap that should have been replaced so freaking long time ago that we're now paying the price for being lazy and sticking with a bad thing instead of moving forward.
• TeaVMFan 2y ago
  If Java is your cup of tea, you might want to try Flavour. I did and now it's the only frontend framework I use. https://flavour.sourceforge.io/ https://flavour.sourceforge.io/ It lets you write your frontend and backend code in the same language, even sharing models and validation logic so refactorings work full stack. You get strong typing and a rich SPA framework that includes routing, templates, and easy server calls. There's a book ( https://frequal.com/Flavour/book.html https://frequal.com/Flavour/book.html ) and a Java SwingSet-like app with live demos and source code called Tea Sampler ( https://frequal.com/tea-sampler/ https://frequal.com/tea-sampler/ ).
  • hasanhaja 2y ago
    How do you think it compares to Vaadin?
• tristan123456 2y ago
  What a load of dung.
• robertclaus 2y ago
  Once you get to the examples of different types of webpages, the author basically admits React (and SPAs in general) is likely appropriate for a bunch of application types. At that point the argument seems to boil down to "use a CMS and a simple frontend if user sessions are simple enough".
• slmjkdbtl 2y ago
  > Frameworkism isn't delivering. The answer isn't a different tool, it's the courage to do engineering. While frameworkism has bad sides, React (hooks) is bad in very unique and particular ways, sometimes switching a different tool is the answer.
• thecodrr 2y ago
  React is not slow. React is not "big". React is not the reason your website is slow. Any engineer who thinks that its React that is causing the slow renders and replacing it with X is deluded. Yes, there are ways to make slow React web apps. But there are also ways to make fast React web apps. It just requires effort and a little bit of foresight.
• jwblackwell 2y ago
  Totally agree. React and Vue are overkill and bloated, and actually lead to a worse experience a lot of the time e.g. users starting at spinning loaders with broken browser functionality (like back buton) A hybrid approach of server-side views with a simple lib like AlpineJS or HTMX for dynamic bits is far better in most cases. The initial page load is blazing fast because the server does the work. Then, for things like filtering or updating lists, you use the lightweight library for smooth, efficient updates. You get the best of both worlds—a super-fast initial experience and the ability to add dynamic features without the React baggage (and often-neglected backend).
  • 7sigma 2y ago
    I've been using Inertia.js with laravel and Vue and its been great, no need to write an API layer. You get the simplicity of writing server rendered with the interactivity of an SPA
    • 0xblinq 2y ago
      Same. Using it at work (although with React/Rails) and it works great. Best of both worlds with minimal drawbacks.
  • globular-toast 2y ago
    I've generally agreed with this but found the UI (ie. HTML) story on the backend is utter shite. Namely it's usually been handled by templates which inevitably lead to ridiculously inconsistent UIs with so much redundancy. In contrast something like JSX is really good and makes building small components for reuse natural. Fortunately there has been some change in this area. FastHTML is a batteries-included library for Python and there are numerous standalone HTML generation libraries that can be used with other frameworks like Django, e.g. htpy, htmy etc. I've been using alpine on a static site and it's really quite impressive just how much of "the stuff you probably want js for" it covers. So much so that you can pretty much say "if you can't do it in alpine, maybe we shouldn't do it at all".
    • jwblackwell 2y ago
• branko_d 2y ago
  It sounds like the author is complaining more about SPAs than the React itself. Indeed, if your needs are more static, a SPA is probably not a good solution. But if you really do need a SPA, React is a sensible choice and can perform well assuming good engineering.
  • grey-area 2y ago
    Nobody needs an SPA, it’s a stylistic choice, not a need.
    • branko_d 2y ago
      Ugh, that's just the fundamentalistic, non-engineering approach that we need less of. Everything is a trade-off, and SPAs offer a trade-off that is right for some cases and wrong for others.
      • grey-area 2y ago
        I disagree that SPAs are the only solution to some problems. This is an orthodoxy which people buy into but there are always a few different approaches possible. What do SPAs actually offer which is unique? There are multiple possible solutions to most problems, including gmail or google maps for example. Just because you want to load code and data dynamically doesn’t mean you need to buy into SPAs (the followers of which I’d argue are far more fundamentalist in insisting you can only use SPAs).
        • branko_d 2y ago
          > I disagree that SPAs are the only solution to some problems. I disagree with that too. Did I ever say otherwise? I do believe, however, that there are problems for which a SPA offers the best trade-off. Not the only solution, but the best trade-off. > This is an orthodoxy which people buy into but there are always a few different approaches possible. Like the orthodoxy that "nobody needs an SPA"? > What do SPAs actually offer which is unique? Interactivity. Good luck keeping your focus or scroll position while reloading a page. If done carefully, performance can also be on that list, though I agree it is often not done carefully. > Just because you want to load code and data dynamically doesn’t mean you need to buy into SPAs Agreed. Though you can load both code and data dynamically from a SPA, if you need. Perhaps our definitions of a "SPA" differ? SPA is when you don't do reloads, hence "single page". But there are many ways to do that, some of them involving React.
• grey-area 2y ago
  Having seen some large react codebases I’d agree wholeheartedly with this article. React solves problems we don’t have any more (eg IE), badly, at the cost of poor performance, lock-in and a host of other problems that other solutions just don’t have. It means downloading MBs of javascript just to render a simple page. It encourages multiple loads of massive json payloads for bits of the page which are then translated into html; this is a huge complexity and network tax for no gain. It encourages constant re-rendering of page components. It encourages mixing code and layout, making it incredibly easy for junior developers to make a terrible mess. It encourages splitting web pages into thousands of components with poorly defined boundaries and putting lots of logic on the front end - this is disastrous for productivity and clarity when the project is of any size. It has a bunch of legacy bits (double rendering, useEffect, useMemo, shadow dom etc) which just aren’t required and are often solutions to problems react itself created. As to a prescription for what to use instead of react - anything else which is not ‘modern javascript’ would be a good place to start. Start with server side rendering and stateless web pages, add interactivity and dynamic loading as required.
  • alexanderchr 2y ago
    React was never intended to solve browser inconsistencies. Of course it developed hand-in-hand with the tools that solved those (transpilers, polyfills, bundlers), but that was not the main reason it was invented or became popular. The original motivation was to describe UI as a function of state. It sounds trivial, because it is when server rendering, but once you start sprinkling enough interactivity it can get messy. It's of course not the solution to everything, but above a certain level of complexity I really think you should let someone else handle the problem of syncing state with UI, and JS on its own will never do that for you.
    • grey-area 2y ago
      Yes that’s a good point sorry I just gave one e.g. from the article of IE event handling. Re the original purpose of react being syncing state, I’m really not sure this small problem is actually worth the trade-offs of massive complexity and lock-in, nor that react is a good solution for it (double renders, persistent rendering bugs, use state, hooks etc). It’s not something important to lots of apps and there are loads of other options from simple polling to web sockets to reloads, this can be done in a far simpler way without react. Also the use cases where this is central are really quite small.
• hlandau 2y ago
  Most webapps would be dramatically improved if the developers were banned from using any JavaScript on the client side in the first version, and allowed only to apply progressive enhancements from there.
• kajaktum 2y ago
  Creating an interactive UI with rapid development is a fundamentally difficult problem. Its no wonder that people spend billions on creating UI (collectively) and I haven't any good ones yet (performant, interactive, efficient). Why not just drop the requirement altogether? All I want is an internet of links, images and texts? Whats so wrong with Facebook that looks like this website? Just a bunch of links and texts. I don't give a shit if the button is a square or round. Why do you get to decide what is "best" for me anyway? Let the web be the web and the user decide how to present them.
• palmfacehn 2y ago
  This keeps coming up here: "It isn't React, just those specific implementations" Perhaps it is React, JS ecosystems and overbloated frameworks generally. These tools provide abundant footguns.
• nathias 2y ago
  ah yes, the guy that does the 'real' engineering, and then I'm hired to rewrite that 'engineering' to a normal modern framework
• prmph 2y ago
  I disagree a bit with the article's implication that putting more code on the client leads to a loss of control. With web programming, there is no way to have full control. Even if you avoid JavaScript on the client and concentrate all the code on the server, the server output still has to be rendered by the browser, and you don't control that. You have no control over what browser is being used, what settings have been applied to the browser, the level of resources available on the client machine, what other programs are running, and so on. I've come to the realization that unless you're OK with some very clunky front-end, there's just no way to avoid quite a bit of JavaScript on the client. Once you need to write a non-trivial UI heavy web app, you quickly realize that avoiding JavaScript on the client is a non-starter, as cool as that would have been. The issues involve a lack of standardized sophistication of the web technologies, like HTML controls being clunky, very unsophisticated and hard to configure/style properly, CSS not being properly composable, HTML forms not implementing the full set of HTTP verbs, etc... To me these are fundamental problems with the web architecture that need solving. Revamping the web architecture to properly support a sophisticated negotiation of control between the developer, the browser, and the end-user would greatly reduce, if not almost eliminate, all the thorny problems that declarative UI frameworks and libraries bring into focus.
  • moffkalast 2y ago
    W3C and WHATWG need to take a long hard look at what functionality is common to most frameworks that's missing from the default HTML/CSS spec and add it. It's literally their job and the existence of such a mass amount of frameworks that implement mostly the same things in slightly different ways means they're not doing it well. There's bloat and then there's sending the exact same thing over the network quadrillions of times at every page load because it's not standard and everyone needs it.
• deleted 2y ago
  [deleted]
• andrewingram 2y ago
  React does have a bunch of legacy baggage holding it back, definitely from a performance angle. But I think a major part of the issue is just the fact that React _is_ so popular, with that comes the inevitability that the majority of people using it aren’t all that experienced. It’s relatively easy to build a React app that performs pretty well if you prioritise performance, though not as easy as something say Svelte or Solid, but getting performance to be prioritised and rewarded is the real battle —- as mentioned in the article itself.
• whs 2y ago
  I'm trying to build server rendered websites, but I find React (or other SPA-API systems) hard to resist: - Form is hard. Doing it in backend make it even harder when the form is complicated. For example, a form with tab needs JS to operate and you need to signal the JS which tab the error is. - If you're using backend form framework, you don't have control over the HTML unless you learn the hook points of it (do you add attribute in code, or in template? Where is the default template to override?) Compared to frontend framework where you can paste the CSS framework's example HTML. - I wanted to build a new user wizard, which should be easy with a frontend framework as you can easily store incomplete state in memory. If not using JavaScript one would have to store the state in the untyped session variables, add hooks cluttering the HTML template, etc. - Progressive enhancement is easier when you have to write the code only once. If there's a table and you want to refresh without refreshing the page, in React you just call the data fetcher again. In HTMX your backend needs to have a "full render" endpoint and a "table only" render endpoint. If you're using jQuery you might as well write the table loop twice in the backend template engine and in jQuery. - I haven't see any good backend framework (be it Django, Laravel, Symfony, Gin) that has similar server-rendered frontend component like React. Many frameworks believed that logic should be precomputed in the view layer and the template engine should not be turing-complete. I was thinking about moving to SSR-rendered SPA, but I know of no Next.js-style library for any frontend framework that actually allow form submission without JavaScript AND progressive enhancement with JavaScript using the same code.
  • pier25 2y ago
    > a form with tab needs JS to operate Yes, this use case is better solved client-side but even in an SSR app you can always use rich widgets/web components in React, Preact, Vue, Svelte, etc. > I wanted to build a new user wizard Use some JS component(s) or web component(s) as I pointed out earlier. > In HTMX your backend needs to have a "full render" endpoint and a "table only" render endpoint See fragments: https://htmx.org/essays/template-fragments/ https://htmx.org/essays/template-fragments/ > I haven't see any good backend framework that has similar server-rendered frontend component like React Plenty of backend solutions give you SSR components that are composable and where you can colocate template with backend logic. See Razor pages in dotnet or Astro. > but I know of no Next.js-style library for any frontend framework that actually allow form submission without JavaScript AND progressive enhancement with JavaScript using the same code I'm 99% certain SvelteKit and Remix allow you to do this.
• cbeach 2y ago
  I've spent years slowly migrating a personal project from PHP to Scala/React, and I'm devastated if React is out-of-date already. The web tech treadmill is relentless! Seems the author recommended HTMX as an alternative in a couple of scenarios including my own use case (https://caption.me https://caption.me). I checked out HTMX. The canonical example on the homepage (https://htmx.org/ https://htmx.org/) was a button where a click calls the server and the response contains HTML to replace the outerHTML of the button. I must be missing something here. Is HTMX really suggesting muddying the back-end code with front end code? So, any changes to front- or back-end would have to be carefully managed to avoid breaking the other side? Feels like PHP all over again!
  • recursivedoubts 2y ago
    yes, htmx is very much suggesting returning HTML rather than JSON from the server, and collapsing a layer of complexity in the process. this has turned out very well for some applications, dramatically lowering complexity: https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/ looking at caption.me, I see nothing that couldn't be effectively addressed using this hypermedia approach, and I suspect it would simplify the application. You don't worry about "breaking the other side" because there is no other side: everything is hypermedia, in the original mode of the web I don't think PHP has much to do with htmx: you can use PHP if you'd like on the server side, but you can use whatever server side technology you'd like to produce HTML. People are using Go, Java, Kotlin, Scala, Rust, Python, Lisp, etc. with it and it works fine. It's a generalization of hypermedia controls[1] (anchors and forms) and, like anchors and forms, has no opinion on what the server side looks like. One piece of good news regarding htmx is that the API is not going to change dramatically in perpetuity, so there is no treadmill to keep up with. [1] - https://dl.acm.org/doi/pdf/10.1145/3648188.3675127 https://dl.acm.org/doi/pdf/10.1145/3648188.3675127
    • cbeach 2y ago
      As I understand it, HTMX front-end components aren't re-usable in the same way as ReactJS components. HTMX components are 1:1 coupled with back-end code. So if I try to build a complex UI with nested structures, I'm going to have to build a parallel structure in back end. The back end will have to manage all state, so there will be round trips for everything and things in server side memory that could be managed easily on the client side. That would affect the scalability and maintainability. I'm not getting a sense of why HTMX would be better than a pure client/server approach. I have no attachment to "hypermedia," or any other concepts penned in the 1960s!