The era of needless frontend tooling is ending. The native web platform has won. AI is about to finish the job.

We've been here before.

In 2009, CoffeeScript arrived as the darling of the JavaScript world. It offered cleaner syntax, arrow functions, classes, destructuring — everything JavaScript lacked. Developers flocked to it. GitHub's internal style guide literally said "write new JS in CoffeeScript". Dropbox rewrote their entire browser-side codebase in it. It was the future.

Then ES6 landed in 2015. JavaScript adopted arrow functions, classes, template literals, destructuring — features CoffeeScript had pioneered. Overnight, the value proposition collapsed. Why maintain a compile step, learn a separate syntax, and deal with tooling friction when the platform itself had caught up? CoffeeScript went from darling to dead in a few short years. Today, most frontend developers don't even know it existed.

The pattern is clear: when the platform catches up, the abstraction dies. And right now, the platform is catching up across the board.

CSS Preprocessors: Mission Accomplished

For over a decade, Sass, SCSS, and Less were essential. Native CSS lacked variables, nesting, and any kind of logical structure for organising styles at scale. Preprocessors filled a genuine gap.

That gap has closed. CSS custom properties (variables) have had universal browser support since 2017. Native CSS nesting shipped in all major browsers in late 2023 — Chrome 112+, Firefox 117+, Safari 16.5+. The @scope rule, container queries, color-mix(), clamp(), the new media query range syntax — CSS has absorbed the features that justified preprocessors in the first place.

If nesting was the main reason you were using Sass, you can go vanilla now. No build step. No node-sass vs dart-sass migration headaches. No dependency to maintain. Just CSS, interpreted directly by the browser.

There are edge cases where preprocessors still earn their keep — BEM selector concatenation, file splitting without @import performance hits, complex mixins. But for the majority of projects? The overhead is no longer justified. The platform is enough.

TypeScript: The CoffeeScript of the 2020s?

This is the more contentious one. TypeScript rides high, and questioning it publicly tends to trigger the same response DHH got when he dropped it from Turbo 8 — PR vandalism, meltdowns, and a lot of people who'd never used Turbo showing up to defend TypeScript's honour like it was a religion under attack.

But the cracks are showing, and they're being opened by serious people with serious projects.

Rich Harris, creator of Svelte — one of the most admired frameworks in the JavaScript ecosystem — migrated the Svelte core codebase from TypeScript to JavaScript with JSDoc annotations. His reasoning was pragmatic: "types are fantastic, TypeScript is a bit of a pain." The friction of the compile step, the tooling inconsistencies, the overhead for library development — it wasn't worth it. SvelteKit had already been written in JavaScript and distributed as source code with no build step. Harris called the result "miraculous for productivity."

DHH, creator of Ruby on Rails, dropped TypeScript from Turbo 8 entirely, calling the type gymnastics code pollution that added "ever so little joy" and "quite frequently considerable grief."

Node.js itself added native type stripping in v23.6 (enabled by default), letting you run .ts files directly by simply erasing the type annotations. No transpilation, no build step. The runtime just ignores the types. It's telling that the approach Node chose was literally tothrow the TypeScript awayand run the JavaScript underneath.

And then there's the TC39 Type Annotations proposal — a Stage 1 proposal to add type annotation syntax directly to ECMAScript, treated as comments by the JavaScript engine. If this progresses, you'll be able to write typed JavaScript that runs natively in browsers without any compiler at all. Static typing was the most requested feature in the State of JS survey every single year it was tracked. The standards body is listening.

The parallel to CoffeeScript is hard to ignore. CoffeeScript gave us features JavaScript didn't have. The standards body adopted those features. CoffeeScript died. TypeScript gives us types JavaScript doesn't enforce. The standards body is working on native type syntax. The trajectory is the same.

None of this means types are bad. Types are valuable. The question is whether you need a separate language, a separate compiler, a separate build step, and a separate set of tooling headaches to get them — or whether the platform will give you what you need natively, the way it did with arrow functions and classes.

The Copycat Problem

If you ask most teams why they use TypeScript, the honest answer for many would be: because everyone else does. It's the same cargo cult mentality that drives React adoption. "Nobody got fired for choosing TypeScript" has become the new "nobody got fired for choosing IBM."

There's a difference between teams that have critically evaluated TypeScript, weighed the overhead against their specific needs, and made an informed decision — and teams that ticked the TypeScript box because the job listing said to. The second group is far larger than the first.

This isn't gatekeeping. It's an observation that the industry has a herd problem. The loudest voices defend their stack choices with the fervour of the converted, not the nuance of the pragmatic. DHH's Turbo PR attracted people who had never used Turbo, showing up to vandalise the repository. That's not technical discourse. That's tribalism.

Enter the Machines

Here's where it gets interesting.

We're approaching a time when most code will be written and maintained by AI agents. This changes the calculus fundamentally.

The benefits of TypeScript — better autocomplete, compile-time error catching, self-documenting interfaces — were benefits for people. They helped humans navigate large codebases, catch silly mistakes, and understand code they didn't write. These are real benefits. But they're benefits designed for the constraints of human cognition.

AI agents don't have the same constraints. They don't need autocomplete. They don't need type hints to understand a function signature. They can read and reason about vanilla JavaScript just as effectively as TypeScript. What they do benefit from is simplicity — fewer tools in the chain, fewer configuration files, fewer build steps that can break, fewer abstractions between the code and the runtime.

A clean, simple stack is easier for an AI agent to reason about, modify, and maintain. Every layer of tooling is a layer of potential failure, a layer of configuration drift, a layer where the agent needs to understand not just your code but the tool that processes your code. TypeScript, Webpack, Babel, ESLint with dozens of plugins, Prettier, tsconfig.json with its maze of options — that's a lot of machinery between "what you wrote" and "what runs."

Strip it back to JavaScript, CSS, and HTML, and the gap between source and execution narrows to almost nothing.

The Death of Component Library Dependency

The same logic applies to large component libraries. The old model was: pick a generic UI library — Material UI, Bootstrap, Chakra — then spend days customising it through someone else's CSS naming conventions, overriding their defaults, fighting their specificity, wrapping their components to match your design. You'd trade the cost of building components for the cost of bending someone else's components to your will.

In an AI-assisted world, this trade-off inverts. Generating a bespoke button component that does exactly what you need, styled exactly how you want, is fast. Faster, often, than figuring out which combination of props and CSS overrides will make a library component behave. The component you generate has no dependency chain, no version to maintain, no breaking changes from upstream, no bundle weight from features you don't use.

Design patterns become more important than generic libraries. A pattern is portable, understandable, adaptable. A library is a dependency. When code is cheap to produce, patterns win.

Where the Economics Changed

This is the crux. The economics of code production have fundamentally shifted, like Alderaan to the Death Star.

Code has gotten much cheaper to produce. This is simultaneously the promise and the peril of the next chapter of software development. The double-edged sword the industry needs to contend with.

The harsh reality is that there will inevitably be fewer developers needed. A single person with AI agents and the right skills can now do what previously required a team of five or ten. Companies are already waking up to the possibility that one sharp engineer with the right tools is the engineering department. The one-person team isn't a fantasy — it's an emerging economic reality that changes hiring, team structure, and what it means to be a professional developer.

This raises an uncomfortable question every developer should be asking themselves: are you a professional, or are you playing make-believe?

Because there are two groups emerging, and the gap between them is about to become a chasm.

The first group is the cosplay devs. They look the part. They've got the mechanical keyboard, the dotfiles repo, the strong opinions about tabs versus spaces. But they've never designed a simple system in their lives. Every attempt at architecture was over-engineered, over-complicated attempts to baffle with bullshit — layers of abstraction justified by "what if we need to swap out the database" (you won't) or "this ensures our event-driven microservice mesh can scale independently" (you have twelve users). The cosplay dev hides behind complexity because complexity looks like competence to people who can't tell the difference. Hand them AI tools and they'll produce more of the same, faster. Mountains of over-engineered slop, slathered in frameworks and libraries, because that's what they've always done and that's what the training data reinforces.

The cosplay dev has never shipped something that people actually use at scale. They've never had the scaling problems that come from having customers, because they've never built something customers want. They've been too busy perfecting their abstraction layers.

The second group are the professionals. Engineers who understand they're here to solve problems, not to write code for its own sake. They accept AI code generation as a tool that, while needing steering, frees them to focus on the actual problem at hand. They actively steer their agents toward simplicity. They know that the best code is the code you don't write, and the second best is code that's easy to delete.

This second group will reach for patterns over libraries. Implementation plans over framework documentation. Clear problem decomposition over clever abstractions. They'll choose Go over Java, WebComponents over React, vanilla CSS over Tailwind — not because they're contrarian, but because simpler systems are easier to understand, debug, and change. These are the developers who will thrive as one-person teams, because they were always solving the problem — not performing the role.

The Security Argument: Every Dependency Is an Attack Surface

This isn't just about developer ergonomics. It's about security. And the data here is damning.

Sonatype's 10th Annual State of the Software Supply Chain report (2024) tracked over 700,000 malicious open source packages since they began monitoring in 2019. The growth is exponential — a 156% year-over-year increase. Of those 700,000+ malicious packages, over 512,000 were discovered in the last year alone. And here's the kicker: npm accounts for 98.5% of all malicious packages observed. The JavaScript ecosystem's package registry isn't just the biggest — it's the most targeted by a country mile.

The financial impact is staggering. Cybersecurity Ventures predicts the global annual cost of software supply chain attacks will hit $60 billion in 2025, rising to $138 billion by 2031 at 15% year-over-year growth. Gartner predicted that by 2025, 45% of organisations worldwide will have experienced a software supply chain attack — a three-fold increase from 2021. The reality has exceeded even that.

In September 2025, the largest supply chain attack in npm's history compromised 18 widely-used packages with over 2.6 billion weekly downloads combined. The attacker phished a single trusted maintainer's credentials. That's all it took — one compromised account, and billions of downstream applications were exposed.

Every npm install is a trust decision. Every package in your node_modules is code you didn't write, running on your infrastructure. The average enterprise application contains 180 third-party components. 80% of application dependencies remain un-upgraded for over a year. 95% of the time a vulnerable component is consumed, a fixed version already exists — but nobody's updating it.

Now consider the alternative. A vanilla JavaScript application with no npm dependencies has a supply chain attack surface of zero. No node_modules. No transitive dependencies. No packages maintained by a single person who can be phished. No malicious code injected into your build pipeline through a package you've never heard of but that one of your 847 dependencies depends on.

Going browser-native isn't just simpler — it's measurably more secure. Every dependency you eliminate is an attack vector you close. Every build tool you remove is a link in the chain that can't be compromised. The security case alone should be enough to make teams question whether they actually need that component library, that CSS framework, that TypeScript compiler sitting in their supply chain.

npm accounts for 98.5% of all malicious open source packages, cumulative growth and financial impact (Sonatype 2024)
npm accounts for 98.5% of all malicious open source packages, cumulative growth and financial impact (Sonatype 2024)

The Data: Speed Without Steering Creates Complexity

The research is piling up, and it backs exactly what we're arguing.

Carnegie Mellon University (2025) analysed 807 GitHub repositories that adopted Cursor (an AI coding agent) between January 2024 and March 2025, tracked against 1,380 matched control repositories. Using SonarQube to measure code quality monthly, they found: code complexity rose by more than 40%, significantly beyond what codebase growth alone would explain. There was a short-lived velocity spike followed by persistent quality degradation. The conclusion: "Speed at the Cost of Quality."

Velocity spike fades but complexity persists after AI tool adoption (CMU 2025)
Velocity spike fades but complexity persists after AI tool adoption (CMU 2025)

GitClear (2025) analysed 211 million changed lines of code authored between 2020 and 2024. They found code cloning (copy/paste) rose from 8.3% to 12.3% of all changed lines — a 4x growth rate. Refactoring dropped from 25% of changed lines in 2021 to less than 10% in 2024. For the first time in history, developers are pasting code more often than refactoring or reusing it.

Refactoring vs copy/paste as percentage of changed lines, 2020–2024 (GitClear)
Refactoring vs copy/paste as percentage of changed lines, 2020–2024 (GitClear)

Google's 2025 DORA Report found that a 90% increase in AI adoption was associated with a 9% climb in bug rates, a 91% increase in code review time, and a 154% increase in pull request size.

Impact of 90% AI adoption increase on bug rates, review time, and PR size (DORA 2025)
Impact of 90% AI adoption increase on bug rates, review time, and PR size (DORA 2025)

Sonar's State of Code Survey (2026) reported that 42% of all committed code is now AI-generated or assisted, yet 40% of developers say AI has increased technical debt by creating unnecessary or duplicative code. Only 3.8% of developers report both low hallucination rates and high confidence shipping AI code without review.

The verification paradox: 42% AI-generated code but only 3.8% developer trust (Sonar 2026)
The verification paradox: 42% AI-generated code but only 3.8% developer trust (Sonar 2026)

Here's the thing: this data describes what happens when AI generates codewithout deliberate steering toward simplicity The AI reaches for whatever patterns dominate its training data — and the training data is full of framework-heavy, over-abstracted, dependency-laden code.

Now imagine the alternative. A developer who actively instructs their AI agent: "no frameworks, vanilla JavaScript, Web Components, native CSS, minimal dependencies." The agent produces simpler code. Simpler code has lower cyclomatic complexity. Lower complexity means fewer SonarQube warnings. Fewer dependencies means less code to review. Less code to review means faster, more reliable reviews. The verification bottleneck shrinks.

Simplicity isn't just an aesthetic preference — it's a measurable defence against the quality degradation that AI-assisted development is demonstrably creating. The teams that will navigate this era successfully aren't the ones generating the most code. They're the ones generating the simplest code that solves the problem.

Design patterns will be the language that bridges carbon and silicon coders. Patterns are easy to communicate, understand, reuse and adapt. They're far simpler than generic libraries trying to cover all conceivable scenarios. A well-documented pattern guides an AI agent more effectively than a thousand pages of framework documentation, because patterns describewhat to build and why— not justwhich API to call

The Bias Problem

AI doesn't discriminate between simple and complex. That's still the responsibility of the developer steering it.

And here's the danger: the training data is biased. The harsh reality is that more bad code exists than good code. More projects use unnecessary abstractions than necessary ones. More tutorials teach "install these 47 dependencies" than "here's how to do it with the platform." If we stop reading, learning, and questioning — if we defer entirely to the AI's suggestions — we'll get bloated, over-complicated systems by default.

The AI will reach for React because that's what most of its training data uses. It'll suggest TypeScript because that's the dominant pattern. It'll import a library for something CSS can do natively because that's what Stack Overflow answers recommended for the last decade. The status quo has gravity, and the training data is the status quo.

Fighting this bias means staying sharp. Reading the specs. Understanding what the platform can do. Knowing when to say "no, we don't need that" to both human teammates and AI assistants. The developers who do this will build better systems. The ones who don't will wonder why their AI-generated codebases are unmaintainable despite having perfect type coverage.

Where We Stand

At uRadical, we work hard to fit into the second group. It's why we're drawn to Go over bloated traditional languages like Java and the baggage that comes with it. Why we favour patterns and problem decomposition over dependency accumulation.

And we're not theorising. Since late 2024, every frontend we've shipped has been vanilla JavaScript and Web Components. No React. No framework. Music Bingo Live — a real-time entertainment platform handling live venues, WebRTC audio, and Stripe payments — runs on vanilla JS. MyWelcomeBook.com — a multi-tenant SaaS with custom domain support — vanilla JS. Even uradical.io itself. Zero npm dependencies on the frontend. Zero supply chain attack surface. Zero framework upgrades to chase. They just work, and they'll keep working long after whatever framework is fashionable today has its own migration guide.

We're not dogmatic about it. We use a tool until something simpler comes along, then we switch. That's an active practice, not a passive one — it means constantly evaluating whether the things we depend on are still earning their place. Right now, for frontend development, the browser platform earns its place and the tooling on top of it mostly doesn't.

This isn't about being a luddite. It's about recognising that the tools which justified their overhead in 2015 don't always justify it in 2026 — and that the arrival of AI as a coding partner changes the equation further.

The platform has caught up. CSS nesting is native. Type annotations are coming to ECMAScript. Node.js already strips TypeScript down to the JavaScript it always was underneath. The browser doesn't need your build pipeline. It never wanted it.

The reset is happening. The question is whether you'll ride it or resist it.

References and Further Reading

CoffeeScript's Rise and Fall

TypeScript Dissent

The Platform Catching Up

CSS Preprocessors Are Optional Now

AI Code Quality — The Research

Supply Chain Security — The Data