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.
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…
You could actually use Perl and Python with IE 4 through Windows Script Host if you installed the versions from ActiveState (ActivePerl, ActivePython, and also ActiveTcl), which provided ActiveX scripting engines for those languages. I actually wrote some small Perl browser LAN apps using this for myself. It was a huge security hole in that anyone who install ActivePerl, Python, or Tcl could be rooted if they visited a web page with the appropriate malicious script tag, as these languages provide out-of-the-box support for file manipulation and other potentially dangerous actions.
You could also use the AS distros to write classic, pre-.NET ASP applications. I know of at least one startup that actually did this (ActivePerl + classic ASP + IIS on Windows NT/2000), or at least seemed to based on their job postings.
> 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.
Usually, with programming languages, that refers to having a wide standard library that allows you to complete many basic or common functions without downloading 3rd party or additional libraries.
Yeah, that's what Python's "batteries included" slogan means. Perl and Python not only ship with lots of libraries, but have built-in functions for file manipulation and running arbitrary shell commands as part of the core language: https://news.ycombinator.com/item?id=42509544
The "guts" of the LHEATcl plugin is a dynamically loadable library (DLL) containing the compiled object files from Tcl/Tk, FitsTcl, POW, etc. Currently, there is just one, monolithic LHEATcl DLL, unlike the LHEA standalone Tcl scripts such as fv where there one DLL for each package (Tcl, Tk, fitsTcl, POW, etc) . This library is placed in your browser's plugins directory. Currently Netscape4.x and Internet Explorer 3.x, 4.x, and 5.0 are supported. Netscape3.x is not supported because the Javascript we use to setup a window to run the tclet in doesn't work in Netscape 3.x. When your browser starts up it scans the plugins directory. If it finds the LHEATcl plugin library, it adds the LHEATcl plugin to its list of plugins and registers the plugin to process files of mime type "application/x-tcl". For details of how this information is stored in the library file, see the documentation for the Netscape plugin SDK.
}}
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.
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.
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.
> 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?
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.