JavaScript Fatigue: Realities of Our Industry
lucasfcosta.com
lucasfcosta.com
> "Software does not exist to please us as programmers and let us write beautiful code. Neither it exists to create jobs for people in the tech industry. Actually, it exists to kill as many jobs as possible, including ours"
Software exists for whatever reason we want it to exist.
I started programming when I was 12 and that was 23 years ago. I sure as hell didn't start programming to solve business needs or to kill jobs.
In fact this mentality is what I find most upsetting about the industry. Tell a software developer to pick a problem and solve it and he'll almost always look at automating existing workflows.
There's this saying that most business software is about automating an Excel spreadsheet shared by email and it's true.
But it doesn't have to be that way. Software could also empower people to do things they wouldn't have dreamed of doing before. Just like with musical instruments, which are empowering people that don't have a voice to produce music. And we don't have to look far for such examples. Just the other day I was reading about a nice app by Microsoft helping the blind to see.
Software's purpose, if it has any, is to be an extension of our minds.
As for the fatigue, that happens because it's 2017 and we are forced to use tools that can be worse than those available in 1980.
Of course, such tools wouldn't be successful if many of us weren't guilty of anti-intellectualism. Just look at how many six figures professionals bitch and moan about having to understand what a Monoid is, even though it's part of standard high-school curriculum in some countries, like Romania.
@tools: just in the WebDev world. I am still battling to start developing web apps, coming from a java/C# now mostly F# world where we can actually debug effortlessly, use static typing (or the superior type inference in the case of F#) and so on
I forget his name, or where I heard it.
I don't know this particular case, but it's well known that countries from the ex-USSR teach math at much more intensive level. I personally know multiple parents who have immigrated to my Western European country and who complain that their child is being taught concepts they've learned years ago, so much that the parents end up having to home teach them after school.
If you don't believe my personal anecdote, here: http://www.meditatiionline.ro/44100-122-411-0-0-Formule_Mate...
(site is -- obviously :-) -- in Romanian, but it's pretty clear)
It's material specifically targeted at 12th grade students, in normal highschools.
Unless you're arguing _all_ programming language ecosystems are rotting (or too young and niche to have an actual ecosystem), I have no idea how you're arriving at that conclusion.
EcmaScript, HTML and CSS are standards that are continuously being developed and seeing updates. Browsers are now evergreen or quickly becoming irrelevant (even old IE will eventually be replaced by the evergreen Edge). My build tools are mostly Webpack and Babel, two actively maintained projects with highly active communities. My applications are mostly built around React, which is also in active development and has the full weight of numerous major companies behind it (not to mention it's being sponsored by Facebook).
So I ask you, how is "the ecosystem" rotting at "its core"? Are you talking about jQuery which today can mostly be replaced by native browser APIs but is still getting updates? Are you talking about Backbone, which everyone has been moving away from for years? Are you talking about Grunt and Gulp and all the other task runners which merrily chug along on myriads of development machines?
The JS ecosystem isn't rotting at its core. The JS ecosystem has no core. And it's not rot, it's compost, obsolete refuse disintegrating to give way to new development, feeding the ecosystem by releasing developers who would otherwise be stuck maintaining outdated technology.
Javascript is a crude tool and the fact that [it was created in 10 days](https://www.w3.org/community/webed/wiki/A_Short_History_of_J...) does not help it.
This language has a lot of compost as you say but one can't differentiate between refuse and pristine tools (the latter might theoretically exist) just by looking at it and no one has the time to analyze all the tools he might end up using since there are so many. So you take one which has the most stars on github (like I did with [graphlib](https://github.com/cpettitt/graphlib)) then you realize that it is crap and you end up writing one from scratch.
Someone said: "A computer is like a bicycle for the mind."
- There is a variety of bicycles at various price points, quality, styles and for varying terrains. If at all possible choose the one you like as much as the one that fits your problem.
- You can enjoy a bicycle by itself and not just for moving your body from point A to B
- I believe fatigue (in general) comes from everyone and their dog reinventing a variety of bicycles, each one a million times, and most of them are half-assed enough they can only roll around a circus pit, if at all, and abandoned the next day they're published (spoiler: maintaining is hard!). Even the high profile ones get through the let's do this again, only different, and we promise, we got it wrong the first time but now it's ok! But it's not helpful for the mind to endlessly learn a new way to ride for the umpteenth time only to pedal in circle. And I believe JS fatigue because of its tyrannic omnipresence in browsers as well as the limitations of the platform lends itself to (almost coerces people into) solving the same problems again and again.
Yes, the author stated this from a very narrow point of view. Software exists for whatever reason we want it to, but business pays people to build it to solve their problems.
>almost always look at automating existing workflows.
I've always justified it in my mind as making existing workers more productive. As long as the company I was working for was constantly hiring, growing and in a competitive market, it was ok.
The paragraph about no one cares what language you use, etc is obviously false. Write a PHP app in a C# shop is an easy way to disprove that theory.
Also, what the author fails to take into account is scalability. As the business grows, the software needs to grow with it, or all those marketing dollars they threw in to grow the company will be wasted and growth will be halted. That's where the business would need to defer technical decisions to technical people.
An acquaintance of mine currently works for a company who is about to hit a hard wall where they will no longer be able to take any more orders due to scalability of the software they chose. They aren't doing much about it, not realizing that by the time this happens, it will be too late. The CEO probably read an article just like this.
But I will agree with the author that JS, and web front end in general, is way more complicated than it needs to be.
> Nobody cares about which programming language you are using, nobody cares about which frameworks your team has chosen, nobody cares about how elegant your data structures are and nobody cares about how good is your code. The only thing that somebody cares about is how much does your software cost and how much revenue it generates
I agree with this to a point. The business cares about code quality so far as it effects the ability to deliver new features and maintenance, which in reality means they care quite a lot. They don't understand, and they can't express it, but they do. I work on a legacy app now that is so brittle the team takes months to deliver features, and they're buggy and error prone. This team is competent for the most part too.
> JS Fatigue happens when people use tools they don't need to solve problems they don't have.
I think the concept the author is going for is best elucidated by Fred Brooks in "No Silver Bullet"[1] when talks about accidental and essential complexity. The idea that there's the complexity of the domain/problem and the complexity we introduce as part of the solution, such as build systems, cross compilers, mvc frameworks etc...
> The JavaScript ecosystem nowadays is responsible for the global revolution the same way steam engines were responsible for the first industrial revolution
I really can't imagine a scenario where this is true. I'd prefer to see some clarification what revolution the author is referring to exactly.
[1] http://www.itu.dk/people/hesj/BSUP/artikler/no-silver-bullit...
Thanks for the feedback. I realize you're right about your last point about the industrial revolution.
That was totally my fault, I didn't intend for people to take that literally but I wrote it in a way that made it sound literal.
Since that was only an introductory statement I decided on removing that based on the facts shown here later in other to avoid deviating from the post's main subject.
Thank you very much for sharing your thoughts!
The immaturity has simply been replaced with smugness and elitism.
This completely elides one of the biggest issues (at least in my job)
-Who is going to maintain the code and how much is that support going to cost.
Maintenance can include troubleshooting and bug fixes/enhancements and sometimes it's just pure support (i.e who does the user contact if their app is crashing).
I don't know about the web which is what I usually associate Javascript with but for in house business applications delivering a well supported application is critical.
I've found (as someone who occasionally has to commission contract work) that unless I am upfront (and dare I say confrontational) about support and maintenance expectations during the design phase I will end up with a complete mess at the end and support costs will end up ballooning out.
I finally started to feel the fatigue with the React and Webpack takeover. I was really into them at first, but I realized that while I was constantly learning new tools, my software wasn't really improving, in fact all the constant changes with upgrading tools was causing a lot of headaches and bugs. And at the end of the day, a good dev can create the same app with react and webpack, or coffeescript and ember, or plain old JS and jquery.
In short, JS fatigue game me premature "get off my lawn" syndrome and I actively avoid front end work now.
But as far as managing data, behavior, socket communications, and CSS-styled DOM manipulation goes, I have zero desire to enter the morass of heavyweight framework churn. JavaScript is a pretty reasonable language that you can be quite productive with even in the browser for front-end tasks.
Sometimes you don't have much of a say into how big things eventually get and sometimes things get a whole lot bigger than you initially imagined.
Good organization helps but still, as a jQuery fan myself who has gone through this a few times recently I've started to realize there may just be a better way. Particularly throwing more than one dev in the mix. Going through someone else's tangled box of electrical cords is no fun at all.
>At a certain size you should look into frameworks
I hear this a lot--the idea that jQuery or vanilla JS can work for smaller projects if well-organized, but larger projects require frameworks--however, I honestly have no idea how it makes sense.
Seems to me that if you have a good pattern and foundation, then it should scale up to larger projects; else, what we're really saying is that it's still a mess, but a small mess that's manageable because the project is small and there isn't that much code.
But, the framework dogma these days is such that we dare not even suggest undertaking a large project without committing to an "acceptable" framework du juor.
I say this as someone who sees some value in frameworks, but also doesn't believe that the ROI is always there, or that it is absolutely necessary to use a framework on even larger projects. After all, frameworks aren't magical. They are just code. More specifically, they are reusable libraries attached to pattern enforcement. Why can't I choose a couple of libs, come up with reusable code, and implement my own patterns without all of the added cruft, opinion, politics, and risk of jumping on someone else's framework?
Plus, many frameworks have just gotten way too big and complex, and we too infrequently emphasize the cost of using a framework vs. simply championinig the benefits. I want one-way data binding, but I have to change languages, introduce copious build steps, and generally follow all of your opinionated patterns, introducing layers of cruft and structure? Then, after all of this, you may change course with no upgrade path or the framework may simply become unpopular? No thanks.
It's like developers don't want to design anything these days.
Frameworks are generally overkill and, increasingly, insert too much opinionated cruft into a project. How can it possibly always be more efficient to wedge in this singularly opinionated way to implement every app just because the team exceeds n members?
There are ways to enforce discipline on larger teams without relying on someone else's ideas.
Often the challenge in scaling up UI code isn’t the amount of data, it’s the increasing complexity of the relationships between different parts of the data. The more dependencies, the more you have to take into account when you’re updating one part of the UI in response to a change somewhere else.
In another comment, le-mark mentioned Brooks’ distinction between essential and accidental complexity, and that applies here as well. A UI needs enough logic to represent the essential complexity in the underlying data, which might be complicated in itself. However, sometimes the UI also introduces accidental complexity to handle transitioning from one state to another.
This is why I find the modern rendering libraries like React to be a genuine improvement in the state of the art. They allow rendering based on the absolute state of your system, instead of changing the DOM selectively relative to whatever was already there, which in general may be an exponentially more complicated situation. Adopting this approach can directly and sometimes dramatically reduce the complexity of the UI code, compared to manually changing the DOM in response to changes in the underlying state.
The heavyweight frameworks I’ve seen don’t offer that same sort of qualitative improvement. They do provide a systematic architecture, which can certainly be helpful as software grows. On the other hand, we’ve been building much larger software than any web app using good software design principles for decades, without necessarily needing the help of these pervasive frameworks. The trade-off with frameworks usually seems to be a quicker start time as the big advantage against potentially being less flexible if the project’s needs change later as the big disadvantage, but since neither of these issues is unique to frameworks this feels like a quantitative question more than a qualitative one.
I agree 100% that the biggest challenge solved by many of these frameworks is state management and, more specifically, capturing and reflecting state changes in the UI. Just seems that most frameworks start addressing this single issue, then get greedy; metastasizing their way up and down the stack. Suddenly, you're completely hooked in, using npm or similar to generate tons of boilerplate with framework-specific templating and a mini language, on top of a custom build process.
So, simplicity is kind of an amorphous concept here. Maybe you pick up the binding, but you've traded away a lot for it. I haven't had much experience with React, and maybe it does a better job of confining its intrusions to view state management. But, with Angular and others, I have seen and experienced these huge learning curves that make sound developers' heads explode. Like anything, we eventually get it and it becomes second nature, so the perceived complexity is hidden to some extent. So, we tend to say, "hey, look at this neat binding that simplifies my code". Meanwhile, we're completely overlooking the learning curve, boilerplate, build process, and MB-denominated framework file sizes.
>potentially being less flexible if the project’s needs change later as the big disadvantage
Interesting take, as it's usually the reverse you hear: that is, without a framework everything will devolve into utter chaos as the project grows and takes on new requirements.
My take is that, framework or no, at the end of the day nothing can take the place of good design. And, I guess that's really my larger point here. People tend to offer up "framework" as the one word answer to Web development these days, and I don't think that's a healthy state.
I think that without frameworks, software developers would not have been able to move between companies so easily and salaries would not have gone up so much.
I don't quite understand the model of writing that would lead to massively tangled jQuery code. Obviously, I'm building internal use and personal projects, but I also design my UI elements based on what HTML/CSS already offers, instead of trying to force foreign designs & models on it.
Of course, JS & front-end development isn't my primary domain. Backend distributed non-web servers, data analysis, and software automation is more my thing. Front ends are just a side requirement of completing the loop sometimes, but software manageability issues at scale aren't unfamiliar to me. I just don't see how people can tangle themselves up as much as they have across the board in the web front end domains.
It's not necessarily a matter of "tangled up" (although that happens also with size if one isn't careful). It's more a matter of very unwieldy to work with and a lot of cognitive overhead. The few "updating DOM" things turn into hundreds, the callbacks multiply, "what function was it that did this? What file was that in?", the bindings start tripping over each other, it quickly turns into another level of problem at size and when it gets to the point it does it's big enough to be real work to refactor.
At the scale you are talking about sure, raw HTML, a handful of global functions doing this and that and a few arrays and objects holding data, no problem. If you have (or work with) something of a different scale using jQuery I'm pretty sure you'll see for yourself and come to the realization I have. There's a reason for the rise of these frameworks and it isn't all fancy hipster nonsense. Well not all of it anyway :)
My solution was to move back to native front end.
Still do web, but try to avoid it.
But those same people also probably worry when they see that a huge percentage of job postings involve front-end web development.
The sense I get,though, is that while there are many web-focused jobs available there's also a ton of competition for those jobs. Whereas with native front end development, there's less demand but also far fewer developers qualified for/interested in the work.
This led to a lot of ugly UI, but also pretty tight low latency UI (compared to the web).
It also impacted job descriptions and the way people think about hiring.
I am the lead developer at a firm with about 25 software developers, we do JavaFX GUIs when we can. We do not mention this in job specs. We do not hire for "frontend" guys specifically. Writing JavaFX code (or WPF or Qt) is just too easy to bother doing a specific candidate search for them - any competent dev can learn these frameworks quickly (and they do). The primary reason to search for UI specific skills in the desktop world is to find people who truly understand usability and graphics design, which is a separate skillset to what the modern kids call "frontend development". There are lots of web UIs out there that look superficially attractive as they just imported a stock CSS theme but which are actually confusing, nonsensical or simply can't scale to the addition of more features. UX design is as much about figuring out your user stories and workflows as it is making nice graphics.
In the case where developers need to do their own UI design, I prefer to just train them and push them to consider appearances when doing the work. It's easier to train someone how to make an attractive-enough UI than to train them in great software engineering. So ideally you'd have two specialists tag-teaming but when that isn't possible, desktop UI + some training is the way to go.
We've used angular on a few projects, but it took time to educate our staff and their time to market as well as the required support increased significantly, and then angular 2 arrived...
Honestly it seems like the JS exists to sell a lot of education and a lot of books. Maybe we did it wrong, but as a clean business case angular was a terrible for us.
(Otoh, programming has changed since our youth time. Back then we programmed for one local, now we do it for thousand remotes. Latency penalties turned upside down literally, storage is faster than SIMM, ui is slower than FDD.)
Since web 1.98a* we stopped to look at program as a whole and separated it into frontend and backend. That was a key point that allowed so much divergence and frustration. It may sound crazy, but we need new, more low-level browser (don't even call it browser, it is a network layer) that could seamlessly connect single heterogenous app on two network endpoints, since no one really cares about underlying protocols anymore. Leave www rot in browser and make internet apps great again. All good tools from '95 are still here.
* you cannot call something 2.0 until it has at most 2-3 generic and mature ways to do everything.
XWindows (https://en.wikipedia.org/wiki/X_Window_System)?
https://en.wikipedia.org/wiki/Time-sharing#Time-sharing_busi...
Frankly, JS is now much more sophisticated, and definitely requires code design skills.
I will probably have to deal in the following years with a Typescript/Purescript + IntelliJ envrionment.
And that makes me much happier than having to deal with JS spaghetti code from the Web2.0 era.
If we didnt have JS conferences we wouldnt have the level of hype that goes into the next-new-shiney-thing. We wouldnt have a platform for companies to sell ideas and platforms to programmers that they dont need, and we wouldnt have the blog posts and opinions of people who go off to create new solutions to old problems etc etc
I totally agree JS fatigue is just another facet of capitialism. You are a programmer, and just like in the gold mining days, the people who got rich were the people spruiking wares to the miners.
Just like how Apple tells u, u need an iphone to be cool, the JS conference tells u, u need a framework to be cool.
And the key thing to remmeber is - dont beleive the hype. read the code, and make an informed choice. Every dependency in your project should be treated like a matter of life and death.
"Complaining about JS Fatigue is just like complaining about the fact that humanity has created too many tools to solve the problems we have..."
Um. No. (Full stop.)
JavaScript et al is evidence that the cone of ignorance expands faster, further than the cone of experience. Wisdom can never overtake, vanquish the chaos.
Many geeks thought rationality would win. Like a natural law. Alas.
Complaining is just stage 2 in the bereavement cycle.
With respect to JavaScript, I'm now in stage 3. Because I have to make rent.
As for the creators, champions, defenders of JavaScript, I relish the certainty that in a few years they'll be complaining about whatever garbage succeeds them. Payback. I hope it sucks.
https://psychcentral.com/lib/the-5-stages-of-loss-and-grief/
There's two types of these guys:
1 the ones who don't know what they did was awful and are thinking about how great they are
2 The ones who know what they did was terrible and are imagining how their shit tastes in our collective mouths
Alas, both types are happily retired from book sales and conference speaking fees, so...
> Software does not exist to please us as programmers and let us write beautiful code. Neither it exists to create jobs for people in the tech industry. Actually, it exists to kill as many jobs as possible, including ours, and this is why basic income will become much more important in the next few years, but that’s a whole other subject.
A lot of software allows new or better technologies which can be used to transform the human experience. Such as video games, flight control systems, video conferencing, etc. Other can save lives, such as radio therapy controllers, alarm systems, pace makers, etc. Some can take it away more effectively, like guided missiles, self manned aircrafts, etc.
Just wanted to point out it exists for more then just that.
Also, in the current market, a company who wants to retain good talent has to allow them some fun, amd giving them the choice of tools or language can be a good recruiting tool, or mechanism to keep good talent.
Software exists to solve user problems (for varying definitions of 'user' and 'problems').
Some problems are time/cost related, and software can automate some of those things to solve that problem.
But then some problems are preventative (or rather, the time and costs prevent things) so software can actually enable new things to happen, like letting the blind use cameras, or enabling more restaurants to do deliveries.
At least there are languages which can be compiled/transpiled to js and WebAssembly is coming so I don't have to touch this abomination.
The top of the top JS Fatigue I've seen, for a while, is Electron React Boilerplate [1]. Just take a look at dev dependencies [2].
I totally agree with the author with not starting with a boilerplate, but as far as I can see, the community thinks the other way around.
1: https://github.com/chentsulin/electron-react-boilerplate
2: https://github.com/chentsulin/electron-react-boilerplate/blo...
Eventually, developers realize that while the over-hyped tool or framework that they're using does add a form of theoretical elegance to their project, it also carries crippling non-obvious overheads which slow down real-world development overall.
I think it's important not to buy into hype. When evaluating and selecting a framework or library for a project, if it has had a lot of hype then instead of marking that as a positive on your checklist, it should be marked as a neutral or sometimes even as a negative.
This. Technology doesn't matter, if your code doesn't fulfill a mission.
Sometimes quick and dirty makes clients happy, and sometimes this is all that matters.
True, but I don't think the answer is just "framework" either. A more thorough analysis of many of these scenarios would likely yield a surprising number of cases wherein the answer is not framework, if all tradeoffs were earnestly considered.
For instance, a couple of short years ago it would have been seen as responsible to build on Angular 1.x. Today, those clients are stuck with an obsolete, underperforming stack that has been deprecated with no reasonable upgrade path.
In some ways, knowing what we do about the ever-changing framework landscape, a reasonable argument could be made that it's almost irresponsible to recommend dependency on these ever-heavier, more intrusive, monolithic behemoths.
JS modules cannot come soon enough. I only hope Node doesn't screw things up for browsers too badly with its modules support.
I like Js.
To a point. Time spent learning the business domain can't be spent on finding new tech products. If you don't explore new tech products, you are potentially missing out on something that would further allow you to maximize revenue and minimize cost or generate new revenue streams or offer some new service that the business wants.
While learning the business domain from people, you're taxing people who could otherwise be working on business problems. There is communication overhead you can't get rid of. You can fatigue someone with domain questions as well. I can't go bother a surgeon any time I feel like it for surgery software feedback -- the guy's likely busy saving lives.
If you're lucky enough to get a mentor who's willing to spend time to teach you the field from an entry level, great, but realize that person could be addressing problems with their expertise and are paying an opportunity cost to teach you, which could translate to revenue or reduced costs.
If you're going to teach yourself to be good at two entire fields, programming and your problem domain, then you're spending a lot of time on that. There might be jobs to tide you over, but again, what else could you be doing with this invested time?
Why JS only? This statement applies to everything, not only development.
It seems that between chaotic feature addition and backward compatibility requirements JS becomes a new C++.
Yes JS is a chore to keep up with because everyone can just push crap online willy nilly.
But the uptick in other languages is likely more because they are new and therefore there they have a virgin land advantage. Thus everyone and their dog jumps in to play with and stake their claim on fame and fortune.
Soon enough those languages will again be bogged down in half measures and fallen behind code.
This because while developers wants to play with new ideas and new code, users value stability and predictability.
That is incorrect. The languages in production that interact with javascript, might be a better way to think about it. They are all generally older than javascript (as opposed to dead, like ALGOL). The MS ecosystems and Java might have a bogged down problem in the future, but when even Lua is updated more frequently than JS, you might want to question the wisdom of the current processes.
This feels like an overly reductive assessment of why people write software. Is the author completely unaware of software projects or technology in which profit motive was not the goal? Are all the engineers at the Internet Archive just using IA as a stepping stone to joining a VC-funded firm? Is ESR just a big fake? And Woz, too?
While it's possible that everything we do in life -- from joining Tinder to hook up, or building Tinder's phone app with React Native and getting paid a high salary -- has no higher purpose than increasing the survivability and propagation of our genes -- there are folks who program and derive joy from building. This includes the early days of Sergey and Larry and Mark Z.
In any case, I'm not sure why this is a useful or interesting lens to view JavaScript churn with. The assertions in this article are just all over the place. In one line, the author writes:
> Optimize when you need, otherwise you will probably be adding unnecessary complexity to your software, which increases cost, and not generating enough revenue to justify that.
And then later on (by "later", I mean the very next line):
> This is why I think we should apply Test Driven Development principles to everything we do in our job. And by saying this I’m not just talking about testing. I’m talking about waiting for problems to appear before solving them.
OK.
Maybe the author seems to have worked on projects in which problems reveal themselves, and do so in convenient serial order. But I imagine many people who end up in frustrating technical debt don't get in that situation willingly, but because life and work and problem solving are messy and chaotic.
> Software does not exist to please us as programmers and let us write beautiful code. Neither it exists to create jobs for people in the tech industry. Actually, it exists to kill as many jobs as possible, including ours
I think basic income is a serious issue that we have to consider in the coming years, but I never understand why programmers can't think past their own jobs. When I write programs to automate work in my life, I don't think of it as writing software that puts myself out of a job, but writing software to enhance and augment my intelligence and productivity. Sometimes that helps my financial bottom line. And other times it let's me tackle even greater, more satisfying challenges.
"The JavaScript ecosystem nowadays is responsible for the global revolution the same way steam engines were responsible for the first industrial revolution"
That is ridiculous. Here is reality:
1.) Labor productivity has been in long-term decline, though computers did cause a temporary surge in the 1990s. See the charts in this post:
http://www.bradford-delong.com/2017/07/monday-smackdown-repu...
2.) Economic growth remains sluggish, especially compared to the post war boom of 1945-1973.
3.) The railroads sparked a massive investment boom. The only time computer technologies came close to triggering a similar boom was during the 1990s.
Thanks for your feedback and for providing such interesting facts.
I really exaggerated in that hyperbole. Thanks again for pointing this out.
If I read the graphs from the link correctly, they show that % productivity growth is declining. Still it is positive thus the productivity by itself continues to grow. Hard to say from the graphs, but it looks like absolute productivity growth per year is bigger (or at least the same) as in the 50's: avg 2.5% growth over 60-70 years means ~5x increase of absolute value, thus 4% / year growth in the 50's is the same absolute value as ~0.8% growth today.
Reducing all programming to meeting some business case defined by a business person is well.... not right.
While at the same time massive elegant pieces of code get stuck in limbo because the people in charge keep chasing programming perfection.
It's absolutely a JavaScript "problem", not one that's specific to web development. Web development is certainly where it's the most prominent but the problem itself isn't at all related to the web.
JavaScript fatigue describes FOMO (Fear of Missing Out) as experienced by developers trying to keep up with rapid developments in tooling/libraries. It's not even really about the language, thanks to Elm, Reason and other new languages that joined the ecosystem.
You're right that it has little to do with the language, but it also has little to do with the niche. Anyone interested in DevOps experienced some degree of FOMO when suddenly Puppet, Chef and Ansible became a thing (being fundamentally different but also mostly doing the same job). If you just started out with Linux before Ubuntu pretty much became the mainstream starting point, "distro fatigue" was almost certainly a thing. It's just plain old FOMO, but with a tweetable buzzword attached to it.
For example compare iOS development vs web development.
But these days I recommend using an intelligent autoformatter like `prettier` when writing JS exactly to avoid any such discussions.
Code is a machine, and elegance will always be important -- bottom-line important -- to making good machinery.
I see programming as a divine pursuit of truth that, as a side-effect, will automate the solution of all our problems (except for over-population. That one's on us.)
At this point the total amount of code in the world should be contracting.