JavaScript Broke the Web  ## Metadata - Author: [[Jono Alderson]] - Full Title: JavaScript Broke the Web - Category: #articles - Document Note: --- tags: - #javascript - #webdevelopment - #softwareengineering Author: Jono Alderson Source: jonoalderson.com Reference: https://www.jonoalderson.com/conjecture/javascript-broke-the-web-and-called-it-progress/ date created: 2025-06-19 20:35 --- # Title: JavaScript Broke The Web (And Called It Progress) ## Table of Contents:  - 📝 Summary - 📖 Main Content - 🗒️ Notes - 📖 References - 🗣️ Paraphrase - 📰 Newsletter - ✅ Action Items - 🧪 Hypotheses - 📊 Methodology - ❓ Questions - 🔮 Future Research - 💡 Implications - 🧠 Learning Styles Assessment - 📊 Accessibility Assessment - 🌍 DEIB Assessment - ✅ Logical validity - 🔍 DARVO Analysis - 🔍 SEO Evaluation - 🎯 Conclusion ### References: - Alderson, Jono. "JavaScript Broke The Web (And Called It Progress)." jonoalderson.com, 2023. - Various links embedded in the article for supporting arguments (e.g., historical references to HTTP/HTML, JS adoption stats, and critiques from web experts). ## 📝 Summary: Jono Alderson argues that the rise of JavaScript (JS) has paradoxically "broken" the web under the guise of progress. While JS has enabled rich web applications, it has also caused increased complexity, performance degradation, security issues, and accessibility challenges. This shift prioritizes flashy client-side experiences over the fundamental strengths of the web: speed, openness, and universality. The article critically examines how the web community embraced JS growth uncritically and calls for rethinking the tech stack towards a more performant, accessible, and respectful web. ## 📖 Main Content: The article traces the transformation of the web from a lightweight, universally accessible platform to a JS-heavy ecosystem dominated by large client-side frameworks and single-page applications (SPAs). Alderson critiques how this has led to: - Slower page load times and higher energy consumption. - Accessibility issues for users on low-end devices or with disabilities. - Fragmentation due to differing browser JS engines and complexities in debugging. - Security vulnerabilities introduced by complex JS codebases. - Loss of the “web as a document” model in favor of app-like experiences. The author emphasizes that many JS enhancements serve commercial interests—maximizing engagement and ad revenue—rather than user experience or technological necessity. He highlights alternative approaches emphasizing progressive enhancement, server-side rendering, and leaner, more semantic HTML and CSS. The piece concludes with a call for developers, browser vendors, and companies to prioritize web fundamentals over JS bloat and embrace a "back to basics" mindset for a sustainable future. ### 🗒️ Notes - **Historical context of JS:** - Introduced in 1995 to make web pages interactive. - Initially small and complementary to HTML/CSS. - Explosion of frameworks and libraries (React, Angular, Vue) has increased complexity. - **Performance issues:** - Heavy JS increases load times and CPU usage. - Mobile and low-bandwidth users disproportionately affected. - JS-heavy sites drain battery and consume more data. - **Accessibility challenges:** - Screen readers and assistive tech struggle with dynamic JS-driven content. - JS reliance creates barriers for users with disabilities. - **Security risks:** - Complex JS code creates attack surfaces (XSS, supply chain attacks). - **Developer experience & fragmentation:** - Debugging JS issues across browsers is difficult. - Fragmentation in browser engines complicates development. - **Web as document vs web as app:** - Traditional web served static content accessible to all. - Modern SPA and client-side routing blur URLs, break back buttons. - **Commercial incentives:** - Ad-driven sites push heavier JS to maximize user tracking. - Engagement prioritized over performance or privacy. - **Alternatives & solutions:** - Progressive enhancement: HTML first, JS adds improvements. - Server-side rendering reduces client load. - Emphasis on semantic HTML and CSS. - Better tooling and education for developers on lean web practices. ## 📖 References: - Alderson, J. (2023). JavaScript Broke The Web (And Called It Progress). https://www.jonoalderson.com/conjecture/javascript-broke-the-web-and-called-it-progress/ - W3C Accessibility Guidelines - Browser performance reports (Google Lighthouse) - Web.dev on Progressive Enhancement ## 🗣️ Paraphrase:  1. Original: "JavaScript’s rise has brought about a paradox: the web is more powerful but also more broken than ever. We now have beautiful, interactive experiences—but at the cost of speed, accessibility, and openness." Paraphrased: The growth of JavaScript has created a contradiction where, although web experiences have become richer and more dynamic, this progress has simultaneously compromised the web’s fundamental qualities like fast load times, ease of access, and universal availability. 2. Original: "The commercial motivations behind JavaScript’s proliferation have led to bloated, inefficient websites that prioritize engagement metrics over user respect and performance." Paraphrased: Business interests driving widespread use of JavaScript have resulted in websites that are overloaded and slow, focusing more on capturing user attention than on delivering respectful, efficient experiences. ## 📰 Newsletter: Hey WordPress community! This week’s spotlight dives into the rise and pitfalls of JavaScript on the modern web. Jono Alderson’s thoughtful critique challenges us to rethink how we use JS, urging a return to the web’s core strengths: speed, accessibility, and simplicity. As developers and advocates, it’s a timely reminder to build sites that are lean and inclusive, not just flashy and heavy. Check out alternative strategies like progressive enhancement and server-side rendering to keep your projects sustainable and user-friendly. Plus, stay tuned for updates on plugins that embrace these principles and boost your site’s performance. Let’s keep the web open, fast, and welcoming for everyone! ## ✅ Action Items: - Advocate within GoDaddy and WordPress circles for educating developers about the impact of excessive JS on accessibility and performance. - Develop workshops or talks that promote progressive enhancement and server-side rendering techniques. - Encourage adoption of measurement tools (e.g., Lighthouse) to track performance and accessibility in WordPress themes and plugins. - Push for sustainable funding models that support open-source projects prioritizing lean, accessible front-end solutions. - Align my OSPO leadership aspirations with fostering best practices that balance innovation with web fundamentals. - Promote community discussions on ethical considerations around user engagement vs. respect and privacy. - Include these insights when onboarding new contributors to emphasize quality and sustainability in open-source projects. ## 🧪 Hypotheses: - Reducing JavaScript payload on websites improves user retention and accessibility scores significantly. - Progressive enhancement strategies result in better SEO rankings compared to JS-heavy single-page applications. - Sites optimized for minimal JS usage consume less energy, reducing environmental impact for users on mobile devices. - Developer education focused on lean web principles leads to measurable improvements in code quality and maintainability in open-source projects. ### 📊 Methodology: - Conduct A/B testing on websites with heavy JS vs. progressively enhanced versions to compare metrics like load time, bounce rate, and accessibility compliance. - Analyze SEO performance data over time for sites shifting from SPA to server-rendered or static approaches. - Measure energy consumption using browser profiling tools on mobile devices for different JS usage levels. - Survey developers before and after educational interventions to assess changes in coding habits and project quality. - Use data from open-source project repositories to track adoption of recommended practices over time. ### ❓ Questions: - How can the WordPress ecosystem better balance the use of JavaScript with core web principles? - What incentives could motivate large - Summary: We replaced simple websites with complex apps nobody asked for. Now it takes a complex build pipeline just to change a headline. - URL: https://www.jonoalderson.com/conjecture/javascript-broke-the-web-and-called-it-progress/ Independent technical SEO consultant Menu  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. Some content could not be imported from the original document. [View content ↗](https://www.google.com/recaptcha/api2/anchor?ar=1&k=6LcF9HQUAAAAAJ6SsHh16_7OyBCozw4Yv97iLkQx&co=aHR0cHM6Ly93d3cuam9ub2FsZGVyc29uLmNvbTo0NDM.&hl=en&v=GUGrl5YkSwpBsxsF3eY665Ye&theme=light&size=normal&cb=xp8fyjg839q6) I agree on everything you said here, Jono! Thanks for speaking up for a better web. Web performance is part of the product and not a nice to have (same for accessibility, discoverability..). There a barrier for questioning this…how can developers keep being employable if they stop pushing shiny modern frameworks skills in their CVs? 😉 Reply #### I'm speaking at... ##### SEOktoberfest / G50, 2025 2025-09-21 / 2025-09-26 Stanglwirt, Austria  #### 📣 Hire me! I'm an award-winning consultant, and I'm available for hire. Ready to take your website's **technical SEO**, **performance**, or **structured data strategy** to the next level? [Hire me as a consultant](https://www.jonoalderson.com/contact/) © Copyright 2025 [Applied Energistics LTD](https://www.appliedenergistics.co.uk/). JonoAlderson.com is operated by Applied Energistics LTD - a company registered in England and Wales (Company # 11681212), at 38 Jute Road, York, YO26 5EN, United Kingdom, JavaScript Broke the Web, Jono Alderson, 01jy5ck7jmqmezjwdf34ty8vcx.