Live data from Hacker News

Brython: an implementation of Python 3 running in the browser

github.com

61–70 of 76 posts

Re: Brython: an implementation of Python 3 running in the browser

#61

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.

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 runn…

I think it's more of a dislike for slow, laggy, and frankly janky experiences caused by excessive JavaScript or under qualified JS developers over the past 10 years.

Re: Brython: an implementation of Python 3 running in the browser

#62

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.

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.

Re: Brython: an implementation of Python 3 running in the browser

#63
post #48

Earlier quoted context omitted.

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 env…

The problem was WebAssembly despite what people think isn't a JS replacement. WebAssembly isn't designed to go after DOM manipulation and the rest of the browser world (in short, think calculating physics and heavy number crunching instead of whether or not some input with id blah is blank). The best analogy I can give is this, imagine using Lua and calling of compiled code (C/C++/Rust/etc), this is the JS/WebAssembl…

The browser has been a system-within-a-system for a long time now. That's a pretty big problem, because it's inefficient computation-wise and has very low interoperability with the host system, which has big implications. The user also has sort of an upside: the browser, being isolated on the host machine, is very portable. And, maybe safer, but I'd argue against this point, because a monolith is too hard to audit; if you want security and correctness you need many small components, not one huge one. But, those are user problems. Big vendors enjoy non-interoperability, because it lets them do user lock-in and have monopolies. That's also why we hardly have medium-sized vendors: only gigantic and minuscule.

If I had a magic wand,

- I'd make Web maximally interoperable, give an API to everything: look up Youtube recommendations or listen to Spotify programmatically or from the command line;

- introduce legislation to forbid non-interoperable for-profit (or infrastructure-level) software; otherwise businesses are incentivized to make walled gardens and lock-in users; e.g. no more countless chat apps;

- get rid of Javascript: it creates too many security and fingerprinting problems, and, if everything has an API, you don't need it;

- break up the browser into a composition of smallest independent components possible; it will get you `apt install facebook-local-events`;

- get rid of password-based authentication: what a horrible idea that was;

- get rid of any client-side possibility to track or fingerprint users; if you're making choices about what services to use or how, those choices can be fingerprinted, depending on some other things, but that's another matter; the other party should not be exposed to what hardware or software or configuration you use or how you use your peripherals;

- introduce consumer and competition protection laws to bring software out of the wild wild west in terms of legislation.

I've more or less described the destruction of Web as we know it, but also a creation of something much better, in my eyes. Doesn't sound very feasible, but that's what I'd do if I had a magic wand.

Re: Brython: an implementation of Python 3 running in the browser

#64
post #48

Earlier quoted context omitted.

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 env…

The problem was WebAssembly despite what people think isn't a JS replacement. WebAssembly isn't designed to go after DOM manipulation and the rest of the browser world (in short, think calculating physics and heavy number crunching instead of whether or not some input with id blah is blank). The best analogy I can give is this, imagine using Lua and calling of compiled code (C/C++/Rust/etc), this is the JS/WebAssembl…

Except that is what is actually happening, despite what people like yourself wish, we are getting our Flash tooling back.

Blazor, Unity, Uno, Qt, TeaVM, the list is only getting bigger and it will only stop if WebAssembly is removed from the browsers.

Pandora box is open and the lid won't close.

Re: Brython: an implementation of Python 3 running in the browser

#65
post #33

4MB for pure brython_stdlib.js ? :(

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.

Re: Brython: an implementation of Python 3 running in the browser

#66

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 fo…

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.

Re: Brython: an implementation of Python 3 running in the browser

#67
post #13

See also https://starboard.gg/ https://github.com/pyodide/pyodide They offer pure client-side Jupyter notebooks. Wasm compiled, no cloud servers needed.

JupyterLite[1] can also be added to this list. [1] https://github.com/jupyterlite/jupyterlite

Consider also https://basthon.fr/ which is used for education

Re: Brython: an implementation of Python 3 running in the browser

#68
post #63
post #48

Earlier quoted context omitted.

The problem was WebAssembly despite what people think isn't a JS replacement. WebAssembly isn't designed to go after DOM manipulation and the rest of the browser world (in short, think calculating physics and heavy number crunching instead of whether or not some input with id blah is blank). The best analogy I can give is this, imagine using Lua and calling of compiled code (C/C++/Rust/etc), this is the JS/WebAssembl…

The browser has been a system-within-a-system for a long time now. That's a pretty big problem, because it's inefficient computation-wise and has very low interoperability with the host system, which has big implications. The user also has sort of an upside: the browser, being isolated on the host machine, is very portable. And, maybe safer, but I'd argue against this point, because a monolith is too hard to audit; i…

has anyone attempted to create a separate standard yet?

Re: Brython: an implementation of Python 3 running in the browser

#69
post #56

Earlier quoted context omitted.

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 env…

Not having direct access to the file system or the network or to a database are because of the sandbox, not because of JavaScript. You can do all those things in Node. Web Assembly isn’t going to get rid of the sandbox.

You could have fakeroot, for instance: https://wiki.debian.org/FakeRoot

Sandbox doesn't imply not having a file system available (for example, for use in imports), I believe this is more of a historic limitation than a strictly technical one (just because we need the sandboxing concept).

I know. Fakeroot is not strictly sandboxing, but I think it illustrates the point.

Re: Brython: an implementation of Python 3 running in the browser

#70
post #63

Earlier quoted context omitted.

The browser has been a system-within-a-system for a long time now. That's a pretty big problem, because it's inefficient computation-wise and has very low interoperability with the host system, which has big implications. The user also has sort of an upside: the browser, being isolated on the host machine, is very portable. And, maybe safer, but I'd argue against this point, because a monolith is too hard to audit; i…

has anyone attempted to create a separate standard yet?

There's loads of document distribution alternatives, both classical (like Gopher) and modern (like Gemini). I'm not familiar with them.
Post reply on HN