10 ms·

JavaScript-heavy approaches are not compatible with long-term performance goals

178 points by luu 8mo ago

piyh 8mo ago
Only a single passing mention of web components?
- vaylian 8mo ago
  > You can use isolated JS scripts, or other approaches like progressively-enhanced web components How would one use "progressively enchanced" web components? Maybe I misunderstand the intention behind this statement, but web components are either supported or not. There doesn't seem to be some kind of progression.
  - DrScientist 8mo ago
    Given custom elements are pretty widely supported by browsers now, I assume you are referring to js being turned off. In terms of designing for that situation - you can follow a pattern where your custom element wraps ( <custom-ele><stdelement></></> ) the element you want to enhance. If js is turned off, then the custom element defaults to rendering it's contents.... https://simonwillison.net/2022/Apr/21/web-components-as-progressive-enhancement/ https://simonwillison.net/2022/Apr/21/web-components-as-prog...
    - tzebco 8mo ago
      Yep, that's the ideal approach for decent browsers. A curious caveat is that IE 8 and below will interpret that example HTML as <custom-ele></><stdelement></> (ie. as siblings, not parent and child) and therefore not apply any component-scoped styles. Not ideal. Of course nobody uses those browsers anymore, the same caveat applies to non-custom HTML5 elements, and the bad behavior has long been preventable with JavaScript [0]. But anyone (else) with an extreme backwards compatibility mindset might consider if they could instead bootstrap from <div class="custom-ele"><stdelement></></> and (if needed and in window) a coordinating MutationObserver. [0] https://web.archive.org/web/20091031083341/http://diveintohtml5.org/semantics.html#unknown-elements https://web.archive.org/web/20091031083341/http://diveintoht...
kylecazar 8mo ago
"Now’s a good time to figure out whether your client-side application should have a server-side aspect to it, to speed up initial renders." My how the tables have turned!
- verdverm 8mo ago
  everything old is new again
slopinthebag 8mo ago
> I’ll focus on React and Redux in some of my examples since that is what I have the most experience with, but much of this applies to other frameworks and to JS-heavy approaches in general. That's not a fair assumption. Frameworks like Svelte, Solid, Vue etc have smaller bundle sizes and rendering speeds that approach the baseline vanilla-js cost. I'm all for criticising Javascript, but moving everything to the server isn't a real solution either. Instead of slow React renders (50ms?), every interaction is a client-server round trip. The user pays the cost of the paradigm on each interaction instead of upfront with an initial JS payload. Etc.
- mosdl 8mo ago
  Plus Redux is horrible for performance, slows things down and overcomplicates everything.
  - Rohansi 8mo ago
    I never understood why state management is overcomplicated in React. For some reason most people use something like Redux which has a very unintuitive API. There are other state management packages available that are so much easier to use and understand, like MobX. https://github.com/mobxjs/mobx https://github.com/mobxjs/mobx
    - littlecranky67 8mo ago
      To shine a light on the mystery, before React had (a) hooks and (b) a stable context API and (c) tanstack-query/react-query or GraphQL - state handling WAS a mess. Thats when redux/mobx etc. made more sense. Try to build something with a pre-2019 version of react and you will understand the need.
    - slopinthebag 8mo ago
      Redux is an implementation of the elm architecture (Tea) which is used for UI state in a lot of languages and frameworks. JS/TS is just not a very ergonomic language for it so it becomes painful quickly. https://guide.elm-lang.org/architecture/ https://guide.elm-lang.org/architecture/
tommek4077 8mo ago
In other news: water is wet. I genuinely don't understand how anyone is still pretending otherwise. Server-side rendering is so much easier to deliver in a performant way, yet it feels like it's being increasingly forgotten — or worse, actively dismissed as outdated. Out of convenience, more and more developers keep pushing logic and rendering onto the client, as if the browser were an infinitely capable runtime. The result is exactly what this article describes: bloated bundles, fragile performance, and an endless cycle of optimization that never quite sticks.
- holoduke 8mo ago
  Pure client side rendering is the only way to get max speed with lowest latency possible. With ssr you always have bigger payloads or double network rounds.
  - k33n 8mo ago
    That’s a laughable claim. SSR is objectively faster, since the client does nearly zero work other than downloading some assets. If the responses are pre-computed and sitting in server memory waiting for a request to come along, no client side rendering technique can possibly beat that.
    - wiseowise 8mo ago
      > objectively faster > provides zero evidence
      - k33n 8mo ago
        I don’t really need to provide “evidence”. I told you why SSR is faster and tbh idc if your time to paint is trash.
      - naasking 8mo ago
        Some pretty compelling evidence is history: we had dynamic and interactive web pages 20 years ago that were faster on computers that were an order of magnitude slower.
prewett 8mo ago
A cogent article. But I think the biggest problem is that the DOM was built for documents, not apps. We know how to build a performant UI architecture: Qt, Java/Swing, Cocoa all have pretty similar architectures and they all ran fine on much poorer hardware than a modern browser on an M1. But unless you use WebAssembly, you can't actually use them on the browser. When the industry shoehorns something into a tool designed for something else, yeah, performance suffers and you get a lot of framework churn with people trying to figure out how to elegantly cut steaks with spoons.
- nine_k 8mo ago
  It very possible to make lightning-fast React web UIs. DOM sucks, but modern computers are insanely fast, and browsers, insanely optimized. It is also very possible to make sluggish-feeling Qt or Swing applications; I've seen a number. It mostly takes some thinking about immediate reaction, about "negligibly short" operations introducing non-negligible, noticeable delays. Anything not related to rendering should be made async, and even that should be made as fast as possible. This is to say nothing of avoiding reflows, repeated redraws, etc. In short, sloppy GUI code feels sluggish, no matter what tools you use.
  - samrus 8mo ago
    > but modern computers are insanely fast, and browsers, insanely optimized I think these facts have been used as excuses to shit up the app layer with slow mal-optimized js code. An example of a recent high performance app is figma, which blows normal js only apps out of the water. And it does so by using c++ wasm/webGPU for its more domanding parts, which is most of it I think we have to let go of the "just get more ram" approach and start optimizing webapp code like figma does
    - nine_k 8mo ago
      Exactly my point: if we're not sloppy, we can achieve amazing performance.
    - Capricorn2481 8mo ago
deleted 8mo ago
[deleted]
robertoandred 8mo ago
Eh, this argument falls apart for many reasons: - His main example of bloated client-side dependencies is moment.js, which has been deprecated for five years in favor of smaller libraries and native APIs, and whose principal functionality (the manipulation and display of the user's date/time) isn't possible on the server anyway. - There's an underlying assumption that server-side code is inherently good, performant, and well crafted. There are footguns in every single language and framework and library ever (he works for WordPress, he should know). - He's right to point out the pain of React memoization, but the Compiler now does this for you and better than you ever could manually - Larger bundle sizes are unfortunate, but they're not the main cause of performance issues. That'd be images and video sizes, especially if poorly optimized, which easily and immediately dwarf bundle downloads; and slow database queries, which affect server-side code just as much as browser-side code.
- afavour 8mo ago
  > There's an underlying assumption that server-side code is inherently good, performant, and well crafted To me it’s an assumption that server side code is going to be running on a server. Which is a known quantity and can be profiled to the nth degree. It’s extremely difficult to profile every possible device your site will run on, which is crucial with low powered mobile devices. > Larger bundle sizes are unfortunate, but they're not the main cause of performance issues. That'd be images and video sizes Not really, no. Large bundle sizes prevent the initialisation of the app, which means the user can’t do anything. By comparison images and videos download asynchronously and get processed on a separate thread. JS bundles also need to be parsed after being downloaded, if you pair a crappy Android phone with an 5G connection the parsing can literally take longer than the download.
- youngtaff 8mo ago
  > Larger bundle sizes are unfortunate, but they're not the main cause of performance issues. That'd be images and video sizes, especially if poorly optimized, which easily and immediately dwarf bundle downloads; and slow database queries, which affect server-side code just as much as browser-side code. In network terms JS tends to be downloaded at a higher priority than both images and video so has a larger impact on content appearing JS is also the primary main thread blocker for most apps / pages… profile any NextJS app and you’ll see what a horrendous impact NextJS has on the main thread and the visitor’s experience
exabrial 8mo ago
I’m still baffled why this language is the universal browser standard. There should be hundreds competing.
- phantomathkg 8mo ago
  I'm still baffled why you don't see JavaScript is fast, but how page rendered is the issue.
  - exabrial 8mo ago
    I’m baffled you don’t believe in benchmarks, but, uh.
    - worthless-trash 8mo ago
      life finds a way ?
    - phantomathkg 8mo ago
      Speaking about benchmark. Node vs Lua shows Node faster than Lua. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/node-lua.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Node vs C, only 4 to 5 times slower. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/node-gcc.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Looking at its root, it is not too bad as a JIT compiled language.
      - xigoi 8mo ago
        “Only” 5 times slower? Imagine if every website that takes 10 seconds to load instead took 2 seconds…
        curtisblaine 8mo ago
        You know that CPU-bound performance would take a really small fragment of those straw man 10 seconds loading a page, right?
wackget 8mo ago
I am so grateful to the author for writing this article. For years I've been fighting a series of small battles with my peers who seem hell-bent on "upgrading" our e-commerce websites by rewriting them in React or another modern framework. I've held the line, firm in my belief that there is truly no compelling reason for a shopping website to be turned into an SPA. It's been difficult at times. The hype of new and shiny tools is real. Like the article mentions, a lot of devs don't even know that there is another way to build things for the web. They don't understand that it's not normal to push megabytes of JavaScript to users' browsers, or that displaying some text on a page doesn't have to start with `<React><App/></React>`. That's terrifying to me. Articles like this give me hope that no, I'm not losing my mind. Once the current framework fads eventually die out - as they always do - the core web technologies will remain.
- wmf 8mo ago
  Let them have React and SSR everything? Didn't the NYT do this?
- hinkley 8mo ago
  I think shopping gets this in spades too because not all shopping sites are meant to be particularly sticky. It's one thing to browse the catalog at my leisure on gigabit networking, a 5k display and 16 CPU cores. It's another thing when I'm standing in Macy's or Home Depot and they don't quite have the thing I thought they have and I'm on my phone trying to figure out if I can drive half a mile to your store and get it. If you want to poach that sale your site better be fast, rather than sticky.
- nchmy 8mo ago
  he links to infrequently.org a few times in the article. You should read every article there - its a revelation. Then check out Datastar
gatane 8mo ago
Github was usable and fast, now it is slow. Guess what changed...
- lenkite 8mo ago
  It was re-written in React and performance was annihilated. The React Virus annexed another victim and we have one more zombie web-site.
  - epolanski 8mo ago
    Yeah, but some project or program manager sure got a raise for delivering this nonsense "update". That was 100% a project sold to upper management as a benefit and modernization.
- ahartmetz 8mo ago
  It's crazy slow. But it's also a closed source, Microsoft platform for Open Source, so it belongs in the trash anyway.
- gloosx 8mo ago
  Acquisitionbombed by Microsoft! Instead of usability and performance it has AI now!
carshodev 8mo ago
This title is very misleading, it should be "Why React is not compatible with long-term performance goals" And I do agree generally. React uses an outdated rendering method that has now been surpassed by many better frameworks. Svelte/Sveltekit, Vue, and Qwik are the best examples. People relying on bloated React packages is obviously not great but that is nothing to do with javascript itself. The JS engines are all relatively fast now. And the document model of the current web provides major accessibility to both humans and search tools like SEO and GEO. JS is not my favorite language. I would rather the web was based on a statically typed language that had better error handling practices like Go. But this will most likely not happen any time soon as it would require every level of the ecosystem to adapt. Browsers, Frameworks, Developers etc. Google would have to take the lead and implement this in chrome then enough developers would have to build sites using it and force safari and firefox to comply. It just isn't feasible. If you want faster webapps just switch to sveltekit or vue or qwik. But often the ones choosing the framework for the project have not written much code in years, they know react is as safe option and used by everyone else so they follow along, if it gets slow its a "bug" causing it as they built apps that were "good enough" before using it.
- hinkley 8mo ago
  The reason I'm a backend dev at the moment is that I looked at the React model and decided I didn't want anything to do with this insanity. I've been appalled by how long and how broadly the mass hysteria lasted.
  - DanHulton 8mo ago
    I managed to avoid learning React long enough to become a manager. I'm not saying I won't ever end up in engineering and won't ever have to learn it, but at least right now, it feels kinda like I got away with something.
  - carshodev 8mo ago
    And what's crazy is with ai the percentage of apps developed using react in comparison to all other frameworks has INCREASED over the last 3 years. It is truly mass hysteria, I would say that 95% of developers, project managers, and CTOs do not truly understand how these systems work under the hood, or at the very least are too scared and comfortable to try other systems. They just repeat the same things they hear and tell each other "react has a big ecosystem" "react is industry standard" "everyone uses react" "react was developed by facebook" "we will use react" "Developers only know react, how could we hire for a different framework?" In my mind its clear that the alternatives are massively better. When i visit certain websites I often get a random tingle that it uses svelte because its way faster and has better loading and navigation than other sites and when i check the devtools I'm almost always correct. I also get the same feeling sometimes when I hit a laggy slow webapp and I open the devtools and clearly see its a nextjs app. A dev team could be trained on svelte or vue in literally 3 days, and so long as they actually understand how HTML, JS, and css work under the hood they would increase their speed massively. People just don't want to take the risk.
coolThingsFirst 8mo ago
Try this: https://mapjoy.app/ https://mapjoy.app/, username and pass johnsmith. All of JS with client side routing, blazing fast. React is utterly amazing.
smaddock 8mo ago
They mentioned React is missing timing information in the devtools profiler. This was actually added in React 19.2 which should be helpful for debugging. https://react.dev/blog/2025/10/01/react-19-2#performance-tracks https://react.dev/blog/2025/10/01/react-19-2#performance-tra...
umairnadeem123 8mo ago
[dead]
jongjong 8mo ago
I was never a big React fan myself. As someone who has used a lot of different JavaScript frameworks over many years, I can say confidently that it's not the best JS framework; especially nowadays due to bloat. Yet it's better than anything available in any other programming language, on any other platform in existence. Never bet against JavaScript. People have done this over and over and over again since it was invented. So many haters. It's like every junior dev was born a JavaScript hater and spends most of their career slowly working themselves to a state of 'tolerating JavaScript'. JS was designed to be future-proof and it kept improving over the years; what happened is it improved much faster than people were able to adjust their emotions about it... These people even preached the JS hate to a whole generation of juniors; some of whom never even experienced JavaScript first-hand. It's been cool to hate JavaScript since I can remember. JavaScript does have some bad parts, as does any other programming language, but the good parts of JS are better than anything else in existence. People keep trying to build abstractions on top (e.g. TypeScript) to try to distance people from JavaScript, but they keep coming back over and over again... And these people will never admit to themselves that maybe the reason they keep coming back to JavaScript is because it's pretty darn great. Not perfect, but great nonetheless. It's hilarious that now we have Web Assembly; meaning you can compile any language to run in the browser... But almost nobody is doing that. Do people realize how much work was required to bring Web Assembly to the browser? Everyone knows it exists, it's there for you to use, but nobody is using it! What does that say? Oh, it's because of the bundle size? Common! Look at React, React bundles are so bloated! But they are heavily used! The excuse that JavaScript's success is a result of its browser monopoly is gone! Enough is enough! The fact is; you probably love JavaScript but you're just too weak to admit it! I think the problem is that non-JS developers have got a big mouth and small hands...
- gorgolo 8mo ago
  Do people really hate JavaScript, or do they just hate the design choices and results that it seems to be correlated with? At the end of the day I’m using SaaS tools that are apparently written in React and I get astounded but how slow and heavy they are. If you are editing a page on our companies cloud-based wiki, I’ve seen my chrome RAM balloon from 3GB to 16G. A mistake was made somewhere, that I know.
- 8mo ago
kittbuilds 8mo ago
[dead]
torginus 8mo ago
My 2 cents: I am not an experienced React dev, but the React compiler came out recently with React 19, which is supposed to do the same thing as Svelte's - eliminate unnecessary DOM modifications by explicitly tracking which components rely on what state - thus making useMemo() unnecessary. Since the article still references useMemo(), I wonder how up-to-date the rest of the article is.
- littlecranky67 8mo ago
  React has always been tracking what component relies on what state, independent of the compiler. That is one of the reason the rule-of-hook has to exist - it tracks if a component calls useState() and thus knows the according setState function that manipulates that particular state. Idk why people claim React is bloat, especially since you can switch to Preact (4kb) most of the time without changes if filesize is an issue for you.
  - Capricorn2481 8mo ago
    Because people make shitty React apps and people think React is slow because of it. It's definitely not slow here. It's within 20% of Svelte. That's not nothing, but it's not the huge monster people claim it is https://krausest.github.io/js-framework-benchmark/2025/table_chrome_143.0.7499.41.html https://krausest.github.io/js-framework-benchmark/2025/table...
    - epolanski 8mo ago
      When 99% of React apps (websites tbh, with very few needs for complex reactivity...) including those built by multi billion/trillion $ companies, struggle to produce non-bloated, non-slow, accessible websites, you know that the library is simply too complex to tame. Of course React can be performant, but still, you're getting a PhD in its internals and hooks to get what you have in vue/nuxt/svelte whatever out of the box.
      - littlecranky67 8mo ago
tpoacher 8mo ago
As an aside, I like their use of blockquotes+details/summary blocks for inserting "afterthoughts/addendums". It's a nice touch, and it works pretty well. Partly because, as a design choice, it forces you to add the afterthought between paragraphs, so the interruption in reading flow is minimal.
Devasta 8mo ago
Why would performance be a goal? If a native desktop app crashes, your users will gnash their teeth and curse your name. A web app? They shrug and refresh the page. They have been trained to do this for decades now, why would anyone believe this isn't intended behavior? No one has a reasonable expectation of quality when it comes to the web.
- zahlman 8mo ago
  > No one has a reasonable expectation of quality when it comes to the web. And that's exactly why I want native desktop apps to make a resurgence.
flohofwoe 8mo ago
This seems to be more about React than Javascript (or indirectly about the DOM). React sitting on top a browser-style DOM would be slow in any language, while Javascript itself can be surprisingly fast, especially when sticking to the right subset. It "only" needs a big and complex JS engine to get to that kind of performance.
cyberax 8mo ago
Our webapp is nearly instant, and it's built on raw React with some sprinkling of Tanstack (their Local Collection DB is a masterpiece). And our stack is intentionally client-heavy. We proactively synchronize all the relevant data and keep it in IndexedDB, with cross-tab coordination. The server is used only for mutating operations and for some actions that necessarily require server-side logic. The issue with dependencies and the package size if valid, but it's also really not a big deal for performance unless you go WAAAY overboard. Or use crappy dependencies (Clerk, I'm looking at you, 2.5Mb for an auth library!?!?). As for hydration, I found that it often slows down things. It's a valid approach when you're doing query-based apps, but when you have all the data locally, it just makes little sense. It also adds a ton of complexity, because now your code has to automagically run in multiple environments. I don't think it can really ever work reliably and safely.
jakub_g 8mo ago
To me, the main problem is that inevitably, any SPA with dozens of contributors will grow into a multi-megabyte-bundle mess. Preventing it it's extremely hard, because the typical way of developing code is to write a ton of code, add a ton of dependencies, and let the bundler figure it out. Visualizing the entire codebase in terms of "what imports what" is impossible with tens of thousands of files. Even when you do splitting via async `import()`, all you need is one PR that imports something in a bad way and it bloats the bundle by hundreds of kilobytes or megabytes, because something that was magically outsourced to an async bundle via the bundler suddenly becomes mandatory in the main bundle via a static import crossing the boundary. The OP mentions it here: > It’s often much easier to add things on a top-level component’s context and reuse them throughout the app, than it is to add them only where needed. But doing this means you’re paying the cost before (and whether) you need it. > It’s much simpler to add something as a synchronous top-level import and force it to be present on every code path, than it is to load it conditionally and deal with the resulting asynchronicity. > Setting up a bundler to produce one monolithic bundle is trivial, whereas splitting things up per route with shared bundles for the common bits often involves understanding and writing some complex configuration. You can prevent that by having strong mandatory budgets on every PR, which checks that the bundle size did not grow by more than X kB. But even then, the accumulation of 100s/1000s of PRs each adding 1KB, bloats the bundle enough to become noticeable eventually. Perf work is thankless work, and having one perf team trying to keep things at bay while there are dozens of teams shipping features at a fast pace is not gonna cut it.
- g947o 8mo ago
  Exactly. To avoid dependency explosion, you need at least one of 1) most libraries built internally 2) great discipline across teams 3) significant performance investment/mandate/enforcement (which likely comes from business requirement eg page load time). I have rarely seen that in my limited experience.
- pas 8mo ago
  It makes sense to have separate entry points for landing pages, no need for fancy providers and heavy imports. In practice people are more than willing to wait for an SPA to load if it works well (figma, gmail/gdocs, discord's browser version used to be pretty good too, and then of course there are the horrible counter-examples AWS/GCP control panels, and so on).
shevy-java 8mo ago
Wasn't WebAssembly going to change all this? Somehow that does not really have been achieved.
- mcraiha 8mo ago
  DOM access is not in Wasm.
azangru 8mo ago
I think digressions about React dilute the message. Ok, we get it, react bad; but what is the actionable message here? What are the robust alternatives? There is a section on how changes to react (the introduction of hooks and of the concurrent mode) necessitated significant code changes almost amounting to rewrites; but which alternatives, other than vanilla web platform, can promise long-term stability? Which alternatives are better suited for which kinds of applications (roughly, an e-commerce site vs excalidraw)?
- nchmy 8mo ago
  https://infrequently.org/2024/11/if-not-react-then-what/ https://infrequently.org/2024/11/if-not-react-then-what/
LAC-Tech 8mo ago
Wonderful article. I do maintenance programming, and many of the problems you mention with typical react apps are also code maintenance nightmares. Managing a large number of fast moving third party dependencies will destroy your developer budget, but devs cant see it because they're "Best Practices"
Meneth 8mo ago
JavaScript isn't good for performance? Could've told you that 20 years ago.
catchcatchcatch 8mo ago
[dead]
jadbox 8mo ago
I've gone all SSR (server-side render) with JSX using Astro or Elysia. If I need frontend logic, I just sprinkle in a little Htmx or roll my own inline js function. It makes debugging 1000% easier and the pagerank scores are usually amazing out of the box.
rorylaitila 8mo ago
I've skipped the whole 'modern' web stack. I've stayed SSR first, hrefs/forms/url as only routing primitives, progressive enhancement, vanillajs-islands only where absolutely necessary. Its great. Apps never randomly break. No build hell. UX easy to debug (just look at the HTML). No random performance degradations. No client has ever said it feels dated. Just finished my first app-like PWA, also SSR. Getting great compliments on the UI and slick interactions using just native browser transitions. The vanilla web stack gets better and better! Honestly don't know what people think they are gaining with a heavy frontend.
- exceptione 8mo ago
  > Honestly don't know what people think they are gaining with a heavy frontend. True, but (I repeat myself here), it depends on what kind of website we are talking about. For instance, a data-heavy SPA that workers use the whole day (like a CRM) is at least perceptually faster and more user friendly compared to the same thing but with traditional whole page reloads.
  - codr7 8mo ago
    There's plenty of middle ground here, you don't need fancy frameworks to do partial reloads.
    - exceptione 8mo ago
      I am open for suggestions, but anything wanting to give a desktop like experience is going to be complex. Like the user clicks a button, now widget a1 » a1.3 » a1.3.2 » a1.3.2.2 should be in an "open state", while widget b1 » b1.2 » b1.2.1 needs to be in "disabled state" and widget c3 » c4 » c5 shows a status message.
      - codr7 8mo ago
        Sure, and the further you go in that direction, the more you're building a traditional desktop GUI experience, which was always a bad fit for the web. So yes, if that's really what you want to do, React or similar is probably what you want. If.
sudodevnull 8mo ago
This is well known. You can have full reactivity without being JS heavy. https://www.youtube.com/watch?v=8W6Lr1hRgXo https://www.youtube.com/watch?v=8W6Lr1hRgXo is a perfect example
allreduce 8mo ago
For websites I use regularly, I can identify those which render server side because I trust that when they load on a slow connection my state is still there. When I see a loading icon on heavy client side JS "apps" I anticipate something breaking and me having to reload and re-enter whatever I was working on.
monster_truck 8mo ago
This seems like it's more about React. Javascript is fine. React is garbage
rglover 8mo ago
Interop has entered the chat.
prinny_ 8mo ago
People in this thread hating on React seem to miss the crucial point that 2016 React was a godsend compared to just about every other option available. Vue only picked up steam quite later as React became more and more bloated or had its development forced by Vercel down a certain road. Angular was THE framework to avoid working on and people hated having to define multiple files for a simple component. The timing for React was just right back in the day. Given how FEs are re-written every 7-10 years there is ample room for other frameworks to knock React off its throne, but before asking "but why not X" you also have to consider that organizations by now have almost a decade of experience building React apps and this plays a major role when deciding on which UI framework to rely on.
dsiegel2275 8mo ago
Lost me at "React is a Framework" assertion. The key difference between a "framework" and a "library" is the inversion of control that exists in a framework. React is a library - your app still maintains control of application state and drives the main workings of the application. It is just simply using the React library to render that application state.
- gloosx 8mo ago
  Fully agree, Inversion of Control is not something which alone defines something as a framework. When defining it along the architectural axis React is architecturally unopinionated thus is has library-level scope, but framework-like control semantics. If framework = anything that uses inversion of control, then a lot of things suddenly become frameworks, including things nobody calls frameworks. One can call it a "rendering framework" but calling it a "web-application framework" is not factually correct.
exceptione 8mo ago
I am the first to admit that SSR worked fine since PHP. But two points I like to make 1) choose boring technology; 2) it is the library, stupid First question should be: what type of web application are we talking about? If your blog does not render or your e-commerce site stops working without javascript, shame on you indeed. If we are talking about SPA's, aka those replacing traditional desktop applications, and you want to throw out React, then we have something to discuss. Because, how are you going to replace MUI/MUI(x)? I keep hearing about the coolness of alternatives, and I am certain open to it, but in the end it needs to be not just better in some aspects or even fundamentals, while completely lacking in practical matters. A simple benchmark I keep going back to is to see if $hotness is able to replace [1], which shows you just one component of many in a cohesive system. I don't contend with the principles in the article, but I do with conclusions like "ripping out react would be the solution". 1. https://mui.com/x/react-data-grid/tree-data/ https://mui.com/x/react-data-grid/tree-data/
suralind 8mo ago
I’ve been very happy using SvelteKit for some side projects. At this point I wouldn’t label myself as frontend developer anymore, but when done right, it’s probably the closest thing to modern, performant and reactive that I know of. It also works really well if the JS just breaks.
fuzzfactor 8mo ago
Somebody noticed.
flatcoke 8mo ago
Agree with the general point, but the nuance matters. Static-first approaches like static exports solve most of this — you get the DX of a JS framework without shipping a runtime to the client. The problem isn't JavaScript itself, it's shipping too much of it.
- SauntSolaire 8mo ago
  Why do people bother creating new accounts just to post these generic AI comments? It's like people want to ruin HN as fast as (in)humanly possible.
Jgoauh 8mo ago
do you think using webassembly (.wasm) for non UI related code might help with client side performance for apps where server side work is less applicable ?
BrenBarn 8mo ago
I'm not a big JS fan, but to be fair this article seems more like "bloated JS frameworks have poor performance". And like, yeah. But you can use JS without using a bloated framework. It's funny though that the article is circling back to Web 2.0-era server-side stuff. It's an idea whose time has come!

178 points by luu 8mo ago

piyh 8mo ago

Only a single passing mention of web components?

vaylian 8mo ago
> You can use isolated JS scripts, or other approaches like progressively-enhanced web components How would one use "progressively enchanced" web components? Maybe I misunderstand the intention behind this statement, but web components are either supported or not. There doesn't seem to be some kind of progression.
- DrScientist 8mo ago
  Given custom elements are pretty widely supported by browsers now, I assume you are referring to js being turned off. In terms of designing for that situation - you can follow a pattern where your custom element wraps ( <custom-ele><stdelement></></> ) the element you want to enhance. If js is turned off, then the custom element defaults to rendering it's contents.... https://simonwillison.net/2022/Apr/21/web-components-as-progressive-enhancement/ https://simonwillison.net/2022/Apr/21/web-components-as-prog...
  - tzebco 8mo ago
    Yep, that's the ideal approach for decent browsers. A curious caveat is that IE 8 and below will interpret that example HTML as <custom-ele></><stdelement></> (ie. as siblings, not parent and child) and therefore not apply any component-scoped styles. Not ideal. Of course nobody uses those browsers anymore, the same caveat applies to non-custom HTML5 elements, and the bad behavior has long been preventable with JavaScript [0]. But anyone (else) with an extreme backwards compatibility mindset might consider if they could instead bootstrap from <div class="custom-ele"><stdelement></></> and (if needed and in window) a coordinating MutationObserver. [0] https://web.archive.org/web/20091031083341/http://diveintohtml5.org/semantics.html#unknown-elements https://web.archive.org/web/20091031083341/http://diveintoht...

kylecazar 8mo ago

"Now’s a good time to figure out whether your client-side application should have a server-side aspect to it, to speed up initial renders." My how the tables have turned!

verdverm 8mo ago
everything old is new again

slopinthebag 8mo ago

> I’ll focus on React and Redux in some of my examples since that is what I have the most experience with, but much of this applies to other frameworks and to JS-heavy approaches in general. That's not a fair assumption. Frameworks like Svelte, Solid, Vue etc have smaller bundle sizes and rendering speeds that approach the baseline vanilla-js cost. I'm all for criticising Javascript, but moving everything to the server isn't a real solution either. Instead of slow React renders (50ms?), every interaction is a client-server round trip. The user pays the cost of the paradigm on each interaction instead of upfront with an initial JS payload. Etc.

mosdl 8mo ago
Plus Redux is horrible for performance, slows things down and overcomplicates everything.
- Rohansi 8mo ago
  I never understood why state management is overcomplicated in React. For some reason most people use something like Redux which has a very unintuitive API. There are other state management packages available that are so much easier to use and understand, like MobX. https://github.com/mobxjs/mobx https://github.com/mobxjs/mobx
  - littlecranky67 8mo ago
    To shine a light on the mystery, before React had (a) hooks and (b) a stable context API and (c) tanstack-query/react-query or GraphQL - state handling WAS a mess. Thats when redux/mobx etc. made more sense. Try to build something with a pre-2019 version of react and you will understand the need.
  - slopinthebag 8mo ago
    Redux is an implementation of the elm architecture (Tea) which is used for UI state in a lot of languages and frameworks. JS/TS is just not a very ergonomic language for it so it becomes painful quickly. https://guide.elm-lang.org/architecture/ https://guide.elm-lang.org/architecture/

tommek4077 8mo ago

In other news: water is wet. I genuinely don't understand how anyone is still pretending otherwise. Server-side rendering is so much easier to deliver in a performant way, yet it feels like it's being increasingly forgotten — or worse, actively dismissed as outdated. Out of convenience, more and more developers keep pushing logic and rendering onto the client, as if the browser were an infinitely capable runtime. The result is exactly what this article describes: bloated bundles, fragile performance, and an endless cycle of optimization that never quite sticks.

holoduke 8mo ago
Pure client side rendering is the only way to get max speed with lowest latency possible. With ssr you always have bigger payloads or double network rounds.
- k33n 8mo ago
  That’s a laughable claim. SSR is objectively faster, since the client does nearly zero work other than downloading some assets. If the responses are pre-computed and sitting in server memory waiting for a request to come along, no client side rendering technique can possibly beat that.
  - wiseowise 8mo ago
    > objectively faster > provides zero evidence
    - k33n 8mo ago
      I don’t really need to provide “evidence”. I told you why SSR is faster and tbh idc if your time to paint is trash.
    - naasking 8mo ago
      Some pretty compelling evidence is history: we had dynamic and interactive web pages 20 years ago that were faster on computers that were an order of magnitude slower.

prewett 8mo ago

A cogent article. But I think the biggest problem is that the DOM was built for documents, not apps. We know how to build a performant UI architecture: Qt, Java/Swing, Cocoa all have pretty similar architectures and they all ran fine on much poorer hardware than a modern browser on an M1. But unless you use WebAssembly, you can't actually use them on the browser. When the industry shoehorns something into a tool designed for something else, yeah, performance suffers and you get a lot of framework churn with people trying to figure out how to elegantly cut steaks with spoons.

nine_k 8mo ago
It very possible to make lightning-fast React web UIs. DOM sucks, but modern computers are insanely fast, and browsers, insanely optimized. It is also very possible to make sluggish-feeling Qt or Swing applications; I've seen a number. It mostly takes some thinking about immediate reaction, about "negligibly short" operations introducing non-negligible, noticeable delays. Anything not related to rendering should be made async, and even that should be made as fast as possible. This is to say nothing of avoiding reflows, repeated redraws, etc. In short, sloppy GUI code feels sluggish, no matter what tools you use.
- samrus 8mo ago
  > but modern computers are insanely fast, and browsers, insanely optimized I think these facts have been used as excuses to shit up the app layer with slow mal-optimized js code. An example of a recent high performance app is figma, which blows normal js only apps out of the water. And it does so by using c++ wasm/webGPU for its more domanding parts, which is most of it I think we have to let go of the "just get more ram" approach and start optimizing webapp code like figma does
  - nine_k 8mo ago
    Exactly my point: if we're not sloppy, we can achieve amazing performance.
  - Capricorn2481 8mo ago

deleted 8mo ago

[deleted]

robertoandred 8mo ago

Eh, this argument falls apart for many reasons: - His main example of bloated client-side dependencies is moment.js, which has been deprecated for five years in favor of smaller libraries and native APIs, and whose principal functionality (the manipulation and display of the user's date/time) isn't possible on the server anyway. - There's an underlying assumption that server-side code is inherently good, performant, and well crafted. There are footguns in every single language and framework and library ever (he works for WordPress, he should know). - He's right to point out the pain of React memoization, but the Compiler now does this for you and better than you ever could manually - Larger bundle sizes are unfortunate, but they're not the main cause of performance issues. That'd be images and video sizes, especially if poorly optimized, which easily and immediately dwarf bundle downloads; and slow database queries, which affect server-side code just as much as browser-side code.

afavour 8mo ago
> There's an underlying assumption that server-side code is inherently good, performant, and well crafted To me it’s an assumption that server side code is going to be running on a server. Which is a known quantity and can be profiled to the nth degree. It’s extremely difficult to profile every possible device your site will run on, which is crucial with low powered mobile devices. > Larger bundle sizes are unfortunate, but they're not the main cause of performance issues. That'd be images and video sizes Not really, no. Large bundle sizes prevent the initialisation of the app, which means the user can’t do anything. By comparison images and videos download asynchronously and get processed on a separate thread. JS bundles also need to be parsed after being downloaded, if you pair a crappy Android phone with an 5G connection the parsing can literally take longer than the download.
youngtaff 8mo ago
> Larger bundle sizes are unfortunate, but they're not the main cause of performance issues. That'd be images and video sizes, especially if poorly optimized, which easily and immediately dwarf bundle downloads; and slow database queries, which affect server-side code just as much as browser-side code. In network terms JS tends to be downloaded at a higher priority than both images and video so has a larger impact on content appearing JS is also the primary main thread blocker for most apps / pages… profile any NextJS app and you’ll see what a horrendous impact NextJS has on the main thread and the visitor’s experience

exabrial 8mo ago

I’m still baffled why this language is the universal browser standard. There should be hundreds competing.

phantomathkg 8mo ago
I'm still baffled why you don't see JavaScript is fast, but how page rendered is the issue.
- exabrial 8mo ago
  I’m baffled you don’t believe in benchmarks, but, uh.
  - worthless-trash 8mo ago
    life finds a way ?
  - phantomathkg 8mo ago
    Speaking about benchmark. Node vs Lua shows Node faster than Lua. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/node-lua.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Node vs C, only 4 to 5 times slower. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/node-gcc.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Looking at its root, it is not too bad as a JIT compiled language.
    - xigoi 8mo ago
      “Only” 5 times slower? Imagine if every website that takes 10 seconds to load instead took 2 seconds…
      - curtisblaine 8mo ago
        You know that CPU-bound performance would take a really small fragment of those straw man 10 seconds loading a page, right?

wackget 8mo ago

I am so grateful to the author for writing this article. For years I've been fighting a series of small battles with my peers who seem hell-bent on "upgrading" our e-commerce websites by rewriting them in React or another modern framework. I've held the line, firm in my belief that there is truly no compelling reason for a shopping website to be turned into an SPA. It's been difficult at times. The hype of new and shiny tools is real. Like the article mentions, a lot of devs don't even know that there is another way to build things for the web. They don't understand that it's not normal to push megabytes of JavaScript to users' browsers, or that displaying some text on a page doesn't have to start with `<React><App/></React>`. That's terrifying to me. Articles like this give me hope that no, I'm not losing my mind. Once the current framework fads eventually die out - as they always do - the core web technologies will remain.

wmf 8mo ago
Let them have React and SSR everything? Didn't the NYT do this?
hinkley 8mo ago
I think shopping gets this in spades too because not all shopping sites are meant to be particularly sticky. It's one thing to browse the catalog at my leisure on gigabit networking, a 5k display and 16 CPU cores. It's another thing when I'm standing in Macy's or Home Depot and they don't quite have the thing I thought they have and I'm on my phone trying to figure out if I can drive half a mile to your store and get it. If you want to poach that sale your site better be fast, rather than sticky.
nchmy 8mo ago
he links to infrequently.org a few times in the article. You should read every article there - its a revelation. Then check out Datastar

gatane 8mo ago

Github was usable and fast, now it is slow. Guess what changed...

lenkite 8mo ago
It was re-written in React and performance was annihilated. The React Virus annexed another victim and we have one more zombie web-site.
- epolanski 8mo ago
  Yeah, but some project or program manager sure got a raise for delivering this nonsense "update". That was 100% a project sold to upper management as a benefit and modernization.
ahartmetz 8mo ago
It's crazy slow. But it's also a closed source, Microsoft platform for Open Source, so it belongs in the trash anyway.
gloosx 8mo ago
Acquisitionbombed by Microsoft! Instead of usability and performance it has AI now!

carshodev 8mo ago

This title is very misleading, it should be "Why React is not compatible with long-term performance goals" And I do agree generally. React uses an outdated rendering method that has now been surpassed by many better frameworks. Svelte/Sveltekit, Vue, and Qwik are the best examples. People relying on bloated React packages is obviously not great but that is nothing to do with javascript itself. The JS engines are all relatively fast now. And the document model of the current web provides major accessibility to both humans and search tools like SEO and GEO. JS is not my favorite language. I would rather the web was based on a statically typed language that had better error handling practices like Go. But this will most likely not happen any time soon as it would require every level of the ecosystem to adapt. Browsers, Frameworks, Developers etc. Google would have to take the lead and implement this in chrome then enough developers would have to build sites using it and force safari and firefox to comply. It just isn't feasible. If you want faster webapps just switch to sveltekit or vue or qwik. But often the ones choosing the framework for the project have not written much code in years, they know react is as safe option and used by everyone else so they follow along, if it gets slow its a "bug" causing it as they built apps that were "good enough" before using it.

hinkley 8mo ago
The reason I'm a backend dev at the moment is that I looked at the React model and decided I didn't want anything to do with this insanity. I've been appalled by how long and how broadly the mass hysteria lasted.
- DanHulton 8mo ago
  I managed to avoid learning React long enough to become a manager. I'm not saying I won't ever end up in engineering and won't ever have to learn it, but at least right now, it feels kinda like I got away with something.
- carshodev 8mo ago
  And what's crazy is with ai the percentage of apps developed using react in comparison to all other frameworks has INCREASED over the last 3 years. It is truly mass hysteria, I would say that 95% of developers, project managers, and CTOs do not truly understand how these systems work under the hood, or at the very least are too scared and comfortable to try other systems. They just repeat the same things they hear and tell each other "react has a big ecosystem" "react is industry standard" "everyone uses react" "react was developed by facebook" "we will use react" "Developers only know react, how could we hire for a different framework?" In my mind its clear that the alternatives are massively better. When i visit certain websites I often get a random tingle that it uses svelte because its way faster and has better loading and navigation than other sites and when i check the devtools I'm almost always correct. I also get the same feeling sometimes when I hit a laggy slow webapp and I open the devtools and clearly see its a nextjs app. A dev team could be trained on svelte or vue in literally 3 days, and so long as they actually understand how HTML, JS, and css work under the hood they would increase their speed massively. People just don't want to take the risk.

coolThingsFirst 8mo ago

Try this: https://mapjoy.app/ https://mapjoy.app/, username and pass johnsmith. All of JS with client side routing, blazing fast. React is utterly amazing.

smaddock 8mo ago

They mentioned React is missing timing information in the devtools profiler. This was actually added in React 19.2 which should be helpful for debugging. https://react.dev/blog/2025/10/01/react-19-2#performance-tracks https://react.dev/blog/2025/10/01/react-19-2#performance-tra...

umairnadeem123 8mo ago

[dead]

jongjong 8mo ago

I was never a big React fan myself. As someone who has used a lot of different JavaScript frameworks over many years, I can say confidently that it's not the best JS framework; especially nowadays due to bloat. Yet it's better than anything available in any other programming language, on any other platform in existence. Never bet against JavaScript. People have done this over and over and over again since it was invented. So many haters. It's like every junior dev was born a JavaScript hater and spends most of their career slowly working themselves to a state of 'tolerating JavaScript'. JS was designed to be future-proof and it kept improving over the years; what happened is it improved much faster than people were able to adjust their emotions about it... These people even preached the JS hate to a whole generation of juniors; some of whom never even experienced JavaScript first-hand. It's been cool to hate JavaScript since I can remember. JavaScript does have some bad parts, as does any other programming language, but the good parts of JS are better than anything else in existence. People keep trying to build abstractions on top (e.g. TypeScript) to try to distance people from JavaScript, but they keep coming back over and over again... And these people will never admit to themselves that maybe the reason they keep coming back to JavaScript is because it's pretty darn great. Not perfect, but great nonetheless. It's hilarious that now we have Web Assembly; meaning you can compile any language to run in the browser... But almost nobody is doing that. Do people realize how much work was required to bring Web Assembly to the browser? Everyone knows it exists, it's there for you to use, but nobody is using it! What does that say? Oh, it's because of the bundle size? Common! Look at React, React bundles are so bloated! But they are heavily used! The excuse that JavaScript's success is a result of its browser monopoly is gone! Enough is enough! The fact is; you probably love JavaScript but you're just too weak to admit it! I think the problem is that non-JS developers have got a big mouth and small hands...

gorgolo 8mo ago
Do people really hate JavaScript, or do they just hate the design choices and results that it seems to be correlated with? At the end of the day I’m using SaaS tools that are apparently written in React and I get astounded but how slow and heavy they are. If you are editing a page on our companies cloud-based wiki, I’ve seen my chrome RAM balloon from 3GB to 16G. A mistake was made somewhere, that I know.
8mo ago

kittbuilds 8mo ago

[dead]

torginus 8mo ago

My 2 cents: I am not an experienced React dev, but the React compiler came out recently with React 19, which is supposed to do the same thing as Svelte's - eliminate unnecessary DOM modifications by explicitly tracking which components rely on what state - thus making useMemo() unnecessary. Since the article still references useMemo(), I wonder how up-to-date the rest of the article is.

littlecranky67 8mo ago
React has always been tracking what component relies on what state, independent of the compiler. That is one of the reason the rule-of-hook has to exist - it tracks if a component calls useState() and thus knows the according setState function that manipulates that particular state. Idk why people claim React is bloat, especially since you can switch to Preact (4kb) most of the time without changes if filesize is an issue for you.
- Capricorn2481 8mo ago
  Because people make shitty React apps and people think React is slow because of it. It's definitely not slow here. It's within 20% of Svelte. That's not nothing, but it's not the huge monster people claim it is https://krausest.github.io/js-framework-benchmark/2025/table_chrome_143.0.7499.41.html https://krausest.github.io/js-framework-benchmark/2025/table...
  - epolanski 8mo ago
    When 99% of React apps (websites tbh, with very few needs for complex reactivity...) including those built by multi billion/trillion $ companies, struggle to produce non-bloated, non-slow, accessible websites, you know that the library is simply too complex to tame. Of course React can be performant, but still, you're getting a PhD in its internals and hooks to get what you have in vue/nuxt/svelte whatever out of the box.
    - littlecranky67 8mo ago

tpoacher 8mo ago

As an aside, I like their use of blockquotes+details/summary blocks for inserting "afterthoughts/addendums". It's a nice touch, and it works pretty well. Partly because, as a design choice, it forces you to add the afterthought between paragraphs, so the interruption in reading flow is minimal.

Devasta 8mo ago

Why would performance be a goal? If a native desktop app crashes, your users will gnash their teeth and curse your name. A web app? They shrug and refresh the page. They have been trained to do this for decades now, why would anyone believe this isn't intended behavior? No one has a reasonable expectation of quality when it comes to the web.

zahlman 8mo ago
> No one has a reasonable expectation of quality when it comes to the web. And that's exactly why I want native desktop apps to make a resurgence.

flohofwoe 8mo ago

This seems to be more about React than Javascript (or indirectly about the DOM). React sitting on top a browser-style DOM would be slow in any language, while Javascript itself can be surprisingly fast, especially when sticking to the right subset. It "only" needs a big and complex JS engine to get to that kind of performance.

cyberax 8mo ago

Our webapp is nearly instant, and it's built on raw React with some sprinkling of Tanstack (their Local Collection DB is a masterpiece). And our stack is intentionally client-heavy. We proactively synchronize all the relevant data and keep it in IndexedDB, with cross-tab coordination. The server is used only for mutating operations and for some actions that necessarily require server-side logic. The issue with dependencies and the package size if valid, but it's also really not a big deal for performance unless you go WAAAY overboard. Or use crappy dependencies (Clerk, I'm looking at you, 2.5Mb for an auth library!?!?). As for hydration, I found that it often slows down things. It's a valid approach when you're doing query-based apps, but when you have all the data locally, it just makes little sense. It also adds a ton of complexity, because now your code has to automagically run in multiple environments. I don't think it can really ever work reliably and safely.

jakub_g 8mo ago

To me, the main problem is that inevitably, any SPA with dozens of contributors will grow into a multi-megabyte-bundle mess. Preventing it it's extremely hard, because the typical way of developing code is to write a ton of code, add a ton of dependencies, and let the bundler figure it out. Visualizing the entire codebase in terms of "what imports what" is impossible with tens of thousands of files. Even when you do splitting via async `import()`, all you need is one PR that imports something in a bad way and it bloats the bundle by hundreds of kilobytes or megabytes, because something that was magically outsourced to an async bundle via the bundler suddenly becomes mandatory in the main bundle via a static import crossing the boundary. The OP mentions it here: > It’s often much easier to add things on a top-level component’s context and reuse them throughout the app, than it is to add them only where needed. But doing this means you’re paying the cost before (and whether) you need it. > It’s much simpler to add something as a synchronous top-level import and force it to be present on every code path, than it is to load it conditionally and deal with the resulting asynchronicity. > Setting up a bundler to produce one monolithic bundle is trivial, whereas splitting things up per route with shared bundles for the common bits often involves understanding and writing some complex configuration. You can prevent that by having strong mandatory budgets on every PR, which checks that the bundle size did not grow by more than X kB. But even then, the accumulation of 100s/1000s of PRs each adding 1KB, bloats the bundle enough to become noticeable eventually. Perf work is thankless work, and having one perf team trying to keep things at bay while there are dozens of teams shipping features at a fast pace is not gonna cut it.

g947o 8mo ago
Exactly. To avoid dependency explosion, you need at least one of 1) most libraries built internally 2) great discipline across teams 3) significant performance investment/mandate/enforcement (which likely comes from business requirement eg page load time). I have rarely seen that in my limited experience.
pas 8mo ago
It makes sense to have separate entry points for landing pages, no need for fancy providers and heavy imports. In practice people are more than willing to wait for an SPA to load if it works well (figma, gmail/gdocs, discord's browser version used to be pretty good too, and then of course there are the horrible counter-examples AWS/GCP control panels, and so on).

shevy-java 8mo ago

Wasn't WebAssembly going to change all this? Somehow that does not really have been achieved.

mcraiha 8mo ago
DOM access is not in Wasm.

azangru 8mo ago

I think digressions about React dilute the message. Ok, we get it, react bad; but what is the actionable message here? What are the robust alternatives? There is a section on how changes to react (the introduction of hooks and of the concurrent mode) necessitated significant code changes almost amounting to rewrites; but which alternatives, other than vanilla web platform, can promise long-term stability? Which alternatives are better suited for which kinds of applications (roughly, an e-commerce site vs excalidraw)?

nchmy 8mo ago
https://infrequently.org/2024/11/if-not-react-then-what/ https://infrequently.org/2024/11/if-not-react-then-what/

LAC-Tech 8mo ago

Wonderful article. I do maintenance programming, and many of the problems you mention with typical react apps are also code maintenance nightmares. Managing a large number of fast moving third party dependencies will destroy your developer budget, but devs cant see it because they're "Best Practices"

Meneth 8mo ago

JavaScript isn't good for performance? Could've told you that 20 years ago.

catchcatchcatch 8mo ago

[dead]

jadbox 8mo ago

I've gone all SSR (server-side render) with JSX using Astro or Elysia. If I need frontend logic, I just sprinkle in a little Htmx or roll my own inline js function. It makes debugging 1000% easier and the pagerank scores are usually amazing out of the box.

rorylaitila 8mo ago

I've skipped the whole 'modern' web stack. I've stayed SSR first, hrefs/forms/url as only routing primitives, progressive enhancement, vanillajs-islands only where absolutely necessary. Its great. Apps never randomly break. No build hell. UX easy to debug (just look at the HTML). No random performance degradations. No client has ever said it feels dated. Just finished my first app-like PWA, also SSR. Getting great compliments on the UI and slick interactions using just native browser transitions. The vanilla web stack gets better and better! Honestly don't know what people think they are gaining with a heavy frontend.

exceptione 8mo ago
> Honestly don't know what people think they are gaining with a heavy frontend. True, but (I repeat myself here), it depends on what kind of website we are talking about. For instance, a data-heavy SPA that workers use the whole day (like a CRM) is at least perceptually faster and more user friendly compared to the same thing but with traditional whole page reloads.
- codr7 8mo ago
  There's plenty of middle ground here, you don't need fancy frameworks to do partial reloads.
  - exceptione 8mo ago
    I am open for suggestions, but anything wanting to give a desktop like experience is going to be complex. Like the user clicks a button, now widget a1 » a1.3 » a1.3.2 » a1.3.2.2 should be in an "open state", while widget b1 » b1.2 » b1.2.1 needs to be in "disabled state" and widget c3 » c4 » c5 shows a status message.
    - codr7 8mo ago
      Sure, and the further you go in that direction, the more you're building a traditional desktop GUI experience, which was always a bad fit for the web. So yes, if that's really what you want to do, React or similar is probably what you want. If.

sudodevnull 8mo ago

This is well known. You can have full reactivity without being JS heavy. https://www.youtube.com/watch?v=8W6Lr1hRgXo https://www.youtube.com/watch?v=8W6Lr1hRgXo is a perfect example

allreduce 8mo ago

For websites I use regularly, I can identify those which render server side because I trust that when they load on a slow connection my state is still there. When I see a loading icon on heavy client side JS "apps" I anticipate something breaking and me having to reload and re-enter whatever I was working on.

monster_truck 8mo ago

This seems like it's more about React. Javascript is fine. React is garbage

rglover 8mo ago

Interop has entered the chat.

prinny_ 8mo ago

People in this thread hating on React seem to miss the crucial point that 2016 React was a godsend compared to just about every other option available. Vue only picked up steam quite later as React became more and more bloated or had its development forced by Vercel down a certain road. Angular was THE framework to avoid working on and people hated having to define multiple files for a simple component. The timing for React was just right back in the day. Given how FEs are re-written every 7-10 years there is ample room for other frameworks to knock React off its throne, but before asking "but why not X" you also have to consider that organizations by now have almost a decade of experience building React apps and this plays a major role when deciding on which UI framework to rely on.

dsiegel2275 8mo ago

Lost me at "React is a Framework" assertion. The key difference between a "framework" and a "library" is the inversion of control that exists in a framework. React is a library - your app still maintains control of application state and drives the main workings of the application. It is just simply using the React library to render that application state.

gloosx 8mo ago
Fully agree, Inversion of Control is not something which alone defines something as a framework. When defining it along the architectural axis React is architecturally unopinionated thus is has library-level scope, but framework-like control semantics. If framework = anything that uses inversion of control, then a lot of things suddenly become frameworks, including things nobody calls frameworks. One can call it a "rendering framework" but calling it a "web-application framework" is not factually correct.

exceptione 8mo ago

I am the first to admit that SSR worked fine since PHP. But two points I like to make 1) choose boring technology; 2) it is the library, stupid First question should be: what type of web application are we talking about? If your blog does not render or your e-commerce site stops working without javascript, shame on you indeed. If we are talking about SPA's, aka those replacing traditional desktop applications, and you want to throw out React, then we have something to discuss. Because, how are you going to replace MUI/MUI(x)? I keep hearing about the coolness of alternatives, and I am certain open to it, but in the end it needs to be not just better in some aspects or even fundamentals, while completely lacking in practical matters. A simple benchmark I keep going back to is to see if $hotness is able to replace [1], which shows you just one component of many in a cohesive system. I don't contend with the principles in the article, but I do with conclusions like "ripping out react would be the solution". 1. https://mui.com/x/react-data-grid/tree-data/ https://mui.com/x/react-data-grid/tree-data/

suralind 8mo ago

I’ve been very happy using SvelteKit for some side projects. At this point I wouldn’t label myself as frontend developer anymore, but when done right, it’s probably the closest thing to modern, performant and reactive that I know of. It also works really well if the JS just breaks.

fuzzfactor 8mo ago

Somebody noticed.

flatcoke 8mo ago

Agree with the general point, but the nuance matters. Static-first approaches like static exports solve most of this — you get the DX of a JS framework without shipping a runtime to the client. The problem isn't JavaScript itself, it's shipping too much of it.

SauntSolaire 8mo ago
Why do people bother creating new accounts just to post these generic AI comments? It's like people want to ruin HN as fast as (in)humanly possible.

Jgoauh 8mo ago

do you think using webassembly (.wasm) for non UI related code might help with client side performance for apps where server side work is less applicable ?

BrenBarn 8mo ago

I'm not a big JS fan, but to be fair this article seems more like "bloated JS frameworks have poor performance". And like, yeah. But you can use JS without using a bloated framework. It's funny though that the article is circling back to Web 2.0-era server-side stuff. It's an idea whose time has come!