
JavaScript developers are incredible at problem solving, unfortunately - ScottWRobinson
http://cube-drone.com/comics/c/relentless-persistence
======
blhack
This is absolutely a NIGHTMARE for new developers. People come into the
language, and there are what seems like an infinite number of "the _only_
right" ways to do something, all of vary degrees of complexity/usefulness, and
_all_ claiming that they are god's gift to computer science.

That last part is the part that is most frustrating to me, and it isn't unique
to javascript.

Google, facebook, yahoo, etc. have all gotten along pretty much just fine up
until this point using existing web technologies. We should ALWAYS be trying
to improve those technologies, and we should ALWAYS being trying to improve
the workflows involved in using those technologies, but what comes across as
ridiculous is the apple-style "this literally solves everything, and
everything before it totally sucks and is useless and you are stupid for using
it" marketing behind them.

I like javascript. A lot. I use it every single day, and it does a lot of
useful things for me.

But my god the cognitive load involved in swimming through all of the "this
library literally saves THE WORLD" marketing fluff is intense.

Javascripters, I get it, you're really excited. I am too. But maybe tone it
down just a few notches.

Here's a thing I wrote about this topic a few years ago:
[http://thingist.com/blog.html?id=21434](http://thingist.com/blog.html?id=21434)

~~~
noir_lord
I just use Knockout.js unless there is a really compelling reason not to, I
just chose _one_ and learnt it decently well.

It supports IE (back to 6 believe it or not), is backwards compatible with
itself, is relatively mature, very stable, performs fine, supports modern
stuff like component orientated architectures and custom tags (if you want
them), interops brilliant with lo-dash/jquery and grows with you, it's also
way more of a library rather than a framework so there is very little koolaid,
the devs answer on github and are active (if not a huge community).

I also rather like it's <button data-bind="click: someFunction">Do The
Thing</button> binding syntax (not least because with phpstorm and pycharm you
can create custom language injections on XML attributes meaning I can do jump
to definition near perfectly).

~~~
another
Yeah, Knockout has also served us well: has been flexible as our architecture
has shifted, and has progressed steadily without forcing us to pay a
"framework churn" tax. It's become a mature, stable, pragmatic option, IMO.

------
vectorpush
> _the ecosystem around Javascript is so densely layered and frequently
> changing that maintenance of any project over any significant period of time
> is going to be a nightmare_

I hear this sentiment often, but don't really see any truth in it. Nobody is
forcing you to update your code to be in line with the latest JS trends. If it
ain't broken, don't fix it, and if it is broken, it was _always_ broken and
that fact has nothing to do with how rapidly the JS ecosystem is evolving.

Oh, but you want to leverage the latest and greatest that the ecosystem has to
offer... well, that's _your_ problem, not the ecosystem's and this is true no
matter which ecosystem you're referring to. JS developers are just spoiled
rotten because JS is so easy to refactor relative to every other part of the
system. When the NoSQL hype train came barreling through the developer
community a few years back, most of us didn't rush out to rebuild our
applications on a NoSQL back-end because the database is _too critical_ to
mess around with.

If you want the latest and greatest you have to pay for it, but don't imply
that there is something _wrong_ with the ecosystem for giving you _more_
options. Choosing the best tool is part of the job, and if you get hypnotized
by every shiny new toy that debuts on the front page of HN, that's a
professional flaw that only you can fix.

~~~
ozziegt
> _I hear this sentiment often, but don 't really see any truth in it. Nobody
> is forcing you to update your code to be in line with the latest JS trends.
> If it ain't broken, don't fix it, and if it is broken, it was always broken
> and that fact has nothing to do with how rapidly the JS ecosystem is
> evolving._

This is a really shortsighted viewpoint. Cue 1 year later where all your
libraries have fallen behind and you want to integrate a new library which has
dependancies on newer version of your outdated libraries.

~~~
vectorpush
> _Cue 1 year later where all your libraries have fallen behind and you want
> to integrate a new library which has dependancies on newer version of your
> outdated libraries._

As I already stated, that's _your_ problem, not the ecosystem's. If everything
has been working fine for a year, but now you want to introduce a new library
into the code, it's up to you to rationalize the necessity of that addition
with the technical burden of updating your dependencies. Nobody is forcing you
to use this new library and the only reason you can even consider this library
as a potential addition to your application is precisely because the fast
moving ecosystem has managed to provide you with a must-have library that you
didn't need a year prior.

That is simply the fundamental nature of dependencies and will be true no
matter which ecosystem you're working with, hence the ubiquity of package
managers like npm, rubygems, composer etc. Either way, just because something
exists, doesn't mean you have to use it.

------
Xeoncross
I learned a while ago that it doesn't matter how broken something is if
everyone is using it.

Humans are incredibly resourceful, if not also short-sighted.

Look at PHP, look at Javascript, look at Wordpress, look at email, look at the
original jQuery etc...

~~~
chuckcode
qwerty keyboard is my favorite example. Designed to solve the key sticking
problem when typing too fast but now we're all stuck with a layout designed to
be inefficient.

[https://www.addedbytes.com/blog/dvorak-vs-
qwerty/](https://www.addedbytes.com/blog/dvorak-vs-qwerty/)

~~~
PebblesHD
For all the hype I hear about dvorak and other alternate keyboard layouts,
I've never met anyone who could type significantly faster on it than I could
on qwerty. This isn't objective in any way but from experience I can't say its
any 'better'. As for ergonomics and other peripheral effects, I can't comment
as I haven't looked into them.

~~~
hkmix
Well objectively it's less finger travel and more home row use, so it has its
merits. The issue is that qwerty is such a de facto standard that you'll run
into many layout issues using dvorak.

~~~
mstechfreak2
I agree. I have a bit faster typing speed right now with dvorak. not sure if
it is really super-better, but I definitely benefited from
[http://www.typingstudy.com](http://www.typingstudy.com)

------
javajosh
"Let's put a weak language on a billion screens and see what happens." The
browser is Arrakis, and JS devs are the Fremen, hardened and shaped by an
environment that is just barely survivable. Let us hope our own Golden Path is
less painful than in Dune.

~~~
thiagowfx
Great analogy!

------
robertfw
Problem: browsers are designed for documents, not rich applications

Solution: javascript

~~~
collyw
Problem: JavaScript is the only language that runs in all major browsers.

So far no solution.

------
Cshelton
When I write c# code, it's just that, code. When I write Rust code it's just
code. When I write JavaScript...I'm making beautiful peices of art. Almost
like an old school watchmaker...a million ways to do the same end result.

------
Nadya
I'm not sure how to interpret the last part...

"Where I am from, the point of digging is not freedom from digging."

Is it a statement that the point of digging is to reach further and learn more
(positive)? Is it a statement more along the lines of "We dig because we must
dig to survive." (negative)? Or possibly that digging is simply a way of life
(negative)?

~~~
mattchamb
I take it to mean that if you keep digging, the hole will just be deeper. I.e.
you cant dig yourself out of a hole.

~~~
Nadya
What are you doing when you "dig into a problem"? :) I have a feeling the
intent was supposed to be pessimistic/negative (as you stated). I decided to
have some fun with the words. It leaves a few possibilities as to the meaning
and speaks well of what the developers are typically doing in their "problem
solving": digging deeper (for knowledge) rather than trying to get out of a
hole.

"People who cannot dig themselves out of a hole have never tried digging
sideways." \- JS Developer

~~~
vbnmvbnmvbnm
The interpretation is left open to the reader. It could be a negative and
cynical nod to the idea that we're doomed, and digging our way straight to
hell, or possibly a coy wink at an absurd paradox of conflicting goals among
participants.

------
felixgallo
One wonders how we get out of this mess. You'd have thought that
Microsoft/Google/Apple/whomever would have at least tried to include a better
alternative language in their browser by now. What stops them besides inertia?

~~~
lkrubner
X, Flash, Swing, JavaFX, SilverLight, AWT and more were all attempts to offer
a GUI over TCP. The important question is why they all failed. This is a
complex issue and many good essays have been written that address parts of the
question. Still, I think most of it can be boiled down to 3 things:

1.) some were closed-source and proprietary

2.) some were needlessly verbose, or enforced a workflow that made it
difficult to interact with designers

3.) some depended on HTTP for at least the initial handshake

What the world needs is an open-source GUI technology that is fun for
designers to work with and which uses a protocol other than HTTP.

My own bet would be that when we finally get such a technology, it will come
from the world of gaming, where they already do amazing GUIs, and where they
often abandon both HTTP and TCP and use UDP instead.

~~~
pags
One was killed by Apple.

~~~
joshstrange
If you are talking about flash let's be clear. Flash was killed by mobile (and
being generally shitty).

It's not like Apple said "Flash is the worst" and everyone said "Hey, you know
I never thought about it like that". In fact I'm sure battery was a major
reason not allowing flash, IIRC that (plus general indifference) was what was
the nail in coffin for even android phones flash.

------
program247365
JavaScript is both easy to get into, but difficult to master. There are places
on your path to JavaScript mastery where you're literally like, "Did I make
the right choices in my life?". Push a little harder, and like anything, the
added effort to understand the choices put in front of others, and why
something works the way it does, will be rewarding.

Illustrations/points like cube-drone has made here are popular because it's
partly an over-exaggeration, and partly true. People on either side of the
fence (JS mastery, or not), can find some kind of common ground of, "Right??
Isn't it painful??"

It's painful if you let it be. With the right mentors, and the right
motivation, you can make JavaScript do wonderful things.

As a whole I think JavaScript has made the web a more fun and interesting
place, no matter how much you want to bitch about the language or the
ecosystem. We stand on the shoulders of giants, and I, for one, appreciate it.
Thanks Brendan Eich! :)

~~~
coldtea
> _JavaScript is both easy to get into, but difficult to master._

There's no such thing as "mastering Javascript", because a language includes
it's ecosystem, and for JS this changes from day to day...

------
andrewchambers
The thing I like about clojurescript is the fact that it has a linker and
library system which makes sense.

------
ciaoben
Just a little advice for newcomers ( like me ) that are scared but at the same
time fascinated when it comes to use javascript. If you choose a framework to
work with, stick to it for the entire project, and if you find an error that
makes you struggle, don't immediately invent your own solution to patch it:
for all the things that are said in this article, it always easy being attract
to the fact that in every framework/code base you can put a simple piece of
code that make things simpler for your and let you go ahead when you are
stuck. But in my experience, most of the times, it only about being lazy and
scared from and understood error. Behaving like this it let you behind, and
don't make you improve your skills. And always break the entire logic of the
tools you're using.

JS is a scripting language, so it easy 'script' your solution and postpone a
problem. But it this way, you will never be able to improve, and your life
with JS will remain frustrating and hard.

------
wwweston
"Prototypal inheritance is pants-on-head stupid."

Well, he's almost merely wrong, if he were to take out the "prototypal" part.

~~~
SomeCallMeTim
Prototypal inheritance works well, if you understand it. It's only "wrong" if
you're of the Java/C++ OOP religion.

~~~
wwweston
My comment is arguably overelliptical, so I'm going to 'splain:

1) I agree that the author sounds like a lot of developers who have a "What am
I going to do without the exact class semantics I'm used to?" moment when they
get to JS, and rather than learn to answer that question, they either decide
that it's an inherent black mark on the language or go on a long quest trying
to get something more like the semantics of another language in JS (often
frustrating because it's almost possible).

2) More importantly, though... _implementation inheritance itself_ is
something a lot of thoughtful developers look on with a skeptical eye. Hence
Gosling's comment about "I'd leave out classes" if he were starting over with
Java, or Golang's interfaces. I wouldn't go so far as to call it "pants-on-
head stupid" (I'll reserve contempt on that level for JS linters that enforce
a no-semicolon policy), because it _can_ be a nice mechanism for re-use, but
it has its problems (fragile base class) and really only ever fits ideally to
the extent that the portion of your domain you're modeling is actually a class
hierarchy.

~~~
SomeCallMeTim
I come from games, which actually map to OO design better than most domains,
from what I can tell. And while I was briefly of the OO religion, I've since
recovered and appreciate all paradigms for what they can best accomplish. I'm
"Post-OO". :)

I do still consider implementation inheritance to be useful. But it's
certainly used poorly in a lot of circumstances (along with MOST of OO design,
including most of Java), and it may encourage bad habits. And I agree that
composition is often a better answer. Depends on what you're doing.

Aside: Do JS linters actually enforce a no-semicolon policy in real projects?!
I started using jshint and jscs recently in part to enforce the use of
semicolons (on the advice of "JavaScript: The Good Parts"). I see that jscs
has a "disallowSemicolons" rule, but I didn't know stupidity went to such
depths as to actually USE that rule...I thought it was there for
completeness...

~~~
insin
> Aside: Do JS linters actually enforce a no-semicolon policy in real
> projects?

Yes, they do. See
[https://github.com/feross/standard/](https://github.com/feross/standard/) as
a preconfigured example.

> (on the advice of "JavaScript: The Good Parts")

To paraphrase The Dude: yeah, well, you know, that's just, like, Crockford's
opinion, man; whether you want to use them or not, there's tooling to support
you either way.

------
erikpukinskis
This is a double edged sword. Yes, web technologies are sprawling, but they
are also constantly improving, which is not always true of the more tightly
controlled platforms. You can build on iOS for example, where there are
generally only a few ways to do things. But then you're waiting on Apple to
release new stuff.

There will always be platforms that are the Wild West, build-your-own-
adventure decentralized toolkits and others that have a narrow political
agenda and are more stable. Neither is better, it's just a question of what
kind of frustration hurts you less.

------
wwwtyro
"Problem: asm.js is basically unwritable by humans."

I have no idea where this is coming from, but it's simply untrue. See [1] for
a ton of examples of it being perfectly human read/writable.

All I can come up with is that people are looking at code compiled to asm.js,
which is of course going to have all semantic meaning stripped from it, no
different than code compiled to javascript.

[1] [http://asmjs.org/spec/latest/](http://asmjs.org/spec/latest/)

~~~
dbattaglia
I wonder if people just say that now without actually looking. The last time I
saw any asm.js code it looked like very boring old c++ code, nothing crazy.
Probably more readable to a newcomer than closures or self calling anonymous
function wrappers.

------
ScottWRobinson
While there's a lot of truth to this comic, I don't necessarily see it as a
bad thing. I think it speaks to the flexibility of JavaScript. Sure, all of
the tools and libraries can be hard to keep up with, but I'd rather have lots
of community support than none.

I have to admit, I was a JavaScript hater for a long time, up until recently
when I actually spent time to learn the language. Now its quickly becoming one
of my favorite server-side languages. Isomorphic JS was too hard to resist :)

~~~
po
So, you're saying you've become the guy with the hat. :-)

~~~
ScottWRobinson
Haha yup, pretty much

------
gotofritz
I actually think the "blame" is not so much Javascript's - after all it has
existed since 1996 and it wasn't like that at all for many years.

I wonder how much the rise of Github's / npm have to do with it. In the last 5
years or so it has become so much easier to create and share projects. Not
only so - it has become a requirement, people use Github as their CV, we are
all _expected_ to have side projects and stuff.

------
drKarl
I wish I could upvote it more...

~~~
adam12
Well, you could create another account... (I'm a javascript developer)

------
UUMMUU
I'm lost as to why Grunt is a problem. I tried to put all of my build scripts
in the package.json but moving to Grunt has been incredibly useful.

~~~
kentor
Because "code over configuration". Personally I'm not a fan of Grunt's API
which requires huge json files where keys mean special things. It feels very
ad hoc and ugly. Gulp's API is like 5 functions.

------
anotherangrydev
Problem: Javascript has almost no standard library. --> Why is this a problem?
What does he mean by standard library? Like, "strings", regexes and hashes?
Not needed.

Problem: Javascript won't run outside the browser. --> Fixed.

Problem: The DOM is too slow for video games. --> Fixed.

Problem: Javascript is single-thread by design. --> Why is this a bad thing?

Problem: Javascript is too slow for video games. --> [Citation needed]

Problem: Javascript has no packaging or a linker to tie these packages
together. --> Linker's not needed, and there are many package managers that
work pretty good. Also, since the beginning of javascript you could always
<script src=""> whatever you need, pretty cool actually.

Problem: Callback Hell. --> This "problem" only bothers bad/lazy/naive coders.

Problem: asm.js is basically unwritable by humans. --> Nope, and also, you may
not need to write asm.js at all.

Problem: Prototypal inheritance is just pants-on-head stupid. --> Clearly a
joke to try to use this as an argument.

Problem: Web resources need to be minified and zipped for performance. -->
Yeaaaaah right, because Javascript == Web.

Problem: Machine generated output is more difficult to debug. --> As compared
to... another machine generated output from a compiled language? Yeah right...

Problem: Async is still a nightmare, huh? --> Same as callback hell.

Problem: Balloning project size and complexity. --> [Citation needed]

Problem: Javascript still doesn't do everything. --> Is this guy serious? Does
he thinks this is a valid argument for anything?

Problem: Output runs very slowly on mobile devices. --> [Citation needed]

The guy's just a lazy coder. His favorite language would be one where he could
just do: "include <what_my_boss_wants>; run();". Good luck waiting for that
one.

~~~
MasterScrat
I... somehow disagree with everything you are saying, sorry.

~~~
andresmanz
Maybe it's because of that attitude of forcing JavaScript upon everything,
instead of simply using the appropriate tools. That's what I expect from
people like this comment writer, and that's what causes that digging in the
comic.

