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