Google proposes Dart bindings and Multi-VM support to WebKit

by Dio Synodinos on Dec 06, 2011 |

Google’s Vijay Menon announced on the WebKit developers mailing a proposal of a branch that would add support for multiple runtimes and ready made bindings for the Dart language. Other languages that could be supported are Python, Java, Ruby, Lua and more.

Vijay justified this action using some of the usual complaints that developers have with JavaScript:

- Speed.  Many languages are faster than JavaScript when run natively and/or do not compile to JavaScript efficiently. - Developer choice.  Another runtime provides developers with more choice without requiring them to use a toolchain.
- Development experience.  Languages supported directly in the browser can have a significantly better debugging and profiling experience than they can with compiled code.

This work is currently just a patch to WebKit and it is yet early to know if it will make it to mainstream:

We have a quite early patch of this work available here:

- multi-vm changes: http://codereview.chromium.org/8806015/
- dart bindings: http://codereview.chromium.org/8802010/

We’re planning to create a multi-vm branch on webkit.org to experiment with this idea.  Our goal with this branch is to (a) demonstrate the above points and (b) show that we can do this without degrading JavaScript performance or the WebKit development experience.  If successful, we’d like to submit these changes to WebKit trunk.  We welcome your feedback.

UPDATE: Joshua Bloch, who has led the design of numerous Java platform features, like the Java Collections Framework, the java.math package, and more, has announced that he has taken up the role of core libraries architect for the Dart programming language. In addition, earlier reporting that the branch had been created was incorrect; it was merely a proposal. The webkit team have explicitly rejected the idea of introducing the ability for a new language at the web page level, arguing that in the same position as a browser supporting something like vbscript, and has the same effect: breaking the open web by making content that only works effectively in a single product.

Related Editorial

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

No they didn't by Alex Blewitt

They posted a message proposing to break the open web, and it was met with much ridicule and comparison to IE and VBScript.

In a nutshell, they were told to fork off.

Cool by Richard Hightower

I hope all WebKit browsers support this and they all support Lua, Python, Dart, Ruby and JavaScript. I hope it makes it to all tablets including iPad, and Adroid. I have never programmed in JavaScript by choice.

HTML 5 apps with Python, Dart, Lua and Ruby sound much more appealing to me. If this is supported on Chrome, and Android for starters that would be cool if it is supported one day by Apple Safari and iPad that would be excellent. Those are the real platforms of the future. It does not have to be everywhere. Just in the new stuff and eventually everywhere and it will become the standard.

I really hope they do add it to WebKit. I assume you can "turn it off" if you don't want to break the "open web".

Re: No they didn't by Richard Hightower

How does having a choice of language break the open web? It would be the apps that choose to use this that break the open web. It is a choice. I could see writing internal enterprise apps and saying you have to use Android or Safari or Chrome to use this. Or perhaps writing apps that were targeted tablets that support this (which one day could be iPad and Android). Choice never breaks the "Open Web".

VBScript failed for many reasons, but not because it broke the "Open Web".

You could support the "Open Web" and the new enhanced language "Open Web". Also tools like Dart that can compile into JavaScript could support both. Pyjamas could support "Open Web" apps and enhanced apps. This sounds, to me, more about choice and evolving the current "Open Web" than it does about breaking it.

Re: No they didn't by Dan Tines

If the open web means Javascript only, then the open web sucks.

I guess Apple engineers get to decide what WebKit's goal are now by Dan Tines

No surprise that's their attitude. And of course there's always the subtle omnipresent "You don't like Javascript because you don't understand it" stupidity.

Re: No they didn't by light iron

+1
One standard VM is great! But just one! I cannot afford two.(jvm x .net)

Re: I guess Apple engineers get to decide what WebKit's goal are now by emrah atilkan

i don't think there is stupidity here. Javascript is a toy, you can continue playing it. Other than you can check some cool OOP language, which is harder BTW.

Re: No they didn't by Shi Kafune

+1
One standard VM is great! But just one! I cannot afford two.(jvm x .net)


Both are not open sourced, last time I checked. It would be nice if we had True open source vm.

Java without the access modifiers and import statements? by Ashwin Jayaprakash

Unlike Scala, Ruby, Groovy which try to confuse developers with unintuitive syntax (gist.github.com/1406238) and convention-over-type-safety at least Dart seems to have a mild/no learning curve. Looks very Java like (is that an accident? Surely not :)

A huge plus is Josh Bloch will be doing his Collections magic again.

There doesn't seem to be any reference to threading/concurrency yet.

Is there a Dart-to-Java-bytecode compiler? IMO, if they can promise DSL friendliness and fix Generics, it'll be a fun language. They've already fixed Java's Lambda syntax in Dart.

Cheers!

Developer Choice: Competition is Good. by dev danke

The webkit team have explicitly rejected the idea of introducing the ability for a new language at the web page level...


Wow. If this statement is true, then say goodbye to browser innovation. If someone on the webkit team really said this, it means there's only One True Way to program for the web. And that way is whatever the webkit team thinks it is.

I support Google's proposal to allow competition in the web browser. Let languages compete. Over time, developers will find the best language(s) for web page programming. But they can't do this until the JavaScript death grip is broken.

It's expected the backlash by Joao Pedrosa

Let's be honest. There's a truth to trying to evolve the standard and coming up short because all you have to offer is proprietary solutions.

If Dart is a journey and not a destination as are all standards that matter, we have a long way to go still.

The excuse that JavaScript is crappy because it was made in 2 weeks won't work forever. While it's true that Dart won't make your code flawless either, helping to upgrade JavaScript produces plenty of good results and helps to remove invisible bugs.

The truth will be in the pudding. Hopefully, in due time, Dart will be revealed as the definite standards solution and move us towards the 21st century in terms of programming languages. Dart isn't a blank slate, but if you see the guys defending standards talking, they don't want blank slates.

Re: Java without the access modifiers and import statements? by Richard Hightower


Is there a Dart-to-Java-bytecode compiler?


JDart is a compiler that takes a Dart file and generate a jar file that can run on any Java 7 compatible VM.

JDart seems to have a difference of opinion on how to handle types. (It seems to favor more of a Scala, Mirah, Kotilin, Ceylon approach.) I am not sure if it is or ever will be 100% compatible with Dart. I am also not sure that it is not.


Unlike Scala, Ruby, Groovy which try to confuse developers with unintuitive syntax...


Thanks for the clarification. I never realized that this was all of their stated objective (sarcasm).

I do share your enthusiasm about Dart.
I wish Dart would have gone more of the Mirah, Scala, Kotilin, Ceylon way of implicit strong typing.
Dart actually went more of the Groovy way of "hey you can specify types if you want to".
Also Groovy 1.8 and Dart have the "if you supply a type we will check it for you at compile time but it does not really matter at runtime".

Of all of the languages Groovy is the closest to Dart but since Dart does not try to be backwards compatible with Java it gets more of a clean slate.

Re: Developer Choice: Competition is Good. by Richard Hightower

I agree. I hope they fork it. GoogKit.

Re: Developer Choice: Competition is Good. by Paulo Pinto

Wow. If this statement is true, then say goodbye to browser innovation. If someone on the webkit team really said this, it means there's only One True Way to program for the web. And that way is whatever the webkit team thinks it is.


The web is for Documents, if you are doing too much JavaScript, you should be doing a desktop application.

Re: I guess Apple engineers get to decide what WebKit's goal are now by Roopesh Shenoy

JavaScript is a toy? It is arguably the language of the future. It has more momentum than most other languages put together, just by the fact that it is probably the only language most programmers are already familiar with to at least some level (whether you are a php developer or a .net developer or a java developer, chances are you have used javascript).

Now, most programmers do use JavaScript as a toy language for minor validations or small UI tricks. And the tooling sucks so far. But it is a functional language, with some features more advanced than some of the OOP languages out there. And with NodeJS, it is the only language that can be used for the entire stack, right from client-side, to server side code (if you use document based databases that allow JSON requests, it makes even more sense to use JavaScript on the serverside).

Re: Developer Choice: Competition is Good. by Roopesh Shenoy

How much Javascript is too much, is very relative. Some might argue that a lot of today's websites are not as user friendly, and can be much better in terms of user efficiency if they used more of JavaScript.

Re: Developer Choice: Competition is Good. by Russell Leggett

HTML was originally meant for documents. That much is very clear. However, to say that "The web is for documents" is pretty narrow minded. The value of application deployment on the web using a standards based, common runtime has already proven itself. HTML5, CSS3, Ecmascript Harmony, et al. are filling the gap fairly well, and while it may not be ideal, it shows that improving the standards to better support apps means that the web can absolutely be a good place for applications.

Re: No they didn't by Richard Hightower

Having read the whole email chain... I don't think it is as simple as they were told to "fork off". This implies that no one thought it was a good idea, and everyone unanimously was against it. There was a lot of back and forth. There were doubts and they were asked to manage it in their own repo and report back. There was also a lot of interests. The <script tag has always had a type attribute. It would be good to see some other standard languages. Python, Dart and Ruby are obvious ones I'd like to see. I've worked with large JavaScript frameworks and it is not something I enjoy at all.>

Re: No they didn't by Russell Leggett

Yes, in the whole chain I think a lot of really good points were made.
1. Why should they do this now for dart when they haven't done it before for other languages like Python which has been suggested for years now.
2. Nobody uses dart yet. They should work with the JavaScript compiler for now and if it gains massive traction, standardizes, etc. It would go a long way towards providing a case for adding to Webkit.
3. Work on making the patch more complete and prove that it could do what it says it will without adding a lot of complexity and maintaining performance.

Basically, Webkit is known for being easy to understand and embed. It is production software, not a place for experimentation. They don't just add branches for side projects, and the Dart team have not made a strong enough case that the branch is worth investing in. Basically, they have a high burden of proof that the branch is deserved. However, by most people they were encouraged to work in their own repo for a while and come back later when they had more to show. I think that's pretty fair. Granted, some people were of the opinion that this is a dead end and will never be part of Webkit, but I think its up to the Dart team to prove its worth, and that's fine. They should expect that kind of resistance, and if they can't overcome it, than their goal isn't worth it. This isn't just another CSS3 property they're adding - it's a whole new language and VM that must interoperate and isn't part of any existing web standards. Its a tall order.

For the sake of our children.. by Sake .

For the sake of our children, please stop pretending that javascript is okay for the future.

Re: It's expected the backlash by Colin Jack

"The excuse that JavaScript is crappy because it was made in 2 weeks won't work forever."

Thats my main gripe with JS, the glacial speed of change.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

21 comments

Educational Content

General Feedback
Bugs
Advertising
Editorial
 InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy