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).

  • 2
    Python in the browser? When did that happen?
    – yannis
    Commented Mar 12, 2013 at 13:19
  • 6
    It didn’t. Notice the would?
    – Profpatsch
    Commented Mar 12, 2013 at 13:21
  • 16
    Well if it hasn't happened, then I don't see what the question is about. When we are talking performance, we aren't talking about languages, but about implementations of languages (and several implementations exist for Python as do for Javascript). If there isn't a client side Python implementation, what's there to talk about?
    – yannis
    Commented Mar 12, 2013 at 13:23
  • 1
    Theoretical Science! :D 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).
    – Profpatsch
    Commented Mar 12, 2013 at 13:33
  • 1
    There once was a Python integration implementation for Internet Explorer, via the COM interface that also enabled a VBScript option to script the DOM. I think MS discontinued the option to use COM integration in version 5 or 6, can't recall. Commented Mar 12, 2013 at 13:53

7 Answers 7


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.

  • This is the most insightful answer yet. So it’s not potential, rather time and money.
    – Profpatsch
    Commented Mar 12, 2013 at 19:50
  • 7
    "Five years ago it would have been a different story" ... and five years from now it might be different again. Commented Mar 12, 2013 at 20:18
  • 1
    >>A language is an abstract thing, the implementation is a concrete thing that can have performance measured.<< Yes, a programming language implementation is a concrete thing. No, a programming language implementation does not have a measurable property performance. Performance is a property of particular programs that use a language implementation, in a particular context.
    – igouy
    Commented Mar 13, 2013 at 16:56
  • 2
    @igouy So if I were to write two functionally identical programs, one in C, and one in Python, you would consider the performance difference to be a property of the application, and not the language implementation? Commented Mar 13, 2013 at 20:17
  • 1
    @ConditionRacer: There are many different ways of writing the same program, so even if a python version of the program had different performance characteristics from a C version, it wouldn't prove that no python version could be equivalent to the C version. See things like asm.js... in any language you can use a giant array to store all your program's state, and can use a small easily optimisasble subset of the language's primitive operations. (As they say "you can write C in any language".)
    – Mankarse
    Commented Jul 31, 2014 at 15:52

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.

  • 1
    This is a very good overview of “how it came to pass…” and as much as I’d like to mark it as correct answer, it answers the question “Why is Javascript the client-side language used today?”, not “Is there a design problem that would make Python too slow for client-side use?”
    – Profpatsch
    Commented Mar 12, 2013 at 14:01
  • VRML... wow that takes me back! Commented Mar 12, 2013 at 14:01
  • 1
    @Profpatsch there is no technical design issue with javascript that makes it inappropriate for being a client side language - other than that nothing uses it and unless it offers some significant advantage (likely including the interactivity with java applets), nothing ever will. The problems are not technical and unless one understands the history of "why javascript" one cannot answer "why not python."
    – user40980
    Commented Mar 12, 2013 at 14:12
  • 2
    @MichaelT: You wrote "there is no technical design issue with javascript that makes it inappropriate for being a client side language". You mean Python not JS??
    – Carl Smith
    Commented Mar 12, 2013 at 15:09
  • @CarlSmith Ahh yes. My mistake... and I cannot edit comments beyond a certain time. Thank you for the correction.
    – user40980
    Commented Mar 12, 2013 at 15:26

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.

  • 7
    Your first point doesn't follow. Everything can be compiled to almost everything (including machine code), but that doesn't mean a program written in some language L and compiled to some language C is as fast as an equivalent program written in language C.
    – user7043
    Commented Mar 12, 2013 at 14:30
  • 1
    Well, CoffeeScript is essentially a different syntax for the same core concepts as JavaScript, and C is essentially a portable assembly language. Python and Javascript, on the other hand, differ quite a lot. To implement Python correctly, you need to support (among billions of other things) the class model, operator overloading, metaclasses, etc. and most of that doesn't map to JavaScript easily and efficiently. Same problem with compiling either of them to C or machine code. A specializing JIT may be your only hope, but JIT compilers targeting JS are yet to be proven practical.
    – user7043
    Commented Mar 12, 2013 at 14:53
  • 3
    One issue is going to be the fact that you can't compress Python like you can JS -- eliminate all those spaces and newlines and there goes your scoping! So you're going to wind up with longer load times for any significant chunks of Python.
    – TMN
    Commented Mar 12, 2013 at 17:12
  • 1
    @TMN interesting point, although one would hope that Python's expressiveness would go a long way to mitigate that (and yes, that's counting lines, not characters, but still, Python's a fairly expressive language).
    – Daniel B
    Commented Mar 13, 2013 at 6:19
  • 2
    @TMN What Daniel B said, and also gzip should reduce the difference. Oh, and Python doesn't need most of those new lines and spaces. Many (though not all) lines can be joined together just fine in Python, e.g. a = something(); frobincate(a); return quux and if condition: react() are single line each. And n indentation levels needs only n spaces, not n * 4 spaces.
    – user7043
    Commented Mar 13, 2013 at 11:37

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.

  • 5
    Someone could build a Python-to-JavaScript "compiler"/converter Well, someone already did.
    – yannis
    Commented Mar 12, 2013 at 13:43
  • Brython as well
    – user28988
    Commented Mar 12, 2013 at 13:44
  • I never had to do this myself, but I am aware of people having written Java applets using Jython. That is not the same thing though as replacing Javascript in the browser with Python. Commented Mar 12, 2013 at 13:55
  • Brython works interestingly fast, at least for rather isolated parts on pages (low interaction with the DOM tree).
    – Profpatsch
    Commented Mar 12, 2013 at 15:23
  • @Profpatsch From the state of it last time I looked at, it doesn't even implement very large parts of the Python language. Conveniently, among the unimplemented features are those that are hard implement well atop of JavaScript. To paraphrase one of the PyPy authors: It's easy to make a nontrivial subset of Python fast, full Python is where it becomes hard.
    – user7043
    Commented Mar 12, 2013 at 15:29

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.


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


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.

  • 2
    Server side javascript was around in '94. jsc lets you work with javascript as a console, much the same as one would get if they typed python at a console.
    – user40980
    Commented Mar 12, 2013 at 14:54
  • @MichaelT: Ok, I edited my response accordingly
    – dagnelies
    Commented Mar 12, 2013 at 14:57
  • 2
    Also you can write desktop apps in Python.... I dont see any real reason for the distinction you are making. Commented Mar 12, 2013 at 15:12
  • Additionally, the 3D modelling tool Blender uses Python for everything from UI to mesh generation. If that's not performantly competitive, what is? Commented Mar 12, 2013 at 20:36
  • @Chris: the distinction is that javascript is a browser technology primarily, while python is mainly a desktop/console technology. My point was that comparing both makes little sense because they serve entirely different purposes.
    – dagnelies
    Commented Mar 12, 2013 at 21:53

Not the answer you're looking for? Browse other questions tagged or ask your own question.