Infrequently Noted

You deride others for offering their point of view on what the news of google's press release means, and then offer your own? What matters to you is not the same as everyone else, no matter how convincingly you delude yourself. Perhaps you should rephrase your statement, "May ME forgive everyone else for existing."

Given that the primary impetus here is apparently about the ability to cut down the edit-build-run-test cycle for developers (a worthy goal!), and that you admit that the project is "a massive C++ behemoth" (a language not known for its speedy compilation or for being easy on programmers, to say the least), are there any plans for Blink to migrate to a faster, more concise, or otherwise more modern language?

I've seen a ton of work done the past few years to try to make C++ programs build faster, but these ambitious projects only serve to narrow the gap between it and other languages, while increasing complexity.

With even interpreted languages offering impressive performance today, and with more and more pieces of all web browsers being written in higher-level languages, when are we going to see layout engines written in something other than C++?

Personally I'm fine with the concept of testing in a new engine; you're right, Alex, web devs should already be testing in Chrome separately from other browsers regardless of the engine it uses. Laziness and carelessness don't help users.

What troubles me about Blink is that the more I read about it, the more I have a strong sense of, "Well, we don't like what's out there right now, so we're going to do our own thing." My concerns are largely in line with Bob's. There is value in being fast, as you say, but there's also risk.

That's underscored by the attitude Blink has towards things like vendor prefixes. I can't imagine that Chromium will always wait to release a feature until it's already out on the market; that's never been how WebKit's been run in the past, and my gut feeling is that the "Exceptions" mentioned in the new features section may appear not-so-coincidentally with the launch of a highly-publicized Chrome Experiment. We could then end up with competing implementations if another browser decides to do it differently. (Hate on vendor prefixes all you want, but at least there's no risk of this when you use them.)

It's great to be efficient and cut what you don't need. It's great to be fast. But please, please, as tempting as it is, don't try to be so fast that you leave the process of new feature standardization in the mirror in favor of doing something for the sake of being first; I really don't want to go back to the days of conditional CSS we faced with IE6.

Will this reduce the memory footprint of each chrome tab? They feel pretty memory hungry at the moment.

Hi Justin,

There are many ways to contain the risk you (rightly) sense. Good project governance is one of them, and we're committed to it in Blink. You can decide for yourself if our 4+ years in WebKit were evidence of good citizenship, but that's what the whole web feature dashboard is about and why folks like me are continuing to be paid by Google to go fight the good fight to improve standards. But there is a large aspect of "trust us" to this, and I know how risky that sounds. The good news is that there are real browser and engine alternatives to keep everyone honest.

But I think your view of the first browser war needs revising: it not only created a platform so capable that it bested the competition even in its decline, it set the stage for today's performance and UX arms race. I'm with you in wanting to do the best we can to contain the potential damage from experiments, and the Blink process is geared to take that seriously. Don't kid yourself, though competition is necessary for improvement. Without it there is no spark and no incentive.

Wishing for progress without a system of incentives that can credibly provide it is asking for perpetual motion.

I find the vitriol in these comments odd.

In my experience, the Chromium team is probably the most thoughtfully responsive team in the field right now. Bugs that I file are routinely fixed within weeks, sometimes days. If you have a good argument, a test file, and it's backed by data and standards, Chrome listens, and iterates, with incredible speed. It's extremely gratifying, and fun for a relatively newcomer like me to participate in moving the platform along. I honestly haven't had the same experience with Safari (crummy private bug tracking system, no helpful discussions) or Mozilla (too often the reply is outright condescension or "hey, go fix it yourself!", which I personally don't have the C++ chops for). I'm not a Google fanboy by any measure, but Chrome Dev Tools has won the hearts of developers worldwide because the team listens. In itself, this has nothing to do with market share.

There are large parts of the web that functionally aren't even "1.0" yet. Look at the Web Animations 1.0 Editor's Draft, just released today. Someone's going to be first up the mountain. If Chrome wants to break off to race ahead, so much the better. We're not there yet, folks.

I will say that some of the anxiety about Chrome dictating standards is reasonable. I think that's a legitimate debate to have. But then again firstcomers have always laid the tracks. That's how the web has always worked. And reality check: if you actually look at the standards formation process around SVG 2.0, for example, which is very much a work in progress at this very moment, you don't see Chrome people even remotely controlling the process. Everyone's at the table, hashing it out. Things look very bright in this area.

Cheers, Alex, for a thoughtful post, and all the work you do.

Bjorne:

C++ contains multitudes. One of the important things that can happen quickly in Blink is that we can move to begin using modern C++. Our primary build toolchains (clang, gcc 4.7, and MSVS 12) all support large sections of C++11 which will pay large dividends. Similarly, we'll be able to drop many abstractions and ifdef/#define layers that have served mostly to insulate WebKit from what can only be described as archaic build requirements. For a flavor of what can go, go give the aptly-named WTF namespace a gander. At a minimum, we'll be able to rely on Chromium's base/ versions of many of these abstractions instead, cutting the # string, number, and vector classes a new Blink engineer needs to learn to be effective in half.

As for moving to something other than C++...we can all dream, right? My personal hope is that by moving more of DOM to JS (a.k.a. "self-hosting"), we'll get a lot of those benefits. What happens with core rendering/parsing can largely change behind the scenes, but the imperatives there are all about runtime perf. We have suffered C++ thus far because it's the only thing that gets us in the ballpark on all of: compat, perf, x-platform support, and "something some people know".

Regards

Hi Bob,

I very honestly know where you're coming from. My background is webdev. I led the Dojo team for years and was the "front end guy" at many jobs before joining Google.

What you may be missing -- and it's easy to, WebKit is a big and mostly uncommented code base -- is that Chrome, Safari, and other ports have been diverging for years while still living in the same tent. This has been enabled by pervasive use of build flags that allow ports to agree to disagree about the feature set we respectively ship to the web.

Consider Chrome for Android and the old-skool Android Browser. What makes them so different? It's not WebKit revision. Nor even choice of JS engine (they both use V8). Nor even the network or remaster stacks. Indeed, the massive differences in behavior, performance, and feature availability was down to dozens of other flags. Just think how much further away safari is than even that.

What's happening here isn't that your testing burden is getting higher. It was already as high yesterday as it will be tomorrow. What is happening is that your assumptions are being turned out for frauds.

I'm sorry it's happening this way, but it will truly be better for your users if you're doing the testing you should have been doing all along.

Regards

Interesting post. Trouble is, development may now be quicker for chrome devs, but the work required by web devs on testing just went up by 33%.

Hi t.:

First, you vastly underestimate the sizes of the teams involved.

Next, as I tried to explain above in the comments, this does nothing to functionally change the testing burden webdevs face. WebKit was already fragmented in ways that meant you were screwing users if you weren't testing on a per product basis instead of assuming that "it's all good, it's webkit based".

You might also misunderstand what's going on here: we're not giving up on the WebKit codebase. Indeed, we're taking it it as our starting-point for Blink. We just hope to evolve it faster. And you're wrong on the meta-point: people expect more out of computers year over year. If the web cannot deliver that change, more closed, more proprietary systems will instead fill the gap. Don't know about you, but that seems like the definition of a regression to me.

Regards

I think your numbers still won't work to make your case. Even if there are a thousand engineers working on Chrome, it is still dwarfed by the number of web developers. A hundred-to-one or a thousand-to-one ratio isn't terribly important in this case.

Re: 'you are screwing your users if you weren't testing on a per product basis'. Unless you have money to burn, testing combinatorics is a judgement-based business- one should test a reasonable set of combinations to cover the anticipated usage. Testing too much is a waste of time. Testing too little hurts in varying degrees. It's a business decision.

Re: the metapoint of people expecting more from computers. You have the theory right, but the example is wrong. For instance, I know how to design a computer with a better instruction set than X86. But the x86 architecture is good enough for the masses. People, real live, non-geeky, human beings expect speed and [generally] the 'how it does it (the apps)' is not only not-important but is downright noisy-blah-blah-blah. Sorry, but after building O/S, middleware, frameworks for too many years-- they are now 'good enough' and apps are where it's interesting. Changing the junk underneath the app can and does create problems. Humans can;t track an infinitely tall vertical stack of technology. Commoditizing the lower parts allow us to move up the stack and concentrate a lot of this innovation (not all, but a lot) at the top--- near where regular, non-geeky, humans live.

I don't want to add another browser to my dev and testing mix. But to your point, given Chrome's popularity, I will be forced to. This will slow down MY rate of innovation (given a budget that doen't flex on maintenance). For some longer-than-I-like time, I'll be carrying the load for two versions of Chrome. And because my customer base spans a number of browsers- I'll not be doing much to special-case browser shiny features. It's a tax.

Like everyone else, I'll bet my CSS is going to bloat up some for some period of time. Gee-- can't wait.

t.:

I've already explained why #'s of devs is a distraction here. Safari and Chrome's behavior had already drifted in ways that made not testing both untenable. Arguing a moot point well makes it no less moot.

Regards

Perhaps while you're at changing things you can get Chrome's version numbers under control? It's on major version 26 now?! Been around for 26 years has it? 13 years? No? Oh, well I guess that every single *minor* release you guys ship is considered a major version. Great.

Also, Chrome is now 2.X Gb on my Mac. Is there a reason why it stores so much data?

I'm sure breaking from webkit will get right on fixing that.

Browser rendering engines are what makes the web what it is-- standards based. Forking webkit is about marginalizing Apple.

It is google taking the embrace-and-extend-and-destroy play from Microsoft's playbook.

Chrome is a dog slow browser with almost no innovation, and it's not because of webkit, as Safari is able to run circles around it. Chrome may score well in JS benchmarks, but in use it locks up, pauses for minutes at a time with a few tabs while safari keeps on rocking.

Here's a translation from BS to English:

http://prng.net/blink-faq.html

Funny, at first I thought when you were talking about cycles and directness you were pointing out how even though you may be squeezing more performance out of chrome with this new engine, us developers will have to spend more cycles testing/debugging/solving on more platforms, and have a less 'direct' path to creating things we want to create.

Instead you were thinking from the point of view of your team being able to spend less cycles, and a more direct path to advances your browser/platform.

Maybe this ends up being a good thing, but I'm still having trouble reconciling how you can immensely speed up innovation and new features, and staying true to web standards (and not breaking the web for the other browsers), which you also see as hugely important.

Thanks so much for the kind words, Alex.

This all seems very selfish to me. The main point of your argument is speedup. Got it. But speedup for the dozen or so developers on something which -might- be considered to be commoditized does not scale well up to the massive amounts of wasted energy on the part of your users (web developers and end-users). The world has not craved another fundamentally different operating system for decades. Same ought to be true for browsers. Inside it might be shiny and new, er, wait... it's written in C++? New? Outside it's the same old thing- navigation, pages, applications.

Okay, it's easier to build. Will it be open? Can other companies use it as you used WebKit?

>*The more clueful of the ink-stained clan will constrain themselves to objective reality and instead pen screeds for/against diversity despite it being a well-studied topic to which they’re not adding much.*

Some BS obscure papers on a tangent of the matter make the issue "well-studied" and closed?

Really?

Dear Alex,

This is my response to you as owner of Blink open source SIP project since 2009.

The thread is here:

https://plus.google.com/113757927151929258451/posts/NCB2kc8sehi

I find this to be confusing for a large amount of users. We developed since 2009 Blink http://icanblink.com which is an open source SIP client for Linux, Windows and Mac. With half a million downloads, Blink is well known project in the open source VoIP community.

It is unfortunate that no research was done to yield a better name for this webkit fork.

Blink is a very popular and useful opensource software for internet communications.

If this was an oversight from Google in picking a name, it should be corrected soon. Just show us that you still care and that you are good at heart.

If it was a deliberate or "i don't care" attitude from a giant company, it is a shame - another instance of going from good to evil.

The one action might soon be forgotten in press, but will remain forever with those who are affected. The choice is yours to make - be good or evil.

Will Blink use the webrtc stack for video/audio? Will this be part of Blink or something seperate that it "plugs" into?

Hey Matto:

Blink (the new fork of WebKit) is not a product, it's a project that other projects (which may be end-user products) depend on. Like WebKit, it implements parts of WebRTC and provides hooks for callbacks to browser-specific implementations of the bits it can't do itself. But nobody will ever download a "copy of blink and use it for WebRTC". Instead, they'll download a product that uses or embeds Blink but which has a different name. For example Chrome, Opera, or some other custom Chromium-based product.

So the way to think about it is that Chrome implements WebRTC via Blink. Blink itself is not a product, it's just a name for the source code repository and project.

Hope that clears it up.