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

121–130 of 214 posts

Re: WebKit is the jQuery of Browser Engines

#121

Post by bzbarsky »

Arelius wrote: post #118
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...

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.

We've seen a new layout engine written. Gecko. It took about 15-16 years to get to where it is now, with on average probably ~100 developers. Granted, you can argue it wasn't the most efficient path to get there, but I doubt that you could rebuild Gecko (or WebKit) from scratch today in fewer than 5 years with a team that's about that size...

For that matter, it's not like KHTML sprang out of the void fully-formed; I distinctly recall it being written. Again, the "the path wasn't optimal" arguments may apply.

Re: WebKit is the jQuery of Browser Engines

#122

Post by tolmasky »

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

Here's another interesting way to think about it: look at the mobile web on iOS. Does it matter that WebKit is open source and forkable? No, since Apple actively prevents "alternative" visions of what the web should be since they just don't allow custom builds of WebKit/JS on there. Any browser you make can only add superficial features, forcing you to use the built in WebKit. You may have a great idea that would instantly make everyone want to use web apps on iOS instead of native apps, but since you 1) can't ship that browser on iOS, and 2) can't convince Apple to commit that change to WebKit proper, you are effectively locked out.

Compare this to a plugin-driven environment vs a standards-driven environment. Say what you like about Flash, but it was able to guerrilla video onto the web without anyone's permission.

Re: WebKit is the jQuery of Browser Engines

#123

Post by romaniv »

pkulak wrote: post #85
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.…

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…

This in an incredibly short-sighted comment. The engine is just a client application. There are millions of websites on the other end of the line. Any changes to web standards also affects them. That's why it's incredibly harmful to treat any single implementation as a de-facto standard.

We need (good) web standards, because we need consistent web architecture where features work together and somebody does long-term planning.

Re: WebKit is the jQuery of Browser Engines

#124

Post by shmerl »

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…

The "almost all of the mobile" part is really bad, and exactly resembles the IE situation on the desktop before. I hope Mozilla will shift the balance there again.

Re: WebKit is the jQuery of Browser Engines

#125

Post by tomjen3 »

phpnode wrote: post #39
oinksoft wrote: post #38

Earlier quoted context omitted.

None of the top five websites use jQuery. Of the top 20, I've got one fifth of them using jQuery: Amazon, eBay, Wikipedia, and MSN. Not in the hospital yet.

but still the majority of them do, by a wide margin. I don't even know why you're debating this, it's completely obvious that jQuery has by far the largest mindshare. edit: ok now I get it, I had a look at your website. You like Closure so jQuery must suck, right? Also I would be in the hospital after 5 shots....

Before you insult a poster, please look at what he is actually refuting: that virtually everybody use JQuery.

Virtually everybody is far more than a majority.

Re: WebKit is the jQuery of Browser Engines

#126

Post by tomjen3 »

oinksoft wrote: post #52
phpnode wrote: post #47

Earlier quoted context omitted.

you're right in that I should have checked first, and really if you think about it it's no surprise that YouTube, Yahoo, Google etc are using their own tools. That does not detract from the point that jQuery has massive, ridiculous mind share and completely dominates the web though. Your point about it being impossible to build a gmail style app in jQuery is extremely dubious. There are an awful lot of complicated JS…

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?

Re: WebKit is the jQuery of Browser Engines

#127

Post by mtgx »

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

I'd be a lot more worried about implementing proprietary codecs like h.264 and HEVC, and DRM schemes on the web than about having one open source rendering engine as the "standard" for web browsers. At least you can fork webkit, and anyone can collaborate on it anyway.

Re: WebKit is the jQuery of Browser Engines

#128

Post by mgkimsal »

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

+1

I've said for years that a pluggable javascript engine should be something that was fundamental to browsers. Extending it further, plugins that allowed for alternate and complementary lower-level technologies (easily embed a python engine, for example) would lead to more competition and innovation.

We just had a discussion (or, I had a rant) about this at a local web meetup last night. 10 years ago it was "IE only". We're moving in to "webkit only" these days, especially if you're targetting mobile users. In some ways it doesn't feel like we've progressed all that much.

Re: WebKit is the jQuery of Browser Engines

#129

Post by malandrew »

bzbarsky wrote: post #119
malandrew wrote: post #115

Earlier quoted context omitted.

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

I don't know if it does or does not. Maybe. Was the Opera browser engine doing anything to provide a more parallel engine option? If not, it arguable wasn't helping in this respect either.

Since WebKit is open source, can't you just submit bugfixes for the bugs that are parallelism bottlenecks? Seems like that would make a lot more sense than coding another engine to accommodate those bugs. If it truly is a bug, there shouldn't be any problem with submitting a bugfix and getting it accepted.

Since you're working on FireFox, are there any examples of WebKit "bugs" that prevent parallelism that you could not fix yourself? Does Mozilla have a team of WebKit engineers whose sole job is to fix WebKit so that those monoculture problems are mitigated and don't become a problem for other browser engines? At the end of the day, all you guys need to defend is the interface, not the implementation. Fixing each other's engines before bugs become features seems like a good way to accomplish this. ref: http://xkcd.com/1172/

The most important abstraction to fix isn't even a WebKit abstraction, it's a W3C abstraction. Everything was doomed from the get go because of the one-to-one relationship between the window and the document. I agree with Kay here about TBL & Co being shortsighted in what the web could have become if a richer interactive experience instead of a document based experience had been considered from inception.

Look at Twitter. That's not a document. That's an application. Each tweet in the interface is a document. Every tweet in that feed is a document that has been "transcluded" into the app Twitter built on top of a document. There needs to be a standard way to "transclude" documents with reference URL that allows interactivity. The fact that the only hyperlinking option we have today is the tag is unfortunate. There need to be more ways of hyperlinking than an tag. You need to be able to window directly to a document or document fragment at a different URL. The #hashanchors aren't sufficient, since they only describe a beginning, not an end to the fragment being excerpt. iFrames kind of provide an alternative, but this was never explored properly. The host app should also be able to provide a cached copy of the contents of any sub-document for performance and to guarantee that a copy of the referred document is always available in the parent context.

edit: downvote? srsly? without a response? downvoting is for comments that don't contribute to the conversation, not for comments you simply don't agree with.

Re: WebKit is the jQuery of Browser Engines

#130

Post by Me1000 »

shmerl wrote: post #124
Me1000 wrote: post #113

Earlier quoted context omitted.

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…

The "almost all of the mobile" part is really bad, and exactly resembles the IE situation on the desktop before. I hope Mozilla will shift the balance there again.

The problem with saying "Webkit is the new IE" is that IE was allowed to stagnate because it was a singular browser with a dominate position in the market. When that position was achieved, it was no longer necessary for the company maintaining it to continue to compete.

Webkit, in contrast, isn't controlled by any one company. The people using it have access to the source, and more often that not are contributing to the project themselves.

I don't think the competition is going to end, It's just going to change form.

Post reply on HN