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.
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.
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
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.
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!
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?
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'.
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.
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.
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.
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...).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Comments
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.
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.
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.
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
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.
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!
Wtaf are you talking about?
My read is those languages share features with perl
"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'.
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.
The people who are pushing for Python in the browser are generally extremely familiar with Python, its indentation, and how silly this argument is.
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.
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.
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.
Monopolists never like it when their monopoly is threatened ... ;-)
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.
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.
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.
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.
An existing codebase can certainly be an obstacle in adopting a PL but I don't think that's the main motivation in practice.
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.
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.
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.
What is the difference between the DOM API, a JavaScript engine and the JS language specification?
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.
Why should Javascript have monopoly on manipulating the DOM? It makes no sense to me.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.