-
Notifications
You must be signed in to change notification settings - Fork 258
PyScript vs X
This page provides an overview of approaches to run Python in the browser. This should help explain why we needed PyScript and how it relates to other solutions.
- http://stromberg.dnsalias.org/~strombrg/pybrowser/python-browser.html
- My talk at Pydata Amsterdam 2016
These approaches take Python code, and then transpile that to a representation (usually JavaScript) that can be executed in the browser.
http://rapydscript.pyjeon.com/
- pre-compiler for JavaScript
- Rapydscript is not valid Python syntax, making it harder to embed in Python scripts.
- Rapydscript is implemented in JS rather than Python.
- Similar to PyScript, PyJS has a transpiler that is implemented in Python by walking the AST tree.
- Although PyJS uses its own ast parser (not the one that comes with Python).
- PyJS tries to be more like real Python, making special classes for everything. A list is not an array. This makes interfacing with other JS code harder. PyScript is "lighter" in the sense that its a way to write JS with a Python syntax; lists are arrays, dicts are objects.
- The JavaScript produced by PyJS is not particularly easy to read.
- PyJS produces bloated HTML output. Flexx can produce a single file.
- PyJS does browser detection, eek!
(this project)
Pyscript differs from the approaches in this category in that it is valid Python and can be written inline in youre regular Python modules.
https://github.com/JdeH/Transcrypt
Most similar to PyScript. Also uses ast module. Constrained to one Python version. Supports multiple inheritance.
https://github.com/pybee/batavia
A bit of an odd one, because it transpiles to Python bytecode, which can then be executed in a Bytecode interpreter written in JS.
- Runs Python bytecode in a a VM in JS.
- Is terribly slow, but may become fast when the VM gets implemented in asm.js
- Interacting with JS is not trivial.
These approaches can run Python directly in the browser.
Was designed to be used as a way to implement web apps in Python. Is like 100x or more slower that CPython though.
- Brython is implemented in JavaScript.
- You cannot do
[].push(x), but interaction with real JS objects seems smooth. Not sure if this is because a list is really an array, or because there is some smart automatic boxing/unboxing. - Python 3
- Uses a transpiler (to JavaScript) internally
Quite similar to Brython. But design goal was to use if for teaching (slowness much less of a problem).
- Skulpt is implemented in JavaScript.
- Skulpt list is not an array.
- Python 2
https://github.com/koehlma/jaspy
Supposedly similar to Brython but has features like suspendability, debugging, etc. Not exactly sure if this is a true interpreter or whether it needs some for of pre-processed input (e.g. Python bytecode), which would make it more similar to Batavia.
These approaches also work by providing an interpreter that can run code "live" in the browser, but they differ from the previous category in that the interpreter is an existing interpreter, which is compiled for the browser. Currently, the compile target is ASM.js, a subset of JS that can be executed much faster. In the future we will get Web Assembly, which will surely result in more projects in this caregory.
Take pypy code, compile using LLVM, export to ASM.js via Emscriptem.
A chrome-only project to run native code in the browser. People have demonstrated running numpy in the browser with this approach. Other browser won't support this technique though; Web Assembly is the future.
Let's compare category A (transpilers), B (interpreters) and C (compiled interpreters).
Pythonic: Category C is about as real Python as it can get, category B tries to be, but are missing some features. Category A is more like writing JS with a Pythonic twist. How Pythonic depends on the implementation.
Speed: Category C is fastest, catergory B slowest, and category A sits somewhere in between, depending on how Python it tries to be.
Memory: Category A is the lighitest. Category B takes about 1MB or a few MB. Category C takes at least 12 MB of JS to load.
When is which project a good choice?
- For running the scipy stack in the browser, only category C applies.
- For teaching purposes, having something working in the browser directly is awesome. Speed is not so much an issue. This makes category B and C (e.g. Brython, Skulpt, PypyjS) excelent choices.
- For building web apps, interpreter based approaches (B) can be used, but will be too slow to become mainstream, IMO. Compiled interpreters like PypyJS are faster, but are heavy to load. Therefore, I think transpiler based approaches will rule this domain.
- To run snippets of Python in the browser, e.g. to let the user define client-side interactivity of a visualization, transpiler-based approaches make the most sense, since the generated snippets of JS can easily be embedded in the total application.