b) Although it is a little hand wavey, they do make an engineering argument: "However, Chromium uses a different multi-process architecture than other WebKit-based browsers, and supporting multiple architectures over the years has led to increasing complexity for both the WebKit and Chromium projects."
> Although it is a little hand wavey, they do make an engineering argument:
Immediately being able to eliminate and not worry about maintaining 7,000 files comprising 4.5 million LOC seems to be a pretty concrete benefit, rather than a hand-wavey one.
The engineering argument is that the differences between Chromium's multi-process model and WebKit2 are big enough that, in order for both projects to move forward, Google needs to fork WebKit. I'm not competent to judge whether this is actually true.
http://trac.webkit.org/wiki/WebKit2 outlines the technical differences between the architectures pretty well. Suffice it to say, the model runs deep, and has real impact on the way things like WebCore are put together.
Chromium uses a different multi-process architecture ... and supporting multiple architectures over the years has led to increasing complexity ... we anticipate that we’ll be able to remove 7 build systems and delete more than 7,000 files—comprising more than 4.5 million lines
Last time I measured (late 2012) the entire mozilla-central repository was 4.488 million lines of code. So I don't believe that by simply streamlining things they'll be able to remove anything like 4.5 million lines. Perhaps an extra zero got inserted somewhere.
4.5 million lines spread over 7,000 files is only ~642 lines per file, so I doubt there is an extra zero. Perhaps they included whitespace and comments in their count.
> Last time I measured (late 2012) the entire mozilla-central repository was 4.488 million lines of code.
Mozilla isn't WebKit.
> I don't believe that by simply streamlining things they'll be able to remove anything like 4.5 million lines.
I suppose you could compare WebKit repos against Blink repos once the latter is live to see exactly what is cut, but I'm going to say the people working on the code that are the source of the count know how many LOC are involved, and that there direct count is more reliable than a third-party estimate based on a different browser's repo.
I think the implication is that most of the code they are removing is not actually code, but boilerplate/machine-generated build scripts/etc. Still, the number of LOC involved has little bearing on whether or not splitting from WebKit is a good idea.
Of course the blog post doesn't go into technical detail. But if you would explore just a single link deeper you would see a pretty good explanation of the changes they're making. It's pretty obvious why they're doing it. It improves and greatly eases the amount of effort required to port/utilize Chromium/Blink not to mention the other benefits from the architecture that they indicate will enable better multithreading.
>Longer term, we can expect to see Blink evolve in a different direction from WebKit. Upson and Komoroske told us that there were all manner of ideas that may or may not pan out that Google would like to try. The company says that forking WebKit will give it the flexibility to do so.
If you look at the commits, there's a fair argument that Google "controls" WebKit. You could almost say Apple got KHTML'ed ;)
I believe this is an honest move. This is what happens with software. Goals change, old code and design no longer makes sense, you refactor or rewrite. The architecture of WebKit was created to address goals that are a decade old now. The multi-process nature of Chrome alone, an amazing achievement and really quite elegant if you've looked at the way they bolted it on, was bolted on all the same.
V8 without a doubt re-invigorated JavaScript. When V8 was announced there was a lot of "do we really need another JS engine" arguments. You could argue that other engines were getting fast as well, but v8 got people really thinking about JavaScript outside the browser. I am excited to see what new insights this new rendering engine brings -- and what unexpected positive consequences it generates.
If you want to really put a tinfoil cap on, you could say that by Google contributing to WebKit they are giving Apple a lot of free code, allowing them to devote fewer resources to their browser. Once Blink diverges father from WebKit it won't be practical for WebKit to merge in changes from there.
One has to wonder if Google will be recruiting other WebKit contributors (RIM, Intel, Nokia, etc) to move over to Blink. This would put Apple in a tough spot.
Blink remains very much open source: the repository should be visible in a minute or three.
We're going to be even more transparent than we currently are, actually, about how things get added to the platform http://www.chromium.org/blink#new-features. I'm pretty excited about how that's going to play out with regard to sharing ideas and implementations.
Of course, I wasn't claiming otherwise, but over time porting code to WebKit from Blink will become more trouble than it's worth. They can still learn from it, but you can hardly deny that this move is going to cause WebKit some pain to fill in the tremendous amount of work you guys were doing (the part about this being the reason for the move was, of course, completely a joke.
The two engines will diverge, yes. I think it'll be better for both in the long run, as we simply have fundamentally different architectural approaches to some pretty core problems the engines are meant to solve. There will be short term adjustments on both sides as we get used to the new options that are now available.
I'm honestly quite hopeful, both about Blink, and about WebKit.
If there is an engineering argument, I'm guessing it's to do with multi-threaded DOM+JS, given the mention of multi-process architecture.
Also, how much does Apple really control WebKit? At a glance, it looks to me like FOSS. (Apple might be the maintainer, but it seems trivial to fork it in a different direction.) Perhaps this is a more nebulous "thought leadership" kind of thing?
Yes. Announcing this especially today seems like a "fuck you" at Samsung.
Downvotes? Anybody thinks that two companies that are in some heat over Android/Tizen et all, just coincided to release information about new rendering engines on the same day?
As if rendering engines are announced every other day, right?
This is a conspiracy theory. PR moves take time, so both Servo and Blink announcement probably baked for many weeks. The best explanation is both PR teams thought today is a good timing, probably because it is right after Easter holidays.
Yes. And sometimes conspiracies happen. Conspiracies don't always involve aliens, illuminati or such. Sometimes they are as simple as "let's secretly aid the Contras in Nicaragua". Or "let's do our PR move at the same time to piss them off".
>PR moves take time, so both Servo and Blink announcement probably baked for many weeks.
Which makes it even more technically possible for someone to have learned of the other's date in advance, during all those weeks, and decided to announce his on the same date.
No, it just means that instead of Chrome for Android and Chrome for iOS having different versions of WebKit, Chrome for Android will use Blink and Chrome for iOS will use the system WebKit, as it does now.
So Google will be using 2 increasingly different rendering engines for Chrome in the future? Well that sucks. Apple really needs to allow other rendering engines on iOS, or at least be forced into it. People complain about the "webkit mono-culture", but a huge platform like iOS actually mandating you use webkit, and their single version of webkit, is a lot worse.
I agree, that would suck. Specially if -for some reason- we start seeing differences in terms of rendering speed/js engine/or other techs between the android version and the iOS version.
There already are speed differences in iOS alone. The native Safari has a faster JavaScript engine than the sandboxed Safari instances that iOS apps use.
Or something like that. Something about security concerns.
It's the JIT for JavaScript that's disabled. I've never seen an official statement on it but I've read that it's that the security model in iOS does not allow compiling code and then executing it, but Mobile Safari gets a unique bypass for this security. Other apps which merely embed a UIWebView are stuck with interpreted JavaScript.
They already are different: Chrome on iOS uses whatever version of WebKit UIWebView uses on the platform (which, until relatively recently, was an old fork of WebKit), whereas Chrome on Android nowadays uses a version almost as up to date as Chrome on desktop.
We're a bit worried about compatibility, certainly. One important thing to note is that WebKit has _tens of thousands_ of layout tests; all of those tests exist right now in the Blink repository, and we're certainly going to continue working with browser vendors in general and the W3C to ensure that we can agree on exactly what standards mean, and how they should be rendered.
We'll be coming at the same problems from different angles, find and fix different bugs, and have the opportunity to peek at how other browsers have done things. I'm quite hopeful that will mean that we'll all end up with better implementations.
Opera on iOS is actually Opera Mini, which doesn't run a rendering engine on the device at all.
And no, Apple does not allow other rendering engines so much. Specifically, they do not allow anything that can execute code that is not distributed with the app. So for example, no JS engine that's allowed to run scripts that don't ship with the app, period (even without a JIT).
Chrome for iOS uses a UIWebView for rendering (effectively Safari), but uses the Chromium networking layer, UI (omnibox), etc. Arguably though rendering/JS is a big part of what makes the browser the browser, but it isn't everything.
Nope, no changes for Chrome for iOS: current version already uses UIWebView and will continue to do so. The rest of the infrastructure (networking, etc), is Chrome code.
Standing ovation. This is most welcomed news since Opera's move to WebKit to keep the current browser innovation pace.
Coupled with Mozilla's announcement of its partnership with Samsung to move Servo forward this is great news for the future of the web. Hopefully multi-process/multi-threaded rendering engines will address some of our current performance gripes with the DOM and open the gate for even more complex UIs and interactions.
…And Opera is following Chrome to Blink, as new-Opera is built on the Chromium Content API (mentioned below, but seems significant enough to bear repeating).
Parallelism is listed as something they are considering, whereas with Servo it's one of the biggest (if not the main) reasons for it existing. From this announcement I can't quite tell what it is with this project that they hope to achieve but I'm sure that will become more clear over time.
I know this sounds bitter, but I read this comment and my interpretation (of the ideology, not how you said it) is:
"Our shitty slow and poorly architected mess of document and script languages is too slow for good application performance, everyone, start floundering around looking for some technology to squeeze another inch of performance out of everything so we can maybe hopefully make our awful mess work finally"
It is probably my bitterness towards XML, but I feel like the whole "use-a-document-markup-language-as-an-application-builder" is making people do crazy things, and not in a good way - it is happening because html is entrenched, and it is the only truly device-agnostic framework right now. So everyone tries to make it work for everything.
That's an interesting way of looking at it. Apple no longer get a free ride. On the other hand, now that Firefox is using WebKit perhaps Mozilla just replaces Google there.
> On the other hand, now that Firefox is using WebKit
Firefox is still using Gecko, and is working with Samsung on a long term effort to develop a new engine (Servo) in Rust.
You may be thinking of the recent news that Opera is using WebKit, but even when that was first report it was identified that they were really basing on Chromium rather than WebKit proper, and they've announced (in this thread, even) that with Chromium moving to Blink, Opera is following.
KDE originally built KHTML. WebKit however is mostly a product of Apple. They made it into the product it is today. Along with help from Google/RIM/etc. But it was mostly them since they needed it to work in Safari and iOS.
Sorry I should've been clearer. I am aware of that, but since anyone can use the code, the most important thing for those using it is that what they have tired their product to is actively maintained. If they don't do the majority of the work to maintain it then I think of them as getting a free ride from whoever is actively maintaining it. I don't mean that as a negative, either. Every company gets free rides in some way or another. Web companies off those that pioneered the web, for example.
WebKit2 is a similar, but different, multi-process model. Chromium never compiled it in, but the integration imposed various constraints both on Chromium and on WebCore. That's certainly one of the reasons we've introduced Blink.
The argument is essentially: "It took up lots of engineering time and effort to maintain compatibility with other platforms, so this allows us not to worry about other platforms and only focus on our own and that will allow us to move faster."
Hopefully this is easier for everyone. If the chrome multithreading architecture really was the pain point then does that mean that webkit will also be deleting thousands of files and become easier to build, just as the chrome team is removing compatibility for other webkit targets? Or will WebKit remain the mess it is now because it strives to work on all the other platforms?
What if Apple decided to do the same thing? WebKit is this wonderful open source success story in part because it runs in so many places on so many things, but isn't a large part of that only enabled because the main contributors took the time to make sure that their work continued to run on the various different architectures? Will Google turn away patches that enable Blink to be compatible with platforms not their own?
I think Apple has already made a similar decision. A while ago, they decided that they'd allow commits which broke the build on non-Apple platforms and that it would be up to platform maintainers to try and keep up.
Google seems on a "replace open with less open" streak, with google reader and caldav shuttering, and now this. The caldav situation especially i cannot conceive as anything but a business decision given that they're keeping it around for those people they like.
With regard to open, Chromium is a nicely open source project, and we're really quite committed to transparency in the project. See http://www.chromium.org/blink#new-features for some of our policies in this direction.
Godwin's Rule Corollary violation:
o Mentioning Google Reader in a discussion unrelated to RSS or Blogging causes automatic loss of debate/argument/credibility.
Super excited about this! There was a long discussion on the webkit mailing list after google tried to add support for multiple language VMs in webkit. The goal was to have a native Dart VM.
"Whatever it wants" within reason. We're actually quite concerned about how new features are added to the web platform, and recognize the need to be careful about what we commit to support forever. See http://www.chromium.org/blink#new-features for some detail about the process we're planning on using going forward.
Additionally: we have had experimental Dart+Chromium builds for a long time, they use a different approach (V8 bindings layer) that doesn't require WebKit changes. However we only use these builds for fast development edit+refresh, for deploying Dart code you should use dart2js (it's just like deploying CoffeeScript, C code via emscripten, etc).
Yeah, tone can be hard to guess from text. Figured the link would be helpful either way :)
disclaimer: I'm on the Dart team (libraries, not core language/VM/dart2js). As exciting as it would be to have Dart VM in Chrome, personally I hope the order is more like:
* dart2js and VM work the same way (basically true already, modulo a few quirks unlikely to affect program behavior. It's not any worse than your typical web standard polyfill, probably a lot better.)
* The language spec is standardized.
* People like Dart, and it becomes really popular for building web apps.
* We have great Dart<->JS interop and it's possible to make the two native VMs work nicely together in the same browser.
* The toolchain makes it practically impossible for a web developer to publish an app that only has .dart files, without the .js version that works on all browsers.
* At that point, it might make sense to add the Dart VM to a browser purely a performance optimization.
Of course a lot could change between now and then. For example, if JS engines keep getting faster and introduce enough fast stuff (like typed arrays, asm.js, etc), maybe we can achieve the speed we need with dart2js.
Fortunately, there are plenty of folks that work on Blink/Chromium that share both the enthusiasm and skepticism that the web community has about Dart. As someone that works on it, I deeply want our team to succeed, but I would like to see it happen in the right way--open web and open source friendly.
yeah, if you're running directly on a VM for the language (e.g. JS on a JS engine, Dart on a Dart engine) you wouldn't need source maps for debugging, unless you are using some other tool that is doing source->source transforms for you (e.g. https://github.com/dart-lang/web-ui currently does some dart->dart source transforms). You'd still have source maps for the dart2js output.
I've only read the first dozen of so entries of that thread but it's so depressing…
We've been waiting for Apple to include support for the W3C Navigation Timing for a long time so their pissing match over multi-VM support in WebKit because it doesn't conform to standards rings hollow.
A long time? The working draft is dated January this year.
The multi vm discussion was in 2011. If you think supporting dart natively in a browser is a good thing you're either a google employee or have your head too far up googles ass to see they are the new Microsoft and this is/was an attempt no different than vbscript in ie
I mean use the monopoly to take the tech, clone, tweak, and then don't contribute back. Thankfully google will keep it open source since they're making money from it quite indirectly. But still.. A "fork you" to apple that would make the web suffer. Douchy.
Isnt "take the tech, clone, tweak, and then don't contribute back" exactly the model Apple used to create webkit from khtml. If memory serves, the khtml team was incredibly unhappy with apple trying to submit giant monolithic and undocumented commits.
What Google's doing now is far kinder than what Apple did then. As noted above, Apple "contributed back" big monolithic patches. By contrast, Google is providing access to a version-controlled repository. The latter is far easier to work with, of course.
The good news is no -blink prefixes! Blink, like Mozilla, will avoid shipping vendor-prefixed features:
Historically, browsers have relied on vendor prefixes (e.g., -webkit-feature) to
ship experimental features to web developers. This approach can be harmful to
compatibility because web content comes to rely upon these vendor-prefixed
names. Going forward ... we will instead keep the (unprefixed) feature behind
the “enable experimental web platform features” flag in about:flags until the
feature is ready to be enabled by default.
Yes! Prefixes are damaging. We're hiding things behind flags instead, which gives savvy developers the chance to experiment without the risk that sites will begin to depend on those experiments.
The parent was likely referring to them being in the stylesheet at all, rather than the way they are managed. Any stylesheet compiler is still going to have the vendor prefixes in the compiled stylesheet.
Before anyone starts moaning about incompatibility, let's face it: developers start to rely on new features the moment they're added. Differentiating between different implementations is pointless, since CSS's design means you can specify a property multiple times and your browser will only use the one it understands. The current system also excluded other rendering engines who web developers didn't consider.
"Let's face it: developers start to rely on new features the moment they're added."
"So this is a huge win for us, the developers."
There's a contradiction here, and I'm not being cute. Your argument is not the only argument to be made, and personally, as a developer, I preferred the old way.
Yep, there are negative externalities, and that always has to be weighed, but I think it was a reasonable approach to allow developers to weigh the use of cutting edge features against their own communities, needs, and goals. That calculation would change depending on how many browsers were offering a proposed recommendation and the browser proportions of your viewers. Lots of interesting stuff was posted around the web, including here, taking advantage of these things. On the other hand, there's virtually no community for whom it would be reasonable to ask to make config changes to view a site, so you you simply can't use cutting edge features. Experimental site designs will be harder to show off and we'll have less public consideration of the implications of new recommendations since there's much less joy in putting together projects that few people will see.
>On the other hand, there's virtually no community for whom it would be reasonable to ask to make config changes to view a site
Actually, HN is exactly the sort of place where people might be willing to do so. Things are posted here which require specific browsers or about:flags changes in Chrome, what would change?
> On the other hand, there's virtually no community for whom it would be reasonable to ask to make config changes to view a site, so you you simply can't use cutting edge features. Experimental site designs will be harder to show off and we'll have less public consideration of the implications of new recommendations since there's much less joy in putting together projects that few people will see.
Showing off demos leveraging experimental browser features that don't happen to be CSS features has often been done with requests to make config changes, because the "put it behind a config flag until it is ready" is pretty standard for everything other than CSS (and, actually, browser vendors have also done it for plenty of experimental implementations of CSS, whether or not the features themselves are standard or vendor-prefixed experimental extensions.)
So what happens when someone introduces a new whiz bang css feature that Chrome handles badly? Something you might, as a developer, want to disable in Chrome, but leave in for everything else? Or any other browser since they're all prone to introducing flakey implementations of CSS sometimes.
All this means is we'll have to go back to the old ways of sniffing out browsers, and I fail to see how that's better.
Nor do I look forward to a deluge of websites prompting me to fiddle with a config to "get the full experience".
Most web developers have very little sway when marketing or clients demand certain things, and this is likely to be something they demand.
>So what happens when someone introduces a new whiz bang css feature that Chrome handles badly? Something you might, as a developer, want to disable in Chrome, but leave in for everything else? Or any other browser since they're all prone to introducing flakey implementations of CSS sometimes.
>All this means is we'll have to go back to the old ways of sniffing out browsers, and I fail to see how that's better.
The situation is no different just now, because -webkit- applies to Safari, Opera and many mobile browsers, not just Chrome. :/
>Nor do I look forward to a deluge of websites prompting me to fiddle with a config to "get the full experience".
Most web developers have very little sway when marketing or clients demand certain things, and this is likely to be something they demand.
"Use a modern browser [actually, Chrome] to get the full experience" is not an uncommon sight these days.
>I was being polite. I'm talking about IE specifically.
Well, this won't help you here anyway. By the sounds of things, features won't be enabled by default until they're ready. Things currently aren't unprefixed until they're ready. The only way to avoid IE if the feature is unprefixed is UA sniffing.
No change.
>Yup, and it's sucky. It's no different to "this site is optimised for Internet Explorer".
It's quite different, actually. Chrome is just quick at implementing web standards, they aren't dictating things and people aren't relying on proprietary APIs.
Hardly. Having a site that has buggy coding which has been tweaked to look good in IE's buggy rendering is a far cry from "our site uses cutting edge web-standard features that your browser does not support, please use a more up to date browser for a better experience". Night and day different.
Ugh, I remember that time, having exactly those arguments. IE having all sorts of non-standard features, so other browsers should probably copy its quirks/bugs also.
To answer your sort-of question, that time was overshadowed when it became obvious that IE6 (and later IE7) was the absolute worst choice. And that's a reputation Microsoft is still trying to clean, years later.
I do, quite well. Proprietary features are miles away from cutting edge web-standards. Being locked into only one browser that works correctly is very, very much different from being able to chose from among many modern browsers (in the typical case).
More so, as I said that particular problem was not nearly as bad as people targeting the rendering of their site to the particular quirks of one particular browser. That was horrible, but it's not even remotely the same problem we face today.
> So what happens when someone introduces a new whiz bang css feature that Chrome handles badly?
You file a bug report on the Chrome (and/or Blink) issue tracker, and it gets fixed.
> Something you might, as a developer, want to disable in Chrome, but leave in for everything else?
Then you use user-agent sniffing to disable it, if you must. The same as you'd do for any flaky implementation of a generally-used feature in a browser. That's not really the notional purpose of vendor-prefixing, anyway (which is about not using the unprefixed name space for things which might later end up with a different standard semantics, not about making it easier for developers to avoid buggy implementation of cross-browser common features).
> All this means is we'll have to go back to the old ways of sniffing out browsers
Or only use features that are well supported across common browsers if you want to avoid browser sniffing.
You had me until that. I've had legit, simple, reproducible bugs sit in browsers for years when they're on "new" features that aren't standardized, yet somehow, every other browser that implements the same feature doesn't have the bug.
Browser vendors use the "not-standardized yet" claim to avoid fixing bugs, while still shipping those features, in my experience.
Another issue with Chrome is that percentage widths are rounded or truncated to the nearest pixel, so creating three 33.3% divs won't fill 100% of the space. It makes a fluid grid difficult to create. I reported this one with the built-in bug reporter, so I don't have an issue link.
> Here's one example that's been open since Chrome 3
I'm not sure that pointing out a "known WebKit bug" (as stated in the linked issue) affecting Chrome for which the Chromium team has a patch that apparently hasn't been implemented upstream is the best example of a problem with the "post on the Chrome/Blink tracker and get the issue fixed" approach, given that that approach was offered as an approach to take to deal with issues arising after Chrome splits from WebKit specifically to stop being constrained by WebKit from making changes.
Hmm, isn't it true though, for example, that without that we'd have had to wait a long time to get simple things like border-radius that were supported in all the browsers but hidden behind vendor extensions?
Having experimental features available to developers creates pressure for all browsers to move forward. Without that we won't know what is important to developers because they'll be stuck using what the browser maker's deign to make "official".
The 'yay no vendor prefixes!' crew seem to have very short memories on what it was like before vendor prefixes..IE Waiting a LONG time (years) for a CSS feature to be 'recommended' by the w3c.
Vendor Prefixes were the best of a bad situation, I think they will be missed quite quickly.
I'm all up for this movement, but the W3C will need to move a lot quicker if this is to happen. Otherwise innovation will just grind to a halt again like it did before.
Since every developer will want it to work in Chrome, this effectively kills vendor prefixes once and for all. It doesn't make sense for Microsoft or WebKit to continue to include them.
So the user would have to enable experimental flags (which will happen approximately never) to see advanced features? And that's supposed to be good for developers? So things like -webkit-box-reflect will no longer be supported in Chrome?
That sounds far worse to me, so I can't even use the new features as they arrive.
I couldn't care less if they add -blink, it takes minutes to push that through a modern CSS codebase. At least I can use the features where they exist.
I know it might be an unpopular comment, but I really don't like this. I had hoped every browser would eventually use the webkit rendering engine. I have a hard time feeling sorry for those engineers that have to maintain compatibility, when I think of the many frontend engineers that now have to test a different rendering engine :(
Rendering engine monoculture isn't a good thing though. If a single rendering engine dominates, then there is less reason to write standards-compliant code - after all, everyone uses WebKit, right?
Yeah, it was wonderful! The alternate browsers just accepted the standards dictated by the dominant browser, and that didn't cause any problems at all!
As much as I was sad to see it go, I sympathize with their problem. If you just have a single C/C++ implementation with no spec, it's a lot harder to know, as a user/web developer, what the correct behavior is and what you can rely on.
It's a shame WebSQL died, though, since I would have loved to have had SQLite in the browser. Maybe the solution would have been to specify a similar, new, SQL database for the web? I would have liked that more than IndexedDB.
> Maybe the solution would have been to specify a similar, new, SQL database for the web?
That would certainly have been a solution, but I think one of the reasons WebSQL went with "use SQLite" as a shortcut was that it was a lot easier. If you specify a reasonably-implementable subset of SQL, you are stuck with that, and you can't piggyback on SQLite maintenance.
I think the decision to abandon WebSQL for IndexedDB rather than expand the spec into something where independent implementations were feasible was probably based on the cost/benefit perceived with having to maintain a separate, browser-specific RDBMS implementation.
I'll say from personal experience on two recent projects: if you're only testing in one webkit browser and not hitting the others there's a good chance that you're missing a couple of bugs. There are a ton of different ways to build webkit, Chrome and Safari were never identical enough to ignore. Fortunately, after developing in Chrome it took about as much effort to support Firefox as it did to support Safari, which is to say about half an hour.
A little out of left field here, but if anyone is interested in working on the other multi-process browser (for OS X at least) I've just released Stainless as open source. Stainless was a hack that actually became quite popular while we Mac users waited for Google to release Chrome for our platform. http://stainlessapp.com
From a short-term perspective, monocultures seem good for developer
productivity. From the long term perspective, however, monocultures
inevitably lead to stagnation. It is our firm belief that more options in
rendering engines will lead to more innovation and a healthier web ecosystem.
I find this a doubled-edged sword. Monocultures are said to foster a culture of laziness, apathy. This hasn't been the case with WebKit.
Don't get me wrong - competition is healthy. I'm simply thinking of how Jovinder experiences the web.
If you think WebKit hasn't fostered a culture of laziness and apathy among mobile web developers, try browsing the web using Firefox for Android or IE (on Windows Phone) sometime.
I've lost track of the number of times I've had to pretend to be something different (desktop Firefox, default Android, Mobile Safari ...) to make a website usable. Every time I have a fresh Firefox install on Android, the first extension I install is Phony.
325 comments
[ 6.5 ms ] story [ 357 ms ] threadThis blog post doesn't make an engineering based argument* so I'm left with the business ones. Which sucks.
* - Just vague "we need to innovate faster" boilerplate. Which is what business people say when there's not a solid engineering based reason.
EDIT:
At the bottom of the project page are some engineering reasons:
http://www.chromium.org/blink
Each person can judge whether it's worth forking or not.
b) Although it is a little hand wavey, they do make an engineering argument: "However, Chromium uses a different multi-process architecture than other WebKit-based browsers, and supporting multiple architectures over the years has led to increasing complexity for both the WebKit and Chromium projects."
Immediately being able to eliminate and not worry about maintaining 7,000 files comprising 4.5 million LOC seems to be a pretty concrete benefit, rather than a hand-wavey one.
The engineering argument is that the differences between Chromium's multi-process model and WebKit2 are big enough that, in order for both projects to move forward, Google needs to fork WebKit. I'm not competent to judge whether this is actually true.
1. Not affiliated with Apple or Google.
2. Not specifically associated with a port in terms of their review areas.
To me, that says a lot about how WebKit governance works in practice.
How is that not engineering based?
Mozilla isn't WebKit.
> I don't believe that by simply streamlining things they'll be able to remove anything like 4.5 million lines.
I suppose you could compare WebKit repos against Blink repos once the latter is live to see exactly what is cut, but I'm going to say the people working on the code that are the source of the count know how many LOC are involved, and that there direct count is more reliable than a third-party estimate based on a different browser's repo.
http://www.ohloh.net/p/mozilla claims that Mozilla is 11,614,049 lines of code.
Hmm. Not sure what to make of that, but the "we're removing 4.5 MLOC" claim still sounds ridiculous.
>Longer term, we can expect to see Blink evolve in a different direction from WebKit. Upson and Komoroske told us that there were all manner of ideas that may or may not pan out that Google would like to try. The company says that forking WebKit will give it the flexibility to do so.
http://arstechnica.com/information-technology/2013/04/google...
I believe this is an honest move. This is what happens with software. Goals change, old code and design no longer makes sense, you refactor or rewrite. The architecture of WebKit was created to address goals that are a decade old now. The multi-process nature of Chrome alone, an amazing achievement and really quite elegant if you've looked at the way they bolted it on, was bolted on all the same.
V8 without a doubt re-invigorated JavaScript. When V8 was announced there was a lot of "do we really need another JS engine" arguments. You could argue that other engines were getting fast as well, but v8 got people really thinking about JavaScript outside the browser. I am excited to see what new insights this new rendering engine brings -- and what unexpected positive consequences it generates.
One has to wonder if Google will be recruiting other WebKit contributors (RIM, Intel, Nokia, etc) to move over to Blink. This would put Apple in a tough spot.
We're going to be even more transparent than we currently are, actually, about how things get added to the platform http://www.chromium.org/blink#new-features. I'm pretty excited about how that's going to play out with regard to sharing ideas and implementations.
I'm honestly quite hopeful, both about Blink, and about WebKit.
Also, how much does Apple really control WebKit? At a glance, it looks to me like FOSS. (Apple might be the maintainer, but it seems trivial to fork it in a different direction.) Perhaps this is a more nebulous "thought leadership" kind of thing?
Downvotes? Anybody thinks that two companies that are in some heat over Android/Tizen et all, just coincided to release information about new rendering engines on the same day?
As if rendering engines are announced every other day, right?
And in terms of Servo, Blink makes Servo more likely to succeed, not less, by breaking open the (mobile) WebKit monoculture.
The only requirement for "stealing thunder" is for one party to know in advance the scheduled date for the other party.
Yes. And sometimes conspiracies happen. Conspiracies don't always involve aliens, illuminati or such. Sometimes they are as simple as "let's secretly aid the Contras in Nicaragua". Or "let's do our PR move at the same time to piss them off".
>PR moves take time, so both Servo and Blink announcement probably baked for many weeks.
Which makes it even more technically possible for someone to have learned of the other's date in advance, during all those weeks, and decided to announce his on the same date.
It was this reason that Adobe could never launch a flash enabled browser on iOS.
Or something like that. Something about security concerns.
We'll be coming at the same problems from different angles, find and fix different bugs, and have the opportunity to peek at how other browsers have done things. I'm quite hopeful that will mean that we'll all end up with better implementations.
And no, Apple does not allow other rendering engines so much. Specifically, they do not allow anything that can execute code that is not distributed with the app. So for example, no JS engine that's allowed to run scripts that don't ship with the app, period (even without a JIT).
That said they may just go with WebKit for iOS + Blink for everything else. Should make testing fun for everyone.
Coupled with Mozilla's announcement of its partnership with Samsung to move Servo forward this is great news for the future of the web. Hopefully multi-process/multi-threaded rendering engines will address some of our current performance gripes with the DOM and open the gate for even more complex UIs and interactions.
"Our shitty slow and poorly architected mess of document and script languages is too slow for good application performance, everyone, start floundering around looking for some technology to squeeze another inch of performance out of everything so we can maybe hopefully make our awful mess work finally"
It is probably my bitterness towards XML, but I feel like the whole "use-a-document-markup-language-as-an-application-builder" is making people do crazy things, and not in a good way - it is happening because html is entrenched, and it is the only truly device-agnostic framework right now. So everyone tries to make it work for everything.
I just see it as a sad circumstance is all.
Firefox is still using Gecko, and is working with Samsung on a long term effort to develop a new engine (Servo) in Rust.
You may be thinking of the recent news that Opera is using WebKit, but even when that was first report it was identified that they were really basing on Chromium rather than WebKit proper, and they've announced (in this thread, even) that with Chromium moving to Blink, Opera is following.
Hopefully this is easier for everyone. If the chrome multithreading architecture really was the pain point then does that mean that webkit will also be deleting thousands of files and become easier to build, just as the chrome team is removing compatibility for other webkit targets? Or will WebKit remain the mess it is now because it strives to work on all the other platforms?
What if Apple decided to do the same thing? WebKit is this wonderful open source success story in part because it runs in so many places on so many things, but isn't a large part of that only enabled because the main contributors took the time to make sure that their work continued to run on the various different architectures? Will Google turn away patches that enable Blink to be compatible with platforms not their own?
This is an interesting move.
Also: https://code.google.com/p/chromium/
https://lists.webkit.org/pipermail/webkit-dev/2011-December/...
If I remember correctly, the patch was not merged in. I guess now google can do whatever it wants!
Additionally: we have had experimental Dart+Chromium builds for a long time, they use a different approach (V8 bindings layer) that doesn't require WebKit changes. However we only use these builds for fast development edit+refresh, for deploying Dart code you should use dart2js (it's just like deploying CoffeeScript, C code via emscripten, etc).
disclaimer: I'm on the Dart team (libraries, not core language/VM/dart2js). As exciting as it would be to have Dart VM in Chrome, personally I hope the order is more like:
* dart2js and VM work the same way (basically true already, modulo a few quirks unlikely to affect program behavior. It's not any worse than your typical web standard polyfill, probably a lot better.)
* The language spec is standardized.
* People like Dart, and it becomes really popular for building web apps.
* We have great Dart<->JS interop and it's possible to make the two native VMs work nicely together in the same browser.
* The toolchain makes it practically impossible for a web developer to publish an app that only has .dart files, without the .js version that works on all browsers.
* At that point, it might make sense to add the Dart VM to a browser purely a performance optimization.
Of course a lot could change between now and then. For example, if JS engines keep getting faster and introduce enough fast stuff (like typed arrays, asm.js, etc), maybe we can achieve the speed we need with dart2js.
Fortunately, there are plenty of folks that work on Blink/Chromium that share both the enthusiasm and skepticism that the web community has about Dart. As someone that works on it, I deeply want our team to succeed, but I would like to see it happen in the right way--open web and open source friendly.
Sorry if this is a naive question!
Edit: just found the answer here, if anyone is interested : https://news.ycombinator.com/item?id=5489111
We've been waiting for Apple to include support for the W3C Navigation Timing for a long time so their pissing match over multi-VM support in WebKit because it doesn't conform to standards rings hollow.
The multi vm discussion was in 2011. If you think supporting dart natively in a browser is a good thing you're either a google employee or have your head too far up googles ass to see they are the new Microsoft and this is/was an attempt no different than vbscript in ie
In what market relevant to this issue does Google have a monopoly?
> to take the tech, clone, tweak, and then don't contribute back.
Its all open source, so it is contributed back. Google just isn't constrained to not change things that WebKit users rely on in future Blink work.
> A "fork you" to apple that would make the web suffer.
WebKit and Chromium both being more free to try different solutions isn't going to make the web suffer, its going to make the web better.
Before anyone starts moaning about incompatibility, let's face it: developers start to rely on new features the moment they're added. Differentiating between different implementations is pointless, since CSS's design means you can specify a property multiple times and your browser will only use the one it understands. The current system also excluded other rendering engines who web developers didn't consider.
So this is a huge win for us, the developers.
"So this is a huge win for us, the developers."
There's a contradiction here, and I'm not being cute. Your argument is not the only argument to be made, and personally, as a developer, I preferred the old way.
Yep, there are negative externalities, and that always has to be weighed, but I think it was a reasonable approach to allow developers to weigh the use of cutting edge features against their own communities, needs, and goals. That calculation would change depending on how many browsers were offering a proposed recommendation and the browser proportions of your viewers. Lots of interesting stuff was posted around the web, including here, taking advantage of these things. On the other hand, there's virtually no community for whom it would be reasonable to ask to make config changes to view a site, so you you simply can't use cutting edge features. Experimental site designs will be harder to show off and we'll have less public consideration of the implications of new recommendations since there's much less joy in putting together projects that few people will see.
Actually, HN is exactly the sort of place where people might be willing to do so. Things are posted here which require specific browsers or about:flags changes in Chrome, what would change?
Showing off demos leveraging experimental browser features that don't happen to be CSS features has often been done with requests to make config changes, because the "put it behind a config flag until it is ready" is pretty standard for everything other than CSS (and, actually, browser vendors have also done it for plenty of experimental implementations of CSS, whether or not the features themselves are standard or vendor-prefixed experimental extensions.)
All this means is we'll have to go back to the old ways of sniffing out browsers, and I fail to see how that's better.
Nor do I look forward to a deluge of websites prompting me to fiddle with a config to "get the full experience".
Most web developers have very little sway when marketing or clients demand certain things, and this is likely to be something they demand.
>All this means is we'll have to go back to the old ways of sniffing out browsers, and I fail to see how that's better.
The situation is no different just now, because -webkit- applies to Safari, Opera and many mobile browsers, not just Chrome. :/
>Nor do I look forward to a deluge of websites prompting me to fiddle with a config to "get the full experience". Most web developers have very little sway when marketing or clients demand certain things, and this is likely to be something they demand.
"Use a modern browser [actually, Chrome] to get the full experience" is not an uncommon sight these days.
>"Use a modern browser [actually, Chrome] to get the full experience" is not an uncommon sight these days.
Yup, and it's sucky. It's no different to "this site is optimised for Internet Explorer".
Well, this won't help you here anyway. By the sounds of things, features won't be enabled by default until they're ready. Things currently aren't unprefixed until they're ready. The only way to avoid IE if the feature is unprefixed is UA sniffing.
No change.
>Yup, and it's sucky. It's no different to "this site is optimised for Internet Explorer".
It's quite different, actually. Chrome is just quick at implementing web standards, they aren't dictating things and people aren't relying on proprietary APIs.
To answer your sort-of question, that time was overshadowed when it became obvious that IE6 (and later IE7) was the absolute worst choice. And that's a reputation Microsoft is still trying to clean, years later.
More so, as I said that particular problem was not nearly as bad as people targeting the rendering of their site to the particular quirks of one particular browser. That was horrible, but it's not even remotely the same problem we face today.
You file a bug report on the Chrome (and/or Blink) issue tracker, and it gets fixed.
> Something you might, as a developer, want to disable in Chrome, but leave in for everything else?
Then you use user-agent sniffing to disable it, if you must. The same as you'd do for any flaky implementation of a generally-used feature in a browser. That's not really the notional purpose of vendor-prefixing, anyway (which is about not using the unprefixed name space for things which might later end up with a different standard semantics, not about making it easier for developers to avoid buggy implementation of cross-browser common features).
> All this means is we'll have to go back to the old ways of sniffing out browsers
Or only use features that are well supported across common browsers if you want to avoid browser sniffing.
You had me until that. I've had legit, simple, reproducible bugs sit in browsers for years when they're on "new" features that aren't standardized, yet somehow, every other browser that implements the same feature doesn't have the bug.
Browser vendors use the "not-standardized yet" claim to avoid fixing bugs, while still shipping those features, in my experience.
Another issue with Chrome is that percentage widths are rounded or truncated to the nearest pixel, so creating three 33.3% divs won't fill 100% of the space. It makes a fluid grid difficult to create. I reported this one with the built-in bug reporter, so I don't have an issue link.
I'm not sure that pointing out a "known WebKit bug" (as stated in the linked issue) affecting Chrome for which the Chromium team has a patch that apparently hasn't been implemented upstream is the best example of a problem with the "post on the Chrome/Blink tracker and get the issue fixed" approach, given that that approach was offered as an approach to take to deal with issues arising after Chrome splits from WebKit specifically to stop being constrained by WebKit from making changes.
Having experimental features available to developers creates pressure for all browsers to move forward. Without that we won't know what is important to developers because they'll be stuck using what the browser maker's deign to make "official".
Just playing devil's advocate here ...
The 'yay no vendor prefixes!' crew seem to have very short memories on what it was like before vendor prefixes..IE Waiting a LONG time (years) for a CSS feature to be 'recommended' by the w3c.
Vendor Prefixes were the best of a bad situation, I think they will be missed quite quickly.
I'm all up for this movement, but the W3C will need to move a lot quicker if this is to happen. Otherwise innovation will just grind to a halt again like it did before.
I couldn't care less if they add -blink, it takes minutes to push that through a modern CSS codebase. At least I can use the features where they exist.
or can someone explain to me the difference?
/s
As much as I was sad to see it go, I sympathize with their problem. If you just have a single C/C++ implementation with no spec, it's a lot harder to know, as a user/web developer, what the correct behavior is and what you can rely on.
It's a shame WebSQL died, though, since I would have loved to have had SQLite in the browser. Maybe the solution would have been to specify a similar, new, SQL database for the web? I would have liked that more than IndexedDB.
That would certainly have been a solution, but I think one of the reasons WebSQL went with "use SQLite" as a shortcut was that it was a lot easier. If you specify a reasonably-implementable subset of SQL, you are stuck with that, and you can't piggyback on SQLite maintenance.
I think the decision to abandon WebSQL for IndexedDB rather than expand the spec into something where independent implementations were feasible was probably based on the cost/benefit perceived with having to maintain a separate, browser-specific RDBMS implementation.
WebKit is not a standard. Writing WebKit code, isn't the same as writing standards-based code. We lived through the ie days, why go back to those?
So we'll have Trident in IE, Gecko in Firefox (OS), WebKit in (Mobile) Safari and Blink in Chrome/ium and Opera.
Maybe, someday. Servo is a long-term, high-risk effort.
I've lost track of the number of times I've had to pretend to be something different (desktop Firefox, default Android, Mobile Safari ...) to make a website usable. Every time I have a fresh Firefox install on Android, the first extension I install is Phony.
They were probably carrying webkit in their own shoulders anyway, cause nobody does so much experiments as chromium team does..
If they have the energy to do it.. thats good news for us :)
Do you have a source for this?