Bitch about JavaScript all you want but this exact failure has occurred in many languages. It’s not a language failure. It’s a people failure. Nobody trains JavaScript developers properly and employers knowingly hire unqualified people to do the work. Of course the result is shit. It would be just as shitty if this were a different language.
If you want to isolate yourself from so much of the stupid then use a PiHole on your home network and stop working around JavaScript. It works for me as someone with 15 years writing JavaScript.
Although I agree that JS is being used incredibly irresponsibly, I also think this article is almost certainly AI-generated with minimal editing based on the way it reads, and I wish that wasn't the case because the topic deserves better than this.
[Edit: Although I recognise that em dashes are what a lot of people use to identify AI-generated text, that isn't what I was doing here. I hadn't even been considering them, to be perfectly honest.]
I often see people say “JS is unstable,you’re always rewriting your code for the latest and greatest framework” and I always wonder where do you work? If I told the people I report to I can’t deliver that for you because we’re rewriting the app, I’d be out of the door soon.
The JS ecosystem is like any technology ecosystem, things change over time but you don’t have to chase the trends, be pragmatic about what you follow and trust me your life will be golden.
> Spoiler alert: we didn’t get app-like performance. We didn’t get better user experiences.
Not sure about that, I'll take Gmail and fastmail any day over outlook and evolution
> The result? Broken back buttons. Image bloat. Inaccessible markup. URLs that don’t behave like URLs. Metadata that disappears. Content you can’t copy. Buttons you can’t keyboard to. Modals that trap you. Scroll positions that reset for no reason. Headlines that shift mid-read. Analytics that don’t match reality. Preview environments that lie. And pages that load… eventually. --
None of that is the fault of Javascript, it's on the people building them. I'm pretty sure in an alternate universe of no JS, we would see the same articles but about the horrible user experiences of full HTML or native apps.
> At the same time, JavaScript stopped being just a front-end language. With the rise of Node.js, JS moved server-side – and with it came a wave of app developers entering the web ecosystem. These weren’t web designers or content publishers. They were engineers, trained to build applications, not documents. And they brought with them an architecture-first mindset: patterns, state management, dependency injection, abstracted logic. The result? A slow cultural shift from building pages to engineering systems — even when all the user needed was to load an article.
Based on my experience, I think this is wrong. Node.js didn't open the web app gates to non-web devs (those devs more likely than not wouldn't even know JS), it was the other way round: it opened the backend gates to frontend devs, because suddenly they could use the language they know to run code in the server.
That is because the actual alternatives to JS such as Flash, Silverlight and Java Applets were much worse. Native apps are bound by the platform's walled garden and practically undiscoverable, hence the need for web apps.
While I don't agree with other points, things got clearer once I reached the following:
> Marketers, content editors, SEOs, designers – they’re all locked out of the process. Because now, even simple tasks require technical fluency.
I worked in web development in the 2000s and then restarted in 2020s. The power of the tools, the speed of development and the result are all much better. The downside? You need to know more (because you can do more and some required things are more complex and people expect more) and less people might be required (ok, this is a downside for some people only...).
Why are we talking about some megabytes transferred nowadays? Most of us have in our pockets a computer 100 times stronger than the first one that beat a human at chess (not to mention that one was occupying rooms). It is more important to have the flexibility and to be able to scale complexity when you need to (hard and not given even with the frameworks), than to "save" some megabytes.
I wish that it did actually break the web so I didn't have to see this same dumbass article every two weeks
These articles always suggest that minimal HTML and jQuery is enough. Like, I guess for a blog, but like, not for web apps? That's the other weird thing - they're always framed like the entirety of the internet is blogs or whatever. How many software engineers are working on blogs? Everything is a webapp now, the vast majority of the time most users spend interacting with the internet is through complex applications like Spotify, YouTube, Gmail, Netflix, Google docs, notion, linear, etc etc etc. I guess there's an audience for complaining about react for some reason
I’m a big fan of the web. I think a lot of people misunderstand its design and fail to grasp how important various aspects of its architecture contribute to its success. It’s very common for people to see it as nothing more than a delivery system for imperative code to run without installation on clients. That’s where the overuse of JavaScript comes from.
But JavaScript itself isn’t bad. JavaScript was an incredible improvement to the web. It’s when people pass over the web in favour of writing JavaScript apps that the problems arise. I think it would do good for people who spend all day writing React apps to spend some time working with things like HTMX to break out of that mindset and get a bit of perspective on how the web is supposed to work.
Thanks for all the delightful feedback, folks!
Some people rightly pointed out that it was a bit hypocritical of my site to be loading a bunch of third-party JS and resources(!), which I've now addressed.
In my defence, this was only due to loading ReCAPTCHA on blog posts as a quick protection mechanism from an influx of spam - which I've now replaced with Turnstile (and only lazily trigger the JS+resources for that when the comment form enters the viewport).
Also, no, the post wasn't written by AI / ChatGPT / etc. :)
Language wars tend to get emotional, as clearly suggested by other commenters.
I think the problem is exasperated when developers can’t put emotion aside and recognise issues, it may be as simple as proper training or choosing the proper tools.
But just objectively looking at the point the author is making, he is right.
Case in point, Indiscriminate use of frameworks have made the web bloated. In fact, I bet half the Links posted in HN won’t even open in slightly older browsers.
But the content they post are interesting. It is not a question of skill, as other commenters here want to point out.
So it seems to argue that these people just don’t care about accessibility or coverage of the tools they use.
Empathy is key. One should be conscious towards their audience, since web is open and far reaching. It is not just a group of developers in their near vicinity or latest conference hosted in a tech city, they should care about.
If you are building something, one should carefully evaluate the tools they use and how it will end up getting consumed by a wide demography of end consumers, who don’t have the same machine as they do.
In 2010, Facebook was one of the best websites to browse. It was everything you wanted a central social media platform to be. You could stay updated about your friends, family and even host pages for your business on it. Everything was just so simple - because they respected what a "hyperlink" actually meant.
Fast forward today, I click on a dropdown on a post with barely 3-4 options, there's a spinner, a dozen requests in the network panel and the menu doesn't even load and gives up. Frontend libraries like React made frontend so needlessly complex that they actually ended up killing the definition of what a hyperlink is.
You click on a link today, it can either take you to where it's supposed to take you, open a dozen random popups or wipe your bank account clean. I miss the good old 2000s era where JS was minimal and the focus was on HYPER TEXT in HTML. We had good content, less frontend complexity. And we had flash for everything else.
> This isn’t evolution. It’s self-inflicted complexity.
> This isn’t accidental. It’s cultural.
> We’re not innovating. We’re rebuilding broken versions of tools the web already gave us – and doing it badly.
> We’re not iterating toward impact – we’re iterating just to stay afloat.
It's not X, it's Y? Dashes? Question fragments? This style isn't just tedious—it's a hallmark of LLM-generated content.
The whole article feels like low-effort LLM-generated clickbait to fan the eternal flamewar between web developers and web app developers. Yes, you might not need React for a static blog. Yes, React is useful for writing web applications. Can we talk about something else now?
Browsers/HTML should support markdown natively, that would be even cooler.
> We’ve rebuilt the web like an air traffic control system – just to serve a few kilobytes of text.
Funny, in the context of Germany's ATC working off some Emacs Lisp cooked up by one dude in just a week back in the 90s [1]
[1] https://old.reddit.com/r/emacs/comments/lly7po/do_you_use_em...
> It’s easier to win an argument by citing SSR compatibility issues than it is to ask, “Why are we using React for a blog?”
I've asked myself this a LOT - the past few years especially.
I think the biggest reason, which the author doesn't touch on, is that *React won*. React won vs. alternatives so much and so thoroughly that it started to be used for everything - even in places that it clearly should not be, like static content pages. The reality is that in most frameworks, it's easier to make the whole page with React for the once piece of the page you needed to be interactive than to make the whole page static and do some vanilla JavaScript manually. The React ecosystem is HUGE, and most developers out there are just gluing things together.
Some "interactive islands" frameworks like Astro and Hyperspan (my own project) are starting to finally change this approach and make the "mostly static with JS sprinkles" approach easier, but they are a late reaction to the core problem described in this post. It will take time for these approaches to gain traction.
JavaScript is named JavaScript because it was intended to "bridge browser and Java applets"
if you read all the old press releases, they try to push the Java applet connection a lot.
The original plan was to run Java applets everywhere and JavaScript as a "glue". I think we are much better off now than with Java applets. It could have been much, much worse.
> Not just slow – awful. Bloated, fragile, over-engineered disasters. They load slowly, render erratically, and hide their content behind megabytes of JavaScript. They glitch on mobile. They frustrate users and confuse search engines. They’re impossible to maintain. And somehow, we’re calling this progress.
I have the slight feeling that JavaScript is not the problem, bad engineering is. Then I can agree to some of the statements in the article. But most of them suggest a simple solution without any context. Programming is one thing, software development another.
Nothing to do with the language, but yeah, js/py, becasue both popular, seem to attract the most worthless devs and that includes framework devs/authors. Ah well, we make money with systems crashing, being slow, losing money (literally, people are using floating point in js and others to do money and losing money that way, and it's not rare either), etc, so please the more js/py we see vs c#/java in enterprise systems, the more we make.
I agree with the sentiment but things were arguably worse when you had to download a whole plugin to visit some websites (flash) or Java Applets.
If anyone is interested in building resilient websites that don't require JavaScript (but can use it to enhance the experience), here's your gateway drug: https://resilientwebdesign.com/
All of this may be true. It raises the question: why has a better way not won out?
It seems to me that the better user experience that would be gained by a different approach has not been worth the (perceived or actual) hit to developer experience.
Or in a sentence: users do not seem to care enough to make it worthwhile.
Knee-jerk headlines are breaking the web.
Personally love this article. Aligns really well with my core philosophy of simplicity. We try to ship MVPs quickly, so we steer clear of these JavaScript frameworks. Rails to the moon!
Without debating the finer points, just at a high level, "right tool for the job". I build landing pages entirely free of js, and Web apps with fairly heavy js (vue+quasar).
I don’t think that the issue is that we changed to designing web sites for developers. I think that the problem is that we started designing web sites for monetization. And this required adding a language and ecosystem that far exceeded the capabilities of the original WWW hypertext vision.
Ad based monetization means that there are going to be all sorts of business requirements to optimize for the monetization case: detailed surveillance metrics, various design requirements related to branding and to fulfill the designers’ “vision“, paywalls allowing search engines to peek through, etc. oh, and a chat assistant, preferably AI powered, because OMG why would we possibly expend the resources to communicate with a customer.
Ad based monetization is just evil; 50 years from now people will look back on the last couple of decades as a lesson on what not to do. It’s not that ads are evil or that monetization is evil, it’s that optimizing the web for ad based monetization causes people to do so many things that are bad for humans.
The problem is the web sucks. CSS sucks. HTML sucks. Javascript is perfectly fine, actually. Browser security sucks. CORS sucks. CSP sucks. SVG sucks. Favicons suck. Shadow DOM sucks. Video controls suck. Web audio sucks. WebGPU sucks. W3C sucks. Chromium sucks.
You know what I'd do to be able to build a website using SwiftUI or GTK?
Given the terribleness of the web, naturally people will use bloated UI frameworks and build tools to even slightly avoid using them directly.
At my first intern job I was experimenting with javascript. HTML 5 was a buzz word. The crusty old guy who wrote C# ASP.NET told me he'd never fool with javascript. Who is laughing now.
This. So much this.
I have a website for my students, with various content they need for assigned projects. HTML and CSS. The webserver itself is a small, simple Java application that sends files requested by the browsers.
KISS.
It's hard to take this article seriously between the unfounded claims and hyperboles.
It's not because of JS that semantic HTML and accessibility are neglected: it's because of inexperienced developers. If anything, modern libraries, frameworks and tooling empower developers to build modern UIs that are accessible. Of course, with power comes responsibility, but that's like blaming the car for speeding.
The article could have been much shorter, but I agree. It's not just the web; bloated, slow, buggy, bad UX software is pervasive nowadays.
Nah, tracking and ads broke the web (using JS).
most frameworks after 2012-13 were never made to make any progress rather they kept devs in the eternal loop of new thing = better thing if simplicity makes perfection, we are currently on the other side of that
The problem of the web as application platform isn't mainly Javascript (just use a proper linter and/or TS, or even WASM), but the adhoc-designed web API layer stack (e.g. the 3D rendering API should sit below the DOM, and there should be a couple of medium level APIs between the low-level rendering API and the DOM (such as text- and shape-rendering, a rectangle-layout API, a compositor API and an accessibility API which then the DOM is built on top - but which could also be used on their own), also WebAudio is just bad:
https://blog.mecheye.net/2017/09/i-dont-know-who-the-web-aud...
...and don't get me started about 'trivial' things like copy-paste, fullscreen, input handling and filesystem access. These are all not programming language problems, but API design problems.
...e.g. the web could be so much more when there wouldn't be this schism between the 'document-view orthodoxy' and the 'app-platform protestants' ;)
>This isn’t evolution. It’s self-inflicted complexity. And we’ve normalised it – because somewhere along the way, we started building websites for developers, not for users.
We started building websites for the marketing department, not developers or users.
These days you can use JavaScript-centric stack (and, gasp, React) to render static HTML that does not require runtime JavaScript at all.
Why bother with it, though?
Imagine you wanted to add elements of runtime interactivity. When we think about new and cool things on the Web, that’s nearly all of them. Ask yourself, what would result in more complexity and moving parts: doing the whole thing in one stack (e.g., JavaScript and React), or using two disparate stacks (say, Wordpress and then a bunch of jQuery) and ad-hoc tying them together by duplicating data model and business logic?
The most under-appreciated point about good design is that it’s not just about a thing looking pretty and functioning well at one point in time. It’s about a thing that can be maintained, improved, and kept in good working condition. Good design is sustainable, it exists and satisfies expectations over time.
Good developer experience is not the only aspect of sustainability (there are also cultural/organizational aspects, business model, etc.), but it is an important one. Modern stack is great from this perspective, allowing to express potentially dynamic layout while largely preserving declarativity (JSX), forcing to think about exactly what data you work with at all times so that you catch more issues at compile time (TypeScript), etc.
Yes, it also offers plenty of opportunities for shooting yourself in the foot if you so choose: by carelessly adding random badly maintained dependencies with massive dependency trees, by not thinking through the architecture or piling on abstraction layers, by adopting a framework that does not exactly fit your use case or that you don’t understand how it works, etc. We’ve all done that at some point, but ultimately it’s skill issue. More powerful tools require more thoughtful application.
Yes, sometimes sustainability can compete with the thing’s being pretty or small at one point in time, even though all of those are worthy ideals. Sometimes tradeoffs need to be made.
It’s really weird these posts that come up with this weird fiction that somehow the web was better in the past.
I’ve seen the whole thing, was there every day for it, and it was never better in ye olde days. It was shit.
And I also don’t buy the moaning and bitching about how bad JavaScript is, and how terrible web sites are these days.
These curmudgeons invite you to join in their sad lament for the fabulous days of yore, and how everything’s just awful today.
The truth is it’s an embarrassing wealth of riches on the web. Sites are (mostly) fast, broadband is fast, content is rich, lots is free, and there’s just an unbelievable number of incredible apps and sites.
And it’s all driven by JavaScript, which isn’t a terrible language it turns out to be a warty, weird, inconsistent yet incredibly flexible and powerful language that has grown and stood the test of time.
So when this latest grumbler invites you to grumble with him, maybe instead see reality instead of the fictional past he presents.
As much as I share the sentiment, at least the browser has one single programming language. What’s a waste of time is to have dozens of backend programming languages (each of them having a few frameworks and countless libraries). So much wasted effort. I agree that variety is important, but ffs, it’s time to make a good use of our time and stop implementing yet again the same things but in a different language.
+1 I do love a good js rant!
For a stark comparison, consider the site where these comments are entered.
HN Rulz! No js, no problem! Fast and functional...
And regarding the comment:
> it loads 754kB of JS across 13 requests
It didn't for me, since I browse by default with javascript and cookies disabled.
The site jonoalderson.com worked just fine without them.
I'm not sure why more technically literate people don't do this...
There's a lot of good deep questions and challenges here. There's a lot of general anger and rage against the web, against JavaScript, but there's specific complaints that are much more real here:
> It doesn’t matter if you’re publishing a blog post or an ecommerce site – the stack is the same. Heavy, abstract, engineered to the edge of usefulness. And nobody understands it. Not fully.
That so many folks are using the same stack seems much much more likely to mean that people do understand it. Pax Reactus feels absurd but the reason it's so saturated is because it's what we know, because it's what's done elsewhere. It's done because lots of people do know it.
> And the worst part? Most of this complexity exists just to retrofit things we used to get by default: routing, metadata, caching, templating, layout.
We didn't get a lot of these by default though. We built those http services. We build template/layout engines for the server side. To a lesser extend we build routers, caches (those have been part of httpd services for a long time).
But it's still very near to me that our frameworks for SPAs (single page apps) often make us bring these concerns in each time. URL routing should be super super super common, to avoid degrading the user experience, but so often it's an afterthought. And it's not really the developers/company's fault entirely, if it's not foremost in the framework design. Its not an add-on its core to having good web architecture.
There was a defense for many years that react wasnt a framework, that it was a library. It only wanted to concern itself with rendering aspects. It left you to do a lot on your own, like state. That's both true, but it's wild how much negative space we haven't seen well integrated, how few good examples we have of a batteries included thoughtful well constructed front end.
To steer towards some kind of closing… it does feel tumultuous and chaotic. Technically we've been in transition and not making a ton of real visible progress since 2020 (react suspense is a good technique but feels obvious in retrospect, rsc is a huge slow shift), transition towards handling the SPA well.
But I'm so happy we are here. This is so different, so much more than what programming has been. HTML, CSS and JS are such an rich and capable platform, an interesting rich front end that displays anywhere on any device with secure and interesting interconnection to the world, that we can architect apps out of however we might dream. Very little seems to hold us back beyond our craft, beyond how we might imagine making these machines. So far in our lurching forward we have created such a richer connected world,… and fairly impressively direct toolkits that have shifted us from craftsmen who understood every little bit and every tool, to an industrialized workforce using advanced React Compilers. I don't love this hyper industrialization, but it's still amazing & powerful; I resist the part of me that wants to pastoralize the web, that has any sympathies for the very ardent very loud clambor against the web, that wants to see only simple pages again, that thinks it should all be torn down.
I really worry that the rage and disdain spreads so readily, on so many topics, & here where I still feel a glow of hope, even as things escalate & go unresolved, even as it feels mostly not to be honing in on really good answers (why are we still so broadly doing all work on the main thread?!). The anti-vocates pile into comments again and again, with endless energy to blast and destroy. I want to chime in to say, yes, it's complicated, but I love and cherish Dynamic HTML still, and I look forward to seeing ongoingly how we architect apps out of this base material.
https://en.wikipedia.org/wiki/Progressive_enhancement
This. But it's hard. But it's worth it. Best of both worlds.
Noice!!!
You mean react broke the web ?
This! Every. Single. Sentence. So true!
Rose colored glasses at their finest. I think this person has forgotten what the web was like 15 years ago. I suggest they visit some Japanese websites to find out.
I’m optimistic on the future. llms.txt will be adopted for all major sites (from AI hype), and ironically it will benefit humans to browse and interact with sites in a simpler manner.
I personally believe that a new era of “lite-browsers” will be made. Emacs got close into this direction, but not accessible to avg. consumers
Text oriented operating systems will be the future.
Saying JS broke the web when your website loads 754kB of JS across 13 separate requests makes me wonder if you're very serious about the problem.