Why we need Python in the Browser

In his Pycon 2012 keynote speech on Sunday, Guido van Rossum covered many of the open “Troll” questions related to the Python community. I’ve had occasion to either complain about or defend all of the topics he covered, and he did a wonderful job of addressing them. The issues could largely be divided into two categories: those that come from a fundamental misunderstanding of why Python is wonderful (e.g. whitespace), and those that are not an issue for the core python dev team, but are being actively worked on outside of core Python (e.g event loop).

And then there’s the question of supporting Python in the web browser. I honestly thought I was the only one that cared about this issue, but apparently enough people have complained about it that Guido felt a need to address it. His basic assertion is that the browsers aren’t going to support this because nobody uses it and that nobody uses it because the browsers don’t support it.

This is a political problem. Politics shouldn’t impact technical awesomeness.

The fallacious underlying assumption here is that modern HTML applications must be supported on all web browsers in order to be useful. This is no longer true. Web browser applications are not necessarily deployed to myriad unknown clients. In a way, HTML 5, CSS 3, and DOM manipulation have emerged as a de facto standard MVC and GUI system. For example, many mobile apps are developed with HTML 5 interfaces that are rendered by a packaged web library rather than an unknown browser. Client side local storage has created fully Javascript applications that require no or optional network connectivity. There are even situations where it may not be necessary to sandbox the code because it’s trusted. Many developers create personal or private projects using HTMl 5 because it’s convenient.

Convenient. It would be more convenient if we could code these projects in Python. Web browsers can be viewed as a zero install interface, a virtual machine for these applications. Such a VM has no reason to be language dependent.

It is simply unfair to all the other programming languages and coders of those languages to say, “we can’t displace Javascript, so we won’t try.” Web browsers have evolved into a virtualization layer more like operating systems than single programs. While it is true that the most restrictive operating systems only permit us to code in Objective C, in general, it is not considerate to restrict your developers a single language or environment.

It is time (in fact, long overdue) for Python to be supported in the browser, not necessarily as an equal to Javascript, but as an alternative. The web is a platform, and we must take Guido’s statement as a call to improve this platform, not to give up on it.

Update: I just stumbled across http://www.gnu.org/software/pythonwebkit/ and I can’t wait to play with it!

Update 2: From the number of comments on this article, it appears that my article has hit some web aggregator. To those users suggesting python to javascript compilers, I’ve been a minor contributor to the pyjaco project, a rewrite of the pyjs library. It has the potential to be a great tool, and the head developer, Christian Iversen is very open to outside contributions. Let’s make it better!

24 Comments

  1. Drostie says:

    There are several technical reasons why browsers won’t do it, and the most prominent is “how are you going to connect the PythonScript that you’re proposing — which will doubtless lack most of Python’s libraries — with the existing JavaScript model?”. The people who are making in-roads are ClojureScript and CoffeeScript, and what they have in common is that they compile to JavaScript so that they can solve this problem.

    Some things get a little more clumsy, especially in the event model, because Python’s lambda syntax is not as powerful as JavaScript’s inline functions and has now been obviated in the one usage case where it was important (providing a function to map() / filter(), both taken over now by generators). So the registering of event handlers is going to be a bit of a sticking point, since you can’t say e.g. “element.onmouseout = def (evt):” in Python. This might be solved with a decorator syntax, @on(element, ‘mouseout’, True) or so, but PythonScript would have to be engineered to provide it before PythonScript was ever implemented in any particular browser.

    Is the PythonScript thread going to be separate from the JavaScript thread? Will they share the same thread? Can you send events to PythonScript event listeners from JavaScript? What about the globals that Python leaves all over the place — will those pollute the JS namespace as well? And how are we going to make it so that we can rapidly parse and execute PythonScript in most browsers? Those are all the sorts of problems that ClojureScript and CoffeeScript have addressed by compiling to JavaScript. Be cautious when making a problem sound much less difficult than it is.

  2. anon says:

    Just a quick note, not using a sandbox because the code is trusted seems a bit odd to me.
    Even code I trust could have been tampered with (in case of signed code the private key could have been stolen) and putting aside a security feature is not something I’d want to do.

    Anyway, thanks for that pythonwebkit link !

  3. Mikael Lindberg says:

    I think the solution is to support all languages.

  4. Daniel Sim says:

    As a heavy javascript & occasional ruby developer, I say “why not?”.

    Though perhaps it’s not so political. Rather, a lack of man-hours to support maintenance of another scripting language while at the same time focusing on improving performance.

    • Ed S says:

      “Why not?” Because it costs time to spec out, time to implement, time to document, and time to maintain. While all of this is going on other, more important tasks are not being worked on.

      • joe says:

        “more important tasks”

        This is a value judgement, and clearly many people place python in the browser as a very important task.

  5. Alex says:

    Actually JavaScript has become quite a big target for language to language compilers, and there are projects that provide the possibility to compile Python to JavaScript such as Pyjamas ( http://pyjs.org/ ). Off course this comes with some caveats, such as debugging being a pain but they will be solved in time (for my previous debugging example, by the browsers introducing SMAP support).

    So I don’t think JavaScript will be replaced in the browser anytime soon (it’s already a really awesome language), but I’m pretty sure there will be a lot of languages that compile to it (see emscripten, CoffeeScript, ClojureScript and others).

    Just my two cents

  6. No_Thanks says:

    No Thanks. As if javascript was not bad enough, we would now have pages refusing to work because of idiotic language design decisions meaning that a lack of whitespace on a line in the Python script would render the web app broken.

    There is a place for Python, but the web it is not.

  7. TuukkaH says:

    For Python support in Firefox and XULRunner, you can install the extension http://code.google.com/p/pythonext/ and then even include Python code in your HTML files if you want to: https://developer.mozilla.org/en/PyDOM

  8. meow mix says:

    That’s funny — I was just thinking this exact same thing last night! I think that Python is well suited to this task. Plus, I think that it would help open up web programming to a lot more people, as they won’t have to deal with the confusion that is JS and its quirks.

  9. Jared says:

    What about pyjs?

  10. Mark Wales says:

    Much as I love javascript, I’d be interested to see other languages in the browser. However, it’s a minor point, and probably not a show-stopper, but any language that uses whitespace for syntax (including CoffeeScript) is always going to be problematic in browsers as it can’t be minified fully. In larger applications this could have a big impact on file sizes.

    • Arthur says:

      Minifying will be solved if the python script gets compiled into byte-code first at the server.

  11. PizzaPanther says:

    I would love to see this happen too. But if this does happen I would like to see python take the Perl – Parrot approach. Make a VM for web broswers that can execute languages built for it. This way Python could be a language that runs on the VM, and other languages could come later.

    While I’m a Python fan, others are not and I’m sure they want to see their language in the browser also. Doing this is definitely technically harder. However, if we can overcome the political problem, I think we should solve the problem in a way that solves the problem for everyone and not just the python community.

  12. David says:

    It sounds like you need to learn JavaScript. It is always going to be more powerful than Python in the browser.

  13. Leonardo Santagada says:

    The problem with pyjs and all the other “lets do a simple transform in a python source to javascript) is that you end up with something that doesn’t have python semantics so it is in my opinion of little value. To really have python on top of javascript you would have to write a complete python interpreter in javascript so you end up with a very very slow python which is also of little value. Changing a browser to support python could be pretty awesome but will take a long time and it would probably have to use pypy-sandbox (wich is not embedable right now and I think doesn’t have a jit).

  14. Joel says:

    The last thing we need is another attack vector for a browser to be compromised. Virtualized and sandboxed or not, haven’t we suffered enough? And what of individual implementations of python? Browser S supports x-features half as good as Browser C, Browser F supports others, and of course Browser E has vendor extensions with DirectZ now with hardware acceleration (but only if you’re on overlord’s favorite OS version)!!

    What you’re suggesting is about as insane as VB in the browser. [tongue firmly in cheek], I think MS already tried that. :-P

    Web doesn’t need any more fragmentation. Microsoft and Google are doing enough without Python being added to the mix.

  15. Ed S says:

    Please enlighten me to the real problem you are trying to solve here. All I see in your post is “Man, python is so hip and awesome! It’s a much better language than javascript and it’s ‘unfair’ that I can’t use my language of choice. Browser teams, please dedicate months and months of time to solving this ‘problem’ because I just really love python!”.

    Right. Just learn javascript bud. Programming languages are tools, not a goal unto themselves. You are not going to sway anyone without providing *real* arguments and demonstrating that this change would solve *real* problems. I don’t see any argument in your post that even attempts to do so. Spend your time solving problems, not inventing new ones.

  16. McDruid says:

    Just develop a Python to js translator. GWT proved this approach works exceptionally well. You would need to develop a browser plugin to support debugging your Python code in your IDE. The browser plugin (only needed for development) provides an out of band channel for the debugger to communicate with the debugged code.

  17. Christoph says:

    Even if this will never happen, the future JavaScript versions will be a lot like Python anyway.

  18. Clint says:

    +1 Ed S. My sentiments exactly. If we were to take the above and replace the words “Python” and “Py***” with “Ruby”, “C#”, or “my favorite language!” we’d call them a quack.

    You’re not really solving a problem at-large, you’re just wishing it were easier to write web apps because your skill in Python, (which I’m sure is extensive) doesn’t port in its entirety to the client.

    Hey, let’s bring back VBScript while we’re at it… that’d make .NET devs happy.

  19. Nicolas says:

    This is obviouly a good idea. Like python, we can also port C/C++, haskell, common lisp, ruby… or whatever to the browser.

    Thoses that don’t want all kind of languages (and any language one could want) available to the browser are just victim of their blob language (here it being javascript). Where the blob language is always enough and the best one for the job and all other languages are judged useless regardless of their features.

    But of course, browser can’t support natively all possible languages. This is the same for OS. Python or C are not supported natively for example on Linux or Windows. Python has an interpreter, C use a compiler.

    So a new language on the browser is no different. It just need an interpreter or compiler.

    This already work well for clojure (with clojure script), for java (GWT), soon for scala (scala GWT). I have also heard of python to js compilers, but I don’t know their exact status.

    Usefullness for different languages on the browser are obvious:

    - Many big developement teams like better statically typed language because of the IDE support and auto-documentation and additional checking it provide.

    - Language are for human, not browsers, OS or computer. IF it is possible to make another language that better fit some human needs so do it. Even if this new language is not usefull to all human… If enough developpers prefer to write code in X language, that is enough to implement it on whatever platform they want to use. You’ll be able to make a business out of it.

    - Browsers are very low level for some abstraction like having different behavior for each browser version/vendor, like managing image sprites or different text/images/resources depending of the locale. Browsers don’t provide this. Doing this on client side consume more resources for no reason. An appropriate compiler/platform/framework can perform theses optimizations on the go.

    - As we see more and more applications with heavy client code and access to the server limited to read/write distant data, we need languages that fit the domain of the application better. Some things are easier to write in prolog, lisp or haskell than javascript. Always use the best tool for the job.

    Always using Javascript is like saying a hammer is always the only tool to use whatever the task.