It’s a very interesting read about Glitch’s backend (server-side) containerized language features.
However my hosted sketch “Blob Growth” runs 100% on the frontend (client-side).
In order to run it on the Processing’s IDE (PDE) only file “Blob_Growth.pde” is needed:
Blob-Growth-Java.Glitch.me/Blob_Growth.pde
For browser-running we need 3 more files though.
The “index.html” as its entry point:
<script defer
src=https://cdn.JsDelivr.net/gh/hapticdata/toxiclibsjs/build/toxiclibs.min.js>
</script>
<script defer src=ToxicLib_Imports.js></script>
<script defer src=ArrayList_Shims.js></script>
<script defer src=https://Unpkg.com/processing-js></script>
<canvas data-processing-sources=Blob_Growth.pde></canvas>
“ToxicLib_Imports.js” which copies the required “ToxicLibs.js” classes to the global context, so they’re available to direct usage by the sketch “Blob_Growth.pde”:
Blob-Growth-Java.Glitch.me/ToxicLib_Imports.js
And the shim hack file “ArrayList_Shims.js”, which makes it possible for JS arrays to use most of the Java ArrayList’s methods:
That is necessary b/c the Java version of “ToxicLibs” store particles on ArrayList containers, while the JS version goes w/ vanilla JS Array containers.
And neither versions feature getters & setters to access their containers via indices.
The reason why we’re able to deploy “.pde” files on the web as 100% client-side apps is b/c “Processing.js” (Pjs) is not only a JS library but also a simple Java Mode to JS transpiler in 1 file!
We can find more about its inception on the article below:
https://JohnResig.com/blog/processingjs/