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

171–180 of 214 posts

Re: WebKit is the jQuery of Browser Engines

#171

Post by steveklabnik »

ChuckMcM wrote: post #139
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.…

This comment captures a lot, perhaps not in the way Ken intended, but I feel compelled to respond. Lets start with the thesis statement, "The web is not open and becoming increasingly less so." On its face, this statement is not only false, it is painfully so. Sort of like saying the world is not round and becoming increasingly less so. To pretty much anyone they would say "the world is clearly round, and its impossi…

You could argue that the IETF has become everything the ISO working groups used to be, and that 'rough consensus and running code' is long gone.

I seem to flip flop back and forth on this, personally. Some days the standards process seems bright and cheery, at other times, I fear Apple/Google/Microsoft are running the show.

Re: WebKit is the jQuery of Browser Engines

#172

Post by zobzu »

DigitalJack wrote: post #109
MatthewPhillips wrote: post #93

Earlier quoted context omitted.

There are dozens if not hundreds of kernels in development today. Some developed as small niche side projects. Some in proprietary embedded products. Some purely as research experiments. I do not see that type of diversity in browser engines and I think it is absolutely as important.

Diversity for the sake of diversity isn't going to get anywhere. That is basically gambling that something good will fall out of a different implementation just because it is different. Instead, focus on solving problems. If the best way to solve a problem is to use webkit, then why do otherwise? If the best way is to go back and fork webkit from 2 years ago, and start your project from there, do that instead. But do…

difference ensure competition and variety of point of views. The problem with monoculture is that it _enforces_ the lack of difference. So if the guys in control of the monoculture stop progressing, or progress in a direction that you do not agree with, you're basically fucked and it takes enormous effort and time to change it.

It happens so many times and with so many things (not even software related) that I'm amazed it's not the first thing that comes to mind.

Re: WebKit is the jQuery of Browser Engines

#173

Post by dasil003 »

stormbrew wrote: post #66
dasil003 wrote: post #33

Earlier quoted context omitted.

Theoretically yes, mono-culture is not a good thing. Having more from-scratch rendering engines would be good for the robustness of web standards. However web standards are hugely complex at this point and it becomes increasingly infeasible to implement from scratch. With WebKit at least you have an open-source pluggable engine, so you're not talking about branded product monopolies where one or two bad actors can fo…

This has always struck me as a really poor argument. For one thing, because webkit itself is by far the youngest rendering engine around and also among the most complete. You can't reasonably argue both for a webkit monoculture and an unreasonably high barrier to entry. Gecko was an open source ostensibly pluggable engine (even MSIE is pluggable, in fact), so why did we need webkit to bring about the monoculture? Wou…

What do you think exactly is my argument? I'm just talking about the way things are, not some ideal that I'm holding up. Also, your commentary has major holes in it:

> webkit itself is by far the youngest rendering engine around and also among the most complete

WebKit was formally released by Apple almost 8 years ago after being in development secretly for at least a couple years before that. That encompasses the entire era of the modern mobile web. It was based on KHTML which I believe was released in the late 90s, in an era when CSS was barely off the ground and not used in any meaningful capacity by web designers of the time. That's the same era when Gecko was first developed and released as a clean break from the previous Netscape rendering engine which was deemed a dead-end from an engineering standpoint. So no, WebKit is not new.

> Gecko was an open source ostensibly pluggable engine (even MSIE is pluggable, in fact), so why did we need webkit to bring about the monoculture?

I don't know, but neither Gecko nor IE was ever meaningfully used as a pluggable engine in a major consumer product outside of the original organization's control. I don't know if there were technical reasons why they were never embraced on a wider basis, but they weren't, therefore they are not very informative on the question of what happens with an open-source rendering engine monoculture when multiple large parties and user bases are relying on it.

> *Should Google and/or Apple fall behind who's going to take up the cause of moving things forward again? People don't use webkit, they use Chrome and Safari.

This sentence is hard to argue because it's a non-sequitur. First of all, anyone can take up the torch any time. The only time this hasn't happened in the history of the web was when Microsoft has a monopoly and their core interests were being eroded by the web. Unlike IE, WebKit is LGPL, so anyone is free to start innovating from the current state of the art. As to the second point that people use Chrome and Safari, that's not entirely true. On Android for instance the default browser is not Chrome. Also, WebKit is being embedded in all kinds of devices. But beyond that, does the fact that people use Chrome and Safari give Google/Apple to the power to hold innovation hostage? First, they are competitors, but even if they colluded, it would be very hard for them to hold off the whole market if everyone else's web browsers were getting better and better. This is not the Windows-monopoly-plus-unsavvy-consumer market of the early 2000s. Everyone is used to computers now and in the web era they won't be corralled into an inferior platform by sheer business inertia.

Re: WebKit is the jQuery of Browser Engines

#174

Post by [deleted] »

gcp wrote: post #154
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.

[deleted]

Re: WebKit is the jQuery of Browser Engines

#175

Post by ChuckMcM »

steveklabnik wrote: post #171
ChuckMcM wrote: post #139

Earlier quoted context omitted.

This comment captures a lot, perhaps not in the way Ken intended, but I feel compelled to respond. Lets start with the thesis statement, "The web is not open and becoming increasingly less so." On its face, this statement is not only false, it is painfully so. Sort of like saying the world is not round and becoming increasingly less so. To pretty much anyone they would say "the world is clearly round, and its impossi…

You could argue that the IETF has become everything the ISO working groups used to be, and that 'rough consensus and running code' is long gone. I seem to flip flop back and forth on this, personally. Some days the standards process seems bright and cheery, at other times, I fear Apple/Google/Microsoft are running the show.

"You could argue that the IETF has become everything the ISO working groups used to be, and that 'rough consensus and running code' is long gone."

Yes you could, I was there in the trenches trying to urge them not to go down that road. I really lost it when we had gotten Sun to release all claim to any rights to the XDR or RPC code libraries so that IETF could endorse it as an 'independent' standard. There were enough implementations out there, a regular connectathon which tested interoperability. Paul Leach, who made it his life's work to prevent any sort of standardization of RPC, successfully rallied Microsoft to overwhelm the otherwise rational members of the IETF and de-rail that process. It was so blatant, and so petty. I remember telling Vint Cerf that I marked that day, and those events, as the death of the IETF as a body with any integrity. Many working groups soldiered along and did well until they became 'strategic' to some big player, and then their integrity too was ripped out of them. Sort of like that movie 'Invasion of the Body Snatchers.' Very sad.

Over the years I've toyed briefly with starting a new networking working group.

Re: WebKit is the jQuery of Browser Engines

#176

Post by qu4z-2 »

lttlrck wrote: post #95
flyosity wrote: post #32

Earlier quoted context omitted.

Your opinions on what JavaScript libraries provide "the best compatibility" has little bearing on your original statement, that jQuery is not as popular as it actually is.

"jQuery is not as popular as it actually is" Hmm.

Read as "[...] your original statement that jQuery is not as popular as [I believe] it actually is."

Re: WebKit is the jQuery of Browser Engines

#177

Post by qu4z-2 »

johansch wrote: post #145
jgraham wrote: post #70

Earlier quoted context omitted.

> While it's challenging to write a browser engine, it is much much more challenging to write a really fast JIT'ing javascript runtime That isn't really true. Sure, modern JITing js-engines are — arguably —the most technically advanced parts of a modern browser. However they are relatively small and self-contained; a suitably (i.e crazy-) talented team of engineers can get ballpark comparable performance of V8/Spider…

This issue is so misunderstood, mostly because it's so easy to market, measure, explain and graph relative performance of javascript engines, but as James says, they form relatively little part of the over-all performance of browsers.

Somehow I find that despite all the pretty graphs showing how fast Chrome/Firefox are surf (by suckless) which is an ~1k lines of code wrapper for webkit consistently manages to feel faster.

EDIT: Much as Chrome used to feel very fast on release, and has been getting gradually slower as far as I can tell. I remember when it used to have finished rendering a page almost before I hit enter.

Re: WebKit is the jQuery of Browser Engines

#178

Post by breck »

oinksoft wrote: post #19
jeresig wrote: post #15

Earlier quoted context omitted.

Are there better JavaScript libraries than jQuery at certain things? Absolutely -- look to Backbone, Angular, Meteor, etc. etc. Are they better than jQuery at doing DOM manipulation? I think that's an easy argument simply by looking at the numbers: http://trends.builtwith.com/javascript/jQuery jQuery or WebKit being dominant platforms doesn't requite that innovation stop, it gives innovation the ability to explode: W…

I think that's an easy argument simply by looking at the numbers Popular does not imply "better."

Popularity is highly correlated with quality.

Given that A is 10-100x more popular than B, what are the odds that B is "better" than A? Slim.

Now, popularity does not imply that something is the best. Often times there is something better that isn't as popular. But generally the popular thing is better than most alternatives.

Re: WebKit is the jQuery of Browser Engines

#179

Post by gsnedders »

johansch wrote: post #142
bzbarsky wrote: post #103

Earlier quoted context omitted.

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

More like half a dozen people and something like 12-18 months (jgraham will correct me) to make the world's fastest JS JIT. But your bigger point stands.

Carakan was 16.5 months from first commit to shipping (and a month or so more to not being notably buggy), with a team of five for the vast majority of that time. The only code carried over verbatim from Futhark was the regexp engine (though that had machine-code generation added to it), and the parser was also pre-existing (though not shared with Futhark!).

For comparison: MS were the last to do a major rewrite of their layout engine, which started, AIUI, before IE7 shipped (Oct 2006) and shipped in IE8 (Mar 2009), and more-or-less reached feature parity with others with IE9 (Mar 2011). To be fair, they were working from a far more archaic codebase than anyone else, so probably had more work, but they also had a far larger team than anyone else working on this.

Re: WebKit is the jQuery of Browser Engines

#180

Post by saurik »

Me1000 wrote: post #113
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 maj…

... and before IE it was Netscape: people didn't like that either, but you (and most people who talk about browser history) seem to forget or ignore that :(. If you go back and read through the W3C mailing lists people really really hated Netscape (the by-far dominant web browser at the time, for which books on HTML would have sections dedicated to optimizing for and would even go as far as to say being Netscape-only was fine) for seemingly making up HTML as they went along (almost all of the stuff in HTML that is deprecated, including all of the markup that was for style and presentation only, were Netscape-only HTML extensions) and refusing to take up the charge of CSS. Microsoft was even occasionally described as the potential savior that would come in with a second implementation that paid attention to them (and in fact you then find a ton of praise on the list from Microsoft publishing open DTDs from IE).

Despite all of this, Netscape (a company whose business model at the time relied on selling web browsers and getting contracts with ISPs to bundle their software with subscriptions) managed to get Microsoft's hands slapped so hard by the justice department for having the gall to give away a web browser as part of an operating system (something we now all take for granted: no one complains that Apple pushes Safari with OS X, nor do nearly enough people scream loudly about the fact that alternative web browsers on iOS are only possible if you use Apple's rendering engine in a crippled mode, defeating the purpose, despite Apple having near-monopoly status on the mobile web) that Microsoft never quite got back the courage to keep moving forward given the new constraints they were under. Thankfully, in the process, Netscape still died, and from its ashes arose the idea that an open-source web browser would be interesting and viable, leading to the ecosystem we have today.

Post reply on HN