A frictionlessly portable interface for literate scientific computing in the browser
Clone or download
Type Name Latest commit message Commit time
Failed to load latest commit information.
.circleci Run jest tests sequentially in CI (fixes #1374) (#1375) Jan 11, 2019
.github Update issue_template.md Feb 13, 2018
bin Cache results of pyodide compression when creating heroku buildpack (f… Jan 15, 2019
docs Update policies.md Jan 18, 2019
server Add a "try it out" mode to iodide (fixes #1330) (#1399) Jan 18, 2019
src Add a "try it out" mode to iodide (fixes #1330) (#1399) Jan 18, 2019
test Use prettier's lint settings for code (fixes #1199) (#1376) Jan 14, 2019
.babelrc small links now appear on hover only Jan 10, 2019
.dockerignore Fix dockerflow / docker container building (#1070) Oct 18, 2018
.editorconfig Add .editorconfig Feb 2, 2018
.env-dist Very basic google analytics support (#1153) Nov 14, 2018
.eslintignore update .eslintignore Jun 18, 2018
.eslintrc.js Use prettier's lint settings for code (fixes #1199) (#1376) Jan 14, 2019
.gitignore Fix #1396: Add in-tree documentation Dec 21, 2018
Dockerfile Update python Docker tag to v3.7.2 (#1301) Dec 28, 2018
LICENSE Create LICENSE Feb 8, 2018
Makefile Have server shells run inside *existing* containers (#1393) Jan 17, 2019
Pipfile Enable brotli compression (#1272) Dec 11, 2018
Pipfile.lock Enable brotli compression (#1272) Dec 11, 2018
Procfile Switch server implementation over to python Jul 12, 2018
Procfile.windows Switch server implementation over to python Jul 12, 2018
QA-CHECKLIST.md Create QA-CHECKLIST.md Sep 14, 2018
README.md Update README.md Jan 17, 2019
docker-compose.yml Use full docker-compose environment for integration testing (fixes: #… Nov 14, 2018
manage.py Switch server implementation over to python Jul 12, 2018
mkdocs.yml Update docs site URL Dec 21, 2018
package-lock.json Update dependency eslint-plugin-react to v7.12.4 (#1392) Jan 19, 2019
package.json Update dependency eslint-plugin-react to v7.12.4 (#1392) Jan 19, 2019
pytest.ini Add gravatar support for when not using github social auth (fixes: #1077 Oct 24, 2018
renovate.json update renovate.json per @wlach's suggestion Sep 13, 2018
setup.cfg Add a datetime helper function to django server tests Sep 27, 2018
webpack.config.js using narrowContentWidth for footer Jan 10, 2019


CircleCI Join the chat at https://gitter.im/iodide-project/iodide

The Iodide notebook

Try it in your browser right now!

Please note: Iodide is in early alpha, and still subject to breakage, changes, and overhauls

View source for science

Today, sharing scientific results is easier than ever. You can email a PDF, write up a Google doc, or post to your blog. You can embed plots, data tables, and even interactive visualizations. But what if you want people to be able to replicate and extend your results -- to take your results and “view source” to see how you arrived at your conclusions? Or even hack and remix them to ask their own questions?

To do that now, you typically have a couple options. You could send your code along side your nice, clean PDF or HTML export, allowing you fine-grained control over your presentation, but requiring you to separate your presentable results from your code and to manage multiple files. Alternatively, you could share your results and code bundled together in a notebook format that mixes code with write-up; this has the advantage of keeping your code and results closely tied together, but the presentation can get a bit unwieldy, especially if you want to share your results with a less technical audience. And in either case, sharing your code will only allow your collaborators to replicate and extend your results if they are first able to replicate your whole setup -- if they can run your code with the same libraries, the same data, and the server access.

If only there was a technology that was great for presenting documents and visualizations, that allows code to run anywhere with zero setup, and that all scientists and citizens had access to...

Luckily, that technology already exists: the web browser.

Iodide is a modern, literate, and interactive programming environment that uses the strengths of the browser to let scientists work flexibly and collaboratively with minimal friction. With Iodide you can tell the story of your findings exactly how you want, leveraging the power of HTML+CSS to display your results in whatever way communicates them most effectively -- but still keeping the live, editable code only one click away. Because Iodide runs in the browser you already have, you can extend and modify the code without having to install any software, enabling you to collaborate frictionlessly.

And thanks to WebAssembly, working in the browser does not mean that you have to work in Javascript. We're already working on getting Python+Numpy+Pandas running in the browser, and that's just the start. We envision a future workflow that allows you to do your data munging in Python, fit a quick model in R or JAGS, solve some differential equations in Julia, and then display your results with a live interactive d3+Javascript visualization... and all that within within a single, portable, sharable, and hackable file.

Our focus is on delivering frictionless, human-centered tools to scientists. You can read more about our core principles below; if our vision resonates with you, please consider contributing to the project!

PS: We're working on a few other ways of making this in-browser workflow as ergonomic for scientific tasks as possible. Two of those key efforts will be (1) using modern JS transpilation tools to extend JS syntax just enough for matrix notation, broadcasting, and other basic scientific computing needs; and (2) compiling best-in-class C/C++ science libraries (and runtimes!) to Webassembly and wrapping them in ergonomic JS APIs. If either of those projects appeals to you, please reach out!

Get in touch

Please feel free to join our Google group to contact us and keep up with what we're working on.

You can also chat with us on Gitter.

Learn more about it

Please visit our documentation.

Using the notebook

Visit https://extremly-alpha.iodide.io/ to see example and demo notebooks, and to learn more!


Please join us! The notebook is written using React+Redux, which, if you haven't used them, are pretty delightful -- there's some learning curve, but even for non-professional webdevs the curve is not too steep, and the mental model is clean and powerful.

See our "How to Contribute" page for more information.

We especially need help with:

  • test coverage for everything in our system.
  • demos, tutorials, and documentation. The more we have, and the better organized it is, the better.

Design principles

Our core principles

  • Human factors come before everything else
  • Scientific computing and computational inquiry implies different needs than typical software development
  • We want to make the advantages of web tech available to scientists without requiring them to become fully fledged web devs

Secondary principles

Flowing from those core principles, we have a number of secondary principles/objectives that revolve around the notion of reduce friction for people that want out the platform.

  • Users should be able to get up and running immediately and be able to start doing real work entirely within the browser.

    • Allowing the notebook to work with other client and/or server-side programs/components/tools (e.g. external editors, external compute kernels (other languages or big data thingies)) might be something cool to work on down the road, but is not an objective at the moment
    • Addons to do things that the browser restricts or can’t do for some reason (file system access, halting hung scripts) could potentially be ok for power users, but cannot be a requirement to get going with a satisfactory experience.
  • Avoid magic APIs -- users should (within reason) not have to learn about a ton of idiosyncrasies of the notebook to get up and running.

    • Users need to be able to build off of existing work/examples/resources. Users need to be able to pull examples from bl.ocks.org or JSfiddle or Stackoverflow and have them run in the notebook without modification (within reason). This means, among other things, seamless access to all browser APIs is a hard requirement, and things that change the way standard Javascript is executed in the browser are to be avoided.
    • Helper libraries are desirable, but they should just act like regular JS libraries and not require users to contort their mental model of how vanilla JS works, or pollute the regular JS environment. (Ex: it would be preferable to add a single namespaced helper lib than to dump a bunch of utility functions into the global scope).
    • We want to support syntax extensions for mathematics, but we want them to be opt in, not something that a user will have to learn to be able to use a notebook.
  • Don’t innovate too much -- at least initially, we want to follow existing, familiar paradigms that will enable people to dive right in.

Initial use case

In building this tool, we will keep our eyes on a broad swath of computational inquiry use cases, and we’ll strive to avoid making decisions that limit the tools use to a specific domain. We're initially be targeting small to medium N data science workflows, since these often come up at Mozilla and we're very familiar with them, but if your use case requires something that we haven't addressed yet, please leave us a message at our Google group.


The Iodide code is shared under the terms of the Mozilla Public License v2.0. See the LICENSE file at the root of the repository.