Jupyter Blog - JupyterLite

JupyterLite 0.8 is released! 🎉

2026-07-10T05:01:00+00:00

JupyterLite is a Jupyter distribution that runs entirely in the web browser without any server components. Deployment and hosting are easy as JupyterLite sites are just static websites.

The new 0.8 release includes a number of new features, bug fixes, and enhancements. This release also brings significant improvements to the user experience and new customization options for JupyterLite deployments.

When the REPL toolbar is enabled, it now includes a Copy Shareable Link button. Clicking it captures the current state of the REPL, the prompt content, the selected kernel and theme, and any non-default options, into the page URL, and copies the resulting link to the clipboard. A notification confirms the link was copied, making it easy to share a ready-to-run REPL with others.

Refreshed Loading Screen

The loading indicator shown while JupyterLite starts up has been redesigned to match the JupyterLab splash screen to make the transition from the initial loading screen to the fully loaded application feel more seamless.

The loading indicator remains configurable, and can be enabled or disabled for specific applications. See the loading indicator guide for more details.

File System Reliability Improvements

JupyterLite 0.8 includes many fixes to the in-browser file system used to store your notebooks and files. Creating files and directories is now faster and more reliable, saving a file to a directory that does not exist is now rejected with a clear error rather than failing silently, and files are no longer opened twice on startup when using query parameters. These changes make working with files in JupyterLite smoother and more dependable.

JupyterLab 4.6 and Notebook 7.6

JupyterLite 0.8 is built on top of JupyterLab 4.6 and Notebook 7.6, and brings many of the respective improvements and bug fixes. Check out the announcement post to learn more about these new releases.

This JupyterLite release includes 9 new features and enhancements, 11 bug fixes, and 5 documentation improvements. 13 people contributed to this release. Across 85 maintenance tasks and dependency updates, we kept JupyterLite up to date with the latest JupyterLab and Notebook releases.

A Terminal in the Browser

The JupyterLite Terminal adds a fully in-browser command-line terminal to JupyterLite, powered by the cockle shell. Commands run as WebAssembly directly in the browser, with no server involved. Version 1.5 adds compatibility with JupyterLite 0.8, and recent releases include:

A growing set of familiar command-line tools compiled to WebAssembly, including ls, cat, cp, mv, grep, sed, tree, git, and the vim and nano editors.
Tab completion for commands, arguments, and file names, with a confirmation prompt before listing a very large number of matches.
New JupyterLab commands for running shell commands programmatically and capturing their output, without opening a terminal panel.

Running terminal commands in the browser

More Kernels with jupyterlite-xeus

jupyterlite-xeus builds JupyterLite deployments around Xeus-based kernels and lets you pre-install packages from conda-forge and emscripten-forge straight into the browser environment through an environment.yml file. Its recent releases (the 4.5 series and the new 5.0) are compatible with JupyterLite 0.8 and add a number of improvements:

A growing list of supported kernels, including xeus-python, xeus-r, xeus-cpp, xeus-lua, xeus-nelson, xeus-octave, and xeus-javascript.
Installing packages at runtime now feels more natural: you can run pip installor conda installdirectly in a cell, with the leading % or ! now optional.

To learn more about pre-installing packages, mounting files, and the available kernels, see the jupyterlite-xeus documentation.

Python 3.14 with the Pyodide Kernel

The Pyodide kernel has been updated to version 0.8.0. It bundles the latest Pyodide release, which upgrades the in-browser Python interpreter to Python 3.14. Notebooks and consoles running on the Pyodide kernel now use the newest Python version, including recent standard library additions such as the new compression.zstd module.

For deployments that pre-compute the set of packages to ship offline, the kernel’s lock add-on can now build a customized pyodide-lock.json from your own requirements — including reading dependencies from a requirements.txt file or a pyproject.toml dependency group — giving site authors finer control over which packages are available without a network connection.

See the pyodide-kernel 0.8.0 release notes for the full list of changes.

Pyodide 314 in JupyterLite

JavaScript Kernel Improvements

The in-browser JavaScript kernel has gained several improvements in its 0.4 development line:

A new iframe-based execution mode with better support for libraries that need direct access to the DOM, such as p5.js.
Initial support for Jupyter Widgets, through Comm channels and a set of base widgets.
Clearer error messages and tracebacks, including a fix for errors that previously rendered as blank in Firefox.

Jupyter Widgets and dynamic imports with the JavaScript kernel

Try it in your browser

If you would like to try the new release in your browser, click on the following link:

Acknowledgments

Thanks to Bloomberg for funding the work on JupyterLite at QuantStack, and for their ongoing support for JupyterLite in general.

Many thanks to all the contributors to JupyterLite. The list below is based on GitHub usernames for the 0.8 release across the different projects:

New contributors: @Darshan808, @MMesch, @MUFFANUJ, @wata727
Returning contributors: @DerThorsten, @agriyakhetarpal, @bollwyvl, @ianthomas23, @jasongrout, @jtpio, @martinRenou, @trungleduc

Thank you to the extended group of contributors in Jupyter Frontends and related project in the Jupyter ecosystem 💛

A User’s Journey with Plugin Playground: From First Idea to Installable JupyterLab Extension.

2026-05-28T17:45:00+00:00

We are excited to announce the 1.0 release of JupyterLab Plugin Playground, allowing you to seamlessly experiment with the creation of Jupyter Notebook and JupyterLab plugins to add any functionality you may desire. To install:

pip install jupyterlab-plugin-playground

or use it from Binder or JupyterLite without installing anything by clicking one of these links: Binder (Lab), Binder (Notebook v7), JupyterLite (Lab), JupyterLite (Notebook v7).

Motivation

Building a JupyterLab extension has traditionally required setting up a complex local environment: installing dependencies from disjoint ecosystems (Node.js and Python), configuring tooling, and hunting down the right documentation. The goal of the Playground is to eliminate that setup overhead and streamline extension development. By bringing the runtime, documentation, and the context required for extension development into a single browser tab, you can go from idea to working extension without any local setup required.

Journey At a Glance

Start with a tiny extension idea that is easy to verify visually.
Choose a build path: Manual or AI-assisted.
Load and iterate inside JupyterLab until behavior is stable.
Build a second extension to prove the workflow is repeatable.
Share plugin files/packages for product and engineering review.
Export as a wheel(.whl) and validate installation in a clean Binder runtime.
Export as a zip and move the scaffold into a normal GitHub repository.

1.0: Pick Your Starting Path

At the beginning, choose the path that matches your confidence level and speed needs. If this is your first time with Plugin Playground, you can optionally run Take the Tour from the Launcher or Command Palette for quick orientation before starting.

Start from File If you already know the APIs you need and want direct control.
Build with AI If you know the intended behavior but want a first draft quickly.

Both paths converge to the same shipping workflow later.

2.0: Build Extension #1 Manually

For the first pass, we will create something small and observable.

Our Goal: add a command named Toggle Right Sidebar to the command palette.

2.1: Create the plugin file

Launch Start from File. This comes with a dummy template.

import {
  JupyterFrontEnd,
  JupyterFrontEndPlugin,
} from '@jupyterlab/application';

const plugin: JupyterFrontEndPlugin<void> = {
  id: 'hello-world:plugin',
  autoStart: true,
  activate: (app: JupyterFrontEnd) => {

  },
};

export default plugin;

Now build the plugin in order:

In Tokenssection in the right sidebar, search ICommandPalette and click insert ( + icon ), so Plugin Playground adds token import and dependency wiring.
Add a simple command skeleton inside the activate function:

const commandID = 'my-first-playground-plugin:toggle-sidebar'; 
app.commands.addCommand(commandID, { label: 'Toggle Right Sidebar', 
  execute: async () => {
      // place cursor here
  } 
});

In Commands, search application:toggle-right-area, place your cursor inside execute of the added command ( see above ) and use Insert in selection This adds at the cursor position:

app.commands.execute('application:toggle-right-area');

commandPalette.addItem({ command: commandID, category: 'AAA' });

After those edits, your file should look like:

import { ICommandPalette } from '@jupyterlab/apputils';
import {
  JupyterFrontEnd,
  JupyterFrontEndPlugin,
} from '@jupyterlab/application';

const plugin: JupyterFrontEndPlugin<void> = {
  id: 'hello-world:plugin',
  autoStart: true,
  requires: [ICommandPalette],
  activate: (app: JupyterFrontEnd, commandPalette: ICommandPalette) => {
    const commandID = 'my-first-playground-plugin:toggle-sidebar'; 
    app.commands.addCommand(commandID, { label: 'Toggle Right Sidebar', 
      execute: async () => {
          app.commands.execute('application:toggle-right-area');
      } 
    });
      commandPalette.addItem({ command: commandID, category: 'AAA' });
  },
};

export default plugin;

Uses the typed plugin template (JupyterFrontEndPlugin<void>) and typed activate parameters. Imports ICommandPalette so the plugin can add entries to the Command Palette.
Registers a new command (my-first-playground-plugin:toggle-sidebar) and executes application:toggle-right-area when your command runs.
Adds your command to the palette under the category AAA.

2.3: Load it and verify behavior

Click Load Current File As Extension or click the run button in the toolbar, and open Command Palette.

When you run Load Current File As Extension, Plugin Playground compiles the active file and registers the plugin object into the live JupyterLab session. During iteration, if a plugin with the same id already exists, Plugin Playground attempts to deactivate and replace it so reload loops stay fast.

Expected result:

Toggle Right Sidebar appears in the command palette ( open command palette by going through view -> Activate command palette or Press Accel + shift + C).

Running it hides/shows the JupyterLab right sidebar.

3.0: Build with AI

If you want a faster draft, use AI assistance for the same extension workflow.

Goal: add the Show Active Notebook Cell Count command with a friendly no-notebook fallback.

3.1: Give AI a precise request

Use Build with AI and give a prompt:

for example, something like:-

Create a JupyterLab plugin named "active-notebook-cell-counter".
Add a command "Show Active Notebook Cell Count".
If no notebook is active, show a friendly dialog message.
If a notebook is active, show the current cell count in a dialog.
Register the command in the command palette under category "Playground Demo".
Export default plugin object.

What this block does:

This gives AI a concrete plugin goal, command name, and fallback behavior requirements.

3.2: Use AI + deterministic inserts together

In the Commands tab:

Insert in selection for predictable boilerplate insertion.
Prompt AI to insert when placement context is tricky.
{n} when you need argument shape clarity ( Inspect the command signature before insertion: it shows expected argument names/types and return details).

Use Insert in selection for predictable snippets, and switch to AI when insertion location or code adaptation depends on the surrounding context.

4.0: Iterate Faster Before Handoff

Once the extensions run, enable Run on save(from the toolbar or from the settings) while polishing labels, command categories, and small behaviour details.

With Run on save, each file save triggers a reload loop for that plugin file, which makes label tweaks, command grouping changes, and message-copy iteration much faster than manual reload cycles. And with enabling the global setting (Load as extension on save), this behaviour is present for all files by default.

Before packaging, you can ask a teammate to review behaviour or just share links for the extension for a quick look using:

Share a single file when sharing is about one plugin file.
Share a package when your logic spans several files.

This keeps review lightweight: collaborators can inspect and discuss behaviour before you commit to repository structure, CI, and release wiring.

6.0: Export as Wheel and Validate in Binder

Now test as an installable artifact in a separate environment.

6.1: Export `.whl`

From the export dropdown ( in toolbar ), choose Export as Python package (.whl).

6.2: Install in Binder

Open JupyterLab on Binder.
Upload the downloaded wheel.
Open a terminal and run:

python -m pip install - force-reinstall ./your_exported_package.whl

What this block does:

Installs the wheel you just exported from Plugin Playground into Binder. (Uses — force-reinstall so Binder replaces any previously installed copy with your newest build). Then refresh JupyterLab and verify commands.

7.0: Export as Zip and Create a GitHub Repository

After runtime validation, move to normal engineering workflows.

7.1: Export `.zip`

Choose **Export as archive (.zip)** from the toolbar export dropdown.

7.2: Bootstrap repository

Unzip locally, create an empty GitHub repo, then run:

git init
git add .
git commit -m "Initial extension scaffold from Plugin Playground"
git branch -M main
git remote add origin https://github.com/<your-org-or-user>/my-jlab-extension.git
git push -u origin main

What this block does:

Initializes a new Git repository from the exported scaffold and creates an initial commit that captures the generated extension baseline.

Now your prototype is in a standard repo flow with PRs, CI, and release automation.

What’s Next

Plugin Playground is still evolving. We’re actively working on the LSP integration for JupyterLite to bring code intelligence autocomplete and diagnostics directly into the editor, an “Ask AI” button on log errors that lets you send error context directly into the AI chat for instant debugging help. In the future, we would like to explore git integration to snapshots every successful load, paired with a built-in diff viewer to compare any snapshot against your current file. If you have any suggestions or encounter any problems, please let us know by opening an issue on GitHub.

Acknowledgements

We are grateful to the Jupyter Foundation and its members for sponsoring the development of Plugin Playground as part of Community Funding Proposals 2025.

We thank Jeremy Tuloup, Nick Bollweg, and Nicolas Brichet for providing inspiration, review, and advice across our work on the plugin and its dependencies. Finally, this work would not be possible without the authors of earlier iterations of Plugin Playground.

About the Developers

Anuj Singh is an OSS intern at OpenTeams. Anuj implemented Plugin Playground v1.0.0 and contributed to its dependencies during his internship at OpenTeams.

Smera Goel is a UI/UX designer at Quansight. Smera contributed to the user experience and design direction of Plugin Playground.

Michał Krassowski is a Senior Software Engineer at OpenTeams. Mike provided guidance and direction for the development of the Plugin Playground.

JupyterLite Officially Joins Project Jupyter!

2026-02-12T16:14:00+00:00

We are thrilled to announce that JupyterLite is now an official part of Project Jupyter. This milestone marks a significant step forward for interactive computing in the browser and strengthens JupyterLite’s role within the Jupyter ecosystem.

What is JupyterLite?

JupyterLite is a JupyterLab distribution that runs entirely in your web browser. Kernels execute directly in the browser using WebAssembly, eliminating the need for an application server. This means:

Instant access: Start computing with a single click: no prior Python setup, environment configuration, or server management required.
Scalability: Host thousands of concurrent users from a static website (e.g., GitHub Pages) with zero per-user server costs.
Privacy and portability: Code and data remain in the user’s browser, making it ideal for embedding in documentation, tutorials, and interactive demos.

JupyterLite greatly expands the options available in the Jupyter ecosystem for education, documentation, and demos, where reducing friction is critical.

As Brian Granger reminded us during his JupyterCon 2025 keynote, Jupyter’s mission is “to empower people of all backgrounds to think, collaborate, and share knowledge using computational storytelling.” From this perspective, JupyterLite is a logical and key next step to take, letting Jupyter take advantage of the impressive strides made in recent years by the WebAssembly/JavaScript ecosystem (in reach and capability) to advance this mission. JupyterLite is an excellent complement to other forms of accessing Jupyter (whether through a local Python installation or a hosted infrastructure service), that facilitates new use cases and lowers barriers in many others.

Interactive computing in the browser with JupyterLite

The Journey of JupyterLite

JupyterLite’s development began in 2021, led by Jeremy Tuloup at QuantStack. Over the past four years, it has benefited from the dedication of several other team members, Martin Renou, Trung Le, and Ian Thomas — as well as invaluable contributions from community members like Nick Bollweg and many others.

Beyond the JupyterLite repository, the project includes comprehensive tooling for creating in-browser language kernels based on xeus. These kernels support languages like Python, R, C++, GNU Octave, Lua, and SQLite, sharing the same codebase as their backend counterparts, developed by Thorsten Beier, Isabel Paredes, Johan Mabille, and Antoine Prouvost. These kernels are built upon the emscripten-forge software distribution for WebAssembly. The project also includes a Python kernel based on Pyodide, and kernels for JavaScript and p5.js. This architecture means that the same language-agnostic model for kernels that Jupyter pioneered over a decade ago, carries over to the WebAssembly world.

The JupyterLite GitHub organization also features the JupyterLite Terminal, a terminal and shell emulator that runs entirely in the browser and was developed by Ian Thomas. It enables the use of basic Unix commands like grep, sed, cat, touch, and even vim or nano, all built to WebAssembly.

The JupyterLite terminal emulator, with basic Unix commands

JupyterLite now powers the official Jupyter website and is used by projects like numpy.org, sympy.org. It also underlies services such as Jupyter Everywhere and notebook.link.

A Natural Fit with JupyterLab

JupyterLite has always been closely tied to JupyterLab. It is increasingly becoming a set of JupyterLab extensions that replace core plugins to manage kernels, settings, and content in the browser. With contributors overlapping significantly with the Jupyter Frontends group, this integration formalizes what many in the community already recognized: JupyterLite is a core part of the Jupyter ecosystem.

The proposal to transfer JupyterLite to the Jupyter governance received strong support from the Jupyter community and by the Jupyter Frontends council.

Better integration with the rest of Jupyter

With JupyterLite now being an official part of Jupyter, it will be easier to find areas for better integration with other aspects of our ecosystem: we can reduce duplication, smooth out the documentation and model for creating and using both “traditional” (server-hosted) and WebAssembly kernels, and make JupyterLite a natural instant-access component of MyST/JupyterBook-based sites, and more.

Mission-wise, JupyterLite is a natural next step for Jupyter, and having it be an official part of the project makes it much easier for the community to integrate its benefits throughout. We hope you’ll try it, use it and contribute to its growth!

Try it in your browser

If you would like to try JupyterLite in your browser, click on the following link:

Acknowledgments and team credits

JupyterLite’s success is thanks to the support of individuals and organizations who believed in its vision. This includes:

QuantStack, for their continued investment in the project since 2021 and the broader Jupyter ecosystem,
Bloomberg, for funding improvements to JupyterLite by QuantStack since 2023,
The Gates Foundation, for funding the development of the xeus-R kernel and its port to WebAssembly,
The Pyodide project, whose pioneering work on Python in the browser via WebAssembly made JupyterLite possible.

Key developers to this stack include:

Jeremy Tuloup (Director at QuantStack, creator of JupyterLite, and JupyterLab maintainer),
Nicholas Bollweg (JupyterLite maintainer and #2 all-time committer),
Martin Renou (Director at QuantStack, JupyterLite maintainer, responsible for integrating xeus with emscripten-forge, and creator of JupyterLite-Sphinx),
Thorsten Beier (Software developer at QuantStack, lead developer of emscripten-forge, and xeus-lite),
Isabel Paredes (Software developer at QuantStack, led the packaging of R and GNU Octave in Emscripten-forge),
Anutosh Bhat (Software developer at QuantStack, C++ kernel in the browser),
Ian Thomas (Software developer at QuantStack, creator of the JupyterLite terminal, and the cockle shell emulator),
Johan Mabille (Director at QuantStack, creator of xeus),
Agriya Khetarpal (Pyodide contributor, JupyterLite-Sphinx maintainer),
Albert Steppi (JupyterLite-Sphinx maintainer).

Thank you for being part of this journey, we cannot wait to see what you build with JupyterLite!

— this post was coauthored by Jérémy Tuloup, Sylvain Corlay, and Fernando Pérez

JupyterLite 0.7 is released! 🎉

2025-12-04T22:11:00+00:00

JupyterLite is a Jupyter distribution that runs entirely in the web browser without any server components. Deployment and hosting are easy as JupyterLite sites are just static websites.

The new 0.7 release includes a number of new features, bug fixes, and enhancements. This release also brings significant improvements to the user experience and new customization options for JupyterLite deployments.

Workspace Support

Support for workspaces is now available in JupyterLite. Workspaces allow you to organize your notebooks and files into separate workspace environments, making it easier to switch between different projects or contexts.

Workspaces are now supported in JupyterLite

The UI layout is also now automatically persisted across sessions. When you return to JupyterLite, your panel arrangements, open files, and workspace configuration will be restored exactly as you left them.

Audio and Video Playback

JupyterLite now includes built-in audio and video viewers, allowing users to open audio and video files directly from within the UI.

Open audio and video files in JupyterLite

Basic Interrupt Functionality

The interrupt button now cancels the execution of cells that are scheduled to run after the currently executing cell. While this doesn’t interrupt the currently running cell itself, it provides better control when executing multiple cells in sequence.

The stop button now cancels the execution of scheduled cells

Basic Notebook Export

JupyterLite now includes basic notebook export functionality through a custom export plugin. Users can export notebooks to different formats including .ipynb (notebook format) and script formats directly from the File menu.

Additionally, JupyterLite provides extension points for third-party extensions to register custom exporters. This enables the development of additional export formats, such as PDF, in future extensions.

Note: there is currently no built-in support for PDF export, but this may be added in the future via a third-party extension.

Basic notebook exports are now available

A download entry has been added to the File menu, making it easier to download files from your JupyterLite environment.

Download a notebook using the file menu entry

Enhanced Markdown Support

Markdown cells now support displaying base64-encoded images stored in the browser’s local storage. This makes it easier to include images in your notebooks without requiring external hosting or network access.

JupyterLab 4.5 and Notebook 7.5

JupyterLite 0.7.0 is built on top of JupyterLab 4.5.0 and Notebook 7.5.0, and brings many of the respective improvements and bug fixes. Check out the announcement post to learn more about these new releases.

JupyterLab 4.5 notably includes significant notebook performance improvements, such as the new optimized cell rendering with the new contentVisibility windowing mode.

Walkthrough video

For a more interactive tour of the new features, watch the video below:

Try it in your browser

If you would like to try the new release in your browser, click on the following link:

Acknowledgments

Thanks to Bloomberg for funding the work on JupyterLite at QuantStack, and for their ongoing support for JupyterLite in general.

Many thanks to all the contributors to JupyterLite. The list below is based on GitHub usernames for the 0.7.0 release:

New contributors: @rgaiacs, @tan-i-ham
Returning contributors: @DerThorsten, @bollwyvl, @diegofcornejo, @ianthomas23, @jtpio, @krassowski, @martinRenou

Thank you to the extended group of contributors in Jupyter Frontends and related project in the Jupyter ecosystem 💛

GNU Octave Meets JupyterLite: Compute Anywhere, Anytime!

2025-10-16T15:04:00+00:00

We are thrilled to announce the newest member of our JupyterLite kernel ecosystem: Xeus-Octave. Xeus-Octave allows you to run GNU Octave code directly on your browser. GNU Octave is a free and open-source Scientific Programming Language that can be used to run Matlab scripts. In this article, we present the challenges encountered when targeting WebAssembly, the current state of the Xeus-Octave kernel, and the future plans for expanding the GNU Octave ecosystem.

Earlier this year, we introduced the JupyterLite kernel for R, Xeus-R-Lite. Much like R, cross-compiling GNU Octave to WebAssembly required the same custom toolchain to enable the compilation of Fortran code, combining LLVM Flang and Emscripten.

Similar to many other mathematically oriented language packages, GNU Octave requires a BLAS/LAPACK implementation. Fortunately, OpenBLAS and the Netlib implementations of BLAS/LAPACK had already been added to the emscripten-forge WebAssembly distribution. Initially, OpenBLAS was the preferred implementation, but for the successful compilation of Octave, Netlib LAPACK was selected as it presented fewer hurdles during the build process.

Cross-Compilation of GNU Octave

One of the complications of cross-compiling Octave to WebAssembly, which had not been encountered with the R source code, was the extensive use of Fortran common symbols blocks in the internal libraries of Octave such as odepack.

C Source: liboctave/external/odepack/slsode.f
C-----------------------------------------------------------------------
C The following internal Common block contains
C (a) variables which are local to any subroutine but whose values must
C     be preserved between calls to the routine ("own" variables), and
C (b) variables which are communicated between subroutines.
C The block SLS001 is declared in subroutines SLSODE, SINTDY, SSTODE,
C SPREPJ, and SSOLSY.
C Groups of variables are replaced by dummy arrays in the Common
C declarations in routines where those variables are not used.
C-----------------------------------------------------------------------
     COMMON /SLS001/ CONIT, CRATE, EL(13), ELCO(13,12),
    1   HOLD, RMAX, TESCO(3,12),
    1   CCMAX, EL0, H, HMIN, HMXI, HU, RC, TN, UROUND,
    2   INIT, MXSTEP, MXHNIL, NHNIL, NSLAST, NYH,
    3   IALTH, IPUP, LMAX, MEO, NQNYH, NSLP,
    3   ICF, IERPJ, IERSL, JCUR, JSTART, KFLAG, L,
    4   LYH, LEWT, LACOR, LSAVF, LWM, LIWM, METH, MITER,
    5   MAXORD, MAXCOR, MSBP, MXNCF, N, NQ, NST, NFE, NJE, NQU

Initially, it was not possible to cross-compile these common blocks to WebAssembly because the latest version of LLVM (v20 at the time of testing) did not support common symbol linkage.

// Source: llvm/lib/MC/MCWasmStreamer.cpp
void MCWasmStreamer::emitCommonSymbol(MCSymbol *S, uint64_t Size,
                                      Align ByteAlignment) {
  llvm_unreachable("Common symbols are not yet implemented for Wasm");
}

As a temporary solution, LLVM was patched with the help of Serge Guelton to simulate common symbols as weak symbols.

void MCWasmStreamer::emitCommonSymbol(MCSymbol *S, uint64_t Size,
                                      Align ByteAlignment) {
-  llvm_unreachable("Common symbols are not yet implemented for Wasm");
+  auto *Symbol = cast<mcsymbolwasm>(S);
+  getAssembler().registerSymbol(*Symbol);
+  Symbol->setWeak(true);
+  Symbol->setExternal(true);
}

A proper solution to enable support of common symbols is currently in progress and will likely be included in the next release of LLVM v22 (see llvm-project/pull/151478). For curious readers, the patched version of LLVM can be found here (linux only).

In addition to the patches for LLVM, GNU Octave required a few minor modifications to target WebAssembly; mainly this entailed disabling the GUI functionalities and consolidating the Fortran function signatures and calling conventions. A full list of patches can be found in the recipe directory on emscripten-forge.

Xeus-Octave

Once GNU Octave had been successfully packaged for WebAssembly, bringing Xeus-Octave to JupyterLite was a simple matter of adding a recipe to emscripten-forge!

Try Xeus-Octave in JupyterLite!

Future Work

For our next steps, the team is planning on expanding the Octave ecosystem by adding Octave packages to both conda-forge and emscripten-forge. The packaging work will require defining a process where Octave packages can be installed in predetermined conda environments, perhaps with some minor modifications to the existing pkg utility.

About the Author

Isabel Paredes, who led the charge on bringing GNU Octave to emscripten-forge, is a senior scientific software developer at QuantStack. Prior to working on this project, she focused on porting the R programming language and the Robot Operating System (ROS) framework to WebAssembly.

Acknowledgments

This project synthesizes work from many open-source contributors.

Emscripten-forge, the distribution of conda packages for WebAssembly, was created by Thorsten Beier, who continues to lead the project. Many recipes were contributed by Isabel Paredes, Anutosh Bhat, Martin Renou, Ian Thomas, Wolf Vollprecht, and Johan Mabille.
JupyterLite, the Jupyter distribution that runs entirely in the web browser, was created by Jeremy Tuloup.
Xeus, the C++ library implementing the Jupyter kernel protocol, enabling a custom communication layer, and is foundational to kernels like xeus-r, xeus-python, running in JupyterLite, was created by Johan Mabille and is maintained by a broader team including Martin Renou, Sylvain Corlay, and Thorsten Beier, who worked on the first integration with JupyterLite.
Xeus-Octave, the Xeus-based Jupyter kernel for GNU Octave, was created by Giulio Girardi and Antoine Prouvost.

JupyterLite 0.6.0 is released! 🎉

2025-06-12T15:04:00+00:00

JupyterLite is an unofficial Jupyter distribution that runs entirely in the web browser without any server components. Deployment and hosting are easy as JupyterLite sites are just static websites.

The new 0.6.0 release includes a number of new features, bug fixes, and enhancements. This release also brings significant improvements to the user experience and new customization options for JupyterLite deployments.

Interactive Input Support

Support for kernel stdin requests is now available, enabling interactive input functions like Python’s input()and getpass() in notebooks. This fixes a long standing limitation of JupyterLite when executing the following code:

name = input("What is your name? ")
print(f"Hello {name}!")

Using input() and getpass() in a JupyterLite notebook

Since input()is used quite extensively in introductory Python courses, this new feature should help make teaching with JupyterLite easier!

New REPL Options

The REPL exposes new options as URL parameters:

promptCellPosition — place the prompt cell to the top, left, right or bottom
clearCodeContentOnExecute — when disabled, the code submitted for execution remains in the code editor, allowing for further edits.
hideCodeInput — when enabled, only the execution output is shown in the console.
clearCellsOnExecute — when enabled, only the last cell is displayed.
showBanner — when disabled, hide the banner for the kernel

Toggling all the new options transforms the console into an interactive editor resembling an ephemeral notebook with a single cell.

A single executable cell in JupyterLite

In addition to these URL parameters, the toolbar includes new items to:

Execute code
Restart the kernel
Clear the cells
Switch the kernel

Check out the REPL documentation for more details on how to use these parameters.

Kernel Indicator and Logs

A new notebook toolbar item has been added to show the kernel status with three different states:

Loading: the kernel is starting or performing some actions
Success: the kernel is ready to execute code
Failure: an error occurred while starting the kernel or during execution, and likely requires a restart of the kernel

This new toolbar item gives users better visibility into the kernel’s status and allows them to view the kernel logs by clicking on the toolbar item to open the log console.

Kernel logs can help troubleshoot JupyterLite issues

Clear Browser Data

By default JupyterLite stores user-created notebooks and settings in the browser.

In previous versions, users had to manually clear the data using the browser developer tools. With JupyterLite 0.6.0 it is now possible to clear the browser data from the UI by clicking on the Help > Clear Browser Data menu item. The confirmation dialog will show options to clear settings and contents.

The confirmation dialog for clearing browser data

Loading indicator

A new indicator has been added to let users know JupyterLite is currently starting up, which is useful for deployments that take some time to load, especially on slow connections.

By default, the loading indicator is only visible in the JupyterLab application (not for Jupyter Notebook or REPL). If you would like to enable or disable the indicator for some or all applications, check out the guide in the documentation.

The loading indicator lets users know something is happening when the page is loaded

Settings import and export

Settings can now be exported to an overrides.json file from the Settings Editor. This file can then be used to pre-configure defaults in deployments or to restore settings.

This allows users to interact with a JupyterLite deployment, make a couple of changes to the settings, and export them to an overrides.json that can be then included in a JupyterLite deployment, or imported in another one.

The new export and import buttons in the Settings Editor

Plugin Manager

Open the command palette and search for Advanced Plugin Manager to open the plugin manager. With the plugin manager, users can:

View active plugins in the running JupyterLite environment
Understand dependency relationships between plugins
Gain better visibility into the configuration of their environment

The plugin manager lists active plugins in a JupyterLite deployment

Improved Multi-site Contents Management

The default in-browser storage is now scoped using the baseUrl of the deployment. This allows hosting multiple sites under the same domain, and keeps user created files isolated from each other.

For example if two sites are hosted on GitHub Pages and available under the following URLs:

In practice this fixes the issue where users would create new files in one site, and they would show up in another site hosted under the same domain.

Multi-Tab File System Access

Using JupyterLite in multiple browser tabs at the same time should now result in less issues, in particular when interacting with the file system.

Extension system

In previous versions, JupyterLite was creating a separate application to register “server” extensions. Examples of such extensions are the different managers (sessions, kernels, settings, contents) but also the actual kernels (Pyodide, Xeus Python). This was not ideal because it introduced a separate namespace for these extensions, and extension authors had to configure their extension to be either a regular JupyterLab extension or a JupyterLite “server” extension.

Starting with JupyterLite 0.6.0, all extensions are now registered at the same level as regular JupyterLab extensions, making use of the new ServiceManagerPlugin type of extension introduced in JupyterLab 4.4.

JupyterLab 4.4 and Notebook 7.4

JupyterLite 0.6.0 is built on top of JupyterLab 4.4 and Notebook 7.4, and brings many of the respective improvements and bug fixes. Check out the announcement blog post to learn more.

Kernel and other updates

In addition to the JupyterLite 0.6.0 release, the Pyodide and Xeus Python kernels have also been updated to be compatible with the latest release.

Other components of the stack such as Voici and thebe-lite will also soon be updated.

Closing the gap with JupyterLab

As mentioned above, JupyterLab 4.4 introduced the ability to replace some of the core ServiceManager plugins responsible for interacting with the server, such as the kernel and session managers.

This allows JupyterLite to progressively become a set of JupyterLab extensions that can be integrated in regular JupyterLab instances.

Using in-browser and regular kernels together

⚠️ This is still very experimental!

An example of such integration is the jupyterlab-hybrid-kernels extension.

This extension allows using both in-browser (JupyterLite) and regular Jupyter kernels together in the same JupyterLab session.

There is also some work happening to explore automatically promoting in-browser kernels as regular kernels when some computations are not possible in the browser, or when some modules are not available.

Promoting in-browser as regular kernels

Migrating to 0.6.0

If you maintain a JupyterLite deployment and would like to update to the latest version, check out the migration guide.

Walkthrough video

For a more interactive tour of the new features, watch the video below:

Try it in your browser

If you would like to try the new features in your browser, click on the following link:

Acknowledgments

The work on JupyterLite at QuantStack was contributed by Anastasia Sliusar, Ian Thomas, Jeremy Tuloup, Martin Renou and Thorsten Beier.

Thanks to Bloomberg for funding this work and for their ongoing support for JupyterLite in general.

Thanks to the Bill & Melinda Gates Foundation (through a grant to CourseKata) for funding the work on the interactive input feature.

Many thanks to all the contributors to JupyterLite, Jupyter Frontends and related project in the Jupyter ecosystem (list below is based on GitHub usernames):

R in the Browser: Announcing Our WebAssembly Distribution

2025-02-28T08:31:00+00:00

In the past few months, QuantStack has received funding from the Bill & Melinda Gates Foundation through a grant to CourseKata to develop support for the R programming language in JupyterLite and the Emscripten-forge distribution for WebAssembly.

Today, we are thrilled to announce the availability of the R programming language in the Emscripten-Forge distribution for WebAssembly, which enables R workflows in JupyterLite through the Xeus-R Jupyter kernel.

JupyterLite with an R Jupyter notebook in use

To experience R in JupyterLite, simply click on the link below:

In this article, we present the details of our efforts to enable R workflows in JupyterLite. We cover the challenges encountered in packaging R and its dependencies for this platform, the solutions we implemented, and the process of handling R mamba packages on the frontend.

Why WebAssembly? Scaling scientific computing workflows in Jupyter to millions of users

The main challenge in scaling Jupyter deployments lies in providing a live computing environment on the server side for each user session.

While Kubernetes-based JupyterHub deployments have been successfully implemented at a university scale (such as the UC Berkeley Data 8 class, or the JupyterHub deployment of Université Paris Saclay), they demand substantial computing resources and a skilled DevOps team to achieve and maintain this level of scalability.

In contrast, JupyterLite represents a fundamentally different paradigm. As a browser-based distribution of Jupyter, it runs language kernels directly in the browser, enabling significantly greater scalability and ease of deployment. Notable JupyterLite-based applications include:

A JupyterLite console integrated into NumPy’s front page, providing immediate access to NumPy functionality without requiring installation.
A similar console application on SymPy’s project page, fully hosted statically.
The official Jupyter website¹.
The examples in Scikit-Learn’s documentation.

These examples illustrate how WebAssembly can be transformative by providing ready-to-use computing environments for scientific workflows, in documentation, blog posts, and scientific communications. The WebAssembly environments are made available to the hundreds of thousands of monthly visitors of these websites without requiring any computing resources on the backend.

JupyterLite deployments displayed on the NumPy, SymPy, and Jupyter websites

[1] Even though it powers the deployment of Jupyter on the main Jupyter website, JupyterLite is not an officially sanctioned Jupyter project.

Beyond Python, enabling R in the browser, and more

While the initial focus of the JupyterLite team has been on the Python programming language, the JupyterLite infrastructure was designed to be language-agnostic from the outset. The same principle applies to the package management stack we have been contributing to over the past few years, namely, mamba and conda-forge.

When we began targeting the WebAssembly platform, we chose to build our efforts on the mamba and conda-forge ecosystem. This decision allowed us to provide customizable environments for WebAssembly and expand beyond Python. This enabled applications such as the JupyterLite terminal, created by Ian Thomas, which comprises a bash-like shell written in TypeScript called Cockle, and WebAssembly builds of native shell commands such as cat, grep, ls, and vim. You can read the earlier announcement introducing the JupyterLite terminal.

Today, we are excited to reveal the availability of R in emscripten-forge, enabling Jupyter kernels such as Xeus-R to be used in JupyterLite.

With the addition of R, emscripten-forge now provides a unified packaging solution for Python, R, and terminal applications for WebAssembly. This covers the scopes of Pyodide (a Python distribution for WebAssembly), WebR (an R distribution for WebAssembly), and Sandbox.bio (a shell emulator with WebAssembly commands).

Building R for Emscripten-forge

Emscripten-forge is a GitHub organization containing recipes to build conda packages for the emscripten-wasm32 platform; it is also the first distribution of conda packages targeting this platform. It is built upon a modernized stack, leveraging rattler-build (the successor to the conda-build package builder) and mamba. The emscripten-forge project, which was created and is still led by Thorsten Beier, is now a team effort covering a broad range of packages.

In order to build R with emscripten-forge, we first required a toolchain capable of converting Fortran and C/C++ code into WebAssembly. Since R relies on BLAS and LAPACK (which are written in Fortran) and many essential R packages wrap native libraries that use Fortran, this conversion capability was crucial.

Fortran

By default, the emscripten-forge toolchain can cross-compile any C/C++ packages into WebAssembly; however, the first challenge in building the R stack was expanding the toolchain to also compile Fortran code. The two compilers that we considered for this task are LFortran and Flang.

LFortran is a compiler built on top of LLVM and designed from the ground up as a cross-compiler. Despite its potential, LFortran is still in its early stages compared to Flang and does not yet fully support all Fortran features.
LLVM Flang is the Fortran compiler of the LLVM project. Unfortunately, it does not support cross-compilation.

Working with Serge Guelton and Kerim Birgi, we initially experimented with the LFortran compiler and contributed to addressing issues encountered when building Netlib LAPACK. The BLAS implementation from this package served as a valuable testing ground since BLAS is one of the core dependencies for R.

After careful consideration, we found that Flang, with its ability to compile a wider variety of Fortran projects, brought us closer to building the Fortran components of R to WebAssembly. George Stagg, the main developer of the WebR project, has written a detailed article on using Flang to produce WebAssembly, which was adapted to the (then) latest version of LLVM (v18). Inspired by George Stagg’s endeavors, Serge posted upstream contributions to the Flang project (#99465, #99822, #101242, #105589), resolving issues with 32-bit platforms that were impacting our effort to support WebAssembly. All of these changes will be included in LLVM/Flang 20.0.

The remaining patches which cannot be merged upstream at this point involve:

(1) enabling code generation that targets WebAssembly (198c0e1),
(2) encoding target-specific size definitions for various data types given that the host and target platforms have different architectures (1da66cd), and
(3) disabling support for 128-bit floating-point types (f20c7c0).

A version of (2) that could be contributed upstream is in the works, which would be one step closer to making WebAssembly an official target for Flang. Additionally, (3) will no longer be needed starting with Flang v20.

These patches were integrated by Axel Obermeier into the Flang build recipe for the conda-forge distribution, making the modified build accessible to everyone. It can be installed on Linux with mamba or micromamba by executing:

micromamba install conda-forge/label/emscripten::flang libllvm19 --no-channel-priority

The final ingredient for our toolchain involved creating a compatible Fortran runtime library. Since Flang implements its runtime library in C/C++, compiling this library with Emscripten proved to be straightforward. We added a recipe for libflang to emscripten-forge, which packages the runtime library and includes all the aforementioned patches.

In the following example, we invoke Flang on a simple Fortran script, and execute the resulting JavaScript and WebAssembly with NodeJS.

> ls
hello.f90  libFortranRuntime.a
> cat hello.f90
File: hello.f90
program hello
 print *, “Hello, Fortran!”
end program hello
> source ~/emsdk/emsdk_env.sh
> flang-new --target=wasm32-unknown-emscripten -c hello.f90 -o hello.o
> emcc hello.o libFortranRuntime.a -o hello.js
> ls
hello.f90  hello.js  hello.o  hello.wasm  libFortranRuntime.a
> node hello.js
Hello, Fortran!

With a working Fortran-to-WebAssembly toolchain, we managed to compile BLAS and LAPACK (See the LAPACK recipe). But before we could get started with building R, we needed to tackle the remaining R dependencies.

Walking up the stack

In R (v4.4), there are a handful of dependencies that are required to provide basic functionality; these are: libiconv, zlib, bzip2, xz, pcre2, and libcurl. Thanks to the packaging efforts led by Thorsten Beier and Wolf Vollprecht, these dependencies are available on emscripten-forge with the exception of libcurl. Because of its socket-based networking architecture and reliance on system-level resource access, libcurl faces fundamental incompatibilities with WebAssembly’s sandboxed environment constraints. Therefore, libcurl had to be disabled in the R source code. As a consequence, downstream R packages which depend on libcurl cannot be ported to WebAssembly until a suitable libcurl replacement is available.

Apart from the core dependencies, R also requires a BLAS implementation. Although external BLAS libraries can be used with R, the R code base contains linear algebra routines from Netlib BLAS and a subset of LAPACK where both libraries are written in C and Fortran. To simplify configuration, we opted for these internal implementations instead of using external BLAS and LAPACK libraries.

Furthermore, several key optional dependencies were cross-compiled to WebAssembly to enhance R’s graphical capabilities; these include libpng, libtiff, cairo, and pango, along with their respective subdependencies. One particularly challenging aspect of packaging these libraries was the cross-compilation of glib, which both cairo and pango depend on. Compiling glib was only possible thanks to the efforts of Kleis Auke Wolthuizen whose patches made glib compatible with Emscripten, and Johan Mabille who disabled multi-threading.

The R dependencies are summarized in the following table:

Table of R dependencies

Cross-compilation of R

Although R typically configures and builds seamlessly on most unix platforms, cross-compiling is not straightforward because R uses a bootstrap approach; first it creates a minimal version of R which is then used to run several R scripts to complete the build process. Bootstrapping is a challenge because the built binaries for the target platform (WebAssembly) are not executable (at least not directly) from the host platform. Therefore, the r-base package necessitates two build phases. First, we compile R for the host platform (Linux) with GCC and Flang; this generates the R and Rscript executables needed for the second phase. And then, we cross-compile to WebAssembly with Emscripten and Flang.

One of the major challenges of this setup was generating the R Data Base (.rdb) and R Data Index (.rdx) files for the internal packages of r-base (base, compiler, grDevices, graphics, grid, methods, parallel, splines, stats, stats4, tools, and utils). To accomplish this, it was necessary to dynamically load some of the internal shared libraries (tools, grDevices, graphics, utils, stats, and methods) which provide essential functionality to generate the data and index files. However, the R executables we created during the first phase of the build are incompatible with the WebAssembly shared libraries. In order to work around this, we temporarily replaced the WebAssembly libraries of the internal packages with the linux shared libraries we built during the first phase (See cross_libraries.sh). This makeshift solution is also used to cross-compile all other R packages; the setup is carried out by the activation script of the cross-r-base package (See activate-cross-r-base.sh).

Additionally, the R source code required a few modifications to enable cross-compilation to WebAssembly.

The Emscripten platform was added to select the correct configuration for the platform.
The dependency on libcurl was removed (as mentioned in the previous section) and as a consequence, the internet package which relies on libcurl was disabled.
System calls which are not compatible with our WebAssembly environment were disabled.
Cairo replaced Xlib as the default bitmap type to enable graphics.

The complete list of patches applied to R is available here: r-base patches.

The R package ecosystem

Building R itself was just the beginning. The next challenge was to provide a wide array of R packages to create a robust development environment. Fortunately, many packages are written in pure R and are available as “noarch” packages on conda-forge, making them directly compatible with emscripten-forge environments. However, for the R packages that require compilation, a package recipe needs to be created and added to emscripten-forge. Thanks to the help of Anutosh Bhat, the following packages have been compiled and are available to use.

r-askpass     r-digest    r-haven      r-magrittr  r-purrr    r-tidyr
r-base64enc   r-dplyr     r-hexbin     r-mass      r-rcpp     r-tzdb
r-bit         r-ellipsis  r-htmltools  r-matrix    r-readr    r-utf8
r-bit64       r-fansi     r-isoband    r-mgcv      r-rlang    r-vctrs
r-cachem      r-farver    r-jsonlite   r-mime      r-sp       r-vroom
r-cli         r-fastmap   r-later      r-nlme      r-stringi  r-xfun
r-colorspace  r-ggrepel   r-lattice    r-plyr      r-sys      r-yaml
r-data.table  r-glue      r-lazyeval   r-promises  r-tibble

Most of the time, cross-compiling an R package is very simple because the bulk of the work is handled by r-base. Building a package typically boils down to a single line:

$R CMD INSTALL $R_ARGS .

Occasionally, minor patches are applied to the package source code to enable the WebAssembly target platform or to simplify cross-compilation. Some R packages, such as r-nlme, contain Fortran code; for such packages, the custom flang compiler needs to be installed before the package can be cross-compiled. Should any package be needed for your use case, feel free to contribute them to emscripten-forge!

Xeus-R

Once a sufficient set of packages is available for the platform, the next step is to provide a development environment for end users. Our chosen tool for this purpose is Jupyter.

The most popular Jupyter kernel for R is IRkernel, which has been developed over several years. It includes complete ZeroMQ bindings for the R language and comprehensive coverage of the Jupyter protocol. However, since IRkernel is tied to ZeroMQ, we opted to work with the Xeus-R project instead, which was announced last year. Xeus-R was developed by Romain François in collaboration with our team and with JupyterLite in mind. It is built upon the Xeus library, which provides a native implementation of the Jupyter protocol and is adapted to work with the JupyterLite frontend.

Fortunately, the components of IRkernel responsible for the rich representation of R objects and rich display in Jupyter frontends were split into two separate R packages: IRdisplay and repr. These packages can be reused in Xeus-R. As a result, Xeus-R and IRkernel offer the same rich display functionality, ensuring that Jupyter notebooks created with one kernel will work with the other. However, Xeus-R provides a different implementation of the communication layer through jupyterlite-xeus, which enables integration with the JupyterLite stack. This integration was previously implemented for Xeus-Python and Xeus-Lua.

One key aspect of this integration is the populating of the in-memory file system used by JupyterLite kernels with the required runtime dependencies, particularly shared libraries. This process is done upon bootstrapping the kernel. For this purpose, Anastiasiia Sliusar and Martin Renou developed mambajs, which, in combination with jupyterlite-xeus, processes conda packages in the frontend and installs them in the kernel filesystem at startup. In WebAssembly, shared libraries need to be handled with special care in order to function as expected. Drawing inspiration from the Python community, we adapted the pioneering work of Pyodide to properly load shared libraries into the filesystem.

How to make a deployment with custom packages

The GitHub repository https://github.com/jupyterlite/xeus-lite-demo is a template for creating a JupyterLite deployment on GitHub pages that includes the packages specified in a conda environment.

The process is as follows:

Create a new repository from the GitHub template.
Enable the deployment on GitHub pages from a GitHub action, as shown in the README.
Edit the environment file to include the desired packages.

For example, to deploy an R kernel with coursekata installed, the environment.yml file would contain the following:

name: xeus-r
channels:
  - https://repo.mamba.pm/emscripten-forge
  - conda-forge
dependencies:
  - xeus-r
  - r-coursekata

The deployment linked at the beginning of this article was created with this template.

How to contribute

Contributors are always welcome! New R packages can be requested by opening an issue on emscripten-forge, or added directly by opening a pull request with the desired package recipe. For instructions on how to contribute, please visit https://emscripten-forge.org/.

What is in the works

Currently, we are developing the infrastructure to dynamically install emscripten-forge and conda-forge noarch packages in JupyterLite kernel environments. This will apply to all Xeus kernels that make use of these packages, such as Xeus-Python, Xeus-R, and Xeus-Lua. In the case of R, this may be directly bound to install.packages.

Additionally, we are working on more advanced features for the R kernel, including support for Jupyter interactive widgets and the split of the pure R parts of xeus-r into a separate package, which would facilitate a possible convergence with IRkernel.

Finally, other language kernels based on the same package management stack are also in the works. Stay tuned for future announcements!

About the Author

Isabel Paredes, who led the charge on bringing R to emscripten-forge, is a senior scientific software developer at QuantStack. Prior to working on this project, she focused on porting the Robot Operating System (ROS) framework to WebAssembly.

Acknowledgments

This effort brought together several endeavors from many open-source developers.

JupyterLite, the Jupyter distribution that runs entirely in the web browser, was created by Jeremy Tuloup.
Xeus, the C++ library implementing the Jupyter kernel protocol, enabling a custom communication layer, and is foundational to kernels like xeus-r, xeus-python, running in JupyterLite, was created by Johan Mabille and is maintained by a broader team including Martin Renou, Sylvain Corlay, and Thorsten Beier, who worked on the first integration with JupyterLite.
Emscripten-forge, the distribution of conda packages for WebAssembly, was created by Thorsten Beier, who continues to lead the project. Many recipes were contributed by Isabel Paredes (for the R ecosystem), but also Kerim Birgi, Anutosh Bhat, Martin Renou, Wolf Vollprecht, and Johan Mabille.
Xeus-R, the Xeus-based Jupyter kernel for R, was created by Romain François.
IRDisplay and repr are pure R packages providing rich display and rich mime type rendering of many core R types, which are used in xeus-r. These two packages stem from the IRkernel project, a Jupyter kernel for R written in R, which was started by Thomas Kluyver, and has been maintained over the years by Philipp Angerer and Jan Katins.
MambaJS, the library enabling the processing of conda packages in the frontend, was developed by Anastasiia Sliusar and Martin Renou.
Conda-forge, the main distribution of conda packages, includes a large number of “noarch” recipes, including for R packages, and is developed by a broad community of contributors worldwide.
WebR, an R distribution for WebAssembly, was created by George Stagg. Although not directly used in this project, it documented numerous patches and changes to the Flang compiler that were adapted for this effort.

Funding

The work by Isabel Paredes and other QuantStack team members on bringing R and Xeus-R to Emscripten-Forge was supported by the Bill & Melinda Gates Foundation through a grant to CourseKata. CourseKata is a nonprofit project dedicated to improving statistics and data science education through interactive, research-backed curricula that integrate professional tools like R and Jupyter notebooks. This grant was part of CourseKata’s broader mission to scale its innovative curriculum, equipping students with the skills and confidence to engage with statistics, data science, and coding in meaningful ways.

JupyterLite Terminal

2024-11-13T19:37:00+00:00

JupyterLite is an unofficial Jupyter distribution that runs entirely in the web browser without any server components. Deployment and hosting are easy as JupyterLite sites are just static websites.

JupyterLite isn’t yet as fully-featured as the more established JupyterLab and developers are always looking for ways to add new features to bridge that gap. QuantStack are therefore delighted to announce that we have been working on a new Terminal for JupyterLite.

How do you try out the JupyterLite Terminal?

Go to https://jupyterlite-terminal.vercel.app/ and click on the Terminal launcher.

What can you do with the JupyterLite Terminal?

Run shell commands such as ls and cat on the same file system as the rest of JupyterLite:

Use tab completion of command and file names, and pipes between commands:

Store and use the command history:

Change the theme settings:

You can even run lua scripts from the command line:

To list the available commands press tab in an empty prompt:

How does it work?

In JupyterLab the Terminal connects to a real shell such as bash running on the server. In JupyterLite the Terminal runs entirely within the browser with commands that are compiled to WebAssembly and glued together with TypeScript to provide bash-like functionality.

The WebAssembly commands are compiled on Emscripten-forge and automatically packaged up when you build a JupyterLite deployment using the Terminal.

You can see which Emscripten-forge packages are included in your Terminal using the cockle-config command:

What is the status of the project?

The JupyterLite Terminal is still experimental and there are lots of things it doesn’t yet do. But it is under active development and major improvements are planned for the coming months. These will include more commands, improvedbash-like shell functionality, and instructions on how to build and use your own WebAssembly commands.

Resources

JupyterLite deployment to try out the Terminal.

Github repositories:

terminal: JupyterLite extension for the Terminal.
cockle: underlying bash-like shell functionality.
recipes: Emscripten-forge recipes for WebAssembly commands.

Acknowledgements

This work was performed by Ian Thomas, Jeremy Tuloup and Thorsten Beier at QuantStack. Thanks to Bloomberg for funding this work and for their ongoing support for JupyterLite in general.

About the author

Ian Thomas is a Scientific Software Developer at QuantStack, is a core maintainer of the Open Source projects Matplotlib, Bokeh and ContourPy, and has an interest in many parts of the Jupyter ecosystem.

Embed interactive itkwidgets 3D renderings into JupyterLite deployments

2023-03-10T14:04:00+00:00

A tutorial that demonstrates a zero-server, interactive 3D rendering notebook and walks through the quick and easy configuration that can be customized to your needs.

By: Matt McCormick, Brianna Major, Jeremy Tuloup, Wei Ouyang, Stephen Aylward

Zero-install web applications have transformed the way we consume and deliver software. Browser-based interfaces facilitate rapid discovery, exploration, and universal access.

However, for research software engineers (RSEs), developing traditional software stacks for web applications is not only onerous, but those stacks may limit essential future scalability and may be even more onerous to sustain. A RSE must face difficult questions:

Who is going to pay to keep the servers online?
Who is going to pay to scale the servers for many user or datasets?
When are you going to find the time to learn and keep up-to-date with all the devops knowledge and skills required?
Who is going to maintain the system and address security vulnerabilities as they arise?
How is private data on the server managed and kept secure?

As one of my favorite professors used to say, in cases like this we can look to the advice offered by a wise doctor:

Patient: Oh, Doctor, it hurts badly when I move my knee like this.

Doctor: Stop moving your knee like that!

In some cases, components of the traditional web application software stack are necessary, and some of those components are easier, more scalable, and more sustainable than others. However, for many RSE use cases, we now can create useful web applications while avoiding traditional server-related hardships altogether.

In this tutorial, we will demonstrate how to create a zero-server JupyterLite deployment that embeds interactive 3D renderings into advanced scientific applications, such as for deep learning medical image analysis applications using MONAI.

JupyterLite is a JupyterLab distribution that runs entirely in the browser built from the ground-up using JupyterLab components and extensions. JupyterLite uses a WebAssembly-based distribution of scientific Python called Pyodide.

ITKWidgets provides interactive widgets to visualize images, point sets, and 3D geometry on the web. ITKWidgets is powered by the same WebAssembly technology. It is built on ITK-Wasm and ImJoy, a hybrid computing platform that communicates via symmetrical transparent remote procedure calls. ImJoy and ITKWidgets support browser-based Pyodide communication along with a number of additional server-client communication transport mechanisms.

In this tutorial, we will first demonstrate a zero-server, interactive 3D rendering notebook. Then, we walk through the quick and easy configuration that can be customized to your needs. Let’s get started! 🚀

0. Preliminaries

Reproduce the figure below, a rendering of medical imaging volume of an abdominal aortic stent, by running the notebook in your web browser! After the page has loaded, use the standard Shift+Enter keys to execute the Jupyter notebook cells.

a medical imaging volume of an abdominal aortic stent rendered in JupyterLite

Note that unlike other Jupyter deployments, the python code runs on your system instead of a server.

1. Create the JupyterLite environment

To build our sustainable JupyterLite deployment, we will use a Python environment that contains Python packages for:

jupyterlite
imjoy_jupyterlab_extension
Any other JupyterLab federated extensions (JupyterLab 3 extensions) that you want in your JupyterLab deployment.

Create a requirements.txt file with:

jupyterlite[all]==0.1.0b17
imjoy_jupyterlab_extension

And install the packages:

python -m pip install -r ./requirements.txt

See also the related JupyterLite extension addition documentation.

2. Add itkwidgets and other Python packages

Next, we will add itkwidgets, its dependencies, and other Python packages and their dependencies, that we wish to include into the JupyterLite configuration for deployment. These packages, along with the packages available in the Pyodide distribution, will be available in the deployed site.

Create a jupyterlite_config.json file, which specifies the locations of the itkwidgets wheel Python packages. Add other desired packages and their dependencies as follows.

{
    "PipliteAddon": {
        "piplite_urls": [
            "https://files.pythonhosted.org/packages/4c/ee/56f970ca26375176d3e4885f58471a12d5a6794bcefe8ad0ccb8d7158ca3/itkwasm-1.0b82-py3-none-any.whl",
            "https://files.pythonhosted.org/packages/6c/55/c3fc7e2b9671d15f0c0becdcb9fad6c330172988744ad6eaa17b71bace88/imjoy_rpc-0.5.16-py3-none-any.whl",
            "https://files.pythonhosted.org/packages/69/d9/5a6c8af2f4b4f49a809ae316ae4c12937d7dfda4e5b2f9e4167df5f15c0e/imjoy_utils-0.1.2-py3-none-any.whl",
            "https://files.pythonhosted.org/packages/c9/dc/3504845528418aff0b71f4b622bb0e8e12adec2d8f2c1ba21d695b9ac6e6/itkwidgets-1.0a24-py3-none-any.whl",
            "https://files.pythonhosted.org/packages/bb/3e/3667ac685ae83887b874896bcb55584797ba6b52a292df3e4b37736a9610/ngff_zarr-0.1.6-py3-none-any.whl"
        ]
    }
}

You can find links to these URLs by browsing the package on PyPI and copying the link from the Download files page for a package.

For packages that do not have a wheel on PyPI, you can provide one locally by placing them in the pypi/ directory of your JupyterLite configuration. For example, if you want to use a local version of itkwidgets instead of the version on PyPi, you could directly add this dask-image wheel to your pypi/ directory.

$ ls pypi/
pypi/dask_image-2022.9.0-py2.py3-none-any.whl

3. Add notebooks and data

Add notebooks and data you would like available in the deployment in the files/ directory. In this tutorial, we will add a Hello3DWorld.ipynb notebook.

$ ls files/
files/Hello3DWorld.ipynb

In your notebook, install additional packages in the first cell with piplite.

import piplite
await piplite.install(["itkwidgets==1.0a24"])

4. Build and deploy

Build your site with the command:

jupyter lite build

Serve the site locally with python -m http.server --directory ./_output or:

jupyter lite serve

The site can be deployed and shared with free static file hosting services such as GitHub Pages, Netlify, or Fleek.

What’s Next

In this post, we learned how to create a scalable, sustainable, zero-server Jupyter deployment that uses ITKWidgets for 3D rendering. In subsequent posts, we will discuss how to create simple, zero-server, custom web applications written in Python with PyScript.

Enjoy ITK!

Report on the JupyterLite Community Workshop 💡

2023-01-27T13:06:00+00:00

The JupyterLite Community Workshop, held at the OVHcloud headquarters in Paris, France from December 7th to December 9th, 2022, brought together a group of developers, educators, and data scientists to discuss the latest advancements in the Jupyter and Python in the browser ecosystems.

Jupyter Community Workshops are a series of community-organized events that aim to tackle challenging development and design projects, grow the community of contributors, and strengthen collaborations.

One of the main focuses of the workshop was the JupyterLite project, a Jupyter distribution built from the ground-up using JupyterLab components and extensions, allowing for very scalable deployments. It already powers inline consoles and notebooks on the websites of major projects of the PyData ecosystem, such as NumPy, SymPy, PyMC, and many more.

The workshop also gathered the main developers and contributors of the Pyodide, PyScript and Emscripten-Forge projects that enable using Python in the browser.

Highlights of the week

During the workshop, attendees had the opportunity to participate in group discussions, and split into smaller group to work on specific topics:

Pyodide, Emscripten Forge, PyScript, and more generally Python in the browser. This lead to discussions about making WebAssembly a first-class platform for the Python ecosystem, as per https://discuss.python.org/t/make-wasm-a-1st-class-platform-in-the-python-ecosystem/21798
A proof of concept for using the Language Server Protocol in JupyterLite was also presented, showcasing its potential for improving developer productivity: https://github.com/jupyterlite/jupyterlite-lsp
A presentation about Capytale and Basthon and the use of Python in the browser in the French high school system, deployed for 5000+ schools and with more than 200,000 active users per month.
Integrating JupyterLite and Pyodide in thebe, for producing interactive documents in arbitrary websites.
Another topic of work was about using the latest real-time collaboration (RTC) improvements developed upstream in JupyterLab. Enabling RTC on a static JupyterLite website will make it an even more powerful tool for remote teams and online education.

Resources

You can find the detailed notes and relevant links taken during the workshop:

JupyterLite GitHub discussion: https://github.com/jupyterlite/jupyterlite/discussions/920
Jupyter Discourse topic: https://discourse.jupyter.org/t/jupyterlite-community-workshop-2022-paris-report/17255

Acknowledgments

Overall, the JupyterLite Community Workshop provided a valuable opportunity for the community to come together and share their knowledge, ideas, and experiences.

We are really grateful to Bloomberg and Amazon Web Services for their donations to the Jupyter Community Workshops program. This event would not have been possible without their generous support.

We are also grateful to OVHcloud for hosting this workshop, and for their continued support to the Jupyter project and the NumFOCUS foundation.

Jupyter Community Workshop: JupyterLite

2022-11-10T15:45:00+00:00

We are thrilled to announce the next in-person Jupyter Community Workshop, which will focus on the JupyterLite project!

The event will be held at the OVHCloud headquarters in Paris, France, from December 7th to December 9th, 2022. Funding for travel expenses is available for attendees from academia and those from groups which are not well-represented in the Jupyter and wider tech community!

Jupyter Community Workshop are a series of community-organized events to tackle challenging development and design projects, growing the community of contributors, and strengthening collaborations.

This specific workshop will focus on the JupyterLite project, a JupyterLab distribution that runs entirely in the browser built from the ground-up using JupyterLab components and extensions. JupyterLite allows for very scalable deployments, and already powers inline consoles and notebooks on the websites of major projects of our ecosystem, such as NumPy, SymPy, Pandas, and many more.

The workshop will last three days, with hands-on discussions, hacking sessions, and technical presentations. The goal of this event is to foster collaboration and the sharing of knowledge between Jupyter maintainers and downstream library authors and power users.

Should you be interested in joining us for this workshop, please fill this form. A limited number of spots are available for this event.

We are grateful to OVHCloud for hosting this event. We are also grateful to the sponsors of the Jupyter Community Workshop series, Bloomberg and Amazon AWS.

Mamba meets JupyterLite

2022-07-14T11:19:00+00:00

JupyterLite is a Jupyter distribution that runs entirely in the web browser without any server components. To achieve this, all language kernels must also run in the browser.

JupyterLite running in the browser as a static website

A significant benefit of this approach is the ease of deployment. With JupyterLite, the only requirement to provide a live computing environment is a collection of static assets. It makes it possible to embed a console or a notebook interface on any static page or blog without having to deal with a server architecture deployment. The scalability of this approach allowed several major projects of our ecosystem (NumPy, SymPy, Pandas, PyMC, and many more) to embed interactive examples on their websites, which are visited by millions of users monthly.

JupyterLite is the easiest and most scalable way to embed an interactive console or notebook on a web page without any server component.

The most prominent JupyterLite kernel is the Pyolite Python kernel, which is based on the Pyodide distribution for WebAssembly. Beyond the CPython interpreter, Pyodide includes many popular scientific computing packages such as NumPy, Pandas, and Matplotlib. Pyodide also provides a foreign function interface (FFI) that allows calling Python from JavaScript and vice versa.

The JupyterLite inline console embedded on the SymPy project website

Pyodide — and beyond

While Pyodide provides many scientific computing packages, its monolithic distribution model does not allow to specify package versions, although versions of pure python packages installed on top can be set. Our goal is to enable the composability of computing environments allowed by package managers and to adopt the conda-forge model for large-scale software distribution crowdsourcing.

Being able to pin down package versions in an environment is a strong requirement for software reproducibility. In fact, a locked WebAssembly environment could be seen as a reproducibility time capsule. As WebAssembly is a recognized web standard, it ought to be runnable for much longer than native binary packages: these are bound to a combination of architecture and platform and will eventually require an emulator.

This is why we developed a mamba-based distribution of WebAssembly packages built with Emscripten.

Emscripten-forge

The choice of the Mamba/Conda package manager was natural. Its main strength is the conda-forge community-maintained distribution, which has become the de facto standard source of packages for scientific computing.

Beyond its solid technological foundations and the multi-platform nature of the conda-forge distribution, its main strength is its social model. It allowed for a crowdsourcing approach of the packaging problem, with a balance of separation of concerns between maintainer teams and across-the-board automation, plus an amazing maintainers community.

We plan on contributing this work to the conda-forge project, so that all recipes live in the same space.

The Mamba/Conda package manager has support for many platforms and architectures such as Linux, OS X (for both x86 and arm64), and Windows. However, the WebAssembly family of platforms is not supported yet.

Adding support for WebAssembly to mamba & conda

To create conda packages for the WebAssembly platform, we relied on the Emscripten toolchain.

We defined a new target platform for conda-build and boa, namely wasm32-unknown-emscripten for which we use the emscripten-32 shorthand name. We then associated the Emscripten compiler, wrapped in a conda package as the C/C++ compiler for this new target.
This already allowed us to build many packages, including simple libraries like bzip2 and zlib, but also more complex packages like Python.
For Python extension modules we used crossenv which can create virtual environments for cross-compiling, and cross-python which integrates crossenv into conda. All the code and recipes for cross-compilation are hosted on the emscripten-forge GitHub repository.
We then used GitHub actions to build packages with Emscripten and upload them to a package server.
Packages are hosted on a deployment of the Quetz open-source server.

With this, you can easily create an environment for the emscripten-32 target:

micromamba create -n my-env --platform=emscripten-32 \ 
    -c https://repo.mamba.pm/emscripten-forge \ 
    -c https://repo.mamba.pm/conda-forge \
    python ipython numpy jedi

Note that we not only added emscripten-forge as a channel, but also conda-forge. This means all noarch packages can be used.

Adding new packages to the emscripten-forge channel

Adding new packages is a simple procedure:

fork the repository https://github.com/emscripten-forge/recipes
create a folder for your package in recipes/recipes_emscripten/<my_package>
add a recipe.yaml for your package in recipes/recipes_emscripten/<your_package>
create a pull request containing the recipe. Once the pull request is merged, the package is automatically uploaded to the emscripten-forge channel.

Integration with JupyterLite

Even though this is a general-purpose conda-based distribution for Emscripten packages, we had one particular application in mind for this first iteration: JupyterLite. The existing Pyolite kernel is too tightly coupled with the Pyodide distribution, so we decided to go with xeus-python instead.

The main reason for picking xeus-python (over ipykernel) is that with xeus-based kernels, it is possible to override the communication layer of the kernel (switching e.g. from ZMQ to HTTP/2). In the case of JupyterLite, the implementation simply relies on direct JavaScript function calls.

You can check out our earlier blog post for more details on the JupyterLite xeus-based kernels.

Providing a complete Python development experience

Some remaining intrinsic limitations to the WebAssembly platform need to be worked around to provide a complete experience to end-users. For example, sockets cannot be created in WebAssembly, preventing the use of the default asyncio event loop implementation. Luckily, the Pyodide authors developed a custom asyncio event-loop called WebLoop: it wraps the browser event loop using the Python — JavaScript foreign function interface (FFI) provided with Pyodide.

Pyjs:

Since it is non-trivial to extract Pyodide’s FFI and use it for other projects, we created a modern Python - JavaScript FFI from scratch. This was done with the following tricks:

Pybind11 is used to call Python from C++ and vice versa,
Embind is used to call JavaScript from C++ and vice versa.

When we use Pybind11 and Embind together we can call Python from JavaScript and vice versa, with C++ as a man in the middle. This not only allows us to write a simple FFI from scratch with relatively little code but also avoids calling any low-level CPython APIs and enables using high-level constructs — like pybind11::object and emscripten::val— instead.
The code is available in the pyjs repository. The API is very similar to Pyodide’s so that it can be used as a drop-in replacement in code, like Pyodide’s WebLoop implementation.

Deployment:The xeus-python-kernel allows conda packages to be pre-installed in the Python runtime. This can be done by passing the XeusPythonEnv.packages CLI option to jupyter lite build. The following command will install NumPy, Matplotlib, and ipyleaflet:

jupyter lite build --XeusPythonEnv.packages=\
    numpy,\
    matplotlib,\
    ipyleaflet

Running the xeus-python kernel with the ipyleaflet widget in JupyterLite

More details can be found in the xeus-python-kernel GitHub repository.

What about the future?

This combination of JupyterLite and Mamba has the potential to open Jupyter to millions of additional users.
Given its scalability, ease of deployment, reproducibility, and accessibility, JupyterLite will be everywhere: countries, organizations, and schools that don’t have access to sovereign cloud infrastructure will be able to deploy Jupyter-based education platforms on servers that they truly own, without endangering the data of their students or becoming too reliant on resources that they do not control.

In the short term, we are working on the following “next steps”:

Mambalite: To support the installation of packages at runtime. Similar to Pyodide’s pip-lite, it will allow downloading packages at runtime.
Fortran: Compiling Fortran code with Emscripten is currently not supported, but it is necessary for key packages like SciPy. Pyodide relies on f2c, a Fortran-to-C converter, in conjunction with a set of patches to compile Fortran code with Emscripten. We are working on a more direct approach: compiling SciPy natively with LFortran.
Binderlite: Binder converts a repository of notebooks into an executable JupyterLab environment, making code immediately reproducible by anyone, anywhere. Emscripten-forge is the missing piece to build BinderLite, a version of Binder relying on JupyterLite instances instead of vanilla JupyterLab instances.
Rust/PyO3 support: We are working on integrating the work of the Pyodide team on Rust/PyO3 support in emscripten-forge. This will be important to build Rust extension modules like cryptography.

Credits

This was built upon the work of a much bigger crowd!

The Pyodide team

The Pyodide project was started at the Mozilla foundation by Michael Droettboom and is now maintained by Hood Chatham, Roman Yurchak, and Gyeongjae Choi.

The foundational work of the Pyodide project pioneered the use of Python in the browser and made all of the rest possible, from JupyterLite to this work.

The Emscripten team

Both Pyodide and emscripten-forge are built upon the Emscripten toolchain, which provides the foundational components to be able to meaningfully run WebAssembly programs in the browser.

The JupyterLite team

The JupyterLite project was started by Jeremy Tuloup, with significant contributions from Nick Bollweg and Martin Renou.

The Mamba Org team

The mamba ecosystem has been instrumental in making these developments possible. We use the Quetz open-source server for hosting the packages and the Boa tool to build them. In the mamba development team, we should highlight the work of Wolf Vollprecht, Johan Mabille, Joel Lamotte, and Andreas Trawöger.

The Xeus team

The xeus project was started by Johan Mabille and Sylvain Corlay. It is at the foundation of the JupyterLite integration and helped to get all the pieces together (Xeus, Mamba, Jupyter). We should especially credit the work of Martin Renou and Thorsten Beier on this integration with JupyterLite.

Acknowledgment

The work of Thorsten Beier, Johan Mabille, Martin Renou, Sylvain Corlay, Wolf Vollprecht, Joel Lamotte, and Andreas Trawoger at QuantStack was funded by Bloomberg.

About the Authors

Thorsten Beier

Thorsten Beier is a Scientific Software Engineer at QuantStack. Before joining QuantStack, he graduated in computer science at the University of Heidelberg and worked at the EMBL. As an open-source developer, Thorsten worked on a variety of projects, from xeus and xtensor in C++ to inferno, kipoi, ilastik, and napari-splineit in Python.

Martin Renou

Martin Renou is a Scientific Software Engineer at QuantStack. Before joining QuantStack, he studied at the French Aerospace Engineering School SUPAERO. He also worked at Logilab in Paris and Enthought in Cambridge. As an open-source developer at QuantStack, Martin worked on a variety of projects, from xsimd, xtensor, and xframe in C++ to ipyleaflet and ipywebrtc in Python and JavaScript.

Jupyter Everywhere

2022-03-15T15:22:00+00:00

Easily embed a console, a notebook, or a fully-fledged IDE on any web page.

In a previous blog post, we announced JupyterLite, a JupyterLab distribution that runs entirely in the web browser, backed by in-browser language kernels.

By default, JupyterLite ships with a Python kernel powered by Pyodide and IPython, bringing a wide variety of features from code completion to interactive visualizations.

The latest releases of JupyterLite now ship with a REPL application by default, that you can embed in any website.

Embed a live Python console on your website 🚀

Do you want to add an interactive code console to your website, so your visitors can run Python code directly in their browser without installing anything?

Let’s say you already have a static website up and running. This could for example be a Jekyll blog. With the JupyterLite REPL, you can embed the interactive console in your website with something as simple as the following code snippet:

<iframe
  src="https://jupyterlite.github.io/demo/repl/index.html?kernel=python&toolbar=1"
  width="100%"
  height="500px"
>
</iframe>

And there you have it, a live Python REPL embedded in your blog! 🎉

An example of embedding a live Python console in a Jekyll blog.

This example relies on the publicly available demo website deployed to GitHub Pages. However we recommend setting up your own JupyterLite deployment, so you can have full control and use custom configuration and extensions (see the Deploying your JupyterLite website section below).

Powering the NumPy documentation 🐍

The NumPy project had already been using an interactive console on the numpy.org documentation website. The previous console was powered by Thebe and mybinder.org. While this gave great flexibility and a way for users to try NumPy without installing anything on their machine, it required starting a new Jupyter Server on Binder for each user, and then waiting for a kernel to start before being able to type some code.

This setup worked for a while but started to become more difficult to maintain and operate.

With the JupyterLite-powered Python REPL, numpy.org is now able to provide an interactive code console and let anyone try NumPy in their browsers. This considerably reduces the number of resources needed and allows for a smoother and snappier user experience.

The JupyterLite REPL on numpy.org

The REPL is currently based on the JupyterLab Code Console, which gives a familiar “look and feel” to Jupyter users. Other user interfaces such as a Single Executable Cell are also being considered for the next version of the REPL.

Try Jupyter 🟠

Another recent adopter of the JupyterLite stack is the official Jupyter website.

try.jupyter.org has been using the public-facing mybinder.org deployment to let users try the different Jupyter subprojects, such as Voilà and the Xeus-based kernels.

This setup has been working nicely for many years. However, the Binder project recently faced funding issues, which drastically reduced the overall capacity of the Binder federation. This means fewer resources are available to users for their projects, and this also impacted the Try Jupyter website.

To mitigate this, we decided to create a custom JupyterLite website and use it for some of the demos on Try Jupyter. Users can then continue to try some of the Jupyter interfaces in their browsers without installing anything on their machines. As a result, the JupyterLab and Jupyter Notebook demos now point to the new JupyterLite deployment.

Launching JupyterLite from try.jupyter.org

The “Try Jupyter with JupyterLite” deployment also includes the jupyterlab-tour extension, offering a user-friendly tour of the Jupyter interface to newcomers.

Deploying your JupyterLite website 💡

Contrary to a regular Jupyter deployment, JupyterLite can be served as a simple static website without running a Python server. This makes it simpler to deploy, and cheaper to operate.

Below are some examples for deploying your own JupyterLite and Python REPL.

Deploy to GitHub Pages

GitHub Pages is one of the simplest ways to host a JupyterLite website.

This is what the demo repository available at https://github.com/jupyterlite/demo does by default. It lets you bootstrap your JupyterLite website with a few clicks, and deploy it to GitHub Pages within a couple of minutes.

Creating a JupyterLite website with just a couple of clicks

After a few minutes, your website will be ready and you can then embed your live Python console with the following snippet:

<iframe
  src="https://yourhandle.github.io/my-custom-deployment/repl/index.html?kernel=python&toolbar=1"
  width="100%"
  height="500px"
>
</iframe>

The JupyterLite REPL running on GitHub Pages

Deploy to Vercel or Netlify

Hosted platforms like Vercel and Netlify are good options to deploy a static JupyterLite website.

The REPLite project is an example deployed to Vercel, based on the following repository with some custom configuration: https://github.com/jtpio/replite

The Python REPL can be embedded with an IFrame:

<iframe src="https://replite.vercel.app/repl?kernel=python&toolbar=1" width="100%" height="100%">
</iframe>

Here we use the ?kernel=python URL parameter to automatically choose the Python kernel on startup.

Deploying to ReadTheDocs using the Sphinx extension

Going the extra mile, jupyterlite-sphinx brings the power of JupyterLite to your Sphinx documentation. It automatically creates a JupyterLite deployment in your documentation website and provides some utilities for using that deployment easily.

If you are developing software, it’s a very convenient tool to let your users test your library directly on the documentation page!

This is also really useful for Jupyter users who want to easily share their work on readthedocs.org, GitHub Pages, or any other host that supports Sphinx documentation.

Installation

You can install jupyterlite-sphinx with pip:

pip install jupyterlite-sphinx

Then add the extension to your conf.py file:

extensions = [
    'jupyterlite_sphinx',
    # And other sphinx extensions
    # ...
]

And that’s it! jupyterlite-sphinx will automatically deploy a JupyterLite website when building your docs with Sphinx.

Usage

jupyterlite-sphinx provides multiple Sphinx directives for embedding Python consoles and custom Notebooks in your documentation:

To embed a Python REPL similar to the NumPy.org one:

.. replite::
   :kernel: python
   :theme: JupyterLab Light
   :width: 100%
   :height: 600px

    print('Hello from a JupyterLite console!')

Embedding the JupyterLite REPL

To embed a full Notebook:

.. retrolite:: my_notebook.ipynb

An interactive Jupyter Notebook on the ipycanvas documentation

Finally, you might also want to embed the full JupyterLite UI:

.. jupyterlite::

Note that the notebooks are saved in the browser local storage, so any work done on those Notebooks can be retrieved later when coming back to the web page with the same browser.

Documentation

You can find the jupyterlite-sphinx documentation with live examples following this link:

jupyterlite-sphinx — JupyterLite sphinx extension documentation

Example

You can find an example of jupyterlite-sphinx being used on ReadTheDocs here:

ipycanvas: Interactive Canvas in Jupyter — ipycanvas documentation

More examples

JupyterLite can be deployed on more platforms than just the ones mentioned above. Pretty much anything that can serve static files should work!

Feel free to check out the documentation to learn more about deploying your JupyterLite website on other platforms: https://jupyterlite.readthedocs.io/en/latest/deploying.html#hosted

Jupyter Everywhere 🌐

With JupyterLite gaining rapid adoption on widely visited websites such as numpy.org and try.jupyter.org, we envision Jupyter being adopted on more websites and documentation over the next months.

We hope to bring interactive computing with Jupyter to even more people than before and make it more accessible by lowering the barrier of entry.

Because JupyterLite can easily be extended with JupyterLab extensions, we also expect more Jupyter-based deployments and applications to flourish, making good reuse of the existing components that constitute the vibrant Jupyter ecosystem 🌸

Jupyter is language agnostic and more kernels are now available in JupyterLite, for example for Lua and SQLite based on the Xeus framework. Soon Jupyter will also power the documentation and websites of other languages, not just Python.

About the authors

Martin Renou is a Scientific Software Engineer at QuantStack and a Jupyter Distinguished Contributor. Martin works on a variety of projects, from xtensor and xeus-python in C++ to ipywidgets, ipyleaflet and bqplot in Python and TypeScript.

Jeremy Tuloup is a Scientific Software Engineer at QuantStack and a Jupyter Distinguished Contributor. Maintainer and contributor of JupyterLab, Jupyter Notebook, JupyterLite, Voilà, and projects within the Jupyter ecosystem.

JupyterLite: Jupyter ❤️ WebAssembly ❤️ Python

2021-07-13T09:11:00+00:00

JupyterLite is a JupyterLab distribution that runs entirely in the web browser, backed by in-browser language kernels.

Motivation

JupyterLite is a reboot of several attempts at making a full static Jupyter distribution that runs in the browser, without having to start the Python Jupyter Server on the host machine, usually done by running jupyter lab or jupyter notebook in a terminal.

The goal of the project is to provide a lightweight computing environment accessible in a matter of seconds with a single click, in a web browser, and without having to install anything on the end-user device.

With in-browser distributions, there is no need to provision the execution environment in the backend. Since the application is mostly a set of static files, it scales more easily, and it is also easier to deploy.

JupyterLite running in the browser as a static website on ReadTheDocs

A full JupyterLab distribution running in the browser

JupyterLite is built from the ground up, reusing many JupyterLab plugins and components as is.

In addition to JupyterLab, JupyterLite also includes the RetroLab interface by default:

JupyterLite with the RetroLab interface

By reusing JupyterLab components, JupyterLite benefits from many of the upstream improvements such as new features, accessibility fixes, and upkeep improvements. The recent work on real time collaboration coming in JupyterLab 3.1 and championed by Kevin Jahns, Carlos Herrero, and Eric Charles can be enabled in JupyterLite too!

Real Time Collaboration with JupyterLite on ReadTheDocs

Pyolite, a Python kernel backed by Pyodide

Pyodide consists of the CPython 3.8 interpreter compiled to WebAssembly which allows Python to run in the browser. Many popular scientific Python packages have also been compiled and made available. In addition, Pyodide can install any Python package with a pure Python wheel from the Python Package Index (PyPI). Pyodide also includes a comprehensive foreign function interface that exposes the ecosystem of Python packages to JavaScript and the browser user interface, including the DOM, to Python.

Pyodide: Python with the scientific stack, compiled to WebAssembly

Currently at version 0.17, Pyodide has benefited from many improvements over the past years: smaller binary size, support for asyncio, and better type translations between Python and JavaScript.

JupyterLite ships by default with Pyolite, a Python kernel backed by Pyodide. Pyolite runs in a Web Worker and thus doesn’t block the main UI thread when intensive computations are executed.

IPython in the browser

Thanks to the work by Madhur Tandon in this pull request, Pyolite is now powered by IPython. This provides access to magics, code completion, rich display, interactive widgets, and many other features.

Using IPython in JupyterLite

Interactive Visualization

Many visualizations libraries such as Altair and Plotly are also supported in JupyterLite, allowing for quick and convenient figures and plots right in the browser:

Using Altair in JupyterLite

Creating Plotly figures in JupyterLite

Support for Jupyter Widgets

Jupyter Widgets rely on the Custom Messages specification of the Jupyter Protocol to send messages back and forth between the kernel and the frontend. This pull request by Martin Renou added support for Comms in the Pyolite kernel, which enabled many of the existing core and third-party Jupyter Widgets to work out of the box in JupyterLite such as bqplot, ipyleaflet and ipycanvas.

JupyterLite comes with support for Jupyter Widgets

More than just Python

JupyterLite makes it possible to have plenty of other kernels also running in the browser. For now, the default distribution includes a JavaScript and a p5 kernel:

Multiple kernels are available in JupyterLite

Both the JavaScript and the p5 kernels run in an IFrame as the code execution sandbox. With the Jupyter display protocol, users can easily render custom animations in the browser:

The p5.js kernel in JupyterLite

Highly Customizable

Just like many existing Jupyter tools, JupyterLite can easily be configured for custom needs.

It supports the new JupyterLab prebuilt extension system added to the 3.0 release. Existing JupyterLab extensions can then easily be reused in JupyterLite too!

The JupyterLab Drawio extension running in JupyterLite

The in-browser server part of JupyterLite also follows a plugin-based approach. The server is a Lumino application without a shell and registers multiple plugins such as kernels, the contents manager or the sessions service. This plugin-based approach makes it very convenient for deployers and site administrators to swap a plugin for another one. For instance, they might want to swap the default contents manager that stores notebooks and files in the browser local storage with another plugin that would save them on AWS S3 instead.

Overview of the plugin-based architecture of JupyterLite

The modularity and flexibility of JupyterLite make it possible to easily add new kernels. For example, the Basthon kernel uses a slightly different execution model than Pyolite. It runs in the main UI thread so users can manipulate the main window DOM from within Python directly, while Pyolite runs in a Web Worker as a background thread. Both approaches have pros and cons, and the JupyterLite plugin system lets extension authors have full control over their kernels.

A prototype for running Basthon in JupyterLite is being developed in the following repository: https://framagit.org/casatir/basthon-jupyterlab/

Basthon in JupyterLite

Deploying JupyterLite

JupyterLite can easily be deployed as a static website. That’s it, no server, no complicated setup, no scalability issue. Just a plain HTTP server to serve static files to users.

This simple approach makes it possible to use a variety of options: nginx, Binder, GitHub Pages or GitLab Pages, Vercel, Netlify, and more. It can even be deployed to ReadTheDocs, which is where the default JupyterLite demo site is hosted and continuously updated.

Many of the deployment scenarios are already documented in https://jupyterlite.readthedocs.io/en/latest/deploying.html. There is also a demo template to easily deploy a custom JupyterLite website on GitHub Pages with a single click: https://github.com/jupyterlite/demo

Thanks to the work by Nicholas Bollweg in this pull request, JupyterLite now offers a jupyterlite command line tool to make custom deployments much more convenient.

One of the goals of JupyterLite is to let anyone build their custom distribution with the set of plugins and extensions they would like to use. For now, it requires using the jupyterlite CLI, but we can imagine having a more user-friendly way of exporting a custom JupyterLite website.

A mock-up for the JupyterLite Exporter

A wide range of use cases

With the ease of deployment and the low barrier to entry, JupyterLite is an excellent fit for a wide range of use cases.

In the educational space, it simplifies access to teaching materials and computing environments. Teachers and students can focus on the content of their classes without worrying about server deployments and monitoring.

With JupyterLite we also hope to enable the next wave of Jupyter users and make the whole ecosystem even more accessible to newcomers and the wider community.

For simpler and smaller-scale projects, it could even help reduce the load on mybinder.org by having a “binderlite” version of JupyterLite deployed on a CDN.

Try it online

JupyterLite can easily be tested in a web browser using the following link:

https://jupyterlite.github.io/demo

Try it locally

JupyterLite can also be used locally. First, install the CLI package with:

pip install --pre jupyterlite

Then, to build the JupyterLite website and serve it locally:

jupyter lite init
jupyter lite build
jupyter lite serve

Check out the documentation for more information about the jupyterlite command-line tool: https://jupyterlite.readthedocs.io/en/latest/developer-guide.html

Next steps

JupyterLite is still under active development, with a lot of improvements planned for the next iterations:

Improve tooling for authoring custom in-browser kernels, reusing the JupyterLab federated (prebuilt) extension system.
Improve the package management story in Pyodide with mamba and the conda-forge infrastructure.
Reuse the JupyterLite packages in other lab-based applications such as Voilà, Gator, and the Quetz Frontend.
Provide more user-friendly tools to easily export a custom JupyterLite distribution.

Getting involved

JupyterLite is under active development happening in:

the main repository: https://github.com/jupyterlite/jupyterlite
satellite repositories (kernels, demos) in the GitHub organization: https://github.com/jupyterlite

About the Author

Jeremy Tuloup is a Scientific Software Developer at QuantStack and a Jupyter Distinguished Contributor. Maintainer and contributor of JupyterLab, Voilà, and many projects within the Jupyter ecosystem.

Acknowledgments

We would like to acknowledge the previous work and the contributors who have worked on exploring the idea of Python in the notebook before us: Jyve, the Iodide notebook, Basthon, and the p5 notebook. It is also worth mentioning that similar projects exist outside of the Jupyter ecosystem, such as Observable and the Starboard Notebook.

We are grateful to Nicholas Bollweg, Madhur Tandon, Martin Renou for their contributions to JupyterLite, to Roman Yurchak and team for the work on Pyodide, Romain Casati for developing the Basthon kernel.

The work on JupyterLite by Jeremy Tuloup, Madhur Tandon, and Martin Renou was funded by QuantStack.

Jupyter Blog - JupyterLite

JupyterLite 0.8 is released! 🎉

Sharing a REPL

Refreshed Loading Screen

File System Reliability Improvements

JupyterLab 4.6 and Notebook 7.6

A Terminal in the Browser

More Kernels with jupyterlite-xeus

Python 3.14 with the Pyodide Kernel

JavaScript Kernel Improvements

Try it in your browser

Acknowledgments

A User’s Journey with Plugin Playground: From First Idea to Installable JupyterLab Extension.

Motivation

Journey At a Glance

1.0: Pick Your Starting Path

2.0: Build Extension #1 Manually

2.1: Create the plugin file

2.2: Fill the missing pieces using the right sidebar

2.3: Load it and verify behavior

Expected result:

3.0: Build with AI

3.1: Give AI a precise request

What this block does:

3.2: Use AI + deterministic inserts together

4.0: Iterate Faster Before Handoff

5.0: Share for Review

6.0: Export as Wheel and Validate in Binder

6.1: Export .whl

6.2: Install in Binder

What this block does:

7.0: Export as Zip and Create a GitHub Repository

7.1: Export .zip

7.2: Bootstrap repository

What this block does:

What’s Next

Acknowledgements

About the Developers

Further reading

JupyterLite Officially Joins Project Jupyter!

What is JupyterLite?

The Journey of JupyterLite

A Natural Fit with JupyterLab

Better integration with the rest of Jupyter

Try it in your browser

Acknowledgments and team credits

JupyterLite 0.7 is released! 🎉

Workspace Support

Audio and Video Playback

Basic Interrupt Functionality

Basic Notebook Export

File Menu Download Option

Enhanced Markdown Support

JupyterLab 4.5 and Notebook 7.5

Walkthrough video

Try it in your browser

Acknowledgments

GNU Octave Meets JupyterLite: Compute Anywhere, Anytime!

Cross-Compilation of GNU Octave

Xeus-Octave

Future Work

About the Author

Acknowledgments

JupyterLite 0.6.0 is released! 🎉

Interactive Input Support

New REPL Options

Kernel Indicator and Logs

Clear Browser Data

Loading indicator

Settings import and export

Plugin Manager

Improved Multi-site Contents Management

Multi-Tab File System Access

Extension system

JupyterLab 4.4 and Notebook 7.4

Kernel and other updates

Closing the gap with JupyterLab

Using in-browser and regular kernels together

Migrating to 0.6.0

Walkthrough video

6.1: Export `.whl`

7.1: Export `.zip`