17 ms·

Brython – A Python 3 implementation for client-side web programming

403 points by gjvc 6y ago

pjmlp 6y ago
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/samplechapter/0735710902.pdf http://ptgmedia.pearsoncmg.com/images/0735710902/samplechapt... Little by little, all plugins will be back.
- toyg 6y ago
  I'm surprised 4guysfromrolla is still up. I remember using their ASP and PHP tutorials in 2001...
  - rudasn 6y ago
    Wow, yes. Their articles were super helpful when I was starting up with asp and sql around that time.
factorialboy 6y ago
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?
- phonon 6y ago
  https://stromberg.dnsalias.org/~strombrg/pybrowser/python-browser.html https://stromberg.dnsalias.org/~strombrg/pybrowser/python-br... https://yasoob.me/2019/05/22/running-python-in-the-browser/ https://yasoob.me/2019/05/22/running-python-in-the-browser/
- goffi 6y ago
  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%20works https://github.com/brython-dev/brython/wiki/How%20Brython%20...), 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
  - goffi 6y ago
    just a correction for my comment above, I should have written "Brython feels like a Python interpreter", but it's transpiling to JS too, the difference is that it's done directly in the browser (it's also possible ahead of time from CLI), and then the JS is stored in indexecDB (this can probably be compared to .pyc from CPython). It's explained there for the curious: https://github.com/brython-dev/brython/wiki/How%20Brython%20works https://github.com/brython-dev/brython/wiki/How%20Brython%20... edit: I've updated initial comment.
  - MaxBarraclough 6y ago
    I hadn't heard of Transcrypt, looks neat. Can it be used server-side? Leveraging a JavaScript JIT seems like a good way of 'passing the buck' for getting high performance out of a dynamically typed language.
  - jennasys 6y ago
    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.
- meredydd 6y ago
  'pansa2 already linked this upthread, but a colleague of mine wrote an in-depth comparison of six popular Python-in-the-browser implementations, and their trade-offs (with sample code). It's a writeup from a PyCon UK talk: https://anvil.works/blog/python-in-the-browser-talk https://anvil.works/blog/python-in-the-browser-talk
sradman 6y ago
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
montenegrohugo 6y ago
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 6y ago
  I assume there's CLI for compilation step?
  - tgv 6y ago
    No, it seems to interpret the text/python script tag.
  - goffi 6y ago
    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
- nicoburns 6y ago
  It claims that: "Speed of execution is similar to CPython for most operations." Unfortunately CPython is several times slower (roughly 7x?) than most JavaScript engines to begin with. So I imagine it is quite slow.
  - wesammikhail 6y ago
    Question: What operations are being done on the client side that requires that much speed? Why is speed even a concern in this case? With modern hardware and the type of applications I am familiar with (rendering tens of thousands of financial data points), I could 50x lower the speed of execution and the client wouldnt even feel it. So I´m geniunly curious what people are working on that requires that much speed/performance?
ascar 6y ago
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 6y ago
  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 6y ago
    > - 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.
    - _fourzerofour 6y ago
      True on your first point, but I imagine GP was considering a case where you've already got a backend in Python.
    - britbull 6y ago
zurn 6y ago
How does this compare to the wasm based approaches? (eg Pyodide)
- jokoon 6y ago
  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 6y ago
    Re using Pyodide outside the Jupyter stack, the documentation has some things about that: https://pyodide.readthedocs.io/en/latest/using_pyodide_from_javascript.html https://pyodide.readthedocs.io/en/latest/using_pyodide_from_... It seems easy to consume from the JS app POV, if you are using the builds from upstream.
zaro 6y ago
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.
- skocznymroczny 6y ago
  Couldn't you just sent the bytecode .pyc instead to fix the no minification issue?
  - meredydd 6y ago
    This is exactly what BeeWare's Batavia does: compile to bytecode server-side, then run a remarkably small interpreter in the browser. This is a substantial win: parsing is a CPU hog, and Brython's architecture does it every time the page loads. That said, in order to support `eval` and friends, you still need a full-fat compiler in the browser. So the best route is probably to use a full-service Python->JS compiler, but compile most of the code ahead of time. That's where we're heading with Anvil (we use https://skulpt.org https://skulpt.org for the client side, but it's the same principle). My colleague wrote up a pretty wide-ranging comparison of browser-based Python interpreters. It describes how (and why) Brython, Batavia, Skulpt, Transcrypt, and Pyodide differ, and the tradeoffs they're chasing: https://anvil.works/blog/python-in-the-browser-talk https://anvil.works/blog/python-in-the-browser-talk
    - StavrosK 6y ago
      In twenty years of professional Python development, I've never used eval once. I'm not saying nobody ever needs it, but it's a niche feature that the vast majority of programs can do without, and is probably not worth the tradeoff.
robertkjohn 6y ago
There are a multitude of resources available for a wide variety of industries looking to hire freelancers. Field Engineer is a well-known global marketplace, where you can hire engineers and technicians to assist your workforce. Sign-up for free today and post a job to see how easy it can be. https://www.fieldengineer.com/blogs/signs-your-team-need-to-hire-freelancers https://www.fieldengineer.com/blogs/signs-your-team-need-to-...
pansa2 6y ago
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 6y ago
  The following table from that article provides a nice overview: https://anvil.works/blog/img/python-in-the-browser-talk/comparison-table.png https://anvil.works/blog/img/python-in-the-browser-talk/comp...
seemslegit 6y ago
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 6y ago
  Never underestimate the power of "But I already know lang X"
  - andybak 6y ago
    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 6y ago
      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 6y ago
        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 6y ago
        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.
    - seemslegit 6y ago
reactchain 6y ago
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 6y ago
  you can check https://github.com/brython-dev/brython/wiki/How%20Brython%20works https://github.com/brython-dev/brython/wiki/How%20Brython%20...
tcbasche 6y ago
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 6y ago
  > 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 6y ago
    Maybe, but at least there’s a community around it is my point
rydre 6y ago
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 6y ago
  >> 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
- NonEUCitizen 6y ago
  Bridge.NET has been around for a few years: https://bridge.net/ https://bridge.net/
numlock86 6y ago
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 6y ago
  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 6y ago
    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 6y ago
      Wow, you're doing some groundbreaking stuff!
joshlk 6y ago
Could you compile Python to Web Webassembly instead of JavaScript? Presumably that would have better performance.
- pansa2 6y ago
  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/
linkdd 6y ago
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.
- mjburgess 6y ago
  It's still python; you can overload operators and give them side-effects in any conforming implementation. It may not be "pythonic", but there's an established tradition of operator methods and there's no requirement that python code conform to any particular tradition.
  - linkdd 6y ago
    Sorry, what I meant was: Is it the Python you want in your browser? So, this is just another implementation with its tradeoffs, just like when using Jython to have Python (without its ecosystem) and the JVM. Here you have Python with another semantic to learn.
    - VectorLock 6y ago
      I see this happening in a lot of Python libraries. It's still Python - or *ython maybe we can call it. The idiom of cutesy operator overloaded spread in from other languages; I'm personally not a fan.
  - stoksc 6y ago
    Yeah, overloading to build a little dsl over some objects sort of is something I’ve seen a lot. See airflow: https://stackoverflow.com/questions/52389105/how-operator-defines-task-dependencies-in-airflow https://stackoverflow.com/questions/52389105/how-operator-de... When it’s used that way, you’ve lost that the operation is semantically analogous to __le__. I think the assumption it has no side effects goes, too. Edit: not saying I like it, though.
DarkWiiPlayer 6y ago
So this is basically fengari but for python?
IshKebab 6y ago
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.
carldaddy 6y ago
I will never understand why people think it's easier to use the same language across every domain.
- at_a_remove 6y ago
  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.
mark-r 6y ago
I love having a Python REPL handy for short one-offs. Now with Brython I'll be able to have it on my Chromebook!
runekaagaard 6y ago
Er2
jokoon 6y ago
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.
- bayesian_horse 6y ago
  Pyodide can be stripped down to "just" python, and you actually have to actively load everything else. I don't think there is going to be a more efficient or lean port of CPython to WASM than pyodide.
- laurencerowe 6y ago
  > 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_javascript.html#loading-packages https://pyodide.readthedocs.io/en/latest/using_pyodide_from_...
mshenfield 6y ago
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/Lib/itertools.py https://github.com/brython-dev/brython/blob/master/www/src/L.... 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.
bayesian_horse 6y ago
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 6y ago
  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.
RocketSyntax 6y ago
How would this compare with plotly dash?
Konohamaru 6y ago
This might be the most significant contribution to frontend development in the past 28 years.
- Can_Not 6y ago
  This is probably the least significant contribution.
darepublic 6y ago
I'd adopt Rust for web before this. This is a solution nobody should desire imo.
crb002 6y ago
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.
sanketdasgupta 6y ago
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

403 points by gjvc 6y ago

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/samplechapter/0735710902.pdf http://ptgmedia.pearsoncmg.com/images/0735710902/samplechapt... Little by little, all plugins will be back.

toyg 6y ago
I'm surprised 4guysfromrolla is still up. I remember using their ASP and PHP tutorials in 2001...
- rudasn 6y ago
  Wow, yes. Their articles were super helpful when I was starting up with asp and sql around that time.

factorialboy 6y ago

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?

phonon 6y ago
https://stromberg.dnsalias.org/~strombrg/pybrowser/python-browser.html https://stromberg.dnsalias.org/~strombrg/pybrowser/python-br... https://yasoob.me/2019/05/22/running-python-in-the-browser/ https://yasoob.me/2019/05/22/running-python-in-the-browser/
goffi 6y ago
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%20works https://github.com/brython-dev/brython/wiki/How%20Brython%20...), 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
- goffi 6y ago
  just a correction for my comment above, I should have written "Brython feels like a Python interpreter", but it's transpiling to JS too, the difference is that it's done directly in the browser (it's also possible ahead of time from CLI), and then the JS is stored in indexecDB (this can probably be compared to .pyc from CPython). It's explained there for the curious: https://github.com/brython-dev/brython/wiki/How%20Brython%20works https://github.com/brython-dev/brython/wiki/How%20Brython%20... edit: I've updated initial comment.
- MaxBarraclough 6y ago
  I hadn't heard of Transcrypt, looks neat. Can it be used server-side? Leveraging a JavaScript JIT seems like a good way of 'passing the buck' for getting high performance out of a dynamically typed language.
- jennasys 6y ago
  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.
meredydd 6y ago
'pansa2 already linked this upthread, but a colleague of mine wrote an in-depth comparison of six popular Python-in-the-browser implementations, and their trade-offs (with sample code). It's a writeup from a PyCon UK talk: https://anvil.works/blog/python-in-the-browser-talk https://anvil.works/blog/python-in-the-browser-talk

sradman 6y ago

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

montenegrohugo 6y ago

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 6y ago
I assume there's CLI for compilation step?
- tgv 6y ago
  No, it seems to interpret the text/python script tag.
- goffi 6y ago
  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
nicoburns 6y ago
It claims that: "Speed of execution is similar to CPython for most operations." Unfortunately CPython is several times slower (roughly 7x?) than most JavaScript engines to begin with. So I imagine it is quite slow.
- wesammikhail 6y ago
  Question: What operations are being done on the client side that requires that much speed? Why is speed even a concern in this case? With modern hardware and the type of applications I am familiar with (rendering tens of thousands of financial data points), I could 50x lower the speed of execution and the client wouldnt even feel it. So I´m geniunly curious what people are working on that requires that much speed/performance?

ascar 6y ago

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 6y ago
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 6y ago
  > - 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.
  - _fourzerofour 6y ago
    True on your first point, but I imagine GP was considering a case where you've already got a backend in Python.
  - britbull 6y ago

zurn 6y ago

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

jokoon 6y ago
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 6y ago
  Re using Pyodide outside the Jupyter stack, the documentation has some things about that: https://pyodide.readthedocs.io/en/latest/using_pyodide_from_javascript.html https://pyodide.readthedocs.io/en/latest/using_pyodide_from_... It seems easy to consume from the JS app POV, if you are using the builds from upstream.

zaro 6y ago

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.

skocznymroczny 6y ago
Couldn't you just sent the bytecode .pyc instead to fix the no minification issue?
- meredydd 6y ago
  This is exactly what BeeWare's Batavia does: compile to bytecode server-side, then run a remarkably small interpreter in the browser. This is a substantial win: parsing is a CPU hog, and Brython's architecture does it every time the page loads. That said, in order to support `eval` and friends, you still need a full-fat compiler in the browser. So the best route is probably to use a full-service Python->JS compiler, but compile most of the code ahead of time. That's where we're heading with Anvil (we use https://skulpt.org https://skulpt.org for the client side, but it's the same principle). My colleague wrote up a pretty wide-ranging comparison of browser-based Python interpreters. It describes how (and why) Brython, Batavia, Skulpt, Transcrypt, and Pyodide differ, and the tradeoffs they're chasing: https://anvil.works/blog/python-in-the-browser-talk https://anvil.works/blog/python-in-the-browser-talk
  - StavrosK 6y ago
    In twenty years of professional Python development, I've never used eval once. I'm not saying nobody ever needs it, but it's a niche feature that the vast majority of programs can do without, and is probably not worth the tradeoff.

robertkjohn 6y ago

There are a multitude of resources available for a wide variety of industries looking to hire freelancers. Field Engineer is a well-known global marketplace, where you can hire engineers and technicians to assist your workforce. Sign-up for free today and post a job to see how easy it can be. https://www.fieldengineer.com/blogs/signs-your-team-need-to-hire-freelancers https://www.fieldengineer.com/blogs/signs-your-team-need-to-...

pansa2 6y ago

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 6y ago
The following table from that article provides a nice overview: https://anvil.works/blog/img/python-in-the-browser-talk/comparison-table.png https://anvil.works/blog/img/python-in-the-browser-talk/comp...

seemslegit 6y ago

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 6y ago
Never underestimate the power of "But I already know lang X"
- andybak 6y ago
  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 6y ago
    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 6y ago
      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 6y ago
        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.
  - seemslegit 6y ago

reactchain 6y ago

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 6y ago
you can check https://github.com/brython-dev/brython/wiki/How%20Brython%20works https://github.com/brython-dev/brython/wiki/How%20Brython%20...

tcbasche 6y ago

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 6y ago
> 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 6y ago
  Maybe, but at least there’s a community around it is my point

rydre 6y ago

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 6y ago
>> 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
NonEUCitizen 6y ago
Bridge.NET has been around for a few years: https://bridge.net/ https://bridge.net/

numlock86 6y ago

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 6y ago
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 6y ago
  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 6y ago
    Wow, you're doing some groundbreaking stuff!

joshlk 6y ago

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

pansa2 6y ago
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/

linkdd 6y ago

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.

mjburgess 6y ago
It's still python; you can overload operators and give them side-effects in any conforming implementation. It may not be "pythonic", but there's an established tradition of operator methods and there's no requirement that python code conform to any particular tradition.
- linkdd 6y ago
  Sorry, what I meant was: Is it the Python you want in your browser? So, this is just another implementation with its tradeoffs, just like when using Jython to have Python (without its ecosystem) and the JVM. Here you have Python with another semantic to learn.
  - VectorLock 6y ago
    I see this happening in a lot of Python libraries. It's still Python - or *ython maybe we can call it. The idiom of cutesy operator overloaded spread in from other languages; I'm personally not a fan.
- stoksc 6y ago
  Yeah, overloading to build a little dsl over some objects sort of is something I’ve seen a lot. See airflow: https://stackoverflow.com/questions/52389105/how-operator-defines-task-dependencies-in-airflow https://stackoverflow.com/questions/52389105/how-operator-de... When it’s used that way, you’ve lost that the operation is semantically analogous to __le__. I think the assumption it has no side effects goes, too. Edit: not saying I like it, though.

DarkWiiPlayer 6y ago

So this is basically fengari but for python?

IshKebab 6y ago

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.

carldaddy 6y ago

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

at_a_remove 6y ago
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.

mark-r 6y ago

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

runekaagaard 6y ago

Er2

jokoon 6y ago

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.

bayesian_horse 6y ago
Pyodide can be stripped down to "just" python, and you actually have to actively load everything else. I don't think there is going to be a more efficient or lean port of CPython to WASM than pyodide.
laurencerowe 6y ago
> 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_javascript.html#loading-packages https://pyodide.readthedocs.io/en/latest/using_pyodide_from_...

mshenfield 6y ago

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/Lib/itertools.py https://github.com/brython-dev/brython/blob/master/www/src/L.... 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.

bayesian_horse 6y ago

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 6y ago
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.

RocketSyntax 6y ago

How would this compare with plotly dash?

Konohamaru 6y ago

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

Can_Not 6y ago
This is probably the least significant contribution.

darepublic 6y ago

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

crb002 6y ago

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.

sanketdasgupta 6y ago

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