JavaScript broke the web (and called it progress)

19th June, 2025

Most websites are awful.

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.

The tragedy is, none of this is necessary. Once upon a time, we had a fast, stable, resilient web. But we replaced it with a JavaScript cargo cult.

Now it takes four engineers, three frameworks, and a CI/CD pipeline just to change a heading. It’s inordinately complex to simply publish a webpage.

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.

How we got here

Around 2010, something shifted. The iPhone was ascendant. Native apps were sleek, fast, fluid. Angular, the first mainstream javascript framework for the web, elhad just emerged. And suddenly, every CMO started saying the same thing in website briefs: “Can we make it feel like an app?”

Developers, armed with new frameworks and good intentions, said yes. JavaScript could, in theory, do seamless transitions and slick UI. So we built towards that promise. Or tried to.

Spoiler alert: we didn’t get app-like performance. We didn’t get better user experiences. What we got was an arms race of complexity.

We started solving simple problems – like navigation or layout – with tools built for full-blown applications.

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.

And so, we rewrote the rules of web development around entirely different needs, almost overnight. Not content, not speed, not interoperability, not discoverability. Just code.

The further we went down this road, the more the stack drifted from the fundamentals. Semantic HTML? Optional. Server-side rendering? Rebuilt from scratch. Accessibility? Maybe, if there’s time. Performance? Who cares, when you can save costs by putting loading burdens onto the user’s device, instead of your server?

So gradually, the web became something you had to compile before you could publish. Not because users needed it. But because developers wanted it to feel modern.

And we’re still paying for that decision.

The cult of developer experience

Today, we optimise for “DX” – developer experience. Not user experience. Not performance. Not outcomes.

Today’s popular frameworks are sold on their DX. The docs are slick. The onboarding is smooth. The tooling is smart, integrated, clever. You can spin up a new app with a CLI command and feel productive before you’ve even written a line of content.

But good DX doesn’t guarantee good UX. In fact, it’s often the opposite. Because the more comfortable we make things for developers, the more abstraction we add. And every abstraction creates distance between the thing being built and the people it’s for.

Now we have component libraries generating button markup. We have page metadata managed in JavaScript functions. We have image loading strategies buried in config files.

Everything’s optimised for developers – and hostile to everyone else.

This isn’t accidental. It’s cultural. We’ve created an industry where complexity is celebrated. Where cleverness is rewarded. Where engineering sophistication is valued more than clarity, usability, or commercial effectiveness.

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?”

And so we keep optimising for the wrong things. Because it feels good. Because it’s fun. Because it looks modern. And because nobody stops us.

Complexity becomes the default

This is how it spirals.

We don’t just tolerate complexity anymore – we expect it. We assume that every site needs a build step, a bundler, a hydration strategy, a routing layer, an API layer, a design system, and some clever cache invalidation logic. We build in microservices, host on edge networks, and deploy pipelines to ship basic content.

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.

Not the marketers, not the SEOs, not even the developers who built it six months ago. Every new tool brings new abstractions, new syntax, new mental models. Making a simple tweak to a headline, a meta tag, or a layout becomes a three-step deployment process.

It’s madness.

We’ve rebuilt the web like an air traffic control system – just to serve a few kilobytes of text.

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’re not innovating. We’re rebuilding broken versions of tools the web already gave us – and doing it badly.

The stack is rebuilding itself in its own image

Fast forward to today. Ironically, after years of chasing abstraction and complexity, the JavaScript ecosystem is now scrambling to reintroduce the things we lost.

Server-side rendering? Back in fashion. Routing? Carefully managed. URL structures, metadata, even HTML output – all being rebuilt, one plugin at a time.

It all looks increasingly like the thing we started with: a conventional CMS, serving HTML, rendered on the server, cached close to the user.

Except now it’s slower, harder to maintain, and dependent on a brittle ecosystem of packages, compilers, and edge handlers.

We’re (re)building platforms like WordPress and it’s features, but with 10x the overhead and none of the usability.

Worse, every new layer introduces new bugs, new compatibility issues, and new cognitive burden. Now we’re maintaining hydration logic and cache strategies and build pipelines just to get a homepage online.

It would be funny if it weren’t so exhausting.

This is the endgame of a development culture obsessed with novelty. We’re not shipping better sites. We’re reinventing basic infrastructure in increasingly convoluted ways – then celebrating the fact that it almost works.

The cycle of iteration and instability

The stack never settles.

Nothing is stable. Nothing is finished. Every sprint, every roadmap, every quarter brings a new initiative: migrate to the latest framework, adopt the new bundler, refactor the routing layer, replace the CMS integration, rebuild the cache.

It never ends. And it rarely helps.

Most of this churn isn’t solving real user problems. It’s solving the problems created by the last round of architecture decisions. We’re not iterating toward impact – we’re iterating just to stay afloat.

And while the stack is busy trying to fix itself, everything else slows down.

Marketing campaigns get delayed because the component library isn’t flexible enough. A/B tests get scrapped because the analytics layer isn’t compatible with the hydration strategy. Content updates wait days for a build. Basic SEO tweaks get buried in backlog.

Meanwhile, the users still can’t load the page.

This is what happens when complexity becomes the product. We don’t optimise for outcomes anymore. We optimise the optimisation layer.

And then we do it again.

Collateral damage to marketers and users

All this complexity doesn’t just frustrate developers. It locks everyone else out.

Marketers can’t update copy or run experiments without raising tickets. They can’t preview content, test layouts, or launch pages. Every change has to go through developers, pipelines, approvals, and rebuilds.

SEOs are stuck trying to diagnose rendering issues they can’t control. Pages load empty, or late, or not at all. Crawl traps appear. Metadata disappears. Structured data gets bundled into a JavaScript object and forgotten.

Content strategists and editors are left editing JSON blobs, Markdown files, or headless CMS forms that have no connection to the thing the user actually sees.

Even basic QA is a mess. Does the page show the right headline? Does the canonical tag resolve correctly? You won’t know until you’ve deployed it. Maybe.

And users? They’re stuck staring at loading spinners. Tapping broken buttons. Waiting for the back button to un-break itself. Watching text reflow as the layout shuffles into place.

This isn’t the future of the web. It’s a slow-motion disaster.

We’ve made websites harder to publish, harder to find, harder to use, and harder to maintain – all in the name of modern development.

JavaScript is powerful – but misused

Let’s be clear: JavaScript isn’t the villain. It’s powerful. It’s essential. It enables rich interactivity, dynamic content, real-time updates. It lets us build tools, not just pages.

Used wisely, it elevates the web.

But most websites don’t need to be tools. They don’t need complex state. They don’t need real-time data or dynamic routing. They’re not apps. They’re brochures, catalogs, portfolios, articles.

And for those use cases, the modern JS stack is complete overkill.

Even ecommerce sites – with product options, variation pickers, add-to-cart functionality, and modal overlays – don’t need full frameworks. These can all be built with minimal, lean, well-targeted JavaScript. No client-side routing. No hydration. No component trees.

A few lines of well-written vanilla JavaScript (or yes, even jquery) can handle 95% of what most websites actually need. Faster. Simpler. More accessibly.

Modern CSS alone can now handle many of the tasks we used to need JavaScript for – like toggles, modals, and even carousels – reducing the need for scripting altogether.

And yes, some sites do have genuine client-side state needs login states, currency selectors, regional availability, and so on. But even those can often be handled more cleanly and performantly with server-side logic, or simple asynchronous JavaScript and AJAX. We don’t need a full reactive runtime to show a ‘logged in’ button or switch from USD to EUR.

But instead, we default to frameworks. We reach for React to build a contact page. We deploy hydration strategies for static content. We compile, bundle, transpile, and optimise code that doesn’t need to exist.

It’s not just wasteful. It’s damaging.

We’re burning user attention, developer time, and business resources to simulate interactivity that nobody asked for.

JavaScript should be the icing. Not the cake. And certainly not the oven, the recipe, and the kitchen sink.

The power problem

The more complex the stack becomes, the more power it concentrates.

Marketers, content editors, SEOs, designers – they’re all locked out of the process. Because now, even simple tasks require technical fluency. Want to change a title tag? Talk to engineering. Want to launch a campaign? Raise a ticket and wait two sprints.

Everything flows through the dev team. Which means the dev team gets to decide what matters, what ships, and what gets deprioritised indefinitely.

And the more complexity they add, the more indispensable they become.

It’s not (usually) malicious. It’s structural. The stack is built by devs, for devs. So when something breaks, or needs changing, or needs explaining – it goes back to the people who built it. Which reinforces the model. Which deepens the dependency. Which justifies more abstraction. And more control.

This isn’t just a technical issue. It’s an organisational one. We’ve handed control of the web to the only people who understand the machinery. And they’re too busy fixing the machine to stop and ask whether we needed it in the first place.

Websites that work

There is a better way. And it doesn’t require a complete rewrite of the internet or a return to 2005.

We don’t need to abandon CMSs. We don’t need to ban JavaScript. We just need to stop treating every website like a software product.

Most sites need to load fast, be easy to navigate, show up in search, and let users do simple things – read, click, scroll, buy. That’s it. And we already have the tools to build that:

• Server-rendered HTML.
• Semantic markup.
• Clean URLs.
• Lightweight templates.
• Edge caching.
• Sensible use of JavaScript where it adds real value.

That could be WordPress. That could be Eleventy. That could be a custom setup. The point isn’t the tool – it’s the mindset.

Build for the user. Build for performance. Build for maintainability.

Choose simplicity over cleverness. Choose transparency over abstraction. Choose outcomes over architecture.

We can still have modern workflows. We can still version control content. We can still preview, collaborate, deploy, iterate. But the foundation has to be the web – not an app, not a shell, not a simulation.

It’s not about going backwards. It’s about stopping the freefall.

The web can work again. We just have to let it.

Reclaiming the web

If you’ve ever felt like your website is harder to manage than it should be – you’re not imagining it.

If it takes days to update a title tag, if your product pages glitch, if your blog can’t load without JavaScript… that’s not “just how it works.” That’s a choice. One made without you in the room.

So ask questions. Push back.

• “Why are we using a full JS framework for a mostly static site?”
• “Why can’t I update this content without engineering help?”
• “Why does it take a build pipeline to change a headline?”
• “Why isn’t this just HTML?”

You don’t need to write code to challenge architecture. You just need to make outcomes the priority.

And remember – complexity isn’t just a technical burden. It’s a financial one. More engineers. Slower launches. Higher maintenance. Less agility. When the stack bloats, so do the costs.

Faster sites. Easier publishing. Better rankings. Happier users.

You can demand those things.

Because they’re not unreasonable. They’re what the web was built for.

And it’s time to start demanding better.

Ask more. Expect more. Push for outcomes, not architecture.

The web isn’t broken by accident. It’s broken by design. And we don’t have to accept it.

That doesn’t mean frameworks have no place. Large or distributed teams often benefit from architectural scaffolding, shared conventions, and modular approaches. But that scaffolding is rarely right-sized. More often, it justifies itself by growing – and creates the need for even more engineers to maintain the complexity it introduced.

And yes, frameworks can be fast, accessible, and SEO-friendly. But let’s be honest: they almost never are. Not in the wild. Not without significant expertise, time, and care. Most developers don’t know what they don’t know. They rely on default configurations and magic middleware that silently breaks the basics.

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.

All fixable.
All avoidable.
All caused by choosing tools that were never built for this job.

This isn’t about going back to table layouts or banning JavaScript.
It’s about building with intent.
Understanding what the web gives us by default – and resisting the urge to rebuild it from scratch.

It’s not about purity. It’s about outcomes.
Use what works.

But question whether it’s working for your users, or just for your developers. 

Keep your files stored safely and securely with the SanDisk 2TB Extreme Portable SSD. With over 69,505 ratings and an impressive 4.6 out of 5 stars, this product has been purchased over 8K+ times in the past month. At only $129.99, this Amazon’s Choice product is a must-have for secure file storage.

Help keep private content private with the included password protection featuring 256-bit AES hardware encryption. Order now for just $129.99 on Amazon!

Help Power Techcratic’s Future – Scan To Support

If Techcratic’s content and insights have helped you, consider giving back by supporting the platform with crypto. Every contribution makes a difference, whether it’s for high-quality content, server maintenance, or future updates. Techcratic is constantly evolving, and your support helps drive that progress.

As a solo operator who wears all the hats, creating content, managing the tech, and running the site, your support allows me to stay focused on delivering valuable resources. Your support keeps everything running smoothly and enables me to continue creating the content you love. I’m deeply grateful for your support, it truly means the world to me! Thank you!