There is, I think, a sort of innocent arrogance that comes with people who boldly claim that renowned, well-adopted frameworks or technologies are straight up bad or a non-improvement over yesterday’s tech.
That’s not to say popularity guarantees quality, that progress is always positive, or that there’s not plenty to criticise. But I do think authors of articles like this sometimes get a big hit from being subversive by playing into retro-idealist tropes. The engineering equivalent of paleo influencers.
Such proposals would suggest a huge global collective of the world’s most talented engineers have been conned into fundamentally bad tech, which is a little amusing.
People make mistakes using bad (but popular) tech all the time. Remember MongoDB when every app needed to be NoSQL for web-scale? Remember when everything was event-driven using Kafka? Remember when every left-pad needed its own microservice?
When large organizations (Facebook, Google, LinkedIn, Amazon) start pushing it, when popular developers blog about it, when big conferences run talks on it, and lots of marketing and ads and sales funded by ad revenue or VC dollars start pushing a tech as “amazing,” it gets adopted by CTOs, becomes a hiring criteria, and suddenly no one wants to admit it’s crap because their entire career depends on it… or more generously they don’t know any better because they haven’t hit the painful edges in production yet, or they haven’t seen how simple things could be with a different architectural decision.
Something being popular doesn’t mean it’s well-suited for a common use-case. Very often it isn’t.
The "paleo influencer" comparison is interesting, but I think it actually works both ways here.
Yes, there's a temptation to romanticize the past and dismiss modern tools. But there's an equally strong tendency to assume that newer, more popular, and more widely-adopted automatically means better. React didn't just win on pure technical merit. It has Facebook's marketing muscle behind it, it became a hiring checkbox, and it created a self-reinforcing ecosystem where everyone learns it because everyone uses it.
The article isn't suggesting that a "huge global collective of the world's most talented engineers have been conned." It's asking a much more nuanced question: did all that effort actually move us forward, or did we just move sideways into different complexity?
Look at the two implementations in the article. They do the same thing. They're roughly the same length. After 15 years of React development, countless developer hours, and a massive ecosystem, we're not writing dramatically less code or solving the problem more elegantly. We're just solving it differently, with different tradeoffs.
Sometimes looking backward isn't about being a "retro-idealist," it's about questioning whether we added complexity without proportional benefit. The paleo diet people might be onto something when they point out that we over-engineered our food. Maybe we over-engineered our frameworks too.
> They do the same thing. They're roughly the same length
But they arent the same, the backbone code has raw HTML strings. These are opaque for code editors and not type safe. React code is using typed objects to construct the html (if you used typescript like is standard in 2025 for react projects). The backbone app is disconnected in the rendering flow. the space-y-2 selector is ambiguous and causes unnecessary searching. Just in this small example adds a level of indirection that just adds noise to what the component does. With everything setting raw html, what if you wanted the requirements blob to be a seperate component for instance. this is super easy and clean in react because html and custom components are treated the same.
It also cherry picks an extremely narrow use case of a single element on the page of a password element. This hides the realities of mature apps that you then need another parent component to check if the confirm password field matches, submits the form to backend and displays errors, checks if username is taken etc. Your example doesnt show calling another component from inside a component, etc.
Your purposefully slicing it in to a narrow use case and trying to show equivalence where there isn't
This is the equivalent of those "Primitive Technologies" Youtube videos of building a swimming pool out of mud. Yeah sure technically you accomplished some definition of a "swimming pool". Yes, in some lens you can stand back and look at your pool and a inground pool with filtration, etc and say that you accomplished the same. Yes, technically you proved if you want a swimming pool you don't need a bunch of other equipment. But if you are building a swimming pool to last and be usable for the next 10 years, you will find out why modern pools are not a dug out hole filled with muddy water.
Did you work on any big backbone apps professionally? We had a huge one at Airbnb where after a certain scale any change by anyone - from new grad to expert - could get stuck in 2 days of debugging pure incidental complexity. Change some ui dom structure? Oops you broke someone’s selector and their event won’t fire anymore. Send an update at the wrong time? Render loop.
Switching to React for that app (and everything else) was such a godsend. Once React landed in the codebase it spread like wildfire because of how eager everyone was to burn down the old way!
To me the “it succeeded because marketing” rings hollow because my experience at the time was:
- people loved their MVC ideas and “semantic makeup”, putting template in the JS was so WEIRD and ICKY. And no doubt the compile step for JSX still is annoying one-time complexity. Lots of resistance / thinking React was dumb.
- then you hear about someone on another team replacing a small but annoying feature with React and how relieved they are to be out of backbone hell
- you try yourself, it’s a weird new world and you struggle a bit with the new concepts. Hit a few sharp edges.
- after a week and a half you can’t go back.
- after 6 months (almost) everyone on every team wants to rewrite to React. (We had a few front end leads clinging to their Separation of Concerns as though changing class names on a node in backbone wouldn’t break a zillion event handlers)
If definitely became The Way and self reenforcing, but in my mind that happened primarily out of merit.
React (and Tailwind for that matter) are great for hiring and getting hired. The chances of someone screwing it up or being lost in their first week/month when parachute into a project are pretty low.
It has very little to do with the right abstraction or the best technical solution to the problem.
The web has no default design pattern. It’s the Wild West for better and worse.
I made my peace with modern web stack once I understood this.
Took the words out of mouth. Every thread about React people come piling in about how overly complex it is.
When people throw around words like "foolishness" to describe tools that millions of professionals use, its hard to take the rest of their comment seriously. It radiates a special blend of arrogance and ignorance.
Whether React is good or bad, there is a reason people use it. Outright dismissing it entirely seems a bit like chestertons fence.
Is it arrogance or is it experience combined with a different perspective? One developer may love React because of the component ecosystem and talent pool, and another developer may dislike it because they're writing custom HTML/CSS anyways and React requires them to write way more JS than their preferred approach. Would I ever choose backbone? No. But many developers may be surprised by how little vanilla JS that it takes to build modern web apps. More than ever the tradeoffs of different frontend stacks need to be evaluated on a project-by-project basis.
I think that kind of criticism is a reaction to the lack of critical examination of the industry standards.
I don’t think React is straight up bad by any means but I do think it is chosen unthinkingly in scenarios where it isn’t necessary. And what of Preact? It’s a 3kb library (compared to > 100KB for React) and is a drop in replacement for probably over 90% of React sites. That wastefulness speaks to an inattention to detail.
I see articles like this as a provocation to pay more attention rather than a serious proposal.
One thing I’ll also say: building static websites and building big interactive web apps are two points on a LONG spectrum. Yet for some reason online discourse ignores this.
This enormous spectrum gets compressed into just “modern web dev” or “JavaScript”. Not just in conversation, but in teaching materials, job postings, you name it. It leads to wild disconnects and disagreements between people who think they are peers but are actually building radically different things.
100% agreed. If you’re making Gmail the extra bulk of React is an afterthought in the context of a giant web app. But when you’re building a mostly static marketing site and don’t consider what’s going to get the thing to load as quickly as possible you’re not prioritising the right things, IMO.
1. Potential compatibility issues. Their preact/compat package doesn't cover 100% of cases (of course it doesn't, otherwise it'd just be React)
2. Risk. Will this thing be maintained long term? I mean sure a potential migration to React probably wouldn't be too painful but.. why?
So, starting from "The average speed for 4G LTE is typically between 10 and 30 Mbps for downloads"
Saving 100kb buys you what exactly? The initial download certainly isn't a factor.. and in a case where the performance really matters you probably want to skip both anyway
SSR html is vastly faster for all parties involved. So much so that all spa frameworks have introduced some sort of server rendering, astro is growing a lot, and things like htmx, datastar, hotwire etc are all getting a lot of fawning attention.
> I do think it is chosen unthinkingly in scenarios where it isn’t necessary
Does this genuinely matter beyond (borderline dogmatic) perfectionism?
There are plenty of things that make products or projects bad, and I'd say, at most, the choice of framework is incidental. It only becomes symptomatic when you have an axe to grind.
IMO, yes. There are a lot of people out there with underpowered devices or slow internet connections (including me when I’m on the subway!) and modern web dev practices that output MBs of JS for simple things are a terrible experience. Just not one experienced by the developers on super fast computers and wired internet connections.
Try browsing the web with Chrome’s network throttling and CPU throttling enabled. It can be torturous.
Just to cite it again: there’s a 3kb library available that does 90% of what a >100KB library does. That no one ever even considers it is not about “perfectionism” in my eyes, it’s industry wide laziness.
If you're using my web app (I wouldn't have used React if it wasn't an application anyway, right?), you're very likely a returning visitor. Even if your first page load after signin in is a drag because you're on the subway and for some reason 100KB take five seconds—you're probably coming back anyway, because my app warrants recurring usage (and the industry heavily optimises towards that, but that's a different story).
So on the second visit, you'll have my vendor bundle cached anyway, the app loads instantly, and you will never even remember how long the first load took.
Given that—tell me again why I should care to convince my boss we need to put considerable investment into an alternative technology with a bunch of dragons lurking about, that may or may not be abandoned in a few years and bite us later on, which might introduce compatibility issues with new libraries, which existing staff and new hires must be trained to account for?
Why would I opt for a world of potential pain, just to make your first page load under bad (thus: rare) conditions slightly better?
That 10% missing are event normalization and event bubbling (preact bubble through DOM, react follows vDOM). Choose yourself what you need, but 100% compat with 3rd party libs is why I stick with react over preact.
OTOH we are taking about the web, here. A domain notoriously defined by technical debt, the "when all you have is a hammer" mindset, NIH, and resume-driven development...
Let's be brutally honest. Big part of choosing tech has to do with the fact that I want to be able to be paid. If react is popular and has some potential for earning me money, then react it is.
There is, I think, a sort of innocent arrogance that comes with people who boldly claim that eating McDonald’s is straight up bad or an obvious step down from “real food.”
That’s not to say popularity guarantees quality, that every menu change is progress, or that there’s not plenty to criticise. But I do think authors of articles like this sometimes get a big hit from being subversive by playing into retro-idealist tropes. The nutritional equivalent of paleo influencers.
Such claims would suggest a huge global collective of the world’s most experienced eaters have been conned into fundamentally unhealthy food choices, which is a little amusing.
> ... a sort of innocent arrogance that comes with people who boldly claim that renowned, well-adopted frameworks or technologies are straight up bad or a non-improvement over yesterday’s tech.
There's a sort of innocent ignorance that comes with people who assume well-adopted or renowned frameworks or technologies became renowned due to positive virtues and not due to external factors at the time.
React was Facebook's reaction to Google's Angular, which was a reaction to backbone and others at the time. At that point, it became a company pissing contest for developer mind-share that embroiled developers in hype trends when the companies themselves were not even using those technologies.
Bootcamps began to teach those technologies because of the hype train and then companies began to hire for those skills because it's what every "new" developer was skilled with due to the massive push by bootcamps at that time (mega rise of MOOCs and bootcamps).
I've spoken to countless founders that made tech choices due to "hiring concerns" and "it's what developers want" and "my buddy XYZ is using it" or "we can't use X because that's the old way".
There's certainly a space to discuss these technologies without being "arrogant" and dismissing what the "majority of developers" use. Maybe the majority is wrong.
I take issue with comments like this, firing off inflammatory criticism based on nothing but guesswork and extremely tenuous “deductions”. There’s like, 8 extremely debatable assumptions here.
Reading between the lines is fair but architecting entire narratives is a stretch. Even then, the narrative lacks logic: why are we arbitrarily trusting what the manager and engineer says “at face value” but not OP? Where on earth is it even remotely implied that OP lets the engineers do what they want?
Repeatedly saying “I don’t know what’s really happening buuut” is not a coupon to let you arrive at such a negative conclusion.
>why are we arbitrarily trusting what the manager and engineer says “at face value” but not OP?
Trust does not matter. The manager might be totally wrong and the guy is getting worse and worse. This does not matter for my argument, which is that the manager puts his opinions above the one of the team lead. And he sees the team lead as part of the problem. Do you think there is an alternative explanation besides the manager not believing in the leadership qualities of OP?
I am also not trusting what the problem guy says, except that OP calls him a competent jerk, which tells me that OP does not disagree that the problem guy is a capable engineer.
>Where on earth is it even remotely implied that OP lets the engineers do what they want?
I wrote it below. If you are the leader of 10 people, 9 of whom trust you and 1 constantly disagrees with you, you can still push through any decisions, because the 9 people will stand up for you and force the one guy to accept whatever you decide.
Imagine having to go to your manager because one guy in your team of 10 does not want to do a post mortem. There have to be 9 other guys who do not care at all about your decisions, else they would have immediately stood up for you, for something as reasonable as a post mortem.
So why do you love working for a leader, but do not care at all when the leader gets criticised for something extremely reasonable. They do not like him because of his leadership abilities. Maybe they like him because he is a nice person or because his lack of leadership gets them something they want.
In the first instance, even if you’re right and the manager thinks team lead is the problem here, it’s quite the leap to go straight to “questions his leadership qualities” over a single interpersonal conflict or difference in viewpoint. It’s plausible, sure. But the manager could just as easily be trying to avoid (needed) conflict.
To your second point, there’s MANY other explanations. We don’t know how the team reacted for a start - maybe they did back up OP. Or maybe, based on the alleged jerk’s aggressive behaviour to the team in the past, they felt scared to speak up. Or maybe they’re junior. Or maybe you’re right and all 9 people unanimously felt OP was in the wrong.
My point wasn’t any of this though, it was mainly: avoid coming to such harsh judgments based on so much extrapolation. Criticise the reported actions, sure, discuss some hypotheticals, but going straight for “you’re a bad leader” goes a bit beyond.
We know they reacted in a way which forced OP to go to his manager.
>Or maybe, based on the alleged jerk’s aggressive behaviour to the team in the past
If that were the case OP would have mentioned it. Workplace bullying is certainly more important than disagreeing and this would make a reasonable case to fire him. If the jerk was bullying his team and OP did not notice, that would prove my argument even more.
>Or maybe they’re junior.
There are 9 other people. And they weren't asked to stand up for their own opinion, but for their team leads opinion. I do not think this matters much. 9 people not standing up for you as a team lead is a very bad sign, even if they are all juniors.
>Or maybe you’re right and all 9 people unanimously felt OP was in the wrong.
This isn't my interpretation at all. My interpretation is that OP had one opinion the other guy had his and the rest did not particularly care either way.
>Criticise the reported actions, sure, discuss some hypotheticals, but going straight for “you’re a bad leader” goes a bit beyond.
But having to go through your manager to force through a totally reasonable decision that is yours to make is being a bad leader. I do not think that there is any alternative interpretation then that this event at least is a failure in leadership.
I am saying this because I want to tell OP how his situation sounds to a complete outsider. OP was there if the 9 guys all immediately stood up for him and told the other guy that he was clearly in the wrong, then this obviously disproves everything I said and OP knows that I am wrong. But if they did not, then he should reconsider his actions and at least allow for the possibility that this was a failure on part of his leadership.
The negativity oozing out of this article undermines the main points (of which there’s some good ones). Belittling and admonishing an entire cohort of your peers because they like a tech you don’t is not helpful.
I think React has some fundamental API issues (Solid/Svelte are better) and there’s way too many petabytes of JS out there for sure. But it pioneered some great concepts, and its ecosystem is robust.
Building complex interactive web apps without a framework is still a disaster in 2025. React and friends are not going anywhere until that changes.
Accountable in what sense? How are journalists trying to pry extra info from staff helpful? If they want to ask questions at press conferences and whatnot - as far as I understand they still can?
> Without proper press access how is there any real accountability?
No.
Real accountability is that the people can torture their leaders when they fail, but that just doesn't happen anymore.
Imagine that this was just a big rock and Trump was sitting on top of the rock like with a group of apes. Also, let's assume that Trump had set fire on the entire banana supply. Do you think the apes would not have picked a different leader immediately?
Rational people would understand that if you make people lose billions that there should be consequences, but someone the world population is more stupid than a bunch of apes.
Having sat through this, the main thing that irked me was Matt's lack of empathy towards impacted users.
Every time Theo tried to talk about the negative community impact or the perceived stability of the platform as a whole, Matt forcefully steered the conversation back towards criticising WP Engine.
Matt seems more concerned with retribution towards WP Engine than doing what's right for the WHOLE userbase. It almost doesn't matter how right or wrong he is in his arguments against WP Engine, what worries me is that he is being vindictive in a way that undermines everything he's built.
That seems understandable, since (according to this video) WPE has apparently been on notice about this for a very long time and has been playing a game of chicken with WordPress.
Indeed, and like Theo, I finished the video with little sympathy towards WP Engine. I think Matt's trademark argument is sound.
But as Theo pointed out, the public was not privy to this long running dispute, and Automattic's drastic action came effectively out of nowhere.
Matt seems so preoccupied with this line of thinking (i.e. is WP Engine doing something wrong) and not nearly preoccupied enough with the impact on the Wordpress userbase, the long-term perceptions of the Wordpress brand, and the overall business confidence in Wordpress as a platform. There are ways to balance both, but Matt has chosen not to.
It is clear to me that Matt sees Wordpress as "the foundation" and "the trademark" and "Wordpress.com" and not the 25% of the public internet that uses it.
I'm also not a lawyer but it also sounds not sound. The "enforcement" of the WordPress trademark is so completely chaotic that it seems clear Matt is just using it as a weapon to extort companies he thinks he's entitled to.
WPEngine may very well be doing something wrong, but WordPress needs a clearer license with which to attack them with
I ask this earnestly, but have you tried it? It most certainly can write a pretty huge variety of code. Yes, it does often have errors, and it struggles with novel or complex problems (as the article points out), but for well known languages and frameworks it is still insanely impressive.
I tried it yes, it did not go well. First it gave me a snippet that looked correct but was not what I was asking for (I guess similar to a search engine). When I tried to point out why the proposed solution did not solve the problem, it could not modify it correctly. It kept oscillating between two incorrect solutions.
I think you've accidentally proven his point. Half the things you've mentioned have been around for half a decade at this point, and pretty much all of them have existed for at least 2+ years.
Frontend is still a fast moving space with a large ecosystem - and I get for some, that's not ideal. But this 'frontend fads' meme isn't really reflective of the current reality.
Rust, which is the greatest new hotness in the backend world is from 2015.
Other major languages in the backend world are at least 2 decades old (C#, Java, Python, C++, Ruby, etc).
C# with the .Net framework is an interesting example. Microsoft realized their original windows only approach was a dead end. They created .Net Core. But someone moving from .Net framework to .Net core didn’t have to relearn much at all, beyond initial config/bootstrapping, and which subset of the APIs had been implemented, because MS completed the implementation in stages.
On the flip side you have React, where you’re ostensibly using the same library for a decade, except halfway in between they made a change which completely flipped how developers weee supposed to use the library.
This is a disappointing and highly inflammatory article. There’s a nuanced and interesting discussion to be had here but the author chooses to demonise and insult entire communities. Does this rhetoric help anyone?
Making highly interactive web apps in 2013 was painful and it is revisionist history to claim otherwise. Keyword being “highly interactive”. If you’ve been mostly building traditional sites then it’s a different situation.
The author says he likes Knockout… well, I respect Knockout too, but having spent many years maintaining a decade-old enterprise Knockout app, it is painfully clear that React was actually real progress.
These frameworks - warts and all - do solve real problems. Just as you shouldn’t trust someone who tells you they’re perfect, nor should you trust someone who dismisses them as a con.
> There’s a nuanced and interesting discussion to be had here but the author chooses to demonise and insult entire communities. Does this rhetoric help anyone?
I mean, it is true that the SPA community has basically taken control of the frontend narrative. No beginner dipping their toes into webdev today can escape the gravity pull of React et al.
From the article:
> I’m angry because for the past decade of web development, I and so many others like me feel like we’ve been repeatedly gaslit, and that so many of the “merchants of complexity” refuse to acknowledge the harm that’s been done.
This I agree with. Beginners should start with generating HTML from their programming language of choice. Experts know better, but a complete beginner has no idea that this is the truth. Everywhere they're bombarded with frontend == React (or some other up and coming framework). Look at the amount of discussion generated by "Do I need to learn JavaScript before React?". This shouldn't even be a question, but you have people passionately arguing for the other side because "frameworks make your productive immediately, you can learn the basics later". The basics are HTML and CSS.
Oh, come on. So the guy uses some harmless exaggeration when selling himself on his own personal website & you're taking him to programmer jail over it?
Do you frequently launch into personal attacks on authors whose articles you disagree with?
If a medical doctors classifies himself as world class and then posts articles about medical matters, then my expectation would be his world class-ness is evident.
This guy's not writing an opinion piece about which brand ketchup tastes best. He has published an opinion piece in which he speaks authoritatively about matters related to the domain he claims he's a world expert in.
As for the harmless exaggeration, it's not harmless. It's poison to my chosen profession.
> As for the harmless exaggeration, it's not harmless. It's poison to my chosen profession.
Now you seem to be the one exaggerating there. While yes I agree that is a crappy way of describing himself, there is no reason to start being so mean about it.
It's typically used in sports and means an athlete or team has won championships in an international league, or a person is an Olympic athlete.
Coding is less explicitly competitive, but there is an element of competition to it. If you were a major contributor to a project that had displaced multiple international competitors, that'd clearly be world class. For example, Linus is a "world-class" coder because Linux is used all over the world and has displaced many operating systems.
No but on HN you should expect that criticism in that direction is valid. You can be world-class in certain niches but I doubt that calling oneself a world-class developer holds in the context of parts of the audience here.
It's ok to sell oneself but I'd be careful with exaggerations in a field with probably >1 million professionals.
If the author is joking about being world class, that would be kind of odd. So is saying you're world class at something in general (unless you're the tiger woods of that something and can demonstrate/back it up).
I have found it is commonly a trend with frontend/javascript/rails devs to be senior/lead/etc after a few years of experience. I think there's a variety of reasons for this, but going back to the author he probably is very adept at his given field. But to brand yourself as world class seems a bit much.
Personal attack? Nope. But if I saw that line before interviewing a candidate - I'd definitely probe them about it
That’s not to say popularity guarantees quality, that progress is always positive, or that there’s not plenty to criticise. But I do think authors of articles like this sometimes get a big hit from being subversive by playing into retro-idealist tropes. The engineering equivalent of paleo influencers.
Such proposals would suggest a huge global collective of the world’s most talented engineers have been conned into fundamentally bad tech, which is a little amusing.