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.
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? 😉
Thanks! Yeah, that’s a tricky bit. This is now such a deeply embedded, cultural problem, that you have to tackle it right up to the point of job definitions, hiring, and team management – and if all of the ‘talent’ in the market is fundamentally the wrong shape for the problems which need to be solved, then that’s tricky indeed. But the sooner we start course-correcting that, the better!
There was no need to tell so much truth. 😁
Great article, Jono! Although curious to hear your thoughts on WordPress since you mentioned that. WordPress Gutenberg editor is built with React, and the project of Gutenberg is too big to move away from React into standard web technologies now. React only live inside the editor, it will not ship to front-end. So users will not suffer from the heavy JavaScript. But for developing custom blocks for the editor — since it requires developers to work with React — it increases complexity and require a build step. I have a mixed feeling about this. Your thoughts?
Setting aside how poorly Gutenberg / Full Site Editing / The block editor etc have been handled, and what a mess working with them in JS is (whilst still juggling half of the ecosystem in PHP, amidst constantly changing/experimental JS APIs)…
React / similar is definitely the right choice for modernizing WordPress’ back-end and content editing experience.
What I have read, oh gosh, someone out there really putting his guts to call the dream programming language of today’s developer A big Mess and Junk. Couldn’t agree more with you Jono, this is really amazing.
I was in that era when people used to call PHP a trash, then I was like arguing with them, me being a developer mastered PHP then learned JavaScript, and after 10 yrs I say i am back at PHP. JavaScript did nothing new.😅😅
Why JavaScript? The fault is just on all the frameworks using typescript.
Modern Vanilla JS is the future!
My god, finally someone’s said it. UX has been getting worse and worse and nobody can remember what it was like because when design is good, its invisible.
JavaScript should have never become a serious programming language. I loved it when it was used for alerts and stuff like that.
I’ve been developing websites since the 90s, and experienced all the trends come and go first-hand in that time. I’ve watched it become more and more needlessly complex, while I keep on making my simple websites with HTML, CSS, vanilla JS, and whatever backend language I feel like using for that moment.
I pride myself on making reliable websites capable of being performant on low-powered hardware. That’s my measuring stick. If it works well there, it’s more than capable on regular hardware.
I’m glad more people are saying this because the web is already a massive layer of abstraction. We need only to add to that when absolutely necessary.
Do you know why frameworks became a trend in the first place?!
It’s because PPL never really wanted to invest in CMS when they can code it for free.
Or perhaps some can’t afford it.
A masterclass in design and dev economy. GenAi overcomes petulant developers with their passive aggressive hold on delivering simple workable scripts.
Excellent article. I share your frustration.
The quality of software has been on a downward trajectory in general. I like you feel that the root cause is over abstraction. An issue that now presents itself is that newer developers have only ever worked in these abstractions. So have been accustomed to bloat and complexity. Which leads to poor end user experiences.
It’s not just the web, my car has crap software, apps on my phone suck, games are regressing, and movie cgi is getting worse. The root cause? Developers are not as skilled as they once were, because they do not work with the limitations they once had.
No dev in 2025 is fit to build roller coaster tycoon alone in assembly.
The car info system is the worst. I’m yet to see a car info system that is not crap
Wait and see what the effect of these AI tools have. Not only are they trained on vast amounts of basic React starter apps, but the code quality is average. Naturally.
So even for a really basic website, “the default” is React. Of course it is not React’s fault. But at least for a while longer, user experience will only mean flashy design and, maybe, a clever headline and an AI generated image.
The real UX gone. But I’m sure things will turn around eventually.
I agree that using what works, or I would say that choosing the best tool for the job is the way to go. That being said, I have no desire to go back to the early web ecosystem with JavaScript being sort of a minor assistant to some tasks.
Remember the good old days of Frontpage and Dreamweaver which put hacky, unreadable code into your pages to make it “work.” Both browsers and JavaScript have come a long way, but building just for the user experience won’t solve the eventual maintenance nightmare. Everyone plans for the feature, or in this case the page, but no one remembers in 2 – 3 years why this was done or the ever-changing landscape that has to be followed. WordPress is great for personal sites and some companies, but for government work it is a challenge that its not up to; PHP being the main security nightmare.
All this said, I am a software engineer that has had quite a career so I speak from experience. This might not be everyone’s experience, but this was mine.
As a developer, I’ve been guilty of trying out a new stack on a new branch of a project. It’s good for the CV/resume, and I got an informed opinion of what works and what doesn’t. Did I over complicate things? Sometimes. However, you didn’t address two related issues.
Many times I wrote simple functioning conventional code, only to be told by a boss (customer, team lead, project manager, product manager, peer who was de facto boss)
* That’s not splashy enough. When I press the button I want it to shimmy and shake and disappear into a splash of rainbow.
* When I press a navigation link, the content should already have been preloaded and rendered, ready for display.
* My grandmother loaded our home page in Netscape Navigator 3.0, and it looks awful. Fix it.
* I love the flashy wiz bang. Now make it work that way if JS is turned off.
I think the committee approach is to blame, with the developer being a major member of it,
Another blame must come from the conflict between web pages and applications. People demand the best of both in a monstrous hybrid that is neither.
Yes, we’re in a complicated Jenga stack. Every time I hear about another language, library, framework, server store, web standard, … I feel sick. We can do it with a simpler stack only if we agree on when is enough enough. My experience was I was saying “No” more than the rest of the committee, so it hurts when you blame me even as I acknowledge that I’m not without blame.
Agreed! I’m hopeful that CSS view transitions (in conjunction with speculation rules and swishy animations) make a lot of those demands not necessarily require a JS framework.
I think I disagree with almost every word of this article, at least 90% of it, but it’s way too long for me to point out everything that was wrong.
Even the premise of the article (the web is getting slower) is entirely incorrect and backed up by no evidence.
Agreed!
It’s fine if you disagree but you can’t provide any points refuting the article?
I’ve always worked on bonafide apps, not blogs and such. I do agree that for simple sites and static sites, react is very much overkill though! I think some of the friction causing people to reach for react for simpler sites is easy reusable components. There are web components but in my experience they leave a lot to be desired compared to the simplicity of using react.
I’ve been saying this on my youtube / twitch streams for over a year now (going almost two years) and debating with people online about these very topics. I have not yet heard any good *logical* arguments why this move towards complexity was *good*. All I get back is anecdotes and personal feelings.
If you want to see what I’m up to: spirofloropoulos dot com has links to my content
This is insane and I speak out loudly about it. As a result, I’ve angered a lot of “big” people and it’s become difficult for me to even find work because I get looked over for saying pretty much what you’re saying here. It’s crazy.
Nice article. My company’s website is fully static (except the contact page), generated on-premise using Hugo. The result: it’s fast and not bloated at all.
BTW, I think CSS is also broken… What do you think about this?
That is exactly what I feel! It took some time for JavaScript to become what it is today. And for a while jQuery was a great help. But today I feel that I can do everything with plain “Vanilla” JavaScript! Who needs these bloated frameworks with their megabytes of libraries behind them and pages of boilerplate to set them up?!?
I think this is a fundamental misconception of problems that exist with a smattering of half truths.
In the early days no one understood how to use WordPress or other CMSs to edit and build pages. They learnt.
It’s now looked back on fondness with people who learnt their trade here and never moved on. You have forgotten the nightmare that used to existed with old CMSs
You might be right about over engineering but that was the case before the “modern JavaScript” stack.
Are you sure? Which stack?
One of the best articles I have read on the topic in a while and aligns at 100% with my thoughts.
New patterns and libs have emerged over the last few years offering the best of all worlds, e.g htmx, live view/wire, data star etc., considerably simplifying the stack, offering progressive enhancement, putting true agility back on the table whilst adhering to and embracing web standards and semantics.
Hats off for writing this beautiful piece of tech poetry with such elegance.
THIS!
The irony of a post preaching the virtues of reducing our dependency on JavaScript but itself requires JavaScript to be read.
In what way does this require JS to be read?
🎯
Pretty preachy. But I think you got it backwards, JS is more powerful than any of these frameworks, that’s why we use the frameworks. Engineering is about restricting infinity and controlling power/energy. It’s more about keeping 200 developers consistent than anything else… jquery can be used and architected many many many many ways… react, 2 or 3 work well… even then, when when you mix the 2 or 3 react approaches it can be a disaster. Abstractions are Leaky, mixing them is an ocean.
Instead of two mobile developers for each platform and windows desktop developer you now have a Web front end developer who can cover all your ui needs. Total disaster, I agree :))
I hear you. I agree with you. I completely understand that a JS tool/lib/framework, in the hands of devs are often misused, resulting in broken web standards and bad UX.
On the other hand I do feel that writing standalone vanila JS can sometime feel disconnected with the rest of the setup. Both *ends either stays unaware or throws a ball assuming the other would catch.
Let me answer these questions from my perspective. I understand that these answers would not apply to all. A select few scenarios would still qualify.
“Why are we using a full JS framework for a mostly static site?”
– Only in the codebase to separate the templates, pages and content (MD). A JS bundler or Node js scripts helps me compile HTML pages. I don’t trust myself with final the HTML files. No JS is delivered to the browser.
– As static site grows in page count, choose to take: no action, JS loads MD renders HTML in browser, or bring in a server to render/cache HTML pages. I would choose a JS stack.
“Why can’t I update this content without engineering help?”
– In most content driven system we can, via CMS or MD files. Any team that says no didn’t design the system properly.
“Why does it take a build pipeline to change a headline?”
– With a CMS, we dont.
– With a template system to keep layout, pages, and content seperate, it must.
– Best let it run on a CI rather than on a developers machine.
– Better visibility and accountability to all stakeholders.
“Why isn’t this just HTML?”
– It can be as long as there is just a handful of pages and a couple of authors. Pages with easier to maintain content.
– Anything slightly more, would be best to be split up as layout, pages, and content. The final output is still HTML, just built by a system, without human intervention.
There’s always light at the end of the tunnel. There are talented people bringing out frameworks with web standards in front and center. Experienced dev are understanding the value of web standards, avoid broken experiences. I hope by the time I hang up my boots, the industry would be in better, open and standard place.
It’s completely naive to blame JS for the corporate web turf war. JS is simply the only language of the greatest platform in the world, the internet, it’s extremely powerful and expressive, making it the ideal language to start and also to master.
The real problem are naive devs coming into the space believing all the fake corp propaganda from bigtechs and investment funds, where the goal is always to increase user base, to drive market share and shift the efforts in their favor.
Years of corporate propaganda abuse made newcomers absorb the worst kind of gimmicks promising the best and always delivering bloated unusable garbage, where simple trivial things made in JS now require tons of framework documentation digging, usually with trash that ARE NOT JS. REACT ISN’T JS. ANGULAR ISN’T JS. TYPESCRIPT ISN’T JS.
It’s totally tragic when “progress” is driven by propaganda, FOMO, fear of recruitment rejection, and corporate greed.
JS make websites better when used right, while the most popular tools/libs/frameworks today are completely bogus incoherent pile of steaming poo. Angular, React, Typescript are all useless artificial propaganda oriented corporate slop making the web what it is now.
Most people have no discernment, experience or enough knowledge to talk about this subject properly. Inexperienced devs in web wizardry thinking they know something have the distorted behavior of blaming JS when the real enemy is the abusive market share dispute at the expense of the sanity of naive gullible devs.
Yes. It’s a lot about being a cool developer or a cool company and using development work as a childish playground to serve all the egos involved,
The real developer question would be: Can I implement this without JavaScript? If CSS is capable of doing it, the answer is yes. But never ask a JS developer, because that would not only be disrespectful, but also a clear sign of your incompetence.
We’ve ended up in a ridiculous state because we don’t know how a mobile menu could be opened if not with JavaScript or, even worse, jQuery. There is (almost) no simple form on the CMS internet that doesn’t stop working if JS is broken.
The overuse of JS (and WP nonces on public pages, lol) are a real disease of today’s web, causing it to weaken and load slowly on mobile devices.
Or, like Steve Souders said years ago:
“Ten years ago the network was the main bottleneck. Today, the main bottleneck is JavaScript.”
Wait. You think websites have some sort of future? Tell that to my homemade agent that’s completing this post while I make coffee.
Great article The comparison of UX to DX is just brilliant and explains so many of the problems we currently have.
It’s really the fault of browser vendors.
Rather than focusing on features to meet the needs of modern web applications (like web assembly, fixing multi threading, memory efficiency), they focus on tracking features and crap like manifest v3.
Let me write my efficient multi-threaded web application in Rust.
Add features to the browser to make it more powerful.
Microsoft, if you’re listening, that’s how you get me to use Edge – not by tricking me into not realizing I’m using it
Wow. Nice to see someone has the courage to speak the truth, with solid research. Hope to see same for Python.
Great article, and right on! I still remember with disdain a certain WordPress framework that I abandoned after it crashed and wiped out my progress – the second time.
But before then, I was perplexed by the need for 20 nested DIVs of different classes and database access to display a headline. In the end, I threw out that framework, and WordPress along with it, and did it with plain old HTML, CSS, and JavaScript. OK, there is some PHP and MySQL on the server, but that’s for dynamic content.
Far too much complexity invested in simple tasks. And it’s not just one framework, it’s Node js, REACT, Vue, Laravel, Drupal.… Enough is enough.
You never get to building a site because you spend decades learning new frameworks. (Don’t get me on “New awesome programming language of the week.”) Two contributing factors to the mess: Corporations that want a new shiny bauble to sell, and developers who want to leave a legacy. We can’t all be Stroustrups.
Many developers now a day is mad after only two terms “modern” and “popular”. Many people who teaches the topic, focus to much on them. My ears are aching hearing those terms.
Vanilla JavaScript is still fast and beautiful. You’re speaking more on Frameworks and NodeJS. (I refuse to accept NodeJS as JavaScript.). The web is ever evolving. The amount of change from 2010 to 2015 was huge.. Thing’s might look bad now, but I promise you, they will be unrecognizable in 2035.
Music to my ears. I spent the last 10 years asking if everybody is mad or just me. I could never understand why replace PHP with JS and why replace SQL with mongo no SQL Jason based bs. Why people are shooting canons at flies.
But now, finally, more and more voices support simplicity, because the purpose of web design are the websites, not the tech behind them.
This was fun😂.
In my opinion it’s not a coincidence that React was created and is pushed by a company whose objective is to move the free web insite its walled garden where you have to pay them to show content to your users (that become their users…)
Great article, well written. I remember the old days when I can build a fully functional site without JS. I usually took it as a challenge to achieve things with only HTML+CSS. Oh God! Those sites used to load faaasst. I think the way to go is for developers to focus on achieving things on the server rather than on the client.
It used to be one job, web developer (full stack), as long as we keep creating different titles, the more complex the web becomes.
A bit of a rant, but fundamentally you’re right.
I think there is a midpoint between what you are saying and the truth. Saying the web hasn’t progressed is just wrong, at least in my opinion. I do think the frameworks have a place and that some of that complexity was necessary.
That being said, i also agree 100% that MOST of that complexity is just for the sake of complexity, and that most devs just like to “feel smart” by making unnecessary changes. A big example that i suffer everyday in my job is micro-frontends. A literal complexity hell that has nearly 0 advantage, unless you have a very specific, very oiled team architecture, which nearly nobody has. Like that, there are countless more examples, ranging all the way from architecture, testing, and more places.
The problem is that a lot of times, these are like fashion, people start talking about it, and think that “this is the future”, and nobody will stop them from using them, until it is too late and making the change means remaking your whole codebase, almost.
A lot of this complexity is pushed by vendors who have created those frameworks and patterns so that they can reap from them and devs have fallen for it, hook, line and sinker. We have devs today who can’t believe that you can host a complete website on a $5 a month plan. The vendors have told them you need a $50 plan, then add $60 for your database, then $5 for caching, then a different service and platform to host and serve your images for $10. And wait you also pay for your users, your plan caters for the first 10K users/visitors and then $0.003 for the next 1K users. Its madness, it’s a cult where people are afraid to ask questions, where you have to do what the tech “influencers” tell you to do.
Quite. The cult of Vercel has a lot to answer for.
Yes! I always find this perspective refreshing. I wrote a book for O’Reilly about it in 2007 “Unobtrusive Ajax” and am glad people are still spreading the good word.
Personally I’m a huge fan of Svelte and SvelteKit, which might seem antithetical to your message, but honestly it’s the closest thing to static HTML out there, except it’s a big improvement on the static web. Plus you can very easily build sites that don’t depend on JavaScript at all! I love it deeply, have used it exclusively for years, and encourage people to try it out if they care about the web.
I agree with some of what you say but trying to solve JavaScript bloat with WordPress is like cutting your head off to fix a migraine. If you are developing for the web and can’t achieve what you want with html and CSS then you are going to need JavaScript in some shape or form. As developers typically solve the same sorts of problems, frameworks have their place. They also often make it easier for developers to collaborate. The problems come when a framework is used where a simpler solution or just vanilla JS would do. The dilution of tools and frameworks etc is also a big problem, especially for new devs. It can take half a day before you even have your development machine setup for working on a particular project.
Well, the other part of the truth is that HTML and CSS are bloated, insufficient, and full of quirks. That’s why people started hacking/patching the web with JavaScript in the first place.
Try to develop a modal window in pure HTML and CSS, or a menu. Yes, it is possible, anchor positioning is maybe baseline today, native modals are already in HTML, but these are very recent additions and might not work everywhere. Or try to implement a typeahead or autocomplete, there is a <datalist /> now, I’m not sure how that works from a11y perspective and it might not suit everyone…
That’s why people start learning from React, because there are components you “render” and it does it’s job. It gives you 80% of what you want with 20% effort, and even that effort is too much for many developers, so they have a problem grasping React.
Like in a typical Pareto, solving the remaining 20% of the web-page, requires 80% added effort, and here we are with modern CSS and proper HTML template because once you start to use <table> for tabular data and <form> with <fieldset> then you have to override the user-agent styles, and elements like <tr> or <legend> are _full_ of CSS quirks.
So people are lazy, they want to build a _beautiful_ UI, and they don’t have experience, and there are paved ways in frameworks to do that. Building a beautiful web page without JavaScript is a task for a real craftsman, and these are rare. So rare, that even the LLM copilots don’t know how to build a _proper_ web, because the majority of examples they learned on are broken.
So to fix the situation we are in, we would need to fix the standards so HTML and CSS allows you to build _beautiful rich_ UI with ease. I don’t think it is possible.
Hello, I have been working as a publisher in Korea since 2011. It’s already been 15 years. I can’t say that I know everything about the job, but after working in this field for so long, I do feel I’ve developed a certain level of expertise.
The term “publisher” as a job title is known to be unique to Korea. From what I understand, this role was first established by a Korean, and although the word “publisher” does exist overseas, I’ve heard that there isn’t a dedicated position focusing solely on publishing tasks, like we have here. Even if this isn’t entirely accurate, it doesn’t matter much to me.
Before the publisher role existed, there were mainly just designers and developers. Designers were usually responsible for markup, and developers took care of scripting. Then, around 2009, the new role of publisher started to emerge. I began working as a publisher in 2011, and back then, the job covered a wide range of tasks, including markup, CSS, UI development, and even some front-end development.
However, a couple of years after the publisher position was created, its meaning started to change. As educational institutions began to train publishers, many designers and developers transitioned into this role. As a result, publisher tasks often became limited to markup for designers or just scripting for developers. This gradually pushed out the front-end development aspect from the publisher’s job.
When I started in 2011, I was still involved in UI development, but the term “front-end developer” didn’t really come into the spotlight until around 2016 or 2017.
To be honest, I had a good impression of earlier front-end or back-end developers, but I’ve felt a bit disappointed with some of the newer front-end developers. As the focus in the industry shifted more towards front-end technology, I felt that the unique value of the publisher role was being diminished.
Especially with the rapid adoption of various DX (developer experience) tools, there were more cases where inconsistent UIs were planned from the very beginning. For publishers, this often meant having to create individual UIs one by one, which was quite challenging.
When I tried to talk about these issues, I found that many front-end developers were convinced that their way was always right, and weren’t very open to discussion or communication.
On top of that, in most of my projects, I have been the only publisher on the team. Usually, there would be one publisher per project, sometimes two designers, and quite a few developers. So even when I voiced my opinions, they were often overlooked. It’s always been a bit disappointing that rational communication hasn’t been easy.
Maybe that’s why the article I read today resonated with me so much.
I was into the early web in the 90s, CSS was still brand new. Then I mostly skipped web design for 20 years and got back in a couple years ago.
The first thing I found is I hate frameworks and (mostly) hate JS. React is a nightmare. The NPM ecosystem is one giant supply chain attack and/or vulnerability.
The WordPress ecosystem is a security nightmare that serves pages like molasses.
I’ve recently taken my site back to nearly pure HTML/CSS and templating through SSI and it feels SO GOOD to be able to open the actual live HTML file and make an edit if I feel like it.
And coming off WordPress, the feeling of speed is incredible. My “site generator” Is just a short bash script that updates the sitemap, archive, index, and slaps the header and footer SSI includes on everything. All in the time it would take the WordPress admin panel to load once, let alone click on anything.