Generative art and Processing

Generative art can make presentations look more beautiful without worrying about copyrights. It can also be printed on a large canvas and put in an art gallery if needed. But despite of this, its place is still not on the web as it has no function, it fulfills no task and it doesn't support a greater meaning. We can't make our images too big on the web; the quality of the ones we include is decreased by compression, so that our original may no longer look the same, especially when we remember how big uncompressed files can be and what fraction of these bytes we see on the web. If images are frequently one of the heaviest elements on a website, it makes sense to use the least amount of them that will support our current goal.

We could create beautiful things with the triple (HTML, CSS, Javascript), but the browser can't support an infinite amount of DOM nodes, CSS can't do some more complex animation that requires synchronization in the movements of various elements, and drawing on the <canvas> through JavaScript requires so many function calls, that it becomes too slow to be practical with many objects. On my machine I can render approx. 20000 DOM nodes and draw 50000 rectangles on the canvas before the browser becomes unresponsive. Contrast this with the problems we have today, which can have millions of instances of input data for which we seek an answer. This means that any problem of moderate complexity can't be solved on the web as there will be no way to represent its instances through the existing technologies.

Processing, another tool for generative art, takes a different approach. It already feels a cohesive whole and we don't need to combine different technologies together to make it work. Since it is based on Java, we can draw up to a million distinctive elements in reasonable time. It is suitable both for animation (as this free book shows) and for still images (just call noLoop() inside draw()). With Processing we can quickly explore how the various variables change over time and how their relationships work—in a very visible way. Most frequently used functions are directly accessible and they don't require an object instance to be called. This can save a lot of time. Instead of typing ctx.fillRect(), we type only rect(); instead of Math.min() or Math.sin(), we just type min() and sin(). Although this is possible in JavaScript, we would need to define a reference to each function. Mathematical formulas are often needed in various simulations and being able to use them conveniently is very important.

Processing.js has a similar API, but works in the browser. The library is relatively big, so it can be much slower if we tend to reload the page often.

Here are other sketches (compressed!) created in a couple of hours with Processing:

As you can see, in terms of speed and output, tools like Processing that are specifically made for graphics can be more powerful than the canvas available in the browser. At the same time, the browser is still better at providing universal value to everyone; it is not just for graphics we create for ourselves. It is a platform for information sharing and interactive feedback. Accessible and inclusive. Although it supports graphics, the visual is by no means used as a single communication channel. The web is much more multifaceted, which is why we so often return to it.