p5.js 2.0 Update: Beta, Timeline, and Compatibility Addons #7488
Comments
ksen0
changed the title
|
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. |
|
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. |
|
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)
Option B (linked toggles)
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 ... |
New Beta ReleaseVersion 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 |
|
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. |
|
Quick chime in to request that v2.0 try even harder to be v1.0 backwards-compatible. This seems like a big accessibility point – how many learning resources, materials (tutorials, videos, handouts), examples, etc will stop working due to breaking changes? Just two are mentioned for now, ie removing I just read the post regarding the pending On a personally affected note, tested within P5LIVE (the tool I develop since 2019 for the live-coding community), and found it breaks almost all demos (and my sketches), with the following error in the console. I also tried excluding the p5.sound lib to see if that's the issue – but perhaps you've made a big change in how Hmm also just disabled all overriding of global vars and still can't get even a basic circle sketch to work beyond the single first frame (remains static, frameCount doesn't grow.. somehow frozen). Happens while only adding a |
|
@ffd8 Thanks for chiming in here. I want to give a bit of context from my perspective and give a bit of reasoning behind the changes. I'm mostly speaking personally here. For p5.js 2.0, the main breaking changes that we currently see affecting backwards compatibility with existing sketches are preload and bezier vertices. Accordingly, the compatibility addon which is already implemented here patches these features where needed. If there are any additional breaking changes, that's what we want people testing 2.0 beta to open issue on, it might just be a bug and not a breaking change, or we might have overlooked it and can implement it into the compatibility addon, so I really encourage that. The compatibility addon does not add significant file size that a sketch needs to load, especially compared with p5.js itself. Creating a major semver release is a very deliberate choice to break backwards compatibility, to be fully backwards compatible will defeat the purpose of doing a major semver release, but that's honestly a bit backward in terms of motivation. The main goal of 2.0 is to bring p5.js up to the standard of modern Javascript and Javascript ecosystem in general, Stepping back a bit, I understand there will be existing materials that will have compatibility issue with p5.js 2.0, I have such materials myself and I know this will be a thing when even before p5.js 2.0 is a well-formed idea. If p5.js is bound to never break backwards compatibility forever because of existing materials, I see that as way too restrictive in terms of what p5.js can be. Keeping breaking changes fully around in p5.js 2.0 (such as bundling the compatibility addon into 2.0 itself) means that the next opportunity to make a clean break can only happen with p5.js 3.0 and we will be back in the same situation and discussion here, except having even less of an argument to make this clean break. The entry level for p5.js 2.0 and consequently materials for entry level should be the same all the way until loading data, changes to bezier vertex are done to reduce non-intuitiveness making drawing curves easier to use, other larger changes are either internal or addition in a non-breaking way. I don't immediately see where that entry level has been a few steps higher so I would like some clarifications here. Mentioned at the top post here, there is a transition plan, p5.js 1.x is not disappearing as soon as p5.js 2.0 is released and we are not abandoning 1.x, bug reports will still be reviewed and fixed just no new feature will be added. p5.js 2.0 is not even going to be the default version used by the p5.js web editor when p5.js 2.0 is released. You can also see in discussions above that we are looking into how to transition the documentation with the view that a lot of people will still be using 1.x. It is planned to have a least a full year for the community to transition with our support before any major switch is done (tentative time to transition has been pushed back from March 2026 to August 2026). If there are incompatibilities in terms of transition plan and timeline, let us know and we can work out something that can work. We are already in the process to testing p5.js 2.0 with known addon libraries to see to what extend they need to update if at all. We have been in touch with OpenProcessing to coordinate a transition plan that they would like to adopt. I'm more than happy to help look into P5Live and its requirement to work with p5.js 2.0 and I would suggest opening an issue for that. |
|
@limzykenneth many thanks for your thorough reply! I'll try to get more familiar with the upcoming features to appreciate why breaking changes were required. p5.js has been amazingly stable (thanks to so much hard work and PRs from the community!), while libraries have brought those deeper features for advanced users – that I would have been personally happy for 1.0 to reach 1.999.... great to hear the org has been working with OpenProcessing to coordinate changes, and I'll do the same as a separate issue. Guess it's also time to finally implement a version selection for individual sketches... In terms of 'a few steps higher' for the entry level beginner – this switch from synchronous loads to async/await, opens a pretty huge can of complicated worms. Just read a few StackOverflow threads and youtube vids to try and get the concept myself (not using it at all, even if I should) – trying to digest to teach a student who codes for the very first time, why they need to async/await their loaded picture of a fish, will likely require some 'just follow me' for a long while. Moments I also wonder about, ie Is the |
|
@ffd8 Honestly I actively avoided async/await myself for the first few years when it was available out of a sense of it being "un-javascript" or some other reason that may or may not be justified. I've since came around I guess and I've been using it where possible and it's relatively intuitive. It is to put it simply the attempt to make everything actually run from top to bottom as we expect it to, so at this point my view is that it is solving the same problem as preload just with Javascript itself.
The rule is In any case, I have completed the write up here, do have a look and let me know if I should clarify anything. It is a bit of a long read to give a fuller context, hopefully it can give you some idea around how to explain promises/asynchronicity to your students. I'm working on other long form write up on other intermediate to advanced stuff as well, including changes to addon library structure, and will likely get around to reviewing the addon libraries you have as well. Others on the team are working on other parts of the transition including more FES messages that helps with migration in both 1.x and 2.0 so error messages can help users correct syntax from 1.x to 2.0. |
|
@limzykenneth great writeup! Definitely clears the confusion on my end and leaves me confident I can get into async/await. Plus this writeup will become required reading in future courses. v2.0 is coming, that's clear and it will cause plenty of pains while juggling both versions during the transition and it's all for the better... nevertheless my stubborn brain fails to see why this In terms of library contributions, the 'callback' parameter won't be disappearing on any of the |
|
@ffd8 Yes, callbacks will still be supported the same. There's also a semi-secret functionality which is that the callback can also act as a filter for the promise resolve value, ie. what you return from the callback becomes the value the promise resolves to after loading is done. This opens up some potential extension possibility where an addon can call |
|
@ffd8 I totally agree with you. Even though it's nice to know that a compatibility layer will add the preload system back to v2 I think that the preload system shouldn't be removed at all. q5.js proves it is possible to do both, so why not implement something similar for p5.js v2? As a teacher I just don't understand why backwards compatibility isn't a priority. It seems like you don't take community feedback into consideration when making big decisions like this. It's sad. :( |
|
EDITED TO ADD: I've updated the timeline to make a bit more space to finish ongoing documentation update effort for p5.js 2.0. While that's in progress, we've also been working on the compatibility resources so please feel free to check those out! Hello again! I wanted to chime in with a quick note (before a longer post The current timeline includes over a year (until August 2026) to consider the details of these changes. Until then, 2.0 is not the default in the editor; and until next March 2026, 1.x will continue to be supported. This directly arises from considering the needs of educators, so that there's no big changes during the academic year, and that the library is available for a while before the switch. By the way, here's how the p5.js Editor will help manage version switching and compatibility addons. The current 2.0 project reflects active feedback from both the community and the advisory committee since the beginning of 2024. From the recent survey and this conversation, it seems that a wider conversation is now needed - and now also more possible because p5.js 2.0 is available for beta-testing. When it comes to the async/await and preload topic, any newcomers to this discussion can also check out the previous discussion from last year about this. There are many different opinions on what best serves students. The choice to move away form I recognize that this is big change, and I'm open to all ideas on how we can make this transition more supportive of learners and educators. Additional to the discussion, I think there's also a very pragmatic approach to this: if we see that, over the course of the next year, it seems like everyone p5.js 2.0 also relies on the preload() addon (in the editor, for example), then of course the conversation of supporting both and bundling can be opened. However, I think it's also really important to see if this change can be a positive one that supports p5.js growing along with JavaScript, and I hope that the next year can help the community try that out in practice. To highlight how @limzykenneth put it: "If p5.js is bound to never break backwards compatibility forever because of existing materials, I see that as way too restrictive in terms of what p5.js can be." Thanks everyone for all you do! |
|
@ksen0 It's great to hear that you're willing to continue the discussion on this and nothing is set in stone yet. I have a new idea that could be a good compromise and it'd be relatively easy to implement. Because the I respect that you want to encourage people to use modern JavaScript features like async/await and also not be bothered with maintaining separate documentation that uses I'm glad to see a willingness to break backwards compatibility in certain areas to streamline the p5 v2 user experience but the preload system is too critical in my opinion, as its removal would break all existing sketches that load anything. One downside of what I'm proposing is that easy lazy loading would not be supported (unless the user defined an empty preload function). But I don't think it's commonly done outside of the context of games, where asset pop-ins in-game can be preferable to making users wait for all assets to load with a loading screen. let dog;
function setup() {
createCanvas(100, 100);
dog = loadImage('dog.png');
}
function draw() {
image(dog, 0, 0);
}In p5 v2 it'd require a callback function. let dog;
async function setup() {
createCanvas(100, 100);
loadImage('dog.png', (img) => (dog = img));
}
function draw() {
image(dog, 0, 0);
}There could be a function like let dog;
function setup() {
createCanvas(100, 100);
usePreloadSystem(true);
dog = loadImage('dog.png');
}
function draw() {
image(dog, 0, 0);
}I respect whatever decision you'll make, no pressure, as I could implement this myself in q5play (my upcoming sequel to p5play) when it's used with p5 v2. |
|
Hello, everyone! Short update this time:
I've also updated the timeline to make a bit more space to finish ongoing documentation update effort for p5.js 2.0, for the next week or so. I will keep posting here as we get closer to release. While that's in progress, we've also been working on the compatibility resources so please feel free to check those out! Regarding the
On discussing it, we also considered the downsides of having an feature that is supported but not documented (how can a learner look it up? If you look it up, does the learner then get stuck in 1.x reference?) and as a result creating a problem for it in the future. I think this is. the main challenge with this proposal, so if someone has thoughts on "subtle features" (especially ones that affect the very first exposure that a learner has to the language) it would be good to weigh in. It would be great if educators are able to keep using 1.x for the time being in teaching but try out 2.0 when it's available, so that we can have a wider community testing period and iteration before the 2025 autumn term kicks off. If the absence of *Here's an example of making the new p5.sound.js add-on library compatible with both 1.x and 2.x0 |
|
@ksen0 Documenting the preload system would be preferable, yeah. 😅 To try to get some other perspectives, I went back and read other comments about the removal of the preload system, but it seems there's been unanimous backlash against it from people not directly involved with p5 v2's development. Granted, maybe the survey responses were more varied so I'm not getting the full picture. But why might this be? Are we just a vocal minority? We're stubborn when it comes to big changes like this? I think I'm the kind of person that likes making big changes. I'm about to make quite a few of them in q5play. For example, I now consider the Kit, you've adequately explained the benefits of the new async setup way, but is preload really so bad that it needs to be removed? Keeping the documentation for it would require a little more work sure, but think of the wealth of resources that are being made somewhat obsolete by these changes. Is there something inherently wrong with handling asynchronous loading behind the scenes for users? To me it's strange to have a library that does so much to simplify the user experience, but draws the line at this. And Kit you've shown it can be implemented with Promises in the compatibility addon, so the only difference is on the user end. I agree that providing an opportunity to teach Sorry for going in circles a bit here. While I'm interested in your response, I won't push on this further. Anyways, it's great to see an example of how addons can be compatible with p5 v1 and p5 v2 regarding preload methods. Thanks! |
|
@ksen0 following up on my question about accessibility. Are there any plans for changes focused on improving accessibility from #6992 and/or beyond? Since it sounds like some folks may be sticking with v1, I think it would be ideal to include those changes in both v1 and v2 so that no one is missing out on accessibility. If you do decide to deprecate textOutput() and gridOutput(), you could add a warning in v1 and remove them entirely in v2. |
|
Hi @calebfoss ! Thanks so much for raising this, I'll try to go through these point by point:
These do remain in v2: https://github.com/processing/p5.js/tree/dev-2.0/src/accessibility Because #6992 section on "Keeping textOutput() and gridOutput()" is additive as far as I can tell, I think this is an issue that can be taken on once 2.0 is live. I agree that those specific ideas "are a lot of work for features that would only improve accessibility in very limited situations," and I think taking a step back and considering if there are other features that would have a wider reach and/or be less work. That's not to say popularity or reach alone determine the features that are prioritized; by definition, access-first prioritization can't rely on popularity alone. But because I am not myself an expert on web accessibility or adaptive technology, I would like to facilitate a more participatory approach to identifying and prioritizing possible features. I am working within the Processing Foundation to map out a path - including a budget - for this. The object descriptions in the #6992 proposal is one possible feature - it seems really promising, but given the limitations of my own experience and knowledge, I am strongly inclined to try to do more formative research as well as consider suggestions from established contributors like you. Over the past few months, here's what I've been thinking about. The survey and community conversations were a part of investigating how to make contribution more welcoming. It seems that new contributors would be very excited to do something to help with accessibility and multi-language support, but it's hard to get started. Even before new language or website features, enabling better maintenance would be important (for example, after reading your proposal I noticed some of the translations have outdated links). I think a little bit of automation here might be helpful, but at its best, I hope that more beginner-friendly maintenance tools/practices around both a11y and i18n can make these values more central. In your proposal, I appreciated your comments advising against AI-generated descriptions and automations of accessibility tasks, and I agreed with your reasoning, especially on the conclusion to focus "on encouraging creators to describe their sketches effectively and to provide good resources to do so." I'm happy to hear your thoughts about this approach (participatory design / research to determine concrete features, focusing on enabling resources/protocols/practices for improving web accessibility of sketches). OK so switching gears a bit here - @quinton-ashley, I'll focus just on this bit for now:
The responses I got overall were really interesting. From both survey and conversations, it seemed like there wasn't so much awareness of 2.0 (about 50:50). Many people were neutral about preload/promises, and quite a few were really positive (including, but not exclusively, those contributors already working on 2.0), so that has informed the approach I described in previous comments:
While there are some different opinions, I do feel quite confident in saying that many people who are affected by p5.js decision making are not on GitHub, and possibly also not on the Processing Foundation social media / newsletter / etc. So if that decision-making is happening in GitHub threads alone, then it may not represent the full range of ideas and needs in the community as a whole. That's why I'm trying to (1) be as transparent and available as I know how to be, and (2) make p5.js 2.0 more present on more platforms. That includes making p5.js 2.0 available - as a complete release, with (optional for over a year) onboarding in the p5.js Editor - for testing and input by a much wider part of the community. I hope that gives a bit of an idea of how I'm approaching these topics. Suggestions welcome! |
|
Thanks @calebfoss for your detailed write-up in #6992! I'll add a couple points here that may be relevant to your discussion with @ksen0 about these features. I'm sharing them on the current issue because I'd also like to discuss some more general points regarding p5 development. Use of shape objects for accessibilityThe application of shape objects to accessibility (proposed in #6992) is really interesting! As part of the custom-shape overhaul that we did for 2.0, we actually created a Since hit testing was mentioned as a possible application of this object-oriented approach, I'll just mention briefly that there's one interesting technique that we might want to consider. It involves using what's called a "hit graph" in Konva.js.2 The implementation seems relatively simple, and it also appears to be quite performant. Although there may be edge cases and some nuances, the basic idea is simple. Everything is drawn in a hidden graphics buffer like In general, if anyone in this discussion ends up working on hit detection, please let me know! Some time ago, I spent a while investigating different approaches, and I'd love to share what I learned. AII think it may be worth revisiting AI at some point in the future. To be clear, my sense is that there are still serious, legitimate concerns about general usage of AI. On the other hand, with respect to immediate impacts on educational uses, the pitfalls we need to worry about have changed since #6992 was posted. And there are potentially huge upsides. As a user-friendly debugger, AI can be really helpful for beginners (as I've seen in my own teaching). More broadly, we now have applications such as Khan Academy's AI tutor Khanmigo (this existed at the time of your comments in #6992, but it hadn't been out as long). Khanmigo has a much wider scope than p5 would likely need, but it illustrates some of the possibilities. Sal Khan's book Brave New Words: How AI Will Revolutionize Education (and Why That's a Good Thing) discusses Khanmigo specifically, and it provides a positive perspective on AI in education more generally. Whether or not we agree with the book's conclusions, one of the takeaways is that, while AI raises serious concerns, it also needs to be compared to the status quo. Right now, accessing interactive instruction on creative coding is mostly limited to students who can afford an education at a limited number of institutions. AI brings with it the potential to provide nearly universal access to a one-on-one, creative-coding tutor. More modestly, AI might be used to provide accessible descriptions of p5.js sketches that are interactive, allowing users to ask questions when anything is unclear. It might also allow universal access to an interactive version of FES, allowing users to ask follow-up questions. To reiterate what I wrote at the top, I do not think that the costs and potential harms of AI should be ignored. My intent here is to suggest that a lot more community discussion on AI would likely be helpful. In particular, it'd be helpful to have such discussions before investing in any potentially large efforts, such as improving certain aspects of p5's accessibility features. As @calebfoss noted, it may make sense to remove some of these features in the long run; being thoughtful about the possible inclusion of AI might prevent currently developed features from suffering the same fate. Edit: Added a note about hit testing. Footnotes
|
@ksen0 That makes sense, but I would argue that the alternative is already in p5: describe() and describeElement(). Across textOutput(), gridOutput(), and AI, I would condense my main arguments against as:
I am glad to hear that you are looking into an accessibility-focused project with a budget in the future. In May 2024, however, @Qianqianye told me that new accessibility features, informed by my proposal, were a priority for p5 2.0 and that a budget and timeline would be worked out in June 2024. In general, I would really like to see this project make good on its 2019 promise to focus on accessibility and inclusion. In the area of inclusion, I pointed out in this comment last month that the Form Elements example on the new website credits the project leadership team and Processing Foundation staff but does not credit the Black woman who originally contributed the example (Prof WM Harris) as the old site did. That problem persists, but PR 779 was merged into the website repo's 2.0 branch today, modifying the examples to use p5 2.0. p5 is a huge project with lots to juggle, and I understand that there are lots of factors to consider. Moments like that, however, make me worried about what is getting prioritized. I want big changes like the new website and v2 to reflect what makes this community so great: its values on making creative coding a more accessible and inclusive space. |
|
I also wanted to mention another thought that came up about my proposal in #6992 for detecting issues pertaining to WCAG 2.3.2. It occurred to me that shaders may be a possible route to efficiently calculate differences in luminosity. Not sure about specifics (sending 2D canvas graphics through shaders may have its own performance issues?), but this sounds like the kind of thing @davepagurek would have some great insights on. Btw @davepagurek, the new textToModel method on fonts is a super awesome feature that I think will get a ton of use. |
|
@calebfoss I think shaders can help power something like that! if we take a snapshot of the frame before moving on to the next one, we can compare with the previous frame's snapshot and see if the luminosity changed by a certain amount. Some notes:
edit: Also, we have a new addon api that should make it easier for us to register a post-draw hook like that! |
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 help 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: #7261
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 as you try out the beta release!
Timeline
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:
Changes
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.
Compatibility add-on libraries
We've prepared add-on libraries for backwards-compatibility between 1.x and 2.0. That repository also contains guides on updating your own sketches and libraries to p5.js 2.0 - so do check it out, try it out, and share what you think to help us improve!
The text was updated successfully, but these errors were encountered: