Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

While we're on the subject, why is JavaScript the only language available for the browser? I can run tons of languages from the command line since they all follow the shebang (#!) convention. Why can't I run Python or Ruby with the <script> tag?

It seems like any language that had appropriate DOM bindings should be able to run so long as the user's browser has the appropriate interpreter. (Kind of like a plugin, but for embedded interpreted languages.) For example:

<script language="Python" version="2.5+" downloadfrom="http://www.python.org/dompython ">

Is this just too much to ask?!



Although you can compile the syntax of Python or Ruby into JavaScript fairly easily, the semantics don't match up very well.

You can run <script type="text/coffeescript"> today. All of the interactive bits on CoffeeScript.org are implemented with it -- and here's an example of a site that uses it for something a little more creative (View Source):

http://thelincolnshirepoacher.com/


Not to mention that coffescript will work on any javascript runtime, not only browsers. It works on rhino, on node, for scripting Qt, and anywhere you can run js.


Lambdas in Python are so pitiful compared to javascript's closures that I think this would be a very bad choice, although you're welcome to disagree with me completely, since this is completely subjective.

This might not be a bad idea for a future project like a hypothetic HTML6, but I still think it's a bad idea _in general_. The web has consistently been about standards, and enabling developers to write code once that runs on many platforms (although the realities of browsers' quirks means that you will need to endlessly tweak your code to work on a given platform). Were we to allow developers to write in any suitable language, there would be much much more work on the part of end users and browser developers to make sure that their system is up to date with the latest language X plugin so that websites that use language X as a scripting language function well/correctly.

In short, this is a bad idea because it would fracture the web, when really we should be embracing standards that make the web simpler and easier for everyone to use.


JavaScript is not the only language available for the browser. ActionScript (Flash) is also available in many browsers, albeit fewer every day. Also, most browsers have a Java run-time for "applets."

Anyone sufficiently motivated and competent could write a browser plugin that holds a run-time for Python, Ruby, C#, whatever. The problem is getting people to install it or to get the browser makers to include it as a default. By historical fluke JavaScript got baked in to browsers early on.


The number of Flash-enabled browsers is not getting "fewer every day"; it's growing. The ratio, however, is probably falling, given the rise of mobile and decent alternatives for things like video.


Actually there are millions of people who have gone out of their way to disable Flash in the browser.

Flash blockers are extremely popular these days.


If you want it to be secure and compatible, you'd have to download implementation of the language in form of bytecode for a virtual machine.

We've had that already, and it didn't go too well:

    <applet>

Also, until all current browsers (including IE9) die, any such script will be unusable or will have awful performance nad slow start caused by compatibility shim.

We're stuck with JS, because it happened to be first one that's good enough. Cost/benefit of having multiple built-in run-times (that won't be more mature and interoperable anytime soon) or adding a VM is too large.


Wouldn't it be a bit of a security risk for browsers to let web sites specify what languages can run? Get rid of the downloadfrom attribute and select from a list of options acceptable to the browser. But then you have the challenge getting your favorite language accepted by all the browsers

Maybe the next standard should require support for an additional language. The competition would benefit everybody. Even if we just put all the language names in a hat and pick one, we'd be on a better path than we are now.


If the other languages have the same constraints as JavaScript why would it be any less secure?

The real problem is getting the language deployed on a critical mass of browsers.

You can do it today by compiling to JavaScript. See: Objective-J, CoffeeScript, Gordon (Flash), GWT (Java), Pyjamas (Python), ParenScript (Lisp), HotRuby (Ruby), haXe, etc.

But of course JavaScript isn't exactly the best language to target, and it could be a lot faster if there were a secure low level VM we could target. Something like the JVM, LLVM, or NativeClient. Then the language runtime could simply be downloaded the first time a page requiring the language is loaded.


Well... you can use Python & Ruby in the browser if you're not opposed to having your users install Silverlight.

(I don't think I'd do this myself, even though I like Python quite a lot.)


That's not really Python or Ruby in the browser, that's IronPython or IronRuby running in the Silverlight's CLR via the plugin. Yes your Silverlight app can get out to the DOM and vice versa, but it's not really what Silverlight was meant for.


If you want to be pedantic and get into a debate nothing is really ruby as the language lacks a spec the best definition of Ruby we have is acts kinda like MRI 1.8.

Also, most browsers don't run really run Javascript, they run ECMAscript or JScript. It's really jQuery converted to bytecode/assembly/C on SpiderMonkey/JagerMonkey/V8/Nitro. Sure you can create a high performance web server, but that's not really what V8 was meant for.

/pedantry


Just so you know, you can only be a pedant for a little while longer; Ruby is currently being made into an ISO standard.

Not to mention RubySpec, which all major implementations are working to conform to. Even though that's built off of "What MRI/YARV do"...




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: