

My gripes with JavaScript - fholm
http://ironjs.wordpress.com/2011/06/22/my-gripes-with-javascript/

======
jerf
The other problem I would see is obvious if you continue with something like
the following logic: All successful languages passed through a phase in which
they had a broadly similar list of problems. How did they escape from that
phase? Because somebody had the power to move the language forward. Somebody
(or small set of somebodies) could say "yes" to that idea and "no" to the
other idea, and implement them, and have them out for use in a matter of
months, gather feedback on the results, and after ten years of repeating that,
create a credible platform.

Javascript's root problem is that there is nobody who plays that role. The
language has now been around for ~15 years, but it has hardly changed in the
meantime. _Not_ zero, I know that, but compared to the advances that any other
language made over the same period of its life, Javascript has hardly moved at
all. Not since Netscape lost the ability to unilaterally move the language
forward by virtue of having the de facto only implementation has the language
been able to move much.

So not only does the language have problems, right now, there is no effective
path for those problems to be fixed in any reasonable period of time. We know
this, because js.next shouldn't be "something we hope to see in a few years"
but rather something that should have been done ~2002/2003, if the whole
improvement process wasn't so broken.

(BTW, remember to separate "the language" from "the bindings". XMLHTTPRequest
was not a Javascript change, for instance, just a new binding that all
browsers had.)

Even the standardization process is slow, somewhat disconnected from
implementation, and is still essentially focused on fixing syntax problems
that have been dangling for a decade now. If js.next somehow successfully
manifests in the next few years, we _still_ have a lot of problems in the
library department, for instance.

Server-side JS will probably face a decision point at some point in the not-
very-near future, where the decision will have to be made as to whether it
sticks as close to client-side, browser JS controlled by a effectively-
leaderless process running at vanishing fractions of the rate of improvement
of any other language, or if it runs off to start creating its own
improvements, probably by paving over the cowpaths. I actually favor the
latter, because it would create some set of people who can say yea or nay,
restore an actual feedback loop, and create progress which could then be
propagated back to clients as appropriate.

~~~
maratd
The fact that everything you said is true makes JavaScript an even more
_amazing_ language. How many languages could survive 15 years without change
and still remain relevant? And not only relevant, but expand their influence?

Certainly this is mostly due to its unique position on the browser, but the
language had to be flexible enough to fill that role and more. That's
_amazing_.

~~~
Someone
IMO, it accomplishes this not as much by being good, as by being a parasite
that infects web browsers. At that, it is so good that some people think the
DOM and JavaScript are in a symbiotic relationship.

Yes, that is tongue-in-cheek, but without JavaScript, web browsers would have
found another language; without web browsers, JavaScript would long have been
forgotten.

~~~
maratd
> IMO, it accomplishes this not as much by being good, as by being a parasite
> that infects web browsers.

My memory is a bit foggy, but I recall Microsoft throwing a bunch of things at
the browser in the beginning. You can specify the language in the script tag.
VBScript anyone?

It wasn't like JavaScript didn't have competition ... it just won a very long
time ago.

~~~
Someone
In my memory, JavaScript won because it had market penetration, it did not get
market penetration because it won.

It had market penetration because it was included with Netscape Navigator.

Yes, it also was good enough at that time, but almost anything would have
been, in a time where a ten-line script was huge. I do not think that it would
have won against say VBScript if the latter would have been available on the
same set of browsers.

------
billybob
There seems to be agreement that Javascript is a messy language which is
popular by default: it was included in Netscape, then other browsers picked it
up. Now we're stuck with it.

I realize this would be very difficult and introduce horrible compatibility
issues for a while, but sometimes I think, "what if we could start over?" What
if Chrome and Firefox started supporting Python or Ruby or a custom, well-
designed language for web scripting? Could it gain enough momentum to replace
Javascript?

Actually, the easiest candidate would be for browsers to start natively
supporting Coffeescript. But imagine a "dream team" designing a language just
for the web, from scratch: Douglas Crockford, John Resig, Guido van Rossum,
Yukihiro Matsumoto...

Is this a "it's crazy but it just might work" scenario, or is it just crazy?

~~~
protomyth
If we started over, we should pick a VM, not a language.

~~~
moomin
Producing a truly language-neutral VM would be an interesting goal, one that
no-one's really got that close to achieving. (I think Microsoft's got
closest.) Making it a compact wire format to boot would be... challenging.

Ultimately, a VM is just another language with lousy readability.

~~~
protomyth
I see your point, but I think a VM spec comes with an implicit promise that it
is OK to develop languages as opposed to the "why don't you just program in
what we give you?" mantra.

I agree its a very hard problem. If I was starting from scratch I would
probably look a lot more on vector operations than someone would have 10 years
ago. Plus the manner of parallelism a person choses would seriously influence
language implementors.

------
kragen
His main point: "there are a couple of critical problems with JavaScript that
prevents it from ever being a viable alternative as development platform for
server application development."

But then he goes on to list things like "Lack of language defined modules and
namespaces" (which it has in common with COBOL, C, and PHP), "null vs.
undefined" (JS has eight kinds of nothingness — '', false, null, undefined,
NaN, 0, [], and {} — as opposed to a usually slightly smaller number, although
Python has nine: '', None, [], {}, (), NaN, 0, 0.0, and False), etc.

I think he has failed to prove his point.

------
BasDirks
I used to hate JS. In fact, like the over-opinionated teenager I was I
wouldn't waste any decent opportunity to make this known to my friends and the
rest of the world: "Real hackers use C, Haskell, Python or LISP!1". But then
as I started doing design work for web, I inevitably came in contact with JS,
and lots of it. And hey, you could actually build stuff with this shit. Then,
being as obsessed as I am with aesthetics and thus coding style and best
practices, I found out that it's actually possible to write good (looking)
programs with JavaScript. Add some CoffeeScript and underscore to the mix, and
I could even write them with pleasure.

This touching lifestory isn't meant to convince you that JS is any good, but
it should illustrate why/how certain individuals come to join the dark side.

------
Spines11
JavaScript is definitely very easy to mess up, but if you follow best
practices, I think it can actually be a pretty nice language.

------
mrspeaker
I'm sure you'll be happy to know that all your gripes are de-griped in js.next
(<http://wiki.ecmascript.org/doku.php?id=harmony:harmony> \- and strawman) -
and with the speed of browser upgrades they'll hopefully be here the
"reasonably close" future. Hopefully.

~~~
fholm
I'm well aware of js.next/harmony/whateveryouwannacallit. Come back to me in
10 years when it's implemented everywhere and everyone that was on an old
version of browser X has upgraded to one with those features.

~~~
olavk
Or use a tool that compiles js.next to lowest-common-denominator-javascript.

~~~
fholm
Yay a dynamic language with a compiler step.

~~~
olavk
Python has a compiler step - source files (.py) are compiled into bytecode
(.pyc) files. It just happens transparently. Doesn't make the language less
dynamic IMHO.

------
david_a_r_kemp
The author strikes out at the "same language on the server and client" claim,
which I think is a bit unfair. one of the great things about node.js for me is
that it is (mostly) js, so I can crank it open and understand what's going on
- this is especially true for libraries. I know js pretty well (and most of
the syntax hacks), so this is pretty straight forward. If I try and do the
same thing with django or rails, then I find myself investing serious amounts
of time just understanding the syntax (the splat operator is a good example).
Using the same language (not necessarily the same environment) that you
already know on the server does have genuine benefits, even if you do have to
treat it differently.

------
pnathan
Javascript is a really lousy language thrown together in two weeks or so.

What ideally should happen is browsers should expose the VM and an entry point
for interpreters to use and configure JS on the VM. That way other languages
could be used against the VM-in-browser.

I suspect Google is trying to move in this direction, but IDK.

------
franze
i never thought that one day i will be the quy who posts this: try
coffeescript, it really really helps (i would not believe it at first, either)

~~~
fholm
I'm not a fan of CoffeScript, it fixes the wrong problems. It's not the syntax
that's the REAL issue, it's the fragmentation, lack of module system, etc.

~~~
gmac
CoffeeScript doesn't do much to fix the bad bits -- it's still JavaScript,
after all -- but it does make the good bits way more fun.

