
Brython – A Python 3 implementation for client-side web programming - gjvc
https://brython.info/
======
ascar
Javascript came a long way and despite its legacy quirks is actually quite
enjoyable with ES6. We also added tons of good tooling (like TypeScript, React
or Vue) to improve the web development experience.

While I still think, it would be nice to use a language that doesn't need 3
equal signs for sane comparisons, I wonder if Python with its strong
whitespace to code-block correlation is actually a good choice for
transmission and remote execution?

It definitely increases the size of transmitted code (tho probably by not so
much because I think files are usually transmitted gzip compressed to modern
browsers).

Are there other issues anyone can think of? It somehow gives me an uneasy
feeling even tho technically a semicolon or repeated 0x20 don't make a
difference except size.

~~~
goffi
White I agree with you about modern JS, using Python in the browser has a few
advantages:

\- it can be the same language as the backend, that's a huge advantage (no
need to change context, you can more easily have the team for backend and
frontend)

\- if you use Python elsewhere (like it's my case for multi-frontends XMPP
client), you can factorize the code

\- it's a really popular language, notably among scientists

\- I have no numbers, but I suspect that once the initial download is done and
cached, Python code should be smaller than JS equivalent

\- there is a huge ecosystem (of course JS is even bigger, but the neat thing
is that you can use both)

And probably other things I'm not thinking of right now.

~~~
zaro
> \- it can be the same language as the backend

This is already the case for Javascript :) Also you get much bigger collection
of ready to use opensource libraries, and better performance.

~~~
KaiserPro
> you get much bigger collection of ready to use opensource libraries,

bigger number, but that's because there is no (useful) standard library in JS.
Datetime for example, there are loads of libs for that in JS, some of which
are complete.

In python you just use the built in one. You bust out to a non standard lib
when you want something fancy.

~~~
speedgoose
Like doing a http request asynchronously?

~~~
JonAtkinson
`import asyncio` is a standard part of Python.

`aiohttp` is a a 3rd party package if you want a more succinct expression of
the same functionality.

------
linkdd
What is this monstrosity in the tutorial ?

>>> document <= 'Hello!' # write in the DOM

Since when the __le__ method has any side effects?

So to sum it up:

\- it runs inside the Javascript VM

\- you change the syntax by breaking the semantics

\- the import mechanisms is completely different

Is it still Python then ?

NB: Still, it's a fun project and hope you had fun making it.

~~~
wenc
Looks like the FAQ covers this question:

[https://brython.info/static_doc/en/faq.html](https://brython.info/static_doc/en/faq.html)

Quote:

Q: why use the operator <= to build the tree of DOM elements? This is not
pythonic!

A: Python has no built-in structure to manipulate trees, ie to add "child" or
"sibling" nodes to a tree node. For these operations, functions can be used;
the syntax proposed by Brython is to use operators: this is easier to type (no
parenthesis) and more readable

To add a sibling node, the operator + is used.

To add a child, the operator <= was chosen for these reasons:

* it has the shape of a left arrow; note that Python function annotations use a new operator -> that was chosen for its arrow shape

* it looks like an augmented assignment because of the equal sign

* it can't be confused with "lesser or equal" because a line with document <= elt would be a no-op if it was "lesser or equal", which is always used in a condition or as the return value of a function

* we are so used to interpret the 2 signs < and = as "lesser or equal" that we forget that they are a convention for programming languages, to replace the real sign ≤

* in Python, <= is used as an operator for sets with a different meaning than "lesser or equal"

* the sign < is often used in computer science to mean something else than "lesser than": in Python and many other languages, << means left shift; in HTML tags are enclosed with < and >

* Python uses the same operator % for very different operations: modulo and string formatting

~~~
corytheboyd
Not at all a Python user, but I don’t get how this is a valid argument at all:

> Python has no built-in structure to manipulate trees

What’s wrong with an API like appendChild etc? I know you’re just quoting the
FAQ but if anyone has an answer I am legitimately curious. I have worked with
Ruby for many years and loath cute DSLs but I always thought it was just the
Ruby community that went overboard on that shit haha

~~~
dragonwriter
> What’s wrong with an API like appendChild etc?

Verbosity vs. fluency, given the application domain, I expect is the concern.
I'd rather have fluent DSL separate from the basic language runtime, though,
so that adopting it is a separate decision from using the runtime.

------
bayesian_horse
I'm not interested in Brython, mainly because the data model is from
Javascript, not from Python.

In my opinion there are two "right" ways for Python in the browser: One would
be a bytecode interpreter in Javascript (like the discontinued Batavia
project), the other is porting CPython or PyPy to WASM (Pyodide).

Both gives you the full Python experience and potentially even full
performance.

~~~
mathgenius
Agree. Another missfire (IMO) is Transcrypt, which is javascript using a
python syntax. Total pain in the #$@! to use.

Also, there is a tiny python (micropython) that has been emscripted. I'm very
interested to try this out sometime.

------
pjmlp
Active State browser plugin is back!

[http://www.4guysfromrolla.com/webtech/082201-1.shtml](http://www.4guysfromrolla.com/webtech/082201-1.shtml)

[http://ptgmedia.pearsoncmg.com/images/0735710902/samplechapt...](http://ptgmedia.pearsoncmg.com/images/0735710902/samplechapter/0735710902.pdf)

Little by little, all plugins will be back.

~~~
toyg
I'm surprised 4guysfromrolla is still up. I remember using their ASP and PHP
tutorials in 2001...

~~~
rudasn
Wow, yes. Their articles were super helpful when I was starting up with asp
and sql around that time.

------
factorialboy
Would love to learn how Brython completes with Transcrypt
([https://www.transcrypt.org/](https://www.transcrypt.org/)) and PyJs
([http://pyjs.org/](http://pyjs.org/))

Is there a page for that?

~~~
goffi
Brython feels like a Python interpreter (it's actually transpiling to
javascript with a thin compatibility layer, cf. [https://github.com/brython-
dev/brython/wiki/How%20Brython%20...](https://github.com/brython-
dev/brython/wiki/How%20Brython%20works)), you can use Python live in the
browser, while Transcrypt transpile Python (or nearly Python, depending on
what features you activate) to Javascript ahead of time (this can be achieved
with Brython CLI too).

Brython has a better compatibility, but Transcrypt being pure javascript on
the browser should be faster (I didn't made the comparison myself though).
Both projects are complementary.

PyJS is a hostile fork (or I should say "hijack", but that's a long story) of
Pyjamas, a Python 2 to Javascript compiler. I'm not sure where they are now,
but at the time Pyjamas was Python 2 only and there was no plan to move it to
Python 3 as this would mean a full rewrite of the transpiler.

It's pretty similar to Transcrypt except that it comes with a library which is
a rewrite of GWT for Python. With that you end up writing web application in a
similar way as you would do for desktop application. I've been using Pyjamas
for years, it was working quite well (but you had to get used to some
bugs/incompatibilities with Python, and I have not experienced that with
Brython so far). About the library, while it seemed like a neat idea at the
beginning, at the end it was an experience too distant from web developing,
and meanwhile HTML and CSS improved a lot so it doesn't really makes sense
anymore.

So from my experience :

\- you want real Python 3 and being able to use it dynamically (in a live
console for instance) ==> Brython

\- you want something as fast as javascript with clean syntax of Python ==>
Transcrypt

Both work well with JS libraries, Brython in addition re-implement most of
Python standard API (but it's long to import, so it's often better to use JS
libraries or native methods).

In addition, and really subjectively, I find the Brython community really
nice, the main developer is reactive and kind.

Brython gives you real Python traceback, and you can even run pdb inside the
browser (which will block your scripts) or an Inspector (a non blocking Python
console) allowing to transfer objects between Python and Javascript for
inspection in dev tools.

edit: corrected the initial statement, Brython feels like an interpreter, but
it's actually transpiling, so you don't have such a big performance impact.

edit2: added that Brython can be compiled AOT from CLI too + precisions that I
didn't compared with Transcrypt myself

~~~
jennasys
I've been using Transcrypt for the last few months and am impressed at how
well it integrates with JS libraries. But then that was done with intention in
the design. I've been writing React+MaterialUI apps in Python and the
resulting code actually still _looks_ like the Python I know and love. I did
get pulled into the NPM/Parcel world for JS package management & minification,
but the build step is relatively painless and Transcrypt has a Parcel bundler
plug-in so there's no extra work involved to use it.

The fact that Transcrypt hasn't implemented the full standard library yet
hasn't been much of an issue for me so far either. In the very few cases where
I was missing something, I just pulled in a JS library in it's place (i.e.
deepcopy).

While using Transcrypt this way requires you to understand the APIs of the JS
libraries that you use, the code you actually write is 99% pure Python.

------
pansa2
I came across this article [0] a few days ago that compares six different ways
to run Python code in the browser.

It describes Brython as a Python-to-JavaScript compiler (as opposed to a
Python interpreter written in JavaScript) that runs on page load.

[0] [https://anvil.works/blog/python-in-the-browser-
talk](https://anvil.works/blog/python-in-the-browser-talk)

~~~
felixr
The following table from that article provides a nice overview:

[https://anvil.works/blog/img/python-in-the-browser-
talk/comp...](https://anvil.works/blog/img/python-in-the-browser-
talk/comparison-table.png)

------
joshlk
Could you compile Python to Web Webassembly instead of JavaScript? Presumably
that would have better performance.

~~~
pansa2
Statically compiling dynamically-typed Python to statically-typed WebAssembly
would be similar to how Nuitka [0] compiles Python to C. This compiled code
may be a little faster than interpreted Python, but it's still going to be
quite slow - much slower in a browser than JIT-compiled JavaScript.

AFAIK the ideal way to maximize the performance of Python in the browser would
be to JIT-compile Python code to WebAssembly. Does anyone know whether
WebAssembly implementations are able to support that?

[0] [http://nuitka.net/](http://nuitka.net/)

------
montenegrohugo
Seems super interesting, but I'm afraid at how much of a performance impact
this might have. Any benchmarks on that? I can't imagine interpreting Python
in JS to be cheap.

EDIT: nevermind, they do make a comparison here:
[https://brython.info/speed_results.html](https://brython.info/speed_results.html)

There _is_ a hit, but it doesn't seem too outrageous. Might be usable in
simple webpages for people coming from Python that don't wish to learn an
entire new language.

~~~
factorialboy
I assume there's CLI for compilation step?

~~~
goffi
AFAIK (Brython devs can correct if necessary) it's transpiled live and stored
in indexedDB, so after first run it's already transpiler.

You can also transpile using CLI to have directly JS.

edit: it's indexedDB, not localStorage

------
reactchain
The documentation could use some work - I have scoured the website and FAQ but
still don't understand how this works. Does it compile into javascript, or it
is a Python interpreter for the browser? What subset of python does it
support? What about libraries?

I recently encountered Pyodide[1], which compiles to wasm. This seems more
interesting/useful, because one can imagine running scientific computations
(for which Python is a good choice) in the browser without much of a
performance hit.

[1]: [https://github.com/iodide-project/pyodide](https://github.com/iodide-
project/pyodide)

~~~
goffi
you can check [https://github.com/brython-
dev/brython/wiki/How%20Brython%20...](https://github.com/brython-
dev/brython/wiki/How%20Brython%20works)

------
seemslegit
For the love of DOM, _why_ replace one dynamic language that is at least
optimized for by the browser by another foreign one with an intermediate layer
in between ?

~~~
cellularmitosis
Never underestimate the power of "But I already know lang X"

~~~
andybak
As well as "I already have code in lang X"

I'm hitting that at the moment with a moderately complex c# codebase that
would be really useful to run natively in the browser.

Yeah - I could rewrite it but I'd much rather not.

~~~
wdroz
Maybe Blazor[0] could be a good fit for you.

[0] -- [https://dotnet.microsoft.com/apps/aspnet/web-
apps/blazor](https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor)

~~~
andybak
Yeah. I keep meaning to dig into Blazor but it seems overwhelming at first
(especially because I'm mainly a C# dev due to Unity and a lot of the .NET
jargon is foreign to me).

There seems to be more lightweight "c# to web-assembly" routes than might be
worth investigating.

~~~
andybak
I think the complexity in Blazor might be a documentation issue. Every
tutorial and quick start I can find assume you're knee deep in the ecosystem.

------
mshenfield
I've looked into Brython and other "Python in the browser" implementations
(transcrypt.org, pypyjs.org). It's fun! At a high level, the approaches are:

* Create a Python interpreter that is able to run Python code directly in the browser (PyPy.js, Brython)

* Transpile Python code into JavaScript and send that to the browser (Transcrypt, which also does a lot of tree shaking to keep the transpiled code efficient).

Here are the benefits, IMHO:

* Share helper code and class definitions across environments

* Most of the std lib, and a handful of popular 3rd party libs, are supported

* In the rare happy path, only have to think about one programming language.

The downsides are:

* Slow. For the "send an interpreter" approach (Brython, PyPy.js), the browser has to compile a whole compiler before moving on to running your code.

* Incompatibilities. For Brython and Transcrypt, C parts of the standard lib have to be re-written in Python for compatibility. So when you're importing something from the itertools package, it's actually a custom implementation like this: [https://github.com/brython-dev/brython/blob/master/www/src/L...](https://github.com/brython-dev/brython/blob/master/www/src/Lib/itertools.py). The custom code will not always be exactly compatible with the CPython implementation.

* Incompleteness. Some std libs aren't implemented, or are only partially implemented. 3rd party libs that rely on these will not work. Popular 3rd party libs like sklearn which get their power by wrapping C/Fortran libraries need custom wrappers that don't exist (AFAIK) yet.

* You still gotta JavaScript. Even in the best transpilation scenarios, things break and you have to figure out what the generated or interpreted code is doing. This is especially tough for Python in the browser tools, which aren't widely used, so have both undiscovered bugs and a lack of community support. In my experience, working in a transpiled codebase doesn't mean you have to learn one thing, but three: the source language, the target language, and the frankenstein monster of the logic/compromises bridging the two.

* Tooling. The ecosystem hasn't reached a critical mass to support tooling. It's unclear if there's enough excitement in the Python community to get it there.

With all that said, unless you're a true believer or just want to have a
little fun (again, it is fun!), I wouldn't recommend this.

------
sradman
From the GitHub Page [1]:

> Brython (Browser Python) is an implementation of Python 3 running in the
> browser, with an interface to the DOM elements and events.

[1] [https://github.com/brython-dev/brython](https://github.com/brython-
dev/brython)

------
tcbasche
I always think these kinds of thing are cool in theory, but I feel like "the
right tool for the job" is always more appropriate, and (for better or worse -
right now) JavaScript is the right tool for the job.

I can only imagine (and shudder) starting to write a front-end app in Brython,
coming up against an error and then not knowing where to turn. At least JS
gives you the confidence of being able to Google / StackOverflow answers.

~~~
kabacha
> JavaScript is the right tool for the job

Is it though? The fact that there are thousands of tools like this and whole
web-assembly movement just might mean that Javascript really sucks at what it
supposed to do.

~~~
tcbasche
Maybe, but at least there’s a community around it is my point

------
jokoon
I implemented some scale scale webapp with it. At some point, it becomes way
too slow.

It's a very cool project, which is only enabled by fast js engines, but the
reality comes back hard: it's an interpreter, running on an interpreted
language. I was never going to be fast.

I'm really forward to skilled people providing python though WASM. And not
pyodide, which is more than just python.

~~~
laurencerowe
> I'm really forward to skilled people providing python though WASM. And not
> pyodide, which is more than just python.

I think pyodide builds numpy and scipy as separate packages, so the base
distribution should be just python.

"Only the Python standard library and six are available after importing
Pyodide."

[https://pyodide.readthedocs.io/en/latest/using_pyodide_from_...](https://pyodide.readthedocs.io/en/latest/using_pyodide_from_javascript.html#loading-
packages)

------
DarkWiiPlayer
So this is basically fengari but for python?

------
mark-r
I love having a Python REPL handy for short one-offs. Now with Brython I'll be
able to have it on my Chromebook!

------
IshKebab
Heh you can see from the performance page the Brython is definitely
faster/slower than CPython:

[https://brython.info/speed_results.html](https://brython.info/speed_results.html)

I wonder what makes big integers 33 times slower/faster.

------
sanketdasgupta
This is a relatively recent talk that goes over the current ecosystem of
Python on the client side:

[https://www.youtube.com/watch?v=eJMT1aImS9Q](https://www.youtube.com/watch?v=eJMT1aImS9Q)

------
darepublic
I'd adopt Rust for web before this. This is a solution nobody should desire
imo.

------
zurn
How does this compare to the wasm based approaches? (eg Pyodide)

~~~
jokoon
Pyodide is a science-oriented suite, it's more than python. I haven't tried
it, and it seems way too big, and seems too complex to build and/or use.

Brython provides some interfacing with the DOM, which is mandatory if it's
replacing javascript.

~~~
zurn
Re using Pyodide outside the Jupyter stack, the documentation has some things
about that:
[https://pyodide.readthedocs.io/en/latest/using_pyodide_from_...](https://pyodide.readthedocs.io/en/latest/using_pyodide_from_javascript.html)

It seems easy to consume from the JS app POV, if you are using the builds from
upstream.

------
crb002
Why not inline WASM for deployment but host human readable Python source in a
URI? Accept liberal input languages but be conservative in the browser output.

------
numlock86
Now we just need a JVM implemented with Brython so we can build a WebAssembly
interpreter in Java that runs JavaScript ... in the Browser!

~~~
pjmlp
Ask and you will be served,

[https://www.leaningtech.com/pages/cheerpx.html](https://www.leaningtech.com/pages/cheerpx.html)

[https://www.leaningtech.com/pages/cheerpj.html](https://www.leaningtech.com/pages/cheerpj.html)

~~~
apignotti
Hi! I am CTO of LeaningTech and I designed these products. Feel free to drop
me any question at
[https://twitter.com/alexpignotti](https://twitter.com/alexpignotti)

~~~
robertlagrant
Wow, you're doing some groundbreaking stuff!

------
carldaddy
I will never understand why people think it's easier to use the same language
across every domain.

~~~
at_a_remove
I can throw out a couple of ideas. First, learning one language really well
versus learning two languages really well -- that's an easy sell. Second, code
reuse. If you think on it some, I am sure more ideas will come to you.

------
Konohamaru
This might be the most significant contribution to frontend development in the
past 28 years.

~~~
Can_Not
This is probably the least significant contribution.

------
RocketSyntax
How would this compare with plotly dash?

------
zaro
So now we can write web apps in one of most inappropriate languages for
frontend development.

White space significant, good luck minifying it.

No anonymous functions, yes you need to have name for that callback, even
though it's simply disabling a button.

Webpack does a great job of handling assets by simply importing/require them
in the code. Python import system, can't support that kind of importing.

And of course there is the performance. Python is generally slower than JS,
and then on top of that you are running Python interpreter in the JS VM.

~~~
kabacha
> So now we can write web apps in one of most inappropriate languages for
> frontend development.

Implying that javascript was ever appropriate.

> White space significant, good luck minifying it.

Just gzip it. Minifying is highly overrated to begin with.

> No anonymous functions, yes you need to have name for that callback, even
> though it's simply disabling a button.

Lambdas are supported, what do you mean?

> Webpack does a great job of handling assets by simply importing/require them
> in the code. Python import system, can't support that kind of importing.

What does this even mean?

~~~
jbreckmckye
> Implying that JavaScript was ever appropriate

Can we please stop doing the 4chan-esque snarky >implying ? It's not
discussion in good faith.

> Minifying is highly overrated to begin with

Compression is not magic and minifying has real world performance gains in JS
projects at least - I don't see how Python would be different here.

> Lambdas are supported

If you want to write your event handlers - which in UI programming is a lot of
your code - in a point-free style, then I think you'll be letting yourself in
for a lot of hassle.

> Webpack... What does this even mean?

I don't know Python too well, but I assume this is about the ability of
Webpack to overload import semantics with non-code dependencies (e.g.
importing stylesheets, icons, bits of JSON). Presumably Brython does not
support this.

You seem quite bullish about the strengths of this project. Exactly what
problems do you feel it solves? Assuming that we already have tooling like
Webpack and are able to write in either ES2020 or TypeScript, what do you
think we gain from writing our UI code in Python?

~~~
VectorLock
>Compression is not magic and minifying has real world performance gains in JS
projects at least - I don't see how Python would be different here.

How much are the gains with minifying (factoring out compression) anyways? I'm
sure they're somewhat faster, but enough to justify the step/obfuscation
(assuming obfuscation isn't a goal)

------
runekaagaard
Er2

------
rydre
Great, we're replacing a slow, dynamic, interpreted (sometimes JIT'd) language
with another even slower!

 _A VM inside a VM._

Eventually people are going to write C# in browser? All NPM packages made
available in Python and C#? All PyPI packages in browser?

Active X plugins are back people!

~~~
terenceng2010
>> write c# in browser

It is happening but with WebAssembly.

[https://dotnet.microsoft.com/apps/aspnet/web-
apps/blazor](https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor)

