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

Question

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

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, Mar 12 '13 at 13:23
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, Mar 12 '13 at 13:33
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
Ah, it's the [Active Scripting](http://en.wikipedia.org/wiki/Active_Scripting) engine, used in many MS products, but now deprecated in favor of .NET. The [ActivePython](http://www.activestate.com/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
@MartijnPieters Several years later I'm trying it now with no success... IE just doesn't seem to recognise the interpreter. — Milind R, Jun 10 '18 at 12:36

score 23 · Accepted Answer · answered Mar 12 '13 at 18:55

23

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.

answered Mar 12 '13 at 18:55

Sean McSomething

3,781
17
25

This is the most insightful answer yet. So it’s not potential, rather time and money. – Profpatsch Mar 12 '13 at 19:50
7

"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
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? – ConditionRacer Mar 13 '13 at 20:17
@BryanOakley Exactly. – Profpatsch Mar 14 '13 at 13:17
@Justin984 -- a property of that combination of program and language implementation. – igouy May 31 '13 at 15:16
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](http://asmjs.org/)... 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 Jul 31 '14 at 15:52

score 5 · Answer 2 · edited May 23 '17 at 12:40

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.

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
@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." — , Mar 12 '13 at 14:12
@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. — , Mar 12 '13 at 15:26

Carl Smith · Answer 3 · 2015-08-19T22:35:56.873

4

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.

edited Aug 19 '15 at 22:35

answered Mar 12 '13 at 13:51

Carl Smith

695
4
13

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. – Mar 12 '13 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. – 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](http://en.wikipedia.org/wiki/Comparison_of_programming_languages#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 06: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. – Mar 13 '13 at 11:37

score 2 · Answer 4 · answered Mar 12 '13 at 13:42

2

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.

answered Mar 12 '13 at 13:42

Aaron S

21
1

5

`Someone could build a Python-to-JavaScript "compiler"/converter` Well, [someone already did](http://www.skulpt.org/). – yannis Mar 12 '13 at 13:43
[Brython](http://brython.info/doc/en/index.html) as well – 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. – Mar 12 '13 at 15:29
Ha, good ol’ bootstrapping. That’s interesting to know. – Profpatsch Mar 12 '13 at 15:48
python 3.6 -> javascript: http://www.transcrypt.org – Jacques de Hooge Mar 21 '18 at 11:21

Ten Bitcomb · Answer 5 · 2015-01-08T18:50:37.393

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.

score 0 · Answer 6 · answered Feb 17 '14 at 10:39

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.

dagnelies · Answer 7 · 2013-03-12T14:52:49.083

-4

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.

edited Mar 12 '13 at 14:52

answered Mar 12 '13 at 14:47

dagnelies

5,415
3
20
26

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. – Mar 12 '13 at 14:54
@MichaelT: Ok, I edited my response accordingly – dagnelies 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. – dagnelies Mar 12 '13 at 21:53

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

7 Answers7