Distribute Treeshakable ESM code

[b12f]

Nature of issue?

• [ ] Found a bug
• [ ] Existing feature enhancement
• [x] New feature request

Most appropriate sub-area of p5.js?

• [ ] Color
• [ ] Core/Environment/Rendering
• [ ] Data
• [ ] Events
• [ ] Image
• [ ] IO
• [ ] Math
• [ ] Typography
• [ ] Utilities
• [ ] WebGL
• [x] Other (specify if possible)

New feature details:

The NPM p5 module currently ships a file that bundles all code into the commonjs format. This prevents treeshaking of unused code. Since the code itself is already written with the import/export syntax, distributing a treeshakable version should be as easy as providing a module key in the package.json and including the raw source, e.g. under p5/lib/esm/color or maybe even p5/color

[welcome[bot]]

Welcome! 👋 Thanks for opening your first issue here! And to ensure the community is able to respond to your issue, be sure to follow the issue template if you haven't already.

[limzykenneth]

I think it is interesting to explore this but I think there may be too much side effects in the library for it to be able to be used effectively. I'm not sure though.

[b12f]

Yeah, at first I thought this would be easy, but after looking at the code it seems a bit harder. It should be possible however to ship the current esm code with a special sketch wrapper, and then a second wrapper for the cjs format, keeping all else the same.

[b12f]

The most immediate change would be to remove all usages of a direct import 'filename.js', and only import { whatever, is, being, used } from 'filename.js'

[limzykenneth]

The most immediate change would be to remove all usages of a direct import 'filename.js', and only import { whatever, is, being, used } from 'filename.js'

I think that's a good first step.

[lmccart]

thanks @b12f. we're not able to prioritize this format right now but perhaps can revisit at a future date.

[CarstenHoyer]

@lmccart - It's been a year. Perhaps it could be prioritized now? I would be interested in putting some work into it.

In my mind, I think we would need a esm-init.js, that would abandon the global p5 instance approach.

I think this would be wortwhile, because it:

• would make the code tree shakeable
• Would make p5 more usable in other libraries
• make the bundle size for other modules smaller - ie a react renderer.

[huumpf]

@lmccart I'd really love to seeing this happening as well!

I'm one of those guys who p5 probably was made for. I'm a Designer/Visual Artist who's not really good enough in coding to contribute to the library itself but I'm loving p5 for what value and fun it brings me – even with my limited coding-skills!

I've actually had a couple projects and moments, where I would have loved to contribute to production-code for websites etc. – Sadly it never happened bc the "real" devs refused to implement the complete giant library that is p5 (which btw. totally makes sense to me at this point).

If there would be any way for people like me to realistically make use of the creative coding part in an actual public web-project, I would love you guys even more than I do already :-)

[limzykenneth]

@huumpf You can open a new issue and fill in the relevant issue template, particularly the question about accessibility. Thanks.

[huumpf]

@limzykenneth would that be your preffered way of addressing this topic (again) or give it more visibility? I thought sticking to an existing thread and just +1ing it would be way to go to avoid "this has already been discussed in #xyz".

Anyway, I'm happy to do whatever is helpful. Tbh i could probably not think of a better way to phrase it than i've already done above. Also, I'm not sure what you mean with "question about accessibility".

[limzykenneth]

@huumpf I would suggest opening a new issue to avoid pinging people who were previously in this thread but no longer want to be notified about this activity. Also we have new requirements for accepting new features which is reflected in an updated issue template that need to be filled in.

In short the access requirement boils down to we will only accept feature requests that increases access, it does explain much on its own but do read more here, which means that for this particular feature, an argument for how it increases access of p5.js for people who may be excluded from the technology or p5.js community.

[davidbwaters]

@lmccart I'd really love to seeing this happening as well!

I'm one of those guys who p5 probably was made for. I'm a Designer/Visual Artist who's not really good enough in coding to contribute to the library itself but I'm loving p5 for what value and fun it brings me – even with my limited coding-skills!

I've actually had a couple projects and moments, where I would have loved to contribute to production-code for websites etc. – Sadly it never happened bc the "real" devs refused to implement the complete giant library that is p5 (which btw. totally makes sense to me at this point).

If there would be any way for people like me to realistically make use of the creative coding part in an actual public web-project, I would love you guys even more than I do already :-)

Just FYI, I'm in the same boat and found https://github.com/LingDong-/q5xjs. It doesn't include 3d (yet), but might be useful in this situation.

[davidbwaters]

And generally speaking, lowering the bundle size directly increases accessibility in areas where bandwidth and internet connection speeds are an issue. China seems to be a region affected by this and p5 seems to be popular with Chinese devs based on some cool demos I've seen on Twitter (search for p5 and you'll see a bunch). So as far as being good for the community and accessibility, it seems like a win. Also, ESM is a web standard and isn't going anywhere. Being able to optimize loading would offer the best experience for running processing in a browser.