Is Processing.js worth it?

Question

I am holding back on seriously pursuing ProcessingJS pieces mostly due to the bloat of the library. I have found that pieces like Ball Droppings do not use the library's Processing syntax parser, which is good, since I imagine it would slow down the page more, especially adding to the initial load and setup time. Still, I am wondering if it's worthwhile to use it basically as a big utility library like UnderscoreJS. For example, how good is its implementation with SVG compared with the other libraries out there today like RaphaelJS? Has anyone gone through the implementation of the Processing API extensively enough? When I skim through the I see a lot of boilerplate I don't really need, as well as a couple instances of questionable coding practices. But the library still seems to perform decently, at least on the ProcessingJS homepage, although the examples are set to run at 15fps, and not the (in my opinion) minimally acceptable 24fps.

Answer 1

I think it strongly depends on the project you are working on and the background knowledge you have with the processing library.

Processing.js is a great choice if you already have learned the original processing api (java) and want to leverage your existing knowledge in the web environment. It might be the only choice if you want to port an existing project to the web - actually this is probably the best time to use it.

If you are a JavaScript programmer and don't know much about processing you probably will dislike to write Java syntax in the browser and everything becomes even more problematic if you have to mix it with js. The API doesn't feel like JavaScript and there is a lot of code that could be written more elegantly.

Regarding performance it is not a bad choice, actually most projects run smoothly and I can definitely recommend using processing.js on circumstances like those explained above.

Here is great list of various javascript engines out there: Javascript Graphic/Game Engines

It is hard to recommend a single library, as the requirements are specific to each project. For simple graphics/diagrams: RaphaelJs is really nice and performs decently

Answer 2

how good is its implementation with SVG compared with the other libraries out there today like RaphaelJS

Processingjs doesn't use SVG as far as i know, it only uses canvas. Raphaeljs only SVG. There's an interesting read here and also at wikipedia about the difference. The main difference is SVG stores the vector data of objects so you can easily change position, colour, etc... of stuff but also provides mouseover events. Canvas - and processingjs - does no such thing, it draws to the canvas and forgets everything so you have to do more work. Don't know about performance difference between the two.

As far as the processingjs API is concerned, I don't have any clue as how it is implemented but since John Resig of jQuery is involved it can't be that bad to say the least.

I agree with user hlfcoding that writing java in browser feels weird. I am too looking for a cleaner solution for my future canvas experiments.

I fail to see how re-rendering for each frame in JavaScript can be seen as performant.

That's exactly how canvas works, you have to calculate and render every frame in js, it's not processingjs specific. I don't think that's such a performance hit, behind the scene a browser running SVG does the same anyway.