p5.js 2.0 RFC

[limzykenneth]

Topic

It has been hinted a few times here and there but the RFC (Request for Comment) document for p5.js 2.0 is now ready!

What is p5.js 2.0?

p5.js 2.0 is the next major release of p5.js. A major release allows us more flexibility to make changes, and we need your help to make the most of it! We're inviting proposals now, and we're focusing all our effort on them (aside from bug fixes). For more context, see this working document, which will eventually contain all accepted proposals.

Access

To guide continued discussion a bit, we want to emphasize that RFC proposals must thoroughly and seriously consider increasing access especially, to quote from the p5.js access statement, "prioritize the needs of historically marginalized groups over the continued comfort of more privileged groups".

We want to take this quite seriously so that we don't venture down routes that goes counter to the goals of p5.js, and to re-emphasize that p5.js 2.0 does not change the goals, commitments, priorities, or non-priorities for p5.js as a project.

What kinds of changes will be accepted for p5.js 2.0?

Essentially, any change to an existing feature can be considered, provided it's difficult to make outside of a major release. For example, changing the name of a function is not hard to do, but we can only do it during a major release because we need to notify users well in advance. That being said, we aim to keep as much backwards compatibility as reasonable for p5.js 2.0 and breaking changes will need a good reason to be so.

How can individuals submit a proposal for p5.js 2.0?

Fill out the p5.js 2.0 proposal form! Anyone can do this.

How can individuals provide feedback on existing proposals?

View the updated list of p5.js 2.0 proposals, click any of the proposals that you're interested in, and add your comments. If you know anyone else who may be interested in an issue, it'd be great if you could add a comment on the issue to tag them.

Proposed timeline for the p5.js 2.0 (TBD)

• February/March: Establishing access goals and defining values for p5.js 2.0
• February/March/April/May: Accepting and reviewing proposals for p5.js 2.0, with a focus on access (like accessibility and FES)
• April 11-13: Hosting an in-person meeting to discuss p5.js 2.0 proposals during OSACC
• May/June: Wrapping up proposal review process
• July-End of 2024: Actively implementing the selected features for p5.js 2.0

---

For those not familiar with the term RFC, it essentially means it is a proposal (often with a formal structure) that is inviting comments and discussion from the wider community on. The p5.js 2.0 RFC is not as formal as other RFC, I'm merely using it as a base structure to begin discussions so don't feel restricted in anyway and I want to gather as much feedback as possible on it.

The document is accessible here which also lives in a working branch of p5.js 2.0. I'm keeping the RFC document in git mainly because I want to keep track of changes to it, which at the same time also means it is at this stage a living document while we have discussions around what p5.js 2.0 can be like.

Each of the major differences/features p5.js 2.0 will have over the current 1.x version is split up into individual proposals in the RFC. I won't go into too much detail about the RFC here otherwise I will just be repeating what's already written in the RFC. Some proof of concept implementations are also present in the branch.

Anyone is welcomed to leave comments on any of the proposals of the RFC here and I particularly like to invite @Qianqianye @davepagurek @nickmcintyre @GregStanton who are either core contributors or have recent significant contributions, to have a look at the RFC. If there is anyone else you think may be interested in leaving comments on any of the proposals, you may wish to tag them as well. I may arrange for larger community video calls to go through things in general or in details as well, more info will come later.

[JustZambetti]

Color Module

The user should be able to

• use different color spaces;
• import new color spaces using addons.

We need a consistent Color API to communicate with many renderers, which make it unfiesable to have renderer dependent color spaces (ex: if you want to use the 2D renderer you have to use HSL). Therefore we could convert any color space to a big-enough one (like ProPhoto RGB) and use that in every renderer.

Proposal

I would use an abstract ColorSpace class with abstract methods to get the common color space. Every color space addon only have to extend the class.

About the public API, a solution could be to remove the ColorMode() functionality and just use functions.

fill(rgb(0,255,0));
fill(hex("00ff00"));

What do you think?

[limzykenneth]

@JustZambetti I'm not sure it is possible to have a common color space that represents every color. First there might not be a color space that encompass every possible color; but secondly and more importantly, the use of a color space is more about describing the relationship between one color and another, ie. as the name implies it puts colors in dimensional space so it would be possible to navigate from one to another.

The approach I would like to go with for this is closer to the approach taken by color.js with proper gamut mapping between color spaces and compatibility with CSS colors. Although I would like to leverage CSS colors as much as possible and almost certainly not have color.js itself as a direct dependency.

[nickmcintyre]

RFC 2.0

@limzykenneth thanks for inviting me to comment! Here are some initial thoughts on the RFC:

• Modularity: This is a great goal. D3 comes to mind as a model to follow.
• Renderers: I like the idea of the minimum p5.js bundle including p5.Element + p5.MediaElement + maybe p5.Renderer2D.
• DOM: Building on the point above, I propose centralizing all the DOM functions from src/dom/dom.js within src/core/p5.Element.js and moving p5.MediaElement to its own file.
• Async: I’d love to see a few examples before sharing an opinion.
• Color: I propose adding a function to simulate color blindness.
• Math: I suggest implementing p5.Vector and p5.Matrix from scratch with a limited scope (core graphics/animation/simulation). Their implementations should strike a balance between compatibility with existing sketches, beginner-friendliness for users, developer ergonomics, performance, and extensibility.
• Reference: I’m curious if we can make the process friendlier for contributors. Building the full website to preview changes isn’t fun.
• p5.Table: +1 for retiring this class. I suggest looking to d3-array for inspiration.
• Data: From the Data group, retire the entire Dictionary (e.g., p5.TypedDict) and Array Functions (e.g., append()) sections.
• map(): consider renaming this function to remap() to avoid confusion with Array.prototype.map() and JavaScript's Map object.
• range(): yes please!
• Static mode

[limzykenneth]

@nickmcintyre I'll share some more complete code examples after this week or so but I'll share some simple ones below, they are all working with the working branch currently.

• Modularity - Will go more towards Dayjs but d3 is somewhat similar. Will share code for this soon (it is mostly working already)
• DOM - I really want to break it up into smaller pieces because at it currently stands it is too big of a file to live only in one file
• Async - see example

let img;

async function setup(){
  createCanvas(400, 400);
  img = await loadImage("./Assets/cat.jpg");
}

function draw(){
  background(200);
  image(img, 300, 300, 100, 100);
}

• Color - color blindness mode sound like a great idea!
• Math - Can use help to build out this proposal more certainly
• Reference - This should come after we have the new website up, we can just take the reference bit of the new website and keep a copy here for preview
• Data - Yes to retiring these as well same as p5.Table
• map() - Definitely worth considering, might need to checkout how other library does it if they have similar function
• Static mode - Can you clarify what this means?

[davepagurek]

If we can await loadJSON(), does that mean we can fix #2154 and have loadJSON return an array when the data is an array?

Also, I hope to get the time to make a more full proposal for this soon, but I'm hoping to refactor our built-in shaders to make them easier to use as a starting off point for making your own shaders, and to enable third party material libraries (#6144) that don't go out of date when we tweak our shaders. An example I had posted on an earlier version of this rfc went something like this:

const myShaderGraph = p5.RendererGL.lightingShaderGraph.fillColor.replaceInput(`
  uniform float millis;
  vec4 makeColor() {
    return vec4(sin(millis)*0.5 + 0.5, 0.0, 0.0, 1.0);
  }
`);
const myShader = myShaderGraph.build(p5);

[limzykenneth]

@davepagurek Yes, awaitable loadJSON should be able to return proper arrays.

For the shaders and any WebGL related proposals, you can file a PR against the working branch RFC document when you are ready.

[GregStanton]

Thanks for inviting me to comment @limzykenneth! This seems like a really great initiative. I jotted down thoughts about the individual proposals, and I have notes on new proposals of my own. But my first concerns are the overall process and timeline, since we only get one shot at 2.0.

Concerns

Under the proposed timeline, the community would have about a month to propose and agree on API changes that potentially can't be undone for the next four years or more. This doesn't seem like a lot of time, considering that many of us may have overlooked opportunities for 2.0 because of the restrictions of 1.x. Some of the changes to the internals may also take a reasonable amount of time to decide on and implement.

For context, I personally would love to see changes merged by April. I think it'd help a lot with the add-on library I've been working on. Overall, though, going fast seems like more of a risk. It may take time to really get the word out about this effort, to provide a streamlined process for new proposals (e.g. with issue templates), and many other things.

Adjustments?

1. Extend the three-month timeframe to six months? Or 12? (I'm not sure if there are any hard time constraints.)
2. Pay a small team of community members to put in regular hours, help lead volunteers, and accelerate the effort?
3. Freeze all work that doesn't involve a systemic or breaking change, to focus efforts on getting to 2.0?

[nickmcintyre]

@limzykenneth thanks for the feedback. Here's what I'm thinking for a couple of points/questions you posed:

• DOM: I'll refine this proposal a bit.
  • p5.Element picks up several new methods in src/dom/dom.js. For example, p5.Element.changed(). The entire class should be defined in src/core/p5.Element.js.
  • p5.MediaElement should be defined in its own file.
  • p5.File should be defined in its own file.
  • Top-level functions such as select() and createDiv() should be defined in src/dom/dom.js or a few more focused files.
• Async: That's what I figured.
  • We should check in with more educators to get their opinions. This change would introduce new syntax and several new concepts for beginners. It could be OK, but we need more opinions.
  • Anecdotally, I've had success explaining await to middle and high school students using a version of Turtle graphics I made for the browser.
  • If we go this route, I propose dropping callbacks and applying a pattern like this instead:

let img;

async function setup() {
  createCanvas(400, 400);

  // Load and preprocess the image.
  await loadCat();
}

function draw() {
  background(200);
  image(img, 300, 300);
}

// A function to load and preprocess a cat image.
async function loadCat() {
  img = await loadImage("assets/cat.jpg");
  img.resize(100, 100);
  img.filter(GRAY);
}

• Static mode: We shouldn't require absolute beginners to define setup() and/or draw(), similar to Processing. We should make it possible to write sketches like the following without calling new p5() at the top of a sketch:

// Create a drawing canvas.
createCanvas(400, 400);

// Draw a circle.
circle(200, 200, 50);

Making this possible could eliminate common sources of friction and misconceptions, especially in early lessons. @MsQCompSci @calebfoss what do y'all think?

Timeline

+1 for taking a little extra time. To echo @GregStanton, the 2.0 release could be a good way to engage a broader cross section of the community. It could also help to organize/prioritize contributions for Processing Foundation Fellowships and GSoC.

I'm all for making 2024 the year of p5.js 2.0 and releasing on Jan. 1, 2025.

[limzykenneth]

Just a quick note about timeframe (I'll comment on the others later next week as I have a busy weekend/early week coming up), while I agree that taking a bit more time would be great, @Qianqianye and I were both keen on getting a release in April. I think it would be great to have at least something more concrete available by April and I'm not entirely sure about letting this progress for a whole year considering the probable pause we'll have on all other feature developments on 1.x.

I will have a chat with @Qianqianye probably next week or the week after to consider some options and will get back to you all. That being said, I don't want to impose a very strict timeline either and would be happy to proceed swiftly but organically.

[davepagurek]

if it helps for reducing the timeline, the WebGL shader change I was mentioning would be an increase in modularity without breaking compatibility, so it doesn't have to be a part of the 2.0 release if my time is better spent helping along the other efforts.