HN Theater @HNTheaterMonth

In its Pycon 2015 presentation, the main author (from Mozilla) answers why isn't so simple to just include python in FF: https://youtu.be/PiBfOFqDIAI?t=1611

⬐ icebraining

What's sad is that Firefox already had Python working inside <script> tags (for addons only, though) back in 2005: https://bugzilla.mozilla.org/show_bug.cgi?id=255942

⬐ bzbarsky

A few notes on that implementation, since I have some firsthand experience with both the implementation and its removal:

1) "For addons only" is an important qualification. It means you don't have to worry about sandboxing at all, since addons are already all-powerful (or at least were at the time).

2) It added a _lot_ of complexity throughout the DOM. There are tons of places in the web platform that basically assume you have a "JS value" and things fall apart if that's not the case. Most simply, what happens if python code sets document.body.onclick and then JS code reads it, or vice versa? It's possible that this complexity and the resulting performance impact is worth carrying around if the use cases are compelling enough, but they just weren't.

3) The python implementation in question did not have a good solution for the problem of cross-language cycles. Those were solved for JS and C++ in Firefox by creating a cycle collector that tightly integrates with the JS GC and the refcounting system the C++ side uses. But that was only possible due to full control over the JS GC implementation (and hence the ability to change it to flag objects as "only owned by C++ stuff" and whatnot). Doing the same thing with Python would be a nontrivial undertaking, just for the C++ and Python bits. Dealing with cycles that involve all three languages would be _quite_ hard.

He addressed Brython at PyCon '15. I don't see the slides online, but the video is at https://www.youtube.com/watch?v=PiBfOFqDIAI.

Abstract:

> PyPy.js is an experiment in building a fast, compliant, in-browser python interpreter. By compiling the PyPy interpreter into javascript, and retargeting its JIT compiler to emit asmjs code at runtime, it is possible to run python code in the browser at speeds competitive with a native python environment. This talk will demonstrate the combination of technologies that make such a thing possible, the results that have been achieved so far, and the challenges that still remain when trying to take python onto javascript's home turf.

> We'll cover: an overview of PyPy and why it's a good fit for this type of project; an introduction to asmjs and the rise of javascript as a compile target; what it looks like when you smoosh these two technologies together; a comparison with other approaches such as brython and PythonJS; and some concrete suggestions for how the result might be useful in practice.

Yes, in his talk at https://www.youtube.com/watch?v=PiBfOFqDIAI&t=1355 Ryan Kelly already showed a Python 3 version of pypy.js

I watched the presentation in Pycon 2015[1], and I really liked how honest/aware they are about the challenges and tradeoffs (so far, the performance it's pretty bad compared to javascript, and the download size is still an issue). At the end is answered why python can't be directly included in Firefox or other browsers(the presenter/main developer works for Mozilla)

[1]https://www.youtube.com/watch?v=PiBfOFqDIAI

⬐ nailer

> At the end is answered why python can't be directly included in Firefox or other browsers(the presenter/main developer works for Mozilla)

Direct link to answer: https://youtu.be/PiBfOFqDIAI?t=1611

⬐ jdnier

"If we ship Python inside of Firefox, no one is going to use it because it's not available in Chrome, it's not available in Internet Explorer." Oh yeah? Try me.

⬐ ben336

The other issue with Python in the browser is that the significant whitespace requirement prevents minification, which would bloat download size.

⬐ dragonwriter

Significant whitespace (in all languages, really, its a difference of degree rather than kind) constrains, but does not prevent, minification. (Idiomatic python code can be reduced by three chars per indentation level on each line with no impact on semantics, and of course other transformations that aren't whitespace elimination that are past of minification are unaffected.)

Heck, there are existing python minification tools.

⬐ klibertp

Also, with SourceMaps you could provide compiled Python code (.pyc), which is already heavily minified.

⬐ abc_lisper

Here's a possible solution

- Let there be pojs landing page

- Download pypy.js in the background

- Run python code

- Dance with Glee!

⬐ callahad

Well, Google more or less tried the same with Dart and has since abandoned that plan in favor of targeting JS as Dart's primary runtime. Then again, the Dart VM never shipped in mainline Chrome, so who knows how a more committed attempt would have played out.

⬐ toyg

That's a bit of a fig leaf: dart never had the clout and popularity Python has, and it was clearly something no other browser vendor could get behind. Python has significant cross-vendor mindshare and wouldn't be perceived as fostering anybody's agenda.

It's true though that getting even two major browser vendors to agree on supporting another scripting language in addition to JS, is really really hard. I don't see it happening unless Nadella's "Really Good, Honest! (TM)" Microsoft makes some sort of grand gesture towards Google or (more likely) Mozilla.

⬐ spankalee

Python might have clout, but in many way it's even harder to optimize than JavaScript, whereas Dart was designed by JavaScript VM experts to be easily optimizable and has a very fast, very small VM.

Python is also only just starting to explore optional typing which is obviously a prime feature of Dart and JS derivatives like TypeScript.

⬐ toyg

It's very clear that this is not a technical problem, but a political one. Dart could be the second coming of Knuth and still nobody but Google would implement it in a major browser.

⬐ voltagex_

I wonder if Python could be embedded as an addon.

⬐ RussianCow

Of course it could. But that would defeat the point, because support wouldn't be widespread enough for any real use (unless you're just using it for an intranet site or something).

⬐ romaniv

As usual, everyone devalues the benefits of progressive enhancement. Add-on would be a great way to get the ball rolling, as long as your website works without it too.

⬐ RussianCow

But we're not talking about some optional feature you can just shim in 1kb of JavaScript, we're talking about the language used to write a web app. Sure, you could use PyPy.js as a fallback, but you'd essentially create a horrible loading experience for >99.99% of your users while you wait for this addon to catch on (which won't happen, because there's no reason for an end-user to install it). For a language like Python to be natively supported on the web, at least one major browser has to support it. And that's not likely to happen given the current state of affairs.

⬐ vog

> python can't be directly included in Firefox or other browsers

So Python is a bad candidate, but there are better candidates out there. For example, jsofocaml (using OCaml in the browser) looks quite promising.

In the end, we need a lightweight yet properly defined and highlevel language, and the ML languages as well as the LISP languages are great candidates for that.

⬐ maximilian

Purescript is a Haskell-like language that is designed to output to javascript. It looks quite nice and has seen a lot of attention lately. It's even in GSoC.

⬐ akst

Purescript is interesting, I've been trying to build a project in it over the last few months. Since it's still pre 1.0, it has proven difficult but understandably so. It's mostly due to arcane/vague error messages (which they're in the process of dealing with), painfully long compile times, (imo) a few missing features, and incomplete young libraries.

On the flip side, with the state of libraries and all, it's provided me with a real incentive to get involved in open source, by having to contribute patches to said libraries and getting actively involved in general discussion.

Edit:

Just so I don't come off as mostly negative, I do enjoy having purescript as another statically typed option on the client side with close semantics to javascript. It's also been nice having a some kind of parsec like library on the client side (purescript-parsing), which was the main reason I chose purescript for this project in the first place.

⬐ arianvanp

plus its semantics lie pretty close to javascript. Most importantly because it's strict instead of lazy. Eventhough its strict it has a very haskelly feel. Both in syntax and type system. Also I think strict semantics is the way to go for efficient Functional Reactive Programming.

Furthermore, Purescript's FFI is really nice to use and it's really easy to bind to existing javascript libraries.

PureScript is community is nice and active. They are also discussing a lot with the `virtual-dom` guys to bring react/om/mercury-like functionality to purescript [0] and it's quite freakin awesome.

Seriously I'd take purescript for javascript any day. I think it's great that we FP folks can finally do frontend dev :-)

[0] - https://github.com/slamdata/purescript-halogen

⬐ magmadiver

Also, ClojureScript.

⬐ dheera

The problem I have with "output to Javascript" languages is that debugging becomes hell. Line numbers no longer correspond to each other, for example.

A slightly less-hellish but still annoying problem is that I often poke at things directly from the console when bugs happen, and this helps me a lot in debugging. However poking at the console requires using JavaScript, which is fine, but it would drive me nuts to have to code in one language (e.g. CoffeeScript, TypeScript, Python) and debug in another (JavaScript) and switch my brain back and forth every few minutes. So I've ended up largely sticking with writing code directly in JavaScript.

Any good solutions to this? Are there replacements to the Chrome JavaScript console that supports those other languages?

⬐ Psyonic

Are you using source maps? If so, you can actually put breakpoints in your other source and Chrome will still break on it. I've even done this with Scalajs.

⬐ stock_toaster

> In the end, we need a lightweight yet properly defined and highlevel language....

Even lua would be a joy!

⬐ espadrine

Out of curiosity, what would make Lua valuable to add in browsers by default? It is similarly prototype-based, has the same closure design, is dynamically typed, has an object system fairly similar to JS (with the type of arrays and hashtables both mixed), and its number system is also based on floating-point numbers…

I honestly don't see how we can justify the cost of adding Lua to browsers. I see the merit of Lua-to-JS compilers (existing codebases or sheer love of the syntax), but built-in?

⬐ trynumber9

Lua 5.1 (2006) has lexical scoping, tail calls, multiple return vales with assignment lists, semicolons are actually optional & most importantly: coroutines. ES6 adds some of these features.

Lua 5.3 has both integer and floating-point types.

⬐ vog

Not sure why this was downvoted. Does anyone care to elaborate?

⬐ toyg

I didn't downvote, but I don't think the problem has anything to do with specific language features. It's purely a political issue: you have to get at least two or three main vendors to adopt the new language at the same time, and none of them must perceive it as a threat to its own agenda. For that to happen, all of them must release compatible implementations that put everyone on an equal level at the exact same time, which is really hard to accomplish. It was very hard even to get javascript where it is now (remember the browser wars and all the incompatible extensions it spawned... ?), starting again from scratch with any new language would be extremely difficult, regardless of how "nice" the actual language is.

⬐ Macha

I believe the issue is politics. I.e. browser vendor A (any vendor) can't unilaterally introduce a programming language and expect others to follow. (MS tried with VBScript, Google gave up on doing so with Dart, for example)

This applies equally to any language.

⬐ itsnotlupus

For historical context, early IE browsers weren't hardcoded to use JavaScript. We know about VBScript, but really there was a generic framework called Active Scripting that would allow any other language to be plugged in.

Python was one of those languages. You could download an ActivePython distribution and start being able to run python in your web page with a <script language="PythonScript"> tag.

I'm not sure if this still works in current IE versions. It might.