Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[p5.js 2.0 RFC Proposal]: Pruning #7090

Open
3 of 21 tasks
nickmcintyre opened this issue Jun 8, 2024 · 2 comments
Open
3 of 21 tasks

[p5.js 2.0 RFC Proposal]: Pruning #7090

nickmcintyre opened this issue Jun 8, 2024 · 2 comments
Assignees
@Qianqianye
Labels
p5.js 2.0

Comments

@nickmcintyre
Copy link
Member

nickmcintyre commented Jun 8, 2024 •
edited

Increasing access

My sense is that this proposal affects maintainability and sustainability more than accessibility. That said, a smaller, more focused core library could be viewed as more accessible to beginners and contributors because there are fewer moving/interrelated parts.

Which types of changes would be made?

  • Breaking change (Add-on libraries or sketches will work differently even if their code stays the same.)
  • Systemic change (Many features or contributor workflows will be affected.)
  • Overdue change (Modifications will be made that have been desirable for a long time.)
  • Unsure (The community can help to determine the type of change.)

Most appropriate sub-area of p5.js?

  • Accessibility
  • Color
  • Core/Environment/Rendering
  • Data
  • DOM
  • Events
  • Image
  • IO
  • Math
  • Typography
  • Utilities
  • WebGL
  • Build process
  • Unit testing
  • Internationalization
  • Friendly errors
  • Other (specify if possible)

What's the problem?

Many classes and functions aren't used widely, if at all. Others were ported directly from Processing and may no longer be needed given all the goodies in modern JavaScript. And a few are broken.

What's the solution?

Prune the following classes and functions. Maybe add some tutorials on data wrangling with arrays and objects.

Data

Events

The entire Acceleration section is broken on iOS without a workaround, so I suggest removing it.

IO

Pros (updated based on community comments)

Example list:

  • Consistency: TBD
  • Readability: TBD

Cons (updated based on community comments)

TBD

Proposal status

Under review
@Qianqianye Qianqianye self-assigned this Jun 18, 2024
@limzykenneth
Copy link
Member

@nickmcintyre Just want to note that I am thinking about pruning many of the things you listed as well (particularly those that thinly wrap JS functions and p5.Table). I wouldn't necessarily remove the mobile events if at all possible and I would still keep the IO loading and http functions as they have their uses, perhaps with some API updates.

Some idea around whether people are using p5.Table for example can greatly help with decision making here.

@davepagurek
Copy link
Contributor

One other WebGL feature that may be able to be pruned is the perPixelLighting property in setAttributes. Turning it off means lighting is only calculated per vertex, then interpolated across faces, for performance or a retro look. I was trying to survey people to see if anyone uses it or knew it existed and it doesn't seem to get much use. I'm open to still including it because it isn't a huge deal, but it feels like maybe something that could be better served by a custom shader provided in a library.

@nickmcintyre nickmcintyre mentioned this issue Jun 20, 2024
Closed
21 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Qianqianye Qianqianye

Labels
p5.js 2.0
Projects
p5.js 2.0
Status: Proposal
Milestone
No milestone
Development

No branches or pull requests
4 participants
@nickmcintyre @davepagurek @limzykenneth @Qianqianye