I have mentioned it on HN before, but I strongly believe that bringing Python to the browser, especially via WASM, and going as far as bringing on a templating library, would allow Python to match things like C#'s Blazor, which honestly has been a productivity boost on web projects.
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.
MattDaEskimo 62 days ago [-]
This wouldn't make sense. JavaScript offers all the utilities necessary, and operates with all web elements.
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.
pedrocr 62 days ago [-]
The web is the only platform where people routinely chide other people for wanting to use their favorite programming languages. For some reason not liking Javascript and wanting to use something else is offensive to a lot of people. In all the other platforms some language may dominate but others are still used and don't cause these reactions.
1317 62 days ago [-]
on other platforms, all languages are relatively equal, it's the same effort to use language a as it is to use language b, and you can get nice results with both
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
mdhb 62 days ago [-]
The entire point here is that this is changing.
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.
wiseowise 62 days ago [-]
> C, C++, Kotlin
> 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!
mdhb 62 days ago [-]
Wtaf are you talking about?
genewitch 61 days ago [-]
My read is those languages share features with perl
"Line noise programming languages"
woolion 61 days ago [-]
>on the web, javascript is built in
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?
DeathArrow 62 days ago [-]
>For some reason not liking Javascript and wanting to use something else is offensive to a lot of people.
For some people it's offensive even if you try to use some other language to write desktop and mobile apps.
azangru 62 days ago [-]
> The web is the only platform where people routinely chide other people for wanting to use their favorite programming languages.
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'.
socketcluster 62 days ago [-]
It's not offensive. It's just very stubborn.
JavaScript has been bashed incessantly. People would actively look for all the bad parts just to complain about it... Totally ignoring all the good parts and the fact that it was extremely well adapted to an evolving web environment and also well-suited for being standardized.
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.
dragonwriter 62 days ago [-]
> 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.
socketcluster 62 days ago [-]
I meant, it is inconvenient in a web context. People do crazy stuff with JS like minifying it writing it all on one-line in the console during testing. It would be different with Python. Sometimes I do write JS functions as one-liners for testing. The Chrome dev console isn't very good at handling tab characters or new lines.
It opens up a whole new can of worms.
61 days ago [-]
DeathArrow 62 days ago [-]
>People would actively look for all the bad parts just to complain about it...
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.
shermantanktop 62 days ago [-]
I’m no python expert but I’ve written a bit, and indentation has just not been a problem in practice.
You can certainly have an aesthetic or philosophical issue with it, but you said “inconvenient” which is a practical concern.
holdenweb 61 days ago [-]
Monopolists never like it when their monopoly is threatened ... ;-)
wiseowise 62 days ago [-]
Yeah? For some reason I don’t see Python, C#, Java people constantly bitching about monopoly of C in OS space.
I also don’t see many people complaining about native gui toolkits, they just silently use their cross platform stuff and that’s it.
athanagor2 62 days ago [-]
> 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...).
coldtea 62 days ago [-]
>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...)
That's because that's a non issue, as you shouldn't be calling eval in the first place.
athanagor2 61 days ago [-]
The other things I wrote about are also non-issues (in practice). They are just ignorant. I could also write about the result of `parseInt(0.0000005)`, which could be more of a real problem.
fragmede 62 days ago [-]
You can dismiss their objections as childish, but people are gonna write in the language they want to (or are paid to) write in. If there's a large body of existing python code they'd have to rewrite in JavaScript, or use some python in the browser route for their purposes, why should we force other people to use typescript because some of us think it's better?
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.
athanagor2 61 days ago [-]
> You can dismiss their objections as childish, but people are gonna write in the language they want to (or are paid to) write in. If there's a large body of existing python code they'd have to rewrite in JavaScript, or use some python in the browser route for their purposes, why should we force other people to use typescript because some of us think it's better?
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.
amonroe805-2 62 days ago [-]
I mean, these things aren’t static. Python may be the second most popular language (behind JS/TS) today, but what if elixir takes over 10 years from now? There is no need for browsers to implement every language-of-the-day.
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.
dangus 62 days ago [-]
Or perhaps you've got it backwards: there's no reason for browsers to prevent anyone from implementing any language they want.
JS and backwards compatibility gave me a chuckle...try hanging out on the web in IE11.
pjaoko 62 days ago [-]
What is the difference between the DOM API, a JavaScript engine and the JS language specification?
pphysch 62 days ago [-]
How does WASM make less sense than the current paradigm of treating JS as "byte code for the browser"?
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.
DeathArrow 62 days ago [-]
Why should Javascript have monopoly on manipulating the DOM? It makes no sense to me.
Izkata 62 days ago [-]
I thought WASM intentionally didn't provide a way to manipulate the DOM? If I'm remembering right they'd still have to use javascript for part that anyway.
giancarlostoro 62 days ago [-]
You say that, but I can do anything you can do with JS to the DOM with Blazor using C#. If my backend is in C# I have no context switch between code syntax wise. I can even call JavaScript code.
holdenweb 61 days ago [-]
i don't see a numpy equivalent in Javascript, and that's just the first module that came to mind that I know PyScript can run in the browser.
austin-cheney 62 days ago [-]
WASM is fine for original applications, like desktop applications, because a WASM application is everything plus the kitchen sink.
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.
giancarlostoro 62 days ago [-]
I've build all types of JavaScript applications, little, medium and large, vanilla, react, vue, hell even ThreeJS, D3.js and many other libraries and frameworks...
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.
austin-cheney 62 days ago [-]
> 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.
lmm 62 days ago [-]
> I have mentioned it on HN before, but I strongly believe that bringing Python to the browser, especially via WASM, and going as far as bringing on a templating library, would allow Python to match things like C#'s Blazor, which honestly has been a productivity boost on web projects.
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.
ashleyn 62 days ago [-]
You could, theoretically, render django templates in the browser today. But you'll still need to contend with using a thin JS layer to access the browser dom. Mooting any real performance benefit, at least if you want accessibility and not a 00s-style flashblob of a page. AFAIK direct dom bindings for wasm aren't being taken seriously and may never really happen.
giancarlostoro 62 days ago [-]
That's perfectly fine, that's what Blazor does. I'm looking to see it become adopted by a project like Django. I think the more we see WASM being adopted by key web frameworks, the more innovation we'll see in the WASM space outside of just a new runtime someone made.
DeathArrow 62 days ago [-]
The problem with WASM is that it can not manipulate the DOM. Why? I don't know.
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.
giancarlostoro 62 days ago [-]
To the end-developer it doesn't matter that JavaScript is hooked anywhere, the only time it matters is if that code is bugged and completely broken, or insanely low performance, which I really doubt.
supportengineer 62 days ago [-]
If my browser supports WebAssembly, I should be able to open my browser, forgo opening any actual web pages, and veer off into WebAssembly-land. From there perhaps there should be a package manager that lets me install packages (like Python, Java, Smalltalk, etc ) and switch to some sort of shell or launcher where I can enter a REPL for the selected language package. From there I could do anything.
kibwen 62 days ago [-]
If you don't want to open web pages then you wouldn't need to use a browser in the first place. WASM can run outside the context of a browser, so what you're asking for is a shell for running WASM apps.
lmm 62 days ago [-]
> If you don't want to open web pages then you wouldn't need to use a browser in the first place. WASM can run outside the context of a browser, so what you're asking for is a shell for running WASM apps.
No, because corporate wouldn't let me install that :(.
nine_k 62 days ago [-]
On one hand, the browser strives to be the universal OS shell, much like a Smalltalk environment before it, and a Lisp environment before that. Everything is scriptable, everything is inspectable, everything is written is a universal high-level language.
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?
DeathArrow 62 days ago [-]
>On one hand, the browser strives to be the universal OS shell
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.
wiseowise 62 days ago [-]
You cannot just compile MS Excel to WASM, because it is a legacy enterprise monstrosity.
xvilka 62 days ago [-]
It already exists. It's called desktop.
deadbabe 62 days ago [-]
Any examples of what you would “do”?
svilen_dobrev 62 days ago [-]
very interesting. So all the declarative stuff, like various type descriptions and preconditions and such, can be precompiled.. (and i am not talking about type-hints/annotations). Maybe some of the meta-programming stuff too.
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.
antocuni 62 days ago [-]
(SPy author here)
function calls in SPy are as cheap as in C.
>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.
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.)
svilen_dobrev 62 days ago [-]
Actually i don't have that much of a problem with the language itself - the new additions are not mandatory nor breaking old stuff, by design. But the way some are used - and started to be applied and forced-down-throat regardless of usecase - leaves me wanting those features to be absent. Better not have gold at all than turn everything into gold - it's not edible.. (here mostly talking about the type-hinting frenzy. But, no point repeating myself)
hoodchatham 62 days ago [-]
The actual code example he made runs about 100 times faster in Spy/emscripten than in Pyodide.
ripped_britches 62 days ago [-]
I’m also super excited about wasm creating language democracy. I’m rooting for dart myself.
hyperbolablabla 62 days ago [-]
Never used dart until about a month ago for Flutter. Really loving it so far - like a better typescript. So many cool language features.
firejake308 62 days ago [-]
In your opinion, why is Dart a better TypeScript? Interested to hear your view, because my experience was quite different. When I learned Dart, I was mostly annoyed because it was almost exactly the same as TypeScript, but just different enough that I had to look up how to do everything again. Like, I understand that Rust is different from other languages because it brings in a totally new approach to software development, which has its use cases. But when I used Dart, I just wondered why Flutter didn't just use TypeScript, since it looks basically the same to me.
mdhb 62 days ago [-]
One of the really nice things about Dart in addition to the fact that it’s an AOT compiled language with truly excellent tooling and documentation is the fact that because it’s not a superset of JS it can skip a lot of the messy parts while keeping the best bits.
One good example I like to point to is the idea of mixins.
As someone that mainly codes in Python and only has rudimentary JS skills, I'm intrigued. The generative art pyscript demos mentioned in the blog post are really nice.
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.
laurencerowe 62 days ago [-]
SPy is a cool experiment which we should applaud, though perhaps it would be helpful to compare to ShedSkin, Nuitka, or maybe Numba along with Cython if the eventual goal is compile everything to Wasm.
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.
ambivalence 62 days ago [-]
> 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.
This is incorrect. It's widely publicized that WebAssembly is often faster than JavaScript.
laurencerowe 61 days ago [-]
While WebAssembly definitely has advantages in terms of faster startup time, throughput is the same order of magnitude as equivalent JavaScript, perhaps 30% faster unless you are using WebAssembly only features like SIMD.
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.)
nine_k 62 days ago [-]
Python is a fine language. It has a nice enough JIT compiler by now. Its structure is similar enough to JS to allow easy interop, and easy exposure of browser APIs exactly the way these APIs are exposed to JS.
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
Wouldn't kill them to mention that all the heavy lifting is done by Pyodide.
__MatrixMan__ 62 days ago [-]
Maybe Nim isn't python-like enough to count, but it compiles to C or JavaScript, which makes it sort of relevant to pythonishness in the browser.
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.
digdugdirk 62 days ago [-]
Have you used it for front-end via Javascript compilation? How well do you find it works for front end specifically?
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.
__MatrixMan__ 62 days ago [-]
I spent a while messing around with https://github.com/ansiwave/nimwave, which I enjoyed but I haven't gotten very far. Though I've been avoiding the front end for so long, I don't know what reasonable feels like in that space anyway.
> 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.
__MatrixMan__ 62 days ago [-]
The reason I was surprised is that it wasn't explicitly an enum type but rather a char (which in retrospect I suppose is sort of like an enum).
rdedev 62 days ago [-]
Other projects that tries to achieve the same: RustPython and py2wasm
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
cxr 62 days ago [-]
Author is right in their dismissive attitude of Pyodide, but their WASM-ward gaze is probably misplaced, too. Once you're talking about acceptability in terms of being "Python-like enough", you should really be considering a Python-like syntax for JS, which would suffice for a bunch of Python programmers (in particular those who only picked it up as a result of ill-considered advocacy by Python proponents who told them that e.g. Python is how science gets done).
JodieBenitez 62 days ago [-]
I write a lot of Python, and I like it very much. But when it comes to the browser, what I don't like is compilation/build steps (yes, that includes Vue/React/Whatever builds). And that's why even I who don't like javascript very much will still be using it vanilla-style even if a compile-your-python-to-browser-wasm ever takes off.
That would still be nice to have some of those python libs to the browser though.
62 days ago [-]
62 days ago [-]
62 days ago [-]
DeathArrow 62 days ago [-]
Why can't regular Python code be compiled straight to WebAssembly?
jessekv 62 days ago [-]
The design of the language.
Regular Python code cannot be compiled, unless cython or mypyc code is considered "regular".
incognito124 62 days ago [-]
Is this the limitation of the current toolchain or is there some fundamental impossibility in the language itself so there can never be a (eg) .py -> ELF compiler?
khimaros 62 days ago [-]
i'm curious how SPy compares with Mojo, apart from the license. are they trying to solve the same problems?
gunian 62 days ago [-]
python in browser more of a pipe dream than me escaping slavery lmaooooo
kace91 62 days ago [-]
I have a Node background so I might be biased but... Why would you want python in the browser?
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.
dangus 62 days ago [-]
I personally find Python way easier to use and understand, and I have more experience with it. I wouldn't be "switching," I would just be writing in Python. I think having more language options would further democratize web development.
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?
Maybe doing scientific stuff in-browser that you would normally need a Python backend (with numpy etc) to do. I don't see it being used for driving UIs.
whywhywhywhy 62 days ago [-]
Getting python running in the browser and getting to the point the packages people care about (torch, numpy etc) would work in the browser seems a huge leap.
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.
hot_gril 61 days ago [-]
Hasn't Pyodide already made this leap? I know the pain of dealing with the Python runtime and packaging across machines, but in this case, the browser is providing a pretty uniform environment.
wiseowise 62 days ago [-]
Unlike JS, Python actually has standard library. Sync by default, optional async, rich community that is (arguably) has better quality on average, scientific and AI tooling, language itself is (arguably) nicer too with all the decorator, contextmanager stuff. Built in typing. That’s just off the top of my head.
JodieBenitez 62 days ago [-]
I prefer Python over Javascript. But I also prefer build-less over compilations steps. So that's Python on the server, Javascript on the browser. Of course there's Brython, but I don't think it competes performance-wise.
coldtea 62 days ago [-]
It's for people with taste in scripting languages.
62 days ago [-]
zoogeny 62 days ago [-]
I hear what your are saying, but there is some advantage to having the same language in multiple places in the stack. One of the advantages of JavaScript is that it can be used both on the front-end and the server. Some people hate that and insist that "real" programmers use a "real" server language but that is not a reasoned take. There are pragmatic reasons to want the same language across the stack.
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.
dang 62 days ago [-]
[stub for offtopicness]
DaSHacka 62 days ago [-]
> [stub for offtopicness]
> [flagged]
> [flagged]
Oh HN, never change
dang 62 days ago [-]
I'm grateful that you replied underneath the stub for offtopicness!
DaSHacka 62 days ago [-]
of course, no better place to say it than here, after all
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.
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?
For some people it's offensive even if you try to use some other language to write desktop and mobile apps.
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.
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.
You can certainly have an aesthetic or philosophical issue with it, but you said “inconvenient” which is a practical concern.
I also don’t see many people complaining about native gui toolkits, they just silently use their cross platform stuff and that’s it.
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...).
That's because that's a non issue, as you shouldn't be calling eval in the first place.
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.
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.
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.
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.
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.
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.
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.
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.
> [flagged]
> [flagged]
Oh HN, never change