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

WebKit is the jQuery of Browser Engines

ejohn.org

Post reply on HN
Print view View original

151–160 of 214 posts

Re: WebKit is the jQuery of Browser Engines

#151

Post by bzbarsky »

malandrew wrote: post #146
bzbarsky wrote: post #107

Earlier quoted context omitted.

Ah, but it does result in stagnation on many axes. Where's the Google or Apple effort to add significant intra-page parallelism to WebKit? It's too hard in that codebase, so it's not happening. If you require that codebase for a web browser, that means no significant parallelism in web browsers. (There's some work being done to parallelize the rendering pipeline, and a bit on painting, but parallel CSS layout seems t…

Since you know a lot about WebKit and parallelism, especially intra-page parallelism, I'd really like to know a lot more about the problems with it. Can you give a brief rundown of the issues and the design decisions they made (and the correct decision IYHO) and maybe some links on where I can find more info?

So a caveat: I don't feel like I know a lot about WebKit. I know a bit about WebKit. I do know a lot about Gecko. ;)

The issues that I've seen are basically endemic to every large C++ application I've seen, actually: shared memory being accessed via pointers from many different places, lazily computed values, shared global (or even just per-page in the case of intra-page parallelism) caches.

These are all reasonable things to do, so I'm hesitant to call them "incorrect", but if you want to design with parallelism in mind you have to either avoid them or carefully design around having low contention on shared resources, access to mutable shared resources protected by some sort of serialization mechanism, etc.

As a simple example, last I looked WebKit's CSS selector matching algorithm cached some state on nodes as it went (as does Gecko's). That means that as things stand you can't do selector matching on multiple nodes in parallel because you can get data races. This one instance can be worked around by deferring the setting of the cached bits until a serialization point, but you have to make sure you do this for every single algorithm that touches non-const members on nodes that you want to parallelize... And C++ doesn't really give you a good way to find all such, given "mutable" and const_cast.

Another example: When WebKit does layout-related things, it directly touches the DOM from the layout code, which is a perfectly reasonable thing to do when you think about it. But it does mean that it can't do layout in parallel with running JS that can modify the DOM. For that you need to have layout operating on an immutable snapshot of the DOM.

As far as more info.... https://github.com/mozilla/servo/wiki/Design is perhaps a start for what we think we know about how this _ought_ to work. Maybe. ;)

Re: WebKit is the jQuery of Browser Engines

#153

Post by malandrew »

bzbarsky wrote: post #151
malandrew wrote: post #146

Earlier quoted context omitted.

Since you know a lot about WebKit and parallelism, especially intra-page parallelism, I'd really like to know a lot more about the problems with it. Can you give a brief rundown of the issues and the design decisions they made (and the correct decision IYHO) and maybe some links on where I can find more info?

So a caveat: I don't feel like I know a lot about WebKit. I know a bit about WebKit. I do know a lot about Gecko. ;) The issues that I've seen are basically endemic to every large C++ application I've seen, actually: shared memory being accessed via pointers from many different places, lazily computed values, shared global (or even just per-page in the case of intra-page parallelism) caches. These are all reasonable…

So earlier I said that making another rendering engine would be a 5-7+ project. How about taking WebKit, forking it and making it highly parallelizable, piece by piece? Is that even possible, or is a big rewrite from scratch with parallelism in mind the only way to go?

Re: WebKit is the jQuery of Browser Engines

#154

Post by gcp »

dubcanada wrote: post #114

I find that funny because even if you add up everything WebKit, Gecko+IE+Opera+Others still have a higher browser share. And most of the "large parts" of the world don't even really use WebKit (I'm looking at China, India, Africa, parts of Europe etc) most of which are IE/Gecko/Opera

Mobile.

Re: WebKit is the jQuery of Browser Engines

#155

Post by oinksoft »

youngtaff wrote: post #143
ripter wrote: post #88

Earlier quoted context omitted.

I just checked Amazon, eBay, and MSN they use jQuery. The only one you listed that doesn't seem to is Wikipedia. You really should actually try the websites before you list them.

I think Wikipedia removed jQuery due to the impact it had on battery life - see Who Killed My Battery ( http://www2012.wwwconference.org/proceedings/proceedings/p41... ) for some details.

People on comp.lang.javascript (which has its problems, and I've been away for a while) have been noting this for a while. jQuery chews far more cycles than comparable libraries with its function overloading, extra $(this) invocations and such.

Re: WebKit is the jQuery of Browser Engines

#157

Post by oinksoft »

tomjen3 wrote: post #126
oinksoft wrote: post #52

Earlier quoted context omitted.

You seriously underestimate the complexity of Gmail. It may well be the most complex JavaScript application in existence with an appreciable user base.

Are you arguing that Gmail is more complicated than google docs?

You make a fair argument. Google has several state-of-the-art JS applications. I thought of Gmail in particular because it probably sees much higher demand and so matters of optimization are probably a bit more important to it. This makes the amount of network activity, client-side caching, etc. it manages really impressive.

But no doubts that Google Docs is in the same ballpark.

Re: WebKit is the jQuery of Browser Engines

#158

Post by azakai »

I disagree with much of this article.

> as a contributor to WebKit you have the complete ability to drive it in a direction you wish (often for the better)

Not really. Follow the internal WebKit politics and you see a lot of conflicts. For example, Google wanted to push multi-VM support (for Dart) and Apple blocked that.

> WebKit is already a de facto standard

On mobile. Mobile isn't everything.

Also, should we have said "ie6 is already a de factor standard and given up"?

> I think one this is clear already: WebKit has completely and unequivocally won mobile at this point. They are nearly the only rendering engine used on the vast majority of mobile browsers, including the soon-to-switch Opera Mini/Mobile browsers too. There is no reason to worry about a slippery slope, the slope has already been slid down. In order for any other browser to remain relevant in the world of mobile (which, you must admit, is quickly becoming the only world we live in) they must keep feature parity with WebKit.

Again, this is utterly defeatist. Even if it were 99% true, should everyone give up?

> At this point it’s honestly a business/engineering decision for Mozilla and Microsoft (as it always has been).

No, Mozilla is a nonprofit and the decision would also regard whether it is good for the web, or not. I'm surprised to see John Resig not realize that - he used to work at Mozilla.

edit: And regarding the main point: jQuery worked in a space that was not standards-based. There were multiple JS libraries, and they fought for market share. No one tried to develop a standard that there would be multiple implementations for. Comparing jQuery to WebKit is odd.

Re: WebKit is the jQuery of Browser Engines

#159

Post by bzbarsky »

malandrew wrote: post #153
bzbarsky wrote: post #151

Earlier quoted context omitted.

So a caveat: I don't feel like I know a lot about WebKit. I know a bit about WebKit. I do know a lot about Gecko. ;) The issues that I've seen are basically endemic to every large C++ application I've seen, actually: shared memory being accessed via pointers from many different places, lazily computed values, shared global (or even just per-page in the case of intra-page parallelism) caches. These are all reasonable…

So earlier I said that making another rendering engine would be a 5-7+ project. How about taking WebKit, forking it and making it highly parallelizable, piece by piece? Is that even possible, or is a big rewrite from scratch with parallelism in mind the only way to go?

We certainly considered that path, with both Gecko and WebKit.

In theory, that's possible, but in practice it would likely take just as long, and at the end you would have a rendering engine that was years behind the competition. Not least because intermediate stages wouldn't be upliftable back to the main codebase because partially parallelizing things leaves you with worse performance than either parallelizing nothing or everything, in many cases.

Post reply on HN