P5.js: Migrate P5.dom into core library

[workergnome]

In talking with @lmccart, it seems to make sense to move the p5.dom code into its own repo, much like p5.Sound currently is.

[therewasaguy]

After some conversations here at p5 contributors conference with @workergnome @lmccart @sarahgp @antiboredom, we're changing course to incorporate p5.dom into the core library.

I think this is the way to go because p5.dom is a big part of what makes p5.js unique compared to other drawing libraries. It not only offers access to the dom, but html5 audio/video and a/v input. It's the web part of "Processing reimagined for the web." And it's only 32kb unminified.

If anyone feels it's better to keep p5.dom as an addon, feel free to chime in. For now I'm modifying the issue name and we're hoping to work on this later in the week.

[workergnome]

:+1:

[lmccart]

this will involve:

• [ ] migrating p5 methods into somewhere? pend: wait for devops discussion about file restructuring
• [ ] migrate p5.Element methods into p5.Element file
• [ ] break out new p5.MediaElement file
• [ ] rebuild documentation
• [ ] remove p5.dom from libraries page, and other mentions through library
• [ ] update GSwp5.js book to remove references to p5.dom as "library"

[shiffman]

I love this decision!

[workergnome]

Hey, @lmccart—are we holding off on this? @futuremarc: Are you working on this?

Right now, as part of #774, the p5.dom.js file is going to be the only thing remaining in the lib directory. Not a huge issue, but an inconsistency that we should address.

[futuremarc]

Actually, I think @lmccart said she wanted to do this one.

[lmccart]

I think #794 relates to this issue as well. I haven't merged p5.dom into the core yet as I had some concerns and I was wondering if others might weigh in on what they think is best. One of the main arguments in favor of this is outlined by @therewasaguy above, and I think this is a strong point. However, my main questions are these:

• Would merging this into core now limit the experimental nature of it that might be necessary as we figure out the optimal API for this module?
• Do the global states with functions such as colorMode(), angleMode(), push(), and pop() feel too confusing if p5.dom elements are considered core? Currently these functions apply only to canvas drawing and do not apply to other html elements created with p5.dom.
  
  
  
  • In some cases, like angleMode(), it would seem very nonintuitive to have CSS follow the angle mode when the default for canvas is radians and the default for CSS is generally degrees.
  
  
• Are the capabilities and defaults of HTML5 beyond canvas so varying across browsers and devices that it would be hard to maintain a consistently functional experience? As an addon, it seems we have a little more freedom for some things to not work or work differently depending on environment. Whereas I think we are aiming with core functionality to support most common, modern browsers across devices?

Thoughts? :)

[workergnome]

Personally, I don't think I would ever use this—jQuery is just too good at doing what it does, and this feels like a less-powerful version of jQuery.

I could be convinced that a very minimal set of DOM manipulation tools were useful for teaching, but in general, the functions that we're using are native to Javascript, and there already exist very good abstractions over them.

However, I'm coming from a web background—I know what this is doing, and how to use it, and what alternatives exist for this. Other people from other backgrounds might disagree.

[sarahgp]

So, I do think there is value in having basic DOM functionality as part of p5 core.

When people first start learning web development, it can seem like each little step one wants to take involves understanding _another_ whole set of tools. I've felt that frustration and heard it voiced by others — and so having basic buttons, etc. as part of the core to me makes p5 much more beginner-friendly. jQuery isn't _hard_, but it can be "another-effing-thing-to-understand!" and easing that would sure be a great thing we could do.

Likewise, even experienced web folks can be loath to load up another library; p5.dom is a lot smaller than jQuery.

This might mean that as a future direction for p5.dom, we focus on lightweight things that are less about recreating bigger DOM manipulation libraries, but I think it makes sense to have some.

My :moneybag: :moneybag:.

[kadamwhite]

@sarahgp Well said. In my head I've been imagining that there's a line we could draw, where we provide basic functionality that gets people going and solves a basic set of use cases—as this is the web, there's always a more-comprehensive tool available that can be added in as needed but I agree that having enough for learners to get their feet wet is important. I just think it's also important to regularly assess where we draw that line, and what functionality we want to provide, because for every additional piece of scope we agree to maintain, that's another set of browser quirks, documentation, learning material, etc, much of which duplicates work that _has_ been done by jQuery et al.

The educators in this conversation can probably articulate how to draw that line between "useful for getting started" and "excessively overlapping with more complex tools" better than I ever could!

[shiffman]

This is terrific discussion. For me, I come from the opposite direction as @workergnome. I came to p5.js from years of working on Processing, and with very little HTML/CSS/JS experience. The scope and relevance of p5.dom is something I think (and hope!) we always be discussing. These points resonate strongly with me and are important to consider:

• p5.dom is likely not useful for an experienced web developer already well-versed in more advanced and powerful tools.
• p5.dom is walking a very strange line of re-implementing features available in native JS and other ubiquitous frameworks like JQuery. Why?

The bigger picture of p5.dom I'm not sure what to say about. But I can say that I see tremendous value in p5.dom in my local context of the intro "creative coding" courses I teach. I'm not sure whether it would be useful in a proper web development course. (Does such a thing exist?) But it's exactly what I am looking for to enable students to "sketch" for the web while learning to program for the first time, in a singular environment thoughtfully designed for a beginner. Key principles I think for us to keep in mind are:

• A small, concise API.
• Stay true to the friendly, accessible style of p5.js canvas.
• It's really about documentation and examples.
• Stay true to the native web b/c ultimately p5.dom isn't the end, it's the beginning.

I think @lmccart points about leaving p5.dom as a separate file are good ones; there are considerations in terms of development / maintenance to consider. However, I do think that p5.dom is _core_ to the being of p5.js whether it lives alongside canvas or not. p5.dom is what allows p5.js to be a tool that enables learning beyond just programming in the context of drawing.

All this said, I might just be completely wrong and will have plenty more to say I'm sure after we try teaching this stuff in the fall!

[futuremarc]

Sure p5.dom as an educational tool is great, but I also believe it's important b/c we should ultimately be encouraging the browser's full capabilities for creative coding experiments.

I think being able to quickly access the DOM with our library and do easy, intuitive, Processing-like behavior with it is really powerful during creative coding experiments. And things like positioning and sizing are 100x more intuitive since its Processing based than normal CSS would be. Its been proving a lot of fun to be able to do 2d and 3d transforms in the p5 way of doing things.

And just like if someone wanted to dive deeper into web audio they'd look to another library, they'd do the same if they want more powerful dom manipulation.

That said, I am not so sure about migrating DOM into core for the reasons @lmccart brings up about promising a consistent functional experience, though I don't think things like pop() and angleMode() being too confusing if merged are much of a concern if we document the DOM functionality well enough

[workergnome]

I really like the training wheels concept that @sarahgp and @shiffman are talking about. I've run into the teaching problem as well, where you _really_ want to show someone how to use a checkbox, but you don't want to teach them jQuery just to use a tiny part of it. But, mostly I like the idea of it being a stepping stone to using the native capabilities of the browser—training wheels, not a re-invention of how to access and manipulate the DOM in software.

@futuremarc, I agree with you that it would be wonderful to try and extend this to capture the full capabilities of the web, but I am really worried about our ability to maintain and support something of that scale. We're probably clever enough to write it, but I don't know that we have a sufficient community to support yet another API for DOM manipulation—and we'd have to figure out what we have that's _significantly_ better than what exists already in jQuery. I've done just enough of it to know that there's an enormous amount of cleverness in things like jQuery—and even using CSS animations correctly takes a good bit of thought, and a really complete understanding of how all of the various browsers optimize for DOM reflowing.

I think deciding what the p5.DOM library is training wheels _for_ is an important consideration. the three models of DOM manipulation I am familiar with are d3, jQuery, and the native browser implementation. I think that, much like the d3 examples that Alex was working on, jQuery is an external library and that we should limit our movement towards that to examples and tutorials. I think that providing a p5-ish gloss on the native browser implementations, with some sort of pointer towards what we're hiding and how you could do it on your own would be helpful.

A little bit of magic, but just enough to make teaching easy and to give you a pointer towards what's behind the curtain.

[futuremarc]

I mean I definitely agree about the training wheels, I just mean we should be considering what would be useful for artists when we consider the scope of the DOM library.

[brysonian]

I like @workergnome's comment that we need to think of what the wheels are for, in the same vein it would be nice if the edges of the implementation are clear, so that when someone outgrows it they know that, and don't waste a bunch of energy hacking at something that could be done more easily with another tool. We don't want anyone trying to ride a race with the training wheels still on.

On another note, is it worth considering just integrating something like sizzle or qwery as our selector engine and sidestep the problems of upkeep and testing? We do that now with reqwest and ajax and maybe it is a good move here as well? No need to reinvent the wheel, especially when we all seem to agree that the current wheel is pretty darn good.

[workergnome]

Now that's a _good_ idea. I love the idea of wrapping p5.DOM around sizzle, and noting that it's the same query engine that powers jQuery. It teaches people about CSS selectors, it gives them training wheels for jQuery, and it means that the issues of support and performance are not ours.

[futuremarc]

Pretty cool idea!

[kadamwhite]

Sizzle is not a tiny lib—I know file size isn't a priority for us (we'll always prioritize making a learnable API and keeping the code legible), but I feel I'd be remiss not to point out the file size bump. Not saying it isn't worth it, though :) we just owe it to ourselves to be aware of what weight we bring in when we do this, because library load time is a component of user experience too.

[brysonian]

For sure. It is 19k minified which is pretty substantial. It might be a case for keeping it as a separate addon, or looking into another option like qwery. (On the topic of size though, opentype is +80k minified, and might also be a candidate for spinning off into a module.)

[workergnome]

I would go Sizzle over qwery—we're not super-worried about file size, and as far as training wheels go, I think it's a better one.

I don't care at all about separate library vs. core—this bug started out as extracting it from the main repo, and has gone back and forth between include vs. separate repo. I just don't really want it hanging out, not a core part of the project, but in the repo.

[lmccart]

Thanks everyone for your thoughtful perspectives! It sounds like there is more feeling that it should be part of the core. @sarahgp's point about not having to learn how to add another thing to get the functionality as a beginning resonated with me a lot. A corollary of this is that we should continue to revisit the boundary of p5.dom and always aim for a sweet "just enough" to get you rolling spot. After which point you could move on to another library.

I believe it's an eventual goal that you are able to select modules and build your own lib so this would resolve issues around large files incorporated into specific modules. I haven't thought about sizzle enough to comment on that, but I think that's best resolved in another more relevant thread. I'll start working to integrated p5.dom into core.

[kadamwhite]

@lmccart Sounds great! I opened #800 to discuss Sizzle specifically, so that we can sidebar that discussion.

[lmccart]

It's been a couple years on this one. My current feeling is that it has continued to make sense to keep p5.dom separate.. it allows for smaller file size and more experimentation with the p5.dom API. I'm going to close this for now, we can revisit if someone wants to reopen the issue at a later point.

[lmccart]

Ok we're opening this again. cc @outofambit

[limzykenneth]

There's a bit of a gap between the last conversationa and the reopening of this issue, I'm just curious that are we planning to break out p5.dom.js to its own repo or are we merging it into core?

[outofambit]

hi @limzykenneth ! i'm going to pull p5.dom into core!

[shiffman]

Woohoo!

[outofambit]

planning to do this later this week after #3758 is done! 🚀

[montoyamoraga]

@outofambit @lmccart i was trying to figure out if this already happened? so exciting!
if so, can we close this issue?

[outofambit]

@montoyamoraga it did! in https://github.com/processing/p5.js/pull/3922! closing this issue! 🎉

[amzon-ex]

hi @limzykenneth ! i'm going to pull p5.dom into core!

Sorry, I'm new to p5 and just scaling the learning curve. Does this comment mean that the p5.dom library has been integrated into the main p5 library? That is, just downloading the main p5.js file would serve all purpose? Thanks.

[limzykenneth]

@amzon-ex Yes, the DOM library has been merged into the core library, meaning any functionalities previously requiring p5.dom.js are all included directly in p5.js. If you have further questions, feel free to ask on the forum. Thanks!