Wolfram Physics in Vanilla Processing

Gallery
9

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/

1 Like