Why don't they implement python and ruby on the web browsers?

Question

I wonder, why don't they implement other languages like python and ruby on the web browsers?

Don't they fit as client programming languages or did it just happen to be that Javascript was the first one to be implemented, and they then kept on only supporting javascript because it just worked.

I mean...I really hate Javascript compared to Ruby, no matter how hard I try to like it, as soon as I see Ruby code I want to cry for Javascript for being so ugly.

Will there be no chance at all for Ruby and Python on the browser side (without having to use Silverlight) for the next 10 years?

Answer 1

Because it would be a pain in the ass.

• Do you think browser vendors will want to bundle and maintain two or three languages just because Javascript is "ugly"?

• Does it not create an additional dependency?

• Wouldn't you think it would create more cross browser or per-implementation issues?

• This has been tried before in Internet Explorer. IE supports VB (and possibly C#) as a scripting language. Why don't Firefox or Chrome support them?

Do the benefits, if any, that these languages will supposedly bring justify all this?

Answer 2

Most probably for historical reason and help standards adoption. You also now have javascript engines that are used in many different browsers, it probably makes no sense (business speaking) to implement other languages and have no user base.

Another thing to consider is all the browsers available. Let say you write your client side in Python, and only a little percentage of the user base can execute it because they all have different browsers/engines not supporting this language. You're screwed.

ref: http://en.wikipedia.org/wiki/JavaScript

Answer 3

Microsoft does allow you to use a lot of different languages on the browser -- with the newest Silverlight add-on (not sure if this yet includes dynamic languages like Python and Ruby, for which MS does have strong implementations known as IronPython and IronRuby; I believe, at least, the plan is to support that, if they're not supported yet).

But most people apparently aren't biting, despite MS's popularity -- they'd rather stick to pages done in Javascript (or Flash, Actionscript, much of a muchness), that despite some past security glitches seem to be safely and soundly "sandboxed" now, meaning that no badly-intentioned website author can use them to read your private files (or online banking passwords, etc, etc) and send them back to evil guys for their use. I suspect some of the security worries may hark back to MS's biggest attempt to allow browsers (or at least specifically their Internet Explorer) to run a lot more code -- the Active/X "controls"... which were "barely sandboxed if at all" in some ways. Maybe this time they've got it right, but (much as this may frustrate web programmers) you can't blame people for not being all that willing to put their identities and livelihoods at (perceived) risk.

Javascript, for all of its problems (and Actionscript, a somewhat similar language) at least were designed from the start to be "sandboxed"; Python and Ruby, despite and in some sense because of being "stronger" languages, were never really designed to be sandboxed... and the difficulty of retrofitting "sandboxing" into a general-purpose language can be evinced from the fact that Python, for example, after many years and many releases attempting to support a "restricted execution mode", has at last finally and totally given up on it (as far as the official releases from the Python Software Foundation are concerned, at least -- of course this needs not curtail the possibility of completely different releases such as Microsoft's IronPython, PyPy, Jython, Pynie, &c, but it is, at least, disappointing;-).

Google's "Native Client" technology is a hopefully-revolutionary attempt to allow running native code on the client (via the browser) while maintaining sandboxing and security: should that mature to a ripe and well-accepted technology, then of course (since even, say, C or assembly language would be so safely supported!), Python or Ruby would be no problem at all.

It's early to say if it will live up to its promise, of course (I'm biased, being a personal friend with several of the developers;-) -- it does have the advantage of being an open-source technology, so any security weaknesses stand a better chance to be spotted by "white hat" guys (as they were in, say, Python's rexec idea) rather than lying hidden until spotted and exploited by the guys in black hats (as typically happens with proprietary, closed-source technologies). I don't quite share Eric Raymond's enthusiasm in proclaiming "given enough eyes, all bugs are shallow"... but I do see where he's coming from, and I suspect that, at least where security/sandboxing is concerned, he may have a point!-)

Answer 4

You can think of JavaScript as a kind of generic, cross-platform byte code that all browsers agree to support at a minimum. Whether it was a good choice for this purpose is debatable, but being that we have agreed on this standard it's much easier to just target your applications to the existing standard rather than invent a new one. Some projects, such as GWT, have made JavaScript the compilation target of another language, to get advantages such as static typechecking which JavaScript lacks.

Answer 5

First, there's the cross-browser compatibility wall in the way: for a language in a browser to be useful in general, it needs to be supported on the vast majority of users' browsers. We're only now making progress towards eliminating IE6. Even if some momentum happened within Firefox and some other browsers to, say, implement Python as a browser scripting language, the likelihood of all major browsers deciding to implement it is near-zero; and even if they do, it would be 5-10 years before it was widely-deployed enough to use in the real world.

JavaScript, as a language (distinct from the API), is pretty clean. Its syntax is entirely textbook, which any experienced developer of other modern languages can read immediately and start writing code for in minutes. Creating objects is straightforward, closures work as you'd expect, and so on. There's nothing remarkable about it, but it's essentially the most straightforward implementation of a high-level scripting language.

The benefits of offering alternatives to it browser-side simply aren't overwhelming. The only time I could see a significant benefit is where it's possible to actually share code between the server-side and client-side, but that'll never be enough to gain the momentum necessary to get either language widely adopted into browsers.

(I should note that the costs really aren't strongly related to browser compatibility. Most of the cross-browser issues with JavaScript are library issues--differences in the DOM implementation--rather than issues with the JavaScript language. Implementing another language wouldn't require a new DOM library, just a set of language bindings to the new language. That's nontrivial, but it's far more likely to lead to the same behavior in both languages--and the same set of bugs--rather than the entirely new set of bugs you'd create if you created an entirely new library.)

Answer 6

At the time JavaScript was designed, Python would have been at a very immature stage (1.2-ish) and Ruby wouldn't have existed at all. What we consider a modern scripting language now didn't exist then. Python didn't gain Unicode support (vital for a web browser) until version 1.6, several years later; Ruby... well, yeah.

The dominant scripting language then was Perl. Let us be thankful Eich didn't copy that.

Technically, a language for execution on the client side needs strong sandboxing capabilities that CPython and Ruby don't have. Whilst Python can be integrated into IE via the Windows Scripting Host, doing so completely hoses your security. It is not trivial to create a sandboxed version of a language that wasn't designed for it.

Will there be no chance at all for Ruby and Python on the browser side

No, none whatsoever, even in a restricted form that solved the security problems. Even Microsoft couldn't make VBScript for the web catch on. JavaScript is the language that works everywhere; you aren't going to be able to beat that inertia.

At this point we must concentrate on improving the language. The standardisation of ECMAScript Fifth Edition is a big step forward, offering new methods that really help with writing terse code that passes around functions like Ruby blocks. And Mozilla's JavaScript implementation offers some interesting new features like Python-style generators. (On the other hand, it also supports E4X, a vile pox on the language, so whatever.)

JS is not so bad, written tastefully. Of course, the majority of code out there, and in tutorials, is anything but tasteful. But that's hardly a problem limited to JS.

Answer 7

Essentially, netscape invented javascript. Microsoft quickly implemented it as JScript in IE so that it could properly render sites written for netscape (at the time, the predominate browser). It was standardized as ECMAScript. As other posters have mentioned, several browser vendors are working on technology to allow multiple languages to be used but this will likely fail (for the internet at least) for two reasons.

• There is a different attitude now towards cross browser compatibility. In the bad old days, when a browser implemented a proprietary extension, incompetent webmasters would gladly use them and slap "Best Viewed in Browser X" on their site. Now, cross browser compatibility is given it's rightful place as high priority

• In light of the above, for such a scheme to succeed, all major rendering engines (Trident, WebKit, Gecko) would have to incorporate it for it to see any use. Good luck getting them to agree on anything.

This is not to say that there wouldn't be use for this technology in an intranet where the IT department can dictate the browser but I doubt that such a thing would happen on the internet any time soon.

Also, despite it's warts, javascript is a very nice language.

Answer 8

Yahoo has a browser add-on called BrowserPlus that lets you create client-side web apps with Ruby. This is because BrowserPlus comes with a Ruby interpreter. They've had it for years, but it seems that not very many people know about it. Its architecture with plug-in services doesn't preclude someone writing a Python service the way they have implemented the Ruby service.

The fact that Ruby is a part of it is somewhat hidden. At the bottom of their PhotoDrop demo they have a blurb about Ruby (copied here):

Why Ruby?

You'll notice the references in the description of this demo, and throughout this site to the Ruby programming language. So the natural questions are:

• How is BrowserPlus related to Ruby?
• Why use a high level language, and more specifically, why choose Ruby?

Good questions! To answer the first, you'll notice in service explorer that there is a published RubyInterpreter service. This thing offers no functions for use by web developers, so what is it? Well, precisely it's a special typeof service, a provider service, that is available for other services to use. RubyInterpreter embeds a full Ruby interpreter (hence the name) and allows services to be written in Ruby. The benefits of authoring services in high level languages include the speed of implementation and portability. For example, the entire implementation of JSONRequest ends up being 142 lines of portable ruby code. This feature of the platform, allowing services to be authored in high level languages, means we can rapidly move from ideas to reality in terms of new services.

So why Ruby exactly? The answer here is pragmatic: Ruby provides a full featured environment with a fairly complete standard library than can be crammed into a download which is 2mb or less. Futher, it's a fun language to work in, and we're actively following and contributing to it's progress. All that said, RubyInterpreter is a service just like any other, and its existence does not preclude support for other high level languages.

In summary, extending the web with high level languages is a powerful idea that allows for rapid innovation. Embedding Ruby is the specific way that we've realized this idea.