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.
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)
- 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)
- 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
- Loses all desktop functionality (hardware support is significantly less than what you get with Flash)
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.
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?"
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?
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?
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.