A high-profile fork: one year of Blink and Webkit | Hacker News Reader

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

browserg.nom.es

152 pointsprogers733 comments

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

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.

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.

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.

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.

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

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.

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.

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.

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?

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

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.

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.

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

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

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

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

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

Not sure where you got that idea from.

This idea is being considered: https://docs.google.com/a/google.com/presentation/d/1XvZdAF2...

That is really awesome.

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.

"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

Very much aligned with React.js approach.

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.

This is interesting...one of the new javascript frameworks on the block (React.js, 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.

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.

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

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

Some details here:

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.

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.

They're both KHTML to me.

https://en.wikipedia.org/wiki/KHTML

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

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.

Reply on news.ycombinator.com