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

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.

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

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.

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.

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.

Once you became a master it's not like things stood still, you were constantly refining your techniques and innovating; but something I've noticed about master craftsmen is that they are extremely conservative in their tools.

Even if they know that theoretically a new tool would allow them to do something with greater ease, they have already put in the time to learn to do that thing with the tooling they have, and they understand that, if they are ever considering adopting a new tool, the tradeoff has to be immensely in its favour.

Often they will adapt the tools they've already spent perhaps decades using, rather than a completely foreign tool. They build a deep mental and physical model of how these things work, and it allows them both a social prestige in demonstrating their ability to do something that others can't with the same tools, and clarity of purpose to not spend their time constantly overwriting their prior knowledge.

You can see this in programming with, for instance, really serious C programmers, who've had decades to internalise the craft and to this day can do anything they need to with C89, or particularly C99.

I think that humans have an inherent need to acquire this feeling of mastery over a domain. Consciously or not, I think webdevelopers have their morale sapped by the constant demand that they relearn how to do the most basic parts of their craft with entirely new tools every few years. Because of this cycle, they are robbed of both the inherent fulfillment of truly learning a craft, and the social prestige that comes with it. That's why it's so irksome to have the newly minted college graduate pushing these new shiny things constantly, it undermines the opportunity to experience gaining true mastery of the domain, both in terms of having to constantly relearn new skills, and in destroying any social prestige which comes with what little deep knowledge of "legacy" systems the developer has accumulated through practicing their craft.

This situation runs totally counter to the human spirit in my estimation.

It happens way too often that even the "latest" version of the documentation (assuming it exists) contains code that outright does not compile, does not work or yields deprecation warnings. I get the motto is "move fast and break things", okay, but at least don't make me curse at you while trying to get started on your project.

Also, when you introduce breaking changes or deprecate something, please give a healthy amount of "common patterns of X gotta be done like Y now", and a decent changelog. Don't make version upgrades even more painful than they already are, or at least try to provide shims.

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.

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

These days, I would actually complain about the opposite problem that there are not enough new frameworks, given that most current popular frameworks are pretty bad and are literally outdated by 8+ years.

Unfortunately, the tech industry is quite crony now so only frameworks that are built by ex-Google or ex-Facebook engineers have any chance of mainstream adoption... All the others have been gas-lit out of existence... Also, these ex-FAANG engineers who actually have a shot at getting any serious eyeballs are too busy living their best life to be toiling away coding open source frameworks. Many of them never cared much for coding anyway.

Our socioeconomic system is such that the people who hoard ALL the opportunities couldn't be bothered to seize a fraction of them... And those who have all the motivation in the world to build something meaningful have literally zero opportunities to do so.

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.

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.

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?

And what's really important - when you talk about the induced risks many teams have no clue about them...

Then again I didn't even know people got mad at new tech. Why would a new JS framework make me upset? It's like getting mad at your friend for making a chess engine when stockfish exists, who cares enough about it?

I don't switch platforms on a whim, because I like to deliver value to my users and tackling problems that actually matter.

If I'm constantly switching to a "better" platform, that's all I'm doing. And in the process I'm wasting time learning the new platforms and getting marginal returns, most of the time. Smart bosses will see right through that, sooner or later, and there goes your employability in your current job.

If, on the other hand, you're inteersted in job hopping every time you learn a new platform, all the power to you. Just make damn sure you don't jump on the wrong bandwagon.

JS also had some things missing that led to many of the frameworks being created in the first place. There was no native package manager or even standardized module imports. Imports had to be handled as HTML globals. Awful for dependency management. At any rate that's partly why we saw the original AngularJS get so popular or tools like Bower, Grunt, Backbone, Handlebars, etc get built and popular before churning out for more end-to-end solutions like Next.js.

JQuery continues to be a reliable library for <1K line web sites. Beyond that complexity, JQuery continues to be a spaghetti code nightmare. It's not wrong to write a SPA. I worked on Trello for years and it was and is a fantastic SPA that produced value to millions of users. But you'll hear no end to grumpy curmudgeons that think SPAs should not exist. Just take everything you hear on HN with a grain of salt.

I remain a React fan after using it for 10 years, but I think it's great when another tool gets a fanbase too that takes a different philosophical approach like HTMX or Solid.

The thing that changed for me is probably to stop blaming my tools and learn to apply things I learn from other places to my current work and tools. That's a lot of space in itself.

I do still keep tabs on things that I don't use but curious about, like GPU advancements and prices even though I don't work in the field or do any serious gaming. Similarly for front-end frameworks--I dabble with them for hobby projects but isn't my day job. Back-end to me seems less sensitive to frameworks, if you get the database schema and SQL right along with some reasonably plain/sane code/dataflow it's probably alright.

I sometimes find myself wishing I needed to use hot new thing, but I can't justify it. e.g. Rust is cool but do I really need that? My day job uses Ruby which is so much slower than other gc languages--wish I had proper static typing though. My bar of acceptability is much lower for tools and raised for how I use them.