Design architecture question

[gganapat]

Julia (and Python) have wrapper functions for MathLink (located in "/Applications/Wolfram Engine.app/Contents/Resources/Wolfram Player.app/Contents/Frameworks/mathlink.framework/mathlink" for MacOS Wolfram Engine). This give a powerful and lightweight way to use Pluto (notebook for Julia) for example to run Wolfram code in a notebook environment. The calculations are extremely snappy. Pluto is based on Observable notebook which is an amazing product. I was wondering if there is way to develop a MathLink.js wrapper which will alleviate several of the pain points. Pluto has its own pain points but if there could be lessons learned from it, WLJS could be benefited a lot. I'm not sure if the current architecture will allow grafting but something to think about.

Here is snippet in Pluto (full file also attached - remove .zip) Wolfram.jl.zip. The file size is only 19kB!

and here is a snippet where 3D plots can be rotated, etc.

[JerryI]

Observable (and Jupyter) was an original inspiration for WLJS project ;)
The key feature we were focused on was to bring easy, fast and snappy dynamics to Wolfram Notebooks similar to Observable. Pluto came to our vision much later on.

Why we abandoned the idea of using JP, Observable

We tried Jupyter API and then later Observable as well, however it could no provide enough flexibility to make syntax sugar, editable math expressions and editable output cells as well as a very slow IO between the evaluation Kernel and the frontend (a very long path from Kernel to Python via ZMQ and then to the frontend).

Also it is also tricky to store interactive 3D plots or some other graphics in there. Jupyter only provides mostly rasterized static images as a output or backed JS code. We store raw WL data in the WLJS notebook, and then frontend interprets it as a plot or as 2D or 3D image, which increases the filesize, but gives more opportunities (pan or rotate a plot or drag a slider without completely offline without a working kernel). However, you don't have to. If you remove all graphical output the final size will be also a few kB.

That's basically the main reasons, why we did not join their club. If we cut our key-features, then WLJS is nothing different from VSCode Notebook or Jupyter/Pluto with Wolfram Kernel.

I personally love the idea of Pluto, where it automatically tracks the dependencies and reevaluates a cell and rasterizes the output image using a new data.

Mathlink.js

If I am not mistaken in the interpretation of your idea, it is to couple Wolfram Kernel and Observable notebook interface (for instance) or something similar and localize the frontend within a Javascript world.

It is definitely possible, the only problem that it will probably a bit more tricky compared to VS Code WL Notebook Extension, and Wolfram Language is not that popular for someone to take care of it.

Then we would need to strip out many things, which make WLJS different from the other solutions. However, one can still use our libraries for rendering 2D/3D graphics and even REST API to built their own notebook interface (with some limitations).

PS: Hope I have interpreted your message correctly ;)

[gganapat]

Hi Jerryl, thank for the very thoughtful response. It is clear you have more than done your homework. On the "Mathlink.js" idea, yes, you have captured my idea perfectly. The combination of something like Observable as the frontend in the JS world is exactly what I had in mind. I think you have a great product as-is but certainly like any other tool there are potentials for improvement and I was thinking this idea could be one pathway to consider.

Again, thank you for your thoughtful response. Hopefully, someone will still pick up the idea of compiling/linking mathlink (as wasm perhaps?) to a JS frontend.

Keep up the great work.

gani -