This illustrates why people are jumping for Processing.js, even if it cripples many of the things that make Processing cool. Paul Downey inadvertently hits the nail on the head:
… somehow hadn’t got around to actually doing anything with it. You see it’s the whole Java thing that puts me off; when it comes to playtime life’s far too short to wrangle a CLASSPATH or compile an applet.
Ah-hah — there’s the reason: developer laziness, and fear of Java. And rightfully so. Configuring a full-blown IDE for Java can in fact be some effort — I think it’s well worth it when you’re doing lots of work over time, but what if you just want to sketch?
Here’s the good news: Processing’s "founding fathers" Ben Fry and Casy Reas agree with you.
The thing is, these JavaScript developers I think haven’t bothered actually trying Processing — the real Processing in Java. The creators of Processing understood that traditional Java development could be a pain. So the whole point of the Processing IDE that you get when you download — a simplified text editor that understands the Processing language — is saving you exactly that trouble. You almost never, ever have to deal with "wrangling a classpath." It just doesn’t happen, certainly not with the included libraries (which do a lot more than Processing.js can). In fact, there’s even a download for Windows that takes care of installing Java for you. Nor do you have to worry about the effort involved in "compiling an applet." Again, Processing does the work for you.
In case you’re interested, what Paul did is reasonably cool — he set up Processing.js inside TiddlyWiki, the personal notebook tool.
But, Paul, in the time it took you to do that, you could have been off and running in the Processing editor. Give it a shot, really. As I said, I think the hack for JavaScript is very much in the spirit of Processing as an open platform. But if you don’t experience it in Java, you’re missing out on a lot of what it can do.