Subject: Re: Why JavaScript sucks
From: kragen@pobox.com (Kragen Sitaker)
Date: Wed, 30 Aug 2000 20:04:15 -0400 (EDT)

Ben Tilly quotes Tim O'Reilly:
> > (Question:  why does no
> > one take JavaScript seriously?  It's becoming more and more important to
> > web-centric applications.  We see its importance growing as book sales
> > go through the roof, but despite the fact that it came out of
> > Netscape/Mozilla, the open source community seems reluctant to claim it
> > as its own.)  
> 
>  . . .
> As for your question, a better one is why I find that good programmers
> inevitably develop a distaste for JavaScript. . . .
> 
> JavaScript IMHO is fundamentally broken.  Here are a few of the
> basic problems. . . .
> 
> 1. They typed neither variables nor the operators.  . . .
> 2. Significant incompatibilities.  . . . 
> 3. Bugs.  Netscape's inheritance is seriously broken.  . . . 
> 4. Missing important features.  Suppose you want to run JavaScript in
>    multiple frames.  Suppose that you have a potential race condition
>    so you want to lock.  Please tell me how to write a safe mutex
>    that does not kill the CPU.  Either you kill the CPU or you have to
>    restructure all of your code to work off of an event driven model
>    so you can hack something up with timeouts.  Oops.

Perhaps you could elaborate on that in private email; I'm not clear on
how the "kill the CPU" option works.

There is, actually, a way you can do this: with an object containing
randomly named properties bound to closures with a thread continuously
iterating through it; this works if insertion and deletion into the
object are atomic and don't fuck up the thread iterating through it,
which seems to be the case in the few browsers we've tested it in so
far.  Of course, even the best JavaScript books (Tim's JavaScript book,
by Flanagan).

> The short answer is that people use JavaScript because there are very
> few options for portable code. 

Right.

Actually, JavaScript isn't that bad a language.  It has most of the
things I like about Perl, and does some of them better than Perl does,
IMHO.  It doesn't have the overall good feel of Perl or Python, but
it's not too bad.  Ben Tilly's #1 is definitely not a problem for me.

JavaScript also inherits Perl's fairly bug-prone coercion rules, and
adds a few bug-prone wrinkles of its own, and doesn't have -w or use
strict.

But the real problems with JavaScript from my point of view --- and
I've been spending the last several months trying to write useful
applications in JavaScript, using a couple of Tim's excellent books, by
the way --- is that the platform is the worst platform I have ever
tried to develop software, bar none.  

I'd rather write bare-metal programs in 8086 machine code in
DEBUG.COM.  I'd rather edit programs in the Bourne shell on a machine
whose only output was a speaker.  I'd rather write Perl on my 2.5"x1.5"
pager's two-thumb QWERTY keyboard and mail it to myself for remote
batch execution.  

I have done all of these, in fact.

They are all easier and more fun than writing portable JavaScript code.

- There's a general problem with long-running script bits: in
  _Microsoft_Internet_Explorer_ 5.0, the user gets a dialog box with
  which they can abort the script; in MSIE5.5, event handlers put the
  window on which they are running in an inconsistent state, and other
  script scraps trying to access the window can crash the browser; in
  the MozillaBrowser, long-running code gets suspended (allowing other
  bits of script to run) while the user is prompted whether to kill
  them.
- all of the parts of your program in a particular window can cease to
  run because the window closed, reloaded, or navigated to a different
  page. If you refer to these pieces of your program from another part
  of your program, the other part will crash.  (Yes, this means they
  fucked up garbage collection by doing explicit free().  Fucking
  morons.  At least it doesn't crash the whole browser any more, since
  Netscape 3.)
- a number of fundamental operations, like setting cookies, provide no
  return value to check for failure. You must determine whether they
  succeeded or failed yourself by other means.
- the multithreading model is not well-defined. Opera does preemptive
  multithreading; the MozillaBrowser suspends long-running threads
  while it offers the user the chance to kill them; other browsers
  simply do purely cooperative multithreading. I am not sure whether
  there are non-explicit ways to yield control, or whether you must
  simply exit (possibly having set a timeout or interval.) To make
  things worse, some [all?] browsers seem to preemptively multithread
  JavaScript when it is running in different windows.
- moving data in and out of form fields is prone to invoking unwanted
  character-set translations. 
- document.write(), the primary output mechanism, usually feeds your
  output to an HTML parser. You must be very careful about what you
  feed it.
- due to the inherent conflict of interest between JavaScript authors
  and browser users, lots of things that are technically easy ---
  opening a small window, for example --- are not possible at all. They
  generally fail silently, but sometimes they throw an exception that
  kills your script and notifies the user.
- a number of operations --- such as opening new windows --- do not
  complete immediately, but have their effect an indeterminate period
  of time later.
- connections between pieces of your program that run at different
  times --- such as before and after fetching a document over the
  network, before and after opening a new window, or before and after a
  one-second delay --- must be done by explicit continuation-passing,
  as Ben alluded to in his Point 4.
- in addition to these difficulties *designed* *into* *the*
  *environment*, there are more than the usual number of ordinary bugs
  and nonconformance in the environments.

I use JavaScript because I have to, because there is no other option.
Not because I want to.

-- 
<kragen@pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
Perilous to all of us are the devices of an art deeper than we ourselves
possess.
                -- Gandalf the Grey [J.R.R. Tolkien, "Lord of the Rings"]