4 ms·

I think author's point is that React is the absolute worst of the evils and it's proprietors shout its false virtues so loudly that it drowns out all discourse

I think author's point is that React is the absolute worst of the evils and it's proprietors shout its false virtues so loudly that it drowns out all discourse and rational thought. It performs the worst (by a large margin) of the major JS frameworks https://krausest.github.io/js-framework-benchmark/2023/table_chrome_109.0.5414.87.html#eyJmcmFtZXdvcmtzIjpbImtleWVkL2FuZ3VsYXIiLCJrZXllZC9yZWFjdCIsImtleWVkL3JlYWN0LWhvb2tzIiwia2V5ZWQvc29saWQiLCJrZXllZC9zdmVsdGUiLCJrZXllZC92YW5pbGxhanMiLCJrZXllZC92dWUiLCJub24ta2V5ZWQvcmVhY3QiLCJub24ta2V5ZWQvc3ZlbHRlIiwibm9uLWtleWVkL3ZhbmlsbGFqcyIsIm5vbi1rZXllZC92dWUiXSwiYmVuY2htYXJrcyI6WyIwMV9ydW4xayIsIjAyX3JlcGxhY2UxayIsIjAzX3VwZGF0ZTEwdGgxa194MTYiLCIwNF9zZWxlY3QxayIsIjA1X3N3YXAxayIsIjA2X3JlbW92ZS1vbmUtMWsiLCIwN19jcmVhdGUxMGsiLCIwOF9jcmVhdGUxay1hZnRlcjFrX3gyIiwiMDlfY2xlYXIxa194OCIsIjIxX3JlYWR5LW1lbW9yeSIsIjIyX3J1bi1tZW1vcnkiLCIyM191cGRhdGU1LW1lbW9yeSIsIjI1X3J1bi1jbGVhci1tZW1vcnkiLCIyNl9ydW4tMTBrLW1lbW9yeSIsIjMxX3N0YXJ0dXAtY2kiLCIzNF9zdGFydHVwLXRvdGFsYnl0ZXMiXSwiZGlzcGxheU1vZGUiOjEsImNhdGVnb3JpZXMiOlsxLDIsMyw0LDVdfQ== https://krausest.github.io/js-framework-benchmark/2023/table... And is highly inefficient in both compute and space: https://timkadlec.com/remembers/2020-04-21-the-cost-of-javascript-frameworks/ https://timkadlec.com/remembers/2020-04-21-the-cost-of-javas... Comparatively, Vue for example, can be used progressively. It is one of the core reasons the Wikimedia Foundation and GitLab chose it: https://phabricator.wikimedia.org/T241180 https://phabricator.wikimedia.org/T241180 . Solid and Preact both perform close to Vanilla and bundle far smaller, improving the end user experience. One of Vue's main technical goals this year is Vapor mode (inspired by Solid) which should yield lighter, faster, and more modular client packages. My take is that React now is the worst of the major libraries yet the most heavily used. It's core design is fundamentally flawed so additional layers of complexity are needed to mitigate it. It doesn't make any sense except for the complexity peddlers who's fortunes depend on more suckers. If you watched the Next.js conf last year, you know what I mean. You can tell they invested a lot of money into production value. I watched a Microsoft developer conference shortly after and the difference was night and day. Ask yourself why Vercel needs to invest that much into a developer conference where ostensibly we developers want good tech, not flashy presentations. Who are they actually selling to? Working at a startup building on Next.js and React, I commiserate with the author's take on complexity peddlers. We have dozens of lines of code for what should take just a handful to do in vanilla. In look at this code everyday wondering why we have piles of JavaScript for very simple interactions. Most recently, a dev made some well intentioned changes that somehow changed Next to only output CSR (no server output HTML); thereby fully defeating the purpose. Now we have a server render cycle calling out to an API that returns JS to render on the client. Probably should just render on the client and skip the middle man! The senior eng team absolutely regrets going Next.js (decision made before I joined). We've been fleeced.

DangitBobby 4y ago
> The senior eng team absolutely regrets going Next.js (decision made before I joined). I am also late to a Next.js engineering party. It was chosen because hype but the developers had no experience in it so they were really just writing it like an SPA (actually no getStaticProps, no getServerSideProps, all client side fetching). The thing was/is a bit of a mess. I think the main problem for them was not taking the time to fully grok the server/client split and take advantage of it before diving in to implement features. I used to dislike Next.js but it's grown on me considerably. Definitely has some problems. That said, I'm having a hard time imagining what this could possibly be: > We have dozens of lines of code for what should take just a handful to do in vanilla.
- CharlieDigital 4y ago
  > I used to dislike Next.js but it's grown on me considerably. Give Astro.js a spin. Notably, take a critical eye to the HTML and JS output of Astro.js vs Next.js. > I'm having a hard time imagining what this could possibly be Think of something as simple as whether a div element is highlighted or not by simply adding/removing a CSS class name. In our case, it's a price tile like you'd see on Target.com. For this piece of functionality, there is a huge mountain of JS (also comprising the state) since we need to manipulate the object model to get the correct behavior when we conditionally render a class name. In vanilla, one might just do something like this and have a general purpose selection behavior: const $ = (selector) => document.querySelectorAll(selector) function select(evt) { $("li").forEach(li => li.className = "") evt.target.className = "selected" } $("li").forEach(li => li.addEventListener("click", select)) https://jsfiddle.net/84b5rhpk/2/ https://jsfiddle.net/84b5rhpk/2/ Another version with super simple option-detail selection: https://jsfiddle.net/84b5rhpk/3/ https://jsfiddle.net/84b5rhpk/3/ Even cleaner V3: https://jsfiddle.net/7szur3ex/ https://jsfiddle.net/7szur3ex/ This code is incredibly fast; requires no compilation, it's highly reusable since it cross cuts the DOM structure using `querySelectorAll` (I can reuse this function to select anything), easy to understand, has no dependency on the underlying data model, and it is stupid easy to debug. A developer doesn't need to learn the quirks of a framework or library to do this. You might make the case that "well, a lot more things are also happening when the user makes a selection", but I'd offer that almost all of the side effects would be easier with vanilla in our case.

DangitBobby 4y ago

> The senior eng team absolutely regrets going Next.js (decision made before I joined). I am also late to a Next.js engineering party. It was chosen because hype but the developers had no experience in it so they were really just writing it like an SPA (actually no getStaticProps, no getServerSideProps, all client side fetching). The thing was/is a bit of a mess. I think the main problem for them was not taking the time to fully grok the server/client split and take advantage of it before diving in to implement features. I used to dislike Next.js but it's grown on me considerably. Definitely has some problems. That said, I'm having a hard time imagining what this could possibly be: > We have dozens of lines of code for what should take just a handful to do in vanilla.

CharlieDigital 4y ago
> I used to dislike Next.js but it's grown on me considerably. Give Astro.js a spin. Notably, take a critical eye to the HTML and JS output of Astro.js vs Next.js. > I'm having a hard time imagining what this could possibly be Think of something as simple as whether a div element is highlighted or not by simply adding/removing a CSS class name. In our case, it's a price tile like you'd see on Target.com. For this piece of functionality, there is a huge mountain of JS (also comprising the state) since we need to manipulate the object model to get the correct behavior when we conditionally render a class name. In vanilla, one might just do something like this and have a general purpose selection behavior: const $ = (selector) => document.querySelectorAll(selector) function select(evt) { $("li").forEach(li => li.className = "") evt.target.className = "selected" } $("li").forEach(li => li.addEventListener("click", select)) https://jsfiddle.net/84b5rhpk/2/ https://jsfiddle.net/84b5rhpk/2/ Another version with super simple option-detail selection: https://jsfiddle.net/84b5rhpk/3/ https://jsfiddle.net/84b5rhpk/3/ Even cleaner V3: https://jsfiddle.net/7szur3ex/ https://jsfiddle.net/7szur3ex/ This code is incredibly fast; requires no compilation, it's highly reusable since it cross cuts the DOM structure using `querySelectorAll` (I can reuse this function to select anything), easy to understand, has no dependency on the underlying data model, and it is stupid easy to debug. A developer doesn't need to learn the quirks of a framework or library to do this. You might make the case that "well, a lot more things are also happening when the user makes a selection", but I'd offer that almost all of the side effects would be easier with vanilla in our case.