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...).
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.
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.
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.
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.
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.
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 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.)
* 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...
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.
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.
For C, you can use the switch -Wswitch-enum with GCC to get warnings and add -Werror to turn the warning into an error.
> [flagged]
> [flagged]
Oh HN, never change
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
Regular Python code cannot be compiled, unless cython or mypyc code is considered "regular".
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.
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.
