
Google Dart native on WebKit? - grobmeier
http://www.grobmeier.de/google-dart-native-on-webkit-08122011.html
======
jashkenas
Instead of this blog post, read the original thread:

[https://lists.webkit.org/pipermail/webkit-
dev/2011-December/...](https://lists.webkit.org/pipermail/webkit-
dev/2011-December/thread.html)

"WebKit branch to support multiple VMs (e.g., Dart)", halfway down the page.

In particular, some of Oliver Hunt's responses:

[https://lists.webkit.org/pipermail/webkit-
dev/2011-December/...](https://lists.webkit.org/pipermail/webkit-
dev/2011-December/018804.html)

[https://lists.webkit.org/pipermail/webkit-
dev/2011-December/...](https://lists.webkit.org/pipermail/webkit-
dev/2011-December/018806.html)

[https://lists.webkit.org/pipermail/webkit-
dev/2011-December/...](https://lists.webkit.org/pipermail/webkit-
dev/2011-December/018813.html)

------
ianso
From reading that email exchange I think the answer to your question is a
definite "no" :-)

Aside from that, Google seems to be arguing that 1) there exist languages that
compile to EcmaScript, so 2) single-vendor VMs in browsers is now OK. I'm
being harsh here but that is the essence of it and it makes no sense at all.

------
nigma
Flashback from 1996: Internet Explorer 3.0 with support of VBScript and
JScript (reverse-engineered JavaScript) released.

Notabene it also featured CSS, ActiveX controls and Microsoft Java VM with
Java Applets - <http://en.wikipedia.org/wiki/Internet_Explorer_3>.

~~~
dmethvin
There was even a PerlScript plugin that you could use.

<http://en.wikipedia.org/wiki/PerlScript>

~~~
est
And ActivePython via ActiveScripting. Python could even run in ASP

------
kenny_r
Dart may not be a standard yet, but both the Dart language and the Webkit
source code are open.

Comparing this to Microsoft and ActiveX is an unfair comparison, imho.

2 things can happen: either Dart falls flat and this has no implications to
anyone, or Dart becomes a major success and nothing is stopping IE, FF or
Opera to writing their own implementation based on the open specification and
code.

I fail to see the problem.

------
dchest
HTML5 specifies "type" attribute for "script" tags
[http://www.whatwg.org/specs/web-apps/current-
work/multipage/...](http://www.whatwg.org/specs/web-apps/current-
work/multipage/scripting-1.html#attr-script-type)

    
    
      The type attribute gives the language of the script or format of the data.
    

I see no reason why some WebKit developers want to restrict what languages
people can add by technical means. If there's a political reason to restrict
it, they probably should discuss it within W3C and remove "type" attribute if
they come to conclusion that JavaScript is the only language allowed.

~~~
ianso
From the perspective of the WebKit team, I think it would be about spending a
lot of time and effort to support something that isn't part of their core
mission, the standardised web.

It would also saddle them with an extra maintenance & support burden for the
foreseeable future, to the strategic benefit of nobody but Google.

I think the original conversation was hampered by a miscommunication - it was
never made clear whether it was just about hacking on a custom version of
WebKit, or about adding Dart support to WebKit based browsers.

~~~
dchest
Let me quote the relevant paragraph from their goals in full:

    
    
      Standards Compliance
    
      WebKit aims for compliance with relevant web standards,
      and support for new standards In addition to improving
      compliance, we participate in the web standards community 
      to bring new technologies into standards, and to make sure
      new standards are practical to implement in our engine.
      We use regression testing to maintain our standards compliance
      gains.
    
    

Clearly, one of their goals is to help bring new technologies into standards,
as evidenced by first implementing CSS animations, transitions, and
transforms, and other various -webkit- things, and then submitting them to
standard bodies. Plus there are some code paths in WebKit that only apply to
OS X Dashboard, which are really the maintenance burden, given that some OS X
relevant bugs are kept in Apple's closed rdar system (I know this because I
helped find a bug in canvas). I see no problem if Google will maintain their
code -- at least, we'd be able to see bugs in an open bug-tracker.

Why restrict innovation only to certain areas?

~~~
ianso
I agree completely that innovation should not be restricted to certain areas
:-) And although I think that Dart isn't good for the web, I would encourage
_anyone_ who wants to e.g. try plugging a different VM into a browser engine
to see what happens.

Secondly I would agree that WebKit has its own OS X-related baggage, but that
just goes to show that nobody's perfect. It's not an argument for adding more.
I would also agree that in the hypothetical case of Dart support being added
to WebKit that Google would be expected to maintain their code, just as Apple
would be expected to maintain OS X stuff.

But again, I think the original conversation was had at cross-purposes. What
started as a conversation about hosting a branch of WebKit to do some
innovating turned into a conversation about standards and the broader web. In
the former case it's a purely technical question of where the work is done,
but in the latter, I think the "participate in the web standards community"
bit comes in to play. Why did Google come directly to WebKit to ask about
integrating Dart instead of talking to e.g. the W3C or WHATWG?

~~~
dchest
_Secondly I would agree that WebKit has it's own OS X-related baggage, but
that just goes to show that nobody's perfect. It's not an argument for adding
more._

We're in agreement then, because what (I think) these patches do is creating a
better abstraction for scripting engines. I'm not very familiar with WebKit
code base, but if there were similar abstractions for other things, they could
get rid of various #ifdefs, for example, for drawing code (CG, Skia, etc.)
[http://trac.webkit.org/browser/trunk/Source/WebCore/html/can...](http://trac.webkit.org/browser/trunk/Source/WebCore/html/canvas/CanvasRenderingContext2D.cpp#L962)
or Dashboard
[http://trac.webkit.org/browser/trunk/Source/WebCore/html/can...](http://trac.webkit.org/browser/trunk/Source/WebCore/html/canvas/CanvasRenderingContext2D.cpp#L962)

------
cjfont
As it has already been mentioned several times before, the lengthy process of
adopting a new technology as a universal standard (via RFC, W3C, etc.) is a
necessary evil which has greater advantages to developers/users than a single
company going commando with their own great idea. Does Google think Dart
deserves an exception to this? Most likely they are seeking a head start at
the risk of others not following (as Brendan Eich has already stated Mozilla
won't comply: <https://news.ycombinator.com/item?id=2982949>).

Edit: Added link.

------
dmethvin
> developers don’t need to use toolchains

Sorry I don't get this. If Dart is delivered to the browser in source form,
you'll still want script compressors and/or tools like Closure Compiler to
eliminate unused code. Even if Dart is delivered to the browser in bytecode
format you'll need a toolchain on the backend--and you'll still need symbol
tables for client debugging.

If anything, the toolchain and project setup will be _more_ complex for Dart
developers if they want to support all browsers. They'll need to create one
set of files for Chrome with native Dart and cross-compile to JavaScript for
all other browsers. Then they'll need to conditionally include one set of
script files or the other.

------
pilif
So. Adding stuff like the canvas tag (added to webkit to display dashboard
widgets) and CSS transforms (ditto) is ok because they were going to submit
them as standards anyways.

But adding another language besides JS is not ok because that would be bad for
the web.

Now, personally I don't care about dart, but I know that I had the same bad
feeling back in the day when Safari learned the then nonstandard canvas tag
than I have now when it should learn the nonstandard scripting language.

I do find it hypocritical though to allow one and disallow the other.

~~~
wwweston
Was there any standardized feature out there that canvas displaced? Heck,
given that Flash didn't do generated bitmaps and Java applets were largely
dead by the time canvas hit, was there _anything_ that it displaced? Or even a
similar competing feature in another browser?

By contrast, Dart is squarely aimed at competing with a feature that's both a
defacto and a formalized standard for web browsers. Not an abandoned and aging
feature, either: JavaScript's proven far more capable than most of the
industry gave it credit for, it's been growing and changing over time, and
there's currently _very_ active development, discussion, and collaboration
underway to improve the language and its performance -- and expand the
features exposed to it by various APIs.

There's a world of difference between those two situations. In the former,
you're introducing a new feature a platform doesn't have yet. In the later,
you're splitting the industry on an existing feature.

------
kombine
Please give us a proper VM like .NET(Mono is a good candidate), Java, Parrot
or whatever instead of yet another crap language(both Dart and JS are shit).
Provide a VM level binding layer to the DOM, and everyone will be happy.
Really, I didn't expect that a company like Google will be so stupid to do so.

~~~
draegtun
Mozilla did donate $10k to The Perl Foundation back in 2007. I think it was
mainly a philanthropic action to help Perl6/Parrot. However they may also be
eyeing a future possibility for hosting their Firefox languages on top of the
ParrotVM.

ref: <http://www.mozilla.org/grants/perl-foundation.html> &
[http://www.parrotblog.org/2008/09/final-report-for-
mozilla-f...](http://www.parrotblog.org/2008/09/final-report-for-mozilla-
foundation-and.html)

------
azakai
> It looks like Dart is going to become native on the WebKit Browser.

No, the actual WebKit mailing list shows the exact opposite. Opposition
(mainly from Apple) was quite strong, and it looks like Google will not be
able to do this as a WebKit branch.

Instead, it will be a branch somewhere outside WebKit apparently. In that
respect it will be like several other Google-specific technologies that are in
Chrome but not WebKit, like NaCl and Pepper.

------
nathanwdavis
They are NOT asking the Webkit project to add Dart. They want to get a
pluggable VM system into Webkit. Then once that is in place, Google would not
need to fork Webkit to get Dart into Chrome. And any other vendor that wants
to be able to extend Webkit with another VM would not need to fork it either.
It is clear that Google wants to get a Dart VM into Chrome, and I would rather
that happen via a pluggable VM system than via a fork of WebKit.

------
hasmoo
What happened to Google's motto "Don't be evil?". Obviously they are trying to
balkanize the web with non-standard technologies again.

~~~
melling
Why would this be evil as long as Dart remains an open standard? Making it run
better on their platform would incentivize the adoption of Chrome and Dart.

Getting near native performance in the browser would help take web apps to
another level. Photoshop in a browser, for example.

~~~
davidu
You've forgotten your history.

<http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish>

And don't think it's not possible, a number of MSFT folks who employed this
strategy are now in leadership roles at GOOG.

~~~
Calamitous
[citation needed]

~~~
davidu
Are you kidding? Start with Vic Gundotra.

------
justncase80
Google is just going to do this whether the open web wants it or not. It seems
like just giving them the cold shoulder excludes you from the conversation and
when Google flies past and you're scrambling to catch up, no amount of
bitching about lack-of-openness will help you.

------
naner
Would Dart require its own interpreter/compiler? I thought Google was just
going to expand V8 to support it. Then again I know very little about
compilers.

------
soc88
Would have been interesting if Dart wouldn't have been such an atrocious, bad
joke of a language.

~~~
18pfsmt
Without explaining how Dart is,"such an atrocious, bad joke of a language"
this comment simply adds nothing to the discussion. I would, however, be
interested to read your critique.

~~~
soc88
They combined the worst parts of Java with the worst parts of JavaScript.

\- Verboseness

\- Patterns

\- No type safety (combined with that dishonest “optional typing” non-sense)

\- No traits (didn't they get the memo that single implementation inheritance
didn't work out?)

\- Map being no Iterable

\- No HOFs in the collection library

\- nulls even for primitive types, ...

I don't like superlatives, but I'm pretty confident calling Dart the worst
language I have seen.

The only mistake they missed are probably Checked Exceptions.

