Processing sketches by Ben Fry and Casey Reas, as ported to JavaScript. A great hack — but is it the second coming JavaScript bloggers say it is?

I think ports, hacks, and tech projects are fantastic. I’m a believer in experiments and proof of concept. So when I saw the port of Processing to JavaScript, I was impressed. I think this stuff is valuable, even if it’s imperfect.

Processing.js could indeed be useful in some cases, and it’s a testament to developer John Resig’s prowess as a JavaScript guru. But it’s limited by the restrictions of JavaScript. That isn’t a deal-breaker — it just means you need to adjust expectations and use this tool as what it is.

Unfortunately, the word "JavaScript" is magical to a lot of the Web development community in a way that seems to make them lose sight of reality.

Processing.js Aftermath [John Resig blog]

That’s sad. Because if "Java" remains a four-letter word (erm … well, you know what I mean), it really will be a massive blow to the open future of rich client media.

The Reality

Processing in Java is …

  • Extensible (you can easily add Java libraries to add features)
  • Massively compatible (you need only Java 1.3 or later, which believe it or not is already on the majority of machines — on CDM, we see roughly the same penetration as we do for Flash)
  • Fast (significantly faster than JavaScript for processor-intensive operations)
  • 3D
  • Functional in the browser and as desktop software on every platform
  • Compatible with desktop features (hardware support, MIDI, synthesis, audio, video … see the extensible bit)

Processing in JavaScript is …

  • Limited to JavaScript’s capabilities — and thus not nearly as extensible
  • Massively incompatible (IE7 doesn’t work at all. Firefox 3 is recommended, even though it’s not out yet.)
  • Slow, often unstable, and CPU-hungry
  • Browser-only
  • Loses all desktop functionality (hardware support is significantly less than what you get with Flash)

This is not to say it’s not a good idea, or that it’s not fun to play with. In fact, none of the above restrictions take away from the coolness of John’s project — I’m really glad he did this, and I think it has a lot of potential. But let’s see how the JavaScript-happy blogosphere takes the news…

The Hype

Chris Blizzard: Think about how fast that stuff might spread on the web, how we might end up with people sharing and learning together and how much better the experience on the web might be in the end.

I agree. That’d be really fantastic. Oh, wait … except that Processing has been available for years, with a massive, open community, several books, and completely free and open-source tools. So why does JavaScript change that? I’ve taught Processing to non-coders and been blown away by how quickly people pick it up. JavaScript makes that job harder, by introducing browser incompatibilities and a more involved syntax. (Some of the bloggers linked in John’s update even admit that their JavaScript code involves more verbose syntax and more lines, and I think it’s less readable — and that’s for simple examples. Yet they keep raving.)

And that’s before you get to the weaker performance and more limited capabilities.

Let’s check in with Wired.

Wired: "We cover a lot of language and software developments here at Compiler, but this might be the most impressive thing we’ve ever seen."

Really? I thought it was impressive, for sure. But the most impressive thing you’ve ever seen? I guess they must have missed the blind bearded lady I saw writing Ruby scripts with her toes, but okay…

I mean, it’s more impressive than anything I’ve personally done, but that’s not usually my point of reference.

Here’s another example:

Andy Baio: "one of the most amazing hacks I’ve ever seen… could Processing.js be the beginning of the end for the closed-source culture of rich media tech?"

The word "hacks" is key here. Processing itself is not a hack: it involves years of work, and people spend years of their life perfecting development in it like an art form. In other words, it’s less exciting than "hacks", which can be summed up in digg headlines and blog posts. Again, I love hacks — just not necessary to the exclusion of other things. (Even Processing.js was a hefty hack, involving seven months of work — and thus, presumably, more subtlety than you get here.) Then there’s the question of "closed-source culture." I’m assuming "closed-source culture of rich media tech" is aimed at Adobe, but even Adobe has an open-source compiler (Flex), uses open-source development tools (Ant, Eclipse), is working to open the player tech, and uses the ECMAScript specification, giving it the same roots as JavaScript.

That’s Flash, anyway. You also have Java, JavaFX, and the like — also open-source, and closer to the capabilities of Flash than Processing.js.

Noticing a pattern here?

If it involves JavaScript, if it’s a bleeding-edge hack, people love it. If it involves Java, if it’s a more mature, developed tool involving years of work, people aren’t nearly as interested.

Again, I’m not looking to bash Processing.js — on the contrary, I think the overheated hype could distract by how cool Processing.js genuinely is. If this is so valuable, why not work on the substance of the problem?

But instead of worrying about the huge problems of delivery, incompatibility, instability, and slow performance, we already have multiple solutions for developing Processing.js code inside the browser. Are people really that allergic to a local client text editor?

And all of this is a sobering reminder of just how out of touch I am. Yeah, you read that right — I’m out of touch. The problem is, I don’t move in the new Web circles. I do real-time audio DSP, video encoding, 3D graphics, live audio synthesis, multi-track sound, and high-definition video on a near-daily basis. This is the stuff that doesn’t work "in Firefox," that you can’t code in JavaScript. It’s the real rich media — the things that are difficult to code, performance-intensive, and can’t be replaced by online Web 2.0 apps. It’s the stuff that’s close to the OS instead of close to the browser and the "cloud." I think it’s connecting this rich client stuff to the cloud that will ultimately create the Web of the future. (Let’s not call it Web 3.0 — let’s just say the slightly more futuristic Web.)

It’s just hard to develop these things — and maybe that’s why people are less interested.

As it happens, part of what makes Flash so competitive is that it’s on the client end of the spectrum. You’re writing in ActionScript, but the important, performance-intensive "business end" of Flash is C/C++ libraries. It’s OS-specific implementations of multimedia support, support for things like video and camera input, and codecs for multimedia. That’s what has made Flash so formidable. Without codec support, Flash’s success on video community sites is suddenly meaningless. Microsoft is moving fast with Silverlight, too, and they’ve got the cash to buy up engineering solutions they need.

Java is better than a lot of people give it credit for in these areas — often far better than Flash. Unfortunately, it’s been crippled by aging multimedia support, support that really looks like it will get in JavaFX and updates to the consumer edition of Java. Java’s not perfect, either, partly because of its cross-platform designs and the language and platform themselves — see also the C++-based OpenFrameWorks, which outperforms Java/Processing at some tasks.

Bottom line: Processing.js is very, very cool. But if you really want an open-source option that can cross platforms, work in the browser and in desktop apps, and has the support for rich clients of the future, it’s not JavaScript. It’s Java. It’s not better — it’s just different; it’s a different tool, one better-suited to this particular application. JavaScript is the apple, Java is the orange. And Processing works on Java now in a really mature version you can download for free. Even if you’re a JavaScript programmer, it’s worth trying it out yourself.

  • There sure has been some insane hype. I love processing.js, and am primarily a javascript developer. The javaness of real processing did scare me, but I gave it a go many months ago, made some really cool apps with it. I really love Processing!

    Beyond the hype and current browser incompatibilities and bugginess, I feel the real power of Processing.js is not the language translation or the running of some processing apps straight in the browser without going through the plugin system. I think the power is that it provides the wonderful Processing graphical drawing interface to javascript developers. As javascript frameworks like Mootools, jQuery, and YUI have unlocked the power of the browser by creating better interfaces to existing things, I think Processing.js will be the beginning of many 'canvas' frameworks which unlock the power of the canvas element itself. I expect the main application will be boring stuff like animated charts, and likely also some really interesting games.

    There are problems with the browser plugin model, and none of them are Java's fault, but never the less, java will always be a second class citizen inside a webpage, just as flash, quicktime, and media player are.

    Nobody want's to wait for java to load just to display a chart.

  • Hey Jenna,

    Good points, all, and I tend to agree. Java applet load times are improving, and there are some fixes … but I think Java's more likely to compete with, say, AIR, than with JavaScript or even Flash. JavaFX should be better, but it'll require a plug-in, so like AIR I think you'll deploy it when you want someone to do something more substantial and you can get them to take the time to download a few megs of software. And I can see the appeal of Processing.js there. But then I come back to this issue, if you can't make it cross-browser compatible, when would you actually use it? Wouldn't you just go to a simpler interface for the Web, and when you really need rich content (which it won't do anyway), go to Flash, Java-based stuff, etc.?

  • Pingback: Create Digital Motion » Want Easy Processing? Use the Downloaded Tool()

  • How do you think that JavaFX and Processing compare?
    I am working on open source image processing in Java, and am wondering which place would be better to try out my algorithms.
    What about OpenFrameWorks is that ready for prime time?

  • JavaFX I don't think has any image processing routines of its own; it's more of a high-level language for putting things together. But both Processing and Java can use stuff from Java.

    OpenFrameWorks is definitely ready for prime time, because the libraries it's based on are very mature; it's more a matter of OFW itself not having mature documentation, which will come in time.

    Which you use depends on what you're doing.

  • Thanks Peter,

    I had some pretty bad experiences doing image processing and computer vision under C++ in the past.
    While doing image processing using Java is a breeze.
    Do you know if Java is fast enough yet to do face tracking, for example, or do you need to go to a C++ based library?

    Here is list of the problem I had with C++ when I tried it several years ago:
    OpenCV was in beta so I used VXL, the other big C++ computer vision OSS library. It had a lot of cool stuff it in but it was very tedious to get started with at least under Linux:
    * Get cmake build system setup
    * Combine with Boost library, that uses bjam build system
    * Get FLTK GUI working
    * Get open GL drivers working
    * Make Python bindings to C++ templates
    * Find a version of GCC that works with all the libraries

    I saw some artists use OpenFrameWorks at the ITP spring 2008 show and thought that maybe it has finally matured to a level where it is easy to work with. What are your thoughts and do you know if it is truly cross platform (Linux, Mac, Windows)?

  • Pingback: Create Digital Motion » Processing + iPhone, Via JavaScript, SpiderMonkey, OpenGL ES()

  • Pingback: BLIZ » Processing Ports: JavaScript, iPhone, Flash()

  • I like Processing.js.

    It works. It's becoming more compatible with the original language as people use it. And browser architecture is going to shift gears dramatically over the next few years so we might see Procesing.js become more suitable in its accessibility than using applet technology.

    And you can still make stand-alone applications using Adobe AIR anyway.