Closed SimonDanisch closed 4 days ago
Will it be possible then to use WGLMakie in Pluto without JSServe ?
No... what would be the use case?
More precisely: what's the use case that isn't covered by a better JSServe pluto integration?
Besides of feeling "non-plutonic", essentially this...
I am not sure how fast Julia->JS data transfer with JSServe
is and how it is done. If it uses ASCII encoding I think that Pluto's publish_to_js
would be faster.
It should be as fast as possible and quite similar to Plutos protocol ;) It may even be faster, since I integrated some MsgPack improvements, that Pluto doesn't have yet... We did want to start sharing the protocol between Pluto & JSServe, but neither @fonsp nor me have had time to push it any further. But we did create the package and put some initial code in it :D
Serverless visualization
JSServe + WGLMakie already work pretty well with a running Julia server, but this doesn't scale very well to serve interactive demos for thousands of people (e.g. blogpost/articles). For that we need to Move more work into the browser on the clients computer and make it easier to remove any communication with Julia.
Move more to JS
WASM integration
Or another possible API:
Compsoable GUI elements
Declarative API for Pluto & AoG and easier animation
Right now one animates in Makie like this:
This is highly performant, but is difficult for complex dashboards where data can change the plot types or attribute passed (e.g. like in AoG). This kind of mutating API using observables and just one plot call is also working against Plutos way of animating, which executes the complete cell defining the plot on every change. So we need a declarative API like this:
Rendering the
plot_spec
efficiently with diffing will be the basis for a much more performant Pluto integration and easier to write dashboards. Prototype exists here: https://github.com/MakieOrg/Makie.jl/pull/2868Test & Polish
More backends