
Why don't they implement Python and Ruby on the web browsers? - jsnk
http://stackoverflow.com/questions/3722334/why-dont-they-implement-python-and-ruby-on-the-web-browsers
======
nupark2
The top comment states that any other options are impossible: "At this point
we must concentrate on improving the language."

I can't stand this willfully defeatist attitude. It's also not restricted to
stack-overflow participants -- this position is pervasive at Mozilla.

Why can't we have a standardized generic bytecode and VMs to run it? Why
should the web be locked to a single language _forever_? Can you imagine if we
had locked desktops and mobile only a single implementation language?

Google seems to be the only company actively looking for a solution via NaCL.
Most of the web community, on the other hand, regularly opposes efforts to
move away from JavaScript as the one true language.

~~~
MatthewPhillips
Mozilla is not against a bytecode VM. Mozilla (and the WebKit team minus
Google) is against arbitrarily adding new language VMs because they create a
major compatibility burden. Remember this:

1) JavaScript is locked in. It's too entrenched, it's never going away. Let's
just accept that.

2) That means that adding additional languages creates a burden. You're now
supporting, at minimum 2 VMs. If you're going to support a second VM you
better get it positively right. That doesn't proclude doing it, it just means
it's not coming tomorrow.

~~~
nupark2
> _JavaScript is locked in. It's too entrenched, it's never going away. Let's
> just accept that._

JavaScript doesn't have to go anywhere, it can run on a shared VM like any
other language.

> _That means that adding additional languages creates a burden. You're now
> supporting, at minimum 2 VMs. If you're going to support a second VM you
> better get it positively right. That doesn't proclude doing it, it just
> means it's not coming tomorrow._

There is literally zero investment in moving such an idea forward on the part
of Mozilla and WebKit (sans Google). In fact, there's active resistance, while
at the same time strongly favoring JavaScript as the one option.

The position more seems to be "we might chip in if someone else comes up with
the perfect answer" rather than "yes, this is a problem that needs to be
solved to improve developer productivity, application quality, and help the
web compete with other platforms".

~~~
maximusprime
> JavaScript doesn't have to go anywhere, it can run on a shared VM like any
> other language.

JS running on a general VM would be slower. That's against the interests of
the user.

People should stop caring what language it is. If you really don't have the
skill required to use Javascript, use something easier for you and get it to
compile to JS.

I've really never understood developers that bitch and whine about programming
languages all day.

Adding alternate languages to the browser does absolutely nothing for the
user. It would only be there to appease the "I shall only develop in lisp"
extremist developers.

~~~
nupark2
> _JS running on a general VM would be slower. That's against the interests of
> the user._

What do you base this on? It's sounds like an unsupported assumption regarding
the complex technical constraints involved in implementing a general purpose
VM and JIT.

Putting the technical specifics aside, intuitively, why would the general VM
be slower, especially since the requirement to support JavaScript would be
obvious to everyone involved from day 1?

~~~
azakai
>> JS running on a general VM would be slower. That's against the interests of
the user.

> What do you base this on? It's sounds like an unsupported assumption

No, he is entirely correct.

JavaScript and most dynamic languages do not run at full speed on static-
language VMs like the JVM and .NET. This is despite tremendous efforts and
motivation to run those languages quickly on such environments, see for
example Microsoft's SPUR paper and everything it has done in the CLR to speed
up dynamic languages.

The fact is, despite all those efforts, even Microsoft did not implement JS on
.NET in IE. This despite Microsoft more than anyone having the capability and
moreso the motivation ("everything on .NET"). Microsoft gave up and
implemented a new JS engine in native code, and it made that new native JS VM
a peer of .NET in Windows 8.

The reasons for this are technical: We do not know __how __to make a single VM
that runs all languages quickly. It's very difficult to do! Dynamic languages
need hand-crafted PICs for example, which are extremely difficult to make
portable and safe, which is necessary for a VM on the web. Also, low-level
details like even how to implement numbers are significant: NaNboxing for
example is used in most JS engines, but it probably doesn't make sense in a
static language VM. Having both NaNboxed numbers and 'normal' ones in one VM
is cumbersome and complex.

~~~
nupark2
> _JavaScript and most dynamic languages do not run at full speed on static-
> language VMs like the JVM and .NET. This is despite tremendous efforts and
> motivation to run those languages quickly on such environments, see for
> example Microsoft's SPUR paper and everything it has done in the CLR to
> speed up dynamic languages._

I'd argue the opposite regarding tremendous efforts and motivation; dynamic
languages were an after-thought for both the JVM and .NET, and on the JVM side
you've only seen any attempts to improve performance recently, with
invokedynamic for Java 7.

The investments here occurred long after the VMs were developed.

> _The reasons for this are technical: We do not know how to make a single VM
> that runs all languages quickly._

The same applies to compilers across the board; we do not know how to make a
compiler that applies all possible optimization available to code always,
either. I still have to manually vectorize critical paths, re-order code
(sometimes in C!) to help the compiler avoid pipeline stalls, etc.

Instead, we do the best general purpose job we can, and it's usually more than
fast enough.

What we're talking about here is a VM that has JS support as its first-order
target. Using the JVM and CLR as performance examples here -- given what they
were built for, and when -- is not particularly valid.

Speaking to NaN-boxing in particular; it's one solution to the problem, but
not the only one. I'm going to remain unconvinced here, given that dynamic
languages have almost always been a late, second-tier concern for anyone
investing serious R&D in the development of a VM/JIT/compiler.

All that said ...

> _The fact is, despite all those efforts, even Microsoft did not implement JS
> on .NET in IE. This despite Microsoft more than anyone having the capability
> and moreso the motivation ("everything on .NET"). Microsoft gave up and
> implemented a new JS engine in native code, and it made that new native JS
> VM a peer of .NET in Windows 8._

Even given the above, implementing a custom optimized JavaScript VM -- even if
it was only available in JS-only case -- would not be a failure scenario.

~~~
azakai
> I'd argue the opposite regarding tremendous efforts and motivation; dynamic
> languages were an after-thought for both the JVM and .NET, and on the JVM
> side you've only seen any attempts to improve performance recently, with
> invokedynamic for Java 7.

> The investments here occurred long after the VMs were developed.

That's a valid point. It is possible that some entirely new kind of VM could
work, that was designed from the ground up for both static and dynamic
languages. But I don't think we have any good idea of such a thing!

Until we do know how to do this, replacing the JS VMs in browsers would slow
everything currently running. And adding another VM alongside it would
decrease speed in other ways (see for example the papers that the Apple dev
mentions in the WebKit discussion for why Apple opposes adding the Dart VM
into WebKit).

~~~
nupark2
I think your points are valid as well.

I'm not ready to take it as a given that we _can't_ build a general purpose VM
capable of running JS at or very near current speeds, but it's also not a
solved problem.

~~~
azakai
I agree, I don't think it's impossible. But, we don't know how yet.

------
doublerebel
The browsers themselves are already built and powered using JS. Maintaining a
comprehensive API at the speed that web tech advances in more than one client-
side scripting language would be hellish -- browser vendors already have
enough trouble agreeing on CSS and JS standards. The Stack Overflow article
already raised a number of good reasons why not. Not sure why this is
garnering so much attention from HN.

~~~
zanny
Because we all hate javascript.

I just wish they decoupled javascript engines and browsers, made a language
agnostic api spec for the DOM, and just let html <script> tags require a
language ref and the browser would be expected to try to find a runtime on the
local machine or ask the user to install it. The monopolistic nature of
javascript in client web browsing is bad for innovation.

~~~
jlongster
Really? You're discounting all of the incredible webapps, games, and social
networking on the web. If Javascript was bad for innovation, I sure don't see
it.

You're talking language syntax. Although it matters, it practically doesn't.
People build stuff no matter what the language looks like. Look at Obj-C, that
thing is horrid (syntax-wise) but look at all the developer adoption.

What _is_ bad for innovation is to move back to the 90's where people had to
handle local instances of applications, fix versioning problems, and have to
install something just because they want one small piece of functionality.

~~~
riffraff
> If Javascript was bad for innovation, I sure don't see it.

This is a fallacy: in absence of a peek at some alternative world where
something else was available, you can't tell that javascript improved or
worsened the innovation rate.

~~~
wwweston
It seems pretty reasonable to observe the desktop world, though, since it has
the properties under discussion, and ask ourselves whether it's easier to
deploy an application to a wide audience there or on the web.

~~~
slurgfest
Well, the problem is that this confounds all the properties of "the desktop
world" with the properties of another client-side substitute for Javascript
(like, say, Dart or some language using NaCl)

------
hannibalhorn
One point not in the existing comments is the event driven nature of the
browser - even if you're eventually able to have good support for other
runtimes in the browser (e.g., you can use Python via the Native Client
plugin) most of them have such a large existing codebase of blocking code that
I think you'd run into a lot of the same issues that you do now with Ruby &
EventMachine, or Python & Twisted.

It's what made Javascript such a great fit for nodejs - no big existing
libraries of blocking code, and everybody was already accustomed to doing
things in an event driven style due to the browser.

~~~
dextorious
That doesn't make any sense. Javascript libs are just as blocking as any
python or ruby lib.

"no big existing libraries of blocking code" (for js) just translates to "no
big existing libraries", period.

It's not like javascript has any special support for non blocking code --or
that any code that does anything useful and specific (ie. not just handling
out work to be done and callback/returned but actually _doing_ the work) can
ever be non blocking.

~~~
mhansen
Javascript has anonymous function closures - nice sugar for a non-blocking
API. Python doesn't have them.

------
whalliburton
Javascript is a perfectly reasonable underlying language. Nothing that I know
of stops people from compiling python or ruby into javascript.

I would never write pure javascript, but using languages that compile to
javascript has been pure joy.

See <http://common-lisp.net/project/parenscript/>

------
winteriscomming
A byetcode/VM approach would be an improvement on the web client. This has
been used successfully for 10+ years on the server (JVM, CLR), so why not
learn from things and advance the state of web development.

I don't understand why people defend JS so passionately. It was build in like
2 weeks, wasn't designed to build large complex applications, and hasn't
really advanced at all since its inception. There are better options out there
and the web development community should welcome any improvements to close the
gap from Native to web.

------
chops
Here's an announcement for a project implementing the Erlang VM in the
browser: [http://erlang.org/pipermail/erlang-
questions/2011-November/0...](http://erlang.org/pipermail/erlang-
questions/2011-November/062879.html)

While not _exactly_ what the OP is calling for, this is interesting
nonetheless, and it does provide a mechanism for using at least one other
language in the browser, even if it uses JS as the platform, rather than
natively supported.

~~~
Tobu
Tons of languages are doing that: OCaml, Python, Java (and Dart and GWT), C,
C++ off the top of my head. I don't think it will catch on, because Javascript
has been good enough and these runtimes have overhead.

------
GigabyteCoin
"closed as off topic by casperOne♦ 8 mins ago"

...

The number of programming topics I have had closed on that site angers me.
They are becoming Wikipedia.

~~~
Tobu
It's justified. The site is used for problem solving.

Here the problem isn't the asker's, it can't be meaningfully solved by anyone
on the site, and it is a matter of opinion whether any answer comes closer to
solving it, or that there is a problem at all.

~~~
GigabyteCoin
re: "The site is used for problem solving."

So says YOU. What's so inherently wrong with letting the people decide?
Obviously, a few hundred people found that post quite relevant to the
website's topic, helpful, and interesting.

What gives Casper the right to destroy hundreds of people's discussion on a
topic that they all deem relevant.

The "vote" on that action was approximately 300 to 1. That 1 vote of no
confidence by Casper counts more than everybody's for some reason. That is
what really gets me.

~~~
Tobu
So says the sites' FAQ:

> You should only ask practical, answerable questions based on actual problems
> that you face. Chatty, open-ended questions diminish the usefulness of our
> site and push other questions off the front page.

The ability to decide what Stack Overflow is and isn't is what makes it a
community, and not a jumble like Yahoo Answers.

And the specifics of closing questions don't have the violence of Wikipedia
deletions. I don't approve of deleting user-contributed content, especially
when it takes effort to build; closing on SO removes linking to the question,
adds a little explanatory blurb, and diverts new attention away from the
question. It doesn't destroy user contributions.

~~~
GigabyteCoin
Now you (and the site's rules) are just getting pedantic.

What's the legal definition of a "Chatty, open-ended question" or a
"practicable, answerable question"? No question is un-answerable or
impracticable imho.

Those are some very ridiculous requirements if you ask me, and 300 odd other
people who voted in favor of this question and it's answers.

P.S. in the midst of all this argument... CasperOne has added and removed his
vote of no confidence for this question. It is now "closed as not constructive
by Tim Cooper, lwburk, Tobu, 一二三, Graviton 8 hours ago". So which is it then?

------
stephth
Quoting a comment under the question:

 _Language preference aside, the fact that no language has good support in the
browser, the server and stand-alone totally baffles me._

I do wonder about this. I don't think the challenge of the task is the only
answer. I think - guess - the rest of the answer might be that in practice,
_most_ developers focus on one of those, maybe two (most probably server and
browser), rarely the three of them. I know first hand that some do work on the
three, but they must be rare, seeing the interest in this. Maybe the momentum
of the app stores bringing web devs to work on apps could gradually make
people more aware of the benefits of having a universal language. Don't get me
wrong, I enjoy the variety of languages, but I would be very happy to be able
to focus and become proficient at one only language, even if that means giving
up on some language specific advantages.

Ironically (given of the context of the comment), javascript might be what
comes closest today.

------
yalogin
The other way to put this question is - Is there sufficient reason/motivation
to try to replace Javascript with something else? What does JS lack or what
are its limitations?

~~~
mixmastamyk
The lack of keyword default arguments drives me nuts, python just does it so
well. Not to mention ===, etc, etc.

None of these things are a showstoppers, but rather amount to "death by paper
cut" that in my mind that make the language unsatisfying to use.

~~~
danmaz74
You can just use CoffeScript for those little problems.

~~~
mixmastamyk
I've looked at it, and while nifty, makes me worry about leaky abstractions
and future support.

Now that you mention it if I'm going to do that, why not use the python-to-
javascript compiler from pyjamas? ... hmm.

~~~
danmaz74
The difference is that CF is very close to javascript and makes it very easy
to transition. But of course, if you prefer python, why not :)

Talking about future support, as CF is included in Rails 3.1, I guess that it
should be guaranteed enough.

~~~
mixmastamyk
I looked in to it. While technically possible it looks like you'll have to
include a script to implement the python-like objects. That's a bit more than
I wanted, just to write javascript in python syntax... so I guess it's not
very practical.

------
reaktivo
I remember being impressed by a Microsoft project[1] a few years ago that did
exactly this, it seems it never took off.

[1] <http://visitmix.com/labs/gestalt/>

~~~
BrianLy
It's based on IronPython/IronRuby/DLR. I've been to a few PyCons and the
CPython-based developers never seemed all that interested in it due to library
support, and the majority of work happening on UNIX platforms. At the same
time .NET developers didn't know what to do with this great set of tools.

------
ebbv
If you spend all your energy complaining about JavaScript and demanding the
browser vendors provide you with a better replacement the problem here is not
JavaScript, it's you.

JavaScript is far from the best language ever created, but it's also far from
the worst.

The biggest pain in the ass working with JavaScript on a day to day basis is
not JavaScript itself -- most of its follies can be avoided by good
programming practices -- it's the DOM.

~~~
winteriscomming
JS has lots and lots of fundametal issues. Weird OO implementation (argue all
you want but prototype inheritance is not what the prevailing wisdom is on how
to do OO), no type system (at least give the option!), no packages/modules, no
generics.

Don't people want dev tools to better help them building and refactoring web
code? Web dev is like 15 years behind server development.

~~~
bzbarsky
Of course some of these things are being fixed (e.g. modules are being added;
there has been talk of optional types). At least when Google or Microsoft
aren't dragging their feet and sabotaging the process.

As for generics, I'm not sure what you're looking for there; it's pretty
simple to write generic functions in JS, or indeed any language with duck
typing, no?

------
sampsonjs
Just don't tell me we need to have JavaScript on the server side too, for
like, consistency, man.

------
VikingCoder
Mono (actually a fork of it) can already compile C# to run on Chrome
NativeClient. So, you're very close, there.

Also, this:

[http://mail.python.org/pipermail/python-
dev/2009-June/090038...](http://mail.python.org/pipermail/python-
dev/2009-June/090038.html)

------
zeeone
If Python uses indentation rather than curly braces or keywords, then it would
not allow for minimization or obfuscation when used in the browser. This is
the main reason IMO Google chose to design Dart with curly braces.

~~~
tikhonj
Playing the devil's advocate, if the browser just had a VM and ran bytecode,
the syntax wouldn't matter.

------
mbowcock
This is an interesting implementation of python in the browser. It's a python
interpreter written in JS, so you wouldn't need any new software on the users
end.

<http://www.skulpt.org/>

------
Pedrom
I would prefer a standard byte-code VM inside of every browser so we could
just make compilers targeting that VM. Then anyone could choose their
preferred language :)

~~~
slurgfest
I would too, but what will be the characteristics of that VM?

And who 'owns' the technology?

------
DanielRibeiro
Well people are doing something:

<http://repl.it/>

<http://syntensity.com/static/python.html>

<https://github.com/replit/emscripted-ruby>

------
rbanffy
The shortest good answer I can come up with is reducing security exposure.
Ending support for JavaScript is not an option, so browser makers would have
to deal with the surface of one or two extra languages in addition to
JavaScript.

I don't think they need the extra work.

------
stock_toaster
Those languages (which I both quite enjoy) are a bit slow though. Maybe
something like Lua which already has a pretty amazing JIT available?

------
elchief
1\. why does stackoverflow close all the interesting questions?

2\. fuck is wrong with javascript?

~~~
htilford
Interesting questions don't have definitive answers.

