Google proposes Dart bindings and Multi-VM support to WebKit

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.

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

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.

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

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.

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

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.

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

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!

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

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.

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

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

I agree. I hope they fork it. GoogKit.

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.

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

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.

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.

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

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, please stop pretending that javascript is okay for the future.

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