

The trouble with Javascript - Brajeshwar
http://www.moock.org/lectures/troublewithjs/

======
mistercow
This seems rather un-self-aware. Yes, "class Food { etc. }" feels more
intuitive to you than how it works in JS _because you learned on the classical
inheritance pattern_. But classical inheritance is not _fundamentally_ easier
to understand than prototypical inheritance. You've just used it for so long
that you don't remember what it was like to see it as a newcomer.

If you want to be fair, this should be called "the problem with OO
programming", and the summary of the problem is that it's complicated and
requires that you learn a lot of counterintuitive concepts.

~~~
romaniv
I've started programming in JavaScript before or at the same time I started
programming in Java and still find that the author's argument is mostly valid.
It's not a matter of habit, it's a matter of consequences and the amount of
knowledge you need to have to make basic language features work correctly.

Prototypes are simply more complicated than classes. They change behavior of
objects, whereas classes _define_ behavior of objects. The syntax doesn't help
it either.

~~~
bryanlarsen
That's your opinion. My opinion is that prototypes are simpler than classes.
The distinction between a class and an object can be very tricky, especially
once you get dynamic or introspective because then you run into the situation
where classes are also objects.

~~~
romaniv
If it was simple, there would be no articles about "proper" ways to construct
objects and arguments regarding whether using the "new" keyword is a a bad
practice. It's absolutely ridiculous that such core language features need to
be discussed and argued about so much.

~~~
mistercow
They don't need to be discussed and argued about. If the irrelevant flamewars
are to be the standard by which a language is judged, then the only language
that will ever pass muster is the one that is never released.

------
romaniv
I would argue that the biggest issues with JavaScript are:

\- Most obvious solutions to simple problems are often wrong. (Examples:
iterating over a "dictionary", getting a variadic function to work.)

\- Callbacks that create callbacks and so on (hard to understand the real
structure of the program) and callbacks that are shoved into global variables
(hard to debug).

\- Insane type conversion paired with poor error logging. (This has nothing to
do with being dynamically typed, BTW. You can be dynamically strongly typed or
at least have some safeguards.)

~~~
sixbrx
I'd add that it's too easy to pollute the global scope accidentally, because a
simple anonymous block structure (e.g. braces) to scope variables is not
allowed. Best workaround is to wrap most all code in an anonymous function
that is then immediately executed (function() {<your code here}}).(), but
that's ugly and easy to forget. I think Coffeescript does this _by default_
for all blocks of code, which IMO is one of the principal reasons for
preferring it to original javascript.

~~~
lowboy
> which IMO is one of the principal reasons for preferring it to original
> javascript.

It's a nice feature, but saying it's one of the _principle_ reasons to prefer
CS over JS is a stretch. Wrapping your entire file in an IIFE is a one-time
development cost and a simple pattern to remember. Compare that to the
syntactic sugar, safeguards, and added functionality that one will leverage
constantly during development.

------
ender7
As an ex-Actionscript, now-JS programmer a lot of this resonates with me.

After the move, I missed a lot of things - mostly the productivity stuff like
type-safe renaming; intellisense; clickable function names. Also the presence
of a real module system, and the fact that the compiler would catch my typos.

However, after comparing my two codebases (the original one in Actionscript
and the new on in Javascript), I can't help but be amazed at all the damn
boilerplate that's in my Actionscript. I ended up spending an enormous amount
of time specifying interfaces and careful inheritance chains so that all of my
type annotations would be compatible and safe. Did I need to do all that?
Probably not, but the design of the language certainly encouraged me to do so.
I can't help but wonder what I could have done with that time - especially
considering the fact that my JS codebase doesn't seem to have more bugs or
worse stability.

Would I switch back if I could? I'm not sure.

I can't help but think that there's a real opportunity for a Coffeescript-like
language with a module system, clean class syntax, and some Go-like features
such as Go interfaces and type inference, plus manual type annotations when
necessary.

~~~
georgemcbay
"I can't help but think that there's a real opportunity for a Coffeescript-
like language with a module system, clean class syntax, and some Go-like
features such as Go interfaces and type inference, plus manual type
annotations when necessary."

haxe meets a lot of these criteria and has been around for a while.

~~~
jdonaldson
seconding this.

Also, a new version of the haxe compiler was just released that is geared
towards supporting new js features and cleaner integration:
<http://haxe.org/download>

------
ufo
Usually rants on Javascript pound on the warts it acquired due to being rushed
to production back in 1995. Warts like semicolon insertion, the lack of a
module system, etc.

Instead of that, we get boring syntax arguments that seem to have come from
yet another static vs dynamic programming language flame war, written by some
someone that thinks the Java OO model is the only acceptable OO model. More
then half that list also apply to Python or Ruby and that is just silly.

~~~
lis
I wouldn't exactly say that the list is wrong, just because half of it also
applies to Python or Ruby. All languages have some kind of issues, so I guess
it's an okayish list of Javascript specific gotchas.

------
jianshen
Random contextual side note:

Colin Moock has been contributing to the webdev world since the late 90s
(<http://www.moock.org/webdesign/>) mostly focused on Actionscript. Back when
people thought web development was a joke (and not flash), he did a ton of
work teaching and writing about what he had learned and I probably wouldn't
know what I know about web dev without folks like him.

That being said, I think the lecture was poorly titled given his
conclusions...

~~~
sosuke
I thought the same thing since I've followed Colin since starting Flash
development. It turns out the title of this post is incomplete, on his
lectures page it is actually "the trouble with javascript (and why it's worth
it)" <http://www.moock.org/lectures/>

------
eo3x0
Here's why a "class" definition is a "function" in JavaScript:

Since JavaScript is prototypal and not class-based, the "new" operator simply
creates a tabla rasa object. The argument to new is a function that runs on
the new object with "this" in the scope set to the object.

Thus "new foo()" creates an blank object and runs foo on it. You can do this
with any function!

If you don't try to force C++/Java semantics onto JS, it's much easier to
understand.

------
gsoltis
I find it a little worrying that "Must run every line of code to find all the
errors" made the list. More worrying was the fact that the author thought
having compiler-enforced type safety would relax that requirement. Giving the
benefit of the doubt, maybe by find all errors, he meant "find all type errors
except for anytime anyone does something dynamic or a cast".

I would hope we all recognize by now that even running all lines of code (100%
test coverage) is insufficient to find all errors (especially semantic ones).
In any language.

------
kevincennis
"The trouble with JavaScript is that when I try to pretend it uses classical
inheritance, nothing works the way I think it should."

------
sosuke
The title is incomplete, on his lectures page it is titled "the trouble with
javascript (and why it's worth it)"

<http://www.moock.org/lectures/>

------
pkmays
Are there really no JavaScript-capable IDEs out there that support code
completion, jump to definition, re-factoring, etc? I don't see anything in the
language that would preclude such features.

~~~
Kaali
Yes there is, and it works quite well:
[http://www.jetbrains.com/editors/javascript_editor.jsp?ide=i...](http://www.jetbrains.com/editors/javascript_editor.jsp?ide=idea)

For sure it has some oddities with the completion as it can't be sure what the
prototypes are, but then it just lists functions from different prototypes
which match your prefix.

~~~
pkmays
Thanks. Those specific complaints from the link seemed more like quality of
implementation issues of typical ECMAScript editors vs Adobe's ActionScript
IDE. I can live without type inference in a dynamic language, but Visual
Studio and Qt Creator have spoiled me on the other features.

------
IanDrake
"Would _YOU_ Let JavaScript Land Your Plane?"

No I wouldn't, but I'd let it run my web app. Dude it's javascript, it runs in
a browser! What other language runs in all the four major browsers? None.

~~~
mistercow
I actually would definitely let JavaScript land my plane, assuming it had
undergone substantial code review, had exceptional test coverage, and was
interfacing with a reliable and sane API (I would definitely _not_ let the DOM
land my plane). In other words, under the same conditions as I would want for
any other language.

------
Androsynth
_This just in: Javascript does not follow the One Way to do things. Developer
outraged!_

------
taylodl
The trouble with JavaScript is the name is misleading - you're lead to believe
it's a scripting form of Java. Instead it's more akin to Lisp in C clothing.
Doug Crockford explains it best.
<http://www.crockford.com/javascript/javascript.html>

------
karterk
If all you want is classical inheritance, there are so many libraries that are
available which mimic that.

~~~
mistercow
I would say "or just use CoffeeScript", but you really should understand
JavaScript better than that before using CoffeeScript.

~~~
MatthewPhillips
Not should, _have to_. You can make the same types of mistakes in CoffeeScript
that you can make in JavaScript. Try compiling this:

    
    
      class Animal
        constructor: -> @type = 'Zebra'
    
        feet: []

------
happycube
Most of the author's 'trouble' would be solved by reading "Javascript: The
Good Parts"

~~~
reginaldo
I came here to post exactly this. I don't know what's happening, maybe it has
always happened, but these days I get more easily pissed when someone's
trouble could be solved just by reading a book... People: blog posts are nice
and all, but for god sake, just read a book. Especially when there is a good,
almost universally agreed upon, such book.

I think it's unbelievable that people want to learn about a subject but can't
be bothered to read a book about it. This leads to flawed learning at the
foundational level, and then avoidable surprises when years (yes, years...)
down the road people discover some "unexpected" behavior they should have
learned about at the very beginning of the learning journey.

In ye good olden days, when people came to a forum with a stupid question that
could be easily solved if the person asking would just bother to read the
manual, they used to get a polite RTFM...

Maybe we should start saying RAFB when stuff like that is posted.

------
fisadev
Let me guess.. you are a java senior developer, aren't you? You should learn
python, or ruby. They will open your mind to a whole new level of abstraction.

~~~
lmm
Please. Python is my favourite language, and has hardly any of the silliness
of js. In python classes are still classes, methods are still methods,
constructors do look like methods but are clearly a special method. Calling
something from the superclass looks slightly odd, but only slightly. People
know better than to monkey with object internals unless they have a good
reason, in a way that doesn't seem to happen in javascript - I suspect because
many perfectly sensible things in javascript look like monkeying around with
object internals (foo.prototype.x = ...). Python is dynamically typed, but it
gets away with it because its types are strict; if you think a is an int but
it's actually a string, you'll catch it when you try and do a + 5. And even
given that, python has added (weak, optional, but still there and
standardized) type annotations. Code completion works, I don't know how but it
does (maybe this could be done with javascript too). Modules are standard and
heavily used. The language has a standard and multiple compatible
implementations.

Thought: if "prototypal inheritance" really is more powerful/useful/etc., why
don't we see efforts to implement it in languages with traditional classes?
I've seen dozens of attempts at implementing "traditional" inheritance in
javascript, but none goingin the other direction.

~~~
tikhonj
Well, the reason you don't really see efforts to implement prototypal
inheritance in classical languages is because it would be much more difficult
than the converse. Prototypal inheritance is both simpler and more flexible
than classical inheritance, so building the latter on the former is much
easier.

Another thing: there is nothing fundamentally wrong with coercing types. The
only time you have an issue with this is when you combine overloading with
coercion. Particularly, JavaScript overloads + and uses it to coerce values,
which is just broken. Either overloading on types or coercing types by itself
is fine and neither is clearly superior; the problems stem from having _both_.

JavaScript also has a standard and multiple compatible implementations; all
the cross-browser issues I know of have to do with the DOM rather than the
language itself. On top of this, some of the JavaScript implementations are
_really_ fast for a dynamic scripting language.

Also, let's not get into Python's many problems and weird semantics. It may
not have the "silliness" of JavaScript, but it has plenty of silliness of its
own. I say this as somebody who's been forced to use it both at work and in my
courses: it's just as confusing as JavaScript was, just in different places.

------
SeoxyS
Don't get me wrong, JavaScript is horrible. But an argument whose major point
is JS' OO is a joke is kind of weak. You would be better off thinking of it as
a C-syntaxed functional programming language with mutable data structures.

Not that it's a more accurate description, but trying to use it as such will
make you more productive and make you write better code.

------
tyler-dodge
Did he just complain that there are no compiler errors in a interpreted
language?

~~~
atjoslin
He basically said 'it's a prototype-based language, therefore it is bad.'

...

------
munchor
[http://www.moock.org/lectures/troublewithjs/actionscript-
cod...](http://www.moock.org/lectures/troublewithjs/actionscript-
codehints-1.jpg)

Off topic, but what font is that?

------
elchief
so? Javascript is never, ever going away.

It'd be real nice if ECMA made some changes to fix the ugly, but how long
would that take to propogate? A decade?

------
sylvinus
... and your point is?

