Would Python be too slow for client-side use in Browsers?

I’ve heard the statement that Python would be too slow to be of any use in browsers.

I reckon Javascript is only superior in this aspect because of companies like Google who need it fast (and made it fast) because they need it to survive, but I could be wrong.

Are there any differences in how Python and Javascript are designed that have an impact on how they (would) perform in browsers?

_{Since as of now there isn’t a client side Python implementation, my question comes from the statement someone made, so maybe it has something to do with the languages itself (although I don’t believe that).}

To start with, we must make a clear distinction between languages and implementations. A language is an abstract thing, the implementation is a concrete thing that can have performance measured. For example, Lisp was once considered far too inefficient for practical use but compilers kept maturing and, eventually, dedicated hardware was developed for it; at one point in the 1980s it was the development platform of choice for high performance workstation development.

That said, the simplest answer is that a fast Javascript implementation like Google’s V8 blows the standard implementation of Python (CPython) out of the water. V8 is a highly optimized virtual machine with a JITer that is amazingly fast while CPython is a fairly simple VM in comparison. There’s an implementation of Python with a JIT but that is still only about 5-6x faster.

Five years ago it would have been a different story. Browsers had simplistic Javascript implementations because speed wasn’t a concern since nobody built ‘real’ software with it and Python would have been equal, if not faster.

In the elder times of the web, when java applets where the ~~main~~ only form of client side interactive content people realized that there needed to be a way to get forms on a web page to be able to interact with the applets on the web page.

From this, a scripting language to link the java applet to the web page was created with the name… javascript.

One can see the vestiges of this legacy with SO questions such as [1], [2], [3] – and the two official documents: Invoking JavaScript Code From an Applet and Invoking Applet Methods From JavaScript Code

With such a language available the browsers of the time (Netscape being the predominant one) made javascript available as a competitive advantage (javascript designed at Netscape – Netscape was the first server side javascript with its server back in ’94 – nearly two decades before node.js). Other browsers followed suit. People were writing pages that used javascript, other attempts at client side scripting would mean completely incompatable pages between things that work and things that don’t – or duplication of code (here’s the {insert language here} block that does this for non-javascript browsers and here is the javascript block for everyone else).

As Netscape was the dominant browser for a period, javascript took hold. While the legacy of Netscape is lost to the footnotes of the source files of Mozilla, javascript lives on and nothing has been able to over throw it’s place.

The problem remains for any other client slide scripting language. Javascript is supported on every browser. If one was to make a browser that supported python (for example) rather than javascript, it would not be able to use the vast majority of the web sites. Furthermore, unless that browser was able to get a significant share of browser traffic, web designers don’t want to create two sets of pages with different scripting languages for the same page.

One might try to make a python scripting plugin for some browser that enabled a python script on the page… akin to how vrml works today. But unless you have heard and seen of a web page that uses vrml, one is just as likely to find use for another web page for another scripting language.

I don’t think Python would be too slow at all. There’s nothing about the language that prevents it running fast enough to at least match JavaScript. It can be compiled to JavaScript, so, if nothing else, you could include a compiler in the browser and only potentially increase page load times.

UPDATE: Please see the comments below discussing why compiling Python to JS would be considerably more costly than implied here.

The problem is trying to convince the browser vendors and W3C to first choose Python, over Ruby or any other nice scripting language, then define a standardised subset, as they can not allow system calls and so on, and then implement it well, all while supporting JavaScript still. That’s not going to happen, but if it did, I doubt that speed would turn out to be a serious issue.

I think Python has its own virtual machine. I don’t have a lot of experience with Python, but I don’t see any reason why it wouldn’t perform as well as a non-optimized JavaScript engine.

Some random thoughts:

(1) You could probably run Python locally through a Java applet using Jython. The hard part I see here is that applets are very restrictive, so you might need to modify Jython to fit within the access restrictions. For instance, if it writes to a log file, you may need to remove the logging code. An applet doesn’t need to be noticeably visible.

(2) Someone could build a Python-to-JavaScript “compiler”/converter. This would be a lot of work.

It depends on the implementation of the language and not necessarily the language itself. Most JavaScript interpreters are much faster than nearly all implementations of Python.

This doesn’t mean that the Python language can’t be used at nearly the same speeds as JavaScript. Opal implements almost the full Ruby language and standard library in the browser by compiling Ruby code into JavaScript code wrapped in closures. Putting aside the overhead of including the Opal library, its speed is far closer to that of straight JavaScript than any other Ruby interpreter that I know of.

I don’t know if there is a Python equivalent of Opal, but such a project would probably mean that the answer to your question is “no”. With the increasing use of JavaScript as an “assembly language for the web”, it wouldn’t surprise me if it will be used more and more as a platform for other languages, especially as mobile computing power increases and the overhead of having a language implemented in JavaScript becomes increasingly negligent.

EDIT: Here is a list of Python implementations for the browser that compile/run on JavaScript.

https://github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-js#python

And in case you are interested, you can check out Opal, which I really like.

http://opalrb.org/

Since I doubt that browsers are ever going to come with support for separate interpreters, such compilers are probably the way of the future in terms of using languages other than JavaScript. Even now, you will get comparable performance in most areas. This is my opinion, however, so keep that in mind.

Even when you asked this question, there were already a number of python implementations available in javascript that can be used on web pages today.

Have a look at http://www.skulpt.org/ or http://www.brython.info/ for starters.

The performance doesn’t seem to be too bad, but you should test them yourself and find out.

Python is a “console” language, running on the server

Javascript is a “browser” language, running on the client

As such, they don’t compete directly

…of course there is node.js and probably python browser plugins, but then it’s more a question about the performance about a particular implementation.

Moreover, for most applications python will do just fine, except if you have to do some kind of extensive computations and squeeze out CPU cycles.

As a last note, python and javascript share many similarities. Due to their dynamic nature, both have to be interpreted at runtime and cannot be compiled as strongly as static typed languages. As such, I assume their achievable performance would be similar.

Filed under: softwareengineering - @ 16:20

Thẻ: browser, client-side, javascript, python

Thiết kế website giá rẻ

Danh mục

Would Python be too slow for client-side use in Browsers?