Brython: an implementation of Python 3 running in the browser

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

From the site guidelines: "Show HN is for something you've made that other people can play with."

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

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.

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.

It's about time to reinvent Java applets.

idk how I feel about web assembly. At least now we can see what client-side javascript is doing. If WASM becomes mainstream then all client side code is going to be essentially binary blobs.

I’ve noticed both “plain HTML please” and “Wasm is awesome” sentiments expressed on HN. I wonder if these reflect two distinct subpopulations, or if there is an intersection of HNers who like both ideas.

The existence of both sentiments speaks to the idiosyncratic history of the web. The browser is powerful because it has grown to be ubiquitous, but also has this odd dual mandate of displaying static content and running dynamic apps.

I don't think Webassembly will ever replace Javascript in the browser. Javascript has a low barrier of entry and if you are creating React/Angular sites there's little to gain from Webassembly for someone not interested in safer languages.

Saying that I am really interested in Webassembly and think the word web in Webassembly does it a disservice.

I have started to think of Webassembly as a light weight JVM. It's heavy sandboxing makes it really interesting as an evolution to FaaS (Function as a service) such as AWS Lambda. Lucet which Fastly is using for their Compute@Edge reports 35 micro second code start time! I can't wait until Fasly put there Compute@Edge on general release so I can try it. I've been playing with Cloudflare workers and as they us Chrome to run WASM files you have to mess about writing Javascript shims so a bit rough around the edges debugging.

Webassembly should realise the original goals of serverless providing a cross platform runtime with security guarantees and be fast and lightweight.

Most people package an entire OS in Docker containers, with WASM they get a small cross platform artifact. This project already looks like a way to run them in K8s https://github.com/deislabs/krustlet.

It also looks great for cross platform media devices. Have the bulk of your code as a WASM binary and then have very thin platform specific shim the WASM interacts with.

I don't think this is ever going to happen. JavaScript is still and probably always will be the language used to manipulate webpages and interact with the user, it's extremely optimized and a quite fast and effective scripting language.

WebAssembly provides an amazing opportunity to do general computing in webpages more efficiently than with the JavaScript scripting language, but it's not designed to interact directly with the user or documents. Certainly that _could_ change in the future, but that's not one of its design goals and I don't think it would even be particularly effective at it.

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.

(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

Thank you for sharing Pyodide. Please consider adding a link to things like this. Cheers!

https://github.com/pyodide/pyodide

Pyodide is rather larger than brython. It's essentially a full python interpreter and stdlib compiled to wasm, whereas brython is a reimplementation of python directly in javascript.

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

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.

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.

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

JupyterLite[1] can also be added to this list.

[1] https://github.com/jupyterlite/jupyterlite

I ran into this recently while learning it... confused me for a long time because I'm typically writing TS for my day job.

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.

Highly recommend looking into Munch, "a dictionary that supports attribute-style access, a la JavaScript." https://github.com/Infinidat/munch

In theory, implementing attribute-style access on user-defined Python object is just a matter of overriding its __(get|set)attr__ methods, for example:

    In [1]: import collections
    In [2]: class DotDict(collections.UserDict):
          2     def __getattr__(self, k):
          3         try:
          4             return self.__getitem__(k)
          5         except:
          6             return super().__getattribute__(k)
          7     def __setattr__(self, k, v):
          8         try:
          9             self.__setitem__(k, v)
         10         except Exception as e:
         11             super().__setattr__(k,v)
    In [3]: d = DotDict({'a': 'b', 'c': [1,2,3], 'square': lambda x: x*x})
    In [4]: d.square(4)
    Out[4]: 16
    In [5]: d
    Out[5]: {'a': 'b', 'c': [1, 2, 3], 'square': <function <lambda> at 0x7f9ef5d5b0d0>}
    In [6]: import datetime
    In [7]: d.created_at = datetime.datetime.now()
    In [8]: d
    Out[8]: {'a': 'b', 'c': [1, 2, 3], 'square': <function <lambda> at 0x7f9ef5d5b0d0>, 'created_at': datetime.datetime(2021, 7, 19, 19, 42, 32, 341393)}

In practice, this can lead to headaches. Take, for example, what happens if we try to serialize `d` (which has a non-serializable lambda function in its keys) using the built-in pickle module:

    In [9]: import pickle
    In [10]: pickle.dumps(d)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    _pickle.PicklingError: Can't pickle <class 'DotDict'>: attribute lookup DotDict on builtins failed

Thankfully there's a third-party library called cloudpickle which can serialize just about any python object to bytes -- even including the user-defined DotDict class (!):

    In [12]: deserialized_d = cloudpickle.loads(cloudpickle.dumps(d))
    In [13]: deserialized_d
    Out[13]: {'a': 'b', 'c': [1, 2, 3], 'square': <function <lambda> at 0x7f9ef650fee0>, 'created_at': datetime.datetime(2021, 7, 19, 19, 42, 32, 341393)}

Since the entire class definition is serialized along with the instance, the deserialized copy preserves the object's attribute-style interface as before:

    In [14]: deserialized_d.created_at.strftime("%c")
    Out[14]: 'Mon Jul 19 19:42:32 2021'

But I recommend Munch over rolling your own because subclassing `dict` is fraught with a surprising number of edge cases.

this is the default stdlib with everything, you have tools to transpile only what you need and make it much smaller: https://www.brython.info/static_doc/en/import.html. Also after first launch it is stored in indexedDB, which speed up import the following times.