-
Notifications
You must be signed in to change notification settings - Fork 141
FAQ
Based on the core principles described in our readme, we’ve made a number of design choices. Some things we’re pretty firm on, but a good number of these choices have been made for the sake of expediency, and are not set in stone (indeed, there are at least a few things we’d really like to change if we can come up with a better approach). We’re very open to hearing other perspectives and exploring other options WRT implementing the broader objectives -- a lot of the big stuff and pretty much all of the details are open for negotiation and refinement.
We’re not wedded to notebook interfaces per se, but in order to make a tool that is immediately familiar to scientists, we’re initially targeting a notebook-style experience because these interfaces are widespread and have a long history of productive use by scientists. (primarily Mathematica, Jupyter (formerly Ipython), but also a host of similar projects (Apache Zeppelin, the Beaker notebook, Databricks notebook, Sage, ...)). In the future, we’d like to experiment with an “editor + output and visualization panes” interface as well (in the mold of e.g. R-Studio, MATLAB, GNU Octave, Juno, ...), which we think is the other style of IDE that has been widely and successfully adopted for scientific workflows.
The decision to start with a notebook interface rather than a pane-based interface was kind of arbitrary (have to start somewhere…), perhaps kind of informed by the vague sense that notebooks are a little more prominent at the moment. But we’re very willing to be convinced otherwise and change directions.
Q: Why just recreate another notebook interface? Why not something more ambitious, interactive, or paradigm-shifting?
We are very much inspired by the visions laid out by people like Brett Victor, and the expression ideas like that have found in things like Observable (formerly d3.express), the Carbide notebook, the LightTable IDE, etc. We think those projects are awesome, and we hope they succeed fantastically.
However, at least initially, we want to keep limit our scope to just providing a familiar iterative code editing+execution workflow, rather than introducing additional abstractions or complexity around things like live code updating, providing widgets to manipulate variables values, and other interesting ideas like that. That stuff is really cool, and we hope it opens up workflows and new ways of exploring ideas, but we initially want to focus on providing a very low-overhead way to approximate existing workflow.
Q: Why build an IDE in the browser rather than leveraging technologies that are already widely used by the JS community to achieve iterative workflows (e.g. things like Webpack with hot module reloading)?
Our objective is to provide a tool that will be familiar, productive, and low friction for scientific computing and computational inquiry, and the workflows and needs of users in this area are somewhat different than for web devs, or other software devs generally. We know that browser-based IDEs haven’t been widely adopted by software developers, but they’re extremely common in scientific computing (notebook interface in particular).
And of course, because providing an extremely low-friction experience is one of our key goals, requiring users to install anything would be a major negative -- we want people to be up and running and editing code with no overhead beyond opening a URL or HTML file in their browser.
It’s also worth mentioning that the kind of workflows we’re targeting initially aren’t quite the same as they’d be in a large software project. Even for scientific computing, a notebook IDE is probably not the best interface for e.g. writing a library to be used in other projects. But it’s a proven interface for computational inquiry -- asking and answering questions using code. This use case typically involves a relatively small amount of code, and much of it may be code that is targeted at a specific question
Q: Why do this in the client? Why not hosted science-as-a-service (for example, Jupyter on a server, like Juliabox)?
Connecting to Jupyter notebooks (and similar technologies) running remotely works fantastically for a great many use cases -- we've used this solution for many years and will continue to do so. We think there are a couple advantages to having code running in the browser for some use cases, but if those use cases don't apply to you hosted notebooks are a great alternative.
One advantage is that some people prefer not to rely on a server; either they don't want to be tied to a service they don't control, they don't want to run their own server infrastructure, or both -- people just prefer to run their code locally on their on machine. In those cases, however, it may be difficult to share analysis code without setting up a lot of software on the machine to which the analysis is sent. Our approach allows you to maintain full control of your code on your machine while still enabling you to share your work seamlessly.
The other big advantage is that having analysis code running live on the client enables seamless real-time interactivity. Server-side notebooks have made great strides in this area, but nothing yet matches the power and flexibility of having true direct access to the DOM.
Because JS runs in browsers and can access the DOM and browser APIs. That is really the only reason -- we are not at all dogmatic about JS; we don't hate it, but we're aware of it's shortcomings. We love Python and Julia, and many other languages, and we'd be thrilled to collaborate with those communities to get those running in the browser under webassembly so that those beautiful languages can also access the power of the DOM and can be run anywhere with zero setup.
We’d really love a better solution for this. Of course evaling in the window scope blocks the whole IDE UI, so you can’t do anything else (e.g. edit other cells, save your progress, etc) while a code cell is executing. We’re open to solutions of all kinds -- running in a Worker, using this “realms” API we keep hearing about, pushing the code to an iframe to be evaled, etc. But it’s a very firm design requirement that users be able to do web programming that looks like the stuff that is done everywhere else on the web. This means seamless access to the DOM and other browser APIs -- users need to be able to experiment with code snippets from bl.ocks.org, Codepen, JSFiddle, Stackoverflow, and other sites that help people learn Javascript, and if browser APIs don’t work as expected, this learning will be hindered enormously. If it’s possible to somehow proxy those APIs within a webworker in a way that works seamlessly, that would be great, but requiring people to learn a non-standard set of APIs is a non-starter -- if people can’t adapt existing code and use all the existing libraries (d3, three.js, etc) that make the web appealing for scientific computing, then the use cases for such an IDE will be deeply undermined.