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.