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.
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.)
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.
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!