Support static mode

[sofian]

NOTE: This feature request was imported from P5.js

The P5.js editor does not currently support "static" mode which allows sketches that do not contain functions setup() and draw() to work.

Static mode is an interesting feature when introducing students to Processing. I wonder if it would even be possible to make it work but I'd be happy to give it a try if this is something others believe would be a benefit.

I personally feel it makes many students feel like it is an empowering feature tof Processing especially for beginners, as it allows to build confidence early on. I usually begin my classes with an empty sketch and show them that this still produces a gray-background canvas, and we build from there.

[catarak]

Thanks for submitting this! I don't have a strong opinion about this, and could be convinced either way, so I'm curious for more input.

[sofian]

In general, one point in favor of it is simply that it would more adequately match the "java" version of Processing. I also believe the IDE (and not the library) is the right place to implement this.

[limzykenneth]

I quite like this idea, however, it would mean that there will be a difference between code written in the editor vs code written in the user's own text editor (ie. if you copy a static mode code from the web editor into a custom setup project in your own text editor it will fail).

This works for Processing because Processing's users will probably be using the editor as the code actually written are significantly pared down from actual fully compiler friendly Java and the compiling stage are also taken cared of. I feel p5.js does less out of the box being just a library itself and just some "magic" to make global mode possible.

That's what I think anyway, whether it is that much of a concern for the users, much can still be said.

[sofian]

Yes this is the main drawback. No intermediate user really uses static mode, it is really more of an educational feature to introduce students to coding. So I believe that by the point users start using p5.js as a library outside of the IDE, they will be advanced enough to not use the static mode anymore, and it will be fine to just point out that static mode is not going to work in that context.

[catarak]

I was looking at this https://github.com/processing/p5.js/wiki/Frequently-Asked-Questions#why-cant-i-assign-variables-using-p5-functions-and-variables-before-setup today, which made me lean towards not including a static mode (or static mode being fairly low priority), but instead explicitly including p5 outside of setup or draw:

new p5();
print(random());

I think another option would be to explicitly have a 'static mode' in the editor which could be turned on by a preference option, but i wouldn't want static mode to be turned on implicitly.

[francisli]

Repeating my comments from the pull request (#488) in case it doesn't get propagated to the folks on this issue thread:

I, too, am interested in having the equivalent of Processing's "static mode" for a workshop geared towards elementary school students. Although it seems like a minor and limited feature, I've always felt that it was a keen insight of the original Processing- to completely remove any distractions from the first interaction, giving students that blank slate/sheet of paper to draw upon incrementally.

This is obviously a somewhat frail implementation of it, but it does work, and it would probably work in the majority of workshop/classroom settings. If you rename the initial js file from sketch.js to something else it will break (of course, it will break your project regardless unless you know how to also modify the html file script reference). Having multiple files can also break, depending on how they are used (this is why the original Processing PDE concatenates the content from all of its .pde file "tabs" into a single source file before pre-processing).

So, I think by the time you're ready to let students open up the side tab, and start manipulating the project files, you've probably gotten far enough that they've learned function declarations and started using setup() and draw()...

[sofian]

@francisli Thanks.

[sofian]

@catarak The option to include a 'static mode' in the editor is a good one : to make it explicit also makes it more clear. I also believe it should be "off" by default -- although (maybe) it could be interesting to overcome that in the URL eg. https://editor.p5js.org?static or https://editor.p5js.org/static or https://static.editor.p5js.org would set the default to be static so that you don't have to ask beginners to perform an extra step.

[francisli]

@sofian @catarak I've just updated my PR to make this static mode implementation an environment variable setting, for your consideration. If the environment variable is not defined or otherwise not set to 'true', then the editor will be in its original implementation. If STATIC_MODE_ENABLED=true is set in the environment, then the default sketch will be empty, and the handler for the code will be enabled.

FYI, I've been using this implementation in elementary school classrooms (3rd grade last year and now 3rd and 4th grade this year), with great success. It really is far less intimidating and a big difference to be able to just jump in to an empty file and have that clean blank slate and not have to answer any questions about the default sketch code or try to explain it.

[shiffman]

I'm really enjoying this discussion! This is such a tricky one that we have gone around and around on with p5.js since the beginning! One thought is that if we do decide to include support for a "static" mode that maybe we alter the code if the user selects "download" to wrap everything in function setup() {}? Could also even crazily provide a warning if the user does select all and copy? With Processing, whenever the code was "exported" to Java it included all the boilerplate wrapper stuff that the PDE itself would hide.