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.
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.
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.
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 ?
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.
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?
You're making the same mistake as the author. I get unnecessarily aggro too, but a plain reading of their comment isn't "they only cater to high net worth people" or they're advocating for such. Its "hey we're talking about 3G connections at this point, which are mostly shut down, and we don't cover developing markets"
Note most of this is nonsensical too.
His primary thing is "you don't need client side code because JS = (HTML + CSS) * x, where X >= 1"
We can start sneering about not caring about users there, too, having a one time client side download of that magnitude can certainly be much better on the poors than 10 page loads with SSR.
I keep hearing the "SPA is actually lightweight" argument but it's never materialized for me, the fastest sites are SSRs that are mostly static. The saving from HTML vs JSON just isn't that much over the wire and mobile CPUs and memory are a bottleneck.
I have a newer iPhone and Safari is still full-refreshing pages constantly due to memory.
With utmost respect, that's not what I'm saying :)
I hold no hot take position on anything web dev, or any firm declarative position.
What I'm trying to get at is, indicia of an article being half-baked includes things like asserting all that's required to agree is to care about the user.
This feels good to say, but doesn't say anything, other than there's been at least some short-circuiting of thought. We can come up with many trivial cases where "caring about users" involves requiring client-side logic during rendering.
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.
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.
I spent a lot of time working on react applications of one kind or another and I think most businesses don’t have “problems that React solves” for their frontends. Somewhere that’s actually an application might, but most line of business applications would be better as something like Rails views rather than React
Because, for most business applications I've worked on, React just complicates the frontend code compared to serving up simple HTML views and for no real benefit aside from "using React"
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.
> 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.
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.
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.
I've been at orgs that wrote 3x apps and at orgs that shipped via RN. RN was a significantly superior choice ime. While yes, it wasn't 100% write once, it was pretty good and also avoided some of the ugly single-platform-only bugs I experienced at choice one, eg in core data libs (subtly different validations on data), that made the write 3 apps strategy be more like 4x work.
As for the article, honesty probably would have just had the author write something like: "RN: an unfortunate but maybe your best choice in these circumstances" instead of pretending there's serious alternatives eg the Apache garbage dump.
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!
"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."
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.
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.
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.
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?
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.
They're a wide chasm between what one can make and what is led to making. React can lead to fast, responsive websites, though you'd be fighting against a current pulling you out to a bloated, buggy mess. There's a unique stench that comes from many react sites where everything is a skeleton screen, everything loads slowly, history rewriting is busted, there's no hotlinking, and scrolling is glitchy. Peek under the hood, it's almost always react. Facebook.com quality is the outlier, not the likely outcome.
React is far from performant for SSR, and it simply can’t be, as it wasn’t designed with backend needs in mind. The fact that it works at all is more of a happy accident or side effect. Current approaches are more like workarounds than proper solutions for making it function effectively on servers.
Most importantly, it’s also not particularly performant on the client side in real-world scenarios.
If React is so great how come Amazon isn't using it in their store?
I think last year an Amazon frontend engineer wrote some tweets explaining they tried React and it was too slow. So they keep using Java for SSR and sprinkle vanilla JS. They were still using jQuery until a couple of years ago and probably still are in some parts of their site.
Do not base your company’s tech decisions on FAANG companies unless your company is a FAANG company. Your challenges are likely very different from theirs
You just picked Amazon arbitrarily because it supports your argument, but there are many more counter examples where react is used, so what's your point?
And who where it’s faster and more performant? Not Pinterest. Not Airbnb. Not X. Not the Amazon competitors he showed. Not even the flipping creators (Facebook) of the framework. You all keep blaming the specific companies for their sites but can’t ever seem to show us an actual performant and good example of react usage.
Because Amazon Store is and aleays was an armpit of webdesign? It's the worst designed e-commerce site and decades of tinkering only brought it half way towards basic level of decency that was obvious to a beginner web developer making their own first e-commerce site from scratch in PHP 20 years ago?
React is in use in many heavily used frontends at Amazon, maybe not the retail site
But there's no inherent reason React couldn't be used for a page that basically shows pictures of products with a description next to them, the bottlenecks will have nothing to do with the frontend in a well engineered system for that type of site
My constant problem with React-based tools is that they don't support deep links properly. You want to right-click on a product description to open it in a different tab to check later, and you can't.
Even freaking Google (who really should know better) suffers from that. Amazon's retail frontend uses plain HTML, so it works fine.
I'm not sure how much experience you have with react, but it doesn't need to "support" links, they function exactly the same as with vanilla js, there's nothing about react that prevents their use. Using JavaScript for links is entirely a developer decision.
I'm familiar with React. And no, links in React often don't work without extra attention.
It's way too easy to put some state information into the context and then have your pages depend on it. For example, you have a page with a filter that is implemented via a simple state, and then a list of widgets that pass the filter. The widgets have a click handler that opens the widget details.
Now you right click on it. If you're lucky, it opens the widget details in a separate tab. However, the filter information is lost.
> I'm familiar with React. And no, links in React often don't work without extra attention.
^ These two statements are at odds with each other.
React will return a pure browser link that behaves exactly as a browser link:
function Comp() { return <a href="some-link">text</a>; }
> The widgets have a click handler that opens the widget details.
>
> Now you right click on it. If you're lucky, it opens the widget details in a separate tab. However, the filter information is lost.
So, the problem isn't React. The problem is people overriding default browser behaviour for their widgets. It was a problem before React, and it will be a problem long after React.
For example, here's Google's premier site about web technologies: https://web.dev/articles Check out the pagination links at the bottom. There's no React on the page
> React will return a pure browser link that behaves exactly as a browser link
No it doesn't (in practice). React is typically used with something like React Router that takes over the whole sub-tree of paths. So links are handled by the single-page app itself, and this can lead to the state leaking through.
> React is typically used with something like React Router that takes over the whole sub-tree of paths. So links are handled by the single-page app itself,
"Taken over by Router", "handled by SPA itself" .... "React is to blame"
> Yes, you don't _have_ to do it this way.
Yes, you don't have to it this way, and this isn't React-specific. See Google's web.dev site built with web components
> And no, links in React often don't work without extra attention
Links work fine, out of the box, react treats them the same way vanilla js does. JavaScript onClick events aren't links, and that's true whether you're using react or vanilla js.
> It's way too easy to put some state information into the context and then have your pages depend on it.
What do you mean it's too easy? If someone makes poor engineering choices because that's the "easy" thing to do, that's their fault, the tool didn't make them do that.
> Now you right click on it. If you're lucky, it opens the widget details in a separate tab. However, the filter information is lost.
This is true of JavaScript in general, it has nothing to do with react. In order for links to work, the server has to render pages that correspond to the link, whether that means encoding state in the url or pulling it from a session, this is required whether you're using react or literally anything else.
> My constant problem with React-based tools is that they don't support deep links properly.
I worry that most people complaining here about React, including the OP, do not actually understand the very basics of React. Here someone is complaining about how React somehow messes with deep links. Without understanding that React does nothing to links. Nothing.
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.
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.
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.
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.
This is one of the reasons I think hooks stink. It seems like they tried so hard to avoid using classes that they came up with an opaque, framework-only way to manage state so that they could declare "ha! Stateless functions at last!". The state's still there, it's always gonna be there, it's just now hidden behind an abstraction that has a few footguns.
1. Nobody said that classes are bad. Yes you can encapsulate logic and state in a singleton, that's not the issue, the issue is how you then "apply" it. There was a fantastic diagram that (most likely) Dan Abramov posted on Twitter a while ago (before it became the olympic pool of diarrhea that it is today) that was demonstrating the superiority of hooks in a beautiful and obvious way but I cannot find it anymore... :/
2. Sorry but if you keep using "weird", "hard" and "complicated" adjectives to define something that is quite honestly not so hard to grasp you make it hard to not go with "skill issues".
Nobody is saying that officially, but for the past 7-8 years the react documentation pretty much ignore class components. Today you have no way of knowing how to create a large class based react application because the ecosystem has moved on, it’s not the best practice.
I’m using weird and hard in a relative and not absolute way. Weird because functions can’t have state, and for years we’ve been taught to keep functions small and predictable.
Hard because there are much simpler ways to write stateful code other than hooks.
The problem with react is that instead of creating a powerful state library, powerful ui library, and creating a bridge between them, they chose to subjugate the state library to the UI library’s limitations.
How do you write a singleton service that can feed state back into the component that calls it when that state changes?
For example, `api.fetchInfo()` would want to feed Loading | Success(T) | Error(E) back into the React component call-site when they change.
EventEmitters come to mind but aren't without their own issues like subscription leaks. And you have to track component arguments in order to know when to call the service again when they change which is a classic source of complexity.
Hooks provide a solution for this since they themselves are just nested React lifecycle constructs (like useState + useEffect).
In class components you just could await the result and perform a set state, and that would be it. Easy as pie.
But now in function components when everything is called all the time without your control you have to use escape hatches like use effect just to work around react.
Hooks let you wrap all sorts of logic (and other hooks) and return values that rerender the callsite component when changed. Just keep adding on to my hook example and you get more and more code that you need to repeat in every class component that uses it.
Of course, the class component solution to this was to use an HOC, but that had its own issues like complex data flow and wrapper hell.
Hooks solve problems of composition without Yet Another Wrapper and they give clearer data flow, better ref forwarding, etc.
It's easy to see complicated useEffect spam and blame hooks but frankly that wasn't any better when it was happening at different layers of HOCs.
You can just use a service instead, expose public methods and hide private while keep expending and refactoring the internal logic. The same way it’s been done for decades. The only problem is the one that react created for itself in function components which is when to refresh the render from the state.
Not parent, but I'll answer anyway: React was much much easier to learn back when Class Components were the thing. Nowadays there is layers upon layers of magic like Functional Components with State from Hooks.
> Nowadays there is layers upon layers of magic like Functional Components with State from Hooks.
1. you can still write class based components if you want, but if you are in a team everyone will hate you for that because...
2. the preferred and vastly more flexible and powerful way is functional components. That's it, there isn't any other way or any other mystical layer of magic.
What everybody in this umpteenth omfg-react-is-satan thread is that implementing complex things with simple things is a fucking pipe dream. Fucking deal with it.
I didn't talk about any pipe dream, I named a very specific way of how those things were done before - in React! - and how it used to be simple and now it's not.
"Fucking deal with it?" What are you, a cultist? I answered a question here, fuck off.
> Sorry to be the bearer of bad news, but the JS-free web isn't coming back.
It has never went anywhere? All it takes is a user brave enough to disable it or to use a web browser that doesn't use it or has issues with it. But for some reason many web devs actively ignore that.
As someone who's been doing React since the beginning, I would agree that it's hard starting out.
However, I think any new paradigm is difficult starting out. Recently I've been learning OO for work and I've been finding it stupidly hard and entirely unintuitive.
I’ve found Vue easier to learn because it bundles things and lets you learn visual components before fully exploring the reactive model. So while the modularity of React is preferable to a seasoned developer, it does no good to a newcomer.
I have no doubt React is easy if you've been there from the beginning. But if you learned it last year like me, you got to find out the hard way that things are done slightly differently in each version, introducing breaking changes which invalidate the vast majority of the documentation you can find (which you need because the official docs is absolute crap for beginners, as it assumes you already know React's paradigms).
what do you mean by learning OO here? javascript is OO too, so you have already been doing OO, as far as i understand it and what you are learning is something different. and now i am curious what that is.
Cannot agree more! Mastering React is ridiculously hard for what it is. There are so many “buts,” “it depends,” and subtle differences to navigate, like useEffect vs. useLayoutEffect. But don't forget useEffect is an evil in the first place and so on, and so on.
It feels like a clever proof of concept with a leaky abstraction at its core, one that no amount of effort can truly fix, no matter how much they throw at it. They’re even building their own compiler. A compiler. For something that’s supposed to represent the V in MVC.
As a SPA framework, it’s questionable. But using React to build server-side apps? That’s beyond absurd for me, it’s like Electron for the backend, only worse. And yet, the industry loves to pretend otherwise, so here we are.
React is a guided missile foot gun. You can figure out how to have it hit something else, but even when you aren’t pointing it at your foot, it’s probably going to hit your foot. You can have that feeling of wonder as the rocket sails off into the distance, and then just as you get customers, it comes back over the horizon and hits your foot. Experienced physicists and rocket scientists can override the guidance mechanism and have a much better chance of not hitting a foot, but who has time for that. Most people just like that it has a big red button labeled “Shoot” that’s easy to press.
You shouldn't write a single useEffect in the first year or two of your career in React.
Why people are so keen on stabbing themselves just because there's one or two weird shaped forks in the kitchen drawer. Why do suddenly everyone tries to use it for spreading butter or peeling eggs?
Just understand what unidirectional data flow is and you are golden. You know the entirety of React you should be using for your first year of full-time job.
That’s true. Just to note, I never claimed otherwise. See, useEffect is an evil remark. This is more based on my experience working with an average React codebase.
As for your question, “Why does everyone suddenly try to use it for spreading butter or peeling eggs?”
I guess part of the reason is that many people rely on older tutorials and patterns where the usage of useEffect was much more tolerated or even encouraged as a catch-all solution. There’s still a lot of inertia from the old componentDidThis/componentDidThat paradigm, with useEffect being its direct replacement.
I feel it is only a recent tendency to finally abandon the overuse of effect hooks.
Just open an average Stack Overflow React question, and you’ll see how many useEffects are crammed in there.
That’s probably the main real-world use case for useEffect. Dedicated third-party libraries like React Query obviously use useEffect under the hood as well
Between modern frameworks and that MS born monstrosity Typescript, I thought this was the JS-free web. I would love to see the back of it.
Web Dev seems to be ignoring the last 10-15 years of new native browser technologies and getting really stagnant with proprietary bloat as a result.
It's a really good time to start from scratch and see what we can do with WebGL/WebGPU/Shaders, WASM(C, C++, Rust Etc) and Web Audio, as well as the new features of Vanilla JS
It was so easy that people strived very, very hard to make it seem complicated - and they succeeded. Back in the day every React tutorial layered in soooooo much other stuff, Redux and a million middleware layers that completely obscured what React was.
The core of React though is really simple and no amount of attempts at complexification can destroy that.
Hello world might be simple, but you don’t have to build very much before you start to run into problems with the simple “props down, events up” and you start needing to learn about contexts, hooks in general and so on.
Hooks is really one of those things where you need an IDE to tell you that you’re doing it wrong, since there’s a whole bunch of footguns. It’s doing its best to solve a hard problem inside the limitations of JavaScript, but it is essentially a kludge.
As someone who developed in Adobe Flex back in the day I find React so straightforward that as long as you keep an iota of discipline then even events, contexts and hooks feel "easy" compared to every other attempt at large Rich Internet Application approaches I've seen.
Just like in Flex the difficulty (and don't get en wrong often extreme awful difficulty) comes when someone fights against the system and can cause a cascade of terribleness. There were always telltale red flags when looking at Flex code when someone tried to circumvent the component lifecycle and the same smell can be spotted in React code.
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).
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_programmin...
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.
This new language.
Do you mean something that compiles down to JS like Typescript, Coffescript & Dart?
Or a language that compiles to WASM like C, C++ or Rust?
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.
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.
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.
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.
> In case I was unclear, I consider Angular dead and obsolete.
maybe you would expand on this? I have no intention to challenge you, just genuinely curios if and why I should consider vue over agnular for new project (I use angular already).
Maybe Angular is still used a lot, in legacy projects. I just mean for starting a new project, imo most people will choose React or Vue in 2024, right? I never used Angular myself, but have used both React and Vue a lot.
I don't have strong insights about current agnular popularity. I think at least teams/companies which built strong expertise in angular will continue using it for new projects unless there is some big reason not to.
Thanks for sharing that graph. It does show React as the leader, the the others in distant 2nd/3rd place.
However I think the "drop off" in the chart for React is misleading/incorrect, and likely indicates just a slowing down of the economy and/or people moving to LLMs for their searches and abandoning StackOverflow completely, as I have.
For the past year I haven't yet found a question that an LLM couldn't answer better than S.O. could, although ironically most of the LLM learning did come from S.O.
Anyway, yeah shops will stick to their legacy code forever unless something forces change, because retooling is super expensive in money and time, not to mention replacing all your developers with different ones!
If you’ve never used it don’t declare it dead. Angular is updated regularly every 6 months. While react is busy thinking how to create more SSR apis, the angular team keeps improving developer experience.
IMO right now it’s easier to start an angular project with much less foot guns than react.
I call plenty of things dead without ever having used them. FORTRAN for example.
What I mean by dead is it's a VERY unlikely choice for any new app. People will choose React or Vue most of the time. You don't see Angular used hardly ever for a new project.
BTW: Vite is the new best way to manage the build pipeline, and makes React super easy to start using.
As I already pointed out, my use of "dead" doesn't mean "no longer in use". It means no longer being selected by choice for a new project.
And your drill press example is agreeing with me, which is that, as I also already said myself, no one needs to have ever used something to be able to declare it dead, nor did I declare something dead because I don't personally use it. That's absurd.
Have you ever worked on a project that used Rails, Laravel, Django or Spring? Without being a SPA? For many (most) websites, I find that these are far superior to client side heavy SPAs with json apis (react, vue etc).
Most of the apps I've worked on were very business oriented, and about people getting work done, rather than "website" type stuff that's mostly static. So for example, being able to refresh a part of the screen with new information from the server, is critical. Doing page reloads would destroy the experience. I have 35yrs exp so yes I've used most of what you mentioned.
I just use the 'fetch' command to get data from the server. That's basically like Ajax. Where React comes into play of course is taking care of all the page updates, which would be a nightmare for any large app, unless you have a framework being used.
WordPress relies on server-generated HTML and its admin interface is a fairly complex "app", especially once you factor in the plugin ecosystem. According to [1], it's used on 43.7% of all public websites.
If every user input causes a page refresh, that's not an "app" that's a "website". If you don't have any executable code (i.e. Javascript), but just form submits, yeah I agree that's what most of the web is, and as you pointed out most of the web is websites not web apps.
I'm not saying my own definition of "app" is the only correct definition, but in my opinion only if I do a click and something on the SAME page changes, then it's an app. Transitioning to different pages isn't an app, imo.
Right. That's precisely why full page reloads/updates every time some action is done (mouse click for example) would be completely unacceptable for most apps I've worked on. I've worked mostly on apps not websites.
The overwhelming majority of default HTML actions (no JS) that happen from a mouse click do not trigger a page load. You're trying to make it sound like selecting an item from a dropdown or selecting a textbox to enter text will cause a complete page load every time unless you use an SPA framework and that's just literally completely untrue.
By your measure though, it sounds as though you'd be fine if these page loads in the javascriptless world were done in iframes, since then only some portion of the site is being reloaded?
I'm using that to illustrate the argument is absurd and the basis on which it is made seems also absurd.
SPAs are heavy and frequently written poorly, often eschewing the principles of loading only the bare minimum for a kitchen-sink approach. If you view the web as having only those two options to accomplish "real work" then yeah, you're gonna thing that SPAs are the only way. It's not reality though.
Static sites have their place in the world, for sure. But for large sophisticated apps where a mouse click might cause a state change that might update an unpredictable number of discreet individual visual changes throughout the entire page, that's where an SPA is needed. If you call this "absurd" it really shines more of a light on your own credibility than mine.
> But for large sophisticated apps where a mouse click might cause a state change that might update an unpredictable number of discreet individual visual changes throughout the entire page, that's where an SPA is needed
In my experience, these apps are rare, yet SPAs are prevalent. Which is a problem.
It would be nice, from a user perspective, if boring "apps" that are mainly forms and tables would quit it with SPAs already.
I know what you mean. The train went off the tracks in about 1995 when JS was invented to begin with. We never had to "Mix Apps with Documents" to begin with, but that's how the industry evolved and to this day every modern stack/framework is still just tools to compensate for that "original sin" lol.
I think you're failing to understand that there are hundreds to thousands of functional applications out there that are not SPAs that are doing all of those things just fine. An SPA is not a requirement to be able to update values in a form, transition between page states, etc. The two options are not only Static Site or SPA -- that is the absurdity.
Making an entire application a single page load and then some API calls sounds attractive when your application is small to medium sized in terms of complexity. It runs into problems when complexity or feature count pass a certain point.
It’s been a while since I worked with WordPress, but isn’t their Gutenberg editor (which is the heart of their CMS) built on React? So while React may not be used on the user facing side, it is still powering the content side of WordPress and in a way, powering all of those sites.
You can't be more wrong. You're saying that only logic performed on the client side can be considered an application? State can be stored in the server. Screen changes can be done by loading html, it doesn't need a framework. React is far from crucial for web development, but people haven't learned anything else the last decade. Most front end developers these days don't even know what a template engine is, and some don't even know how to create a website without a backend rest api that spews json data.
I wasn't comparing SSR to non-SSR (Server Side Rendering). As long as you can refresh portions of a webpage (or states of GUI elements), after a user action (button click or whatever), that's fine.
However the reason my Dialog Boxes open in a millisecond, and close in a millisecond too, is because I choose to render them locally. I'm not against SSR tho, as a viable concept. That's a different complex discussion where there are trade-offs to consider.
> 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.
The options you present are: "either use a JS framework or don't use JavaScript at all". That's a false dichotomy. I've built plenty of interactive apps with JavaScript without using frameworks.
> I've built plenty of interactive apps with JavaScript without using frameworks
And once you reach sufficient project complexity, you will end up with just another homegrown framework, with all the lessons learned by mature frameworks, left to be fixed over the next 5 years.
Oh yeah? And when will that happen? Because people have been throwing this argument at me since at least 2014. I still haven't slipped on a banana peel and accidentally fallen on a homegrown framework. You don't just create a framework by accident.
I don't have any context, but I do have trouble imagining that any of your projects have scale/complexity above brochure-ware if you haven't run into this.
Even if you know of massive projects in JS, the problem isn't that they cannot exist, it's that maintaining them takes 100x the manpower it would in TypeScript.
Yes it is. App.js is all the code there is. You can't count the two other files with 10 lines each. lol. Let's be honest here.
And yeah for a tiny toy project like this you can get away with having zero design, zero architecture, zero object models, zero classes, and sure since everything is zero, we can throw in "Zero TypeScript" and "Zero Frameworks". Looks like some high-schooler's first ever coding project.
There's literally only 4 JS files in the whole repo and you couldn't be bothered to check how much code they have? Even after I told the other guy who made the same false claim "no, it's not a single file codebase"?
Jesus you people are insufferable. So obnoxiously confident while being wrong about easily verifiable facts.
> tiny toy project
Huh? 99% of web development is about rendering text and images. This project is moving your mouse inside a web browser & provides a plausible chat experience without a language model. That's more ambitious than just about any actual work project I've seen.
Even considering chatbot.js, it's still a small enough toy project to just barely get by without type safety. I don't consider a project "large" until it's in the 30K to 50K LOC at least, where it becomes impossible to literally remember where each use of any given variable is. Type Safety catches most typos at build time, and also allows ease of refactoring. Only these small projects can get by without type safety, but EVEN the small projects DO benefit from catching errors at build time. It's just a self-foot-shoot to find bugs at runtime instead of build time.
The question in this thread is not TypeScript vs JavaScript. It's framework vs no-framework. Specifically, is it possible - possible at all - to create an interactive web app without frameworks - one that isn't "just a document" or "brochure-ware". I've demonstrated pretty clearly that yes it is possible. You people just keep shifting the goalposts further and further... Now it doesn't count unless it's 50K LoC? As if unnecessary complexity was some kind of inherent good.
I never saw anyone on this thread deny that JS CAN be used without frameworks. As a developer since before the internet even existed I've written probably at least two to four million lines of JS in my life, so I'm well aware.
What people are saying is that for LARGE projects you NEED a framework. And your app is tiny. It's got like two source files. So it's just an example of a tiny project getting by without a framework. I have a couple of those currently myself, because I don't need a framework for them. They're just HTML+CSS+JS.
He's right. You have a project with two source files in it. That's basically not at any kind of scale he was talking about, and is easily classified as brochure-ware, from an architectural standpoint, simply because there's no architecture to it at all. Just a monolithic file.
I was willing to assume good intentions from you earlier, but at this point it's clear you're just lying. You've seen the number of files in the repository, we already had a back and forth and you already conceded there was more than one file. And yet here you are, reiterating the same lie. Weird stuff.
Those two 17 LOC files don't count. That leaves precisely two source files, just like I said. It's well under the threshold where I'd consider a framework mandatory.
> And your app is tiny. It's got like two source files.
If the same app had been written by a typical team of React devs, it would be >1000 source files and 50K LoC. That's not an argument against my approach, it's an argument in favor of it.
The SPA version would unmanageable without the latest 4th generation JS build tools. Spend an afternoon reading the manual for the configs. Watch the output of 'pnpm list' break your terminal environment when you try piping it through 'less'.
You have it exactly backwards. Since React does all the DOM updates automatically, my massive project, with 100s of thousands of TypeScript LOC, has zero DOM calls in it. lol.
I have a lot of "framework free" single-developer projects as well (such as https://bongo.to ), but that isn't really what I think we are talking about here. Single developer projects can do whatever they want, it isn't a problem. The problem comes when you have to work with distributed teams, juniors, etc. One way or another a large team still has to come to agreements about how to do things, and without an external reference it will have to be made up in an ad-hoc manner instead. This often leads to issues, many of us have noticed.
I absoluetly agree with your sentiment, and furthermore in projects as large and mature as mine, with 500K LOC (about maybe 30% in TypeScript) lots of times I simply cannot remember enough about my code to effectively refactor it from memory without type safety (to check me) and IDE refactoring to DO the refactoring.
I mean if I need to change a variable name in a class or something, unless it's a perfectly unique name (easily searchable), it would take me hours to do in JS what I can do in 4 seconds with TypeScript.
The claim upthread was that you couldn't make a web app at all without a framework ("or it would just be a document"). I said yes you can and the goalposts shifted to: sure, but only "brochure-ware" (referring to simple unambitious projects). I show an ambitious interactive project made without a framework and now the goalposts are moving to: sure, but large distributed teams couldn't work like this? You know, this solo project is more ambitious than 99% of the projects I work on at my actual work. You know, projects that have 10, 40, or 100 devs working on it.
For any large project you need type-safe languages. 99% of experience developers (10+ years of experience) will agree with this opinion.
Sure you can develop very large projects in JS, as long as you don't mind being 1% as efficient, and having 100x more bugs. In JS, refactoring a huge project is the biggest nightmare in the world and really no human is capable of doing a great job of it in a reasonable time, even if they have a high IQ and decades of experience.
Me too. lol. People who don't think type-safe languages are important are the ones who simply haven't yet run into the problems you run into without type safety, and no amount of HackerNews posting is going to suddenly give them the experience to understand.
"People who disagree with me on the topic of """best language/framework""" are ignorant and lack experience to see how {my_favorite_language} is actually the bestest"
I literally said the exact opposite. I don't care what language you use as long as it's type-safe.
Any language that lacks type-safety is completely inappropriate for large-scale projects. There's no seasoned developer on the planet who disagrees with that sentiment. None. Zilch. If some guy claims to be #1) decades experienced and #2) doesn't like type-safe languages, then he's lying about either #1 or #2 or both.
First it was "10+ years experience", which would qualify me, but now you shifted the goalposts again to "decades" experience. Lol. I guess you can keep pretending that everybody who matters agrees with you when you just count everybody who disagrees as someone who doesn't matter
I originally typed "seasoned developer" and then I edited it to say decades. Neither one of us has perfect definition of "seasoned developer" in terms of precise years, and it doesn't even matter.
But there are some things that are obvious to any seasoned developer and the value of type-safety is one of them. It's not my opinion. Is a fact. And yes if you say you have 10+ yrs and you don't prefer type-safe languages, then yes I indeed do not even believe you.
I'm a seasoned developer. Your opinion is just your opinion, not a fact.
Have you heard of Python by any chance? Pretty much the entire field of data science is built on top of a dynamically typed language. Plenty more seasoned developers working in that field.
Seasoned Python developers started using every type-safety feature available to them, as they've became available, just like JavaScript developers who know what they're doing have switched to TypeScript for the same exact reason.
If Python was just fine without type-safety that's how everyone would have kept it.
> Seasoned Python developers started using every type-safety feature available to them, as they've became available, just like JavaScript developers who know what they're doing have switched to TypeScript for the same exact reason.
This is another lie from you. A vanishingly small minority of Python developers is using "every type-safety feature available to them". Not that it even matters to your earlier claim, because Python is not a type-safe language even for those developers who are using "every type-safety feature available to them". You claimed earlier that "Any language that lacks type-safety is completely inappropriate for large-scale projects" even though you seem to be aware of the fact that "seasoned developers" are using Python for "large-scale projects". So, again, you're just lying.
Every highly experienced developer knows the importance of type-safety. The existence of large numbers of experienced Python developers in the world doesn't disprove that, because it's a statement about their knowledge, not their actions.
Python developers simply tolerate the lack of type-safety only because it's a trade-off to get other things the language has to offer. I agree there are trade-off decisions being made.
Yep, great developers know they "need" type-safety, but we don't always have it. Even my own app has a Python Microservice in the docker stack where 100% of my LLM/AI code is contained, simply because I wanted all the latest and greatest AI tooling (especially LangChain). I opted for Python over Java for that microservice, but used various tools to achieve build-time type-safety.
> And yes if you say you have 10+ yrs and you don't prefer type-safe languages, then yes I indeed do not even believe you.
You don't believe what exactly? Don't believe I have 10+ yrs of experience? You can see that my GitHub account has activity from the past 10 years, so... you don't believe I prefer dynamic typed languages like Python? You think I actually prefer static typing and I'm lying about that? Like what?
I guess literally none of those people were "seasoned developers" either, and none of them had ever worked in a "scaled" and "large" project, like you mr big man.
Also, we're talking about the web here. How many type-safe supersets of JavaScript are there? When you say "I don't care what language you use as long as it's type-safe", you're pretending as if there's more viable options than just TypeScript.
There is a choice on the server side too, to go with type-safe languages or non-type-safe ones. When I'm stating something as true and general as the importance of type-safety I speak as broadly as possible, because I'm indeed NOT talking about just TS when I say "type safety", I mean it everywhere computer code exists. All untyped languages are garbage.
That was kind of my point. You speak to type safety and all the issues not having is that would be prevented but memory safety is yet another one and is a huge issue with common platforms TODAY. So, obviously your pet issue isn’t the only one out there and there are trade offs made.
My point was how our most serious issues are with memory management that exists in popular type-strict languages and so type safety is not up there in importance compared to the biggest causes.
That's exactly backwards. Without the type-safety in those memory-unsafe languages (like C++) there would be 100x more buffer overruns and other memory issues and security holes. Having the type-safety in place is literally the main thing that makes memory-unsafe languages viable.
Popularity is not an argument for merit. Diabetes and heart disease are popular. Taylor Swift is popular. It doesn't follow that I should desire these things.
If appeals to the status quo were reasonable arguments, there would be no room to improve on what is.
Popular is not a synonym for "common", like you're implying it is. They're different things. Popular means desired.
The more popular a piece of software is, the more likely it is to have had the bugs worked out of it, the more people there are reporting issues, the more answers there are on StackOverflow, the more likely AI/LLMs are to be able to answer questions, the more secure it's likely to be, the more stuff interoperates with it, etc. Popularity alone isn't a good reason to select something, but it's a good data point, with which so judge viability.
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
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.
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
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.
Sometimes you have to fight fire with fire. The fact that some people reach for React before even considering what they are building requires some corrective polemics.
If you try something for a decade and it doesn't work, maybe a change in style is necessary! An article exceeding 20 pages doesn't sound like the best persuasion strategy.
I’m not a front end engineer and I read most of this, at first for sheer morbid curiosity about the drama, then I kept reading because it looked like deep knowledge and detailed exposition of a complex subject, then I kept reading because I was wondering who listens to a guy like this and why?
In my experience, regardless of your skill at communication, coworkers or bosses that are actually interested in getting to deep knowledge or detailed analysis about anything are extremely rare. If you need to communicate a subtle point or detailed argument, then you’ve already lost. This is because for any technical decision the opposite argument from FUD is easier to make and easier to digest, regardless of whether the FUD advice is to stay/defect on the tech stack or the design decision or whatever. IOW the winning strategy is basically to always go 2nd after what TFA calls the “thoughtful engineer” burns out the audience by being rational and thorough. Even more bluntly.. most people are just showing up to work and have no interest (and much less passion) for craftsmanship.
I wish it was different, since I believe in architecture / design. But, there’s a good chance no one cares about your detailed analysis at all and you’re much better off producing more shallow demos/diagrams/decks regardless of whether your audience is engineers or management.
My only quibble is that it’s certainly possible to choose React (or any popular solution to a problem) without considering other options too much, and still care about craft.
> coworkers or bosses that are actually interested in getting to deep knowledge or detailed analysis about anything are extremely rare
I agree! In general, people are resistant to change, period. Some are particularly wary of facts and logic (see: politics). Successfully getting points across, even when one "is right," often requires a lot of strategizing and non-technical effort.
Whole books have been written on this subject [1]. For those attempting to navigate the challenge, just remember that it's all too easy to burn out in the office while "chasing your ideals.". Doing this while keeping your sanity is an art :-).
I happen to agree with most of what he said, but man, that tone was insufferable ...
(non-wrapping extra long lines have not helped but maybe that's on my user agent)
My rules of thumb:
* informational website / blog - static frontend (Django! :heart:)
* some interactivity - htmx
* a lot of interactivity (app that happens to libe in the browser) - spa (React and weep)
For a very strong assertion he makes (even if you need spa, react is obsolete), he dismisses finding a good alternative as an exercise to the reader. The ones listed offhandedly in a side note look all the same (as react) to me.
Yes, I think you’re right. I overwhelmingly agree with his articles, but when I share the content with my colleagues it gets at best a careless shrug, but most often what amounts to “but [technology referenced] is good because it’s popular.” React is one of those problematic choices companies continue to make.
> 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.
The sad part is that it's the same increasingly hostile arguments he's making while he spent the decade making sure that browsers remain bloated and tech requires Javascript to even barely function: see his entire work on web components.
> 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
He's not the only one speaking about web performance, or doing research. He's not Casaandra. At best, he's a false prophet.
His series on web performance gaps is good, though.
> and tech requires Javascript to even barely function: see his entire work on web components.
I'm confused by this characterization of web components. While they can minimally work without JS now (i.e., declarative shadow DOM), the whole premise builds atop of how the web and the browser works, and that is progressive enhancement. Your browser starts showing you the content before all of the content has finished downloading, and as it finishes, it progressively enhances the content of the page. Web components is a part of that story.
Why do you want web components to work without JS? Do you also put the same constraints on frameworks?
> the whole premise builds atop of how the web and the browser works
Of course not. They need Javascript to participate in forms (though a button on WCs still can't work as a submit button), they need JS to handle global styles, they need JS to handle ARIA (there are at least two different proposals for this), they need JS to fix text selection etc. etc.
Nothing in web components two dozen specs builds on top of basic browser functionality.
> Why do you want web components to work without JS? Do you also put the same constraints on frameworks?
That's bot what I wrote. I'm calling Alex Russel's hypocrisy. He's ranting against web frameworks while he's spent the past decade creating tech that needs more and more JS for basic functionality (and more JS to fix issues previous designs and patches) and is literally advised to be used as only through libraries and frameworks
I think most responses to his posts are missing that this is the most important part:
> In practice, the only thing that makes web experiences good is caring about the user experience — specifically, the experience of folks at the margins. Technologies come and go, but what always makes the difference is giving a toss about the user.
> In less vulgar terms, the struggle is to convince managers and tech leads that they need to start with user needs. Or as Public Digital puts it, "design for user needs, not organisational convenience"
This is the most important thing. The entire article series is making this point in great detail, and also being very angry at orgs (especially public services!) that don't get this.
I think this message does get a bit buried under invective against React. Surprise surprise, if you do start with user needs, then sometimes that does lead to you building a React-based SPA. I think from Alex's perspective working with organisations, looking at it from the other direction: for any given React SPA, it is unlikely that React was chosen because of user needs.
The problem is that this fundamental claim undermines the entirety of the argument. You can build a good web experience in React if you care about the user experience.
I don't find the argument to be undermined by this. From my perspective, his strong statements against React read as deliberately lacking in nuance just like the conventional wisdom of "just use React and don't think too hard about it". It's a deliberate overvorrection away from the status quo. There can be room for nuance once the default assumption has been shaken.
I get why people are offended or find it unhelpful. If you read through his Reckoning series, I hope you'll understand some of the righteous anger he has for organisations that fail to serve the user, even when public service is their explicit purpose.
Blaming it on React may not be the most effective strategy. Who knows. But I still find value in the message.
"In short, nobody should start a new project in the 2020s based on React. Full stop."
He lost me. My React web app of medium complexity is statically exported and gets cached by the user's browser. All the data it needs for the main page is fetched by a single graphql call. The UI code renders in less than 10ms even on old machines. Network and the backend are the primary bottlenecks for me.
Could I redesign and rearchitect it such that the frontend is very slow to render even on modern machines? Yes, quite easily. And I suspect, many people complaining about React's performance are doing just that.
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.
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.
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:
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.
... 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.
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].
Apart from running screaming in the opposite direction from tagged templates for security reasons, I think a more suitable approach (that fits current ECMAScript naming conventions / namespacing) might just be something like:
You can already effectively do this, though you'll have to decide for yourself if putting the following lines of code into a top-level module translates to "Writing your own framework":
import html from "MyModule"
const content = html`<h1 id=hello>Hello world!</h1>`; // No New API Needed
document.querySelector("#container").replaceChildren(content.childNodes)
You're losing the pretty printing in the console but there's options for that -- from tweaking the toString() prototype method to straight up creating a custom class that acts as an Element.
Worth noting too: you could cheat in the html function above and have it directly return content.childNodes, thus reducing the differences between the two examples to simply "patch" vs "replaceChildren".
In your example, are you envisioning that HTMLElement.patch() is doing something different than Element.replaceChildren() or Element.replaceWith()? That'd be one area that wouldn't be addressed with this.
Having it first-party would be lovely but it's already pretty doable.
All of what I'm talking about is doable through libraries today (or you can write it yourself). But making things available through DOM APIs create a new baseline where the very same tools are made available for anyone, no matter the framework (think: document.querySelector APIs).
Regarding patch, morphdom explains very well the difference between replacing and patching the DOM [1]:
> Replacing an entire DOM tree is fast but loses internal state (e.g., scroll positions, input carets, CSS transitions). Instead, we aim to transform the existing DOM tree to match the new one, minimizing changes and preserving state.
Also, there's the matter of performance. Diffing and patching as a single method call implemented natively should be a lot faster than using a bunch of JS code.
I agree on the point of first-party, as I already wrote.
I suspect there would be a lot of edge case footguns in trying to write something like patch() that tries to crawl the content as a diff and make only the minimal changes. Things like events being bound incorrectly to elements, what to do when the structures of the old and new don't match in some breaking way, etc.
Not saying it can't be done but I suspect it's more complexity than we think of typically when using a term like patch. Some of those items (such as transitions) can be pretty straightforward to deal with already.
> Also, there's the matter of performance. Diffing and patching as a single method call implemented natively should be a lot faster than using a bunch of JS code.
Performance and the DOM (especially as typically deployed in an SPA / the "modern" web) don't really go together already, so I'm not convinced that's a particularly compelling argument. Making it first-party on its own is already that compelling argument IMO.
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:
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).
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.
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).
WebAssembly can't do anything without Javascript. You're still using the same annoying Web APIs with another layer of indirection between. Plus, now you're using the slow Rust compiler so your iteration times are going to suffer. We already have type-safety in Typescript. We don't have to care about lifetimes, either.
Agree that WASM cannot yet directly manipulate the DOM. But are build times in JS/TS framework world any slower than Rust compile times? I'm not convinced on this point.
As a disclaimer, I still prefer vanilla JS and progressive enhancement.
TS is very fast with esbuild and the likes, it's basically just stripping off the type annotations. Your setup may vary, of course.
The other point isn't so much that there's a wrapper around the DOM, but that the DOM API itself is bad and slow. There's only so much pain a better language can take away here, and Rust isn't even a better language for that domain.
> WebAssembly can't do anything without Javascript.
But it's JavaScript glue code generated by Rust's wasm-bindgen that you don't need to care about. And eventually the glue code will be unnecessary with wasm component model DOM access.
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.
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.
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?
* Accessibility tools may not be able to detect that it's an interactive element unless you go out of your way to mark it up as such
* It often (always?) breaks middle-clicking/opening in a new tab. In your navigation example is fine, but for example in Jira it's an absolute crapshoot which links will behave properly when middle-clicked
* We already have a tag for a clickable element that is not a link: <button>
Good points, but I think you and the others who responded to my question are thinking about "web pages" vs what I generally create, which are responsive mobile PWAs for internal line of business apps.
> Accessibility tools
Not all applications are created for accessibility, it depends on the app and the intended audience. While in a perfect world we'd all be section 508 compliant, cash strapped startups frequently aren't in a position to invest in that for MVP.
> It often ... breaks middle-clicking
Do you use the same standard for a native app that you install from an app store? Almost everything I've written over the past decade or so has been "web tech as a replacement for native" - not a public web site, so the function comparison should be against native apps. I probably should have mentioned that in my original question.
> We already have a tag for a clickable element that is not a link: <button>
Sure, but I don't think it always makes sense semantically or from a code standpoint to use the button tag. For example, maybe I have a tiny little plus symbol for "expand". Like a lot of folks, I generally use some like font icons, or material symbols for stuff like that. Frequently it makes more sense to use a span or div to render the icon, and just handle the click event.
I'm not advocating for the use of divs instead of "a" tags everywhere, I just think there are normal and reasonable situations where it makes sense.
All engineering is a series of compromises and trade-offs. I'm not going to judge a dev that makes an info icon work to slide out a drawer which has a tabbed sub-nav, because they didn't hammer an A tag into something that it wasn't intended for, or because they didn't want to try to make whatever font icon library they're using work with a button tag.
Do you religiously check that you haven't broken ctl-click, middle click or "right click/open in new tab"? I come across a site - sorry I meant "app" - almost every day that breaks this.
There's nothing wrong with clickable divs. The problem is using them in place of links.
If you're linking to something, then just use a link. So people get their accessibility/screenreader support, and you can still use JS to accomplish whatever other auxillary behavior you want.
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.
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.
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.
Another thing is that almost every complaint I see about React (except bundle size maybe, but who cares?) exists in the APP context.
If your use case is a simple website, React is just a nice templating lib and you won't need to use any of the things people generally dislike about it. That AND your experience when you inevitably have to add some interactivity is going to be 100x better than vanilla JS.
As for the build step, there are many turn key solutions nowadays that "just work". And isn't a small build step a plus, compared to being at the mercy of a typo breaking everything? To me that piece of mind if worth a lot, compared to whatever manual testing you'd have to do if you work with "text" files.
Are these templates only used on the server-side to generate the HTML upfront? Or is it being generated on the client?
> experience when you inevitably have to add some interactivity is going to be 100x better than vanilla JS
I don't believe this can quantified. How are you measuring DX improvements? Are you also able to continue to measure these improvements as your application/codebase scales?
It's certainly possible to generate the HTML up-front. Tooling like Next.js even sets things up so it's easier to render the HTML for the first page load on the server than to push it to the client.
I have a website. It's not great, it doesn't get much traffic, but it's mine :). If you disable JS, it works: links are links, HTML is loaded for each page view. If you enable JS, it still works: links will trigger a re-render, the address bar updates, all the nice "website" stuff.
If I write enough (and people read enough) then enabling JS also brings performance benefits: yes, you have to load ~100kB of JS. But each page load is 4kB smaller because it doesn't contain any boilerplate.
Obviously I could generate the HTML any way I choose, but doing it in React is nice and composable.
If you really want to, you can have a react app that is just static templates with no interactivity with a simple Node server that just called renderToString and all of a sudden react is just a backend templating framework. If you want to get really fancy you can then re-render specific components on the client side without re-rendering the entire page. You don't need NextJS to do this either, its very simple and straightforward and lets you use an entirely frontend toolchain to do everything.
Building a web application with a UI in a professional context without a frontend build is borderline malpractice. Even a "thin" layer of JS on top requires some degree of dependency management, and I personally have no desire to go back to the days of vanilla CSS, so you need a SASS/SCSS transpiler. Then there's a lot of handy things that frontend builds do, like normalizing SVG icon formats, automatic organization of static assets etc. The fact is the "islands of interactivity" model still requires two builds.
Nowhere in my comment did I say abandon a build step?
I’m saying—if you do not have high interactivity requirements, which I would claim is most things on the web—you will encounter a lot less overall complexity shipping mostly server-rendered pages with isolated, self contained JS bundles where you need them.
I was using multi-entrypoint build steps outputting separate per-page or per-feature CSS and JS bundles long before I ever worked on an SPA, it’s hardly a good reason to move your entire UI and routing to the client-side.
What's rendering the pages on the server? Because if its not javascript, and you still have a frontend build, you have a repository with two separate builds, and builds are expensive to maintain. If your containerizing, you need two different containers, each with a dependency management system, a runtime, probably a separate workflow for development and production.
There are many ways to render pages on the server using a single JS builds, most template rendering engines have a node implementation, and most javascript frontend frameworks have a mechanism to render components statically to a string. If we're talking about a simple, mostly-static website, the content is going to be cached so the performance of the backend isn't a huge factor. So just use JS for the whole thing, and save yourself a build.
What does "most sites" even mean? I do this professionally, and I assume that most of the people replying here do as well. The article we're discussing is written by a professional for an audience of professionals. The number of sites I've had to build that were entirely static with no interactivity I can count on one hand.
Very funny that you think a build with an entire CMS involved is somehow "simpler". You apparently have a lot of patience for Django's static asset management pipeline, but I do not.
Modern CSS has _some_ of the features of SCSS/SASS. It does not have all of them. But most importantly, many of dependencies one might want to use also make use of SCSS/SASS downstream. If you're happy to build everything from scratch and eschew any dependencies that require a build system, then have fun explaining to your product person why it took so much time to build a thing that they know very well is a pre-built component in some frontend library somewhere.
> Modern CSS has _some_ of the features of SCSS/SASS. It does not have all of them
You say it like more those features are desirable.
> then have fun explaining to your product person why it took so much time to build a thing that they know very well is a pre-built component
Sure. I wasted more time getting an assortment of pre-built components to behave than I did building the basics from scratch. And then comes a breaking change. And then that component library uses styled components and doesn't run properly on the server. Why do people do this to themselves?
> Any web application with a UI _requires_ a frontend build for CSS/JS.
Except it really doesn't. Core web technologies have gotten so much better since the jQuery/pre-SASS days that you can absolutely get by without a build step.
- http/2 makes bundling a questionable choice
- polyfills are pretty much no longer a thing
- CSS now has most (all?) of the features that people used SASS for (variables, nesting, etc.)
- es6 modules work
This has been a big talking point in the Rails community lately — one of the big selling points of Rails 8 was the fact that you can, by default, ship a whole webapp without a build step, and that this is considered the "happy path".
In web application terms, the "build" is everything that needs to happen to get your application running into production. That means a runtime and dependencies. Speaking of dependencies, does your perfect frontend simply not have any of them? Is every tool you will need to use perfectly packaged with vanilla CSS and ES6 modules? Browser support for import maps is around, but its nothing I would build a production application on. And god help if you if you work in a context that requires support for older browsers.
Maybe in 5 years this will be a practical approach, but there's a reason that old ways of doing thing hang around: they're well-documented and reliable.
I mean, people ARE doing it, and like I said it's mature enough to be the default way to build Rails apps. There's tradeoffs, no doubt, but this is absolutely a valid, productive way to write (certain types of) web apps.
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.
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.
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?
They’ll love something that loads fast and feels fast even if they’re on a cellular connection at the gas station. Such as me trying to load a gas station app to pay at the pump in a rural area and waiting forever for each step due to the size.
I'm having trouble forgiving Vue for the backwards compatibility issues and short support period from Vue 2.x => Vue 3.x. I'm now faced with unnecessary cost to upgrade line of business apps built with Vue that in full maintenance mode but now have critical security vulnerabilities popping up in scanners with no way to fix them other than large scale code migration. I saw they are now dropping support for Vue 2 even in the DevTools, so even migration is going to be harder, if we can't easily introspect the pages we are migrating.
I'm suspecting they are going to drop backwards compatibility again in the near future by deprecating support for the options API - leaving me with another headache.
That's actually fair and my one gripe with Vue, and I just spent the past week and a half porting over my old project that I wanted to resurrect. If they screw with my vue3 using composition API then I'll dust off my pitchfork.
Has gitlab finished upgrading yet? Last time I checked they spent 2+ years and that’s with codemod tools and super smart engineers.
At work, I spent a month upgrading one project to work with the compatibility build and we’ve been slowly migrating for the past 18 months. After the end of this year, we should be out of the woods for that project but then we have 3 more so…
Luckily, Evan has said that he has zero interest in fracturing the community again and I believe him. The new architecture of Vue 3 also makes it very easy to adopt almost any new paradigm into Vue as evidenced by the numerous demos Evan has made to compare Vue to other JS frameworks like Svelte and Solid.
What I like about React is that generally speaking, it has rock solid backwards compatibility support (class components are still supported for example), presumably due to Meta using it at scale such that they cannot scrap everything immediately. Vue, being not used in any large company, does not have the same sense of responsibility to preserve backwards compatibility, it seems. This has its pros and cons though but for many people, backwards compatibility is a big deal.
I started with Vue and switched to React, because of better library and TypeScript support. Every other framework pales in comparison to React due to its ecosystem, and I'm not gonna spend time building new packages to bridge that gap when I have my own work I need to get done, so I'll just use React and npm install what I need.
Back when I switched, I was looking for a good drag and drop library as well as a node based diagramming library. React Flow for the latter is best in class, and it's simply unavailable for other frameworks.
To me, the best part of react/jsx is that if you know HTML, and you know JavaScript, you can easily write JSX. I'm primarily a backend engineer, but I grokked JSX pretty much instantly. Anything in scope in JS is available in the JSX.
Vue templates are, well, yet another funny little template language. The hello world example already seems way too magical. Just let me use the language I already know.
Fun fact, you can use JSX with Vue and get the benefit of its built-in reactivity framework. I've done this for small prototypes and it's quite nice. My favourite part was that without .vue files, I could compile the whole app using esbuild instead of fiddling with webpack (yes yes I will try Vite one day).
I think i'm passed splitting html, js and css into separate files.
Having logic, presentation and styling all in one spot addressable via js and jsx feels so much more ergonomic for apps of reasonable complexity.
I will say though that solidjs seems like an improvement on react though.
Amen. I adopted react for the first time in around 2014. It’s now “boring” and various predictable groups of people are desperate to replace it with /something/, while I’m getting on with my job of delivering software using a nice set of reasonably standardized tools, not having problems hiring, and just generally enjoying life.
Long may the reign of typescript, nodejs and react continue.
Last time I looked at react was 2016 or so and every tutorial was referencing some different mutually incompatible version of some component (router, redux, flux, some other alphabet soup) and everyone had their own list of essential ingredients in a basic hello world app. I came away from the whole experience thinking here’s an ecosystem that needs to mature another 10 years or so before I want to even look at it (I’m not a frontend person, it’s all academic to me.)
Is there a consensus on any of it yet? How to do routing, state, builds, etc? Or is there still as many combinations of components as there are tutorials?
Routing: react router (not very good imo but widely accepted and good enough)
state: No libraries. Just use “useState” and if necessary “useReducer”
Builds: vite
Then pick a query caching library so you don’t need to treat fetched data like its application state… ReactQuery is widely accepted and very good. Apollo if you’re using graphql
I'd throw in the occasional context provider store. However, the point absolutely stands that most likely don't need a state library in React anymore unless you're learning it to maintain an older codebase.
> Routing: react router (not very good imo but widely accepted and good enough)
Unnecessarily complicated and confusing, with odd choices in the most recent version (that IIRC are not backwards compatible). I went with wouter after searching around.
> state: No libraries. Just use “useState” and if necessary “useReducer”
useState is the same thing as the old setState, and useReducer not much different - they're not sufficient for building an app because you just revert back to the original state antipattern, prop drilling.
I don’t see how prop drilling is an anti pattern. Passing data around via props is a feature of the library, it’s totally fine if you need to pass a lot of props.
If you really have too many props or need to widely disperse the same prop you can refactor using higher order components or use a context. A separate state management library isn’t necessary unless you are building something with a ton of complex UI state like a photo editor or a music production workbench.
Prop drilling refers to depth, not width - you had to add the props to every intermediate component between where the state is stored and where it's used. Some of us tried to come up with nested usage patterns so at least the intermediate components didn't need to know about the structure and it wouldn't be a pain when moving things around, but it still wasn't very good.
> with odd choices in the most recent version (that IIRC are not backwards compatible)
This exact sentence could have been said about react router 8 years ago when I last looked at react, lol. And IIRC it was react router that turned me off the most, as every react tutorial that stressed working permalinks/URLs (which I believe to be essential) was teaching me react-router, but with sample code that was incompatible with the latest version. Because documentation and tutorials would last like a month tops before they were all horribly broken and out of date. Sounds like this hasn’t changed much.
The best way to learn a library is to learn it by itself without bringing in other things. I encourage you to learn React without any router, redux, or any alphabet soup indeed. Don't even need a build step, since JSX is optional.
Have you heard of HTML, CSS and forms? They are even more boring, more mature, more stable, often faster, have a huge community, massive resources and ecosystem. React is even built on one of these technologies!
Back in 2013 there was a nifty little library that everyone, absolutely everyone ended up using called https://vanilla-js.com. They even had a size calculator depending on the features, amounting to zero bytes every time (25 bytes gzipped).
Java is way way better than React (hooks) in this regard. Boring tech is good, but React is the opposite of boring tech, it innovates new way to write software, but ends up in disaster.
755 comments
[ 1.9 ms ] story [ 408 ms ] threadOh, and the author would like to kindly point out that React is legacy now. Because they said so. In case you didn't know.
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.
I was not able to notice any difference between them
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 ?
Software engineers tend not to experience the web on the same class of device as most of their users.
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.
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?
Note most of this is nonsensical too.
His primary thing is "you don't need client side code because JS = (HTML + CSS) * x, where X >= 1"
We can start sneering about not caring about users there, too, having a one time client side download of that magnitude can certainly be much better on the poors than 10 page loads with SSR.
I have a newer iPhone and Safari is still full-refreshing pages constantly due to memory.
With utmost respect, that's not what I'm saying :)
I hold no hot take position on anything web dev, or any firm declarative position.
What I'm trying to get at is, indicia of an article being half-baked includes things like asserting all that's required to agree is to care about the user.
This feels good to say, but doesn't say anything, other than there's been at least some short-circuiting of thought. We can come up with many trivial cases where "caring about users" involves requiring client-side logic during rendering.
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.
If you struggle with backend code then you’re just not a good backend developer. Maybe just stick to HTML/CSS.
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.
"In short, nobody should start a new project in the 2020s based on React. Full stop."
What about the rest of them?
that is neither here nor there. you are replying to an article whose thrust is that react ought never be used.
> Somewhere that’s actually an application might
might, lol? wait are you the author?
> most line of business applications would be better as something like Rails views rather than React
why?
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.
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.
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.
As for the article, honesty probably would have just had the author write something like: "RN: an unfortunate but maybe your best choice in these circumstances" instead of pretending there's serious alternatives eg the Apache garbage dump.
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!
That's covered in this section: 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...
https://github.com/brillout/awesome-react-components
This point is not directly covered in the article.
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)
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
It isn't? I find React to be great to work with.
Most importantly, it’s also not particularly performant on the client side in real-world scenarios.
For evidence, here’s a guy testing major websites using his awesome react-scan tool: https://x.com/aidenybai/status/1861442057598062653
I think last year an Amazon frontend engineer wrote some tweets explaining they tried React and it was too slow. So they keep using Java for SSR and sprinkle vanilla JS. They were still using jQuery until a couple of years ago and probably still are in some parts of their site.
Someone is contesting that "frameworkism isn't delivering" when we have objective data to prove that it is in fact not delivering.
The Amazon store is just a good example because there's a lot of data about it, not because it's FAANG.
Please help me understand where I misunderstand
"No, trucks are good for X"
"Look at this use case (Amazon) with tons of objective data that shows that trucks are bad for X"
Are you arguing that web devs should ignore CWV for e-commerce sites?
The Amazon site is pretty ugly, yes, but it’s functional and fast.
But there's no inherent reason React couldn't be used for a page that basically shows pictures of products with a description next to them, the bottlenecks will have nothing to do with the frontend in a well engineered system for that type of site
Even freaking Google (who really should know better) suffers from that. Amazon's retail frontend uses plain HTML, so it works fine.
It's way too easy to put some state information into the context and then have your pages depend on it. For example, you have a page with a filter that is implemented via a simple state, and then a list of widgets that pass the filter. The widgets have a click handler that opens the widget details.
Now you right click on it. If you're lucky, it opens the widget details in a separate tab. However, the filter information is lost.
^ These two statements are at odds with each other.
React will return a pure browser link that behaves exactly as a browser link:
> The widgets have a click handler that opens the widget details. > > Now you right click on it. If you're lucky, it opens the widget details in a separate tab. However, the filter information is lost.So, the problem isn't React. The problem is people overriding default browser behaviour for their widgets. It was a problem before React, and it will be a problem long after React.
For example, here's Google's premier site about web technologies: https://web.dev/articles Check out the pagination links at the bottom. There's no React on the page
No it doesn't (in practice). React is typically used with something like React Router that takes over the whole sub-tree of paths. So links are handled by the single-page app itself, and this can lead to the state leaking through.
Yes, you don't _have_ to do it this way.
Yes , yes it does, in practice.
> React is typically used with something like React Router that takes over the whole sub-tree of paths. So links are handled by the single-page app itself,
"Taken over by Router", "handled by SPA itself" .... "React is to blame"
> Yes, you don't _have_ to do it this way.
Yes, you don't have to it this way, and this isn't React-specific. See Google's web.dev site built with web components
Links work fine, out of the box, react treats them the same way vanilla js does. JavaScript onClick events aren't links, and that's true whether you're using react or vanilla js.
> It's way too easy to put some state information into the context and then have your pages depend on it.
What do you mean it's too easy? If someone makes poor engineering choices because that's the "easy" thing to do, that's their fault, the tool didn't make them do that.
> Now you right click on it. If you're lucky, it opens the widget details in a separate tab. However, the filter information is lost.
This is true of JavaScript in general, it has nothing to do with react. In order for links to work, the server has to render pages that correspond to the link, whether that means encoding state in the url or pulling it from a session, this is required whether you're using react or literally anything else.
Just like how routing and history is “solved” but I encounter websites every other day that completely break my browser history.
I don't think that's true. More likely, you use react websites all the time and don't even think about it because the links work as you expect.
I worry that most people complaining here about React, including the OP, do not actually understand the very basics of React. Here someone is complaining about how React somehow messes with deep links. Without understanding that React does nothing to links. Nothing.
I'm discussing the retail site specifically because that's where CWV matter.
If a company has internal tools that take seconds to load it doesn't really matter. Captive users don't have much of a choice.
E-commerce is fundamentally small data once the user lands on a product page, so every subsequent link and click should be instant.
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.
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.
This is one of the reasons I think hooks stink. It seems like they tried so hard to avoid using classes that they came up with an opaque, framework-only way to manage state so that they could declare "ha! Stateless functions at last!". The state's still there, it's always gonna be there, it's just now hidden behind an abstraction that has a few footguns.
2. Sorry but if you keep using "weird", "hard" and "complicated" adjectives to define something that is quite honestly not so hard to grasp you make it hard to not go with "skill issues".
I’m using weird and hard in a relative and not absolute way. Weird because functions can’t have state, and for years we’ve been taught to keep functions small and predictable. Hard because there are much simpler ways to write stateful code other than hooks. The problem with react is that instead of creating a powerful state library, powerful ui library, and creating a bridge between them, they chose to subjugate the state library to the UI library’s limitations.
For example, `api.fetchInfo()` would want to feed Loading | Success(T) | Error(E) back into the React component call-site when they change.
EventEmitters come to mind but aren't without their own issues like subscription leaks. And you have to track component arguments in order to know when to call the service again when they change which is a classic source of complexity.
Hooks provide a solution for this since they themselves are just nested React lifecycle constructs (like useState + useEffect).
Of course, the class component solution to this was to use an HOC, but that had its own issues like complex data flow and wrapper hell.
Hooks solve problems of composition without Yet Another Wrapper and they give clearer data flow, better ref forwarding, etc.
It's easy to see complicated useEffect spam and blame hooks but frankly that wasn't any better when it was happening at different layers of HOCs.
1. you can still write class based components if you want, but if you are in a team everyone will hate you for that because... 2. the preferred and vastly more flexible and powerful way is functional components. That's it, there isn't any other way or any other mystical layer of magic.
What everybody in this umpteenth omfg-react-is-satan thread is that implementing complex things with simple things is a fucking pipe dream. Fucking deal with it.
"Fucking deal with it?" What are you, a cultist? I answered a question here, fuck off.
https://overreacted.io/making-setinterval-declarative-with-r...
It has never went anywhere? All it takes is a user brave enough to disable it or to use a web browser that doesn't use it or has issues with it. But for some reason many web devs actively ignore that.
However, I think any new paradigm is difficult starting out. Recently I've been learning OO for work and I've been finding it stupidly hard and entirely unintuitive.
It feels like a clever proof of concept with a leaky abstraction at its core, one that no amount of effort can truly fix, no matter how much they throw at it. They’re even building their own compiler. A compiler. For something that’s supposed to represent the V in MVC.
As a SPA framework, it’s questionable. But using React to build server-side apps? That’s beyond absurd for me, it’s like Electron for the backend, only worse. And yet, the industry loves to pretend otherwise, so here we are.
Why people are so keen on stabbing themselves just because there's one or two weird shaped forks in the kitchen drawer. Why do suddenly everyone tries to use it for spreading butter or peeling eggs?
Just understand what unidirectional data flow is and you are golden. You know the entirety of React you should be using for your first year of full-time job.
As for your question, “Why does everyone suddenly try to use it for spreading butter or peeling eggs?”
I guess part of the reason is that many people rely on older tutorials and patterns where the usage of useEffect was much more tolerated or even encouraged as a catch-all solution. There’s still a lot of inertia from the old componentDidThis/componentDidThat paradigm, with useEffect being its direct replacement.
I feel it is only a recent tendency to finally abandon the overuse of effect hooks.
Just open an average Stack Overflow React question, and you’ll see how many useEffects are crammed in there.
It was so easy that people strived very, very hard to make it seem complicated - and they succeeded. Back in the day every React tutorial layered in soooooo much other stuff, Redux and a million middleware layers that completely obscured what React was.
The core of React though is really simple and no amount of attempts at complexification can destroy that.
Hooks is really one of those things where you need an IDE to tell you that you’re doing it wrong, since there’s a whole bunch of footguns. It’s doing its best to solve a hard problem inside the limitations of JavaScript, but it is essentially a kludge.
Just like in Flex the difficulty (and don't get en wrong often extreme awful difficulty) comes when someone fights against the system and can cause a cascade of terribleness. There were always telltale red flags when looking at Flex code when someone tried to circumvent the component lifecycle and the same smell can be spotted in React code.
Would it be fair to say in which case that React shouldn't be a tool teams reach for unless they have people who have mastery of it or can pay for it?
> user won't be able to tell the difference.
I think the user can:
https://infrequently.org/2024/08/object-lesson/
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.
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.
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.
https://rescript-lang.org/
I build all my react this way.
No prop drilling, no Redux, no context, no mobx no state.
If you need to communicate between components then send a document event.
Your react application will be dramatically more simple without state.
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.
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.
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.
1. to birdlime
2. (reflexive) to get bogged down
maybe you would expand on this? I have no intention to challenge you, just genuinely curios if and why I should consider vue over agnular for new project (I use angular already).
SO trends show that angular is more popular, while vue is loosing share (not necessary absolute number): https://trends.stackoverflow.co/?tags=angular,vue.js,reactjs
However I think the "drop off" in the chart for React is misleading/incorrect, and likely indicates just a slowing down of the economy and/or people moving to LLMs for their searches and abandoning StackOverflow completely, as I have.
For the past year I haven't yet found a question that an LLM couldn't answer better than S.O. could, although ironically most of the LLM learning did come from S.O.
Anyway, yeah shops will stick to their legacy code forever unless something forces change, because retooling is super expensive in money and time, not to mention replacing all your developers with different ones!
IMO right now it’s easier to start an angular project with much less foot guns than react.
What I mean by dead is it's a VERY unlikely choice for any new app. People will choose React or Vue most of the time. You don't see Angular used hardly ever for a new project.
BTW: Vite is the new best way to manage the build pipeline, and makes React super easy to start using.
Fortran certainly has its issues with portability and feature development, but it is by no means dead.
And your drill press example is agreeing with me, which is that, as I also already said myself, no one needs to have ever used something to be able to declare it dead, nor did I declare something dead because I don't personally use it. That's absurd.
[1] https://w3techs.com/technologies/details/cm-wordpress
https://developer.chrome.com/docs/web-platform/view-transiti...
Yeah, but it ain't. lol.
Users don't care how it was implemented or how nice the code looks, they just want it to work.
By your measure though, it sounds as though you'd be fine if these page loads in the javascriptless world were done in iframes, since then only some portion of the site is being reloaded?
I'm using that to illustrate the argument is absurd and the basis on which it is made seems also absurd.
SPAs are heavy and frequently written poorly, often eschewing the principles of loading only the bare minimum for a kitchen-sink approach. If you view the web as having only those two options to accomplish "real work" then yeah, you're gonna thing that SPAs are the only way. It's not reality though.
In my experience, these apps are rare, yet SPAs are prevalent. Which is a problem.
It would be nice, from a user perspective, if boring "apps" that are mainly forms and tables would quit it with SPAs already.
Making an entire application a single page load and then some API calls sounds attractive when your application is small to medium sized in terms of complexity. It runs into problems when complexity or feature count pass a certain point.
However the reason my Dialog Boxes open in a millisecond, and close in a millisecond too, is because I choose to render them locally. I'm not against SSR tho, as a viable concept. That's a different complex discussion where there are trade-offs to consider.
The options you present are: "either use a JS framework or don't use JavaScript at all". That's a false dichotomy. I've built plenty of interactive apps with JavaScript without using frameworks.
And once you reach sufficient project complexity, you will end up with just another homegrown framework, with all the lessons learned by mature frameworks, left to be fixed over the next 5 years.
Yes it is. App.js is all the code there is. You can't count the two other files with 10 lines each. lol. Let's be honest here.
And yeah for a tiny toy project like this you can get away with having zero design, zero architecture, zero object models, zero classes, and sure since everything is zero, we can throw in "Zero TypeScript" and "Zero Frameworks". Looks like some high-schooler's first ever coding project.
No, it's not. Chatbot.js is 3400 LOC.
There's literally only 4 JS files in the whole repo and you couldn't be bothered to check how much code they have? Even after I told the other guy who made the same false claim "no, it's not a single file codebase"?
Jesus you people are insufferable. So obnoxiously confident while being wrong about easily verifiable facts.
> tiny toy project
Huh? 99% of web development is about rendering text and images. This project is moving your mouse inside a web browser & provides a plausible chat experience without a language model. That's more ambitious than just about any actual work project I've seen.
What people are saying is that for LARGE projects you NEED a framework. And your app is tiny. It's got like two source files. So it's just an example of a tiny project getting by without a framework. I have a couple of those currently myself, because I don't need a framework for them. They're just HTML+CSS+JS.
https://news.ycombinator.com/item?id=42282054
"brochure-ware"
B-R-O-C-H-U-R-E-W-A-R-E
I was willing to assume good intentions from you earlier, but at this point it's clear you're just lying. You've seen the number of files in the repository, we already had a back and forth and you already conceded there was more than one file. And yet here you are, reiterating the same lie. Weird stuff.
If the same app had been written by a typical team of React devs, it would be >1000 source files and 50K LoC. That's not an argument against my approach, it's an argument in favor of it.
a codebase with a 1300 line file.
I mean if I need to change a variable name in a class or something, unless it's a perfectly unique name (easily searchable), it would take me hours to do in JS what I can do in 4 seconds with TypeScript.
The claim upthread was that you couldn't make a web app at all without a framework ("or it would just be a document"). I said yes you can and the goalposts shifted to: sure, but only "brochure-ware" (referring to simple unambitious projects). I show an ambitious interactive project made without a framework and now the goalposts are moving to: sure, but large distributed teams couldn't work like this? You know, this solo project is more ambitious than 99% of the projects I work on at my actual work. You know, projects that have 10, 40, or 100 devs working on it.
Sure you can develop very large projects in JS, as long as you don't mind being 1% as efficient, and having 100x more bugs. In JS, refactoring a huge project is the biggest nightmare in the world and really no human is capable of doing a great job of it in a reasonable time, even if they have a high IQ and decades of experience.
Any language that lacks type-safety is completely inappropriate for large-scale projects. There's no seasoned developer on the planet who disagrees with that sentiment. None. Zilch. If some guy claims to be #1) decades experienced and #2) doesn't like type-safe languages, then he's lying about either #1 or #2 or both.
But there are some things that are obvious to any seasoned developer and the value of type-safety is one of them. It's not my opinion. Is a fact. And yes if you say you have 10+ yrs and you don't prefer type-safe languages, then yes I indeed do not even believe you.
Have you heard of Python by any chance? Pretty much the entire field of data science is built on top of a dynamically typed language. Plenty more seasoned developers working in that field.
If Python was just fine without type-safety that's how everyone would have kept it.
This is another lie from you. A vanishingly small minority of Python developers is using "every type-safety feature available to them". Not that it even matters to your earlier claim, because Python is not a type-safe language even for those developers who are using "every type-safety feature available to them". You claimed earlier that "Any language that lacks type-safety is completely inappropriate for large-scale projects" even though you seem to be aware of the fact that "seasoned developers" are using Python for "large-scale projects". So, again, you're just lying.
Python developers simply tolerate the lack of type-safety only because it's a trade-off to get other things the language has to offer. I agree there are trade-off decisions being made.
> For any large project you need type-safe languages. 99% of experience developers (10+ years of experience) will agree with this opinion.
Clearly, more than 1% of experienced developers choose Python, despite it not being a type-safe language.
You don't believe what exactly? Don't believe I have 10+ yrs of experience? You can see that my GitHub account has activity from the past 10 years, so... you don't believe I prefer dynamic typed languages like Python? You think I actually prefer static typing and I'm lying about that? Like what?
Oh, and it just so happens that Python was the most popular language in the 2024 StackOverflow survey: https://survey.stackoverflow.co/2024/technology#2-programmin...
I guess literally none of those people were "seasoned developers" either, and none of them had ever worked in a "scaled" and "large" project, like you mr big man.
Me: "Seat belts are important."
You: "Awfully funny considering our major car accidents these days are mostly all ones with seat belts."
You're implying a nonsensical causation that's purely a correlation.
If appeals to the status quo were reasonable arguments, there would be no room to improve on what is.
https://en.wikipedia.org/wiki/Argumentum_ad_populum
The more popular a piece of software is, the more likely it is to have had the bugs worked out of it, the more people there are reporting issues, the more answers there are on StackOverflow, the more likely AI/LLMs are to be able to answer questions, the more secure it's likely to be, the more stuff interoperates with it, etc. Popularity alone isn't a good reason to select something, but it's a good data point, with which so judge viability.
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!
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://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.
> 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.
In my experience, regardless of your skill at communication, coworkers or bosses that are actually interested in getting to deep knowledge or detailed analysis about anything are extremely rare. If you need to communicate a subtle point or detailed argument, then you’ve already lost. This is because for any technical decision the opposite argument from FUD is easier to make and easier to digest, regardless of whether the FUD advice is to stay/defect on the tech stack or the design decision or whatever. IOW the winning strategy is basically to always go 2nd after what TFA calls the “thoughtful engineer” burns out the audience by being rational and thorough. Even more bluntly.. most people are just showing up to work and have no interest (and much less passion) for craftsmanship.
I wish it was different, since I believe in architecture / design. But, there’s a good chance no one cares about your detailed analysis at all and you’re much better off producing more shallow demos/diagrams/decks regardless of whether your audience is engineers or management.
My only quibble is that it’s certainly possible to choose React (or any popular solution to a problem) without considering other options too much, and still care about craft.
I agree! In general, people are resistant to change, period. Some are particularly wary of facts and logic (see: politics). Successfully getting points across, even when one "is right," often requires a lot of strategizing and non-technical effort.
Whole books have been written on this subject [1]. For those attempting to navigate the challenge, just remember that it's all too easy to burn out in the office while "chasing your ideals.". Doing this while keeping your sanity is an art :-).
--
1: https://pragprog.com/titles/trevan/driving-technical-change/
(non-wrapping extra long lines have not helped but maybe that's on my user agent)
My rules of thumb:
* informational website / blog - static frontend (Django! :heart:)
* some interactivity - htmx
* a lot of interactivity (app that happens to libe in the browser) - spa (React and weep)
For a very strong assertion he makes (even if you need spa, react is obsolete), he dismisses finding a good alternative as an exercise to the reader. The ones listed offhandedly in a side note look all the same (as react) to me.
The sad part is that it's the same increasingly hostile arguments he's making while he spent the decade making sure that browsers remain bloated and tech requires Javascript to even barely function: see his entire work on web components.
> 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
He's not the only one speaking about web performance, or doing research. He's not Casaandra. At best, he's a false prophet.
His series on web performance gaps is good, though.
I'm confused by this characterization of web components. While they can minimally work without JS now (i.e., declarative shadow DOM), the whole premise builds atop of how the web and the browser works, and that is progressive enhancement. Your browser starts showing you the content before all of the content has finished downloading, and as it finishes, it progressively enhances the content of the page. Web components is a part of that story.
Why do you want web components to work without JS? Do you also put the same constraints on frameworks?
Of course not. They need Javascript to participate in forms (though a button on WCs still can't work as a submit button), they need JS to handle global styles, they need JS to handle ARIA (there are at least two different proposals for this), they need JS to fix text selection etc. etc.
Nothing in web components two dozen specs builds on top of basic browser functionality.
> Why do you want web components to work without JS? Do you also put the same constraints on frameworks?
That's bot what I wrote. I'm calling Alex Russel's hypocrisy. He's ranting against web frameworks while he's spent the past decade creating tech that needs more and more JS for basic functionality (and more JS to fix issues previous designs and patches) and is literally advised to be used as only through libraries and frameworks
> In practice, the only thing that makes web experiences good is caring about the user experience — specifically, the experience of folks at the margins. Technologies come and go, but what always makes the difference is giving a toss about the user.
> In less vulgar terms, the struggle is to convince managers and tech leads that they need to start with user needs. Or as Public Digital puts it, "design for user needs, not organisational convenience"
This is the most important thing. The entire article series is making this point in great detail, and also being very angry at orgs (especially public services!) that don't get this.
I think this message does get a bit buried under invective against React. Surprise surprise, if you do start with user needs, then sometimes that does lead to you building a React-based SPA. I think from Alex's perspective working with organisations, looking at it from the other direction: for any given React SPA, it is unlikely that React was chosen because of user needs.
I get why people are offended or find it unhelpful. If you read through his Reckoning series, I hope you'll understand some of the righteous anger he has for organisations that fail to serve the user, even when public service is their explicit purpose.
Blaming it on React may not be the most effective strategy. Who knows. But I still find value in the message.
"In short, nobody should start a new project in the 2020s based on React. Full stop."
He lost me. My React web app of medium complexity is statically exported and gets cached by the user's browser. All the data it needs for the main page is fetched by a single graphql call. The UI code renders in less than 10ms even on old machines. Network and the backend are the primary bottlenecks for me.
Could I redesign and rearchitect it such that the frontend is very slow to render even on modern machines? Yes, quite easily. And I suspect, many people complaining about React's performance are doing just that.
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
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
It achieves 95% of the effect, and you maintain one implementation, not two.
I think many people would argue that it is easier to build a good web app in React than plain HTML/CSS/JS.
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:
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
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.
After the initial "SPA fever" died down, these frameworks cropped up to address the shortcomings of SPAs such as a lack of SEO-compatibility.
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/
Worth noting too: you could cheat in the html function above and have it directly return content.childNodes, thus reducing the differences between the two examples to simply "patch" vs "replaceChildren".
In your example, are you envisioning that HTMLElement.patch() is doing something different than Element.replaceChildren() or Element.replaceWith()? That'd be one area that wouldn't be addressed with this.
Having it first-party would be lovely but it's already pretty doable.
Regarding patch, morphdom explains very well the difference between replacing and patching the DOM [1]:
> Replacing an entire DOM tree is fast but loses internal state (e.g., scroll positions, input carets, CSS transitions). Instead, we aim to transform the existing DOM tree to match the new one, minimizing changes and preserving state.
Also, there's the matter of performance. Diffing and patching as a single method call implemented natively should be a lot faster than using a bunch of JS code.
---
1: https://github.com/patrick-steele-idem/morphdom
I suspect there would be a lot of edge case footguns in trying to write something like patch() that tries to crawl the content as a diff and make only the minimal changes. Things like events being bound incorrectly to elements, what to do when the structures of the old and new don't match in some breaking way, etc.
Not saying it can't be done but I suspect it's more complexity than we think of typically when using a term like patch. Some of those items (such as transitions) can be pretty straightforward to deal with already.
> Also, there's the matter of performance. Diffing and patching as a single method call implemented natively should be a lot faster than using a bunch of JS code.
Performance and the DOM (especially as typically deployed in an SPA / the "modern" web) don't really go together already, so I'm not convinced that's a particularly compelling argument. Making it first-party on its own is already that compelling argument IMO.
https://github.com/WICG/webcomponents/issues/1069
https://htmx.org/essays/when-to-use-hypermedia/
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/
1: https://podcasts.apple.com/us/podcast/elm-the-future-of-open...
2: https://reasonableapproximation.net/2024/11/02/elm-community...
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.
Use something like Leptos and be happy:
https://www.leptos.dev/
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.
https://krausest.github.io/js-framework-benchmark/current.ht...
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
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.
As a disclaimer, I still prefer vanilla JS and progressive enhancement.
The other point isn't so much that there's a wrapper around the DOM, but that the DOM API itself is bad and slow. There's only so much pain a better language can take away here, and Rust isn't even a better language for that domain.
But it's JavaScript glue code generated by Rust's wasm-bindgen that you don't need to care about. And eventually the glue code will be unnecessary with wasm component model DOM access.
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.
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.
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?
* It often (always?) breaks middle-clicking/opening in a new tab. In your navigation example is fine, but for example in Jira it's an absolute crapshoot which links will behave properly when middle-clicked
* We already have a tag for a clickable element that is not a link: <button>
> Accessibility tools
Not all applications are created for accessibility, it depends on the app and the intended audience. While in a perfect world we'd all be section 508 compliant, cash strapped startups frequently aren't in a position to invest in that for MVP.
> It often ... breaks middle-clicking
Do you use the same standard for a native app that you install from an app store? Almost everything I've written over the past decade or so has been "web tech as a replacement for native" - not a public web site, so the function comparison should be against native apps. I probably should have mentioned that in my original question.
> We already have a tag for a clickable element that is not a link: <button>
Sure, but I don't think it always makes sense semantically or from a code standpoint to use the button tag. For example, maybe I have a tiny little plus symbol for "expand". Like a lot of folks, I generally use some like font icons, or material symbols for stuff like that. Frequently it makes more sense to use a span or div to render the icon, and just handle the click event.
I'm not advocating for the use of divs instead of "a" tags everywhere, I just think there are normal and reasonable situations where it makes sense.
All engineering is a series of compromises and trade-offs. I'm not going to judge a dev that makes an info icon work to slide out a drawer which has a tabbed sub-nav, because they didn't hammer an A tag into something that it wasn't intended for, or because they didn't want to try to make whatever font icon library they're using work with a button tag.
Just use <a> and you don't have to.
If you're linking to something, then just use a link. So people get their accessibility/screenreader support, and you can still use JS to accomplish whatever other auxillary behavior you want.
Smells like a mistake. Or a button.
> Also, not all clicks are navigation actions.
There are other interactive elements like buttons.
• 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.
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.
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.
If your use case is a simple website, React is just a nice templating lib and you won't need to use any of the things people generally dislike about it. That AND your experience when you inevitably have to add some interactivity is going to be 100x better than vanilla JS.
As for the build step, there are many turn key solutions nowadays that "just work". And isn't a small build step a plus, compared to being at the mercy of a typo breaking everything? To me that piece of mind if worth a lot, compared to whatever manual testing you'd have to do if you work with "text" files.
Are these templates only used on the server-side to generate the HTML upfront? Or is it being generated on the client?
> experience when you inevitably have to add some interactivity is going to be 100x better than vanilla JS
I don't believe this can quantified. How are you measuring DX improvements? Are you also able to continue to measure these improvements as your application/codebase scales?
I have a website. It's not great, it doesn't get much traffic, but it's mine :). If you disable JS, it works: links are links, HTML is loaded for each page view. If you enable JS, it still works: links will trigger a re-render, the address bar updates, all the nice "website" stuff.
If I write enough (and people read enough) then enabling JS also brings performance benefits: yes, you have to load ~100kB of JS. But each page load is 4kB smaller because it doesn't contain any boilerplate.
Obviously I could generate the HTML any way I choose, but doing it in React is nice and composable.
Why do you think that? What problem is a build tool solving for you that without it you think you're being irresponsible for not doing it by hand?
I’m saying—if you do not have high interactivity requirements, which I would claim is most things on the web—you will encounter a lot less overall complexity shipping mostly server-rendered pages with isolated, self contained JS bundles where you need them.
I was using multi-entrypoint build steps outputting separate per-page or per-feature CSS and JS bundles long before I ever worked on an SPA, it’s hardly a good reason to move your entire UI and routing to the client-side.
There are many ways to render pages on the server using a single JS builds, most template rendering engines have a node implementation, and most javascript frontend frameworks have a mechanism to render components statically to a string. If we're talking about a simple, mostly-static website, the content is going to be cached so the performance of the backend isn't a huge factor. So just use JS for the whole thing, and save yourself a build.
This is outdated nonsense for most sites.
I sincerely disagree. I am not about to add node to a project that gets by fine with Django + HTMX.
I'm tempted to say that adding hundreds of perishable npm packages to a project is a better heuristic for 'malpractice'.
Modern CSS is amazing. Why on earth would anyone use SCSS? It pays to look at what Vanilla can do these days.
> Even a "thin" layer of JS on top requires some degree of dependency management
Use modules and import away. If it is truly a thing layer, there's no need for further optimisation until far along in the product.
You say it like more those features are desirable.
> then have fun explaining to your product person why it took so much time to build a thing that they know very well is a pre-built component
Sure. I wasted more time getting an assortment of pre-built components to behave than I did building the basics from scratch. And then comes a breaking change. And then that component library uses styled components and doesn't run properly on the server. Why do people do this to themselves?
Except it really doesn't. Core web technologies have gotten so much better since the jQuery/pre-SASS days that you can absolutely get by without a build step.
- http/2 makes bundling a questionable choice
- polyfills are pretty much no longer a thing
- CSS now has most (all?) of the features that people used SASS for (variables, nesting, etc.)
- es6 modules work
This has been a big talking point in the Rails community lately — one of the big selling points of Rails 8 was the fact that you can, by default, ship a whole webapp without a build step, and that this is considered the "happy path".
Maybe in 5 years this will be a practical approach, but there's a reason that old ways of doing thing hang around: they're well-documented and reliable.
And perhaps most important of all: it's the tool we know.
>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.
https://www.npmjs.com/package/routerino
Lots of massive paradigm shifts with little backwards compatibility.
I’ve gone through like 3-5 times where there is some massive changes between versions.
Right now they are pushing some new routing mechanisms…
I'm suspecting they are going to drop backwards compatibility again in the near future by deprecating support for the options API - leaving me with another headache.
Has gitlab finished upgrading yet? Last time I checked they spent 2+ years and that’s with codemod tools and super smart engineers.
At work, I spent a month upgrading one project to work with the compatibility build and we’ve been slowly migrating for the past 18 months. After the end of this year, we should be out of the woods for that project but then we have 3 more so…
Luckily, Evan has said that he has zero interest in fracturing the community again and I believe him. The new architecture of Vue 3 also makes it very easy to adopt almost any new paradigm into Vue as evidenced by the numerous demos Evan has made to compare Vue to other JS frameworks like Svelte and Solid.
Vue templates are, well, yet another funny little template language. The hello world example already seems way too magical. Just let me use the language I already know.
I will say though that solidjs seems like an improvement on react though.
Long may the reign of typescript, nodejs and react continue.
Last time I looked at react was 2016 or so and every tutorial was referencing some different mutually incompatible version of some component (router, redux, flux, some other alphabet soup) and everyone had their own list of essential ingredients in a basic hello world app. I came away from the whole experience thinking here’s an ecosystem that needs to mature another 10 years or so before I want to even look at it (I’m not a frontend person, it’s all academic to me.)
Is there a consensus on any of it yet? How to do routing, state, builds, etc? Or is there still as many combinations of components as there are tutorials?
Routing: react router (not very good imo but widely accepted and good enough)
state: No libraries. Just use “useState” and if necessary “useReducer”
Builds: vite
Then pick a query caching library so you don’t need to treat fetched data like its application state… ReactQuery is widely accepted and very good. Apollo if you’re using graphql
Unnecessarily complicated and confusing, with odd choices in the most recent version (that IIRC are not backwards compatible). I went with wouter after searching around.
> state: No libraries. Just use “useState” and if necessary “useReducer”
useState is the same thing as the old setState, and useReducer not much different - they're not sufficient for building an app because you just revert back to the original state antipattern, prop drilling.
If you really have too many props or need to widely disperse the same prop you can refactor using higher order components or use a context. A separate state management library isn’t necessary unless you are building something with a ton of complex UI state like a photo editor or a music production workbench.
This exact sentence could have been said about react router 8 years ago when I last looked at react, lol. And IIRC it was react router that turned me off the most, as every react tutorial that stressed working permalinks/URLs (which I believe to be essential) was teaching me react-router, but with sample code that was incompatible with the latest version. Because documentation and tutorials would last like a month tops before they were all horribly broken and out of date. Sounds like this hasn’t changed much.