On using the hot new shit in software development

Yes, I’m one of the evil people destroying “the web”

Let’s start with a disclaimer: This post is written by someone who has primarily been doing full stack web app development of JavaScript SPAs, with GraphQL servers, and (serverless) Node.js APIs for years. For some people in the web development community what I do has little to do with the web they love, and everything to do with what’s wrong with the modern web. But that’s a discussion best left for another day. With that out of the way, you can now better gauge how I might relate to “the hot new shit” in web development - umm, I meant to say “JS ecosystem”. 😜 So I got to play with new, constantly changing JavaScript stuff1 for years. What’s my take?

New is always better

First: There’s no denying that jumping into new tech is fun. There’s learning happening, and a bit of the smug feeling of being ahead of the curve - yes, programming is a pop culture. The temporary feeling is:

New is always better.

The long tail of consequences

That feeling lasts like… a week. Maybe, if the new thing is very good, a month. After that, frustration tends to switch more nuanced reasoning back on. Some things about the new stuff usually are better than previous stuff the new thing is meant to supersede. But other aspects? Guess what, they’re the same or worse. Surprise, that’s because the new stuff is usually not much better overall, just optimized for different scenarios. Trade-offs. 🤷

But now that you adopted the new stuff you set yourself up to partake in all the early mistakes and learnings of stuff. You’re stumbling into bugs no one reported yet, wasting hours due to gaps in the documentation. You’re adopting new APIs closing the gap to existing stuff’s capabilities, but have to re-write your code frequently to adopt to breaking changes.

All that time is not spent on getting the shit done you’re trying to achieve.

You might find yourself being wrong on estimations more than you’re used to, you’re over-promising. A common criticism that I personally found myself rarely agreeing with is that new stuff has a smaller community or ecosystem. It’s e.g. true that for years React has has the best UI component libraries, which indeed - depending on the project - can save a lot of time on undifferentiated work. But once a minimum amount of traction is reached, the ecosystem is exploding exponentially with 3rd party packages, teaching material, meetups, conferences, quickly solving the most pressing needs. Most indispensable stuff is anyway in or compatible with plain JS.

Hype machinery

Naturally, creators of new stuff will market the heck out of what they built, and compare it in ways that make their new stuff look favorably 2. It’s not surprising that a lot of successful OSS is build by companies. They have large enough resources and audiences to will popularity into existence to some degree.

But creators are only trying to swing the odds in their favor - the contagious hype is created by a shepherd industry of (wannabe) influencers / evangelists on Twitter (now Mastadon?), Dev.to, Meetups and, conferences. People trying to create a brand, trying to make a living off of your attention. Their constant enthusiasm for the last new stuff creates a stream of FOMO, fertile ground to buy their latest thousand dollar online course to learn today’s new stuff. If those people manage to learn new stuff every week, maybe you’re an old relict if you don’t reinvent yourself at the same speed too?

Fuck the hype - it’s short lived

At the speed that hot new stuff is released and hyped, there’s no time to really use it, battle-test it, and understand it at the depth that you will have to, if you adopt stuff in a proper code base. The latest blog post’s “hello world”[^Unfortunately a lot of content barely goes past that level] will not suffice, and it says nothing about how stuff will hold up at larger scale, after months or years - or in the context of your application. Content creators get their following for sharing content that keeps the audience ahead of the curve, for hype, not for nuance. No one goes to conferences with the title “jQuery 15 years in - the long term pros and cons in the context of our medium sized online shop”.

Survivors

Hype wears off, and what remains feels boring because it turned mainstream a long time ago. I consider it a good sign when the hype is gone, but there’s still organic usage growth. That is the type of stuff that many companies will chose, what future legacy code bases are written in, that stuff is going to be maintained for years. That means it’s going to create value for years. Guess what - boring is also good for code bases. It’s easy to find collaborators with matching skills and experience, and well-established, standardized boredom in the undifferentiated layer of the software leaves more attention and time for the custom tech debt and maintenance work.

Maybe I’m also a survivor - a survivor of many hype cycles. It’s left me a bit wary, and weary of today’s hype cycles. 10 years into coding I already feel and sound like a grand dad. But some things never change - I’ll try new stuff, and some of it I’ll add to my permanent tool set. Most stuff will fade. But as grand dad, I’ll be slower to pick up new stuff. Let others be the canaries of the mine shafts of today’s new stuff.

Footnotes

  1. With that term I mean to encompass languages, frameworks, libraries, tooling,…

  2. Sometimes even in shady ways, even or especially when it comes to scientific and objective looking points like benchmarks - looking at you, Turbopack.