I’m a big fan of Observable and also author of elm-visualization.
Do you think Elm could be suited for this sort of domain?
In the long term yes. But there is a long way to go before it can compete head to head with JS on what I would call explorative programming. The main Elm brings to the table for application programming is stability and maintainability. Those are less useful for building a notebook. Also in my experience for notebooks the Elm Architecture kind of gets in the way as most notebooks need to perform effects in various ways.
In your own opinion, how does
elm-visualization compare to D3.js? They are strictly different paradigms, the latter being highly procedural. What are the advantages of each?
elm-visualization is highly inspired by D3. One thing to understand about D3 is that it is a whole bunch of libraries covering all sorts of things, many exist because at the time they were written there were no good solutions to these problems. So for example D3 has a notion of “selections” which exist to manage DOM mutation. In my opinion this is the trickiest part of D3 and the one that elm-visulization doesn’t have, since in Elm you have the virtual DOM which is a much easier abstraction.
On the other hand, most of the core bits of D3 that actually implement visualization algorithms are fairly functional in nature. They mostly follow the pattern of:
const fun = d3.makeFun(someConfig)
const output = fun(input);
This is essentialy the Elm type of:
fun : Config -> Input -> Output
except it allows you to mutate the config after it has been partially applied.
So in essence elm-visualization and D3 are quite similar - one is in Elm and omits a lot of the legacy cruft (and a lot of useful features too as I haven’t had time to implement everything I’d like!) the other in JS and is somewhat tied to its own specific DOM management system).