Firefox has a SpiderMonkey javascript engine. Chrome has V8 javascript engine.

Obviously those engines are a separate products and browsers utilize some kind of interface API to interact with them.

On the other hand programmers longed for a long time for their favorite language in browser. So much so, that we have products like GWT (for java), parenscript (for mon lisp), HJScript (for haskell), and i'm sure many other libraries for many other languages that allow programmers stay with their favorite language and generate client side code as well.

The idea is so obvious that i am surprised that there's no implementation of it yet. Why not publish the interface API of browser to language engine and allow web sites to provide custom language engines as downloadable bundles. With current internet speeds 3-4 megabytes one time download is not a problem for majority of applications, even more so for intranet usage.

So where's our pluggable engines ?

Firefox has a SpiderMonkey javascript engine. Chrome has V8 javascript engine.

Obviously those engines are a separate products and browsers utilize some kind of interface API to interact with them.

On the other hand programmers longed for a long time for their favorite language in browser. So much so, that we have products like GWT (for java), parenscript (for mon lisp), HJScript (for haskell), and i'm sure many other libraries for many other languages that allow programmers stay with their favorite language and generate client side code as well.

The idea is so obvious that i am surprised that there's no implementation of it yet. Why not publish the interface API of browser to language engine and allow web sites to provide custom language engines as downloadable bundles. With current internet speeds 3-4 megabytes one time download is not a problem for majority of applications, even more so for intranet usage.

So where's our pluggable engines ?

• javascript
• browser

Share Improve this question Follow edited May 2, 2014 at 3:57 tshepang 12.5k2525 gold badges9898 silver badges139139 bronze badges asked Apr 13, 2011 at 18:54 Vagif VerdiVagif Verdi 4,91611 gold badge2929 silver badges3333 bronze badges 2

• SpiderMonkey and V8 and not just languages, they are also a plete VM. Why not separate language from a VM, and allow third parties provide their own languages like JVM and dotnet do ? That would take care of security too. – Vagif Verdi Commented Apr 13, 2011 at 19:08
• I fail to see the benefit... why would you want this? – Ruan Mendes Commented Jun 6, 2012 at 14:54

Add a ment  | 

4 Answers 4

Sorted by: Reset to default 10

You don't need pluggable engines really, just an agreed upon byte-code format. Google is going down that path now with NaCl and PNaCl which is based on LLVM. So any program that piled down to a safe subset of LLVM byte-code could be run in the browser.

Browser vendors can't even agree on a mon video format (see the html5 <video> debate) or on how the document DOM object should look like, and you want them to agree on a whole language interface?

Good luck.

I guess you forgot about applets and embed's. Both offer exactly what you want. And both suck for the very same reason.

We've been down this route in the past.

Older versions of IE supported VBScript as a scripting language in addition to JScript.

The result was a whole load of sites that only worked in IE.

This isn't what the web needs again. As a developer, I may desperately want to write code using my favourite language, but as a user I want to be able to browse all sites on the web without having to worry about which plug-ins I need for any given site, or whether my preferred browser can even use those plug-ins.

This is the problem that Microsoft's Silverlight has had. It might be a marvellous technology, but to the end user, why do I want another plug-in? Silverlight has managed to gain some market share thanks to the sheer power of Microsoft, but really not that much.

Now, if the code reaching the end user is consistent, regardless of the language it's written in, then the language doesn't matter. But this effectively means piled code (or at least bytecode), which is a whole different kettle of fish to running a scripting language in the browser.