Co‐Author Motives - q5js/q5.js GitHub Wiki

Motivation: Part 1

This section was written by @LingDong-

After having used many graphics libraries across many different languages, I have found that the Processing system has one huge advantage over others:

It gets stuff drawn onto the screen quick and easy!

This might sound silly, but it actually means a lot for people concerned with creative expression. The easier it is to try things out, before one's time and patience is up, the greater chance that you'll get something nice in the end. Therefore, although you can theoretically achieve the exact same result in any decent graphics system, the tool does matter in practice. Artists want more time to spend actually working on how their piece looks, instead of wondering why the computer doesn't work as intended.

At Carnegie Mellon University, where I studied computational art, p5.js is taught as the framework for the web, and its been a great introduction. However, due to some of the ways in which p5.js is implemented, I found myself using it less and less as I made more and more projects. Lately, I've found that I'll reach directly for the standard JavaScript/Web APIs instead of p5.js. I sometimes think of this as shedding the training wheels on one's bicycle. But I missed the artist-centered logic of the p5 interface! I started thinking, "Is there a better way?"

Just to clarify, I think the official p5.js implementation is perfectly justified for its philosophy and suitability for its intended purpose, but my own needs are different enough that I think they justify another implementation instead of pull requests to the official one.

In fact, its not uncommon for successful software systems to have multiple implementations of the same spec (think: compilers of C, implementations of SQL, and engines of JavaScript). This allows the user to choose a backend that best suits their goals or needs. When one is using p5.js (or Processing or OpenFrameworks), what one is really using is the same set of commands, the intuitive way of describing drawings, that empowers creative expression. The actual way these commands are implemented internally is incidental; it should be possible to swap internal implementations as necessary.

Motivation: Part 2

This section was written by @quinton-ashley

I thought @LingDong-'s work on q5 and the idea itself had great potential, so I decided to implement more of the p5.js API. My main goal was to make it work with p5play!

An increase in performance of even a few frames per second can make a significant difference in the user experience of a work of interactive art or a game, especially on mobile devices.

I was also interested in working on q5 because for a lot of p5.js users, the library itself is a black box. Even as an expert JS programmer and someone who teaches CS for a living, I still find myself scratching my head when I look at the p5.js source code. p5 was initially released 10 years ago and bad design choices were made due to JS limitations at the time. It's also become an absolutely massive library, with literally over 100,000 lines of code and documentation!

Thanks in large part to @LingDong-'s design, q5 is well organized, concise, and utilizes many modern JS features! I think even without inline documentation, the source code is easier for experienced JS programmers to comprehend.

I also started working on q5 because unfortunately I had a bad experience with The Processing Foundation. Simple bug fixes I contributed to p5.js all took over 5 months to be released. That's unacceptable given how well funded TPF is. I began to see p5play solely relying on p5.js as a liability. So being able to provide q5 as an alternative became a priority for me.

I think the problem is that management takes exorbitant salaries, 76% of the annual budget, yet many of them still work other full time jobs. They seem to expect that just because p5.js is open source that volunteers will do most of the dev work. 🕵️

When criticized, TPF staff play the victim, silence dissent, and badmouth former contributors, regardless of how much time and effort they've donated to TPF projects. This behavior is inexcusable. Its driving away the people who made Processing and p5 great. 🚪

In October 2023, The Processing Foundation's co-founder, Ben Fry, resigned and publicly criticized management for squandering millions of dollars in donations. I agree with Ben and I hope that TPF will hire full time developers to work on p5.js in the future. The summer 2024 pro5 grants are a great step in the right direction.

Motivation: Part 3

This section was written by @Tezumie

My journey into contributing to q5.js began with a deep passion for creative coding. I initially built my own library, T5.js, from scratch to learn more about the inner workings of a creative coding library. This project was driven by my desire to understand and enhance the process of creating visual art through code.

The q5.js team took notice of my work on T5.js and reached out to suggest we combine our efforts to further develop q5. We shared similar goals: minimizing the size of the library, optimizing performance, and adding much-needed functionalities that p5.js had yet to implement.

One of the aspects I love most about q5.js is its compatibility with p5.js add-ons, something my custom T5.js project lacked. Working with Quinton and the team has allowed me to get creative with new functionalities in q5 as well. We've collaborated on several features, such as FlexibleCanvas, which enables projects to be dimension-agnostic.

I genuinely love creative coding and engage with it every day, giving me a deep insight into the needs and potential improvements for a library like q5. My hope is to bring this knowledge and enthusiasm to our work on q5, continually advancing the library to better serve the creative coding community.