5 ms·

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

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 2y 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.
- holdenweb 2y 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.
- athanagor2 2y 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...).
  - fragmede 2y 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.
    - amonroe805-2 2y 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 2y 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 2y ago
        What is the difference between the DOM API, a JavaScript engine and the JS language specification?
    - athanagor2 2y 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.
  - coldtea 2y 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 2y 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.
- pphysch 2y 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.
- pedrocr 2y 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 2y 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 2y 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 2y 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!
- DeathArrow 2y ago
  Why should Javascript have monopoly on manipulating the DOM? It makes no sense to me.
  - Izkata 2y 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 2y 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.
ashleyn 2y 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 2y 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.
austin-cheney 2y 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 2y 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 2y 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 2y 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.
DeathArrow 2y 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 2y 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.

MattDaEskimo 2y 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.

holdenweb 2y 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.
athanagor2 2y 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...).
- fragmede 2y 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.
  - amonroe805-2 2y 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 2y 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 2y ago
        What is the difference between the DOM API, a JavaScript engine and the JS language specification?
  - athanagor2 2y 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.
- coldtea 2y 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 2y 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.
pphysch 2y 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.
pedrocr 2y 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 2y 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 2y 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 2y 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!
DeathArrow 2y ago
Why should Javascript have monopoly on manipulating the DOM? It makes no sense to me.
- Izkata 2y 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 2y 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.

ashleyn 2y 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 2y 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.

austin-cheney 2y 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 2y 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 2y 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 2y 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.

DeathArrow 2y 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 2y 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.