Disclaimer: I’m not much of a Julia- or web developer, so I hope the more knowledgeable can correct me if I get anything wrong here.
I don’t mean to disparage the efforts of @shashi and others – Escher is a great project and does a lot of cool stuff. However, I agree with its readme in that it’s not ready for public projects, and I also think the approach it takes may not be a good fit here.
First, whenever you interact with a component on an Escher page in a non-trivial way, you have to communicate with the back end. This makes the page less responsive and also takes a surprising amount of data. For example, on the Serpinski demo, dragging the slider back and forth a few times exchanges half a MB of data with the back end.
boids.jl example, running the simulation uses 3 MB/sec of bandwidth.
This doesn’t make a difference for me running a single instance of the webpage on localhost, but it won’t easily scale to the case where you have multiple people, or even a single person on a low-bandwidth connection.
Always having to shuffle data back and forth between the client and the server also prevents you from easily doing a lot of things that are natural parts of modern web pages. For example, you might want to plot the solution to the differential equation. If you want to let the user zoom in on the y-axis of a Gadfly plot, you need to implement custom controls for doing this. Then, every time the user touches one of those controls, the page needs to talk to the server, which rerenders the entire plot and sends the whole thing back. However, there’s really no need to use the server for something like this, and it’s trivial with client-based plotting packages like Plotly or Highcharts.
Someone should correct me if this is not correct, but I think Escher is also single-threaded and blocking. If one user submits a differential equation that takes two seconds to solve, no other user will get any response in that time, and all the requests that come in during that time will pile up.
I think the easiest way to do something like this is to have a normal web page served by any old webserver, and use Julia only for the back end. Looking at this a bit more, I think that JuliaWebAPI.jl might be a better choice than the options I mentioned previously. I’m still figuring out exactly how to use it with JuliaBox, but once I have it going I think I can throw this whole thing together pretty quickly. If you have a notebook that shows roughly what sort of diff-eq solver you want to provide send it my way, otherwise I’ll set it up with a simple example.