Live data from Hacker News

WebKit is the jQuery of Browser Engines

ejohn.org

21–30 of 214 posts

Re: WebKit is the jQuery of Browser Engines

#21

In the case of JavaScript libraries virtually everyone has standardized upon jQuery at this point. This guy really lives on his own planet. Maybe most websites that only need to add a small piece of JS functionality are using jQuery, but I seriously doubt that "virtually everyone" writing large JS projects is using jQuery. Google Closure Tools, Sencha/ExtJS, and MooTools remain quite popular, and a host of developers…

I don't think this is particularly controversial opinion to have at this point: http://trends.builtwith.com/javascript/jQuery http://trends.builtwith.com/javascript

Re: WebKit is the jQuery of Browser Engines

#23

In the case of JavaScript libraries virtually everyone has standardized upon jQuery at this point. This guy really lives on his own planet. Maybe most websites that only need to add a small piece of JS functionality are using jQuery, but I seriously doubt that "virtually everyone" writing large JS projects is using jQuery. Google Closure Tools, Sencha/ExtJS, and MooTools remain quite popular, and a host of developers…

[deleted]

Re: WebKit is the jQuery of Browser Engines

#24

In the case of JavaScript libraries virtually everyone has standardized upon jQuery at this point. This guy really lives on his own planet. Maybe most websites that only need to add a small piece of JS functionality are using jQuery, but I seriously doubt that "virtually everyone" writing large JS projects is using jQuery. Google Closure Tools, Sencha/ExtJS, and MooTools remain quite popular, and a host of developers…

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

Re: WebKit is the jQuery of Browser Engines

#25
post #15
post #8

Earlier quoted context omitted.

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…

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…

Backbone, Angular, Meteor etc etc ALL use jQuery!

Re: WebKit is the jQuery of Browser Engines

#26
post #20

In the case of JavaScript libraries virtually everyone has standardized upon jQuery at this point. This guy really lives on his own planet. Maybe most websites that only need to add a small piece of JS functionality are using jQuery, but I seriously doubt that "virtually everyone" writing large JS projects is using jQuery. Google Closure Tools, Sencha/ExtJS, and MooTools remain quite popular, and a host of developers…

I don't think he's living on his own planet, he's actually right - jQuery runs the client side web. Not for everyone but easily 90% of sites (that actually have javascript functionality at all) will use jQuery

Rather, the practice of providing a DOM API compatibility layer runs the web, jQuery being the most widely used library of this sort. When you step out of the god-object API jQuery provides and look at the internals, jQuery, MooTools, and Closure look surprisingly similar. I find the latter to provide the best compatibility (so does Google), but that is another discussion altogether.

Re: WebKit is the jQuery of Browser Engines

#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 able to close the gap, much less surpass, with WebKit on that front.

At that point, any competitive advantage they hold in features is being offset in a fairly substantial performance penalty. Good move making the switch. Differentiate elsewhere.

Re: WebKit is the jQuery of Browser Engines

#28
post #9
post #7

I like the arguments: "Don't worry about happening, because it's already happened!"

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 there. To be honest though, I think that's misleading. Mobile Safari has been ridiculously dominant compared with other webkits, in mind and marketshare, and it's that monoculture causing the problems we currently see.

Serious new contenders like Chrome and Opera entering the mobile market with webkit renderers will, I think, actually help that situation to some degree by actually competing with Mobile Safari and not being half-hearted also-rans.

Re: WebKit is the jQuery of Browser Engines

#29
post #4

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

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 reinventing the engine.

Re: WebKit is the jQuery of Browser Engines

#30
post #16
post #11

Earlier quoted context omitted.

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.

That's an interesting assumption to make: Just because Safari or Chrome hypothetically used Gecko doesn't mean that competition would've halted. Why couldn't it have been any different from when Chrome used WebKit as its basis and absolutely trounced Safari?

I wouldn't say Chrome WebKit trounced Safari WebKit. The browser surrounding the engine was better. This means little wrt. to the engine.
Post reply on HN