Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Blink: A rendering engine for the Chromium project

blog.chromium.org

Post reply on HN
Print view View original

151–160 of 326 posts

Re: Blink: A rendering engine for the Chromium project

#151

Post by coldtea »

macrael wrote: post #138
tolmasky wrote: post #124

Earlier quoted context omitted.

Maybe because anyone who has used Safari knows that WebKit2's multiprocess architecture is worse in practice. As a full-time Safari user I can tell you that things have gotten markedly worse since it went multiprocess. Pages go white momentarily (not crash) all the time, and on top of that they also crash all the time. Additionally, I believe that unlike Chrome, Safari has ONE separate process for all the tabs, and t…

Wikipedia says WebKit2 has been part of Safari since Safari 5.1 which I believe was released with Lion, or so. So it absolutely is in production. The major difference here being that WebKit2 is part of the webkit project, so as the rendering engine (which sits atop both webkit1 and webkit2) is improved by all the various parties involved in WebKit's development, it gets better for everyone. Google's fork now means th…

>The major difference here being that WebKit2 is part of the webkit project, so as the rendering engine (which sits atop both webkit1 and webkit2) is improved by all the various parties involved in WebKit's development, it gets better for everyone.

That's in theory. In practice nobody bothered besides Apple.

Re: Blink: A rendering engine for the Chromium project

#152

Post by kbenson »

tolmasky wrote: post #139
kevincennis wrote: post #133

Earlier quoted context omitted.

Sincerely curious: why are you still a full-time Safari user in light of all those complaints?

Like most things, habit probably. Also, I used to work a lot on Safari/WebKit, so I guess sentimental value? That being said, I do like the way Safari "feels" a lot more than Chrome. I think Chrome is actually quite ugly, and bad from a UI perspective. For example, Safari's overflow tab menu is a much nicer solution than Chrome's insistence on shrinking tabs ever smaller until you can't tell them apart at all. Additi…

Just in that specific, or also zoom in general? Chrome has had zoom for as long as I can remember, and that's years.

Double click to zoom seems like something that shouldn't be too hard to do in an extension.

Re: Blink: A rendering engine for the Chromium project

#154

Post by jmesserly »

nickporter wrote: post #83
jmesserly wrote: post #55

Earlier quoted context omitted.

This is addressed in the FAQ: http://www.chromium.org/blink/developer-faq#TOC-Is-this-just... http://www.chromium.org/blink#new-features 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'…

Right, I wasn't saying this in a negative way :). That is quite interesting!

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

Re: Blink: A rendering engine for the Chromium project

#156

Post by dragonwriter »

TazeTSchnitzel wrote: post #91
jmesserly wrote: post #86

Earlier quoted context omitted.

Yeah. It would be the same problem that WebSQL had: http://www.w3.org/TR/webdatabase/ 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.

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

Re: Blink: A rendering engine for the Chromium project

#157

Post by erichocean »

dragonwriter wrote: post #113
tomelders wrote: post #104

Earlier quoted context omitted.

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…

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

and it gets fixed

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.

Re: Blink: A rendering engine for the Chromium project

#158

Post by dragonwriter »

jfoster wrote: post #119
account_taken wrote: post #24

Competition is good. Nobody wants to be left behind by Google, so time for Apple and MS to step it up again.

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.

Re: Blink: A rendering engine for the Chromium project

#159

Post by dragonwriter »

macrael wrote: post #138
tolmasky wrote: post #124

Earlier quoted context omitted.

Maybe because anyone who has used Safari knows that WebKit2's multiprocess architecture is worse in practice. As a full-time Safari user I can tell you that things have gotten markedly worse since it went multiprocess. Pages go white momentarily (not crash) all the time, and on top of that they also crash all the time. Additionally, I believe that unlike Chrome, Safari has ONE separate process for all the tabs, and t…

Wikipedia says WebKit2 has been part of Safari since Safari 5.1 which I believe was released with Lion, or so. So it absolutely is in production. The major difference here being that WebKit2 is part of the webkit project, so as the rendering engine (which sits atop both webkit1 and webkit2) is improved by all the various parties involved in WebKit's development, it gets better for everyone. Google's fork now means th…

> The major difference here being that WebKit2 is part of the webkit project, so as the rendering engine (which sits atop both webkit1 and webkit2) is improved by all the various parties involved in WebKit's development, it gets better for everyone. Google's fork now means that changes to the rendering engine they make to Blink will no longer have any effect on the WebKit project, which does seem to be a major difference.

It also means that the work they do on the rendering engine for Blink won't be constrained by the constraints imposed by support the various WebKit implementations.

Re: Blink: A rendering engine for the Chromium project

#160

Post by tolmasky »

kbenson wrote: post #152
tolmasky wrote: post #139

Earlier quoted context omitted.

Like most things, habit probably. Also, I used to work a lot on Safari/WebKit, so I guess sentimental value? That being said, I do like the way Safari "feels" a lot more than Chrome. I think Chrome is actually quite ugly, and bad from a UI perspective. For example, Safari's overflow tab menu is a much nicer solution than Chrome's insistence on shrinking tabs ever smaller until you can't tell them apart at all. Additi…

Just in that specific, or also zoom in general? Chrome has had zoom for as long as I can remember, and that's years. Double click to zoom seems like something that shouldn't be too hard to do in an extension.

I meant "smooth zoom" I guess? I can pinch in from anywhere on the page and center in on any particular item at any particular zoom level. Unless I've missed something, Chrome seems to have "integral" stepwise zooming, which also always zooms from the center of the page (vs where my mouse cursor is). It ends up feeling like Safari's old zoom which would just make the individual items bigger (as opposed to actually scaling the page), but I'm pretty sure Chrome is indeed scaling the page, just doing it in a way that I find frustrating and less useful.

Another example, I'm watching an embedded YouTube video which thus annoyingly doesn't allow fullscreen, so I double tap it, and it fills the browser window, and it seems to be smart enough to render at correct resolution at that scale (since it still allows you to choose a higher resolution even though it won't full screen).

To do similar feats with Chrome I have to manually jigger things around.

Post reply on HN