There is a sense in which this is pretty cool... even <i>very</i> cool. And I'm all for anything that makes scientific / data-oriented analysis and exploration more accessible.<p>But on the other hand, I remain unsure that it makes sense to continually try to push <i>everything</i> into the browser. Take:<p><i>Iodide documents live in the browser, which means the computation engine is always available. Whenever you share your work, you share a live interactive report with running code. Moreover, since the computation happens in the browser alongside the presentation, there is no need to call a language backend in another process. This means that interactive documents update in real-time, opening up the possibility of seamless 3D visualizations, even with the low-latency and high frame-rate required for VR.</i><p>I mean, yeah, OK, there are aspects of this that make sense. But there are always tradeoffs. Take, for example this point: <i>"there is no need to call a language backend in another process"</i>. This also means that you're limited to the processing power available on your local machine, which is - BTW, being shared among everything running on your computer.<p>I'm not saying that Iodide is bad, mind you. But it - like any other tool - may not be appropriate for everything. As a corollary to that, I think it might be a fun experiment to see what it would take to provide an ability to move the computationally expensive parts between the local computer and a remote $BEEFY_HOST in a seamless way.