p5.js 2.0 Update: Beta, Timeline, and Compatibility Addons

[ksen0]

Hi!

I’m Kit, and I’ve joined the Processing Foundation recently as project lead for p5.js! I am so excited to be part of this amazing community, and to start helping bring the vision of p5.js 2.0 to completion.

In this update, I want to share our current thoughts about compatibility. (Even as p5.js 2.0 becomes more stable, p5.js 1.x will continue to be supported!)

Last year, we initiated the p5.js 2.0 RFC (Request for Comment) process to collectively re-envision the next major release of p5.js. Since then, many contributors have been working to make p5.js 2.0 happen.

• You can read more about the Governance Model and Decision-Making Process in the previous update: p5.js 2.0 Updates #7261
• You can find the beta release of 2.0 here: https://github.com/processing/p5.js/releases/tag/v2.0.0-beta.2 🆕

Now that the beta release is available, you can try testing out the beta! Please report any bugs you encounter to help improve p5.js 2.0. To try out the beta release:

• You can duplicate this web editor project: https://editor.p5js.org/davepagurek/sketches/wiOiYAp6P
• You can also add a script tag to this build that @davepagurek is hosting: <script src="https://davepagurek.com/stuff/p5/p5-2.0-b1.min.js"></script>

Even as p5.js 2.0 becomes more stable, p5.js 1.x will continue to be supported for at least a year. Here’s the timeline so far:

• We plan to have p5.js 2.0 finished by the end of March 2025.
• Up through the end of March 2026 (next year!), the p5.js Editor will still default to p5 1.x, with an option to switch to 2.0 when it is finished.

Between 1.x and 2.0, there are many additions, and some breaking changes. In addition to making p5.js 2.0 available as a library, we are working on preparing several compatibility addons that would make it possible to keep using 1.x features that are no longer part of 2.0.

• You can review the 2.0 changes in the release notes
• We’ve prepared this check-in survey about the breaking changes. This is because many users of p5.js are not active on GitHub. Please feel free to engage in the discussion here on any topic in the survey or regarding the changes - and to share the survey with p5.js users you know who might be!
• Do you have a library that depends on p5.js and you’d like to update it for compatibility with 2.0? If your library is in the directory then we are already planning to check whether the change from 1.0 to 2.0 breaks examples given by that library. Feel free to test your library out with the new release, or reach out / comment here!

What do we mean by “Compatibility addon?” If you want to use something like preload() which has been removed in 2.0, you would have to use a <script> tag to import both p5.js 2.0 and the compatibility addon for that feature. If you do that, any use of preload() just like in 1.x will continue to work. We are preparing addons for other changes, such as shape/vertex, listed here.

Thank you!

[GregStanton]

Thanks for the update @ksen0!

Question: Is there a plan for syncing the reference on p5js.org with the default version of p5.js in the web editor? For example, if the web editor defaults to 1.x until March 2026, but the reference documents version 2.0 when it's released in March 2025, then users following the reference may get unexpected errors.

I imagine there's already a plan in place for this, but in case there's not, here's an initial idea. By the time 2.0 is released, I think it will have been about nine months since the release of the new p5.js site. So, perhaps the link at the bottom of every page that reads "Looking for the old p5.js site? Find it here!" is no longer needed; it could be moved to a less prominent place on the site. In its place, there could be a link that reads "Using the new p5.js 2.0? Check out the updated site." In March 2026 when the web editor defaults to 2.x, this arrangement could potentially be flipped, with the 2.x version being the main version, and a link to the 1.x version at the bottom of every page.

In addition to alleviating confusion around the reference, this would also address conflicts relating to tutorials and examples, and to the contribute page, all of which might contain updates related to 2.0.

[ksen0]

Hi @GregStanton that's a great question!

This depends on exactly how reference is updated on the website itself. I am in the process of checking if/how it would be technically possible, but one idea would be that the URLs stay stable, and each page allows toggling between versions in a way that persists. So one possible behavior is that while the editor defaults to 1.x, and so does the site, opting in is done twice. Or, as you describe, if a user opts-in in one place, that persists in the second place (e.g., through a cookie). Depending on how a hypothetical "version toggle" might be able to work, it could be used in tutorials/examples, not only reference. If it's not possible or practical to do a "version toggle" approach, something like what you're describing makes a lot of sense.

One thing we've also been discussing is the idea of pro-actively helpful with transition from 1.x to 2.0. As I mentioned, libraries in the directory we are already planning to check whether the change from 1.x to 2.0 breaks examples given by that library, and notify those projects through an issue. It is up to the maintainers of each library whether to support 1.x, or 2.0, or both, and on what kind of timeline. I think it would be best if resources like the libraries page are also able to show which version is supported.

There are also other pieces, like the Autocomplete Hinter in the p5.js Editor, and FES, that will need to be updated to help users navigate errors related to versions. One way I'm thinking about this: if someone is starting not from the p5.js website, but from an example they found elsewhere online, and is new to p5.js, what are the possible ways that our tools can help them understand and resolve the errors?

Very happy to hear additional thoughts about all the above.

[tespin]

hi all, excited for these upcoming changes!

@ksen0 based on what you described, my understanding is that users would have 2 approaches:

Option A (independent toggles)
editor and site default to 1.x

1. user switches editor to 2.x
   • editor now uses 2.x
   • documentation still on 1.x.
2. user then switches docs to 2.x   
   • Both editor and documentation are now toggled to 2.x

Option B (linked toggles)

1. user toggles either editor or docs to 2.x
2. maybe a prompt or alert asks to confirm the switch, and both pages are then on 2.x

if i misinterpreted, please feel free to clarify! otherwise, i think both have strengths but also some tradeoffs. option A is more flexible and more explicit with the transition but introduces some cognitive load with having to keep track of which page is on which version. option B has a more consistent environment which is great for beginners, but would probably need some complex state management and can still be disruptive if there is no clear indication of versions persisting between pages.

@GregStanton's suggestions look familiar with how other popular tools have managed transitions. for example, for react's transition from v17 to v18, they made a beta version of their docs available at a new url (i think beta.reactjs.org or something). the legacy site was maintained but updated with banners and other indicators that pointed to the new docs until they finally transitioned to react.dev. i do feel this strategy is complicated in its own way with maintaining all the urls but it worked for their use case (big conceptual changes and new approaches to state and data management).

i think that p5 2.0's changes are less conceptual and more implementation, for the most part? there will definitely need to be version-specific references but the core concepts and learning pathways still feel similar. maybe we can think about a hybrid approach where the current editor url defaults to editor 1.x, but the ui includes a "Try in 2.0" button that links to something like editor.p5js.org/v2. for the reference docs, i believe i've seen other tools use a select / dropdown menu for global version selection, or if we want to limit to only the changed functions, their specific entries can have a 1.x / 2.x toggleable switch as part of the editor ui, which could also be used in the tutorials / examples pages. this way editor 1.x remains stable during the transition with a clear 2.0 opt-in, and the docs are flexible depending on what the user chooses.

other thoughts: a migration guide would be really helpful esp for users or libraries, possibly some kind of version detector in the code editor, a v1 to v2 converter ...

[limzykenneth]

New Beta Release

Version 2.0.0-beta.2 is now released with a few fixes and getting things up to date with 1.x.

I'll create a release on NPM as well so people can try out using p5.js directly from NPM with ESM and the beta being available on jsdelivr.

Edit: JSDelivr links

• p5.js - https://cdn.jsdelivr.net/npm/p5@2.0.0-beta.2/lib/p5.js
• p5.min.js - https://cdn.jsdelivr.net/npm/p5@2.0.0-beta.2/lib/p5.min.js

[calebfoss]

Welcome, @ksen0! I'd like to check in about accessibility in p5 2.0.

Last year as part of the project funded by @sovereigntech, I proposed some possible changes for improved accessibility in #6992. I see that this is listed as a high priority in the project, but I'm not seeing any updates on implementation. Will any of them be included in 2.0? Will there be any other features targeting accessibility?

One of the issues I mention in that doc is #6126, which has been open for over a year and still appears to be an issue in the 2.0 beta.

To commit to the project's mission, and especially since donations and unpaid labor are solicited while highlighting accessibility as a priority, I hope to see p5 and its website catch up on accessibility issues before adding new features like these.

Beyond my previous suggestions, I would love to see accessibility testing performed to get feedback from people with disabilities on both the experience of creating with p5 and engaging with content created using it. I think this would bring up many new directions for development that would prioritize accessibility. My suggestions are limited by my perspective as an able-bodied person.