A possible future of Python in the browser
lukasz.langa.pl
lukasz.langa.pl
I'm totally all-in on WASM over JavaScript, unless your back-end is also JS/TS then no objection.
I could see Django benefitting greatly from being able to run template logic in-browser.
Converting python code to WASM would cause even less performance than JavaScript.
The only reason to do something like this is if you only know Python and refuse to use anything else.
The ignorance and prejudice of most developers are staggering. They simply think "Javascript is shit", and all their arguments boil down to jokes about NaN and the weird behavior of ==. JS is (by far) not a jewel of a PL but it's telling that those people don't know anything about the real cursed and weird parts of JS (such as: eval does not behave the same depending on how you call it...).
of course, LLMs, with their nascent ability to translate code into different languages, makes the question of rewriting something in a different language more tractable, but it's still a hike.
Additionally, browser JS adheres to a quite strict backwards compatibility requirements. Python can and does deprecate and remove APIs, and I would imagine the community would not like to lose that flexibility.
WASM is probably the best bet here, in that it provides a well-specified low-level target, such that the door is open for other languages for anyone who is allergic to learning/using javascript.
JS and backwards compatibility gave me a chuckle...try hanging out on the web in IE11.
An existing codebase can certainly be an obstacle in adopting a PL but I don't think that's the main motivation in practice.
> of course, LLMs, with their nascent ability to translate code into different languages, makes the question of rewriting something in a different language more tractable, but it's still a hike.
Entirely agree. In my current company there's quite a bit of reluctance to spend some bucks to have good tools and I resent it. Rewriting (quickly!) some Python into say, C++, would be absolutely great.
That's because that's a non issue, as you shouldn't be calling eval in the first place.
Python is not that different from Typescript. Neither can be interpreted by the browser. Both can be compiled into JS or WASM to be run in the browser.
vs on the web, javascript is built in, and you have to specifically go out of your way to use something else (which be a worse experience than the one that's already built in*)
*idk, i don't have personal experience, but i think that's the reasoning at least
Granted to various degrees. Running Python, Ruby or PHP in the browser requires shipping a interpreter compiled to WASM and is indeed a lot of overhead, however compare and contrast that with say C, Rust, Dart, C++, Kotlin or C# which all have dedicated WASM compilation story’s which ship native WebAssembly bytecode without the interpreter overhead.
For a lot of those languages they are on an equal footing to JS in every non DOM manipulation context and only getting better overtime as more and more WASM proposals start to move through the standardisation process unlocking better performance and capabilities.
I think in that particular light, it’s very hard to see JS holding the same privileged position on the web it traditionally has. A new generation of languages are emerging which are much much nicer to work with.
> much nicer to work with than JavaScript
Glorified assembly, if war crime was a language and a marketing tool to promote JetBrains IDEs that barely works outside of JVM. Truly nice way to work!
"Line noise programming languages"
That's not even true except in the sense that the browser will (most likely) run it (well, some subset of it...). Compilation or transpilation of a language are not considered to be "going out of your way", unless you only program in assembly. And even JS-based stacks tend to have some form of compilation step to gather and process 'assets bundles'. So why not use a modern language that has more web-oriented features than JS?
Oh, I've been plenty chided for wanting to use Node on the server, and not something faster like Go. Although you may have included web backend into 'the web'.
The people who are pushing for Python in the browser are going to be in for a shock when they realize how inconvenient Python's indentation is to deal with.
The people who are pushing for Python in the browser are generally extremely familiar with Python, its indentation, and how silly this argument is.
It opens up a whole new can of worms.
You can certainly have an aesthetic or philosophical issue with it, but you said “inconvenient” which is a practical concern.
What are the good parts? When you only have a hammer, everything is going to resemble a nail.
Javascript was designed to manipulate the DOM and bring a bit of interactivity to otherwise static web pages.
It wasn't designed to write applications in. Nor it was designed to be used for web backend, mobile software and desktop software.
It's like some people try to write everything in Bash and protest when some other people want to use other languages.
For some people it's offensive even if you try to use some other language to write desktop and mobile apps.
I also don’t see many people complaining about native gui toolkits, they just silently use their cross platform stuff and that’s it.
WASM is a bad idea for web applications as a JavaScript replacement because it’s everything plus the kitchen sink. Most of time people advocating for this are people that cannot program JavaScript. Don’t feel bad about that though, because most people writing JavaScript cannot program JavaScript.
Nothing compares to how nicely integrated Blazor is. I don't have to waste my time "turning on my JavaScript brain" and thinking of all the nuances, I was just doing C# for the back-end logic, and I can continue using C# for the front-end. I can continue with the same mindset and skill set. It's drastically more productive.
I can take any developer who has zero front-end experience but tons of C# experience and have them building very capable web applications, and nobody using them would tell the difference.
WASM was birthed out of trying to make JavaScript even faster.
WASM was birthed as a Flash replacement, but ubiquitous to programming languages. It, according to its maintainers and originators, has nothing to do with JavaScript.
Scala.js runs in the browser in a way that actually works and feels first-class, I'd highly recommend it if you haven't tried it. Scala has a reputation for obtuse symbol-heavy code, but you don't have to write that way if you don't want to - most Python code translates directly into equivalent Scala, and there are libraries (particularly lihaoyi's efforts) designed to support this style.
I really like Blazor but since it has to rely on Javascript hooks to work with the DOM it kind of make it slower when compared to a JS framework.
No, because corporate wouldn't let me install that :(.
The browser seems to have everything that's needed, and ChromeOS is basically built on that idea.
The limiting factors though are performance and compatibility. Even with a JIT compiler, both JS and WASM are pretty wasteful, resource-wise. Because of that, you cannot just compile MS Excel to WASM; you'd have to bring half of Win32 APIs, DCOM, and tons of libraries to it, too. While technically it's not impossible, the result would be quite sluggish at best.
And if you have to run native-code apps anyway, why your Python CLI shouldn't be a native app, too?
Then there is no need for the browser. We can download an app and run it on a portable VM on any hardware. Or am I missing something?
I thought the whole point of the browser was to use HTTP to fetch HTML and CSS and render them. With a few sprinkle of some scripting language to manipulate the DOM and make things interactive when needed.
But why would still need a browser if everything becomes an app? Another layer of abstraction and virtualisation will just waste time and incur hardware costs.
i was thinking some weeks ago that it may be time to "fork" python - as language - in a way to preserve the initial simplicity and clarity it did have and is losing faster and faster. But, nevermind. Will have to live with whatever there is.
edit: looking at the code, some things might be optimized but no idea if these are on critical path (like, that switch-by sq_idx, or 6 lines.append.. ), or whether func-calls are as expensive in Spy as they are in Cpy. But anyway, squeezing few percents is not the point.. if one needs magnitudes.
You can check by yourself seeing of the spy compiler translates the code to C in the (super-experimental) spy playground: https://antocuni.pyscriptapps.com/spy-playground/latest/
I've had this thought, and seen others express it. The main problem is there is no general agreement on what should or shouldn't make the cut.
I've sort-of designed a new language from scratch, but I haven't been able to convince myself to make time to implement anything significant, or even really discuss what I've already figured out in any detail.
I do like Mr. Langa's idea about pre-computed ("@blue") code - although it doesn't strike me as particularly novel. (It's something I want to do in my own language, too - or rather, I have in mind a metaprogramming system, so you'd have macros that manipulate the AST and either insert a result when it's fully determined at compile time, or runtime code otherwise.)
One good example I like to point to is the idea of mixins.
Take a look at how Dart does it here: https://dart.dev/language/mixins
Then take a look at TypeScript here: https://www.typescriptlang.org/docs/handbook/mixins.html
You might also be interested in this https://dart.dev/resources/coming-from/js-to-dart
* use the exact same web APIs as outlined on MDN like you can in JavaScript.
* Without having to leave Dart and all of the type safety and tooling you get with that.
* while still being able to compile to WASM.
* With zero runtime overhead in terms of performance
Example of what that looks like here: https://github.com/dart-lang/web/blob/main/web/example/examp...
Using decorator calls to "compile" chunks of python code seems like an increasingly popular trend in ML (and presumably other numerically intensive code) - e.g., numba, jax.jit and triton.
I'd maybe quibble with "running natively on WebAssembly with speed in the same order of magnitude as Rust" given I expect that statement would be just as true if you replaced Rust on WebAssembly with the equivalent JavaScript.
But ultimately while I understand the motivation - at the beginning of my career before I discovered Python I wanted to write command line scripts in PHP because that was what I knew! - I think it is ultimately a dead end since by breaking from the Python ecosystem you end up having to compete against JavaScript which is not really that far from Python and has an existing library ecosystem to plug into.
This is incorrect. It's widely publicized that WebAssembly is often faster than JavaScript.
Of course the big advantage from using a language designed for lower level work is that you are far less likely to hit performance pitfalls. But if you write JavaScript as if it were C you tend to get very good performance.
I am sceptical that SPy will manage to beat JavaScript performance wise on average. But I'm interested to see how they do in part because of their learnings could make JavaScript in WebAssembly faster. (WebAssembly has much faster startup than JS which makes per request isolation practical if JS in WASM gets fast enough.)
But the power of Python currently mostly lies in its being a glue language. Python easily and neatly wraps things like numpy, scipy, polars, pytorch, etc, all implemented in native code. Not being able to use these would be a major limitation. But being able to use these would be a colossal change to the browsers' capabilities, security model, and, well, purpose.
Pyodide is far from a perfect CPython and even the packages it includes often have limitations you won't find when running natively. But there's definitely enough here to be interesting and even somewhat useful. Here's an interactive app written on Pyodide that uses astropy, numpy, and matplotlib: https://shinylive.io/py/examples/#orbit-simulation
Independently of its compilation flexibility, it's nice to work with. For example it was the first language that ever gave me compile error because there were cases that my switch statement didn't account for.
For C, you can use the switch -Wswitch-enum with GCC to get warnings and add -Werror to turn the warning into an error.
I've always been fascinated by the concept of Nim, but with a non-programming day job, I've never found the time to dive in to learning it well enough to reach my equivalent python skill level.
My Nim journey was stalled by this bug in its nix toolchain: https://github.com/NixOS/nixpkgs/issues/308593. I guess that's the price we pay for straying from the beaten path.
So far my issue with pyiodide or other interpreted variants of python in wasm is the huge startup time especially if you need to install dependencies. The above projects i hope eventually reach a point where we can just compile everything
That would still be nice to have some of those python libs to the browser though.
Regular Python code cannot be compiled, unless cython or mypyc code is considered "regular".
Like, I get the appeal of more languages beyond JavaScript for the frontend, but I'd have guessed this would mostly be attractive to people who like significantly different languages to js, like maybe something compiled and strongly typed.
Python and Javascript seem to be in the same ballpark of "interpreted scripty language grown larger". I don't think moving to python would give me a different enough language to warrant the cost of switching.
And so it sometimes goes the other way. Java was used through a transpiler for the front-end for some of the classic Google apps (I don't know if that is still the case). So it makes some sense, for a Python heavy team, to consider the same approach. And with the growing support of WASM it is probably even easier than it was when it required transpilation to JavaScript. And since a lot of ML work is in Python there is undoubtedly growing interest.
I think the other points of view on this thread where people point out how ridiculous it would be to force you to use one specific language on the desktop or even on mobile are thought-provoking.
If I can make iPhone apps with .NET [1] why not client-side browser code with Python?
[1] https://learn.microsoft.com/en-us/dotnet/maui/what-is-maui?v...
You can't even package up a python application to work on an arbitrary machine with those libraries without a world of hurt and some quite laughable hacks, most distributed python software is started from a .bat file that installs a local copy of python not an .exe, the ones that are a single .exe (PyInstaller) unzip themselves into a temp folder every time they are run.
With how poor Python is at even distributing software written in it's home desktop environment to another machine it's going to be a large leap to get all that to work on another machine without in another environment. (Environment as in desktop/browser not venv wrapper)
Python seems so limited in where it can go by the ideological choice that it's installed into the base of the operating system rather than treating it's libraries as relative to it's scripts location. Entire ecosystem is built within wrappers just for this ideology.
Says a lot imho when it's easier to distribute a Javascript application to people than a Python one when JS was never intended to run outside a browser.
> [flagged]
> [flagged]
Oh HN, never change