
JavaScript Fatigue Fatigue - fagnerbrack
https://medium.freecodecamp.com/javascript-fatigue-fatigue-66ffb619f6ce
======
carsongross
I very much like Quincy, but I can't agree with this article.

 _“The Universe is under no obligation to make sense to you.”_

The universe may be under no obligation to make sense to us, but our tools
are.

The fact is that the vast majority of the complexity currently be introduced
into web development is unnecessary for the vast majority of web applications.
I built a tool to make it possible to implement most modern web UX patterns[1]
with almost no javascript code whatsoever, and to be adopted as much or as
little as necessary for a given project. It is possible to make modern web
development simple (or at least as simple as it was in 2004[2]) if you make
that a goal.

Javascript fatigue is real. Lots of smart people are simply abandoning front
end development altogether. The Javascript community needs to face up to this
fact with an open mind and not dismiss what a significant number of people are
experiencing.

[1] -
[http://intercoolerjs.org/examples/index.html](http://intercoolerjs.org/examples/index.html)

[2] - [http://intercoolerjs.org/2016/05/19/back-to-the-
future.html](http://intercoolerjs.org/2016/05/19/back-to-the-future.html)

~~~
ng12
There's complexity of tooling, and complexity of code. I'll take simple code
over simple tools any day. The package.json in my SPA is bloated but the
majority of the code is pretty simple and the bits that aren't are well-
encapsulated.

Back when I was using just jQuery and maybe Backbone or KO the tooling was
simple but an incredible amount of rigor was required to keep the code
maintainable. A big part of my job right now is providing a dev environment
where people don't get fatigued -- most of the tech decisions I make are
geared towards ease-of-use by backend devs. Sure, the toolchain is relatively
complex, but it's a fundamental part of why I'm able to do that.

~~~
cocktailpeanuts
I think there's a conflict of interest when a guy whose job is to adopt these
frameworks says they're good, don't you think?

Not saying you're wrong. I'm not even saying what you're doing doesn't matter.
In theory it should work as you described. But I'm saying in reality you may
be too into what you're doing that you don't realize what others think.

I've had a few people who were in your position in my past job, and they
seemed to believe what they are doing is indeed better for the team (and so
did the managers, that's why they were working on it in the first place!), but
from an actual "user" point of view, they didn't help at all but made me a
very dissatisfied developer. The thing is most people don't officially
complain about it because they don't want to be seen as a loser who "can't
move fast enough".

But here's what REALLY happens while you're thinking everyone's benefitting
from your work:

As a developer, less code WITHOUT knowing what's going on underneath is the
worst feeling ever. That's one of the biggest criticisms on rails. But that's
a different story since rails actually provides huge benefit as a result (and
people know that it isn't going anywhere so it's worth learning)

When we come to JS land, there's no clear "10X" benefit to adopting these
technologies. Sure there are incremental benefits but they don't justify
learning every new packaging tool / framework every couple of months. I shit
you not, a lot of companies have gone from grunt to gulp to webpack (and who
knows what's next) just because they're the cool new tool that's "better" than
the other. Some may say I'm lying just to exaggerate, but I am not. They do
this because they want to "attract new developers who are looking to work with
latest technology".

But in my opinion that's the stupidest thing a product building company should
do. You're better off attracting great developers by building a product that's
so compelling that developers want to contribute no matter what the stack is.
I'm sure Snapchat had no problem attracting top talent in LA when all they had
was a shitty mobile app that they didn't even bother making pretty.

Lastly in most cases, only a few people on the team are responsible for taking
on these framework migrations. Which means the rest of the developers just
become "users" and are left feeling like some passive idiots who just follow
the "early adopters". As a result the developers fall into two categories: 1.
People who don't want to feel left out and pretend they like the tool and keep
following (and this feeling of "following" feels really shitty if you are not
a "follower" kind of person); 2. People who complain how these "upgrades" are
totally unnecessary and as a result treated like "old school" by the people of
group 1.

Step back and think about how much efficient web development has become for
90% of developers (Not for you, who already are on board and an expert in
adopting one new edge tool every month). To be clear, I know how to use all
these tools (grunt, gulp, webpack, etc.) but whenever I need to build a quick
prototype I just use plain old html/css/jquery. You could say you could use
things like Yeoman to set up things quickly, but that's not the point.

~~~
ng12
> I think there's a conflict of interest when a guy whose job is to adopt
> these frameworks says they're good, don't you think?

Not at all. The reason I accepted that gig was because the team previously had
a complex SPA written with what the above poster would consider simple tools
-- and they were extremely unhappy with it. It took too long to add features,
to modify things, to grok the control flow, to hunt down bugs. And that's not
to say the app was poor quality: for the tools used everything was fairly
idiomatic and organized. They hired me because they thought things could be
better, and I thought they could too.

> As a developer, less code WITHOUT knowing what's going on underneath is the
> worst feeling ever.

Do you write all your code in assembly? The whole reason we use tools is
because we don't want to think about what's going on underneath. React/Redux
are simple by design and both incredibly easy to reason about. Webpack is a
little more complicated by nature (most build tools are) but even then the
core API is very simple -- just define a chain of compilation tools to process
files of a given type.

> in adopting one new edge tool every month

I'm not sure where you get this impression from. The last major change to my
standard stack was Flux -> Redux, and that was almost a year ago (and a
relatively simple migration). Apparently you enjoy being crumdugeonly, but
please have some faith that some of the web development community know what
they're doing and care very deeply about the same things you do -- namely,
crafting maintainable software.

> I need to build a quick prototype I just use plain old html/css/jquery

Sure! Pick the right tools for the job. Those are the right tools for a demo,
the wrong tools for a long-lived SPA which needs to be maintained/extended by
a team of engineers.

~~~
Falkon1313
It's actually a lot easier to maintain and extend something over a long
lifespan if it _doesn 't_ have tons of dependencies from many different
sources evolving in different directions at different velocities.

In a long-lived application, early team members will need to learn the new
tech and later team members will need training in the old ways to work on your
now-archaic tech stack (that you couldn't upgrade because of version
incompatibilities). They'll also need custom-built dev systems that come with
the project (because some of the tools are no longer available in those
versions or at all). You won't be able to use new tools without first
backporting them. You may have to deal with potential security issues in code
that is no longer supported even though you don't even need that code, because
it's there in the dependencies.

In fact, in some cases the use of lots of dependencies might actually be
better for quick prototyping (because they let you do so much with so little
development) that you don't have to maintain and extend than for long-term
projects. It's a tradeoff. Either way has benefits and drawbacks.

------
combatentropy
From the article:

    
    
      > the reason why JavaScript development is so complicated:
      > web development itself is inherently complicated.
    

It's really sad to me that the writer cites necessity as the reason for
complexity.

    
    
      > We are trying to build applications that run right in a dozen browsers
    

I remember cross-browser CSS and JavaScript from 2005 as infinitessimally
shorter, and that was when we had to contend with IE 6. All of the other
browsers back then behaved fairly uniformly. Now, IE 11 is almost
indistinguishable from the rest.

    
    
      > look good on thousands of different devices
    

There are really just two devices: big screen, little screen. To think you're
targeting "thousands of different devices," you must be counting every make
and model as a "different device" (and even then, it's more like dozens). Tell
me, how does targeting the Samsung Galaxy S3 and the iPhone 6 require a bunch
of JavaScript dependencies?

    
    
      > load fast enough for impatient commuters in the subway
    

This is an art we have lost. The web used to ride on 28.8 kbps.

    
    
      > and are still accessible enough that blind people can use them.
    

That also has been a solved problem for well over a decade.

    
    
      > The Cambrian explosion of tools you see around you
      > is what rapid progress looks like when it’s not
      > controlled by an Apple or a Microsoft.
    

The web was never controlled by Apple. At one time it was dominated by
Microsoft, but even then I could write cross-browser JavaScript without really
thinking about it, with jQuery (2006).

    
    
      > At the same time, web developers are closing security
      > vulnerabilities all over the place.
    

What other security hole is there for web devs to handle besides cross-site
scripting, and how does any security hardening lead to magnitudinous
JavaScript dependencies?

    
    
      > If this evolutionary process frustrates you [...]
    

Is this evolution or entropy?

~~~
ben_jones
> what other security vulnerabilities for Web devs to handle besides csrf

Not defending the article but the more intertwined the client and server code
becomes, as well as server side development in nodejs etc , the more security
vulns javascript developers will be exposed to.

In addition nodejs has become arguably THE introductory web development
language and as such offloads many complex but necessary tasks to its third
party libraries in order for beginners to develop efficiently. This means
security features ranging from CSRF to ORMS to CORS etc are taken out of the
domain of developers and into that of typically un vetted third party
libraries, becoming a vulnerability in and of itself.

~~~
extrapickles
The advantage of CSRF/CORS/etc being taken care of by third party libraries is
that it will be actually handled (even if its very basic) in sites created by
beginners, which is better than not having it at all.

------
moron4hire
Here are some things to keep in mind:

HTML5 is responsive and semantic by default. If you work with it rather than
against it, you'll have incredibly rich documents that support users very well
on a wide variety of different devices _at no additional effort on your
behalf_.

If you stick to only enough CSS3 as to actually _style_ HTML5, not _redefine_
it, then CSS is extremely easy to maintain, too.

ES5 is implemented in all major browsers and its simple parts are very simple
to learn. OOP and FP vie for the hearts and minds of developers with
terrifying sparks and flames, but we've built entire empires off of procedural
programming. Your choice of programming paradigm will likely have zero impact
on your project's success.

All of the difficulty we have is when we try to buck these strengths. You
don't need a task runner if you aren't running tasks to translate Haml and
SCSS and CoffeeScript to HTML5 and CSS3 and ES5.

I'm not saying there isn't value in doing those things. I have my own
convoluted process that I am constantly tweaking. But they are by far not the
default. If you want to say that Web development is inherently complicated,
you must talk about what is at its core. And the core of HTML5/CSS3/ES5 is not
complicated. You can write it with a plain text editor. You can load it in any
browser. You can serve it from any web server in their _default_ settings. We
fundamentally _choose_ to complicate these things.

~~~
combatentropy
Kind of reminds me of Jujutsu. I was about to recommend we all start a new
framework, jujutsu.js, whose total file size is 0 bytes, but then I remembered
that, of course, it has been done before: [http://vanilla-
js.com/](http://vanilla-js.com/)

------
romaniv
_> "web development itself is inherently complicated"_

The functionality of 99% of all websites I see these days can be replicated
with simple DB calls, string concatenation and a handful of straightforward
progressive enhancement libraries on the client side. Some developers simply
_choose_ complexity.

The fundamentally complex aspects of web development aren't solved by the
stuff people are fatigued by anyway.

~~~
ng12
I think there's a divide here -- "websites" you and I and the rest of HN
visit, and "web applications" which are non-trivial interfaces to complex
data. If you're using Webpack, React, Redux, Typescript and NPM to render
basically static content you're doing it wrong.

~~~
sotojuan
> If you're using Webpack, React, Redux, Typescript and NPM to render
> basically static content you're doing it wrong.

Yet this is what everyone does and what romaniv means. We have good tools for
applications that people use for static content.

Here's my reasoning: As someone looking for a Web Dev job, your static site
built with Handlebars or server-rendered HTML won't impress anyone. Build it
with React/Redux/Immutable and suddenly you get more interviews or at least
more hits. This has happened to me.

Therefore, when those people finally get employed they'll just keep building
with the tools that got them the job and never think if they really need them.
If you switched a complex React app to a server-rendered Node/Rails/Django
one, how much more less work would you have to do?

~~~
ng12
I think "javascript fatigue" is just a bad term. It's like sayings I have
"hammer fatigue" because I've been whacking at screws all day.

------
ggregoire
My thoughts about JavaScript and the libraries/frameworks/tools depreciation:
[https://gist.github.com/ggregoire/f41ae88bb8e192ad70be690f19...](https://gist.github.com/ggregoire/f41ae88bb8e192ad70be690f19851a33)

TL;DR: We have mostly used the same tools for years. People feel that React or
Webpack are the new hype tools for cool kids, but React is there since 2013
and Webpack since 2012. A lot of companies still use Angular 1 (released in
2010, almost 7 years ago).

~~~
tonyedgecombe
"almost 7 years ago"

I'm working on software that was started in 1999, this isn't unusual.

------
iandanforth
"web development itself is inherently complicated."

The best teachers I've ever had took things that many people label as
"inherently complicated" and made them clear and simple. More often than not
complexity arises from insufficient depth of understanding not from something
intrinsic to the subject matter.

"these new tools are very much a good thing. ... They will make you a happier
... developer."

I object strongly to being told what will make me happy. The current tool set
does not (other than React). I am glad they make _someone_ happy.

------
aikah
Javascript and its ecosystem are now more complicated than java's ... without
type safety. The problem is the language wasn't designed with all this in
mind. Not even talking about the bare bone nodejs std lib which makes any task
a chore since most third party modules are not maintained past their first
year of existence. What a mess.

~~~
gerbilly
And npm could learn a _lot_ from maven.

~~~
jessaustin
npm could be faster. What else could npm learn from maven?

~~~
ryanbrunner
I'm not familiar with Maven, but comparing to other package managers
(primarily bundler)

\- A sane approach to locking that's built in and impossible to forget.

\- Deterministic installs.

\- Basically enough stability that "delete your node_modules and npm install"
is _never_ a necessary solution to anything (I've had tons of instances where
I've had to do this with npm).

------
brianvan5155
So, in essence, just suck it up.

The funny thing is that JavaScript development isn't a goal. It's never the
goal. Complex toolsets sometimes assist in the achievement of goals... but you
can't say "JavaScript overload is totally the right thing" when you aren't
talking about the goals that need to be met. Simply having a philosophy that
developers should learn new things all the time to stay current... that's not
a good argument to support the current tooling.

I'm glad there's a lot of people working on open source projects. I wish
they'd publish more documentation about use cases and UNIFIED (not piecemeal)
deployment configurations, though. After all, your toolset has valid and
relevant use cases... right?!?!

------
scotty79
I don't mind JS and all of the ecosystem. I like the openness unseen anywhere
else and dynamic growth and dropping stuff when better stuff gets created.

But as I'm trying to control page transitions in SPA using react-rotuer v4 I
have a feeling that I basically re-implement subset of a browser ... poorly.

------
Grue3
>We are trying to build applications that run right in a dozen browsers, look
good on thousands of different devices, load fast enough for impatient
commuters in the subway, and are still accessible enough that blind people can
use them.

Then why do they not do that? Every "modern" web application loads slow as
hell, works decently only in Google Chrome, ruins the functionality of the
back button, and eats 100% of your CPU. I've seen blogs, _blogs_ , that do
this sort of stuff.

~~~
dwaltrip
Every web application does all of those terrible things? Your hyperbole is a
bit extreme.

Even if it is a very high percentage, say 90%, we are still left with millions
of high quality applications. You may have to do some work to find them, but
it's no apocalypse.

Whenever participation in some dynamic becomes immensely widespread (in this
case, building web apps) the average quality of each instance always drops.
This is a well understood phenomenon that is not unique to web applications.

------
Hates_
As someone who has only ever done web development how true is the statement
"web development itself is inherently complicated" when compared to other
fields of programming? After seeing the Jonathan Blow talk on software quality
I really questioned how much I over-estimated the complexity of what I do
every day.

~~~
gadrev
Could you provide the full title or a link to that particular talk of Jonathan
Blow?

~~~
sgift
[https://www.youtube.com/watch?v=k56wra39lwA](https://www.youtube.com/watch?v=k56wra39lwA)
Probably this one.

------
tangue
The problem is not javascript or people complaining about javascript, the
problem is fetichism of an inefficient toolchain. When I read that "“Over
400ms is being spent simply walking the Browserify tree.” on a site like
Tumblr...

[0][https://docs.google.com/document/d/1E2w0UQ4RhId5cMYsDcdcNwsg...](https://docs.google.com/document/d/1E2w0UQ4RhId5cMYsDcdcNwsgL0gP_S6SDv27yi1mCEY/edit)

------
seangrogg
While I agree with parts of this article, the fact of the matter is that in
the majority of cases "JavaScript fatigue" is self-inflicted.

Chances are most of your users don't care about you using ES6 or TypeScript.
They're not checking to see if your code is minified, uglified, bundled, code-
split, or whatever. What matters to most users is _their_ experience, not
yours.

So if you're using Webpack and Babel and TypeScript and Gulp... you _opted in_
to that complexity. If you feel like you need 18 tools to develop your apps
that's on you, not JavaScript.

------
nihonium
I've really liked this post. I've totally agree with it. We should feel lucky
to have such tools. I'm tired of hearing how awful is javascript ecosystem.
How about comparing Front End vs Back End technologies? You have Javascript,
and it's supersets for Front End, you have 100s of different languages for
Back End development. One might say Back End sucks because it is very
different across different languages and companies.

~~~
BoorishBears
If you want to consider every facet of backend instead of the few main ones
that show up when you want to solve a problem X in language Y then why claim
frontend is just Js?

By your reasoning for backend, frontend sucks because I could probably find
Open GL wrappers for every language used on the backend and make a front end.

Backend really is relatively simple because usually language X has a few
really good libraries/frameworks you can pick up. Js is Node.Js. Python is
Django or Flask depending on what you want to do, Elixir is usually Phoenix,
etc.

------
rbanffy
> We are trying to build applications that run right in a dozen browsers, look
> good on thousands of different devices, load fast enough for impatient
> commuters in the subway, and are still accessible enough that blind people
> can use them.

Wow! That sounds cool! When do we start doing that?

Now, seriously, the complexity of the problem is enough you don't need to pile
up more complicated tools on top of them that become, too, problems to be
solved. We have tools to manage micro-dependencies we create because we have
the tools to manage them. Then we invented tools to bundle micro-dependencies
because we didn't want the browser to request 300 separate functions in 300
separate http requests and soon we'll unbundle them and let the browser
request them because the individual request itself becomes cheap enough...

I get we are talking about "web applications" that have routes, don't re-
render pages and don't hit the server for full pages. If this reminds you of
what we were doing with Visual Basic in the early 90's minus using HTTP to get
JSON data from a server, it's because this is a solved problem. What it feels
like is that we are trying to re-do it with the wrong abstractions.

------
sickbeard
I think the author is mixing up complicated tasks and confusing tools

------
SadWebDeveloper
The problem is not the tooling, the browsers or JS itself, the problem is that
JS developers are trying to put themselves EVERYWHERE THEY CAN in attempt to
pursue the now infamous "full-stack engineer" motto.

------
tashoecraft
Why don't people understand that this is our way of unionizing. If you buy
into the rapid change landscape, convincing your company to change every few
years, then you've locked your job in.

------
clifanatic
The first comic I think is supposed to make me feel sorry for the poor saps
who have to test against a dozen different Android phones but I couldn't help
but think what a luxury it would be to work for an employer who actually
provided physical hardware to test against. I've been developing software for
25 years and have yet to encounter this.

------
carapace
No, this is stupid.

Show me the "business value" proposition for NOT using Elm ([http://elm-
lang.org/](http://elm-lang.org/)) over the expletive-deleted soup of modern JS
web "app" development or shut up.

We have become complexity junkies and this article is _a junkie rationalizing
the habit._

------
z3t4
Meanwhile we argue that switch statements are too complexed and should be
avoided.

------
z3t4
The user dont care what tools u use. Dont forget who you are designing for!

------
xwowsersx
tl;dr "JS is getting more complicated. Other things are really complicated
too. Take it from me: this is a good thing."

