Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google Dart native on WebKit?

grobmeier.de

Post reply on HN
Print view View original

31–40 of 47 posts

Re: Google Dart native on WebKit?

#31

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

Re: Google Dart native on WebKit?

#33

Post by vetinari »

hasmoo wrote: post #7
melling wrote: post #5

Earlier quoted context omitted.

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.

Open standard? Dart is neither a standard nor designed in an open process.

Just like canvas tag, right?

Re: Google Dart native on WebKit?

#34

Post by kevingadd »

pilif wrote: post #31

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 th…

It should be pretty clear that Dart and Canvas are entirely different matters. There is very little about the two that's similar, beyond trivial things like how they both began nonstandard.

Every browser vendor at times adds new tags or attributes if they think they can improve the web as a whole. When possible things are vendor prefixed, but still, it's something all the vendors do. It's the only way to get that technology into customers' hands.

Even though the canvas API is arguably a bad design, it certainly gets the job done - and nobody else stepped up to solve the problem before Apple did. It also made it into standards relatively quickly, and was implemented by other browser vendors pretty easily.

Re: Google Dart native on WebKit?

#35

Post by BrendanEich »

melling wrote: post #5
hasmoo wrote: post #2

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

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.

What open standard do you mean?

Clue: open source != open standard. Code overspecifies badly. Any implementor who cannot or will not use the (evolving) Google code would have to reverse-engineer the "interop spec", which is less specific than the C++.

Re: Google Dart native on WebKit?

#36

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

Re: Google Dart native on WebKit?

#37

Post by souichi »

BrendanEich wrote: post #35
melling wrote: post #5

Earlier quoted context omitted.

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.

What open standard do you mean? Clue: open source != open standard. Code overspecifies badly. Any implementor who cannot or will not use the (evolving) Google code would have to reverse-engineer the "interop spec", which is less specific than the C++.

Please forgive me if I am wrong but JavaScript was not an "open standard" either in the beginning. It took you 1 year to submit it to the ECMA body for consideration. And, oh boy, you are still fixing JS design mistakes with a group of quite smart engineers and computer scientists.

Now lets step back and look into the past: was JavaScript implementation or specification as open to comments and feedback as Dart is now? There are public mailing lists, issue tracker and open repositories that accept patches and suggestions. Did you have that for JavaScript?

I might be utterly wrong but I bet you did not. Yet instead of participating in the language effort or at least stepping back and patiently watching it's birth and growth into something standardizable you criticize and bash it.

May I humbly ask you why?

Re: Google Dart native on WebKit?

#38

Post by Calamitous »

davidu wrote: post #13
melling wrote: post #5

Earlier quoted context omitted.

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.

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.

[citation needed]

Re: Google Dart native on WebKit?

#39

Post by BrendanEich »

souichi wrote: post #37
BrendanEich wrote: post #35

Earlier quoted context omitted.

What open standard do you mean? Clue: open source != open standard. Code overspecifies badly. Any implementor who cannot or will not use the (evolving) Google code would have to reverse-engineer the "interop spec", which is less specific than the C++.

Please forgive me if I am wrong but JavaScript was not an "open standard" either in the beginning. It took you 1 year to submit it to the ECMA body for consideration. And, oh boy, you are still fixing JS design mistakes with a group of quite smart engineers and computer scientists. Now lets step back and look into the past: was JavaScript implementation or specification as open to comments and feedback as Dart is now…

You're new here, another 3-hour-old HN account. Do you by any chance work on Dart for Google?

In any event, why don't you catch up and familiarize yourself with my arguments by reading my comments here:

https://news.ycombinator.com/item?id=2998374

and in the whole thread:

https://news.ycombinator.com/item?id=2982256

--- begin quote ---

``Accusing me of hypocrisy shows ignorance of that word's definition in light of the history of my career.

``I'm not practicing one thing and preaching another. I worked on JS standardization less than a year after shipping it in Netscape 2 beta. After that I co-founded mozilla.org. I'm not currently doing A and preaching not-A, nor have I been doing "proprietary" work for a long time. I've paid my dues.''

--- end quote ---

As for "criticize", my comment here asks what open standard someone else (not you) meant. I'd like to know. Let's hear the other person's answer, before criticizing anyone. I did not criticize a soul in my comment.

As for "bash": stop lying. I did not bash a thing and you know it. The lamest form of non-argument is to whine about "bashing" and utterly fail to engage the substance of the other person's argument.

You, however, are making an anonymous ad-hominem attack on me for not doing something Netscape simply would not support 16 years ago. I could have quit and let VBScript win. I'm not bragging about JS but (smart people on TC39 notwithstanding -- you needn't put me down by implying they're doing all the good-parts work :-/) JS has succeeded beyond many expectations. Good luck to Dart getting the same adoption.

And JS won't go away quickly, so my position, independent of my past, is that we ought to improve it rather than starve it by trying to do a new language. Same as for HTML -- I co-founded the WHAT-WG to do HTML5 when the W3C abandoned HTML in 2004.

Make no mistake: (1) Google is pulling people off of JS to do Dart; (2) Dart will not get foreseeable adoption in any browser of significant market share but Chrome.

If Chrome had Netscape's market share, then Dart could probably become de-facto standard, as JS did back in 1996. Perhaps Chrome will get there, but it'll take a while, and in the mean time, Dart both costs JS (because Google has pulled people off of JS) and threatens to fragment the web (and WebKit first, the topic of this thread).

Re: Google Dart native on WebKit?

#40

Post by BrendanEich »

vetinari wrote: post #33
hasmoo wrote: post #7

Earlier quoted context omitted.

Open standard? Dart is neither a standard nor designed in an open process.

Just like canvas tag, right?

I remember canvas in 2004, I demo'ed it in a Firefox prototype at Web 2.0 that fall. The development of the API took place on the very early whatwg.org, mailing list and even in a few face-to-face meetings (recorded to the list). It was IIRC based on PostScript level 2, or really an Objective-C API based on the PostScript-2 model, from Apple.

But a bunch of others had early say in the wide-open (to members, and in terms of mailing list access) WHAT-WG on the exact API form and substance, and canvas evolved under this feedback years before it became a de-facto standard. It is still not a de-jure standard, as HTML5 isn't done yet.

Perhaps Dart will evolve similarly, but I doubt it. Canvas was "easy" in that 2D graphics APIs (built into OSes, or portable ones such as Cairo) already existed and were a close-enough fit to the affine-transform-only 2D canvas API. Thus for most browsers, hooking up canvas was quick work, weeks if not days, modulo spec corner case fussing that dragged out for a while.

In contrast, Dart requires either digesting the native VM source and learning to embed it (if not support it -- will other browsers just file bugs and wait for patches? doubtful), or else reverse-engineering it (some browser vendors have their own legal reasons not to use open source).

And only then, once a VM of some kind has been minimally ported into a browser, would the work to integrate it with the DOM, JS, and any other languages which might have commerce among garbage collected heaps possibly begin.

The last point means adding a cycle collector, which as Filip Pizlo of Apple points out here:

https://lists.webkit.org/pipermail/webkit-dev/2011-December/...

is likely to cost noticeable performance.

This is a far cry from canvas, both in terms of standardization politics and intrinsic complexity (which mainly determines odds of cross-browser support).

Hope I wasn't feeding a troll! This may be educational to some, anyway.

Post reply on HN