Processing Visualization Language Ported To Javascript

Manfre writes "On his birthday, John Resig (creator of jQuery) has given a present to developers by releasing Processing.js. This is a Javascript port of the Processing Visualization Language and a first step towards Javascript being a rival to Flash for online graphics content. His blog post contains an excellent writeup with many demos."

'polished turd'

[teknopurge]

This is some great work....

but this is like a polished-turd. Flash doesn't exist anymore to do animation or dynamic graphics, it exists to run fast. JS engines were not designed to process this kind of data efficiently, as seen by your CPU graph when running the demos.

I don't want to take away from the work, because it's a slick hack, but it's not the right tool for this job.

Regards,

Re:'polished turd'

[AKAImBatman]

Flash doesn't exist anymore to do animation or dynamic graphics, it exists to run fast.

Wait, are we talking about the same Flash? Because I've done a lot of Flash and Actionscripting, and "Fast" is not even in the vocabulary. Software rendered graphics pipeline? Check. Slow VM interpreter that makes Java 1.0 look fast? Check. Lack of direct rendering APIs? Check. Focus on animation at the expense of dynamic scene creation? Check.

Granted, Flash 9 is a major improvement, but it is arriving rather late in the game.

Not going to happen

[stonecypher]

The primary strength of Flash is its single vendor, rigorously portable, rigorously backwards compatible runtime. Javascript is far too fragmented to be a competitor to flash.

Re:Heh AvP comes ot mind here

[Anonymous Coward]

You lose anyway. You and the rest of the "ASCII text forever" crowd don't speak for me.

Eric

[erickhill]

Regardless if this is usable today for client work, this is insane stuff. The first iteration of Flash eons ago had plenty of nay-sayers. He made this over the course of seven months? Bow down, I say. Very impressive.

Re:'polished turd'

[AKAImBatman]

JS interpreters are not optimized to do image manipulation, DOM updates, etc.

Whiskey Tango Foxtrot. Optimized for image manipulation? You do absolutely ZERO image manipulation in Javascript. Same with Actionscript. All that is pushed down into the Canvas and Flash rendering engines, respectively. Same thing with DOM manipulations. Sure, you say "insert this item" or "delete this object", but it's the C/C++ engine under the covers that does the heavy lifting.

People haven't done their own image manipulation since Amigas stomped the earth.

Right now it's always faster(CPU %) to do an animation in Flash then it is to do the same animation in JS.

You make that statement, yet you posted a benchmark that showed Javascript to be faster than Flash. I'm rather confused. You do realize that the benchmark you posted below was in millisecond and not operations per second, right? i.e. Lower is better.

You have zero evidence for your statements. Listen to someone who actually knows something about these platforms. There's no reason why Javascript can't perform the same function as Flash using the Canvas APIs. And you know what? That's not a bad thing. :-)

Re:Not going to happen

[ozamosi]

I know, and so does everyone else.

You know, I recently heard about a project by John Resig (creator of jQuery) called Processing.js. It's a Javascript port of the Processing Visualization Language, which means it could be viewd as a rival to Flash for online graphics content.

You should check out his blog post [ejohn.org]

In case the sarcasm wasn't obvious enough: that's one of the most important things that Javascript libraries solve

Re:'polished turd'

[AKAImBatman]

I mentioned this above, but I'll reiterate it here. In that benchmark, LOWER IS BETTER. The brand-new Flash 9 VM engine did excellent (as I expected it would), but the Flash 7 and 8 engines were generally creamed by the Javascript engines. Which I don't think is what you're trying to prove at all.

The secret to the performance of Flash 9 is this little beauty: http://www.mozilla.org/projects/tamarin/ [mozilla.org]

A fully modern, high-performance, Just In Time compiler that gives the JVM a run for its money. It's an amazing piece of Javascript technology that Adobe has donated to the Mozilla project for inclusion in the next major revision of FireFox. Wonderful, wonderful engine that absolutely no one is using yet.

See, if you compiled to Flash 7 or 8, you're still triggering the Flash 8 engine. The Flash 9 engine is a complete rewrite that only works with Flash 9 content. So the next chapter of performance wars has yet to be written.

Q.E.D.

Re:Creator of WHAT?!

[grahamd0]

Can someone please explain to me why anyone would regard jquery as a black mark on John Resig's work?

I've found it very useful for anything but the most mundane js tasks. Certainly better than the piles of other libraries that all seem to be based around the fallacy that javascript needs classical inheritance. (Hint: It doesn't. It has prototypal inheritance.)

Re:'polished turd'

[frosky]

As a longtime Flash developer i can also tell you that wether u use it for animation, GUIs or for basic web apps, the primary appeal to people like me was that Macromedia created avery easy to learn authoring environment. And even as the application grew to include programming and such, its concept of timeline, tweens, movieclips, etc. was far simpler to learn than the alternatives - including MM Director. To me that is the core strength of Flash. So whoever attempts to compete should take that into consideration. Before Adobe acquired MM they failed miserably at competing because they had a very clunky authoring environment (at least as noted by most of my developer peers at the time)

Re:Creator of WHAT?!

[grahamd0]

Actually, I said it was useful for anything except the most mundane tasks (where the overhead of loading a library is not justified by the task).

Re:'polished turd'

[AKAImBatman]

Please check that link again as it appears you ahve misread it.

Actually, you should check my post below as I explained in detail why Flash lost that handily. The short version is that Flash 9 is not comparable right now because the VM is not in use by many projects. By the time it's in heavy use, FireFox will be using the exact same engine.

Did you even look at the JS code that is your "framework" to this stuff?

Sure. And the piece you picked (like most of the code) is motion computations. The piece you picked does a handful of mulitplies and library (fast!) calls for log, random, and square root. That *could* be heavily optimized with lookup tables, but there wouldn't be much point. That's not even a blip on the processor's time. All the real work is done in the Canvas API calls where the blitting happens.

There is no image manipulation in Javascript or Actionscript. The computations you see could be faster if Javascript had true primitive support, but at the end of the day it just doesn't matter. I know that because that was optimization 101 back when we developers had to write our own 3D engines. A routine that runs once per frame is far less of a concern than a routine that runs once a line or even once a pixel! Moore's law has continued to reinforce that truth. :-)

Other than that, Mrs. Lincoln, how was the play?

[Em Ellel]

Thus, anything outside of the above (images, pixel processing, and text) should work "ok" everywhere.

Is it just me or does graphical language that does not fully support image, pixel, or text processing seems a bit.... silly.

Don't get me wrong, I think its a cool toy I will be playing with, but until it actually works in more than one beta browser, its is no threat to Flash at all.

-Em

Re:My Post

[fuzzy12345]

javascript is crappy scripting language for use with HTML. [...] Java is a full blown object oriented programming language

I think you meant to say "Javascript is a full blown power-users' language, basically Lisp but with syntax problems, whereas Java is a crappy low-level language; the COBOL of the millenium."

Re:Heh AvP comes ot mind here

[rbanffy]

All we need is a decent and fast implementation of JavaScript. Apple seems to have a nice one in Safari that appears decent in Midori/Webkit.

And, BTW, we need one badly, because the Flash (I don't trust Adobe) and Silverlight (I don't trust MS) crowds are coming and won't wait for a fast JavaScript engine.

Re:My Post

[Uncle Focker]

Java is a crappy low-level language

Java's a low level language? That's news to me.

the COBOL of the millenium."

So you mean it's highly ubiquitous language with 100s of billions of lines of code written in it that spreads over innumerable applications?

Re:My Post

[Free the Cowards]

So you mean it's highly ubiquitous language with 100s of billions of lines of code written in it that spreads over innumerable applications?

Pretty much. Both Java and COBOL blow great big donkey chunks, but they're both used all over the place. They both have this great property of making it difficult to shoot yourself in the foot, which makes it practical to unleash hordes of medium/low quality programmers on a code base and actually come up with something that kinda sorta works.

Re:'polished turd'

[kestasjk]

Conway's game of life isn't a very realistic use case, a large bit-array with lots of sequential reads/writes. It's always going to be a CPU-bound task, no matter what optimization it gets More interesting and realistic are the graphical demos, which show off Canvas. The ones which draw something in Canvas and then do nothing more are probably the most realistic real-world-like demos, and they shouldn't cripple anything.

Re:My Post

[tkinnun0]

You nowhere near describing a stackbased cpu with the java language, it's not low level, ok?

Ummm, the Java byte-code is the embodiment of a stack based language, what with its operand stack and stack frames. You would have a point, if you had insisted on a register-based cpu...

if you ever done low lewel you know what I mean

I haven't written, but I have read enough assembler to see a disturbing amount of similarities: unconditional jumps, labels, bitwise arithmetic operations, reading and writing to registers (local variables). Sure, there is more freedom when it comes to declaring the operands for any instruction. Sure, the JVM checks the bounds of your array access. But compared to a modern CPU, I'd imagine that's peanuts.