Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

share|improve this question
2  
Python in the browser? When did that happen? –  Yannis Rizos Mar 12 '13 at 13:19
4  
It didn’t. Notice the would? –  Profpatsch Mar 12 '13 at 13:21
11  
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 Rizos Mar 12 '13 at 13:23
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. –  Martijn Pieters Mar 12 '13 at 13:53
1  
Ah, it's the Active Scripting engine, used in many MS products, but now deprecated in favor of .NET. The ActivePython python distribution included a Python engine for the Active Scripting environment, I wonder if it still does and if it'd still work in IE. –  Martijn Pieters Mar 12 '13 at 14:03

6 Answers 6

up vote 14 down vote accepted

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.

share|improve this answer
    
This is the most insightful answer yet. So it’s not potential, rather time and money. –  Profpatsch Mar 12 '13 at 19:50
4  
"Five years ago it would have been a different story" ... and five years from now it might be different again. –  Bryan Oakley Mar 12 '13 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 Mar 13 '13 at 16:56
1  
@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? –  ConditionRacer Mar 13 '13 at 20:17
    
@BryanOakley Exactly. –  Profpatsch Mar 14 '13 at 13:17

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.

share|improve this answer
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 Mar 12 '13 at 14:01
    
VRML... wow that takes me back! –  FrustratedWithFormsDesigner Mar 12 '13 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." –  MichaelT Mar 12 '13 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 Mar 12 '13 at 15:09
    
@CarlSmith Ahh yes. My mistake... and I cannot edit comments beyond a certain time. Thank you for the correction. –  MichaelT Mar 12 '13 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.

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, assuming we're not allowing 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 very much doubt that speed would turn out to be a show-stopper.

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

share|improve this answer
6  
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. –  delnan Mar 12 '13 at 14:30
    
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. –  delnan Mar 12 '13 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 Mar 12 '13 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 Mar 13 '13 at 6:19
1  
@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. –  delnan Mar 13 '13 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.

share|improve this answer
4  
Someone could build a Python-to-JavaScript "compiler"/converter Well, someone already did. –  Yannis Rizos Mar 12 '13 at 13:43
    
Brython as well –  World Engineer Mar 12 '13 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. –  Martijn Pieters Mar 12 '13 at 13:55
    
Brython works interestingly fast, at least for rather isolated parts on pages (low interaction with the DOM tree). –  Profpatsch Mar 12 '13 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. –  delnan Mar 12 '13 at 15:29

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.

share|improve this answer

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.

share|improve this answer
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. –  MichaelT Mar 12 '13 at 14:54
    
@MichaelT: Ok, I edited my response accordingly –  arnaud Mar 12 '13 at 14:57
2  
Also you can write desktop apps in Python.... I dont see any real reason for the distinction you are making. –  Chris Travers Mar 12 '13 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? –  Andrew Gray Mar 12 '13 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. –  arnaud Mar 12 '13 at 21:53

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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