An Experimental Port of SageMath to Browser via WebAssembly (v86)

[Yanshu Wang]

Hello.

I am happy to share my experimental port of SageMath to Browser in client side.

Try it here:

https://wangyenshu.github.io/SageMath-in-Browser/

Screenshot on Chrome:

The drawback is that it will download 1.5GB memory state file. (It can use these cache later.) And the computation is quite slow. You may always open the browser console to see its downloading status.

This is a screenshot of doing integration:

Source code and build guidance:

https://github.com/wangyenshu/SageMath-in-Browser

If you just want to host it or run a local server, simply clone this repository and upload to the static site hosting provider or run 'make run'.

Yanshu Wang

[Dima Pasechnik]

Thanks, I tried the link https://wangyenshu.github.io/SageMath-in-Browser/

in Firefox, it works, although the startup is very slow, it takes several minutes.

Then it's not too bad.

Is there a reason for using Sage 9.5, which is quite old?

Dima

--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/sage-devel/09feb2d3-91c7-423a-aefa-07acaaac755cn%40googlegroups.com.

[Yanshu Wang]

Hello Dima.

Thanks for your feedback.

SageMath-in-Browser uses the v86 emulator to run Debian-12 with SageMath installed via apt. Currently, v86 only supports emulating the x86 architecture. For SageMath installation methods on Linux, as far as I know, only the Debian apt repository provides the prebuilt binary for the x86 architecture. (Conda-forge does not provide prebuilt binary for 32-bit x86 either, as I found.) So, the version is Sage 9.5, as provided in Debian-12 repository. You can see the Dockerfile used during the build process for more details.

I can try to adjust the Dockerfile and build SageMath from source. But that could be a bit more challenging.

Yanshu Wang

[Georgi Guninski]

Nice :)
At the cost of performance, you get the security of not allowing
remote native code execution (like `system("rm -rf /ANYTHING")`) on
the server, right?

[Yanshu Wang]

Yes, you are right.

I tried to use Nix to install Sage 10.7 on x86 architecture and port to web in the same manner. But it fails. What is worse is that I heard Nix is dropping support for 32-bit platform and prebuilt pacakges (link). If anyone knows an easy method to install SageMath on x86 linux, please tell me and that could help me speed up the progress a lot.

Another benefit for WebAssembly port of SageMath is that it is cross platform and can be easily ported to Android/iOS/Windows using tools like capacitor or cordova or electron.

Yanshu Wang

[Georgi Guninski]

If you need a set of static files served from a web server, then you
can install some 32 bit i386 distro in a virtual machine (very easy if
you find the distro) and build 32 bit sage there. Probably the newer
the distro, the easier is to build sage.

[parisse]

Fascinating! 

What is the expected performance penalty? From a few tests, I'd say it's between 1 and 2 orders of magnitude slower than sage native code (25* to 50*) and 1 order of magnitude slower than Giac compiled to emscripten (https://www-fourier.univ-grenoble-alpes.fr/~parisse/xcas.html), once JIT compilation steps have been done (before that, some initial computations are very slow). Not surprising considering the fact that i386 native code must be run in the browser.

[Yanshu Wang]

Hello.

I don't know the expected performance penalty. v86 has a profiling functionality (see https://github.com/copy/v86/blob/master/docs/profiling.md). I can try to measure that if I have time. v86 is x86-to-wasm JIT, though.

Also poor internet connection can affect the performance. v86 will load binary files on demand. In the folder images/debian-9p-rootfs-flat, you can see all the files in the rootfs of the docker used in the building process are extracted and compressed with name hashed. v86 will download the corresponding files when you launch a command that uses them. You can open the developer console and try typing factor(400), you will see it downloads some bin.zst files.

Update:

I managed to compile sage 10.8 to i386 target. Now SageMath-in-Browser is using Sage 10.8. I move the built artifact to gh-pages branch and only stores sources in the main branch so that cloning this project will be faster.

I compile sage using the classical build method (see build script), this seems to be an editable-install. I cannot remove the cloned source folder even after 'make install', otherwise some links are broken and sage will not launch. How to do non-editable install using the classical build method? That can reduce the size of the rootfs.

I have not tried compiling sage using meson and conda. I guess that would be more difficult for i386 target since many packages in conda-forge do not support i386 architecture.

You can even type 'exit' and go to the directory /root/build/sage (where I cloned sage to) to run doctest:

[Georgi Guninski]

> I don't know the expected performance penalty.

To measure the time, create `file.sage` with fast code.
In bash run: time sage file.sage # for native sage
and: time emulated_sage file.sage #for JS sage

To benchmark inside sage, one possibility is:
sage: timeit("code")

[Yanshu Wang]

SageMath-in-Browser is about 2 orders of magnitude slower than native sage code.

I ran the following bench mark:

'from sage.misc.benchmark import *'

'_ = benchmark()'

Output of SageMath-in-Browser:

Output of native sage:

[parisse]

Thanks for the confirmation.  
It’s a fascinating technical milestone, but if we are looking to resources conservation,  this is clearly not the right direction...

[Tobia...@gmx.de]

This is cool! Thanks for your work.

Just as shot in the dark: perhaps the 32-bit version of archlinux allows to install all up-to-date sage dependencies. If that's the case, you could just build sage using `pip install .`, which is then non-editable.

@others: what do you think about adding this to the website as "Try SageMath", so that potential users can see if they like sage enough to install it on their PC?

[Tobia...@gmx.de]

Alternatively, one could try to see if https://github.com/container2wasm/container2wasm works to get a 64bit-based version.

[Dima Pasechnik]

On Sat, Feb 14, 2026 at 12:09 PM 'Tobia...@gmx.de' via sage-devel <sage-...@googlegroups.com> wrote:

This is cool! Thanks for your work.

Just as shot in the dark: perhaps the 32-bit version of archlinux allows to install all up-to-date sage dependencies. If that's the case, you could just build sage using `pip install .`, which is then non-editable.

@others: what do you think about adding this to the website as "Try SageMath", so that potential users can see if they like sage enough to install it on their PC?

IMHO it's too slow to be a good ad for SageMath at the moment.

By the way, WebAssembly-built sympy, https://www.sympy.org/en/shell.html, seems to be considerably faster.

I don't know why. 

On Saturday, February 14, 2026 at 3:28:10 PM UTC+1 parisse wrote:

Thanks for the confirmation.  
It’s a fascinating technical milestone, but if we are looking to resources conservation,  this is clearly not the right direction...

On Saturday, February 14, 2026 at 1:36:39 PM UTC+1 wangyen...@gmail.com wrote:

SageMath-in-Browser is about 2 orders of magnitude slower than native sage code.

I ran the following bench mark:

'from sage.misc.benchmark import *'

'_ = benchmark()'

Output of SageMath-in-Browser:

Output of native sage:

On Saturday, February 14, 2026 at 4:55:39 PM UTC+8 Georgi Guninski wrote:

> I don't know the expected performance penalty.

To measure the time, create `file.sage` with fast code.
In bash run: time sage file.sage # for native sage
and: time emulated_sage file.sage #for JS sage

To benchmark inside sage, one possibility is:
sage: timeit("code")

--

You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/sage-devel/f34f64ef-a1cf-4f40-99b6-61a4fe8520aen%40googlegroups.com.

[Yanshu Wang]

> Alternatively, one could try to see if https://github.com/container2wasm/container2wasm works to get a 64bit-based version.

Unfortunately, container2wasm will not work for image with size greater than 2GB (like SageMath). See this discussion (https://github.com/container2wasm/container2wasm/issues/230). Also 64-bit wasm can be even slower than 32-bit.

> By the way, WebAssembly-built sympy, https://www.sympy.org/en/shell.html, seems to be considerably faster.

I think this is because WebAssembly-built sympy uses pyodide, which is compiled to wasm directly, so it runs almost natively in your CPU. However, SageMath-in-Browser runs code in the CPU emulated by v86. I think in order to achieve the same performance as WebAssembly-built sympy, SageMath must be compiled directly to wasm using tools like emscripten. But that is far more challenging than the current SageMath-in-Browser approach.

[Yanshu Wang]

As a proof of concept and an application of this WebAssembly port, I create a cordova/electron offline wrapper of SageMath-in-Browser for Windows x64.

You can download it from google drive: SageMath-Cordova-Wrapper-0.1.0-win-x64.zip or download the split zipped files from github release.

This should be the easiest way to install sagemath on windows: just unzip it and you can launch sagemath by executing "SageMath-Cordova-Wrapper.exe". No WSL, no

Administrator privileges needed and completely portable. However, similar to SageMath-in-Browser, its performance is worse than a native installation.

Souce:

https://github.com/wangyenshu/sagemath-cordova-wrapper

[parisse]

On Sunday, February 15, 2026 at 2:22:32 AM UTC+1 wangyen...@gmail.com wrote:

I think this is because WebAssembly-built sympy uses pyodide, which is compiled to wasm directly, so it runs almost natively in your CPU. However, SageMath-in-Browser runs code in the CPU emulated by v86. I think in order to achieve the same performance as WebAssembly-built sympy, SageMath must be compiled directly to wasm using tools like emscripten. But that is far more challenging than the current SageMath-in-Browser approach.

 

CPython can be compiled to wasm by emscripten, therefore you get an acceptable perfomance penalty. For example inverting a 50x50 matrix with integer coefficients in -99..99 takes about 3 seconds on my laptop with sympy live, vs about 1.3 second (native python3 interpreter) vs 0.01s (Giac/Xcas compiled to wasm) vs 0.004s (sage native) or 0.0012s (Giac/Xcas native). But sympy remains Python interpreted code and does not include advanced maths algorithms, so it will be slow except for small inputs.

[Tobia...@gmx.de]

As a continuation of the experiment, I tried to see what packages are missing from emscripten-forge to satisfy all of sage's dependencies (see https://github.com/sagemath/sage/pull/41680). Here is the result:

```

error    libmamba Could not solve for environment specs
    The following packages are incompatible
    ├─ 4ti2 =* * does not exist (perhaps a typo or a missing channel);
    ├─ autoconf =* * does not exist (perhaps a typo or a missing channel);
    ├─ automake =* * does not exist (perhaps a typo or a missing channel);
    ├─ bliss =* * does not exist (perhaps a typo or a missing channel);
    ├─ c-compiler =* * does not exist (perhaps a typo or a missing channel);
    ├─ cddlib =* * does not exist (perhaps a typo or a missing channel);
    ├─ cibuildwheel =* * is not installable because it requires
    │  └─ bashlex =* *, which does not exist (perhaps a missing channel);
    ├─ cliquer =* * does not exist (perhaps a typo or a missing channel);
    ├─ cxx-compiler =* * does not exist (perhaps a typo or a missing channel);
    ├─ cypari2 >=2.2.1 * does not exist (perhaps a typo or a missing channel);
    ├─ ecl =* * does not exist (perhaps a typo or a missing channel);
    ├─ eclib =* * does not exist (perhaps a typo or a missing channel);
    ├─ ecm =* * does not exist (perhaps a typo or a missing channel);
    ├─ fflas-ffpack =* * does not exist (perhaps a typo or a missing channel);
    ├─ fortran-compiler =* * does not exist (perhaps a typo or a missing channel);
    ├─ fpylll >=0.5.9 * does not exist (perhaps a typo or a missing channel);
    ├─ gap-defaults =* * does not exist (perhaps a typo or a missing channel);
    ├─ gfan =* * does not exist (perhaps a typo or a missing channel);
    ├─ givaro =* * does not exist (perhaps a typo or a missing channel);
    ├─ iml =* * does not exist (perhaps a typo or a missing channel);
    ├─ ipykernel >=5.2.1 * is not installable because there are no viable options
    │  ├─ ipykernel [6.15.0|6.15.1|...|6.29.5] would require
    │  │  └─ psutil =* *, which does not exist (perhaps a missing channel);
    │  ├─ ipykernel [6.30.0|6.30.1|...|7.2.0] would require
    │  │  └─ __win =* *, which is missing on the system;
    │  ├─ ipykernel [6.30.0|6.30.1|...|7.2.0] would require
    │  │  └─ __linux =* *, which is missing on the system;
    │  └─ ipykernel [6.30.0|6.30.1|...|7.2.0] would require
    │     └─ __osx =* *, which is missing on the system;
    ├─ jupyter-sphinx =* * is not installable because there are no viable options
    │  ├─ jupyter-sphinx [0.3.2|0.4.0|0.5.3] would require
    │  │  └─ nbconvert >=5.5 * but there are no viable options
    │  │     ├─ nbconvert [6.4.5|6.5.0|...|7.9.2] would require
    │  │     │  └─ nbconvert-pandoc [==6.4.5 pyhd8ed1ab_2|==6.5.0 pyhd8ed1ab_0|...|==7.9.2 pyhd8ed1ab_0], which requires
    │  │     │     └─ pandoc =* *, which does not exist (perhaps a missing channel);
    │  │     ├─ nbconvert [5.5.0|5.6.0] would require
    │  │     │  └─ pandoc >=1.12.1,<3.0.0 *, which does not exist (perhaps a missing channel);
    │  │     ├─ nbconvert 5.6.1 would require
    │  │     │  └─ jinja2 >=2.4,<3a0 * but there are no viable options
    │  │     │     ├─ jinja2 [2.10|2.10.1|...|2.11.3] would require
    │  │     │     │  └─ markupsafe >=0.23,<2 *, which does not exist (perhaps a missing channel);
    │  │     │     └─ jinja2 2.11.3 would require
    │  │     │        └─ markupsafe >=0.23,<2.1 *, which does not exist (perhaps a missing channel);
    │  │     └─ nbconvert 7.0.0 would require
    │  │        └─ lxml <5.2.0a0 *, which does not exist (perhaps a missing channel);
    │  ├─ jupyter-sphinx 0.5.3 would require
    │  │  └─ ipykernel >=4.5.1 *, which cannot be installed (as previously explained);
    │  └─ jupyter-sphinx [0.2.4|0.3.1|0.3.2] would require
    │     └─ sphinx >=2,<4 *, which requires
    │        └─ docutils >=0.12,<0.17 *, which does not exist (perhaps a missing channel);
    ├─ jupyter_client =* * is not installable because there are no viable options
    │  ├─ jupyter_client [7.3.2|7.3.3|...|8.6.3] would require
    │  │  └─ pyzmq >=23.0 *, which does not exist (perhaps a missing channel);
    │  ├─ jupyter_client [8.7.0|8.8.0] would require
    │  │  └─ pyzmq >=25.0 *, which does not exist (perhaps a missing channel);
    │  ├─ jupyter_client [5.2.3|5.2.4|...|7.1.2] would require
    │  │  └─ pyzmq >=13 *, which does not exist (perhaps a missing channel);
    │  └─ jupyter_client [7.2.0|7.2.1|7.2.2|7.3.0|7.3.1] would require
    │     └─ pyzmq >=22.3 *, which does not exist (perhaps a missing channel);
    ├─ lcalc =* * does not exist (perhaps a typo or a missing channel);
    ├─ libblas =* *_openblas does not exist (perhaps a typo or a missing channel);
    ├─ libbraiding =* * does not exist (perhaps a typo or a missing channel);
    ├─ libbrial =* * does not exist (perhaps a typo or a missing channel);
    ├─ libflint =* * does not exist (perhaps a typo or a missing channel);
    ├─ libgd =* * does not exist (perhaps a typo or a missing channel);
    ├─ libhomfly =* * does not exist (perhaps a typo or a missing channel);
    ├─ linbox =* * does not exist (perhaps a typo or a missing channel);
    ├─ lrslib =* * does not exist (perhaps a typo or a missing channel);
    ├─ m4ri =* * does not exist (perhaps a typo or a missing channel);
    ├─ m4rie =* * does not exist (perhaps a typo or a missing channel);
    ├─ maxima <5.48.0 * does not exist (perhaps a typo or a missing channel);
    ├─ meson-python =* * is not installable because it requires
    │  └─ ninja =* *, which does not exist (perhaps a missing channel);
    ├─ meson =* * is not installable because it requires
    │  └─ ninja >=1.8.2 *, which does not exist (perhaps a missing channel);
    ├─ mpfi =* * does not exist (perhaps a typo or a missing channel);
    ├─ nauty =* * does not exist (perhaps a typo or a missing channel);
    ├─ ninja =* * does not exist (perhaps a typo or a missing channel);
    ├─ ntl =* * does not exist (perhaps a typo or a missing channel);
    ├─ palp =* * does not exist (perhaps a typo or a missing channel);
    ├─ pari =* * does not exist (perhaps a typo or a missing channel);
    ├─ pkg-config =* * does not exist (perhaps a typo or a missing channel);
    ├─ pkgconfig =* * is not installable because it requires
    │  └─ pkg-config =* *, which does not exist (perhaps a missing channel);
    ├─ planarity =* * does not exist (perhaps a typo or a missing channel);
    ├─ pplpy >=0.8.6 * does not exist (perhaps a typo or a missing channel);
    ├─ primecount =* * does not exist (perhaps a typo or a missing channel);
    ├─ primecountpy =* * does not exist (perhaps a typo or a missing channel);
    ├─ primesieve =* * does not exist (perhaps a typo or a missing channel);
    ├─ pycosat >=0.6.3 * does not exist (perhaps a typo or a missing channel);
    ├─ python-lrcalc [=* *|~=2.1 *] does not exist (perhaps a typo or a missing channel);
    ├─ python =3.12 * does not exist (perhaps a typo or a missing channel);
    ├─ rpy2 >=3.3 * does not exist (perhaps a typo or a missing channel);
    ├─ ruff =* * does not exist (perhaps a typo or a missing channel);
    ├─ rw =* * does not exist (perhaps a typo or a missing channel);
    ├─ singular =* * does not exist (perhaps a typo or a missing channel);
    ├─ sirocco =* * does not exist (perhaps a typo or a missing channel);
    ├─ sympow =* * does not exist (perhaps a typo or a missing channel);
    ├─ tachyon =* * does not exist (perhaps a typo or a missing channel);
    ├─ ty >=0.0.12 * does not exist (perhaps a typo or a missing channel);
    └─ uv =* * does not exist (perhaps a typo or a missing channel).

```

Some of them are most likely false negative (eg python, meson-python, ninja) and a few others are no hard requirements for us (uv, ruff, jupyter stuff, autoconf). The most important ones to attack would be gap, ecl/maxima, flint, singular - at least a couple of them already provide wasm builds, so adding them to emscripten-forge doesn't seem to be impossible. If someone feels motivated to contribute those packages, I would join the effort, definitely from the side of the sage build script and CI.

[Yanshu Wang]

That is great. Just to save time, I am happy to list the existent wasm builds of the most important ones:

• gap wasm builds doc: https://github.com/gap-system/gap/tree/master/etc/emscripten
• gap wasm demo: https://wangyenshu.github.io/gap-wasm/ and web sources and some instructions: https://github.com/wangyenshu/gap-wasm/tree/gh-pages
• ecl wasm builds resources: https://turtleware.eu/posts/Common-Lisp-and-WebAssembly.html
• flint wasm builds resources: https://github.com/flintlib/python-flint/blob/main/.github/workflows/ci-emscripten.yml

As far as I know, only singular has no wasm build.