3 ms·

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,

by ianso 15y ago

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 15y ago
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 15y ago
  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 15y ago
    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/canvas/CanvasRenderingContext2D.cpp#L962 http://trac.webkit.org/browser/trunk/Source/WebCore/html/can... or Dashboard http://trac.webkit.org/browser/trunk/Source/WebCore/html/canvas/CanvasRenderingContext2D.cpp#L962 http://trac.webkit.org/browser/trunk/Source/WebCore/html/can...

by ianso 15y ago

dchest 15y ago

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 15y ago
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 15y ago
  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/canvas/CanvasRenderingContext2D.cpp#L962 http://trac.webkit.org/browser/trunk/Source/WebCore/html/can... or Dashboard http://trac.webkit.org/browser/trunk/Source/WebCore/html/canvas/CanvasRenderingContext2D.cpp#L962 http://trac.webkit.org/browser/trunk/Source/WebCore/html/can...