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.

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

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

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

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

nickmcintyre opened this issue Jun 8, 2024 · 4 comments
Assignees

Comments

@nickmcintyre
Copy link
Member

nickmcintyre commented Jun 8, 2024

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

@limzykenneth limzykenneth moved this to Proposal in p5.js 2.0 Jun 11, 2024
@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.

@Qianqianye Qianqianye moved this from Proposal to Implementation in p5.js 2.0 Sep 10, 2024
@davepagurek
Copy link
Contributor

@GregStanton pointed out that we have both curveDetail() and bezierDetail(), and those affect curve() and bezier() respectively. It might make sense to consolidate these into just one detail that applies a sampling density to all curves, especially since in 2.0 this will apply to curves and beziers in beginShape()/endShape() too.

@GregStanton
Copy link
Collaborator

@nickmcintyre and @limzykenneth: Any updates on whether p5.Table will be removed? Here's an old GitHub comment I made about one use case. Basically, it can be useful to render tables directly on the canvas, e.g. when a table needs to be shown or interacted with alongside a graph that's drawn on the canvas. A class like p5.Table could be a starting point for that kind of functionality, but I'm not sure if the current p5.Table API is the most accessible option.

Back when I was using ProcessingJS, I made a library that could render tables in the canvas, for math-education purposes. It had a number of features including custom styling. A minimal example is below.

Table:
Simple Table Example

Code:

//create table
beginTable("rows"); //data interpreted as rows
tableData("x", -2, -1, 0, 1, 2);
tableData("y", 4, 1, 0, 1, 4);
endTable();

//set (X, Y) position of table's top left corner
setTablePosition(20, 100);

//draw table
drawTable();

On the one hand, p5.Table might've saved me some time. On the other hand, the API for p5.Table might've been too confusing for my audience. Based on a quick glance, here are a few possible sources of difficulty:

  • To create a table row from scratch, it's necessary to specify the row by calling the constructor directly and passing a string to it, rather than passing in values as separate arguments or an array.
  • There's a general setter for setting an entry in a table, as well as setters that are specifically for numbers or for strings, leaving users to wonder when they should use one or the other.
  • Rows and columns aren't treated symmetrically, which may lead to unnecessary complications (see this question on Stack Overflow about HTML tables for an example of such a complication). It seems common for table APIs to be based on rows specifically, but I'm not sure why.

Maybe it'd make sense to remove p5.Table for now if it doesn't seem to be used much, and add-ons can potentially experiment with different APIs if there's demand? For example, I'd probably want a different table API for Mathemagical (a p5 add-on meant as an upgrade to my old library).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Implementation
Development

No branches or pull requests

6 participants