Might just be me but this article mostly seems like assumptions and doesn't really paint a good picture.
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?
> It's like getting mad at your friend for making a chess engine when stockfish exists
Making a chess engine (or anything!) when others exist when the goal is wanting to get into learning how chess engines work is very different to making one with the explicit intention of releasing it into the public domain as a tool/dependency that is used by thousands or millions, needs constant updates and support, works differently than the others while accomplishing the same underlying goals, looks mostly similar but also different enough to be annoying, and is arguably just a different opinion (not necessarily worse or better) on how to structure a project at roughly the same level of abstraction.
Frameworks also are not just tools in the sense that you use them to accomplish a task N times, they end up as a foundational layer in a project, with the benefits and costs of that.
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.
> 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?
Many companies who use React will not consider your CV. React is as fundamental as JavaScript itself so omitting it in a CV is red flag. And learning modern React ecosystem from the scratch is no easy undertaking even for experienced developer.
Considering future employability when choosing a tech stack is definitely a valid concern and it should be clear for everyone involved. Using unconventional technologies makes it harder to hire people, because many developers will afraid to hurt their CVs.
That’s because React was messed up when it was at iteration 16. Slightly harder to understand at 17. But 18 completely jumped the shark on being able to understand the thing.
I'm pretty ignorant when it comes to modern JS (still mostly using jquery when having to do something browser-side), but
> And learning modern React ecosystem from the scratch is no easy undertaking even for experienced developer.
feels like a pretty strong statement to me.
I've seen a few snippets here and there of various JS frameworks over the years and they could be summed up as "reactive programming for browsers" - which doesn't seem particularly groundbreaking.
So I assume that I just don't know where the difficulty comes from. My question is then: where is the nonobvious complexity of learning React?
The main reason for the no-go is that you get hired by HR, not another developer. Many times the company has outsourced the hiring process to another company and that one has even less of a clue about programming. So they just read the keywords (or use an AI) to match you. No match, no interview.
Ofcourse you can pick up another stack much easier if you already know another. But that is not interesting if all you do is compare number of matches on the CV.
> learning modern React ecosystem from the scratch is no easy undertaking even for experienced developer.
Strong disagree on this. Modern Angular and Vue work almost identically to React. The details are different, but the principles the same. For an experienced dev, that knowledge should translate directly.
The ecosystem is also not that bit. React Router and some state management tools are the only React-specific libraries one really needs. The rest you can lookup.
The trickiest tooling in the JavaScript ecosystem has always been the build tooling, and that's largely shared across frameworks.
Wow, that's very delusional. React is very popular but can't be compared to JS. JS is THE scripting language of the web with backwards compatibility going back to 3 decades ago. You NEED JS if you want interactivity in your website. React is nowhere near there. React won't disappear but it is likely that at some point it will become the new jQuery (present in many websites, used sometimes and regularly maintained) and people will use simpler tech like svelte
They needed Angular 17/18, I worked with 16, after the initial call they didn't want to continue due to this. Not sure how real the job was. Apparently if you start with AngularJs, then 2, 6, 8, 10, 12, 16, it will be impossible to upgrade to 18 /irony
I guess the real reason was they thought that you couldn't hit the ground running but they didn't even try to see if that's true or not. I have changed projects in the same company before and they really wanted to know how fast can you become productive and anything beyond 2 weeks sounded too much and the they needed 2 months to create all my accounts and give me access.
> 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.
Related: there are few things in this world I capital H hate with a murderous rage quite so thoroughly as a smug 23 year old blithely declaring individuals who've been mastering entire tech ecosystems longer than they've been alive "don't want to learn". Correction, children: we get sick of learning bullshit subsets of things we already know merely to satisfy the current marketing cycle among technological semi-literates.
This is getting so ingrained in todays society that it even spills over on non-tech. We have this provatisation craze going since a while and as soon as something don't work we expect the market to sort it by switching provider. For example now, the state has hired a taxi company to do all school transports for all kids that can't take the bus for any reason. And all other disabled transports that is the responsibility of the state. This has been working very bad since a number of reasons. The solution to this is that they rewrite the rules for the next contract round. All taxi companies gets to bid on the contract and the cheapest wins the contract.
If it didn't work with the previous one, do we really think it will work with the next one that wants even less money? Hint: The workers are the same since the winning bid cannot be won by a single taxi company. There will be a big company that has no drivers and they in turn will hire all the local taxi companies to do the actual work. They will do the same mistakes of setting the incentives wrong and we will end up with non function disabled people transport. Again. It's not even the first circle coming round. It just keeps happening.
Our brain don't like to break accumulated "knowledge" to replace it. Especially if it's just to recreate a different mess without a global improvement in insight. And if this occurs too often.. it feels as breaking your leg every time your bones heals..
I don't get angry when I read a new topic, even if complicated, it's a motivating pleasure even.. but trying to reverse yet another vaguely specified build system .. not so much.
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.
Good or smart bosses might see through that, but how many of those are there? Who even takes time these days in hiring to look at references an applicant provides? For example I have some 30 project repos and a few of them are great displays of skill. So far in no interview anyone has ever given any indication have having had as much as a cursory glance at what I created in my free time. Things more difficult to understand conceptually, than any work task I have had. Things neater and cleaner than any work code. Things showing advanced understanding of programming concepts, that can be helpful in many places. Whole applications. And yet ... I get put into whiteboard coding interviews, that are completely removed from reality.
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.
This is what many employers don't get. If they hire someone with very solid fundamentals, not just some one framework specialization, they will, with minimal learning effort, be able to product acceptable, and soon better results. But in hiring as in other matters the short term view is so prevalent, that very capable people can have difficulties getting the job.
I can't believe I'm reading this in 2025.
People are repeating things which used to be true back in 2014 but don't make any sense in today's context. Even this supposedly 'shiny new' framework called Svelte is from 2016... That was almost 8 years ago.
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.
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.
How can you give it a thought without experience? Trying new things on smaller projects allows you to solve annoying issues with the last library. Or fail to do so. Either way no one can just sit and decide what’s best simply by reasoning.
Before anyone asks I’m not advocating for React here, and also far from being new to this game. Btw, do you count Vue as old or new? Which version? Is 3 “established”? Would you hire a Rails guy for Zend?
> no on can just sit and decide what's best simply by reasoning
Scary as it sounds, this happens more than most people realize because it stems from directed marketing in structures where financiers are making the decisions and the engineers are just expected to adapt. I don't know about the developer arena, but in industrial automation (my field) new tech and software gets pushed frequently based on whether or not a bean counter said it would improve efficiency, not because it was tested in that specific environment. It's a constant headache for integrators. The number of times I have had to sit and listen to a room full of salesmen explain to me why we're suddenly using Y when X was working just fine is ridiculous. They see in dollars, and to them, testing the new software or component in the working environment prior to making the call is a waste of dollars when weighed against how many dollars they will save with expedited implementation.
It's maddening, and probably the prime factor that makes my job unpleasant.
The "adopting a tech with minimal thought" bit was about high level decision making.
I have no particular thoughts on Vue's newness or oldness because front-end JS is a frantic treadmill that I'm glad to not be involved in.
As for "would I hire a Rails guy for Zend?"
As I said, unless I'm desperately patching holes in a sinking boat, where I need you to jump right in and man the bilges with your indepth $framework knowledge, I hire first and foremost for a proven ability and willingness to learn and an attitude that makes you a good team fit.
You could be Rasmus Lerdorf and I'd reject you if you weren't interested in learning new things, and I'd reject you if you were an asshat, even if you're the best Zend developer ever, because if you're an asshat, you're going to lower the productivity of my team.
So would I hire a "Rails guy" for Zend? Yes. It's not like a Ruby framework is so massively different to a PHP framework that you need 10 years of Zend to make the transition.
But then, I'm biased,I self-taught in Python, focused on Django 1.0, got hired by a Java shop, started in Tapestry, then Wicket, then focused on backend, then went to RH to work on an K8s operator built on Vert.x, then ended up working at a Python shop 15 years after my previous in-depth usage of Python, working on a Django 4.0 app, and then FastAPI apps, even though I'm not a "FastAPI guy" nor a "Django guy".
Funnily enough though, I am a "Kafka guy", but now so are a bunch of my colleagues because I focus on sharing the knowledge.
To be clear, I wasn't hired to be a Django guru, or a FastAPI one, I was hired to implement code that satisfies business needs, in a manner that involves Django or FastAPI.
And yep, I've learned a shit ton about modern Django, but I've been productive since day 1. Because I enjoy learning and want to learn.
So yeah, I'm totally hiring that Rails person for Zend work if they've got the right mindset and the right fit.
I think you described much of the European Java job market atm where shops prefer hire Spring/Boot-experienced devs. A lot refuse to invite you to interview if you have 0 XP with it or will try to hire you as junior (less pay), no matter that you were in fact doing Java using other tools. Absolutely insane.
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.
There is no success without try. If nobody ever tried to make something new, we would have never had many of the great tools we like today. The main problem with the fatigue is not new tools, it's when a tool exists for some time, gets used by real-world people, and decides to change major things. There could be good reasons for the change: maybe something that wasn't well thought enough, or the big picture has changed, .... but then all those users/developers have to adapt their real-world scenarios to the new major forced change, and this fucks everything and everyone up. And this tends to happen way too often with modern development.
Engineering is a lot about trade-offs. Use a new (dynamic/not stabilized thing) because it is 20% better at something, but you risk to need to adapt or use something old and stable that involves more work?
It is possible that many people avoid thinking explicitly about these trade-offs then they are upset. But if you worked in the field more than 6 years you should have seen the pattern.
I worked with people that preferred 10 years old, stable technology and they did not have surprises. There were some downsides, but I think these types of companies are there.
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.
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.
I agree, I've basically gone the same path as you, just ended up with a different stack to solidify behind, but same idea.
> 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.
I think it would all be fine, if people could just accept they're are part of this turning wheel, but instead they'll kick and shout that "No, but it's different this time, this time we really found the silver bullet" while you continue to look at them changing from HypedThing to HypedThing, repeating the marketing pitch while running into new walls.
I'll get jumped but whatever: Currently this is happening with for example TypeScript, where some people are so into it, they don't see it as just another "Compile to JS" language that will eventually be replaced by something else once the hype wheel starts turning yet again.
> they don't see it as just another "Compile to JS" language that will eventually be replaced by something else once the hype wheel starts turning yet again.
In case of TypeScript, they might be right - given its peculiar positioning and staying power, as well as indirect effects from resurgence of popularity around type systems (Rust, type annotations being leveraged in LLMs, etc.), it wouldn't surprise me if at some point, browsers (read: Google) decided to start supporting it as first-class language. A decade down the line, it might be that JavaScript will end up being compiled down to TypeScript instead of the other way around.
> it wouldn't surprise me if at some point, browsers (read: Google) decided to start supporting it as first-class language. A decade down the line, it might be that JavaScript will end up being compiled down to TypeScript instead of the other way around.
If WASM still exists in some flavor at that point, but TypeScript ends up being the target for JS instead somehow, we can assume we probably have other, way worse issues in the world to deal with, because something clearly went wrong.
I think it’s more likely that TypeScript’s features will just be subsumed into Ecma262 with some adjustments to support backward compatibility. IMHO part of TypeScript’s staying power has been that the changes it makes are more conceptually radical compared to the useful but relatively lightweight sugar of Coffeescript for example.
Most frameworks are still there (requiring everyone be fluent in all of them) just because no meteorite killed that specific dinosaur.
Every framework starts from scratch pretending all done before belongs to the trash can, much like that multi-year discussion re: Raku being better than Perl just because has "say" instead of "print".
The net outcome of that? the complete irrelevance of both.
Dear nerd-framework author, can you all invest 5 minutes in a cross compiler/converter, strive for compatibility and not reinventing the wheel when native JS performs the very same thing?
I think that most simple and even some complex business use cases are already covered by solutions like WordPress, Shopify, Salesforce, etc. If one feels satisfied with “PHP + HTML + CSS + a sprinkling of JS”, maybe they don’t need any PHP or JS at all.
I'm so very deeply uninterested in the hype train. I'll keep using C, C++, and C# until the wheels fall off.
I do not care at. All about how shiny and whizzbang your new toy is, mine works fine, it solves my problems, and requires no improvements for my use requirements. I'm not investing a sizable fraction of my limited life to rewrite in the hip new framework du jour. I'll keep the code that works and the tools that aren't broken.
I also deeply do not want to be associated with the cargo cult ya-yas that think they're so clever and smart for suggesting rust. Thoroughly disgusting behavior. I don't want to use a language where I get that kind of response to simple questions.
C is fine. It will keep working for a very, very long time.
There is one glaring omission IMHO: documentation, or to be precise its quality.
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.
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).
Balancing NIH with dependency hell requires good judgement AND time. If you need to get something done to a deadline you take the path that is easier in the short term.
In Python projects I also find people use the output of pip freeze to generate their requirements.txt so it contains indirect dependencies and these never get removed. I just removed numpy from the requirements.txt of a web app - if was a dependency of an obsolete dependency.
> 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).
its also frustrating and annoying. People really should learn something of the history of their field. Do people have no curiosity?
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.
The effect that you’re describing applies to vanilla js sites as well. It’s usually the result of an average team competence, or of just having a team. You’re cool with vanilla only until there’s few more random guys who slap the patches over the code. The only difference is that this method may break the codebase so bad that the site won’t see the light at all and there will be nothing to complain about.
> The only difference is that this method may break the codebase so bad that the site won’t see the light at all and there will be nothing to complain about.
Yes.
Or put another way: new shitty frameworks let teams of average competence to handle more challenging tasks, raising the complexity cut-off above which the shit pile collapses on itself and the product never gets published. This is not a good thing, because in practice, this means more garbage software being produced, and competing against older software that - by definition - had to be not shit just to see the light of day. Thing is, more and cheaper garbage always wins on the market because it's cheaper to make (= more money on polishing the turd and marketing the heck out of it). Overall result: instead of fewer good offerings, we have a glut of garbage ones.
I sort of agree, but believe that we are in our own shitty tech bubble, of which vanilla is actually rock bottom. It just doesn’t float as much.
It always puzzled me that we haven’t collectively invented some ways to skip all this “complexity” like e.g. ERP/CRM/CMS platforms do. Instead every team figuratively rewrites their whole stack from scratch in assembly. Even google sheets can publish a document and make it dynamically work faster and easier than any real-world webapp. I get your ideas, but we all are missing something here.
I'm guessing that's a bit of the dreaded "Not Invented Here" syndrome at play, but mostly just that everything is evolving too fast, in too many places, all at the same time.
Consider, we've pretty much solved the problem of quickly creating good GUIs for software with RAD tools in the 1990s/2000s. But that was on the desktop. Then the web happened, and then mobile happened, and we couldn't port RAD tools to them because the web platform, having been created with documents in mind, was fundamentally incompatible with ideas behind GUI. We've collectively spent the last 20 years simultaneously trying to paper over this incompatibility, while slowly pushing the underlying platform to be more app-friendly.
Today, the platform is still torn between the document and app paradigm, and we've managed to begin replicating the most basic features of RAD tools of yore, but all on top of a mile-high heap of bloat. But the Earth didn't stop in its tracks for those 20 years - the world underwent the digital transition in that period, businesses had to make do with whatever tools were available, no matter how shitty, and thus we've been experiencing a high-paced churn, with services being constantly upgraded as old hacks stopped working, and new ones promised (often falsely) to be less shitty than those before.
Maybe it'll all settle one day. The web will slow its evolution, and people will have time to clean up all the mess, and then we'll finally dig ourselves out of this big regression in software quality, capabilities, and production time, relative to the RAD times. But until then, we suffer. Transitional periods suck.
I'm going to add something that isn't being mentioned here who's impact is underappreciated I think, and that's the idea of developers as craftsmen. Normally when you learn a craft, you eventually reach a sort of mastery, in the old guild system this was a literal title that you acquired.
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.
Seems like mostly bittervets replying here. We've all been there, at the start of our career, perhaps struggling to be relevant in our field. Then finally finding what looked like Thor's Hammer and machinegun nailing all possible requirements with it. Or maybe it was just me <shrug>.
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.
Honestly I think part of this is just a symptom of the tech industry getting older and people getting set in their ways. But also, the web hasn't really changed as much as was changing 10 years ago. New developments in JS, HTML, and CSS as well as the need to support mobile as a first class citizen, along with a boom of SaaS apps created a high demand for new ways of thinking about web development.
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.
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?
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.
Lots of things use Wasm/WaSI as a plugin interface/runtime everything so I really question your closing point. It’s more intended that you compile to it from other higher level languages like C, C++, Rust, C# etc. than writing the text format for example.
I suspect the reason it hasn’t become commonplace to build web UIs with it is because your average frontend dev isn’t too familiar with those languages or their UI libraries nor writing a browser compatible rendering backend for them.
When I call WASM functions the types I have available to me are i32/64 and f32/64. There are not other options. Not even byte arrays.
If I need to pass strings, structs, bytes etc I have to allocate memory inside the WASM instance, serialize the data into this memory, pass the memory offset as a parameter to the function that should operate on it, deserialize the data and then clean up the mess. This is awkward, error prone and risky.
Yes, I do use WASM from a high level language that has automatic memory management. That's why this old fashioned messing about manually with memory allocation and doing pointer arithmetic seems like such a huge step back.
Yes, there are people that make plugin frameworks. And yes, one of the things they have to do is to hold their nose and just accept that this is the ugly reality of using WASM. It doesn't mean that this isn't a terrible design flaw. It is.
Well, I have my primary browser (Vivaldi) set to block ads with uBlock Origin and reject any cookies or persistent storage request that is not specifically allowlisted. The number of websites that fail to load with a JS error, for what is basically a content page that should be static HTML rather than a "rehydrated server-side rendered page", is just infuriating. It's not even as if I disable JavaScript by default, although I really should.
I get going for things that may help - but from a risk perspective my team has seen many of these get misused and create significant risks especially when it comes to the security of the app flow. Add context blindness to the mix and we've never seen so many vulnerabilities in years if not decades.
And what's really important - when you talk about the induced risks many teams have no clue about them...
I wouldn't say that I get angry or fatigued so much as disappointed or even merely not excited about most new things.
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.
A new framework every 18 months or so is fine until you get too old to learn the new tricks. In my case that happened with React at age 60 when having used callbacks for a decade or more this new f%$^&led thing called a promise came about that just threw me for a loop. AI would have been useful to write that code for me but it was still 5 years away. There used to be legacy codebases still running like business applications written in Cobol that ensured employability for old dogs but not the case for javascript.
69 comments
[ 2.5 ms ] story [ 128 ms ] threadThen 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?
Making a chess engine (or anything!) when others exist when the goal is wanting to get into learning how chess engines work is very different to making one with the explicit intention of releasing it into the public domain as a tool/dependency that is used by thousands or millions, needs constant updates and support, works differently than the others while accomplishing the same underlying goals, looks mostly similar but also different enough to be annoying, and is arguably just a different opinion (not necessarily worse or better) on how to structure a project at roughly the same level of abstraction.
Frameworks also are not just tools in the sense that you use them to accomplish a task N times, they end up as a foundational layer in a project, with the benefits and costs of that.
Many companies who use React will not consider your CV. React is as fundamental as JavaScript itself so omitting it in a CV is red flag. And learning modern React ecosystem from the scratch is no easy undertaking even for experienced developer.
Considering future employability when choosing a tech stack is definitely a valid concern and it should be clear for everyone involved. Using unconventional technologies makes it harder to hire people, because many developers will afraid to hurt their CVs.
> And learning modern React ecosystem from the scratch is no easy undertaking even for experienced developer.
feels like a pretty strong statement to me.
I've seen a few snippets here and there of various JS frameworks over the years and they could be summed up as "reactive programming for browsers" - which doesn't seem particularly groundbreaking.
So I assume that I just don't know where the difficulty comes from. My question is then: where is the nonobvious complexity of learning React?
Ofcourse you can pick up another stack much easier if you already know another. But that is not interesting if all you do is compare number of matches on the CV.
Strong disagree on this. Modern Angular and Vue work almost identically to React. The details are different, but the principles the same. For an experienced dev, that knowledge should translate directly.
The ecosystem is also not that bit. React Router and some state management tools are the only React-specific libraries one really needs. The rest you can lookup.
The trickiest tooling in the JavaScript ecosystem has always been the build tooling, and that's largely shared across frameworks.
I don't see a scenario where this is likely, other than if you're contributing directly to the react codebase.
Wow, that's very delusional. React is very popular but can't be compared to JS. JS is THE scripting language of the web with backwards compatibility going back to 3 decades ago. You NEED JS if you want interactivity in your website. React is nowhere near there. React won't disappear but it is likely that at some point it will become the new jQuery (present in many websites, used sometimes and regularly maintained) and people will use simpler tech like svelte
> 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.
At the same time all the implementation details fly under the radar, and the mountain of dependencies keeps increasing in size.
If it didn't work with the previous one, do we really think it will work with the next one that wants even less money? Hint: The workers are the same since the winning bid cannot be won by a single taxi company. There will be a big company that has no drivers and they in turn will hire all the local taxi companies to do the actual work. They will do the same mistakes of setting the incentives wrong and we will end up with non function disabled people transport. Again. It's not even the first circle coming round. It just keeps happening.
Our brain don't like to break accumulated "knowledge" to replace it. Especially if it's just to recreate a different mess without a global improvement in insight. And if this occurs too often.. it feels as breaking your leg every time your bones heals..
I don't get angry when I read a new topic, even if complicated, it's a motivating pleasure even.. but trying to reverse yet another vaguely specified build system .. not so much.
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.
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.
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.
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.
Before anyone asks I’m not advocating for React here, and also far from being new to this game. Btw, do you count Vue as old or new? Which version? Is 3 “established”? Would you hire a Rails guy for Zend?
Scary as it sounds, this happens more than most people realize because it stems from directed marketing in structures where financiers are making the decisions and the engineers are just expected to adapt. I don't know about the developer arena, but in industrial automation (my field) new tech and software gets pushed frequently based on whether or not a bean counter said it would improve efficiency, not because it was tested in that specific environment. It's a constant headache for integrators. The number of times I have had to sit and listen to a room full of salesmen explain to me why we're suddenly using Y when X was working just fine is ridiculous. They see in dollars, and to them, testing the new software or component in the working environment prior to making the call is a waste of dollars when weighed against how many dollars they will save with expedited implementation.
It's maddening, and probably the prime factor that makes my job unpleasant.
The "adopting a tech with minimal thought" bit was about high level decision making.
I have no particular thoughts on Vue's newness or oldness because front-end JS is a frantic treadmill that I'm glad to not be involved in.
As for "would I hire a Rails guy for Zend?"
As I said, unless I'm desperately patching holes in a sinking boat, where I need you to jump right in and man the bilges with your indepth $framework knowledge, I hire first and foremost for a proven ability and willingness to learn and an attitude that makes you a good team fit.
You could be Rasmus Lerdorf and I'd reject you if you weren't interested in learning new things, and I'd reject you if you were an asshat, even if you're the best Zend developer ever, because if you're an asshat, you're going to lower the productivity of my team.
So would I hire a "Rails guy" for Zend? Yes. It's not like a Ruby framework is so massively different to a PHP framework that you need 10 years of Zend to make the transition.
But then, I'm biased,I self-taught in Python, focused on Django 1.0, got hired by a Java shop, started in Tapestry, then Wicket, then focused on backend, then went to RH to work on an K8s operator built on Vert.x, then ended up working at a Python shop 15 years after my previous in-depth usage of Python, working on a Django 4.0 app, and then FastAPI apps, even though I'm not a "FastAPI guy" nor a "Django guy".
Funnily enough though, I am a "Kafka guy", but now so are a bunch of my colleagues because I focus on sharing the knowledge.
To be clear, I wasn't hired to be a Django guru, or a FastAPI one, I was hired to implement code that satisfies business needs, in a manner that involves Django or FastAPI.
And yep, I've learned a shit ton about modern Django, but I've been productive since day 1. Because I enjoy learning and want to learn.
So yeah, I'm totally hiring that Rails person for Zend work if they've got the right mindset and the right fit.
edit: typos
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.
It is possible that many people avoid thinking explicitly about these trade-offs then they are upset. But if you worked in the field more than 6 years you should have seen the pattern.
I worked with people that preferred 10 years old, stable technology and they did not have surprises. There were some downsides, but I think these types of companies are there.
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.
> 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.
I think it would all be fine, if people could just accept they're are part of this turning wheel, but instead they'll kick and shout that "No, but it's different this time, this time we really found the silver bullet" while you continue to look at them changing from HypedThing to HypedThing, repeating the marketing pitch while running into new walls.
I'll get jumped but whatever: Currently this is happening with for example TypeScript, where some people are so into it, they don't see it as just another "Compile to JS" language that will eventually be replaced by something else once the hype wheel starts turning yet again.
In case of TypeScript, they might be right - given its peculiar positioning and staying power, as well as indirect effects from resurgence of popularity around type systems (Rust, type annotations being leveraged in LLMs, etc.), it wouldn't surprise me if at some point, browsers (read: Google) decided to start supporting it as first-class language. A decade down the line, it might be that JavaScript will end up being compiled down to TypeScript instead of the other way around.
If WASM still exists in some flavor at that point, but TypeScript ends up being the target for JS instead somehow, we can assume we probably have other, way worse issues in the world to deal with, because something clearly went wrong.
Every framework starts from scratch pretending all done before belongs to the trash can, much like that multi-year discussion re: Raku being better than Perl just because has "say" instead of "print". The net outcome of that? the complete irrelevance of both.
Dear nerd-framework author, can you all invest 5 minutes in a cross compiler/converter, strive for compatibility and not reinventing the wheel when native JS performs the very same thing?
I do not care at. All about how shiny and whizzbang your new toy is, mine works fine, it solves my problems, and requires no improvements for my use requirements. I'm not investing a sizable fraction of my limited life to rewrite in the hip new framework du jour. I'll keep the code that works and the tools that aren't broken.
I also deeply do not want to be associated with the cargo cult ya-yas that think they're so clever and smart for suggesting rust. Thoroughly disgusting behavior. I don't want to use a language where I get that kind of response to simple questions.
C is fine. It will keep working for a very, very long time.
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.
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).
In Python projects I also find people use the output of pip freeze to generate their requirements.txt so it contains indirect dependencies and these never get removed. I just removed numpy from the requirements.txt of a web app - if was a dependency of an obsolete dependency.
> 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).
its also frustrating and annoying. People really should learn something of the history of their field. Do people have no curiosity?
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.
Yes.
Or put another way: new shitty frameworks let teams of average competence to handle more challenging tasks, raising the complexity cut-off above which the shit pile collapses on itself and the product never gets published. This is not a good thing, because in practice, this means more garbage software being produced, and competing against older software that - by definition - had to be not shit just to see the light of day. Thing is, more and cheaper garbage always wins on the market because it's cheaper to make (= more money on polishing the turd and marketing the heck out of it). Overall result: instead of fewer good offerings, we have a glut of garbage ones.
It always puzzled me that we haven’t collectively invented some ways to skip all this “complexity” like e.g. ERP/CRM/CMS platforms do. Instead every team figuratively rewrites their whole stack from scratch in assembly. Even google sheets can publish a document and make it dynamically work faster and easier than any real-world webapp. I get your ideas, but we all are missing something here.
Consider, we've pretty much solved the problem of quickly creating good GUIs for software with RAD tools in the 1990s/2000s. But that was on the desktop. Then the web happened, and then mobile happened, and we couldn't port RAD tools to them because the web platform, having been created with documents in mind, was fundamentally incompatible with ideas behind GUI. We've collectively spent the last 20 years simultaneously trying to paper over this incompatibility, while slowly pushing the underlying platform to be more app-friendly.
Today, the platform is still torn between the document and app paradigm, and we've managed to begin replicating the most basic features of RAD tools of yore, but all on top of a mile-high heap of bloat. But the Earth didn't stop in its tracks for those 20 years - the world underwent the digital transition in that period, businesses had to make do with whatever tools were available, no matter how shitty, and thus we've been experiencing a high-paced churn, with services being constantly upgraded as old hacks stopped working, and new ones promised (often falsely) to be less shitty than those before.
Maybe it'll all settle one day. The web will slow its evolution, and people will have time to clean up all the mess, and then we'll finally dig ourselves out of this big regression in software quality, capabilities, and production time, relative to the RAD times. But until then, we suffer. Transitional periods suck.
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.
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.
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.
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?
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.
I suspect the reason it hasn’t become commonplace to build web UIs with it is because your average frontend dev isn’t too familiar with those languages or their UI libraries nor writing a browser compatible rendering backend for them.
If I need to pass strings, structs, bytes etc I have to allocate memory inside the WASM instance, serialize the data into this memory, pass the memory offset as a parameter to the function that should operate on it, deserialize the data and then clean up the mess. This is awkward, error prone and risky.
Yes, I do use WASM from a high level language that has automatic memory management. That's why this old fashioned messing about manually with memory allocation and doing pointer arithmetic seems like such a huge step back.
Yes, there are people that make plugin frameworks. And yes, one of the things they have to do is to hold their nose and just accept that this is the ugly reality of using WASM. It doesn't mean that this isn't a terrible design flaw. It is.
And what's really important - when you talk about the induced risks many teams have no clue about them...
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.