
JavaScript Fatigue - bluejellybean
https://medium.com/@ericclemmons/javascript-fatigue-48d4011b6fc4#.m0c2f9fe5
======
BinaryIdiot
I certainly can appreciate most of this post. I've used so many different
frontend (angular, polymer, ExtJS) and backend (express, hapi, restify)
frameworks and the various common building tools (grunt, gulp) that it's
almost impossible to become great at all of them and for a new comer who maybe
only used one or two of those frameworks it can be painful getting started.

I've started using less and less frameworks as I work on harder and more
complex projects. Sometimes I worry I'm toeing the line at becoming the "old
kook who hates new frameworks" but I like things to be explicit and simple;
for example if I can write a plain script to handle my build process without
integrating grunt or gulp I'm certainly going to do that.

> Leverage folder & file-naming conventions for automatically discovering
> application-specific routes, actions, tests, and more.

Not a fan of this. This is implicit behavior which is almost never intuitive
until you're experienced in the tooling that has it. I'd much rather be a tiny
bit explicit where there is a list somewhere and I edit that list with
patterns or explicit file names. There is no reason there should be
"discovery" of such things at _development time_.

~~~
isoos
Similar to this note: I've done my fair share of using dependency injection
frameworks in the Java backend world (e.g. Spring), just to develop a healthy
dislike for every DI out there. The magic is nice and good, until it becomes a
burden, and a constant question of where certain objects are coming from. It
was a pain to see the same design pattern to emerge in the (compiled-to-)JS
world, with all of the same problems and complexities.

I wonder if any _good_ pattern had similar lifecycle, winning the minds and
then spreading to different domains.

To be fair: I do think DI has value, but I started to prefer explicit over
implicit, and most DI stuff is focusing on implicit and magic.

~~~
on_and_off
have you tried dagger 2 ? I think it makes a good job at dispelling the magic
as much as possible.

------
darylteo
Today I started a rebuild of my website as a technical exercise.

1 working day in, and I haven't written a single line of actual html.

Do a search for "require" on npm. There are 90,000 npm packages. There's
"require-dir", and "require-directory" then "require-all". Some are shims for
require on the frontend, rather than for the backend.

Every other build tool has its own ecosystem of tools that shim around an
existing tool. And then webpack's packages notoriously pollute the package
global namespace ( _-loader, and slightly better_ -webpack-plugin).

Main problem is both the blessing and the curse of Javascript (and slightly
mirrors the ongoing popularity of PHP) - there're so many resources available
that it's so damn easy to get in. And it's so tempting to build YAJF/J, and
even more so nowadays. And as the author mentions - there's very little
community curation.

For someone who doesn't sit in the frontend stack everyday, it's quite frankly
madness. It's like playing chess with a hydra. The author has problems with
the React startup cost - I think it's a problem plaguing the entire js stack.

~~~
chubot
If you're not a front end developer, then why is it a technical exercise to
learn all this stuff? Personally, I don't want to learn things that will be
obsolete in a few years.

I also rebuilt my website as a technical exercise, but I'm doing it in raw
HTML, CSS, and JS. Literally with vim and shell scripts to build it.

I know it can meet the requirements of a personal website, and many other
kinds of sites. It probably takes a little longer, but I know it's going to
work in 5 years, and I will know how to maintain it.

And I will have more foundational knowledge. Things have changed a lot with
HTML and CSS. I learned how to use HTML5 onHashChange. And I did my own "CSS
reset" without using any libraries. I wrote my own table sorter with raw DOM
manipulation.

I think you need this knowledge to help you use the framework correctly
anyway.

~~~
enraged_camel
>>If you're not a front end developer, then why is it a technical exercise to
learn all this stuff?

There are many reasons. For one thing, a lot of developers are "full-stack"
and don't have the luxury of focusing on just the front-end or the back-end.
For another, learning new tools, frameworks and methodologies will make you a
better overall developer.

>>Personally, I don't want to learn things that will be obsolete in a few
years.

Better not work in web development then. It's probably the fastest moving
subfield in software and there's no guarantee that what you're learning today
won't be obsolete in a few years. So your best bet is to learn as much as you
can, rather than putting all your eggs in one basket that you think will last
a long time.

~~~
chubot
Yeah, professional web dev is not for me, though it seems I'm not the only one
lamenting the state of affairs. It seems that it's not just the frameworks
that are thrown away in 3 years, but sometimes the products built with them
too!

I think learning new "frameworks and methodologies" only makes you a better
developer to the degree that they are well thought-out. It seems like a lot of
JavaScript stuff is basically still in a state of flux, where people are
experimenting and figuring things out.

I spent a lot of time learning Python, C++, C, R, bash, OCaml, and
HTML/CSS/JavaScript. All those things have lasting value, and I expect to be
using them in 5 years, and probably most of them in 20 years.

I would say jQuery has lasting value, since it has an elegant data-driven /
document-driven model. I look a new things to understand if they have lasting
value. React does seem principled to me, and I was interested in playing with
it, although these threads have what dampened the enthusiasm.

I am using HTML/CSS/JS to display statistics and visualizations, and it works
perfectly for that. In any case, I do think there is a problem where a lot of
front end devs don't actually understand the abstractions the browser
presents. It's basically the same problem as Python or Ruby programmers not
understanding what syscalls are and writing horrifically slow code.

------
CloudYeller
It's scary that if you don't jump on _some_ kind of framework bandwagon,
you'll be half as productive as framework devotees within 4-5 years.

When I joined my current team in 2015, they were still using Python Paste and
jQuery for everything, while I was well-versed in Angular + a modern Python
server framework. Armed with my modern libraries, I could do more in 1 day
than an average teammate could in a week. In other words, my team lost a
_staggering_ amount of productivity over the past 2-3 years, just because they
were hanging onto old ways that were still legit even in like 2011. And it's
obvious that the half-life of frameworks is only decreasing over time.

What will happen when an average framework's half life is 1 year? Or 6 months?
Humans aren't built to adapt so much, so quickly. I can gain proficiency with
a new library in 3-4 months, but what happens when I get tired of doing that?
Will I just fade into the background as some high school kid outproduces me
5:1 simply because he was lucky enough to learn FrameWorkABC a couple months
ago while I was busy with a personal issue?

Hopefully by that time, the singularity will be so close at hand that we'll
have bigger fish to fry, like basic income, or something.

~~~
chubot
Honest question: what kinds of things are you doing with React/Angular that
you can't do with jQuery? (I'm not a front end developer -- though I do write
significant amounts of raw HTML, CSS, and JavaScript).

Is it really higher productivity, or is it just keeping up with the latest
fashion?

I feel like the vast majority of websites don't need more than a little
JavaScript -- exceptions being Google Maps, Google Docs and spreadsheets, etc.

AirBNB is listed here -- honest question: do they really need a lot of JS? I
mean mainly it's showing a lot of pictures and providing good navigation and
search. Am I missing something? It's basically like eBay in 2000 except
prettier, and that was done without a lot of JS.

[https://github.com/facebook/react/wiki/Sites-Using-
React](https://github.com/facebook/react/wiki/Sites-Using-React)

Asana might be a good candidate for a real "app" that needs the complexity.

Why is Wired on there? I think news sites are the worst offenders in terms of
using unneeded JavaScript.

~~~
enraged_camel
>>Honest question: what kinds of things are you doing with React/Angular that
you can't do with jQuery? [...] Is it really higher productivity, or is it
just keeping up with the latest fashion?

Answer to the first question: nothing. Everything you develop using
React/Angular/etc. can be written using vanilla HTML/CSS/JS.

The difference is that, as your pages become more and more interactive, it
becomes harder and harder to deal with the complexity. I recently developed a
web form that has a little over 1,000 lines of JQuery. After a while, it
became really difficult to keep track of various event handlers, when they
would fire and how to make sure they didn't interfere with each other. If I
were using a framework like React, it would have been much easier. Here's a
diagram that outlines this concept:
[http://imgur.com/dSQTLDE](http://imgur.com/dSQTLDE)

>>I feel like the vast majority of websites don't need more than a little
JavaScript

Web _sites_ don't. Web _apps_ do. The distinction becomes bigger and more
important every day.

~~~
chubot
I just have a hard time understanding where all these web _apps_ are coming
from, and what the real requirement is. It seems to me that the ratio of
problems that require web apps to web sites is more like 1:1000 than 1:10. In
other words, I wonder why it seems _everyone_ is using React or Angular,
rather than just a few people.

I mentioned Google maps, docs, and spreadsheets as bona fide apps. They
require a completely different approach. They are extraordinarily stateful on
the client.

What other sites need that? As mentioned, I don't think AirBNB does. How much
state does it need on a page? It's basically like a shopping cart, like eBay.
You search for properties, and then you book one. (Maybe it is different for
listers, I haven't listed).

I get that you need more advanced stuff like React and Angular to manage a lot
of state on the client. jQuery gets messy in that case. But I am wondering why
apps all of the sudden need this much state. If you break up your app into
different pages, then you don't need so much state on each page. The state is
in the URI.

In other words, I see a lot of it as self-inflicted pain... the customer
didn't actually want all this stuff. They just want to order a meal online or
something. I looked through that whole "Built with React" github page, and I
am still trying to understand where the requirements for lots of state are.

I don't buy the motivation of keeping everything on one page to save network
latency... if you actually profile a lot of web pages nowadays, the rendering
time is greater than network time! I'm seeing _full seconds_ reported by
Chrome dev tools just to render!!! It doesn't appear that anyone cares about
latency, given how slow most web sites and apps are.

~~~
enraged_camel
It's not about latency, but about overall performance. Rendering on the server
is slower than rendering on the client, because the server may have to deal
with a thousand requests per minute whereas the client doesn't. So you push
the logic to the client and let the browser deal with it until talking to the
server is actually necessary (e.g. when the time comes to submit the data).
Therefore client-side frameworks become a kind of distributed processing of
application logic.

Furthermore, you shouldn't take latency for granted. Many users are on choppy
mobile connections. Waiting for the server after every action results in a
really bad user experience in those scenarios.

~~~
chubot
I'm not really buying it... Rendering on the server seems like a solved
problem to me. Web apps scale.

Sure, you can save servers by offloading work on the client. But I think your
server cost is absolutely dwarfed by developer salaries. I guess it depends on
whether you have more front end people or back end people. Good front end
people seem to be just as expensive and rare as good
backend/C++/Unix/distributed systems people these days.

On mobile, most web apps are a disaster. They are certainly a lot worse than
light HTML. Never mind waiting for the server on every action -- try getting
the app to load in the first place! The Android and Chrome team have numbers
on the astronomical rate of user-aborted or otherwise failed page loads on
mobile. On mobile, users see the white screen for 5-10 seconds (probably
waiting for your 10-50 round trips for your JS, CSS, heavy image assets, and
especially third party JS) and then give up.

~~~
frik
You are so right!

I hand tuned web apps (vanilla JS5, no libs/frameworks) and opimized them for
mobile, and they are very fast.

But most don't care and use bloated JS libraries/frameworks and the end user
has to wait several seconds until the 1MB JS file loads over a cell connection
or even crash the mobile browser because the site owner thought it is okay to
integrate 30 advertisement and analytics third party JS files.

------
jondubois
I have used many frontend frameworks (Backbone, Knockout, Angular, CanJS,
React, Polymer). I find React to be overly complex/bloated. It sucks you into
a whole new universe which probably shouldn't exist in the first place.

At first, you think that React will take the complexity out of building apps.
Soon enough you realize that React on its own isn't enough; you have to follow
particular programming patterns like Flux or Redux (which adds more
constraints/complexity).

Then, with all the complex data rendering happening behind the scenes
(diffing), you start to realize that REST is no longer a suitable medium for
transferring data over the wire so now you have to use GraphQL/Relay.

Personally, I much prefer the approach which Google has taken with the Polymer
'framework' \- You can setup models (WebComponents) to hold simple, atomic
values and you can wire them all up on the frontend (no diffing necessary) -
You get all the live binding awesomeness without the insane complexity.

For example, with Polymer, you can setup a dynamic collection of item IDs and
then use those IDs to load the individual properties of each item - You can
hook everything up to update in realtime (both the collection and the bound
properties for each item).

The Polymer approach is simple and efficient - Also, once the WebComponents
standard has been implemented in all major browsers, you will be able to run
that code without any special libraries or frameworks.

~~~
k__
Well, I think in comparison to Polymer, Angular and Ember it has a really tiny
API and easy to grasp concepts. Yes Polymer uses components too, but I found
it a bit clunky in the past (used it ~2 years ago).

But yes, stuff like Flux isn't really easy. I use Redux and it took me much
more time to grasp than Ember-Data or something.

------
kenOfYugen
React has shifted the questions asked by newbies, from which framework to
choose, to what tooling to choose to complete the framework. Essentially it's
a framework in library disguise.

It's used more as a simplifying term for a family of related technologies,
rather than React the library itself.

For experienced coders this doesn't matter too much. More toys to play with.
Newbies seem to be having a hard time picking up all those buzz-word ridden
notions of the available tooling.

Not everyone can have a deep computer programming background, so they have to
be confused and then get it wrong, in order to learn.

It's not React's fault, it can't solve everything. It is what it is, the
problem is irrational people, trying to make a front-end messiah out of it.

~~~
eloisant
The difference is that with a framework, moving to something different
(sometimes even upgrading the framework) for a big project is extremely
painful.

With libraries, and pretty your own framework custom build for that project,
you can upgrade components one after the other and move without breaking
everything.

------
andrewingram
I think the last few years, 2015 in particular, have been about finding the
right patterns to enable development of robust and performant JavaScript apps.
It's feeling more and more like most of the gaps have been filled in, with
just a few things remaining.

Remember, before frameworks like Django and Rails came along, state-of-the-art
backend web development was pretty horrendous. We're still in the wild west
stage for front-end, which is arguably a much more hostile development
environment. It doesn't really matter if your backend toolkit is 100mb, on the
front-end it absolutely does. The backend doesn't also have to deal with new
browser releases having bugs that spontaneously break your website.

But I think we're honing in on the right patterns, it's felt to me that whilst
there's been a lot of churn in which individual libraries we should be using,
there's increasing stability in the approach they take. I'm hoping that in a
little more time, the Django's and Rails' of the front-end will start to
appear.

------
luiscarli
I see the multiplicity of tools and libraries as a result to the fact that we
have not yet arrived at a good stable solution for the unique problems that
interactive front-end applications have today.

If we had good and stable solutions, new libraries and tools would have a very
difficult time to get traction, just for the sake of being new and doing
things different.

The javascript stack today is a reflection of the complexity of the problems
it needs to deal with.

We can still use jquery and write code directly on script tags of html page,
zero tooling problem and complication. Most front-end developers don't do that
anymore because it does not solve the problems for developing complex web
applications.

A clear winner may one day arise and dominate and simplify the stack, but it's
also a possibility that the complexity and multiplicity of the problems the
front-end deals with don't sustain one clear winner.

------
raquo
I don't get the point of this article.

It posits the usage of small independent tools as a problem, and then provides
solutions to the problem that are not much more than prepackaged combinations
of these tools and therefore were made possible entirely by these tools being
small and independent. But these tools are apparently also bad because you
need to think to use them, and write config files to tell them what you want
from them.

This doesn't make any sense. The ecosystem is working as it's supposed to be
working.

Am I missing something here?

PS: Not sure why you would pick on React for tooling complexity. You can use
it with one <script> tag and no JSX, just like angular or jquery or whatnot.
If you also want to use ES6, JSX syntax, have your code linted, hot module
reloaded, uglified, your sprites auto-generated, and all your assets packaged
for efficient distribution that's not react, that's a lot of independent
feature requests that require astonishingly minimal boilerplate to get running
considering the value you're getting. All of that is completely optional too.
If you look at how typical real-world react and angular projects look, they
would be very similar in terms of build tools used.

~~~
jondubois
The article makes perfect sense; React is bloated - It has too much tooling,
too much complexity, too many ways to do anything and no single way to do it
all!

In other words, conceptionally, it's about as simple as that tangled mess of
jQuery logic you wrote 10 years ago.

React without JSX is just horrible. I don't know why they even bother
mentioning this approach in the beginner tutorials - The code would be
completely unreadable.

~~~
cozuya
While I agree React without JSX is terrible and React with JSX isn't too great
anyways ("className" vs "class"? "defaultChecked" vs "checked"? everything has
to be wrapped in a parent or it errors??) it really doesn't feel bloated to
me. I do almost everything inside of class method functions I define or inside
of the render itself - if you're heavily leaning on stuff like
shouldComponentUpdate that really feels like an antipattern regardless.

------
bttf
This article is actually highlighting (indirectly) the strengths of Ember.js
and its ecosystem. As an Ember dev this article made me appreciate the way the
development of ember tooling and the library itself are both intertwined, and
that best practices are constantly being implemented into the tools used
across all developers, core maintainers and simple users alike.

------
vldr
Every language / framework has its tooling options but javascript has _a lot_
and no standard/preferred ways. Like with standards, it seems that tooling
problems are solved by creating new / more tools.

I have a strong Python background and I'm overwhelmed by the tools available
for just building / managing javascript and making it usable. With python (for
example) you don't need additional tools for managing/defining/importing
modules, building/compressing/minifying code or adding additional language
features.

The solution for me was to switch from Angular (where I had to make all
choices myself, which I wasn't capable to do) to Ember(-cli) that is making
the choices for me. And the lack of such a tight integrated supported set of
tools is what is and will keep me from moving to other frameworks in the
forseable future.

------
Egregore
I think Meteor might be the solution to some of these problems: it's easy to
set up, you can start working in few minutes.

Also it's very easy to work with React from Meteor:

[https://www.meteor.com/tutorials/react/creating-an-
app](https://www.meteor.com/tutorials/react/creating-an-app)

~~~
sotojuan
Another solution is ember-cli[1]

[1] [https://guides.emberjs.com/v2.2.0/getting-started/ember-
cli/](https://guides.emberjs.com/v2.2.0/getting-started/ember-cli/)

------
kartan
>Application developers should not have to become experts in the underpinnings
of the library just to use it.

I understand that that is the final goal. But as we introduce new technologies
it takes a time and more powerful machines until they can be simplified.

There is a lot of people asking for easy ways to build systems for millions or
billions of users. We will get there but we are still not there. It is amazing
that it is already so much simpler and cheap than 10 years ago.

If a product with similar features is easier to use makes sense to choose it.
But demand simple solutions to complex problems looks like out of place.

------
aikah
As people,tools and runtimes move to ES6 modules things will get better and
people will no longer have to use these dreadful frameworks. I for instance
try to experiment directly with virtual dom and dom diffing, without using
anything else.

------
jbverschoor
Fully agree.. Javascript "stacks" are just that. Stacks of unrelated libraries
which have to be stitched together using competing tools that do the same and
cannot describe their own USP.

------
carsongross
It's time to stop the madness:

[http://intercoolerjs.org/](http://intercoolerjs.org/)

~~~
bcardarella
...because the solution to JavaScript fatigue is yet another new JavaScript
framework.

