5 ms·

I was not able to donate, PayPal again doing its shenanigans (my country of origin not supported to donate). Anyway, what I typed there was: I read that you do

I was not able to donate, PayPal again doing its shenanigans (my country of origin not supported to donate). Anyway, what I typed there was: I read that you don't support JS intentionally. That's fine and dandy. If I were to create a browser from scratch, I'd probably do that. However, what I'd really like to see is the ability to plug many scripting engines: Maybe you want to make V8 pluggable, or SpiderMonkey, or let's open the box: plug Python! That might enable the possibility to have a front-end stack that is HTML, CSS and Python (without the JS in the middle). It would open a whole new spectrum of Web development, one that is not subjugated to the pitfalls of JS. WebAssembly kind of opened that door, but a native interpreter would be good to have. P.S.: I'm aware Brython exists, but it feels like a cheat to me.

dartos 2y ago
Honestly that sounds terrible for the web. JavaScript is weird, but it was specifically made and has evolved entirely for making non blocking, snappy, event driven user interfaces. Python was not. Also, you’d end up breaking the very standards that make the web open. If websites only work on 1 browser because it’s the only one that supports Python, then you’ve just lost the open web. That’s the whole idea around WASM. A standard compile target that’s designed for the sandboxes environment of websites.
- ivanmontillam 2y ago
  Python was an example of my point, but I was thinking even more along the lines of any scripting language that employs pre-processors, so the code inlining works. Much like PHP does with open and closing tags, in the early days of Web development, I remember doing websites with Dreamweaver that way. How'd you feel about a client-side PHP subset?
  - dartos 2y ago
    > Python was an example of my point, but I was thinking even more along the lines of any scripting language that employs pre-processors, so the code inlining works I’m sorry, I’m not really understanding what you mean here. > client-side PHP subset I’d dislike it for the same reasons as before. Php was made to and evolved largely for generating HTML on a server. Not to have snappy, non blocking, event driven user interfaces. And since PHP is not a standardized the same way JavaScript is, any browser may or may not implement it the same was as another. We’d be back in the early 2000s world of browsers incompatibilities. What would native browser support for php give you vs a wasm implementation of it?
- jmathai 2y ago
  Seems reasonable to implement a portion of an open spec for niche use cases like this. Every browser takes several gigs of ram once you have more than a couple tabs open. I’m in the niche looking to trade off some functionality to gain some efficiency.
  - Beijinger 2y ago
    https://www.uzbl.org/ https://www.uzbl.org/
  - dartos 2y ago
    A browser which implements a subset of the specs that major browsers implement is still part of the open web. A browser which implements unique functionality breaks away from the open web.
- int_19h 2y ago
  Python has await/async; what else do you need for non-blocking, snappy, event-driven UI?
  - dartos 2y ago
    JavaScript didn’t always have async await. The implementation details also affect runtime performance. JavaScript rarely blocks execution, it’s what makes it snappy. For example, Python blocks by default, unless you run your inside a Python async wrapper like asyncio.
pavlov 2y ago
Back in the late 1990s, multi-language support was part of the original design of the <script> tag. Microsoft’s market-leading browser defaulted to VBScript rather than JavaScript. But of course people wanted interoperability rather than writing separate scripts for IE and Netscape. Python is ill-suited for browser scripting because it boldly claims to have “batteries included”, i.e. it has a sprawling standard library, and most of it is entirely incompatible with the browser environment’s sandboxing and async execution model. So Python for browser scripting would be a limited subset. And if you go there, what’s really the point of writing programs in an incompatible version of a language whose sole reason to exist is the supposed ease-of-use…
- ivanmontillam 2y ago
  > Python is ill-suited for browser scripting because it boldly claims to have “batteries included”, i.e. it has a sprawling standard library, and most of it is entirely incompatible with the browser environment’s sandboxing and async execution model. Per a previous comment[0], Python was an example of my point, but I was thinking even more about any scripting language that employs pre-processors so the code inlining works. > Back in the late 1990s, multi-language support was part of the original design of the <script> tag. Microsoft’s market-leading browser defaulted to VBScript rather than JavaScript. That in the context of the browser wars back then. Today that war is kind of settled, still fighting to take down some Chrome's dominance of course. > But of course people wanted interoperability rather than writing separate scripts for IE and Netscape. But my point is that it would be a kind of start, JS is too dominant for the front-end community. If you don't know JS you're just dead in the water. You have to inherently like JS to be an effective front-end developer. That's an unfair constraint. WebAssembly kind of opened that door, but we are still in these early days. -- [0]: https://news.ycombinator.com/item?id=42508950 https://news.ycombinator.com/item?id=42508950
- GoblinSlayer 2y ago
  >Python is ill-suited for browser scripting because it boldly claims to have “batteries included” And javascript simply downloads its own batteries. "Only on first visit, I swear".

dartos 2y ago

Honestly that sounds terrible for the web. JavaScript is weird, but it was specifically made and has evolved entirely for making non blocking, snappy, event driven user interfaces. Python was not. Also, you’d end up breaking the very standards that make the web open. If websites only work on 1 browser because it’s the only one that supports Python, then you’ve just lost the open web. That’s the whole idea around WASM. A standard compile target that’s designed for the sandboxes environment of websites.

ivanmontillam 2y ago
Python was an example of my point, but I was thinking even more along the lines of any scripting language that employs pre-processors, so the code inlining works. Much like PHP does with open and closing tags, in the early days of Web development, I remember doing websites with Dreamweaver that way. How'd you feel about a client-side PHP subset?
- dartos 2y ago
  > Python was an example of my point, but I was thinking even more along the lines of any scripting language that employs pre-processors, so the code inlining works I’m sorry, I’m not really understanding what you mean here. > client-side PHP subset I’d dislike it for the same reasons as before. Php was made to and evolved largely for generating HTML on a server. Not to have snappy, non blocking, event driven user interfaces. And since PHP is not a standardized the same way JavaScript is, any browser may or may not implement it the same was as another. We’d be back in the early 2000s world of browsers incompatibilities. What would native browser support for php give you vs a wasm implementation of it?
jmathai 2y ago
Seems reasonable to implement a portion of an open spec for niche use cases like this. Every browser takes several gigs of ram once you have more than a couple tabs open. I’m in the niche looking to trade off some functionality to gain some efficiency.
- Beijinger 2y ago
  https://www.uzbl.org/ https://www.uzbl.org/
- dartos 2y ago
  A browser which implements a subset of the specs that major browsers implement is still part of the open web. A browser which implements unique functionality breaks away from the open web.
int_19h 2y ago
Python has await/async; what else do you need for non-blocking, snappy, event-driven UI?
- dartos 2y ago
  JavaScript didn’t always have async await. The implementation details also affect runtime performance. JavaScript rarely blocks execution, it’s what makes it snappy. For example, Python blocks by default, unless you run your inside a Python async wrapper like asyncio.

pavlov 2y ago

Back in the late 1990s, multi-language support was part of the original design of the <script> tag. Microsoft’s market-leading browser defaulted to VBScript rather than JavaScript. But of course people wanted interoperability rather than writing separate scripts for IE and Netscape. Python is ill-suited for browser scripting because it boldly claims to have “batteries included”, i.e. it has a sprawling standard library, and most of it is entirely incompatible with the browser environment’s sandboxing and async execution model. So Python for browser scripting would be a limited subset. And if you go there, what’s really the point of writing programs in an incompatible version of a language whose sole reason to exist is the supposed ease-of-use…

ivanmontillam 2y ago
> Python is ill-suited for browser scripting because it boldly claims to have “batteries included”, i.e. it has a sprawling standard library, and most of it is entirely incompatible with the browser environment’s sandboxing and async execution model. Per a previous comment[0], Python was an example of my point, but I was thinking even more about any scripting language that employs pre-processors so the code inlining works. > Back in the late 1990s, multi-language support was part of the original design of the <script> tag. Microsoft’s market-leading browser defaulted to VBScript rather than JavaScript. That in the context of the browser wars back then. Today that war is kind of settled, still fighting to take down some Chrome's dominance of course. > But of course people wanted interoperability rather than writing separate scripts for IE and Netscape. But my point is that it would be a kind of start, JS is too dominant for the front-end community. If you don't know JS you're just dead in the water. You have to inherently like JS to be an effective front-end developer. That's an unfair constraint. WebAssembly kind of opened that door, but we are still in these early days. -- [0]: https://news.ycombinator.com/item?id=42508950 https://news.ycombinator.com/item?id=42508950
GoblinSlayer 2y ago
>Python is ill-suited for browser scripting because it boldly claims to have “batteries included” And javascript simply downloads its own batteries. "Only on first visit, I swear".