Framework Fatigue: The Real Reason Developers Get Angry About New Tech

When people get cross, it's most likely because it's the same old hype cycle in action that has been cycling for the past 40 years:

1. New Thing gets traction, 2. New Thing gets hailed as Next New Thing, 3. Everyone jumps on board and New Thing is The Only Thing you should be using, 4. New Thing Fatigue sets in as various things about New Thing aren't so great after all, 5. Everyone moves on to Next New Thing because maybe that really is the Next New Thing.

Rinse and repeat.

For those who have been in the game for as long as me (I'm not a proper dev but 30 years "doing web stuff" makes me an interested onlooker), it's a fairly tedious cycle to watch come and go over many iterations. It's one of the reasons I try and stick with boring old PHP + HTML + CSS + a sprinkling of JS for the stuff I do.

YMMV but the point is, it's everso tedious and unsettling to those involved trying to figure out what the next thing to focus on should be.

The article comes to this conclusion:

> After years of observing these cycles, I think it comes down to one word: employability.

> Developers want to keep getting paid for what they already know and use. We worry that today’s optional technology will become tomorrow’s job requirement.

However, that's not the real reason for the "fatique" or anger from the seasoned developers. The anger stems from the fact that we've seen all of this so many times before and it seems we're unnecessarily burning cycles on something that is spinned as "innovation", but pragmatically is a distraction.

This anger is further fueled by junior developers jumping directly on the new frameworks and disregarding the "old tech" as some sort of legacy.

This is missing another big reason: we're not just writing this stuff and casting it out into the void, fulfilling weird demands of weird space aliens somewhere. No, much more than producers, we're also - like everyone else - users of software written by others, too.

I don't do much frontend work these days, and when I need something, vanilla JS and CSS serve me just fine. Yet, I get angry or saddened by new things in web space all the time, and yes, sometimes even "offended to the bone that this new generation of developers is just running in circles" - that's because even if I don't work with frontend myself, I will be on the receiving end of all the bloated webshit garbage. Will be, and am - like everyone, I already am drowning in kaka felota.

Take SPAs: yes, they have a place, and frameworks can be used correctly and efficiently. But they mostly aren't, and instead, almost every single website I use - news sites, bank sites, online stores, e-mail services, blogs - they are all now steaming pile of half-broken garbage. Shmaybe they look cuter, and are easier to use with fat fingers on a tiny phone, but they're also less functional than generation before, and take longer to do anything. We've been through couple iterations of SPA-fication, and each one made things worse.

No, the true reason I get angry about new tech, is that new tech is shit, and I'm going to be force-fed that shit, because everything is going digital, everything is being written by juniors, and the market at this stage is structurally unable to make things better, or take feedback. So each time I see a new turd get a spike in popularity, I know that one year for now, I will be suffering at the receiving end of it.

It's not just frameworks.

Every ORM or new database adjacent thingy has to invent a new WhateverQL. Kinda sorta like SQL but not the same (and usually less powerful) so you have to learn its syntax if you want to use it.

And same thing with structured document and each type having their own pathing syntax: xmlpath, jsonpath, css selectors. I was going to write at least yaml is using jsonpath but it got me to this other Thing-du-jour: config file formats.

If you're rejecting someone for having 4 years of Vue.js and you want React experience, well, you're either crippled and close to failure and desperately need to parachute in a JSX slinging ninja to avoid bankruptcy, or, you're hiring for stochastic parrots in human form, as opposed to hiring intelligent developers who can learn what needs to be learned.

I've never been hired for a framework, nor have I ever hired for a framework.

So. Je m'oppose the employability claim.

However, I do get annoyed when everything is gotta be in <X> lang or we're using <Y> tech that is designed for a different use-case, because someone read a few too many whitepapers or blog posts and has chosen a technology because it's new and shiny and hypey, with minimal thought as to whether or not it's actually useful for your given situation.

Employability anxiety triggered by technology deprecation (real or perceived) is universal. Think e.g., of the large pool of C++ programmers that feel the stress of "memory safety" and Rust. But framework fatigue seems to be an issue affecting the javascript ecosystem disproportionally hard.

The fascinating thing about JS/TS UI frameworks is that they seem to grow out of a frustration with all the complexity, heaps and heaps of oddball syntax, implicit behaviors and things that need to happen in a particular order or things blow up in ways that take years to learn to avoid.

So someone sets out to "fix" some aspect of this, discovers that their new design was incomplete, and then all of this weirdness seeps back in to "fix" the problems that arise, and then the cycle starts over.

I had hoped that WASM would provide an opportunity to invite more disciplined designers to accomplish something in the browser, but that never happened. I've often wondered why. I've tried to make use of WASM on the server side, but I have to admit that it is limited and clumsy and leads to heaps of unpleasant and risky code.

Shiny object syndrome still goes strong in the software engineer population.

Jokes aside, the real value is in the fundamentals. Frameworks (or even simple languages like Go) can be learned to use efficiently in a matter of days. Good fundamentals make this process smoother.

Software Engineering is about always maintaining the right balance between NIH syndrome and dependency hell (yeah, don't pull in leftpad as a dependency).

As such, new frameworks keep coming out as people decide to build something small and focused, and that keeps growing and becomes a framework.

It is bound to continue, as it should.

One should neither get too excited nor too upset, but some of those announcements will sound funny to anyone who's been around for a while (in general it is mostly rehashing all the same ideas from 70s onward).

The author names "employability" as one of the reasons developers oppose new tools. Not the take I expect when I started the read, but after giving it a though, it's actually something I've been bothered by recently. Due to favorable circumstances, I didn't have to learn frameworks other than Angular. This obviously limits my career opportunities and I'd be totally OK picking up another tool. But will potential employers even consider my CV that doesn't mention React? Will they be willing to offer the same position level and give me time to learn their stack? I am not so sure about that.

There's a gradient of kinds of knowledge, between things on one side that are more permanent and closer to "How things work" and on the other side more aligned with "How to use a tool or abtraction to accomplish task X in environment Y".

Most frameworks exist on the right side, a more abstract and less detail-oriented way of accomplishing task X in environment Y, but as a layer above the details it's really just one person or a group of people's opinion on one specific way to do that, doesn't necessarily reflect the inner workings, and is largely an arbitrary choice about how to structure something (this is all by design, that's why these tools are made).

New frameworks come along with supposed new ideas, but they rarely change the nature of the details (in fact as a layer above they usually cannot), hence the "Seen it all before" feeling. Maybe you've not seen the new structure before, but you likely already know how it works underneath, and likely have seen tens of other people's opinions on how to name X, structure Y, and organise Z.

Getting angry about New Tech is rarely getting angry about New Tech, it's just being tired of "New" tech that sits at the same layer, solves the same 'problems' but with different words but is seen as a serious revolution. Not that new approaches and ideas aren't beneficial, and sometimes they do catch the wind and become almost a standard. But they're still just layers above the details below.

Of course the "How things work" side is also really a result of human decision-making, so down to something like the speed of light it's all just human decisions about how to structure something, but the lower level you get the more permanent the knowledge is. It doesn't change week to week on a whim, it's likely not a short-term trend but a slow and (hopefully) considered evolution of thinking.

Can it be coincidence that the word "revolution" means both a fast, radical social change but also for celestial bodies a complete cycle that brings you back to the same place you started?

In the world of JavaScript there are two very separate populations:

1. Those who start and end with employability

2. Those who build products

There is sometimes some overlap, like people who use react native or can’t go deeper than react or jquery to build things and yet still build original polished products. The overlap though is generally shallow and certainly isn’t universal because when shipping a product there are things that matter more than aesthetics.

For people who build products new frameworks and code style is an often irrelevant aside. It’s all about what to write and not how to write it. How to write the code almost never seems to come up until measuring for performance or security.

For the people only interested in employability, regardless of candidate versus management, these framework discussions are critical. Things tend to focus on basic literacy.