
Why I’m thankful for JavaScript fatigue - callumlocke
https://medium.com/javascript-scene/why-im-thankful-for-js-fatigue-i-know-you-re-sick-of-those-words-but-this-is-different-296fae0c888f
======
ysavir
> It’s like walking into a restaurant and finding out that they have all your
> favorite dishes and every one of them is free and complaining about how long
> it’s going to take you to read over the menu and make up your mind about it.

I suppose it's a matter of perspective. For me, it's more like walking into
used car lot. Most of the cars have lost (or voided) their warranties. Some
are certified pre-owned. That one in the corner looks nice, but I don't know
how to drive stick, and am not really interested in learning. At least it's
not a custom gear box, like this other one.

I can look at the new car lot across the street, but I'm not sure I want to be
the first to use one of those self-driving electric smart cars. It's neat, but
I'd rather stick to proven standards, and gas stations are more common than
charge stations, anyway.

And I could probably get to where I'm going with just a bicycle.

~~~
Touche
Also, the problem with big chain restaurants with a thousand things on the
menu is not reading the menu, it's that none of it is very good. Much rather
eat at a small restaurant with 5 things on the menu that are all excellent.

~~~
ksherlock
And the other problem is there are 23 kinds of bespoke artisanal ravioli and
maybe it was handmade by a Michelin chef or maybe it's from a bootcamp
graduate that spent two weeks learning how to blog, star things on pinterest,
and require('can-of-chef-boyardee')

~~~
strictnein
You gave me false hope.

    
    
       npm ERR! 404 Registry returned 404 for GET on 
       https://registry.npmjs.org/can-of-chef-boyardee

------
peterkelly
JavaScript fatigue is an affliction that affects only those who's learning
priorities are poorly chosen, such as framework-of-the-month.

This is why universities teach _computer science_ rather than just
programming. Learn about programming language _paradigms_ \- procedural,
object-oriented, functional, etc; the language itself doesn't matter. Learn
about relational databases. Distributed systems. Computer architecture. State
machines. Formal grammars. Language translators/compilers. Data structures.
Algorithms. Computational complexity/big O notation. That's the theory side of
things.

Understand Unix, version control systems, and how to log into and administer
remote systems. Learn about what TCP/IP is and how higher-level protocols like
HTTP relate to it. Ensure you're able to write a program in at least one
language that can talk to at least one type of database, and present at least
some sort of user interface. That's the practice side of things.

These things will pretty much set you up for life. By themselves they're only
a start, but you can pick up the rest as you go along, lazy evaluating any
expertise you need with specific technologies as you go along.

As far as front-end web development is concerned, all you _really_ need to
know is JavaScript, HTML, CSS, and the DOM. Pick an abstraction layer on top
of that _if you feel it helps you_ , but don't feel that you need to know
about every framework out there, because new ones are being generated faster
than you can learn about them.

And yes, becoming good at this takes many years. But ensure that whenever
you're investing time to learn, it's something that will last.

~~~
ktRolster
It's great to know basic principles, and I highly recommend that.

If you want to do frontend though, you need to know some concrete things. And
then you choose a framework (or more likely, some frameworks, since there's no
'one-size-fits-all'), and it no longer becomes supported. At that point you
begin to feel Javascript fatigue.

 _But ensure that whenever you 're investing time to learn, it's something
that will last._

Which web framework is that? Probably none right now. But waiting is not an
option, websites need to be built today.

~~~
awinder
You're investing the time to learn the architectural patterns, which will
likely either stay relatively similar over time, or morph (which will be
easier for you to pick up), or they're drastically change, in which case
you'll probably have a level of understanding for why they changed. And yeah
along the way you'll implement stuff today and that's an important component,
but learning is as much about the long game as it is the short game, and you
can play that long game without having too much anxiety over these choices

~~~
bobbytherobot
Exactly. I've met too many front-end devs who are unable to separate the
architectural pattern from the implementation of the library they are using.
They have the larger mountain to climb when needing to learn a new framework.

~~~
edblarney
"I've met too many front-end devs who are unable to separate the architectural
pattern from the implementation of the library they are using."

That's because front-end development is based on a core of HTML/CSS/JS which
itself does not lend very well to architectural paradigms.

People 'starting out' on the front-end, in some ways, never learn how to write
propers software. They've been using weird ideas from the start.

~~~
tpolischuk
That's actually kind of interesting. HTML/CSS/JS really are the framework.
It's already a great separation of concerns (HTML for data/content, Javascript
for behavior and logic, and CSS for presentation). Everything on top of it
just seems like implementation details.

~~~
elmigranto
If you want to display documents, sure, I agree. If you need complex UIs,
manually updating DOM without any kind of abstraction is definitely not a
right choice.

------
jjcm
I'm a prototyper, so people often come to me first to vet new ideas. Often
times this means implementing a feature on an existing product platform. When
I started doing this 5 years ago, I was working with a new language every
month. It was ruby one day, C# the next, and I'd go to sleep every night
praying next week wouldn't be PHP.

These days everyone is using javascript. In the last year I've done countless
javascript projects and _one_ project in java. I can't tell you how refreshing
it is to not have to brush up on syntax and install a suite of tools every
time I want to work on a new product. Nowadays it's just clone the repo, do a
npm install, and you're up and running for the most part. It's lovely.

------
fatbird
I agree with his point, but I think he mischaracterizes JS fatigue. He's right
that it's exhausting trying to keep up with all of it, and that's part of JS
fatigue, but the other side is the endless hype machine that's internal to the
tech community, where our media is an endless stream of "look at my new
framework!" and "you're doing react wrong!" and "why functional is making a
comeback!"

We do it to ourselves not just by continually stuffing the buffet with every
possible option, but also by making our community dialogue an endless
infomercial, which has a big influence on trying to keep up with it all. We
have conflicting desires to contribute and to self-promote, and the result is
an aggressive bazaar in which you need to consciously filter out 90% of the
noise so you don't get overwhelmed.

~~~
finchisko
I agree with you. IMHO I see it as good thing. Maybe 6 projects bring so
little innovation comparing to project they're trying to replace. But then
somebody will take the good parts of all those projects and create something
that is significantly better. Innovation does not grow on trees, there is slow
and bumpy road to it. :-)

------
hackcrafter
> Nobody is ever going to know everything there is to know about modern web
> architecture

I think this is the root of the sentiment that is expressed as "JS fatigue"
and bullet train rides etc.

I'm torn though. On one hand, this is equivalent to saying: Nobody is ever
going to know everything about an operating system and how a machine performs
the operations we expression a high level language like, you know, C!

The thing is, we still were able to teach the abstraction of the single-
machine computation model that C is abstracting in a single semester to the
point of making new coders _operational_.

But I can't imagine trying to construct a course to teach "modern web
architecture" in a single semester.

On the flip side, a lone developer who can chose their _battles_ wisely has
more leverage to produce something of value today than was ever freaking
possible, ever!

I'm betting on the the new "OS" abstraction as cloud-native services (DB as a
service, event streams as a service, mobile syncing as a service, heck,
everything but your core logic as a service).

But by it's nature this world is redundant, competitive, multi-vendor,
fractal-specialized and I only see that trend increasing.

So yes, one person will never know everything there is to know, the _new_
skill will not be learning every framework, platform or service, but being
able to grok the core nature and characteristics of your problem so you can
apply the closest matching tool with the maximum leverage.

Essentially, the _new_ skill will be to optimize for laziness :)

~~~
CoryG89
I am not sure I agree that optimizing for laziness will ever be a skill. But
indeed, I am not sure it's possible to know everything there is to know about
just about _anything_. How can you ever be sure there isn't still something
left to discover?

I am reminded of something I used to hear all the time: you learn something
new every day.

~~~
hackcrafter
Ha! Yes, my shorted argument of "optimizing for laziness" doesn't sit right,
but the core of it how much your choices matter in what you are _not_
building.

\- Cloud-based apps used to mean managing VMs, keeping kernels up to date,
setting security settings on server configs. It doesn't have to[0]

\- Mobile dev used to mean compiling platform-specific code and shipping it to
app-store review. It doesn't have to[1]

\- Storing state server-side used to mean running your own DBs and worrying
about their persistence and multi-host-scaling. Don't even need a reference
here since there a so many choices.

[0] [https://www.ibm.com/developerworks/cloud/library/cl-
bluemixf...](https://www.ibm.com/developerworks/cloud/library/cl-
bluemixfoundry/)

[1] [https://getexponent.com/](https://getexponent.com/)

~~~
dragonwriter
> Cloud-based apps used to mean managing VMs, keeping kernels up to date,
> setting security settings on server configs.

PaaS offerings where this kind of thing was not required were among the very
early dynamically-scaled application platforms to get the "cloud" label. IaaS
offerings where this is required and part of the price for greater control
exist, to be sure, but have never been the only cloud platforms.

~~~
webmaven
Or even the first cloud platforms.

------
indubitably
Pretty rich coming from the complainer-in-chief of JS, the guy who advises not
employing people who don't happen to agree with his personal take on how JS
should be written.

------
caseysoftware
I think the bigger problem is that we, as developers, don't appreciate risk
and how to mitigate it. We always want to play with the latest and greatest
tools, technology, approaches, etc, etc.

My advice to the teams I mentor is choose _at most_ 1-2 risky areas and
reduce/eliminate risk everywhere else.

If you have a new idea with a new team, stick with established tools. If you
have a well-gelled team with understanding of the space, experiment with tools
or approaches.

When your idea is unproven, your team is unproven, your tool is unproven, your
stack is unproven, and your approach is unproven, success is unlikely at best.

~~~
jaredsohn
>When your idea is unproven, your team is unproven, your tool is unproven,
your stack is unproven, and your approach is unproven, failure is unlikely at
best.

Should this be success is unlikely at best?

~~~
caseysoftware
Ha, thanks & corrected. :)

------
dy
One benefit often overlooked is that during high periods of churn in an
industry (let's specify JavaScript fatigue as a symptom of rapid churn in
Software Engineering for Web Applications). There are more opportunities to
quickly speed up your career. Fresh problems call for new solutions and fresh
eyes to work on those problems.

The opposite of JS Fatigue is climbing the J2EE certification ladder - if we
were all still building Struts/JSP apps then there would be no room for new
ideas to flourish. I felt very similarly about Ruby on Rails in 2004, there
was 4-6 years where someone early in their software development career to
learn a stack, find work doing that tech and manage a team (exactly what me
and several of my good friends did).

------
throwbsidbdk
I see the proliferation of JavaScript tools as a massive failure of the
vanilla js standard library and ECMA. Most of the stuff out there just
rebuilds basic language features that would be standard in other languages.

We wouldn't need node, npm, typescript, angular, react, web pack, or most of
the bazillions of libraries out there if vanilla js had reasonable defaults.

It's causing horrid fragmentations probably won't go away until js is replaced
maybe 5 years down the road.

The best we can hope for is a c++ style solution. A new language that's
basically a massive preprocessor on top of the original that fixes as much as
possible. My hope is in typescript for now

~~~
throwbsidbdk
I think node is the funniest example. "Yay we can run js on the server now!
This is the future!"

But wait, what other language can't you run on the server? I can't think of a
popular language in existence before js to take so damn long just to have a
web interface. It took js ten years! Even rust has a web server and it just
hit 1.0. Oh and node is still single threaded, something horrific for servers
that usually have 16+ cores.

~~~
icedchai
You could run Javascript on the server back in 1996.

Netscape Enterprise Server supported Javascript as a server-side language,
similar to VBScript or PHP. They called it Livewire.

------
Kequc
The problem is very accurately described as people trying to use every
framework and every library all at once. Too many developers are neglecting
their knowledge of the base language. JavaScript has become incredible in
recent years, but you'll still find new projects being built incorporating
jquery.

I have tried react redux and seriously people, after all your badgering and
all of your carrying on. I still prefer vanilla es2015+ with typescript. I can
do everything you can do sans MBs of extraneous client side code. I also have
more control.

Use your tools for what they are useful for, stick close to the metal. You'll
save yourself tons of grief.

~~~
bjacobel
React + ReactDOM + Redux is a little over 50kb minified and gzipped. I'm not
saying that's nothing, but "MBs" is a strawman.

------
wnevets
Precisely my feelings about the fake problem of JavaScript fatigue, glad to
see it finally make the front page of HN.

~~~
samtho
> fake problem of JavaScript fatigue

Can you elaborate why you called the problem fake? Not disagreeing, genuinely
curious as to why you called it that.

~~~
wnevets
Its really just an excuse for people who don't like JS to complain about JS
being popular. They honestly hate the fact that JS is one of the most popular
languages in the world right now.

You don't see a-lot of post making the frontpage of HN complaining about
programing language fatigue, car fatigue or anything else with a lot of choice
fatigue.

~~~
marcosdumay
Javascript is in the unique position where a lot of people (well, nearly
everybody) that don't like it are forced to use it.

------
dennisnedry
Agree with the author 100%. We want tons of new JS tools and frameworks out
there so we can learn and evolve newer and faster ways of developing. I still
remember when jQuery first came out and how earth-shattering that was. This
inspired so many more devs to create better and easier to use tools.

~~~
edblarney
Were JS and browsers to have been designed 'properly' (or better) with
hindsight, 'jQuery' would have never needed to come into existence.

JS evolution is perniciously different than the evolution of most other
languages.

~~~
CoryG89
In hindsight of course it's obvious. jQuery should just have been built-in
from the beginning! And all browsers should have always behaved the same and
should never break compatibility with never versions. Then jQuery would never
have needed to exist in the first place. Problem avoided.

------
throwaway23421
> gifts

fuck this dude. typical contractor that doesn't have to maintain unsupported
backbone.js based applications. just shits something out using the latest
technology then fucks off

------
rootlocus
> and every other exciting, scary, new, hipster Haskell thing that exists in
> the web dev world today.

Ha ha! A fatigued JS developer complaining about hipster Haskell things!

------
amelius
> From this point going forward, no single human being is ever going to have a
> completely full grasp of every corner of JavaScript, CSS, and Web APIs.

What does that mean for security, given that two secure systems combined can
result in an insecure system?

~~~
CalChris
In general, if I don't use something, if it's outside of my focus, that
shouldn't harm security. As an example, given your two secure systems which
can combine into an insecure system, if I don't use that second system I
should be good. If I do, I better know their interactions.

This argues for a small reliable toolset rather than having every contrivance
in the HomeDepot center aisle on my belt.

Not full stack, definitely not fool stack, just stack.

------
makecheck
In some respects the problem of “too many libraries” is the same issue we have
with news headlines, etc.: too much going on, and not enough value placed on
curating.

Right now everyone just wants to build things full-time. As an industry, it
would make a lot of sense to have expert developers who spend some non-trivial
amount of their time just on _curating_ : writing down what actually works,
what doesn’t, etc. Maybe a “stack overflow” for software packages. And after
awhile, it should become expected that you consult _those curated lists first,
every time_ before you build anything else.

------
finchisko
I wish I fully understand what people mean by javascript fatigue. I can
translate fatigue to my language, but it still doesn't make sense.

~~~
dexwiz
The fatigue comes from having to constantly keep up with JavaScript and
everything new.

5 years ago building JavaScript page was straight forward. Most of the time
you would include JQuery from a CDN, and code in a server side template. If
you were really serious, you used something like Backbone Or Ember (both very
new). But the options were limited. JavaScript was often limited to AJAX
requests, a modal or two, and some JQuery plugins. Very few people were
"JavaScript Developers." They wrote JS for their webpages and
Ruby/Python/Java/Whatever for everything else.

But NodeJS and ES5 broke open the floodgates for JavaScript Development by
elevating Javascript from something only seen in a <script> tag to a fullstack
language. With that came a surge of new libraries, frameworks, methodologies,
and opinions. It's exciting when a community grows so fast and puts out so
much. Many old Javascript patterns and styless were declare obsolete and new
ones were created.

A new framework and stack seemed to come out every month. Suddenly Javascript
needed build scripts and a pipeline. Grunt came along to solve that problem.
Which was replaced by Gulp. Which was replaced by npm scripts. And now yarn?
This rapid iteration of technologies appeared all across the Javascript
ecosystem. Backbone, Angular, React, Vue, Angular 2. Flux, MobX, Redux. But
these switches are as much a change in fashion than real improvements. But
either way, the change takes effort to learn and implement.

It turns out learning a new framework, library, pattern every 6 months is
tiring. Its fun to learn something new. But having to constantly be learning,
and at such a high rate, takes a lot of effort. That is the fatigue. The
fatigue of every time you open up HN, there is some new JS library that will
replace whatever you are using now. And if you don't switch, you are an idiot
using old technology. Or at least the community makes you feel that way.

~~~
duderific
That was a really great writeup of the issue, thanks for that.

------
amelius
I think I'm having a case of "JavaScript fatigue fatigue".

~~~
paulddraper
The next step is not far away.

------
karmajunkie
I definitely appreciate the sentiment. Its true, the JS ecosystem has exploded
and there's been a lot of shrapnel flying around for quite a while. It feels
like the smoke is starting to clear and some different groups of consensus are
starting to form about some generally reliable patterns and tools which makes
things easier.

For me, having learned web development in a time when it really was the
smallest part of what could be considered development, the tooling and
techniques are at once awesome and horrifying. :) The browser's transition
from a much more useful version of Gopher to a platform in and of itself has
created a lot of opportunities and challenges, and while JS still isn't my
favorite language by a long shot, its gratifying to see its progress.

------
vmorgulis
> I recently built an app prototype in a couple days using nothing but vanilla
> JS and the DOM. I was literally two days in before I installed a single non-
> dev dependency. Guess what? It was fine.

IMHO a good strategy to reduce the cognitive load (and limit dependencies).

~~~
nkkar
I loved this admission. There is a lot of awesome, powerful, fancy stuff out
there today, but you can get a lot done with the vanilla approach. I was
introduced to JS back when AJAX was 'blowing up', and today still prefer to
hack quick ideas w/ at most a jQuery import

------
kazinator
It's very hard to know everything. I made a programming language and I'd be
screwed without the manual to refer to. Recently I was utterly surprised by
something that was implemented ("you can do that?").

What was it ... aha, I remember: introspection over exception handling sites.
The ability to just get a list of the frames through an API, and then directly
pick one and jump to it (regardless of whether it catches the type of
exception being passed to it that way).

------
strictnein
> "From this point going forward, no single human being is ever going to have
> a completely full grasp of every corner of JavaScript, CSS, and Web APIs"

This. Reading the comments at HN and other places gives you the impression
that there are people who do know everything, but that's not the case. There's
just lots of technical people here who are experts in various fields, so
there's always experts to comment on things.

------
vldr
I picked EmberJS because of javascript fatigue - it makes most choices for me
and gives me some guarantee that it will work together.

But even that fails in practice: sourcemaps don't work properly so you don't
get to debug your original ES6 code and more issues like that. Meanwhile
there's no clear focus on where the framework is really going (routable
components? working pods in ember-cli?, etc)

------
somecallitblues
Could some of this fatigue be due to to JS being so damn hard to troubleshoot?
I'm still struggling with troubleshooting JS after years of using it on and
off. I still console log everything and keep refreshing the page. Is there a
more sane way of doing it?

------
MrBra
This article seems to me a self reassuring post written by the author after he
suffered himself the JS fatigue.

------
curried_haskell
Haskell programmers are hipsters now?

~~~
Finnucane
Well, they're the ones juggling while riding backwards on a unicycle.

------
edblarney
JS fatigue is not a fake problem, it's real and different from other forms of
fatigue.

The metaphor used in the article i.e. 'learning another language every 6
months' is not apt - because those are not 'new languages' and they are not
'new and critical parts of the landscape' for any specific vertical.

If any one of those languages were to have the same degree of evolution as JS
... then 'fatigue' would also be an issue.

JS has a pernicious problem for a few reasons:

1) The language is quirky, fragmented, there are still no 'agreed upon'
approaches to do many things even outside the context of libraries. There are
really no analogues to 'prototype' based languages, which possibly makes it
great for some things, but it's not great for those wanting to use more
classical ways of thinking about information organization.

2) Runtimes, particularly browser - are highly fragmented, and there's scant
documentation. Safari docs for Mac/iOS are literally empty in some spots.

3) JS doesn't come with a lot of things 'baked in' to the language that most
others support, so discovering those 'standard libs' has been a painful
process.

4) Due to the limitations of the browser, we see a lot of churn in frameworks.

Though there is some advantage to 'community participation' \- the pernicious
problem is _most of the churn is not fully forward_. It's 3 steps forward, 2
steps back, and a step sideways.

There's a lot of time and investment in learning something new that won't
exist in the future - that's costly.

Learning Lambda's for Java 8 is probably worth investing in for Java
programmers ... because Java 9 will surely use them as well.

Taken as a whole - there is an enormous amount of inherent 'reducible
complexity' in the JS ecosystem, which any JS developer intuitively senses.

If someone were to have made up their mind about JS right from the start, and
had come up with some good standard libs ... and the evolution of the language
were to have been more 'version' and less 'pick and chose' (Es6 means
something different in each environment) ... then the complaint would be
valid.

It is what it is ... but JS fatigue is a real thing.

~~~
z3t4
one reason why JS is so popular is because there are no standard lib. There
would be no nodejs etc.

~~~
cocktailpeanuts
node.js was built from scratch, in C, to resemble javascript syntax
intentionally.

~~~
bobbytherobot
What? The engine is written in C, but all JavaScript engines are written in
another language (C being the most popular) because it is an interpreted
language. The engine isn't written from scratch because it is the V8 engine
from Google. Of course the system binding and package system is written
specifically for Node.

~~~
paulddraper
C++, actually.

------
draw_down
You can't learn every library or every tool but you can learn how the language
actually works. For example, if you think JS has floats and integers, you have
some reading to do. If you think "array" is a type, take heart, because you
can learn why that's not correct. If you can't decide whether to use Ember or
Angular, maybe you can grasp how closures work.

Before React and Redux and Gulp and whatever else, understand how the language
works. Pretty please.

