[HN Gopher] Brython: an implementation of Python 3 running in th...
___________________________________________________________________
Brython: an implementation of Python 3 running in the browser
Author : redfox2
Score : 134 points
Date : 2021-07-19 15:59 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| bmannix wrote:
| Brython has been around a long time, at least 7 or 8 years. While
| I love Python and I'm not a particularly big JS fan, I feel like
| if Brython didn't really make a dent before ES6 and TypeScript,
| then it will be really hard to do it now. Does anyone know what
| the biggest Brython project/app is? Can we see it in production
| other than a simple hello world?
| redfox2 wrote:
| Yeah, it has been there for quite some time, but has really
| started getting off the ground in about mid-late 2019 which is
| strange, since like you mentioned, the advent of TS. But slowly
| a lot of interest has been brewing over it, it's growing faster
| than ever, and has been attracting users/contributors a LOT
| only since the start of last year.
|
| https://academy.cs.cmu.edu/
|
| This is Carnegie Mellon's academy website, running on Brython.
| See the Brython Wiki page on their GitHub, they got a list
| there.
| rossdavidh wrote:
| Python was itself around for years, predating PHP by several
| years even, before it took off; PHP got big much quicker.
| Ruby was around for several years before Rails helped it take
| off outside of Japan. So, that doesn't mean Brython will take
| off now, but it does at least suggest it's possible.
| bluedays wrote:
| I'm hoping web assembly eventually completely replaces
| javascript. It would be amazing if we could theoretically compile
| any language down to be browser compatible.
| gchamonlive wrote:
| This is something that I wanted to hear more from people
| invested in frontend.
|
| I work exclusively as a DevOps/DataOps/Backend engineer and
| have little contact with stuff running in the browser. I did,
| however, work with AngularJS back in the day, and although the
| framework itself didn't lend itself to nicely to productivity
| and simplicity, I believe that what I found most confusing was
| how unergonomic the browser environment itself was, from not
| dealing with a filesystem (and thus having to resort to tricks
| like transpiling and bundling) to the rather terse API, not
| having for instance a SQLite natively and not being able to
| enable something like this without bringing copious amounts of
| megabytes of extra javascript deps...
|
| Is the browser environment becoming more dev-friendly with the
| adoption of WebAssembly? I ask that because, in my opinion, if
| the browser itself doesn't evolve, it doesn't matter which
| language we use, interacting with it will still be a hassle.
| All in all, it feels like the browser advanced a lot in
| technology for optimization and resource management, but not so
| much in becoming more user-friendly to the developer.
| Tade0 wrote:
| > not having for instance a SQLite natively
|
| We had this for a brief moment in the form of Web SQL, but as
| a rule web standards require independent implementations to
| be developed, and all the implementors were using SQLite
| under the hood. The current alternative is IndexedDB - for
| better or worse.
|
| > Is the browser environment becoming more dev-friendly with
| the adoption of WebAssembly?
|
| Yes, but that doesn't have much to do with WebAssembly.
|
| JavaScript as a language evolved, we have TypeScript with its
| flexible and expressive type system and bundling is becoming
| less of a pain with each consecutive framework re-written
| using ES2015 modules(and loaded via e.g. Snowpack
| https://www.snowpack.dev/).
|
| WebAssembly is helpful when there's a need for some heavy
| lifting - e.g. in software codecs, but that's still a niche
| application.
| peterthehacker wrote:
| Technologies like TypeScript are still dependencies that
| require transpiling to vanilla JavaScript and add to the
| bundle size. While typescript is becoming more and more
| common (for good reason) it still is effectively a
| workaround that compensates for the unergonomic-ness of the
| browser environment. You could make the same argument for
| frameworks like Angular, React and Vue.
|
| If WebAssembly replaced js, then newer, more efficient
| browser languages could be invented. Like a new
| implementation of typescript could be created that is
| statically compiled and more efficient. All of this
| transpiling from x to js and y to css would be unnecessary.
| bri3d wrote:
| The "y to CSS" part would still be there - even with
| WebAssembly, your UI options are still pretty much the
| DOM (great for documents and form entry, not so great for
| applications) or canvas (too low level and loses platform
| consistency, accessibility, usability, really every
| affordance of an operating system).
| julienb_sea wrote:
| Transpiling is more about broad browser compatibility
| than anything else. In any event, even if you invented
| some more efficient browser language, it would likely
| need a universal browser-compatible compilation target
| anyway (like web assembly). This isn't particularly a
| step forwards from TS compilation to JS, and the loss of
| all common JS libraries would be a huge drag on adoption.
| laurencerowe wrote:
| That's already pretty much the case. Python has been though
| it's not fast and the stack size limit is problematic.
| https://github.com/pyodide/pyodide
|
| Pyodide is used in https://jupyterlite.readthedocs.io/
|
| Maybe things will improve with web assembly GC, though it will
| require work to port GC languages to it.
| redfox2 wrote:
| Guido mentioned he was focusing work on CPython to make
| Python faster
| dolmen wrote:
| text/javascript or application/javascript?
|
| And so, text/python or application/python?
| miohtama wrote:
| See also
|
| https://starboard.gg/
|
| https://github.com/pyodide/pyodide
|
| They offer pure client-side Jupyter notebooks. Wasm compiled, no
| cloud servers needed.
| redfox2 wrote:
| Starboard is completely different from Brython, although it is
| cool. As for pyodide, it still involves proper working
| knowledge and literal implemetation of JS - Brython just needs
| you to know the bare basics, the rest is just pure Python
| deven88 wrote:
| JupyterLite[1] can also be added to this list.
|
| [1] https://github.com/jupyterlite/jupyterlite
| redfox2 wrote:
| I discovered this about a month ago, and it deserves to go up to
| the sky.
|
| The GitHub page is linked at the end.
|
| Some articles/content that relates to this ([4] is pretty cool
| and definitely check it out, so is [6]):
|
| [1] https://brython.info/static_doc/en/intro.html
|
| [2] https://towardsdatascience.com/run-python-code-on-
| websites-e...
|
| [3] https://stackabuse.com/an-introductory-guide-to-brython
|
| [4] https://rayluo.github.io/brython-project-template/
|
| [5] https://github.com/rayluo/brip
|
| [6] https://github.com/brython-
| dev/brython/wiki/Brython%20in%20t...
|
| [7] https://academy.cs.cmu.edu/ (CMU's academy website runs on
| Brython)
|
| Here's the GitHub page: https://github.com/brython-dev/brython/
|
| And the Wiki, for examples -https://github.com/brython-
| dev/brython/wiki/Brython%20in%20t...
|
| If you're familiar with all that's going on with the source code
| or at least some parts of it, and have time to spare, do take the
| time out to contribute to this project. It's pretty insane what
| they're building.
|
| You can join their Google Groups forum here:
| https://groups.google.com/forum/?fromgroups=#!forum/brython
| dang wrote:
| Great post and great comment but please don't put "Show HN" on
| submissions like this. As rahimnathwani pointed out, that
| signifies that the project is your personal work.
|
| https://news.ycombinator.com/showhn.html
| rahimnathwani wrote:
| From the site guidelines: "Show HN is for something you've made
| that other people can play with."
| anticristi wrote:
| Can I hijack this post for a nit-pick?
|
| While I love Python and feel most comfortable with it, it always
| bothered me that it make a distinction between accessing a
| dictionary item and accessing an object member. E.g.:
| a["getStuff"]() # call the "getStuff" function of dictionary "a"
| b.getStuff() # call the "getStuff" method of object "b"
|
| In contrast, in JavaScript, these two are equivalant.
| a["getStuff"]() a.getStuff()
|
| I find JavaScript more dev-friendly. Any idea why Python didn't
| opt for the same approach? Would make sense to me, since
| "everything is a dictionary/object".
| rhacker wrote:
| I ran into this recently while learning it... confused me for a
| long time because I'm typically writing TS for my day job.
| supervisual wrote:
| I would argue opposite, For a long time JS had this issue where
| when you iterated on keys in a dictionary you had to ensure you
| were skipping methods etc via .hasOwnProperty check. Python by
| making clear distinction between contents and functionality
| avoids this.
| frou_dh wrote:
| I found the following article and associated presentation to be a
| great overview of the options for this kind of thing:
| https://anvil.works/blog/python-in-the-browser-talk
|
| Transcrypt's (https://github.com/QQuick/Transcrypt) approach made
| the most sense for me. The project seems to be a heroic effort by
| one guy.
| wilsonfiifi wrote:
| Yeah Transcrypt is interesting! There's even a book that shows
| you how to use it with React [0]. Personally I think mithril.js
| would be a better fit than React because JSX isn't supported.
|
| [0] http://www.transcrypt.org/pdfs/rtptutorial.pdf
| redfox2 wrote:
| Please have a look at the last comment for all related content
| links - implementation, projects, doc etc.
| eatonphil wrote:
| After reading this thread and being frustrated by the pretty
| useless exceptions Brython gives, I switched over to using
| Pyodide (which took 5 minutes, both libraries are pretty simple).
| There is a huge improvement on usability with Pyodide. It doesn't
| wrap JavaScript objects in lots of additional structures like
| Brython does and it actually gives stack traces that end in user
| code!
|
| I've only been exploring Pyodide for the 10 minutes since I
| switched over and discovered these two pieces.
|
| I'm curious if there's a good reason to use Brython over Pyodide.
|
| Edit: Ok one weird thing with Pyodide is that I cannot use
| subscripts with JavaScript objects in Python. I have to use dot
| accessors. So not `row["age"]` but `row.age`. Kinda weird, not
| too Pythonic.
| yboris wrote:
| Thank you for sharing Pyodide. Please consider adding a link to
| things like this. Cheers!
|
| https://github.com/pyodide/pyodide
| eatonphil wrote:
| It's a great project! I use it to power the Python interpreter
| for an in-browser backend of an app I'm working on.
|
| I wrote a bit more about my experience using it (and a guide for
| others) here:
| https://datastation.multiprocess.io/blog/2021-06-16-language....
|
| My biggest gripe is that so far I haven't been able to get good
| stacktraces out of it on errors. It also wraps all objects in
| custom Brython types that you have to rewrap in Python types to
| do stuff like get `.keys()` on JavaScript objects.
| redfox2 wrote:
| Yeah. Like I said, it could really do with more contributors
| who can work on these issues and add keep adding features.
| rayluo who is a major contributor (developed brip to support
| using regular PyPi packages with brython), for example, works
| at Microsoft, and most probably does this in his spare time.
| More people like this can help bring Brython up even more, so
| there's a majority coverage for what JS can do, with Brython.
| Joining their Groups forum really shows you how much they're
| working and how much they're dedicated to this. This is only
| going to keep growing, if more devs and contributors hop onto
| the project even in their spare time.
| stuaxo wrote:
| Fantastic there is brip, I like to check in on Brython from
| time to time, and the lack of something like Brip was one
| reason I haven't been able to use it more.
|
| I guess being able to take the C parts of extensions and have
| them compiled with emscripten would be a logical step
| further.
| redfox2 wrote:
| https://github.com/rayluo/brip
|
| This brings standard PyPi packages to Brython
| peterthehacker wrote:
| This project will transpile python code to JavaScript code
| instead of something WASM-based, like pyodide [0].
|
| What are there the performance and usability consequences of each
| approach (py to js vs. py to wasm)?
|
| [0] https://github.com/pyodide/pyodide
| redfox2 wrote:
| Pyodide still involves writing JS (literally). Brython just
| needs you to know the simple basics of JS (since the syntax is
| similar), and you're good to go with pure Python from there on.
| meredydd wrote:
| (Disclosure: I'm a maintainer of https://skulpt.org, another
| Python-in-the-browser runtime, as well as a Python web
| framework/dev environment that uses it, https://anvil.works)
|
| The short answer is that basically all the current Python-in-
| the-browser implementations (and there are a few!) predate
| widespread support of WASM. But even once WASM is a thing, you
| get a choice between:
|
| 1. Compile a full Python environment to WASM (via Emscripten),
| and load it in the browser. This is what Pyodide does - it lets
| you use a _boatload_ of existing libraries, but you have to
| download and bytecode-compile the world to do it. On my machine
| Pyodide takes 10+ seconds to load. (PyPy.js, which predated
| WASM, was even worse!) The upside is that you can run more or
| less anything from the existing ecosystem. This tradeoff is
| great for Pyodide 's use case (notebooks in the browser) - long
| load times are OK, but you really want those numerical
| libraries.
|
| 2. Ship a lightweight, JS-based runtime. This is what Brython
| and Skulpt do. You'll pay in performance (compilation overhead,
| interpretation, and the overhead of preserving Python rather
| than JS semantics for things like attribute lookup), but your
| payload will be much smaller (Skulpt is ~250kb on the wire),
| and you'll be interactive much faster. We chose Skulpt for the
| client side of our full-stack Python-in-the browser platform,
| Anvil (https://anvil.works). Unfortunately, you'll be amazed
| how many Python libraries don't work in this environment. Most
| "normal" Python code is pretty straightforward, but dig into
| any big library and you'll find a native dependency really
| fast. (Skulpt's original 'datetime' implementation was ported
| from PyPy, and even _that_ depended on native code. In PyPy,
| the interpreter written in nearly pure Python!) In something
| like Anvil, this is no biggie, because you can call server-side
| code with one function call, but it could be a nasty surprise
| in a traditional app.
|
| 3. Compile "not quite Python" to JS (this is what Transcrypt
| does). This more or less transliterates Python code to the
| nearest Javascript equivalent. This produces really compact,
| JIT-friendly JS code, but it will bite you the moment you rely
| on Python semantics that aren't there in JS. Worse, you're now
| neither fish nor fowl: If you have a question, you can't
| consult StackOverflow for Javascript answers, but half the
| Python answers won't work for you.
|
| (To my knowledge, nobody has yet attempted the "WASM +
| lightweight runtime" approach. We've occasionally discussed it,
| but it would be hard to retrofit to an existing project,
| because you'd want to move a-lot-but-not-all of the runtime
| into WASM to avoid being hammered by the JS-WASM bridge, and
| building a Python runtime from scratch is a heavy lift...all
| for a performance boost you might just get from generating
| faster JS.)
|
| Before the pandemic, a colleague of mine wrote an in-depth
| comparison of six popular Python-in-the-browser
| implementations, with sample code and a discussion of their
| trade-offs, with a lot more detail than I can fit into this
| comment: https://anvil.works/blog/python-in-the-browser-talk
| fulafel wrote:
| In addition prior to webassembly there were asm.js +
| emscripten based Python ports. With mostly the same
| properties as the wasm based ones.
| dolmen wrote:
| Maybe a small Python engine (MicroPython, Snek [2]) on
| WebAssembly might also fit some niche uses.
|
| MicroPython has a version working in the browser using
| unicorn.js (which emulates ARM CPU). [3]
|
| [1] https://micropython.org/ [2] https://sneklang.org/ [3]
| https://micropython.org/unicorn/
| coupdejarnac wrote:
| Thanks for skulpt. Using it as a replacement for replit to
| teach kids.
| dang wrote:
| Past related threads:
|
| _Brython: Python in the Browser_ -
| https://news.ycombinator.com/item?id=26781461 - April 2021 (1
| comment)
|
| _Brython - A Python 3 implementation for client-side web
| programming_ - https://news.ycombinator.com/item?id=23746067 -
| July 2020 (214 comments)
|
| _Brython - Client-side web programming in Python_ -
| https://news.ycombinator.com/item?id=15914805 - Dec 2017 (1
| comment)
|
| _Brython - A Python 3 implementation for client-side web
| programming_ - https://news.ycombinator.com/item?id=9792536 -
| June 2015 (60 comments)
|
| _A Python 3 implementation for client-side web programming_ -
| https://news.ycombinator.com/item?id=5807059 - June 2013 (117
| comments)
|
| _Brython, Python in the browser_ -
| https://news.ycombinator.com/item?id=5133047 - Jan 2013 (65
| comments)
|
| _Brython - Python to Javascript translator_ -
| https://news.ycombinator.com/item?id=4923530 - Dec 2012 (68
| comments)
|
| (That last thread and the June 2013 thread are good for anyone
| worried that HN has become more negative lately...)
| redfox2 wrote:
| Wow I wasn't aware of those. But apart from the 2020 post, the
| others are pre-TS. Brython seems to have come a long way since
| TS came in
| d33d33 wrote:
| 4MB for pure brython_stdlib.js ? :(
___________________________________________________________________
(page generated 2021-07-19 23:01 UTC)