Why don't they implement Python and Ruby on the web browsers?

http://stackoverflow.com/questions/3722334/why-dont-they-implement-python-and-ruby-on-the-web-browsers

by jsnk • 15 years ago

122 141 15 years ago

stackoverflow.com

reaktivo• 15 years ago

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• 15 years ago

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.

hannibalhorn• 15 years ago

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• 15 years ago

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• 15 years ago

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

tolmasky• 15 years ago

Nothing in these languages prevents them from being event-based or non-blocking. All these languages have perfectly fine callback architectures. Javascript wasn't magically designed to be event-based, its just that the DOM APIs (which have nothing to do with JavaScript) were written in an event-based way because it really couldn't have been done in any other way.

Similarly, if you were to put Python or Ruby in the browser you would necessarily need them to have some sort of DOM APIs (or there wouldn't be very much they could do in the browser). Those DOM APIs would once again be written in an event-based way.

The "big existing libraries of blocking code" would be inconsequential since they would for the most part have nothing to do with the kinds of things you are doing on the web. Who cares if theres some file reading code in Ruby that is blocking? You don't read files in browsers. Think of the opposite proposal: if I went and implemented these same libraries in the same blocking fashion in JavaScript, it wouldn't all of a sudden become a worse language for the browser.

doublerebel• 15 years ago

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• 15 years ago

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• 15 years ago

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.

MatthewPhillips8• 15 years ago

We don't all hate JavaScript.

gnaritas• 15 years ago

> Because we all hate javascript.

Says who? I love JavaScript, as do a great many other developers. I look at CoffeeScript and all I can think is yuk.

maratd5• 15 years ago

> Because we all hate javascript.

You only hate JavaScript when you're starting out. When you get to know the language and how to use it properly, you begin to appreciate it in a very unique way. Until you understand what prototypical programming truly is, you don't understand JavaScript.

bzbarsky2• 15 years ago

There _is_ a language-agnostic API spec for the DOM; that's the whole point of the DOM specs. It's led to APIs that are a huge pain to use from any language (I've tried it from C++, Java, and JavaScript).

dman2• 15 years ago

Why arent browser UI's created using HTML, CSS and JS ?

wwweston5• 15 years ago

I think the various Mozilla projects actually do have facilities for this, and that some significant portion of the chrome is done this way.

Where browser UIs aren't done this way, though, I suspect it's because the APIs are for components that aren't markup based -- you write the software for the platform with the APIs it provides, or (as I believe Mozilla has done) you write your own platform on top of something else.

I think the real question to ask yourself is -- if the conventional patterns of the desktop API that we'd more or less laid down by the mid 90s were so generally awesome, why didn't some universal client based on them take off instead of the web?

It's not as if we didn't have network aware desktop-style clients at the time...

Tobu4• 15 years ago

In large part they are. Mozilla Firefox is 80% JS, and the chrome is XUL, an XML language.

nupark220• 15 years ago

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.

johno215• 15 years ago

I think the reluctance comes from being burned by Microsoft infusing their own technologies into the web browser in the past.

I realize that Python and Ruby would be standard and open but people still fear the possible fragmentation.

nupark220• 15 years ago

If the browsers were to implement a general purpose VM, the choice of actual high-level languages would be distinct from the browser maker, and open to experimentation and competition.

MatthewPhillips8• 15 years ago

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.

nupark220• 15 years ago

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

zokier2• 15 years ago

Why 2 VMs? Can't you compile JavaScript to the imaginary bytecode and have a single unified VM to run them all?

georgemcbay2• 15 years ago

If JavaScript never goes away and no other options are built into the web browser, the web will become irrelevant within 10-15 years.

No language lasts forever (especially not one that evolves as slowly as Javascript does), and tying the web to JavaScript and JavaScript only very obviously dooms the web. Not this year or three years from now, but eventually.

That nobody other than Google is making long-view plans for the future in this regard is somewhat insane.

melling• 15 years ago

A bit cliche but "never is a long." Of course it will be supplanted someday. All it takes is path in a different direction.

tzs• 15 years ago

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

The same thing could have reasonably been said of Flash just a couple of years or so ago. It was on something like 99% of browsers.

> That means that adding additional languages creates a burden. You're now supporting, at minimum 2 VMs.

Why would we need 2? Why not one VM that the additional languages AND JavaScript can all be compiled to? Then here's what you have in the browser:

1. That single VM.

2. A JavaScript compiler that compiles to that VM, so that you can still send JavaScript the traditional way as source code loaded by script tags.

Then, if someone prefers to work in Python or Ruby (or Lua, or whatever), they can compile to the byte code on the server, and send the byte code to the browser.

I'm sure that some will object that this means that if people use those other languages, then essentially they are sending binary to the browser instead of source. However, with all the hacks being done to minimize JavaScript code size, and all the machine generated JavaScript we have now, it is getting harder and harder to consider what gets sent to the client "source code" anymore for a lot of sites.

zokier2• 15 years ago

Yes, what if we had locked mobile to a single language... like Android (Java), iOS (ObjC), WP7 (C#/Silverlight), webOS (JavaScript), Symbian (Symbian/C++). Oh, well... at least we have the glaring success of MeeGo which didn't embrace single language completely.

nupark220• 15 years ago

I'll break this down:

- Android: Java, NDK (C++, C), ObjC (via Apportable), MonoTouch (C#/F#), Lua, JS

- iOS: C, C++, ObjC, JS, Lua, MonoTouch

... actually, that's as far as I want to go. Point is, you can pick your implementation language, and people do.

We're also likely to see additional language explorations on these platforms as they stabilize and mature.

wvenable• 15 years ago

> Why can't we have a standardized generic bytecode and VMs to run it?

And why stop there! There are plenty of "languages" that currently compile into HTML and CSS (like HAML and SASS for example). If we have a common VM for scripting then why not a common VM for HTML and CSS as well. Heck, we could do this all with a single VM and a common API. For backwards compatibility, we could use a new HTML tag to enable this VM. Furthermore, as a proof of concept, you could design a plugin for all the major browsers that implements this.

rsanders• 15 years ago

Hey, that sounds familiar...

maratd5• 15 years ago

> 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?

In the beginning, this was the intended design. Which is why you still specify the language when injecting code into the page.

That original design is flawed and does not work well on the web. Adding other languages is a horrible idea.

> Can you imagine if we had locked desktops and mobile only a single implementation language?

Apples and oranges. On both platforms, programs rarely interact with each other and when they do, it's through the OS using a standardized API.

The web is different. One piece of code is always interacting with another piece of code, that is interacting with a third and so on. There is no standardized API. You just call the appropriate function, if available.

To implement other languages, not only would you need to compile to bytecode, add VMs, etc. you would also need to add APIs that would allow communication between different pieces of code, written by different people, in different languages. Even if implemented, which would be a nightmare, it would still stifle the very nature of the web, the very dynamism that makes web apps different.

I don't want the web to become like the desktop or mobile space. I want to pull in code from twitter, facebook, my code, etc. and have it all work together, communicate with each other, and create a dynamic environment, all on one page, client-side. This is only coming into reality now.

nupark220• 15 years ago

The JVM and the CLR have already adequately demonstrated that multiple languages can easily (and with adequate performance) share common libraries and APIs.

Mixing Scala, Java, Ruby, JS, and PHP -- all in one process -- is simple and straight-forward on the JVM.

That said, the language of the web is HTTP and REST and open APIs, not injection/eval of JavaScript.

wwweston5• 15 years ago

If this is a complete puzzle to you, you might spend some time meditating on a parallel issue: why have we spent 20 years iterating HTML rather than proliferating various hypermedia schemes? Or "better" yet, some real universal client that works like Display Postscript or X-Windows?

Also consider that there have already been two freely targetable VM plugins which have had near total market penetration at various points in the web's history. Both of them were capable if flawed. One of them was even arguably massively successful. Why is the world moving on from them?

nupark220• 15 years ago

> why have we spent 20 years iterating HTML rather than proliferating various hypermedia schemes?

You have to remember that HTML is predated by SGML, and that HTML and its precursors were designed for the purpose of providing document markup. We've continued to evolve these solutions for document markup, and in this regard, they do an adequate job.

However, what we've seen in recent years is a rapid emergence of the use of HTML and JS for producing fully interactive, stateful, and performance-demanding applications. This wasn't due to the suitability of HTML for the task, but rather, due to the lack of any other reasonable standardized competing platform.

HTML has fallen over in this context; the DOM is ill-suited towards standard re-usable UI widget programming, JS is frustrating for building large applications, the performance profile is tremendously bad on mobile devices. This has led companies like Google to task teams with exploring how to fix HTML to be more amenable to application development -- whether it be dart, replacing the DOM, NaCL, or otherwise.*

> Also consider that there have already been two freely targetable VM plugins which have had near total market penetration at various points in the web's history. Both of them were capable if flawed.

Highly flawed. Java's plugin implementation was incredibly technically flawed (just look at the startup times), as was Adobe's (for different reasons). Moreover, Adobe Flash was not standardized, the documentation was sprawling and complex, and the bytecode format and libraries available changed significantly through the lifetime of the product.

However, this does not mean a VM isn't possible; that's what we already have today, with V8 et al.

> Or "better" yet, some real universal client that works like Display Postscript or X-Windows?

Would that be better? There are plenty of fundamental technical reasons those approaches for networked applications did not take off.

Of course, one could argue that <canvas>+webgl provide a modern successor. A generic rendering environment with client-side code execution.

lang• 15 years ago

I don't understand this fixation on js either. Even more, i don't understand the fixation on html, css and all so called web technologies. Common, web was never designed for the sort of applications we are trying to make it run. We need a totally new approach.

winteriscomming4• 15 years ago

Agreed.

cageface• 15 years ago

A totally new approach just means you have to support two incompatible standards, most likely with more bugs and inconsistencies than you have now. I'd much rather see all the browser momentum we've gained lately going towards more comprehensive support of the existing standards, as flawed as they may be.

sciurus• 15 years ago

Arguably there already is a totally new approach, centered around an app store rather than a browser.

bitops• 15 years ago

To a large extent, I think apps are the answer here. (And just to be clear: I'm not conflating apps with app stores).

Consider the early days of the web: remember when Java applets seemed like the way of the future? (Okay, that's perhaps a bit of a stretch).

But I'm serious! What is the net other than a delivery mechanism for things?

How things are implemented is not the issue, the thing people really care about is easily getting software into the hands of end users. How that software happens to work internally is immaterial for most folks.

wladimir• 15 years ago

A generalized, dynamic-language friendly bytecode to replace Javascript would be great. Please let me choose to use Python for client-side web without resorting to language cross-translation hacks.

Find the commonalities between Ruby, Python and Javascript and such (there are a lot!) and base the VM on that. "Legacy" javascript can then run in the existing VM. For JS, people can choose to compile it or let the browser compile it.

On the other hand I don't like NaCL at all. Even with all the security measures, there is just too much risk in executing native code directly from the web. Also it splits up platforms, splitting the client world into x86 and ARM, instead of allowing for innovation in CPU-land by exposing are more abstract interface. It is a repeat of the "browser plugin" paradigm, which luckily failed.

chops• 15 years ago

Here's an announcement for a project implementing the Erlang VM in the browser: http://erlang.org/pipermail/erlang-questions/2011-November/0...

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.

Tobu4• 15 years ago

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.

VikingCoder• 15 years ago

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

yalogin• 15 years ago

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?

tikhonj5• 15 years ago

Proper tail-calls! Of course, I think neither Python nor Ruby support them either, but one can dream...

mixmastamyk4• 15 years ago

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.

danmaz742• 15 years ago

You can just use CoffeScript for those little problems.

xer0• 15 years ago

"Not to mention ===, etc, etc."

In that context, I read "etc, etc" as a variant of the "etc" operator.

GigabyteCoin5• 15 years ago

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

tikhonj5• 15 years ago

I'm also annoyed by the overly eager closing, but in this case I think it's justified: it's a relatively argumentative question with no real answer. The goal behind StackOverflow is to be something vaguely like interactive documentation for all of programming, so something like this doesn't really fit in. I imagine it might fit better with a site like programmers.stackexchange.com.

d0mine• 15 years ago

The question is not closed at the moment.

GigabyteCoin5• 15 years ago

Looks like Casper really is a cowardly ghost.

Tobu4• 15 years ago

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.

GigabyteCoin5• 15 years ago

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.

ebbv• 15 years ago

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.

winteriscomming4• 15 years ago

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.

bzbarsky2• 15 years ago

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?

slurgfest3• 15 years ago

I really don't think it's fair to insist that if anyone doesn't think Javascript is the optimal solution to every client-side web programming problem, they are themselves 'the problem'.

"There are worse things than Javascript" is not a great argument for why nobody should ever try to improve the situation.

zeeone• 15 years ago

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.

tikhonj5• 15 years ago

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

mixmastamyk4• 15 years ago

gzip will negate a great deal of that advantage.

munificent2• 15 years ago

> IMO Google chose to design Dart with curly braces.

I don't think minification was a concern. Familiarity was: the world's most popular languages are curly-based so adopting that makes the language easier to learn for millions of coders.

whalliburton• 15 years ago

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/

mbowcock• 15 years ago

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• 15 years ago

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

slurgfest3• 15 years ago

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

And who 'owns' the technology?

sampsonjs• 15 years ago

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

winteriscomming4• 15 years ago

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.

stephth• 15 years ago

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.

rbanffy• 15 years ago

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• 15 years ago

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• 15 years ago

1. why does stackoverflow close all the interesting questions?

2. fuck is wrong with javascript?

htilford• 15 years ago

Interesting questions don't have definitive answers.

DanielRibeiro• 15 years ago

Well people are doing something:

http://repl.it/

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

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

Why don't they implement Python and Ruby on the web browsers?

Related Stories