

A high-profile fork: one year of Blink and Webkit - progers7
http://browserg.nom.es

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

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

~~~
Touche
With all due respect, IndexedDB was first developed like 5 years ago at this
point. WebGL over 3. It's fine that you have different priorities, but you
should just admit that you have different priorities instead of saying you
want both while letting webapp features lag behind by several years compared
to Chrome and Firefox.

~~~
om2
We've had support for WebGL internally for years. The decision to ship it was
based on sufficiently improving graphics driver security. For most of webgl's
existence, Apple engineers have been editors of the spec. For IndexedDB, we
originally wanted to keep pushing for WebSQL, and still believe IndexedDB is
technically inferior. But we are setting aside our personal opinions in the
interests of interoperability.

There are other features we have shipped well before Chrome or Firefox.
Everyone is first at something. Eventually the browser engines converge.
That's how the browser market works.

~~~
Touche
I know you guys are first on some things, but as I said those things generally
are CSS related. I can't think of _any_ web-app enabling current generation
features that Apple engineers are editors of the spec. Not WebRTC, not
Manifest, not Full Screen mode.

If I'm wrong, please list these specs. I'm not questioning your abilities,
just your priorities. JavaScript Promises are not webapp-enabling so that's
irrelevant. Does your IndexedDB allow storing of Blobs? That's important for
many classes of web apps (any that need to store large amounts of arbitrary
data).

~~~
om2
Would you consider Canvas, HTML5 Video, CSS Transitions and Animations,
Application Cache, or WebSQL to be web-app-enabling features?[1] We were first
to ship all of those. And they sure as heck aren't for documents primarily.

Editing a spec is a separate question from shipping order or general
engineering priority. Not sure why you are conflating the two. Sounds like
moving the goalposts.

I'd encourage to test IndexedDB in a WebKit nightly or in the Yosemite beta.
It's still kind of buggy and not necessarily complete for final, but we'd love
to hear about the key blocking issues from web developers.

[1] Yes, it seems like AppCache and WebSQL are both likely to be replaced by
newer technologies, but I don't think that's relevant to whether sufficient
priority has been placed on the area of webapps.

~~~
Touche
I bring up editing spec because it is an indicator of priorities. Apple does
edit specs, just not the type we're talking about here. As for your list of
features you guys did first, that's great and I'm appreciative of the work,
but those are all pretty dated at this point. We're talking about today's web,
not that of 5+ years ago. Anything in the last 2 years? We can both list off a
dozen from Google and Mozilla.

~~~
Touche
Arg, I really don't want to argue with someone I respect as much as I do.
Agree to disagree on this one, and thanks for your work.

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

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

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

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

------
Siecje
I thought Blink was trying to Implement the DOM in JS?

So it would have less C++ code but more JS.

~~~
Touche
Not sure where you got that idea from.

~~~
dpino
"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)

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

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

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

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

------
illumen
They're both KHTML to me.

[https://en.wikipedia.org/wiki/KHTML](https://en.wikipedia.org/wiki/KHTML)

~~~
nostrademons
As a web developer, they're definitely not KHTML to me. Have you tried doing
modern webapp development on Konqueror lately?

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

