
JavaScript Fatigue: Realities of Our Industry - lucasfcosta
http://lucasfcosta.com/2017/07/17/The-Ultimate-Guide-to-JavaScript-Fatigue.html
======
bad_user
These statements are false:

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

~~~
crimsonalucard
Also are you kidding about Monoids? No way category is part of any General
Education curriculum.

~~~
nostromo123
Sure is, I can confirm for Romania. We studied it as part of 12th grade
algebra (last year of highschool, in Romania).

If you don't believe my personal anecdote, here:
[http://www.meditatiionline.ro/44100-122-411-0-0-Formule_Mate...](http://www.meditatiionline.ro/44100-122-411-0-0-Formule_Matematica_Grupuri_Structuri_algebrice_Monoizi.html)

(site is -- obviously :-) -- in Romanian, but it's pretty clear)

It's material specifically targeted at 12th grade students, in normal
highschools.

------
le-mark
There are a lot of questionable ideas in this piece.

> 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...](http://www.itu.dk/people/hesj/BSUP/artikler/no-silver-bullit.pdf)

~~~
lucasfcosta
Hi le-mark,

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!

~~~
le-mark
Ah ok, hyperbole can be an effective oratorical device, I use it myself from
time to time. It's tricky though.

~~~
exelius
Side note - this type of exchange is why I love HN. It's like Reddit for
mature adults.

~~~
na85
>It's like Reddit for mature adults.

The immaturity has simply been replaced with smugness and elitism.

------
vlunkr
I think what this doesn't address is why fatigue is more of a problem is JS
than in other languages. You rarely hear about Ruby fatigue, Python fatigue,
etc. Is the insane turnover rate of JS tools really essential to writing great
software?

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.

~~~
wruza
I think JS has this problem because of constantly high inflow of new
developers who easily get on new boats. They cannot differentiate between old
and new tools (except for hype and cv-driveness), and new tools don't kill
their productivity as much. Personally I never made it into frontend because
learning basics makes me sick of html/css/js trinity, and learning advanced
tools is a neverending war. Advanced js programmers feel that and try to
create more tools, shorting the circuit.

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

~~~
icebraining
Why do we need new stuff? What's wrong with the existing ways of connecting
processes over the network?

~~~
verinus
the effort required to write boilerplate code over and over again with no
standard way I would guess...

------
weq
I totally agree with the article, but i also find it ironic because this guy
got his platform speaking at conferences which IMO as the root of JS fatigue.

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.

------
specialist
From the article:

 _" 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/](https://psychcentral.com/lib/the-5-stages-of-loss-and-grief/)

~~~
RandyRanderson
I laughed out loud at this.

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

------
juststeve
Everyone wants to make developer tools for street cred, and the github 'social
coding' culture is just a vehicle for self promotion. I agree that in the
blogs and conferences there's not enough focus on solving business issues, but
people should care about languages, because it also is a business issue as
others have pointed out. An example: if I worked in a AAA game studio and I
decided to write a critical feature in haskell and then quit, will my boss and
coworkers care? Maintainability of code, documentation quality and testing are
not prioritized enough in the community and conferences which is why i feel
there is so much churn, and we get a new programming language every second
friday. ie the new tools are the symptom, not the cause of the problem.

------
anoplus
The writer has nailed it for me.

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

~~~
didibus
I dunno about this. Automation of tasks that used to be manual is real, but
software goes beyond this.

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.

~~~
bryanrasmussen
I agree that software does not just have to be about destroying jobs, but
people are often working on projects that will kill jobs and won't acknowledge
it.

~~~
didibus
In my experience people have always acknowledged it. Now did they care is
another question.

------
edem
This article fails to address the main problem: the javascript ecosystem is
like a cancer: it spreads at an alarming rate and you just can't keep up and
the quality of the tools converges to zero. Even the numerous
[hiccups]([https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/](https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/))
don't make js devs realize that there are big problems at the heart of the
javascript world. They are either blinded by the Blub paradox or just do it
for the money. Most js devs don't even know what big O is and how do you
expect someone to write a graph library (or anything involving the simplest of
algorithms) without that knowledge?

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.

------
drinchev
> Nowadays something I see very often is people looking for boilerplates when
> they’re trying to learn a new technology, but, in my opinion, you should
> avoid boilerplates when you’re starting out.

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](https://github.com/chentsulin/electron-react-boilerplate)

2: [https://github.com/chentsulin/electron-react-
boilerplate/blo...](https://github.com/chentsulin/electron-react-
boilerplate/blob/4fbc20253374bd2b378ef8dfbff37566eb83cc45/package.json#L118)

------
jondubois
I think that a problem in the JavaScript community is that some projects and
people rise to the top extremely quickly and this creates undue hype - Then
developers just pile onto the latest shiniest ideas and abstract concepts
without actually doing the due diligence for themselves in a real-world
practical setting.

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.

------
tanilama
> Technology is not a goal. 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.

This. Technology doesn't matter, if your code doesn't fulfill a mission.

~~~
Xoros
And it may brings back a little bit of humility in our field. There's often no
need for a hammer, as shiny as it is, to crack an egg open.

Sometimes quick and dirty makes clients happy, and sometimes this is all that
matters.

~~~
mythrwy
While this is certainly true it's also our responsibility to consider the long
term well being of a client rather than just their temporary placation with a
bit of sugar. Picking apart what people actually need from what they claim to
need is an underrated skill.

~~~
unclebucknasty
> _our responsibility to consider the long term well being of a client_

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.

------
spankalee
The progression from AMD to CommonJS and all the additional tooling that
required is one of the worse things to happen to JS, but it's treated here
like just a natural progression from worse to better. AMD actually works in
browsers given the features they have. CommonJS requires tooling to function
and IMO started the avalanche of tools we need today.

JS modules cannot come soon enough. I only hope Node doesn't screw things up
for browsers too badly with its modules support.

~~~
model_m_warrior
There was nothing wrong with AMD loading, but the Js developers really wanted
to use their bloated frameworks. We're several years in. Everyone getting
their advanced Js applications faster? Exactly.

I like Js.

------
FLUX-YOU
>which is why it is extremely important to know the problem domain we are
working on

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?

------
progx
" __JS __Fatigue happens when people use tools they don 't need to solve
problems they don't have"

Why JS only? This statement applies to everything, not only development.

~~~
bryanrasmussen
Yes - the specific JS Fatigue is thus an instance of a more general type of
fatigue. As it is often the case that specific things turn out to be instances
of more general things.

------
quanticle
Original site appears to be down, but Internet Archive has a mirror:
[https://web.archive.org/web/20170727012317/http://lucasfcost...](https://web.archive.org/web/20170727012317/http://lucasfcosta.com/2017/07/17/The-
Ultimate-Guide-to-JavaScript-Fatigue.html)

------
mpg515
It would be very nice if browsers were not so bad, and included more than just
Javascript rendering engines. Like, I don't know, maybe Python? I am
personally very tired of being tied into JS. I don't even like it as a
language very much but since I'm a FED, I have to use it, or something that
transpiles to it. This is not a very good paradigm.

------
jack9
JS doesn't have a reasonable patch and release cycle, so it's always going to
be a chore to try to keep up with discoveries and best practices. The
noticeable uptick in releases for other languages are why it's such a joy to
work with living languages, instead of the twisted JS world of half-measures
and fallen-behind code.

~~~
digi_owl
Half and half.

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.

~~~
jack9
> But the uptick in other languages is likely more because they are new and
> therefore there they have a virgin land advantage.

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.

------
danso
> _Reusable space rockets, self-driving cars, robots, artificial intelligence:
> these things do not exist just because someone thought it would be cool to
> create them. They exist because there are business interests behind them.
> And I’m not saying the people behind them just want money, I’m sure they
> think that stuff is also cool, but the truth is that if they were not
> economically viable or had any potential to become so, they would not
> exist._

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.

------
lisa_henderson
You won't find anything in any set of economic statistics that can offer the
slightest justification for this statement:

"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...](http://www.bradford-delong.com/2017/07/monday-smackdown-republican-
economists-burn-yet-more-of-their-reputations-department.html)

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.

~~~
lsh123
"Labor productivity has been in long-term decline"

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.

------
andrewstuart
Actually I think that in many cases the technology is the goal. Much of
programming is driven by love for the art and the craft and much programming
is done primarily because its what people to choose to do because they love
it.

Reducing all programming to meeting some business case defined by a business
person is well.... not right.

~~~
digi_owl
And yet some of the biggest commercial software successes are just that, to
hell with everything but the business case(s).

While at the same time massive elegant pieces of code get stuck in limbo
because the people in charge keep chasing programming perfection.

------
sAbakumoff
I always thought of programming as the art. it needs you to be creative, it
may give you moments of enlightening and desperation and happiness and
depression. the article tries to persuade me that actually all that I do is
reducing cost. sad.

~~~
sAbakumoff
Downvoters, do u care to elaborate?

------
shusson
Please stop calling it JavaScript Fatigue. The complaints are web development
related(specifically the browser) not language specific. The distinction is
important because people keep trying to compare the issues with other
languages.

~~~
pluma
I am what the cool kids call a fullstack developer these days. I use
JavaScript in the browser and on the server. My build tools are written in
JavaScript. I also write JavaScript for the database (in fact, I am a
contributor to a database that is _partially_ implemented in JavaScript).

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.

~~~
shusson
Languages usually have a technology that drives their popularity. Javascript
has the browser, and in my opinion the browser is the reason for most of the
fatigue. Sure call it FOMO, and of course it happens in other domains, but web
development has it particularly bad.

For example compare iOS development vs web development.

------
rv77ax
I bet the author use space instead of tab.

~~~
pluma
If you write JavaScript and don't use two spaces for indentation you're being
intentionally obtuse.

~~~
scottmf
What why?

~~~
pluma
Because you don't exist in a vacuum and two spaces is the most popular form of
indentation in the ecosystem.

But these days I recommend using an intelligent autoformatter like `prettier`
when writing JS exactly to avoid any such discussions.

------
carapace
> Software solves business problems. This is it. Software does not exist to
> please us as programmers and let us write beautiful code.

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

