
RE: “How it feels to learn JavaScript in 2016” - 0xCMP
https://0xa.io/its-funny-but-the-reality-is-these-tools-solve-real-problems-ebf48402d4af#.o92ddrako
======
niftich
Hopefully all tools solve real problems, but JS right now has too much 'throw-
out-everything-you-know' re-implementations of too many ideas at the same
time. As the post suggests, this manifests as incompatible implementations
where previous experience with one tool does not translate to familiarity with
the problem domain.

There's also not enough genuinely helpful meta-information to go around, as
single-tool how-to and quickstart guides dominate, and most discourse about
pros and cons doesn't address deep, foundational concerns. Some counter-
examples are the Redux Prior Art page [1] and the Mithril comparison page [2]
that go into detail about how their architectural decisions and dataflow
differs from that of other, similar frameworks.

But what this post doesn't address is why additional new tools proliferate. It
seems to both defend tools as legitimate, but yet admit that all of them suck
bad enough that new ones are constantly coming out. So what's the way out?

[1]
[http://redux.js.org/docs/introduction/PriorArt.html](http://redux.js.org/docs/introduction/PriorArt.html)

[2]
[http://mithril.js.org/comparison.html](http://mithril.js.org/comparison.html)

~~~
0xCMP
op here: Yes I do defend the tools because the alternative the article I
responded to apparently was not to use any tools. Obviously this is an option,
and for some cases it's hands-down the best one, but simply complaining about
the complexity isn't a solution either. The tools fix major problems with JS
development which the authors of the tools had no hand in making or power to
fix.

Many people complain about grunt/gulp/webpack but they don't want to use
Makefiles. Many people complain about how icky JavaScript is and can't wait
until ES6 and Babel already gives that to you today. There are thousands of
well written packages you can use to avoid reinventing the wheel which you
need to include as yet another file on a CDN which could end up being a
security vuln. or at the very least slower in HTTP 1.x. Same issue when people
complain about npm or left-pad.

They have perfectly valid complaints though, but the experience and
productivity then and now are completely different. And when you get past
setting up the tooling it's light years better. One hopes this only gets
better and simpler over time, but for now it's not.

