

Why we need Python in the Browser - jinhui
http://archlinux.me/dusty/2012/03/13/why-we-need-python-in-the-browser/

======
hetman
For some time now I've been wondering why the primary scripting format
consumed by browsers is JavaScript (a language intended for humans) and not
some sort of standard bytecode that would be executed in a browser's virtual
machine.

What we need is the JSVM! In other words, something like the JVM but adapted
for the browser. That probably means it would have a more dynamic typing focus
since it makes sense for JavaScript to be the primary language targeted by the
system (though there's no reason this couldn't evolve over time just like the
JVM has).

All of a sudden you don't need to build in Python support, or Ruby support or
LISP support or whatever else you fancy into the browser. The browser no
longer cares what you compiled the script from, it just gets the standard
bytecode and everyone's happy.

~~~
Drakim
I'm sure we could have some sort of JSVM, we could even have some sort of
bytecode for the HTML, but it would destroy part of what makes the web so
great: it's openness. The ability to view the source of any webpage, and even
make chances and enhance it locally.

There is also the fact that certain optimization can only be done by the
browser if it has the actual source code rather than the compiled bytecode.

~~~
justncase80
In both .net and java there exists excellent decompilation tools where you can
easily decompile the bytecode back into java or C# or anyother language. It's
not necessarily going to give you the original source code (especially missing
comments) but it works incredibly well nonetheless. You could easily debug in
it and edit it dynamically in browser tools as well. This is pretty much a
solved problem. I wouldn't consider this a limitation worth talking about
again.

------
tomp
Python in the browser would ultimately lead to all the same problems as
Javascript in the browser. In a few years, we'll be hearing: Clojure in the
browser, Scala in the browser, Haskell in the browser.

I've been programming in Python full-time for the past 6 months, and it's main
deficiency are the same as JavaScript's: no (optional) static typing - I'm
really sick of writing checks whether my function got values of the correct
types, and unittests testing if a class's/function's signature changed in an
unexpected way.

What we need, in my opinion, is a dynamic language with powerful optional
static typing (unlike Dart, where types are just comments), with sane object-
orientedness, and support for immutable values. The core has to be really
simple, but the language has to be powerful enough so that libraries can
provide the missing functionality (math - rationals, matrices, ...;
concurrency - channels, isolates, ...; GUI, IO (with formats, ...)).

~~~
Pewpewarrows
> I'm really sick of writing checks whether my function got values of the
> correct types, and unittests testing if a class's/function's signature
> changed in an unexpected way.

Sorry to be blunt, but if every one of your Python functions and methods
begins with isinstance() checks for every parameter, you just missed the point
of the entire language. Python was built on a foundation of ducktyping, with
the mantra that "it's easier to ask forgiveness than permission" (EAFP).

Just use your parameters in whatever way you expect them to be, and either
catch the rare Exception there or allow them to bubble up. Here's some
suggested reading on the subject:

<http://www.canonical.org/~kragen/isinstance/>

[http://stackoverflow.com/questions/6092992/why-is-it-
easier-...](http://stackoverflow.com/questions/6092992/why-is-it-easier-to-
ask-forgiveness-than-permission-in-python-but-not-in-java)

~~~
haberman
The Python approach means that when an exception is thrown, it's unclear whose
fault it is. Is it a bug in the called function, or in the caller for passing
a bad parameter? The larger the program the more of a problem this becomes.

It also means that when you change a function signature, the compiler can't
tell you all the call sites you need to fix. You have to find them through
testing. This is a large barrier to aggressive refactoring.

Even the Python C API provides facilities for checking that arguments have a
specific type and raising TypeError if not, so it can't be _that_ completely
counter to the intention of the language:
<http://docs.python.org/c-api/arg.html> (see O!)

~~~
Pewpewarrows
> It also means that when you change a function signature, the compiler can't
> tell you all the call sites you need to fix. You have to find them through
> testing. This is a large barrier to aggressive refactoring.

This is a problem inherit to every dynamic language. You sacrifice brain-dead
refactoring for improvements and tradeoffs elsewhere. Not to mention that
modern IDEs and tools like Rope [1] can definitely help.

[1] <http://rope.sourceforge.net/>

------
trothamel
We don't need Python in the browser. We need x in the browser, where x is
every language and runtime.

Javascript isn't some sort of global optimum that's perfect for every possible
application. The subset of Javascript that's supported by a wide range of
current browsers certainly isn't. And the result is that people aiming for the
web environment are limited by what Javascript can do - even though there are
languages that are arguably more expressive than it.

The problem is right now, only browser makers get to decide what languages run
in the browser. Browser makers have their own concerns, and supporting new
languages hasn't been historically among them.

What would be nice to aim for is a model where browsers can support multiple
language runtimes. Instead of the browser makers being the ones to support a
language, that language's advocates would be responsible for the port - and I
suspect the competition and cooperation would make them stronger.

Ideally, the language runtimes would be installed transparently. That's the
big potential of a project like Native Client - if it lives up to its billing,
it makes downloading the latest version of a language runtime to a browser
safe, while giving near-native speed and abstract machine.

This would let Python, Ruby, Haskell, Scala, Closure, Java, non-legacy
Javascript, and more exist in the same browser, giving the web platform the
same diversity of languages as is available on the desktop.

(Mobile platforms seem to also have this problem. The recent move from
general-purpose to language-specific platforms is sub-optimal.)

~~~
skizzikskizziks
So I'm a little ignorant, but I think I'll benefit from answers more informed
people give:

My question is, why aren't people out there (who are more experienced at
programming/developing than I am) developing support for X language(s) in open
source web browsers like Firefox. I'm sure I don't fully understand how this
works yet, but can't anyone who wants to be developing this capability
independently instead of waiting for browser makers to do it?

~~~
TylerE
Because unless the major browser makers ship it in their mainline product,
it's worthless.

~~~
skizzikskizziks
That's a good point; does that imply that it can't be incorporated after the
fact? That if a number of dedicated users applied it to the product
themselves, the browser makers wouldn't come around to incorporating it?

------
carsongross
We don't need Python in the Browser.

We need a _VM SPEC_ for the browser, so we can have whatever language we
damned well please in the browser.

Why Google decided to go with Dart rather than publish a VM spec is beyond me.

~~~
kirbysayshi
Brendan Eich has talked about why bytecode + VM is a bad idea for a browser:
<http://www.aminutewithbrendan.com/pages/20101122>

If you really want a VM, it already exists. It's called JavaScript, assembly
language of the web.

I would hate for sites to start saying, "Requires the PyJSVM v0.8 or better to
function, download it now!"

EDIT: in hindsight, this post was careless. I was wrong about the "PyJSVM"
point, and I posted the minutewithbrendan link to provide commentary, not
"Eich said it, so it must be true."

What I should have said:

JavaScript is so widely used today, that anything that comes along purporting
to be better (such as bytecode, Dart, whatever) must be _so much_ better as to
provide a clear reason for developers and users. If it's just "better", then
JS will remain dominant because it's good enough. Therefore, it makes sense to
target JS from other langs. It's definitely not getting slower, and we're on
the cusp of some great APIs!

~~~
carsongross
Surprise, surprise. Mr. Javascript thinks a VM for the browser would be a bad
idea. Let's address his points:

Viewing source is a non-sequitor: the source code could be streamed down with
the bytecode.

Standardizing a bytecode is no harder than standardizing a language and DOM,
in fact, should be easier.

Versioning bytecode is no harder than versioning languages.

Bytecode does _not_ imply an implementation any more than a language does,
although it can imply semantics.

And then, at the end, he basically advocates a JS-specific bytecode. Hah. Oh,
but they aren't working on it in committee. That says about all you need to
know.

There is _nothing_ about a bytecode spec that harder than a language and
language spec.

Basically, he doesn't want any competition for Javascript. That was an
incredibly weak podcast and he should have been shredded for it. People cut
this guy way too much slack.

~~~
ootachi
The semantics are the hard part. Just making a bytecode for some language
isn't hard. The problem is coming up with some semantics that allow all
languages to be implemented efficiently on top of it. Turns out that's
extremely difficult. The JVM and .NET certainly didn't achieve that; the Java-
fied and .NET-ified versions of languages are typically slower and don't
integrate well with their host languages.

~~~
carsongross
Slower and integrate less well than _javascript_?

C'mon.

------
tuukkah
There's a Firefox extension that integrates Python:
<http://code.google.com/p/pythonext/>

With that installed, you can write extensions in Python and even include
Python code in your HTML files if you want to:
<https://developer.mozilla.org/en/PyDOM>

------
nailer
Source mapping (part of ES6) gives proper error messages for other languages
compiled into JS, I believe this would include Pyjamas etc.

But do Python programmers who haven't programmed for the browser before
realize how important async is?

Tornado and Twisted users are used to passing around functions, but they're
very small subsets of the Python community, who, if asked to fetch something
and do something with it, would generally wait until it's fetched.

~~~
jerf
"But do Python programmers who haven't programmed for the browser before
realize how important async is?"

Not a very useful question. Anyone who has ever programmed on a GUI of any
sort will know how important that is, anybody else will rapidly learn. The
vague-but-pervasive idea that web developers invented async about two years
ago and thus "async experience" can be presumed to have not penetrated out to
those other less enlightened communities who still haven't discovered its
Mighty Powers is... not exactly historically accurate, let us say. GUIs have
always had to deal with async issues, going all the way back to the dawn of
GUIs. It's not a new idea. It's probably older than you are. (It is older than
I am.)

~~~
nailer
> Anyone who has ever programmed on a GUI of any sort

Most Python folks are backend folks. As mentioned, I frequently see Python
folk (including myself a few years ago) confusing async code for JS being a
complex language.

> anybody else will rapidly learn.

Why?

Delphi and the other desktop app RAD tools took care of callback integration -
the entry point for the code was generally not shown, it was just visually
attached to the button.

------
Joeboy
Can the rpython translator support js as a target? Could you compile pypy to
js that way, to provide a python environment in existing browsers?

To be honest though, JS is a perfectly OK language for web browsers, and if
you really want to reuse python code it probably makes more sense to translate
it before it gets to the browser, using automated tools or otherwise.
Supporting everybody's favourite language natively in every browser would be
horrible.

~~~
tav
Yes, you can compile PyPy to JavaScript. There even used to be a JS backend as
part of the RPython translation toolchain, but it got dumped since no-one was
interested in working on it [1]. There've been more successful attempts like
RPythonic [2] in translating from RPython to JavaScript by going via
Emscripten [3], i.e.

    
    
      RPython -> LLVM -> Emscripten -> JavaScript
    

And, then, there have been efforts like my own which have focused on building
a WebKit bridge [4] to PyPy.

[1] [http://www.mail-archive.com/pypy-
dev@codespeak.net/msg03946....](http://www.mail-archive.com/pypy-
dev@codespeak.net/msg03946.html)

[2] [http://pyppet.blogspot.com/2011/04/rpython-to-
javascript.htm...](http://pyppet.blogspot.com/2011/04/rpython-to-
javascript.html)

[3] <https://github.com/kripken/emscripten>

[4] <https://github.com/tav/naaga/tree/master/webkit_bridge>

------
ma2rten
I like Python, but JavaScript is sort of good at what it does: evented
programming. In javascript it's really easy write a closure. I have not worked
with asynchronous frameworks like twisted, but I'd image it's a little more
awkward. Am I wrong?

~~~
justncase80
Python also has lambda syntax, therefore closures are quite easy to do.
Example:

items.select {|e| e.isFoo}

It's arguably more terse and superior to javascript in that particular feature
as well.

~~~
steve-howard
That's Ruby, if I'm not mistaken. In Python you'd do

filter(lambda e: e.isFoo, items)

~~~
andreasvc
It's more Pythonic to write

    
    
        [e for e in items if e.isFoo]

------
okal
There's <http://skulpt.org>. Not sure how complete it is, though.

------
mcdaid
The language in the browser is not the problem to me. If I could use python it
wouldn't change the fact that you still need to deal with the DOM, CSS and
browser differences.

------
dhconnelly
It seems that the primary method of disagreement used by only-JavaScript-in-
the-browser advocates is as follows:

1\. Talk about the "open web"; 2\. Tell you to compile to JavaScript.

I really don't understand why this is considered a reasonable response to
people who just want to build things with the language they prefer, without
being treated as second-class citizens.

~~~
ttt_
Maybe because people are afraid to end up with a fragmented web all over
again.

Preference of language shouldn't really be a factor. The real question is that
any change must be properly standardized and implemented by all browser
vendors else you end up with "This webpage is written in python and is only
supported by Chrome 39+ and Firefox 43+".

Does using your prefered language really outvalue that?

I think the bytecode argument is a more feasable one, as long as it could
somehow be compiled to javascript and support older browser versions
effortlessly.

~~~
steve-howard
Version fragmentation is nearly a non-issue if browser updates are automatic
by default and non-intrusive. Firefox is slowly catching up, and Chrome is
very good at this. IE would obviously need to substantially change its release
cycle if it lost enough market share, though I imagine that won't happen for
quite some time.

------
jnowl
If google is serious with Dart, I'd hope they would release some library/tool
that bridged python to chrome and supported the dart dom libraries.

I would think that would help make it popular which would help compel other
browsers to support such technology.

------
mhansen
This is ridiculous. I love python, but it has no language support for an event
loop, and if you put it in a browser, everything would have to be done in an
event loop. It'd be ugly.

Javascript excels at evented programming. Use the right tool for the job.

~~~
Yaggo
I was just going to comment that at least Python has _yield_ (generators)
which helps to avoid callback spaghetti¹, but Javascript seems to have got it
too in 1.7².

[1] <http://www.tornadoweb.org/documentation/gen.html>

[2]
[https://developer.mozilla.org/en/New_in_JavaScript_1.7#Gener...](https://developer.mozilla.org/en/New_in_JavaScript_1.7#Generators)

------
martincerdeira
I think about this, a time ago and create a drumbeat project:

[http://webcache.googleusercontent.com/search?q=cache:Q-BEBq4...](http://webcache.googleusercontent.com/search?q=cache:Q-BEBq4_Bb4J:https://batucada.mozillalabs.com/en-
US/projects/client-side-
python/+mozilla+drumbeat+python&cd=3&hl=es&ct=clnk&gl=ar&client=firefox-a)

but, sadly, nobody follows this idea...

------
spobo
If your python eventually compiles down to JavaScript it's worth doing. That
way you can get the developers to hop on because it's easier to program.
Browsers could then implement functions to directly process the python source
and not the JS which would have speed benefits.

But I really feel there is no need for python in the browser. JS is good
enough. If you want an easier way to write it use CoffeeScript.

------
scriptproof
With a tool like Enyo you can write all the code in a sort of JavaScript, and
it is converted to HTML + JavaScript. Google also has a tool to convert Java
to JavaScript. Why not a similar tool for Python (or other language)? No
practical need to have a lot of languages in the browser itself IMHO even if
it would be nice to program web pages with his favorite language.

------
andybak
An ideal situation would be installable interpreters that still allowed you to
use a system-wide rendering engine. I actually think Windows had something
similar with ActiveScripting.

I assume something like QT allows you to script the webview with whatever
language you have bindings for? Unfortunately QT+bindings is a pretty long way
from 'zero install'

~~~
hannes2000
Sounds more like plugin hell to me. I think it's becoming increasingly harder
to convince users to install browser plugins (for good reasons), and it's not
even possible on most mobile browsers.

~~~
andybak
As with the original article I'm talking about desktop apps which would
already require an installer. It's just about reducing the pain of that
install.

------
BrennanCheung
We don't need another language in the browser. We need a VM in the browser. As
in byte codes. That way ANY language can be used. JS gets compiled down to a
VM and then that is run in most implementations of JS. Why can't we just
target that VM directly and use our own tools and compilers instead of being
forced to compile it to javascript?

------
Newky
Sorry if this is a bit off-topic, but its mentioned that there is work being
done on an event loop in python, Can anyone give me some sources on this?

Are they talking about async frameworks such as twisted/tornado? or is there
more core work that I don't know about?

------
voidr
JavaScript is the bytecode that you can compile your python or whatever code
too. Just make the standards committee implement some nice features that are
useful for bytecodes and you are all set.

------
joshaidan
I remember Internet Explorer used to support VBScript. Is that still supported
in IE? It's been so long since I've used IE!

------
nkassis
What about using Native Client (nacl) to compile an implementation of python
(without the batteries)?

~~~
azakai
It would just run on Chrome, and it would just run on x86 and x86_64 machines.

~~~
nkassis
That's true but for the first part, it's mostly due to a lack of interest by
other vendors. For the second part, isn't the nacl team working on a protable
version of nacl?

It's at least one way to get python in the browser today.

~~~
azakai
> That's true but for the first part, it's mostly due to a lack of interest by
> other vendors.

The lack of interest by other vendors is because NaCl isn't an appropriate
technology for the open web, not just random lack of interest. (First and
foremost, because it is CPU-specific, while the web is supposed to run
everywhere.)

> For the second part, isn't the nacl team working on a protable version of
> nacl?

A research project called PNaCl, yes. But it is a different technology than
NaCl despite the similar name. One is based on gcc, the other llvm, one ships
CPU-specific machine code, the other bitcode, etc. So it is at this point too
early to tell if PNaCl will achieve good portability+speed, NaCl's speed
doesn't mean PNaCl will be fast too. Adopting NaCl because of the promise of
PNaCl doesn't make much sense.

------
hereonbusiness
how would one go about minimizing python code ?

------
rsanchez1
Would creating a Python interpreter that runs on Chrome's Native Client be
enough? In NaCl you have an environment that lets you take C/C++ code and
deploy programs written in that code to the browser. The Python interpreter
(and the ones for several widespread languages) is written in C. Why not put
the two together?

I've seen a proof-of-concept of this on webOS, which is essentially a browser
since JavaScript programs can run natively. In webOS 1.4.5 and above, there is
the PDK, which is a library that lets you make C/C++ programs compatible with
webOS and run them on-device. Part of the PDK is the plugin interface, which
allows JavaScript code to call C-compiled functions, which the C-compiled
program exposes to JavaScript with special PDK functions.

Since the Python interpreter is in C, it can be adapted with the PDK to allow
Python programs to run natively. Here is a post demonstrating it:

<http://www.ezequielaceto.com.ar/techblog/?p=359>

In Chrome, NaCl is analogous to the PDK, so why not have Python as an NaCl
plugin and use it to run Python in the browser? You have to imagine that if
NaCl gets widespread use, similar and compatible technology will pop up in
competing browsers, so sooner or later your Python will be cross-browser.

I'd like to see someone try Python in NaCl.

------
funkah
Just don't be so afraid of JavaScript. The future can be yours, today!

------
leon_
> the most restrictive operating systems only permit us to code in Objective C

uninformed gibberish.

------
justncase80
I think he misspelled 'Lua'.

------
mbq
Many people would be very surprised to see what MS Pyton is capable of (-:

~~~
nailer
Sure, Silverlight can run Python, but Microsoft has stepped away from plugins
in IE10, and SL/ML run poorly or not at all in most other desktops and
tablets.

------
mahmud
As a user of Real Programming Languages (Common Lisp, Java, C) I'm indifferent
to scripting languges, but if I had to choose ONE to see in the browser, it
would be Lua.

It has sane, symmetric minimal design that gets closures. It also _looks_ like
a programming language. I can type Lua into the Firebug repl and not worry
about indentation.

~~~
ramblerman
I like how you capitalized the Real Programming Languages, as if it is some
official definition.

The notion that python isn't real, is just silly.

~~~
mgkimsal
Of course Python is a Real Language, it exists, etc, yes. But it's not a Real
_Programming_ Language.

You see, everyone using python, ruby, perl, php, and other similar platforms -
we're not _programming_ , we're just _scripting_. The difference is _so_
extreme, that, well... if you don't understand, _I'm_ not going to bother
explaining.

~~~
icebraining
Sorry, Poe's law kicked-in and I mistakingly downvoted you. I'm very sorry:|

~~~
mgkimsal
Sorry too - I should have added a sarcasm tag (or, more appropriately, a
sarchasm tag).

I've been doing PHP for 16 years (among other things), and have grown tired of
the "scripting vs whatever" debates/comments/remarks/jibes/etc over the years.
That didn't come across enough in my original post - sorry. :/

