4 ms·

A high-profile fork: one year of Blink and Webkit

152 points by progers7 12y ago

illumen 12y ago
They're both KHTML to me. https://en.wikipedia.org/wiki/KHTML https://en.wikipedia.org/wiki/KHTML
- nostrademons 12y ago
  As a web developer, they're definitely not KHTML to me. Have you tried doing modern webapp development on Konqueror lately?
  - emilsedgh 12y ago
    I guess parent post was just sentimental. But, just to let you know, Konqueror has the ability to use multiple engines. It supports both KHTML and Webkit. You could have a tab rendered with KHTML and another one with Webkit.
Siecje 12y ago
I thought Blink was trying to Implement the DOM in JS? So it would have less C++ code but more JS.
- Touche 12y ago
  Not sure where you got that idea from.
  - progers7 12y ago
    This idea is being considered: https://docs.google.com/a/google.com/presentation/d/1XvZdAF29Fgn19GCjDhHhlsECJAfOR49tpUFWrbtQAwU/preview?sle=true#slide=id.g3840fe06e_00 https://docs.google.com/a/google.com/presentation/d/1XvZdAF2...
    - Touche 12y ago
      That is really awesome.
    - mccr8 12y ago
      FWIW, Firefox has supported something along those lines for a long time, through XPCOM. A little over a year ago, I implemented something slightly more modern for WebIDL in Firefox. Our approach, and I believe the approach described in these slides, is too heavyweight for things like elements that need to be very high performance, but it is useful for a lot of things.
  - dpino 12y ago
    "Finally we’d like to explore even larger ideas like moving the entire Document Object Model (DOM) into JavaScript. This has the potential to make JavaScript DOM access dramatically faster" http://www.chromium.org/blink http://www.chromium.org/blink
    - polskibus 12y ago
      Very much aligned with React.js approach.
    - Flow 12y ago
      I think it's a very cool idea as this could let the JIT melt together browser code with user code to one tight piece of code.
    - reflectiv 12y ago
      This is interesting...one of the new javascript frameworks on the block (React.js, http://facebook.github.io/react/ http://facebook.github.io/react/) has made use of a 'virtual dom' which basically does a diff and compares it to what was already rendered and then does minimal changes to express the new state based on that. From what I hear (I have yet to dive into React, although I plan on it) this makes it VERY fast...because the DOM is essentially touched as little as possible directly.
- dragonwriter 12y ago
  I got the impression that was one of the long-term ideas that Blink might pursue rather than an active immediate focus of effort after the fork.
leeoniya 12y ago
i find the treemap graphs under "Priorities and revealed preferences" very difficult to parse. there are a lot of the same files in there with different colors. pretty poor viz choice IMO.
- yalooze 12y ago
  The players bar graph also threw me. The y-axis increments aren't equal. I realise it's to fit the highest figure in but it doesn't allow for a fair comparison. Possibly better to put an artificial ceiling on it and retain equal increments. Although that introduces it's own set of issues...
Touche 12y ago
> My high-level take on the past year is that the Blink project has been more focused on next-gen webapps with a heavy focus on the compositor, scheduling, and style subsystems. The WebKit project has been more focused on documents and improving existing pages with faster line layout and style selection (as well as an enormous amount of great work on JSC and bindings). That was always the case, even when they both used WebKit. Apple didn't include many of the "next-gen webapps" stuff that Google implemented, like IndexedDB. They were always more focused on CSS, for example.
- pavlov 12y ago
  That was a good balance of power for WebKit, IMHO. One company was focused on web apps, the other on native apps, but they both benefited from having a cross-platform renderer. With the big contributors pulling in different directions sometimes, WebKit tended to settle on a happy middle. Hopefully there's a silver lining to the Blink fork: more differentiated renderers in the wild means that web developers will have to rely more on standards again, instead of going nuts with "-webkit" prefixes and Chrome-only apps.
- om2 12y ago
  Ir's true that Blink project leaders have expressed a disinterest in improving web documents relative to web apps. But the WebKit project is very interested in both document-centric and app-centric uses of the app platform. We are frankly a little confused at the idea that there is a conflict. The best platforms include awesome document support. It's true that the Web is a little quirky in this regard - it's built inside-out with the app layer embedded inside the document layer, instead of vice versa. But that is part of what has helped it be more successful. But actions speak louder than words. Some awesome webapp-focused stuff that's been just recently announced: IndexedDB, WebGL, JavaScript Promises, Media Source Extensions, Web Crypto, a vastly improved JavaScript VM that scales from super quick startup for simple pages to advanced optimizations for complex webapps, and massive optimizations for webapp responsiveness (covering DOM, rendering, layout, style, JS, etc). And that's just the announcements, there is a lot more cool stuff in WebKit nightlies like HTML templates, new ES6 language features, major web developer tools improvements, and more.
tkubacki 12y ago
ShadowDOM is a key new web technology - hope Apple will get it one day - even MS is considering adding ShadowDOM to IE http://status.modern.ie/shadowdomunprefixed http://status.modern.ie/shadowdomunprefixed
tlrobinson 12y ago
I'm curious what the 300,000 lines of code removed in Blink were, and the corresponding but smaller removal of code in WebKit.
- Scorponok 12y ago
  Some details here: http://techcrunch.com/2013/05/16/google-has-already-removed-8-8m-lines-of-webkit-code-from-blink/ http://techcrunch.com/2013/05/16/google-has-already-removed-... As I understand it, Google and Apple did things like sandboxing in different ways for Chrome and Safari, and so there was a lot of code in both projects that could be ripped out once the alternate way of doing things didn't need to be supported any more.
- paulirish 12y ago
  Fairly sure a good chunk of it was the various WebKit ports: QT, GTK, etc. On the WebKit side they dropped the Chromium port, the V8 binding layer, etc.
azakai 12y ago
Very interesting stuff! Kudos for taking the time to put this together. I have 2 suggestions for the presentation: 1. "Cumulative commits" looks like it starts from 0 in 2013, and that total commits doubled in the two projects over a few months. This is potentially misleading - I assume this is showing additional commits since 2013, i.e., 2013 is the baseline. Might be worth mentioning that explicitly. 2. "The players" graph has a nonlinear, seemingly arbitrary scale. This is potentially misleading as it looks like e.g. Samsung has 1/3 the commits of Google, when actually it is more like 1/10. Might be worth mentioning the scale is not linear, or just using a linear scale?
- progers7 12y ago
  Excellent points, thank you. The players graph is tough. There are many 0 entries which means a true log scale is out. A linear graph ends up being dominated by Apple and Google so you can't really see the other organizations. I should call out the scale more explicitly though. Btw, the scale is technically a sqrt scale: https://github.com/mbostock/d3/wiki/Quantitative-Scales#sqrt https://github.com/mbostock/d3/wiki/Quantitative-Scales#sqrt
  - stormbrew 12y ago
    If Apple and Google dominate, the graph really should show that. Can I propose breaking it down into two graphs: One with Google, Apple and other; and the other graph breaking down the others? It's a hard problem, but I really think non-linear scales obfuscate more than they clarify for stuff like this. Non-linear scales should be used to eliminate variables not relevant to the analysis. That Google is 10* Samsung is part of, and not extrenuous to, the analysis here.
mwsherman 12y ago
What a great bit of dataviz. Would love to see similar for OpenSSL vs LibreSSL.
i_am_ralpht 12y ago
> the Blink project has been more focused on next-gen webapps with a heavy focus on the compositor, scheduling, and style subsystems. I thought Blink probably wanted to change some things about the compositor (ScrollingTree/ScrollingConstraints being separate, for example) more than doing new work on it. The WebCore compositor is in pretty good shape (composited position sticky, etc) so I'm curious if there's anything neat I'm missing out on :). I know that the Chromium Compositor (outside of Blink) has had significant upgrades in the last year, though (Chrome for Android can now scroll without dropping frames on every tile boundary -- huzzah!).

152 points by progers7 12y ago

illumen 12y ago

They're both KHTML to me. https://en.wikipedia.org/wiki/KHTML https://en.wikipedia.org/wiki/KHTML

nostrademons 12y ago
As a web developer, they're definitely not KHTML to me. Have you tried doing modern webapp development on Konqueror lately?
- emilsedgh 12y ago
  I guess parent post was just sentimental. But, just to let you know, Konqueror has the ability to use multiple engines. It supports both KHTML and Webkit. You could have a tab rendered with KHTML and another one with Webkit.

Siecje 12y ago

I thought Blink was trying to Implement the DOM in JS? So it would have less C++ code but more JS.

Touche 12y ago
Not sure where you got that idea from.
- progers7 12y ago
  This idea is being considered: https://docs.google.com/a/google.com/presentation/d/1XvZdAF29Fgn19GCjDhHhlsECJAfOR49tpUFWrbtQAwU/preview?sle=true#slide=id.g3840fe06e_00 https://docs.google.com/a/google.com/presentation/d/1XvZdAF2...
  - Touche 12y ago
    That is really awesome.
  - mccr8 12y ago
    FWIW, Firefox has supported something along those lines for a long time, through XPCOM. A little over a year ago, I implemented something slightly more modern for WebIDL in Firefox. Our approach, and I believe the approach described in these slides, is too heavyweight for things like elements that need to be very high performance, but it is useful for a lot of things.
- dpino 12y ago
  "Finally we’d like to explore even larger ideas like moving the entire Document Object Model (DOM) into JavaScript. This has the potential to make JavaScript DOM access dramatically faster" http://www.chromium.org/blink http://www.chromium.org/blink
  - polskibus 12y ago
    Very much aligned with React.js approach.
  - Flow 12y ago
    I think it's a very cool idea as this could let the JIT melt together browser code with user code to one tight piece of code.
  - reflectiv 12y ago
    This is interesting...one of the new javascript frameworks on the block (React.js, http://facebook.github.io/react/ http://facebook.github.io/react/) has made use of a 'virtual dom' which basically does a diff and compares it to what was already rendered and then does minimal changes to express the new state based on that. From what I hear (I have yet to dive into React, although I plan on it) this makes it VERY fast...because the DOM is essentially touched as little as possible directly.
dragonwriter 12y ago
I got the impression that was one of the long-term ideas that Blink might pursue rather than an active immediate focus of effort after the fork.

leeoniya 12y ago

i find the treemap graphs under "Priorities and revealed preferences" very difficult to parse. there are a lot of the same files in there with different colors. pretty poor viz choice IMO.

yalooze 12y ago
The players bar graph also threw me. The y-axis increments aren't equal. I realise it's to fit the highest figure in but it doesn't allow for a fair comparison. Possibly better to put an artificial ceiling on it and retain equal increments. Although that introduces it's own set of issues...

Touche 12y ago

> My high-level take on the past year is that the Blink project has been more focused on next-gen webapps with a heavy focus on the compositor, scheduling, and style subsystems. The WebKit project has been more focused on documents and improving existing pages with faster line layout and style selection (as well as an enormous amount of great work on JSC and bindings). That was always the case, even when they both used WebKit. Apple didn't include many of the "next-gen webapps" stuff that Google implemented, like IndexedDB. They were always more focused on CSS, for example.

pavlov 12y ago
That was a good balance of power for WebKit, IMHO. One company was focused on web apps, the other on native apps, but they both benefited from having a cross-platform renderer. With the big contributors pulling in different directions sometimes, WebKit tended to settle on a happy middle. Hopefully there's a silver lining to the Blink fork: more differentiated renderers in the wild means that web developers will have to rely more on standards again, instead of going nuts with "-webkit" prefixes and Chrome-only apps.
om2 12y ago
Ir's true that Blink project leaders have expressed a disinterest in improving web documents relative to web apps. But the WebKit project is very interested in both document-centric and app-centric uses of the app platform. We are frankly a little confused at the idea that there is a conflict. The best platforms include awesome document support. It's true that the Web is a little quirky in this regard - it's built inside-out with the app layer embedded inside the document layer, instead of vice versa. But that is part of what has helped it be more successful. But actions speak louder than words. Some awesome webapp-focused stuff that's been just recently announced: IndexedDB, WebGL, JavaScript Promises, Media Source Extensions, Web Crypto, a vastly improved JavaScript VM that scales from super quick startup for simple pages to advanced optimizations for complex webapps, and massive optimizations for webapp responsiveness (covering DOM, rendering, layout, style, JS, etc). And that's just the announcements, there is a lot more cool stuff in WebKit nightlies like HTML templates, new ES6 language features, major web developer tools improvements, and more.

tkubacki 12y ago

ShadowDOM is a key new web technology - hope Apple will get it one day - even MS is considering adding ShadowDOM to IE http://status.modern.ie/shadowdomunprefixed http://status.modern.ie/shadowdomunprefixed

tlrobinson 12y ago

I'm curious what the 300,000 lines of code removed in Blink were, and the corresponding but smaller removal of code in WebKit.

Scorponok 12y ago
Some details here: http://techcrunch.com/2013/05/16/google-has-already-removed-8-8m-lines-of-webkit-code-from-blink/ http://techcrunch.com/2013/05/16/google-has-already-removed-... As I understand it, Google and Apple did things like sandboxing in different ways for Chrome and Safari, and so there was a lot of code in both projects that could be ripped out once the alternate way of doing things didn't need to be supported any more.
paulirish 12y ago
Fairly sure a good chunk of it was the various WebKit ports: QT, GTK, etc. On the WebKit side they dropped the Chromium port, the V8 binding layer, etc.

azakai 12y ago

Very interesting stuff! Kudos for taking the time to put this together. I have 2 suggestions for the presentation: 1. "Cumulative commits" looks like it starts from 0 in 2013, and that total commits doubled in the two projects over a few months. This is potentially misleading - I assume this is showing additional commits since 2013, i.e., 2013 is the baseline. Might be worth mentioning that explicitly. 2. "The players" graph has a nonlinear, seemingly arbitrary scale. This is potentially misleading as it looks like e.g. Samsung has 1/3 the commits of Google, when actually it is more like 1/10. Might be worth mentioning the scale is not linear, or just using a linear scale?

progers7 12y ago
Excellent points, thank you. The players graph is tough. There are many 0 entries which means a true log scale is out. A linear graph ends up being dominated by Apple and Google so you can't really see the other organizations. I should call out the scale more explicitly though. Btw, the scale is technically a sqrt scale: https://github.com/mbostock/d3/wiki/Quantitative-Scales#sqrt https://github.com/mbostock/d3/wiki/Quantitative-Scales#sqrt
- stormbrew 12y ago
  If Apple and Google dominate, the graph really should show that. Can I propose breaking it down into two graphs: One with Google, Apple and other; and the other graph breaking down the others? It's a hard problem, but I really think non-linear scales obfuscate more than they clarify for stuff like this. Non-linear scales should be used to eliminate variables not relevant to the analysis. That Google is 10* Samsung is part of, and not extrenuous to, the analysis here.

mwsherman 12y ago

What a great bit of dataviz. Would love to see similar for OpenSSL vs LibreSSL.

i_am_ralpht 12y ago

> the Blink project has been more focused on next-gen webapps with a heavy focus on the compositor, scheduling, and style subsystems. I thought Blink probably wanted to change some things about the compositor (ScrollingTree/ScrollingConstraints being separate, for example) more than doing new work on it. The WebCore compositor is in pretty good shape (composited position sticky, etc) so I'm curious if there's anything neat I'm missing out on :). I know that the Chromium Compositor (outside of Blink) has had significant upgrades in the last year, though (Chrome for Android can now scroll without dropping frames on every tile boundary -- huzzah!).