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

141–150 of 214 posts

Re: WebKit is the jQuery of Browser Engines

#141

Post by ripter »

oinksoft wrote: post #98
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.

You ought to read comments before replying to them. I clearly said that only those four are using jQuery, and that the remaining sixteen do not. I checked all of them by hand before stating this, except for Wikipedia because it is common knowledge that MediaWiki uses jQuery. Also, your idea below about sniffing for $ is a bit embarrassing. Firefox, Chrome, etc. have come with $ for many years as an ID or query select…

you ought to read comments before replying to them.

I clearly said you can not just check for `$`.

Re: WebKit is the jQuery of Browser Engines

#142

Post by johansch »

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

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.

Re: WebKit is the jQuery of Browser Engines

#143

Post by youngtaff »

ripter wrote: post #88
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.

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.

Re: WebKit is the jQuery of Browser Engines

#144

Post by jonknee »

snowwrestler wrote: post #64
pkorzeniewski wrote: post #24

Earlier quoted context omitted.

jQuery has a 90% market share[1] among JS libraries so I think it isn't an exaggeration. [1] http://w3techs.com/technologies/overview/javascript_library/...

But the biggest websites generally don't use 3rd-party JS libraries at all--Google, Yahoo, Facebook, Twitter, etc. all write their own javascript libraries. Sure there is a long tail of sites that do use jQuery, but most of them don't do very much or get much traffic. If you look at jQuery's market share by aggregate user sessions or by aggregate time on site across the entire web, it does not look nearly as importan…

> Sure there is a long tail of sites that do use jQuery, but most of them don't do very much or get much traffic.

Most sites in general don't get much traffic, but it's absurd to argue that jQuery is not popular amongst large websites. You don't think sites like nytimes.com, craigslist.org, twitter.com (that's right, check the source), live.com, netflix.com and pintrest.com push a lot of traffic? Even more sites use Sizzle, jQuery's selector engine.

Re: WebKit is the jQuery of Browser Engines

#145

Post by johansch »

jgraham wrote: post #70
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…

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

Re: WebKit is the jQuery of Browser Engines

#146

Post by malandrew »

bzbarsky wrote: post #107
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.

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?

Re: WebKit is the jQuery of Browser Engines

#147

Post by malandrew »

gcp wrote: post #11
spicyj wrote: post #10

Earlier quoted context omitted.

"…because it's already happened and the world hasn't exploded ." It's hard to know now what the very–long-term effects will be but John's point that the web has benefited from Chrome's creation is hard to argue with. As for whether it's benefited more or less than if Chrome had used a different rendering engine, we'll never know…

I believe KTHML->WebKit has pretty much illustrated that having standards that allow new implementations to be developed is a good, essential thing. We'd have been in an interesting, and perhaps worse state if Safari and Chrome were both Gecko based instead of competing therewith.

Why would we be in a worse state if Chrome and Safari were Gecko based?

Re: WebKit is the jQuery of Browser Engines

#148

Post by malandrew »

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.

Asana to me feels far more complex and robust than Gmail. There are tons of things I can do that feel desktop like in Asana, that I can't do in Gmail.

Re: WebKit is the jQuery of Browser Engines

#149

Post by watmough »

I look at the who the author and hesitate to disagree, but I've had better experience in some areas with Firefox on Android (notably webgl) than I have had with Chrome / Chrome Beta.

Personally, aside from a few small wrinkles, I prefer the experience of using Firefox over Chrome on Android.

Re: WebKit is the jQuery of Browser Engines

#150

Post by yuhong »

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…

As an example, I personally figured out where legacy color parsing is in the Netscape classic source: http://stackoverflow.com/questions/8318911/why-does-html-thi...

It is so subtle even Netscape's own Gecko rewrite did not get it completely right the first time: https://bugzilla.mozilla.org/show_bug.cgi?id=121738

Post reply on HN