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

111–120 of 214 posts

Re: WebKit is the jQuery of Browser Engines

#111

Post by bsimpson »

ZeroGravitas wrote: post #28
jeresig wrote: post #9

Earlier quoted context omitted.

Pretty much! People worry that the transition to a WebKit monoculture would result in some terrible things. On the contrary Chrome has shown that a shared rendering engine does not result in stagnation. Stagnation is a separate concern from a shared core.

On desktop the only browsers that use Webkit are Chrome (about 1/3 of the market), Safari (about 1/10) and now Opera (currently unreleased). So roughly two thirds of the market are on non-webkit engines which I think contradicts your argument as there's still competition there. However, on mobile (a market which Chrome has only just entered) you could say that webkit is dominant and that we can already see problems t…

iOS browsers have to use WebCore for rendering/JS, but WebKit has always been optional but default on Android, WebOS, Bada, etc.

Once you consider that mobile != iOS, it seems silly to say Mobile Safari is the ridiculously dominant platform.

Re: WebKit is the jQuery of Browser Engines

#112

Post by bzbarsky »

tericho wrote: post #29
mmatants wrote: post #14

Earlier quoted context omitted.

The cool part about jQuery is that I don't have to use it . Same with Bootstrap. So it's not a needless tyranny. With browser engines things get a little more political - mono-culture is not a good thing. But at least Firefox holds enough of a market share, and of course IE is now a much better player in this space - so WebKit can't get away with too much silliness.

I think you're missing the point. Firefox & IE are browsers, WebKit is a browser engine, market share has nothing to do with WebKit. Chrome gained market share because instead of reinventing the browser engine, they improved on it and re-branded it. John's point seems to be that IE & Mozilla using WebKit wouldn't result in a mono-culture because they could still produce their own features and not worry about reinvent…

That assumes that the WebKit engine is already as good as we'll need it to be or can be improved as needed in arbitrary ways.

But it's not, and it can't be.

Think about how something like the Servo project would happen (or not) in a WebKit monoculture world.

Re: WebKit is the jQuery of Browser Engines

#113

Post by Me1000 »

kenjackson wrote: post #71

The web is not open and becoming increasingly less so. People love to talk about how the web is about open standards and such, but it really is rather quite closed. It's driven less by standards and more by de-facto implementations. Soon we can get rid of the standards committee and just talk to the implementers of webkit to define the "standard". And I think even worse has been the wholesale discounting of plugins.…

Lets step back from the "open" buzzword and look at the empirical facts.

Less than a decade ago you made sure your web sites ran well in Internet Explorer, a closed source browser that was allowed to stagnate. IE took the W3Cs standards as more like "guidelines" and not a specification.

- Today, every major web browser (except IE) uses an open source rendering engine (or the browser itself is open source.

- Every major web framework and library is open source.

- Most of the servers running the web are powered by an open source OS.

- The standards bodies are actually working faster than ever on new version of Ecmascript and HTML.

- IE's marketshare is smaller than ever.

Years ago some guys had a crazy idea to make a browser for KDE. Today it's powering much of the desktop web and almost ALL of the mobile web. Perhaps I just like a good love story, but it seems like this is a pretty great achievement for "open". Now, it seems pretty disingenuous to say "the web is not open" and even more so to say that just because more people are working on the same open source project that it's, "becoming increasingly less [open]."

[edited for formatting]

Re: WebKit is the jQuery of Browser Engines

#114

Post by dubcanada »

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

Re: WebKit is the jQuery of Browser Engines

#115

Post by malandrew »

bzbarsky wrote: post #96
pkulak wrote: post #85

Earlier quoted context omitted.

And that's bad why? So the web only works with one rendering engine. One rendering engine that's open source and can be used and modified by anyone for any purpose. Standards are great for things like protocols (even languages), but an entire web browser is a tad more complicated than TCP or even C++. No two browsers have ever implemented HTML/JS/CSS perfectly and they never will. If that's the case, then what's the…

One rendering engine that has some serious limitations, like not being very parallelizable, because of highly entrenched implementation choices. Which means that if you want hardware capable of rendering the web it can't be low-power highly-parallel hardware; it has to be high-power-consumption fast-serial-operation hardware. Why is that bad? I guess that's a matter of perspective. I think that would be a terrible ou…

You know that you can always start an open source project that fixes these parallelization issues and start building out an engine that is better, right? It'd probably be a 5-7+ year project, but it certainly is doable.

In fact, it's possible that the poor parallelization support will be the Achilles' tendon of WebKit on a long-enough time scale.

This is no different than the Achille's tendon of the DOM that is procedural-style immediate mode graphics instead of retain-mode graphics. Browser apps will never compete with iOS apps in terms of user experience until this procedural approach is replaced with a declarative functional reactive approach.

Think long term. The Windows hegemony eventually buckled under its own weight. There's no reason to think that WebKit won't eventually do the same on a long enough time scale. Figure out what will lead to its collapse because that is an opportunity. In fact, letting WebKit lead the way allows you to learn all the ways in which WebKit does it wrong. WebKit will continue to trail blaze on the interface, but doesn't have to be the end all be all of implementations for those interfaces.

Between Tizen and B2G, there is plenty of innovation in the web browser space. I just hope that transclusion is always considered a first world citizen in this brave new world.

Re: WebKit is the jQuery of Browser Engines

#116

Post by Achshar »

gcp wrote: post #8
fideloper wrote: post #3

Not to derail the topic, but did anyone else read that headline as a negative, only to find that it wasn't (necessarily)?

Maybe it depends on what your view of jQuery is: In the case of JavaScript libraries virtually everyone has standardized upon jQuery at this point. In other words, as far as he cares things other than jQuery don't have a right of existence. Although it's very popular it's probably even more arguable if there aren't better JavaScript frameworks than jQuery, compared to whether there are better rendering engines than W…

I actually don't like jQuery at all and I read the headline in negative, so your theory holds true, atleast to me.

Re: WebKit is the jQuery of Browser Engines

#117

Post by beatgammit »

snowwrestler wrote: post #61
cs702 wrote: post #4

WebKit and jQuery -- and Bootstrap -- are becoming the new 'Win32 API.'

WebKit, yes - because all websites must comply with it if they want to succeed. jQuery and Bootstrap, no. They are useful libraries, but developers can choose not to use them and still succeed. Few of the biggest websites use them, for instance--they mostly write their own javascript and templates. But they all test against WebKit.

True. I don't work at a large company, and we definitely don't have a huge install base, but we develop several large JS apps, none of which use jQuery.

Only our smaller, cobbled together pages use jQuery. If it grows, we switch to something that meets our idiomatic style better: smaller modules in a CommonJS/AMD style.

JQuery takes over your code, and it seems like WebKit is doing the same thing. Some of our developers only include -webkit prefixes until I complain loud enough for them to throw in the rest: -moz, -o-, -ms.

I hope FF never switches, because then we'd be even more locked in.

Re: WebKit is the jQuery of Browser Engines

#118

Post by Arelius »

bzbarsky wrote: post #103
hemancuso wrote: post #27

In the past there was some amount of competitive advantage in owning the rendering/browser engine. You could add unique features, fix things your competitors wouldn't, whatever. These days performance is heavily driven by the javascript runtime. While it's challenging to write a browser engine, it is much much more challenging to write a really fast JIT'ing javascript runtime. It seems unlikely Opera would have been…

Actually, writing a fast and compatible browser engine is a much larger project (at least an order of magnitude larger) than writing a fast JS JIT. Just for scale, the latter takes about 2-3 years as recent history has shown, with a team that numbers a few dozen people at most. The former takes hundreds of developers, and several more years...

While it may be true, we haven't actually seen a new layout engine written, so it's pretty difficult to estimate how long it'd take. Webkit was mostly functional as KHTML many years and tens to hundreds of developers ago.

Re: WebKit is the jQuery of Browser Engines

#119

Post by bzbarsky »

malandrew wrote: post #115
bzbarsky wrote: post #96

Earlier quoted context omitted.

One rendering engine that has some serious limitations, like not being very parallelizable, because of highly entrenched implementation choices. Which means that if you want hardware capable of rendering the web it can't be low-power highly-parallel hardware; it has to be high-power-consumption fast-serial-operation hardware. Why is that bad? I guess that's a matter of perspective. I think that would be a terrible ou…

You know that you can always start an open source project that fixes these parallelization issues and start building out an engine that is better, right? It'd probably be a 5-7+ year project, but it certainly is doable. In fact, it's possible that the poor parallelization support will be the Achilles' tendon of WebKit on a long-enough time scale. This is no different than the Achille's tendon of the DOM that is proce…

> you can always start an open source project that fixes these parallelization issues and start building out an engine that is better

Sure. We (Mozilla) are doing that right now.

> It'd probably be a 5-7+ year project

If there is no WebKit monoculture. If there is, such that the project has to duplicate WebKit bugs after reverse-engineering them, then it's a lot longer, if possible at all (because some of the bugs are parallelism bottlenecks).

Which is precisely my point. A WebKit monoculture would make it less possible to start such an open source project.

> Think long term.

You mean the one in which we're all dead?

Even if a hypothetical WebKit monoculture "merely" delays the advent of more-parallel rendering engines by 20 years, as opposed to preventing it altogether, that's still a huge loss in my book.

Re: WebKit is the jQuery of Browser Engines

#120

Post by KaoruAoiShiho »

cs702 wrote: post #4

WebKit and jQuery -- and Bootstrap -- are becoming the new 'Win32 API.'

WebKit and jQuery are good. Bootstrap is a fundamentally poor product, and I don't mean the concept of there being a standard framework that people can build upon, I mean the execution of Bootstrap itself.

So I freaking hope not.

Post reply on HN