views:

1008

answers:

4

Hi!

I am thinking about making a website with some fairly intense JavaScript/canvas usage and I have been looking at Processing.js and it seems to me that it would make manipulating the canvas significantly easier. Does anyone know any reasons why I shouldn't use Processing.js? I understand that older browsers won't be able to use it, but for now that's ok.

-fREW

+3  A: 

If you're OK with it not working in IE7, then go for it. I've had it working in Firefox 3. It's a slick way to bring Silverlight/Flash effects to your page.

My hunch is that libraries like Processing.js will change or be upgraded on a fast track path, so get ready to run when they do and keep up with the new features.

AndrewDotHay
+1  A: 

I'd say use Flash instead. More browsers have Flash installed, than the number of browsers that work with processing.js. In addition, you'll get much better performance from Flash versus using JavaScript (at least for now, though there are projects in the works to speed up JS a lot, but it's still a little ways off)

davr
Ideally Flash, Silverlight, et al should all be killed off by (at the very least de-facto) standardised in-DOM content and functionality.
David Toso
+2  A: 

It doesn't simplify drawing on your canvas. What it does do is simplify the task of animation if you are using canvas. If you are doing animation and you don't care about full browser support then use Processing.js. If you are not doing animation (if you are doing charting or rounded corners for example) then don't add the overhead of Processing.js.

Either way, I recommend that you learn how to use the canvas API directly. Understanding the canvas api, especially transformations, will greatly help you even if you are using Processing.js.

Prestaul
+3  A: 

As mentioned, IE is not supported by Processing.js (including IE8 beta). I've also found processing.js to be a bit slow in terms of performance, compared to just using canvas (especially if you're parsing a string with Processing language, instead of using the javascript API).

I personally prefer the canvas API over the processing wrapper, because it gives more me control. For example:

The processing line() function is implemented like this (roughly):

function line (x1, y1, x2, y2) {
  context.beginPath();
  context.moveTo(x1, y1);
  context.lineTo(x2, y2);
  context.closePath();
  context.stroke();
};

And you'd use it like this (assuming you're using the javascript-exposed API):

var p = Processing("canvas")
p.stroke(255)

////Draw lines...///
p.line(0,0,10,10)
p.line(10,10,20,10)
//...and so on
p.line(100,100,200,200)
////End lines////

Notice that every line() call has to open and close a new path, whereas with the canvas API you can draw all the lines within a single beginPath/endPath block, improving performance significantly:

context.strokeStyle = "#fff";
context.beginPath();

////Draw lines...///
context.moveTo(0, 0);
context.lineTo(10, 10);
context.lineTo(20, 10);
//...so on
context.lineTo(200, 200);
////End lines...///

context.closePath();
context.stroke();
Leo
When I tried this out, many examples also did not work in Chrome, Safari. This should be fixed..
Nils
That's a rather contrived example, isn't it? In Processing, you'd do the same thing with beginShape(), vertex(), and endShape().
endolith