Thirty years after it first appeared in browsers, JavaScript sits at an odd crossroads. The language powers nearly every website on the planet. Its runtime runs on servers, edge networks, even desktops. Yet a fresh essay published yesterday captures a growing sentiment among veterans. The ecosystem wants something younger. Something faster. Something not written in JavaScript.

Maroun Baydoun laid out the case plainly in his post on maroun-baydoun.com. The piece hit Hacker News within hours and sparked familiar debates. Developers recognize the pattern. Tools once praised for making the web approachable now feel bloated. The chase for performance has rewritten core parts of the toolchain in Rust, Go and Zig. Speed arrives. Familiarity leaves.

But speed comes with trade-offs. Rewrite a bundler in Rust and you gain impressive benchmarks. You also shrink the pool of people who can debug its internals when something breaks at 2 a.m. The new tool looks familiar from the outside. Its guts tell a different story. As Baydoun writes, “The new tool still looks like a duck and quacks like a duck, but it’s a different beast altogether.”

This tension runs deeper than one blog post. The State of JavaScript 2025 survey, released earlier this year and covered by InfoQ, shows TypeScript now dominates. Forty percent of respondents write exclusively in TypeScript, up sharply from prior years. Only 6 percent stick to plain JavaScript. Lack of static typing still ranks as the top language complaint. Yet the very success of TypeScript adds its own layers of complexity.

React remains the most used framework at 83.6 percent. Next.js follows closely. Both generate plenty of complaints. One developer quoted in the survey said they’ve used Next.js in production for six years and found “the Next complexity has gotten absurd.” Others worry about Vercel’s influence over the project’s direction. These aren’t fringe voices. They represent a maturing community that has lived through multiple cycles of hype and regret.

And the fatigue feels real. Articles from earlier this year, including one on daily.dev, advise teams to stop chasing every new framework. Pick a default stack. Focus on web fundamentals. Time-box experiments. The average developer, the piece notes, uses only 2.6 frontend frameworks across an entire career. A small scaffolded app can still pull in over 200 transitive dependencies. The numbers explain why many engineers feel overwhelmed.

Framework authors keep promising simpler mental models. Signals. Islands architecture. Server components. Resumability. Each addition solves one class of problems while introducing others. Developers spend more time evaluating options than shipping features. The cycle repeats. New logo appears in package.json. Old problems remain.

Tooling tells a similar tale. Webpack still sees heavy use. Yet the survey found it disliked by 37 percent of users. Vite earns far better marks. Turbopack, the Rust-powered successor backed by Vercel, lags in adoption. Developers want fast builds. They also want tools they can reason about when the build fails.

Baydoun captures the absurdity neatly. “We’re compiling JavaScript with Rust to produce JavaScript that runs inside an engine written mostly in C++.” The sentence lands hard. It highlights how layers accumulate. Each layer promises to hide complexity. Often it just moves the complexity somewhere else.

Discussions on Hacker News around the essay echoed these points. One commenter suggested that perhaps JavaScript simply wasn’t the right tool for critical infrastructure in the first place. Another noted that when Rust, Go and Zig reach the same age as JavaScript, the software world may look quite different. The comments mix frustration with pragmatism. Few want to abandon the web platform. Many question the current path.

Some voices push back. A February piece on Medium argued the ecosystem has entered a consolidation phase. React feels less experimental. Vite replaced much of Webpack’s complexity for new projects. The chaos hasn’t vanished, but the pace of disruption may have slowed. Happiness scores in the State of JavaScript survey have held steady around 3.8 out of 5 for years. Not ecstatic. Not terrible.

Yet stability proves elusive for teams maintaining large codebases. An InfoWorld article from April described how the hardest problems in frontend development now center on system design rather than framework quirks. State relationships grow unclear. Responsibilities blur. Changes ripple in unexpected ways. Debugging turns into detective work across invisible dependencies. Frameworks solved many original problems. They created new ones at larger scales.

JavaScript’s ubiquity cuts both ways. It runs everywhere. That success encouraged an explosion of experimentation. The web platform improved dramatically. ES modules, async/await, fetch and other native features reduced the need for heavy libraries. Yet the application code written on top grew more elaborate. Server components blend client and server concerns in ways that can confuse even experienced developers.

Recent coverage shows the conversation continues. A September article on Web Directions suggests the entire frontend stack may be heading toward obsolescence as AI changes how interfaces get built. The complexity that frameworks were meant to manage might soon be handled differently. The tower of abstractions could prove unnecessary.

Baydoun doesn’t call for abandoning JavaScript. He questions the reflexive pursuit of speed at the expense of maintainability and shared understanding. Those extra milliseconds from a faster build tool don’t always translate into better products. They can mask deeper issues. When the black box works, nobody complains. When it breaks, fewer people know how to fix it.

The language itself continues to evolve. Proposals for native type annotations gain traction. The Temporal API for better date handling shipped in Chrome earlier this year. These changes address long-standing pain points. They arrive slowly, as standards must.

Teams face practical choices. Some double down on TypeScript and a stable set of tools. Others experiment with lighter approaches or even server-rendered HTML with minimal client-side JavaScript. A few explore languages that compile to WebAssembly. The data shows most production work still happens in the familiar stack. The dissatisfaction simmers underneath.

Perhaps this moment marks a healthy midlife reckoning rather than decline. JavaScript won the browser wars decades ago. Its runtime conquered the server. The question now is whether the surrounding ecosystem can mature without losing the accessibility that fueled its growth. Faster tools help. Opaque tools hurt. Thick abstractions free developers from low-level details until those details matter.

The coming years will test whether the community can prioritize clarity alongside performance. Whether they can resist the urge to rewrite working infrastructure simply because a newer language offers tempting benchmarks. The web needs JavaScript. It may also need fewer layers between developers and the code they ship.

Baydoun ends on a reflective note. The party looks great on the surface. Green benchmarks. Faster deploys. Thinner abstractions. Yet something feels off. The strange time he describes isn’t going away soon. Developers will keep building. The tools will keep changing. The real test lies in whether the systems they create remain understandable five years from now.