BIT-101
Bill Gates touched my MacBook Pro
The language and platform you use for creative coding is a huge deciding factor in how you will work, how much you will enjoy working, and even the kinds of work you will do. So it’s worth shopping around and coming up with something that lets you do the kind of things you want to do and makes it a good experience.
As readers of this blog will likely know, I started out my career in Flash. I’d wanted to do creative coding as far back as the mid-80s and had made some games and creative apps in BASIC on the Commodore Amiga, but never got beyond that until I discovered Flash around 1998. The workflow there just clicked for me and I was able to do all kinds of stuff that I only dreamed about before that. No, that’s not right. I was able to do far more than I had dreamed about.
What I loved about Flash was that it was initially a combination of coding and more traditional drawing and animation tools. You could draw something with the mouse or a tablet and animate it on the timeline, or you could animate it with code. Later versions of ActionScript gave us an actual drawing API where we could create shapes in code, and then animate them in code. At that point, for many of us, the Flash IDE became unnecessary and we moved on to code-centric tools like MTASC (Motion Twin ActionScript Compiler) and various code editors. Later there was FlexBuilder and a standalone SDK for creating ActionScript projects, and third party dev environments like FDT (Flash Development Tool).
What I liked about ActionScript was how easy it was to create art and animation. The drawing API was decent and a first class part of the tool. As was the display list and animation system. The enterFrame event let us code the timeline. The display list with nested sprites and movie clips made complex animation a piece of cake. Initially the language was loosley typed, but even when typing and classes were added, it remained very expressive. It never tripped you up with fussy syntax (though it did have its idiosyncracies). And compilation was pretty fast. Nearly instantaneous for simple things, and not bad for even more complex projects. The Flash Player was ubiquitous, so you could upload your content and the whole world could see it and interact with it.
When Flash’s days were numbered, Processing (or, as it was known a the time, “Proce55ing”) was an obvious replacement for many. It had a lot going for it, even back then. A very simple IDE, but you could also code using your own editor and tools. A super rich drawing an animation API, well beyond what Flash/ActionScript had. One drawback for me was that Processing was Java-based. And the output for the web was Java applets. These were not nearly as accessible as Flash movies. And by “not accessible” I simply mean that people could not access them because they didn’t have the Java plugin installed in their browser. But it’s great for installations or for generating movies, animations or graphics that would be used elsewhere.
Later, the JavaScript adaptation of Processing - p5.js brought much of the core functionality of Processing back to the web.
I used Processing off and on but it never made it to the top of my list of languages and platforms. The same with p5.js. I have a lot of respect for both. I just never went deep with them.
Both versions of this tool are very solid choices to this day for creative coders.
Cinder was another platform that saw a lot of adoption by creative coders around the time of Flash’s demise. It was co-created by Robert Hodgin, a hugely influential artist in the Flash community at the time, initially known by his project, flight404, one of the original classic Flash experimental sites.
Cinder is C++ based, and was far more powerful than most other tools in use at the time, and came with a higher learning curve. It was, and probably still is, used for many professional projects.
Unity was another obvious choice for a lot of Flash developers looking for a new home. It was mainly targeted as a 3D tool, but eventually had capable 2D animation workflows as well. It had a serious IDE for creating visual content and animation as well as coding in C# and JavaScript (if I recall correctly). Towards the end of Flash’s life, 3D was a popular subject on the platform. There were multiple home grown 3D libraries like Papervision3D and Away3D, and eventually Adobe added native 3D to the tool. For the people who were into that, the switch to Unity was a no-brainer. And it remains a hugely popular platform for game development in particular.
Of course, for many of us, JavaScript was an obvious path. It was mostly the same language as ActionScript - based on ECMAScript - and with the release of HTML5’s Canvas and 2D drawing context, it had a very capable drawing api which was very similar to Flash’s. The requestAnimationFrame function was essentially the same as ActionScript’s enterFrame event. So transitioning from Flash to JS/HTML/Canvas was quite easy. Additionally, it had the same benefit of allowing you to upload your creation and having it be available to the world. This is the path I took.
As a side note, Canvas also eventually supported a 3D context using WebGL, so it supported native 3D as well.
Anyway, when I was starting out on this path in March 2011, I did a series of 30 blog posts - one per day - about my journey in learning JS. The first post is here. And while they aren’t indexed, you can still walk through them by clicking on the next posts links. The code formatting didn’t survive very well, but if you really want to read 13-year-old technical articles, you gotta expect some rough spots.
JavaScript/Canvas remained my weapon of choice for 6 or 7 years. And it’s still an occasional second place tool I reach for now and then.
What I like about JavaScript… again, very expressive. It’s not fussy and lets you do what you want. In fact, it probably gives you too much leeway. And has more idiosyncracies than ActionScript had. The drawing API for canvas is very capable and very extendable. Zero compile time. It’s interpolated. And you just upload and everyone can see and interact with your creation. You hardly need any tooling at all. A simple text editor will suffice. But you can install hard core editors and linters and code completion tools, etc. that will speed up your dev.
If you want, you can go with TypeScript, which gives you optional typing and a lot of other advanced language features. But this means you need Webpack or some other system for transpiling, which ups the complexity of your projects significantly.
Some of what I did not like so much about JavaScript:
While I’d done a lot of on-line interactive pieces for nearly two years, I found myself being a bit more interested in creating large, high-res images for various projects, and have wanted to do more with creating static images and even movies, combined with generated audio or music. The JS flow for this was not as good. Working through the browser to create an image or animation on a web page and then saving that to a file on the file system is a pretty horrible idea, but that’s what I was doing.
Also, while JS has made great strides, it is not the fastest platform out there, especially when you start thinking of creating hundreds, or even thousands of frames for a movie.
Finally, I’ve mentioned some of the idiosyncracies of JS. They really do get pretty crazy at times. Some very serious WTF moments with how JS interprets code. It’s all logical if you look deep enough. I guess. I mean, there are reasons why it does what it does. But those reasons don’t make much sense to the average human.
So in late 2017, I started looking around for my next language and platform.
Python was an initial choice. Python has tons of libraries, and more than a few for drawing 2D graphics and doing animations, including pycairo. But while I’d done some work in Python and liked it well enough, I kind of wanted to learn a new language. So I skipped over this one at the time.
A couple of times later, as recently as late 2023, I thought about coming back to Python using pycairo. I ported some of my existing stuff to it, but found it painfully slow compared to what I’ve been used to over the last few years. So I again abandoned Python as a serious language for creative coding. Just my opinion.
In last 2017, two languages had caught my attention, Rust and Go. I decided to go for Rust first. I found some Rust bindings for CairoGraphics, which is a C-based graphics library - the same one pycairo is based on. I built out a capable graphics library and started doing some fun stuff using Rust. It’s a great language for creating apps and services, but I really struggled with it for doing any kind of creative coding. It’s extremely strict. It aims to prevent you from doing anything that could create a crash or memory issue. It just won’t compile until you do things the exact way Rust demands. Going back to my last post, it was extremely hard to stay in creative mode while fighting with the details of how Rust wanted things to be. It just wasn’t going to work for me. That said, others have done creative coding and even game programming in Rust. Power to them. It’s not for me.
Click!
I dipped my toes into Go in early 2018 and haven’t really looked back since. Every once in a while I think about trying something else (see above about Python) and always come back to Go. I stuck with CairoGraphics using a library I found called go-cairo and started building my own library on top of that. For whatever reason, the language just clicked with me. Although strictly typed, it often doesn’t feel like it is. It gets out of your way and lets you code. The syntax is mostly easy to pick up. It’s FAST. It is a compiled language, but you can run it like a scripting language - go run main.go. This compiles your code to an executable in a temp folder and then runs it. The compilation is generally so fast that it feels instantaneous, like you’re just interpreting a file - with a very fast interpreter.
Cairo is pretty much a superset of HTML Canvas’s drawing API. Very capable and very extendable. The library I was using was not in active development or maintenance, and after submitting a few updates (which were merged in), I finally just forked it and made my own version which I maintain for myself at least - blcairo. Beyond just cairo bindings, it adds all kinds of custom drawing routines and an animation framework for creating still images, frame sequences, gifs, videos, sprite sheets, or image montages. Beyond that I created another library, bitlib, which has custom math, geometry, easing, random, color and noise modules. This is in constant development. Almost every project I do winds up with some update to one or both of these libraries. The two of them are my bread and butter and I’ll talk more about them in a future post (or two).
Beyond the language itself, what I like about my current workflow is that it’s code -> executable -> image or animation on disk. Liberating myself from the browser was one of the main things I was after in 2017 when I decided to move away from JS.
One of the things I really miss about Flash and JS though is that interactivity. I can generate and upload animated gifs or videos or images and people can see them, and it’s great. But sometimes I miss the days of making things people could play with and interact with and explore on their own, sometimes wasting hours on them. Maybe someday I’ll get back into that, but I feel like I’m on the right path for now.
As I said in the beginning of this post, finding the right language and platform is pretty important to your workflow and productivity and even your creative potential. Don’t just do what everyone else is doing. Explore and find out what works for you. Hopefully something will click.
Next up I’ll talk about another piece of my workflow, which I started to touch on here - libraries.
Header image 'Computer books' by simonov is licensed under CC BY-SA 2.0.
Comments? Best way to shout at me is on Mastodon