[p5.js 2.0 RFC Proposal]: Pruning

[nickmcintyre]

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

• createStringDict()
• createNumberDict()
• p5.TypedDict
• p5.NumberDict
• append()
• arrayCopy()
• concat()
• reverse()
• shorten()
• sort()
• splice()
• subset()

Events

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

IO

• loadTable()
• loadBytes()
• httpGet()
• httpPost()
• httpDo()
• save()
• saveTable()
• p5.Table
• p5.TableRow

Pros (updated based on community comments)

Example list:

• Consistency: TBD
• Readability: TBD

Cons (updated based on community comments)

TBD

Proposal status

Under review

[limzykenneth]

@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]

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.

[davepagurek]

@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]

@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:

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).

[limzykenneth]

@GregStanton @ksen0 Is putting together something to collect community comments about p5.Table and other pruning related things above more generally and outside of GitHub to collect more diverse data. We can make a decision about it after that and it's not in a hurry since it is relatively trivial to remove a feature.

p5.Table even if removed can live on as a community maintained addon library so if there are things that depend on it, it should be relatively easy to have it around still.

[isohedral]

I found this thread after encountering some surprising p5.Table behaviour, and figured I'd comment. I'm not surprised that this functionality is being considered for removal—it's clearly not one of the most valued parts of the library. On the other hand I say that with some regret. I'm presently writing a lesson about p5.Table for an intro programming course. I think there's some value in learning to work with tabular data, particularly for students who might be interested in using P5.js for data visualization. So at the very least I'd hope it could live on as an add-on, as @limzykenneth suggests.

[Let me mention the surprising behaviour, for the record. The method p5.TableRow.getNum() throws an exception if the value in the table isn't a number. In my test sketch (which I tried on editor.p5.js), that exception then gets silently absorbed, leaving me with no information about what I did wrong. Based on past experience with P5.js I'd have expected a visible error message in the editor's console. Hope it's OK to include this here—I'm not 100% sure this deserves to be a separate issue report.]

[isohedral]

...And for the record I agree with @nickmcintyre's list of the many vestigial functions left over from Processing that simply aren't needed in P5.js. (There are some that I know could be deleted immediately, and others that I'd have to learn more about first.)

[ksen0]

Closing this one as complete for 2.0!

The community feedback mentioned above has a writeup about it here and p5.Table related API has been marked for later removal but was kept in 2.0, as there is not yet an alternative. Potentially HTML tables might be a way forward, and is currently in a discussion and design stage.