Ah, JavaScript development, the ever-evolving frontier of web development. New runtimes, package managers, libraries, frameworks, module systems, and packages pop up like mushrooms after a rainstorm. Every week, it feels like a tech carnival, with flashy new tools and configurations tempting you to hop aboard the latest hype train.

Let’s start by acknowledging that innovation is a positive force for good. The JavaScript ecosystem is a hotbed of creativity, where developers are constantly pushing the boundaries of what’s possible. New libraries and frameworks emerge to solve real-world problems, making developers’ lives easier and applications more powerful.

Innovation itself is not the problem. The problem is the collective behavior of developers, often resembling a herd of lemmings, that can lead to chaos. Front-end (and consequently Full-Stack) developers seem to be particularly susceptible to FOMO and analysis paralysis. Once (or even before) a developer starts to feel comfortable with a tech stack, a new kid on the block arrives, and some begin suddenly questioning every decision they’ve ever made.

Imagine this scenario: you’ve been working with React for a while, building beautiful (let’s be honest, janky but functional) user interfaces, and you’re finally getting the hang of it. But wait, Svelte comes along and promises to revolutionize the way you think about front-end development. You start to wonder if you’ve been living in the Stone Age and if Svelte is the key to enlightenment.

Perhaps you’re knee-deep in Node.js, happily coding away server-side, when Deno makes its grand entrance, boasting improved security and a new approach to runtime environments. Suddenly, your Node.js project feels like last year’s news, and you can’t help but question if Deno is the future. Nota bene: Bun was released right before this article was published, and its release only makes my point stronger.

FOMO leads to a never-ending cycle of tool evaluation, configuration tweaking, and second-guessing. It’s like being stuck in a revolving door that never stops spinning. You find yourself constantly switching between libraries and frameworks, never truly mastering any of them, and your deliverables suffer from analysis paralysis.

I’ve been picking on Front-end developers, but let’s be fair: backend developers face choices too; I’m all too familiar with the Go / Rust / Zig argument (and I’ll save Ruby on Rails and PHP for a future date). There are so many general-purpose languages (GPLs, as opposed to domain-specific languages, DSLs) that, of course, there is bound to be arguing, evangelizing, and a general lack of consensus.

However, I would posit the arguments that arise over which backend language to use are of an entirely different class than the arguments that arise within the JavaScript ecosystem.

Your average Go developer and Python developer get into an argument over whose language is Better. What are their talking points? Typically, the Python developer will criticize Go for having a smaller package ecosystem, and no significant support for Machine Learning, praising Python for ease of development – it’s often faster to get a prototype out the door for Python than for Go.

The Go developer will then come back complaining about Python’s slower speed, dynamic typing, and runtime package management. If both parties are reasonable, they may agree that while both languages are “General Purpose,” there are still “domain preferences” for each language. In other words, there are problems and use cases where one language is the better tool for the job, even if both could work. (I’m aware the comparison between a compiled and interpreted language may be more extreme than between Go and Rust or Python and Julia, but the point still carries.)

Now look at an argument between a Vue user and a React user. The Vue user might complain about JSX syntax, the corporate backing (Meta), and the relaxed project scaffolding (the strict 1:1 component to file rule means all Vue projects end up organized somewhat the same, without requiring developers to search across files to find where a component is defined.) Conversely, React developers insist ‘the future is React’, more developers know React (hiring talent is easier), and complain the strictness of Vue’s scaffolding leads to verbose, sprawling directories and ReallyLongAndSpecificComponentNames.vue (getting Java flashbacks, anybody?)

Of course, I won’t pretend all arguments about these libraries are the same. React does mobile better (thanks to React Native). Vue does incremental adoption better. (React and Vue have gone back and forth on which has better performance.)

So, while there are Domain arguments to be had across JavaScript frameworks, the point I am making here is that the loudest and oft repeated disagreements over JavaScript stacks are about Developer Experience (DX) and preference, rather than which stack can do the job better in production.

I still don’t think these arguments over preference are The Problem With The JavaScript Ecosystem™. Different developers will make judgment calls for one choice over another. But if the tools can all (mostly) get you to the same, functional result, and it’s really a DX and preferential choice question, FOMO is the problem. The most important factor for seamless DX is the stability of the ecosystem: building components and shipping changes to production should become muscle memory over time. This muscle memory can never develop when the developer is constantly switching between tools and libraries.

Backend developers listen to the arguments over which JS stack does what and how. Inevitably overwhelmed, they retreat back into their caves to write some of the finest, purest Haskell ever conceived, then sit back with a glass of brandy admiring their monads (or something like that, I don’t know, I don’t write Haskell) leaving the Scary Frontend World alone.

It’s generally acknowledged that Linux “distro hopping” is an unhinged practice fit for masochists and the clinically deranged. It’s high time we collectively agree stack churn in the JavaScript Ecosystem is a comparable vice. What is the solution then? Where’s a good tradeoff between stifling innovation and maintaining stability?

Be pragmatic. If you’re a library maintainer, keep building awesome tools, but don’t expect everyone to use them right away. There are already so many moving pieces. If what you’re building is truly revolutionary, it will stand the test of time and eventually become a standard (whether you like it or not!).

If you’re building a product, you need to ship. Leave the bleeding edge, the framework wars, and library hopping to the maintainers of the tools. Chances are you don’t need to be an expert in every new library that comes out.

Stop, settle, and pick something to move forward. If you can’t decide where to start, then vox populi vox dei: start with Next.js. Get really good at it. Only switch up your stack if there’s a feature your platform can’t function without. It’s time to focus on shipping, not deliberating. I regretfully inform you, that even if you can’t take advantage of the latest shiny, you’ll be ok!