Great points, Matei! I agree with you about the global variables being an issue, which can lead to weird unforeseen errors.
That said, I still think p5 is great. After playing with the vanilla JS web-canvas API, I find myself reinventing the wheel a lot. Depending on use case, and especially with generative art, I find p5 to be more than sufficient, unless I go crazy with WebGL and the p5.sound library.
I'd go so far as to claim p5 is made for expression, whereas the native API is made for production (people who are very familiar with the API and need very performant projects).
Finally, there are a lot of optimizations p5 makes under the hood that a developer may end up overlooking (for example: creating 100s of circles instead of copying one instance)
I also find myself reinventing the wheel a lot. If I'd want to build something bigger I'd go with something high level like pixi (or if you want something super low level but still nice you can take a look at picogl)
I think the optimizations are really easy to miss, the best examples beeing those 2 quick doodles I linked in the original comment
Yes, it's cool for generative art where you just want to take a screenshot of the final thing, but if you want something real time you might need to rewrite it in vanilla js (or another lib)
Again, i think it's a tool with an amazing educational value, but that comes at the cost of it not beeing the right tool for more advamced stuff
Have you disabled the friendly error system? According to the docs, it can degrade performance up to 10x. I don't think it's included in the minified version so you don't have to disable it in that case.
I've used p5 a lot for a fairly wide range of project sizes, largest being about 2-3k lines. It definitely got some major downsides. The use of globals my biggest gripe for large projects and testing. Some of the p5 libraries, the p5.sound especially, are horrible with performance, at least with what I was doing.
That being said, the API for p5 is excellent. Since it is based on Processing, the ease of use has been thought through extensively. I definitely don't think I would ever want to use vanilla canvas API. I think the Processing foundations mission of making a library accessible for artists and designers fits perfectly with p5.
Everything you said though is spot on. In the end, it's all about trade-offs.
Cameren, I agree wholeheartedly about the issue with globals! Have you got a chance to play around with p5 instance mode [p5js.org/examples/instance-mode-in...]? It helps somewhat with this issue.
Yes, I have used instance mode. My P5-Electon Quickstart Template uses p5 instance mode. It definitely solves the problem of globals, but at the cost of readability p.ellipse vs just ellipse. While it is pretty much required in order to build a well structured application, something about it just feels not in the spirit of p5.
Overall, for a vast majority of projects made with p5, I think instance mode is not necessary. Globals really don't matter when you're quickly iterating and building a cool art piece with a code base you are not going to maintain.
I think that reduces the problem by a little bit, but you are still mutating the variables scoped to the main function. Atm i dont think theres any actual functional way
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I hate p5.js. Why you might ask?
I get why it's neat for beginners, but I wouldn't recommend it to anyone who understands vanilla js.
Great points, Matei! I agree with you about the global variables being an issue, which can lead to weird unforeseen errors.
That said, I still think p5 is great. After playing with the vanilla JS web-canvas API, I find myself reinventing the wheel a lot. Depending on use case, and especially with generative art, I find p5 to be more than sufficient, unless I go crazy with WebGL and the p5.sound library.
I'd go so far as to claim p5 is made for expression, whereas the native API is made for production (people who are very familiar with the API and need very performant projects).
Finally, there are a lot of optimizations p5 makes under the hood that a developer may end up overlooking (for example: creating 100s of circles instead of copying one instance)
edit: very cool galaxy map btw!
You hit some great points!
Again, i think it's a tool with an amazing educational value, but that comes at the cost of it not beeing the right tool for more advamced stuff
Have you disabled the friendly error system? According to the docs, it can degrade performance up to 10x. I don't think it's included in the minified version so you don't have to disable it in that case.
p5js.org/reference/#/p5/disableFri...
I've used p5 a lot for a fairly wide range of project sizes, largest being about 2-3k lines. It definitely got some major downsides. The use of globals my biggest gripe for large projects and testing. Some of the p5 libraries, the p5.sound especially, are horrible with performance, at least with what I was doing.
That being said, the API for p5 is excellent. Since it is based on Processing, the ease of use has been thought through extensively. I definitely don't think I would ever want to use vanilla canvas API. I think the Processing foundations mission of making a library accessible for artists and designers fits perfectly with p5.
Everything you said though is spot on. In the end, it's all about trade-offs.
Cameren, I agree wholeheartedly about the issue with globals! Have you got a chance to play around with p5 instance mode [p5js.org/examples/instance-mode-in...]? It helps somewhat with this issue.
Yes, I have used instance mode. My P5-Electon Quickstart Template uses p5 instance mode. It definitely solves the problem of globals, but at the cost of readability
p.ellipsevs justellipse. While it is pretty much required in order to build a well structured application, something about it just feels not in the spirit of p5.Overall, for a vast majority of projects made with p5, I think instance mode is not necessary. Globals really don't matter when you're quickly iterating and building a cool art piece with a code base you are not going to maintain.
I think that reduces the problem by a little bit, but you are still mutating the variables scoped to the main function. Atm i dont think theres any actual functional way