Riding the Roller Coaster of Development Tooling

Fashion hunting and window shopping are things script kiddies look for. People actually building products and solving read world problems dont stress over that stuff because their attention is consumed elsewhere.

My suggestion is to just build what you want to build. If the thing you build is slow refactor it to be faster. If that thing misses some new cool kid feature then write the new feature. Never does tool fashion come up.

You describe FOMO -- fear of missing out.

A lot of what gets announced and contributes to the illusion of constant change and "so much happening these days" amounts to fad and fashion, mostly short-lived and niche. You don't have to jump on every new shiny thing. Ask yourself, would you want to work for a company or client who constantly chased fads?

If some new thing gets traction, last for a few years, grows a developer base, and has successful products that use it, take a look and see if it fits your work. If it just "sounds real neat" maybe play with it but don't change course or waste a lot of time -- wait to see if it goes anywhere.

No one can learn all of the actually useful tools, languages, frameworks, much less the niche and ephemeral, so don't stress over it. Truly useful and innovative things prove themselves over time.

I focus my time and attention on tools that seem to have staying power, make me more effective delivering value, and that I can get paid for.

There's a lot. But you don't need it all. Just choose well and keep it simple.

These days I find it very easy to recommend Astro for instance. It is batteries included enough you really don't need anything else.

Bun, deno and Hono are other projects that simplify a lot of the tooling by including most of what you need out of the box.

I'd argue that if you choose any of the options above web dev is easier than ever.

In earlier days, it may have been more commercially viable to create polished developer tooling -- Turbo Pascal was a great example. Unfortunately, the world has become more complex, as everything is now interconnected, and processing power has increased. Open source, while great, probably diminished competition.

We now live in a world where complex sociological patterns dictate which tools get the most traction. It is easier for a tool to gain more popularity if it has company backing, if you are good at presenting, or if you make only small incremental changes. Technical merit is often less relevant. There is also "first-mover advantage" and countless other processes at play.

All this to say that, indeed, from a technological perspective, the world is totally crazy. But from a sociological perspective it is fascinating, and it is a great time to be alive.

If you don't like the Node ecosystem, then perhaps you may consider doing Java back-end development, as many people in that space adhere to the Lindy effect [1].

[1] https://en.wikipedia.org/wiki/Lindy_effect

You shouldn't worry too much about the FOMO (fear of missing out).

I was contributing to node.js and v8's JIT back in 2010-2012 and I loved the NPM ecosystem at that time. To me, node.js was at its peak when express.js and koa.js were the fast way to write a backend. It took minutes to do the things that took hours or days in other programming languages.

But eversince the babel transpilation epidemic infected pretty much every package and bundler that doesn't want to deprecate legacy node.js versions, I kind of switched ecosystems.

I still think that typescript was a mistake, as it embraces language paradigms that come from C# and aren't fitting the ES language as well as e.g. the AS3/AS4 approaches back then. From a compiler perspective, it doesn't generate code that validates types, so it's useless for providing a typesafe API/SDK to third parties without the type definitions (in typescript).

I then kinda switched to Rust, as I liked the neon-bindings a lot for building better integrations with node.js at the time. But during the last years I feel that Rust gradually falls for the same feature fatigue, and I think that the upstream language maintainers should be more stubborn and take more time to think more thoroughly about feature/syntax implementations. A huge part of the Rust community is just for the sake of hype, though - and a lot of packages and bindings are just incomplete weekend-hacks.

I absolutely feel the same way. For me Node/NPM is the stuff of nightmares. It is freaking impossible to maintain any decent sized project (even side project) in this eco system within a reasonable time investment.

Then there is Go + SQLite + HTMX + AlpineJS + and you are done. No complex build / transpile / whatever steps, just go build and done. Deploying consists of copying one binary and one database file to your server and you're done. Building and running stuff is easy and fun again. The JS community can go kick rocks...

Pick your tools and use them. If your company or team requires a tool not in your toolbelt, learn it and use it when required, but always have your preferred stack in your pocket.

When the opportunity arises to sway your team towards new tooling, demo your choices.

There are new tools all the time, and it's worth it to not get too attached to any one stack. Letting yourself get too attached to one tool is a surefire way to box yourself in. Most of them do similar things, but in different ways. My thoughts on this are that the code is what matters, not the tooling.

I don't know if there's a term for this, but never updating your tooling also keeps a potential door closed.

During my first internship, we never changed the stack. When I ran in a problem, it was because either - we needed to bump major vers - it's too new of a feature and the library isn't actively maintained

In my current job, worst case it's just not a stable feature yet and we need to wait. Both situations need a workaround, but I get a lot more motivated if I get the feeling we're "on-edge" of a tool.

You will one day realize that they are all the same with only minor variation. you will lern to pick and choose what is important to you. You will pick something and only look back once a decade - long enough to you what works and have intelligent conversations about pros and cons with others with a decade in something else. Sometimes you will switch but there will be no hurry

Working with Node and Python made me want to pivot towards a batteries-included ecosystem like .NET, but I'm somewhat stuck with what I'm getting paid to do for now.