12 ms·

WebKit is the jQuery of Browser Engines

252 points by jimsteinhart 14y ago

justindocanto 14y ago
Great points. Nice read.
fideloper 14y ago
Not to derail the topic, but did anyone else read that headline as a negative, only to find that it wasn't (necessarily)?
- k3n 14y ago
  No, given that it's from ejohn.org...
- gcp 14y ago
  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 WebKit. I believe it comes pretty close to illustrating what I believe is so wrong about his arguments.
  - jeresig 14y ago
    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 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: When you don't have to work about nit-picky cross-platform capabilities or standardization then you get to focus on performance and building sweet frameworks like Backbone and Angular.
    - oinksoft 14y ago
      I think that's an easy argument simply by looking at the numbers Popular does not imply "better."
      - breck 14y ago
        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.
        dvhh 14y ago
        Popularity is no correlated with quality, more with "good enough for the price".
    - phpnode 14y ago
      Backbone, Angular, Meteor etc etc ALL use jQuery!
      - pestaa 14y ago
        Wrong. At least Angular JS brings its own jQuery-like functions and does not depend on jQuery by itself.
        camus 14y ago
        angularjs uses jquery api , like zepto does it is a hidden dependency. but you are basically using a subset of jquery when you use angularjs.
        qu4z-2 14y ago
        And Gecko uses most of the WebKit api. We're talking about implementations here, not specs.
  - sigzero 14y ago
    "In other words, as far as he cares things other than jQuery don't have a right of existence." I don't think he made that point at all. He is merely reflecting on the fact that jQuery has the most market share and by a long way.
  - Achshar 14y ago
    I actually don't like jQuery at all and I read the headline in negative, so your theory holds true, atleast to me.
- papsosouid 14y ago
  Yeah, same here. I assumed this was going to be some article about why webkit is bad for the web somehow. Funny how statements like that can have such dramatically different interpretations.
cs702 14y ago
WebKit and jQuery -- and Bootstrap -- are becoming the new 'Win32 API.'
- philbarr 14y ago
  Let's hope it doesn't get that bad.
- mmatants 14y ago
  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.
  - tericho 14y ago
    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.
    - bzbarsky 14y ago
      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.
  - dasil003 14y ago
    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 foul things up for everyone. An IE6-like scenario is completely impossible with WebKit.
StavrosK 14y ago
I like the arguments: "Don't worry about <x bad thing> happening, because it's already happened!"
- jeresig 14y ago
  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.
  - StavrosK 14y ago
    I agree with that, it's just that the way the argument was phrased was funny :)
  - ZeroGravitas 14y ago
    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.
    - Turing_Machine 14y ago
      According to Statcounter.com's current numbers, Chrome is 36.9%, Safari is 8.57%, and Opera is 1.2% = 46.67%, leaving 53.3% for everything else. That's not "roughly two thirds". Also, Safari and Chrome are both trending upwards, everything else is trending downwards. http://gs.statcounter.com/#browser-ww-monthly-200807-201302 http://gs.statcounter.com/#browser-ww-monthly-200807-201302
oinksoft 14y ago
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 are skipping compatibility layers altogether and only supporting IE9+ and other recent browser versions, particularly those targeting mobile devices.
- kbutler 14y ago
  Perhaps he is overstating it a little, given that he's the creator of jQuery.
- untog 14y ago
  No, I think the vast majority of websites really do use jQuery. Certainly, Wordpress uses it, so pretty much every Wordpress blog out there does. I just tried the Spotify homepage- yep- Huffington Post- yep... I think that everyone really has standardised on jQuery unless they're doing something specialised.
- phpnode 14y ago
  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
  - oinksoft 14y ago
    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.
    - 14y ago
shmerl 14y ago
Boring. They can switch to Gecko with IPC embedding for a change: https://wiki.mozilla.org/Embedding/IPCLiteAPI https://wiki.mozilla.org/Embedding/IPCLiteAPI
hemancuso 14y ago
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.
- RaphiePS 14y ago
  Correct me if I'm wrong (and I very well may be), but isn't the JS runtime separate from the rendering engine? I was under the impression that Chrome uses WebKit for rendering and V8 for JS. So, even if Opera switches over to WebKit, that shouldn't affect JS.
  - ksherlock 14y ago
    Opera announced that they'll be using v8 for JS. So why opera instead of Chrome? They'll differentiate themselves with the UI, mouse gestures, ad-blocking etc.
  - AdamTReineke 14y ago
    You're right. The point he is making is that there is no need to maintain a rendering engine if it is no longer a point of differentiation when you can focus your efforts on improving the features that make your browser stand out.
    - RaphiePS 14y ago
      Ahh, looks like I misunderstood, thanks. But will developers/users really flock to Opera just because it has a fast JIT? For me, Opera is just something to check for compliance.
      - 14y ago
Yaggo 14y ago
"I don’t think anyone can successfully argue that Chome/Chromium isn’t a better browser than Safari [...]" That sounds like Chrome was somehow superior to Safari. Chrome has some nice features that Safari lacks (and vice versa) but from browser engine perspective they are definitely on par.
- nicholassmith 14y ago
  That stuck out for me as well, I could argue that Chrome isn't a better browser than Safari for me, but functionally they're both using WebKit so they render sites identically in most cases.
  - jeresig 14y ago
    Except when it comes to the JavaScript engine. Safari's JS engine is the slowest out of Chrome/Firefox/Safari: http://arewefastyet.com/ http://arewefastyet.com/
    - nicholassmith 14y ago
      I'd still argue that Chrome isn't a better browser for me, irregardless of JS processing speed.
    - deleted 14y ago
      [deleted]
  - untog 14y ago
    Aside from JS performance, I'd argue that Chome's rapid updates make it a better browser. Safari as at best months old.
    - nicholassmith 14y ago
      Sure, there's a lot going on that makes Chrome a great browser, but it's still not my daily driver as I prefer Safari for a myriad of non-technical reasons. I like the iCloud tab sync, the Twitter integration, the fact it looks significantly nicer than Chrome in terms of blending with the system style (which is arguable given how little else tries these days from Apple's own applications).
dinkumthinkum 14y ago
I wouldn't say mobile is the only world we live; that's a bit of a stretch for me.
addlepate 14y ago
I wish stagnation was Safari's problem. I wish.
petercooper 14y ago
I don't disagree but I also see it more as WebKit as the "Linux kernel" of browser engines. Safari and Chrome both use WebKit but are very different in what they offer.. so they're like the Ubuntu and RedHat. Is it a bad thing that AIX and Solaris fell by the wayside in a rush to Linux? I don't think so. So neither should adopting WebKit as a sort of common kernel in browsers, IMHO. But that's all it is.. MHO ;-)
- MatthewPhillips 14y ago
  But Linux isn't even close to being the only kernel being worked on. Neither absolutely nor from a marketshare perspective.
  - maratd 14y ago
    But WebKit isn't even close to being the only engine being worked on. Neither absolutely nor from a marketshare perspective. Hence, the comparison. Firefox and IE both comprise a major chunk of the market.
  - tombooth 14y ago
    So Firefox would be Mach, Trident Windows and the assorted other smaller browser engines other 'kernels'?
  - snprbob86 14y ago
    What's your point? There's also Trident (IE) and Gecko (FF), just like there's NT and BSD.
    - MatthewPhillips 14y ago
      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.
      - 14y ago
snarfy 14y ago
"This page best viewed in Internet Explorer". Remember those days? This is not a good thing. The HTML spec should be the standard, not WebKit's bugs.
- ripter 14y ago
  The difference is that WebKit is open source with several large companies contributing to it. If it doesn't follow the HTML spec you (or anyone else) can fix the bug. IE was closed source and Microsoft disbanded the team that developed it (IE6). If it had a bug, there wasn't anything you could do about it. You just made your site work around the bug, possibly breaking it on other browsers.
pcwalton 14y ago
Increasingly, jQuery is not just an implementation, but is rather an API. That's why we're seeing the rise of alternatives like zepto.js that match the jQuery API de-facto standard but are implemented better (smaller, dropping IE6 compatibility). Replace "jQuery API" with "Web API" and this actually argues against John's point. Multiple implementations are better for everyone.
- jeresig 14y ago
  I'm not sure Zepto could be defined as "better" considering that it only implements a small subset of the jQuery API. In the browser world you can't get away with implementing a small subset of a specification, it'll be consider broken and people won't use it. I'm not arguing against multiple implementations. If Mozilla were to switch to WebKit, rewrite its DOM implementation to be 20x faster, and then release that -- that would be absolutely stupendous! Much in the same way that the Chrome team created a new JavaScript engine that was much faster than Safari's JS engine. I am arguing that the writing is on the wall for the common parts of a browser. A browser vendor's time will be used much more efficiently by collaborating with each other on the implementation instead of writing a number of separate implementations.
  - pcwalton 14y ago
    "If Mozilla were to switch to WebKit, rewrite its DOM implementation to be 20x faster, and then release that -- that would be absolutely stupendous!" Rewriting WebKit's DOM implementation to be 20x faster wouldn't be possible without rewriting WebKit. The DOM implementation is one of the most central parts of any rendering engine. We're working on doing that (Servo), but not by building on top of WebKit for precisely this reason. "Much in the same way that the Chrome team created a new JavaScript engine that was much faster than Safari's JS engine." They did that by replacing JavaScriptCore wholesale, rather than building on top of it. This was only possible because JavaScript is a standard, not defined by JavaScriptCore's implementation. If JSC had had a monopoly and the Web started relying on JSC's quirks, then V8 might never have happened.
  - goldfeld 14y ago
    In as much as I consider jQuery a kitchen sink approach, anyone who tries to trim it down to the core (and dropping old browsers which need lots of ifs and elses) may well be better in my opinion.
kenjackson 14y ago
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 still strongly believe that being tied to JavaScript as really the only client side language is a mistake. It's not a great IL and limiting the language for such a pervasive platform is scary. I powerful plugin model would be, IMO, one of the best things to a truly powerful web. I wish the web was more open. I wish that browsers were a truly extensible runtime that specified lower level abstractions, that allowed more innovation at the top of the stack. It feels like we're walking into the dark age of the internet.
- etherealG 14y ago
  if the code for the de facto implementation is open source, does it matter? i see the code and the standard as the same thing in different languages personally.
  - tolmasky 14y ago
    They are different things because its unrealistic to fork WebKit and get any significant market share. So even though you might make a worthwhile change to the engine, realistically you need that change to be accepted by WebKit proper for it to matter.
    - jeresig 14y ago
      Forking WebKit is effectively the same as writing your own browser, with regards to standardization. At the end of the day you want to get everyone to agree on the standard -- having an implementation that everyone can use only helps to sweeten the deal.
      - tolmasky 14y ago
        The response was more in regards to the grand-OP's desire for a lower level extensible runtime and lamentation about plugins, more than a comparison to standards now that I think about it. In other words, which web is more open: 1. One in which all the code is open source but there are huge hurdles to releasing your own browser, and any new feature is thus at the mercy of just a few big companies (Apple, Google, etc.). or 2. One in which perhaps all the browsers were closed source, but adding new features to any such browser really was just a matter of referencing a script on a web page? The questions is more or less only useful as a thought experiment by this point of course, and in particular I don't feel that the "standards" process was ever particularly open to begin with, so I don't think things have, or will, necessarily get much worse.
bobsy 14y ago
I think it is obvious that WebKit has won and by a margin when it comes to browser engines. For Opera it is the best move for them. They can now focus the majority of their development time on making the browser great instead of putting a decent chunk of their development time in effectively replicating what WebKit does. I think in the coming year or so Opera will be become a far better browser for it. As for Mozilla and IE. You would expect Microsoft have more than enough resources to keep working on Trident/Lynx whatever it is called. For Mozilla is their OS tied to their own engine? I don't know how committed they are to it. For all the releases of Firefox tabs still aren't sandboxed and phpmyadmin often freezes the entire browser when looking at monster tables... perhaps they would benefit from spending more time improving the browser and less time working on rendering. I wonder what would have happened if Microsoft, Mozilla or Opera had open sourced their browser engine with WebKit. Perhaps we would have seen a split and more competition in this area. Now it is who has the $$$ to continue to develop their own propriety engine.
- gcp 14y ago
  I don't know how committed they are to it. Extremely, especially in this context. The reason why Opera is switching (web compatibility issues if you're not the dominant implementation) is exactly the reason why Mozilla would fight a switch with tooth and nail - and remember that unlike Opera they cannot care for profit when doing so. Here's an extensive reply from a Firefox developer: http://www.quora.com/Mozilla-Firefox/Will-Firefox-ever-drop-its-Gecko-layout-engine-to-adopt-WebKit http://www.quora.com/Mozilla-Firefox/Will-Firefox-ever-drop-... I wonder what would have happened if Microsoft, Mozilla or Opera had open sourced their browser engine with WebKit. I have no idea what you mean.
  - mtgx 14y ago
    He means that there are different parts of a browser you can focus on and innovate there. If the rendering engine was 'out of the way", and didn't have to worry about that part, they could focus a lot more on other stuff. Right now Microsoft has to focus on making Trident catch-up with webkit, and it's still 2 years behind webkit in HTML5 features. Go to html5test.com and see how far IE10 is. It's more behind than Chrome 10 was when IE9 launched 2 years ago.
dubcanada 14y ago
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
- gcp 14y ago
  Mobile.
  - deleted 14y ago
    [deleted]
watmough 14y ago
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.
malandrew 14y ago
I know this is OT, but how hard would it be to create a thin layer so that WebKit run on bare metal?
- simias 14y ago
  Depends on the metal, which is why it's nice to have an OS as an abstraction layer :)
- kbrosnan 14y ago
  Mozilla is doing this with Gecko. Google is sort of doing this with Chromebooks (AFIK). There is little to no incentive for Apple or Google to do this on their flagship products of iOS and Android since they already have dev ecosystems using objective c and java respectively.
- dvhh 14y ago
  wasn't that the goal of webOS ?
azakai 14y ago
I disagree with much of this article. > as a contributor to WebKit you have the complete ability to drive it in a direction you wish (often for the better) Not really. Follow the internal WebKit politics and you see a lot of conflicts. For example, Google wanted to push multi-VM support (for Dart) and Apple blocked that. > WebKit is already a de facto standard On mobile. Mobile isn't everything. Also, should we have said "ie6 is already a de factor standard and given up"? > I think one this is clear already: WebKit has completely and unequivocally won mobile at this point. They are nearly the only rendering engine used on the vast majority of mobile browsers, including the soon-to-switch Opera Mini/Mobile browsers too. There is no reason to worry about a slippery slope, the slope has already been slid down. In order for any other browser to remain relevant in the world of mobile (which, you must admit, is quickly becoming the only world we live in) they must keep feature parity with WebKit. Again, this is utterly defeatist. Even if it were 99% true, should everyone give up? > At this point it’s honestly a business/engineering decision for Mozilla and Microsoft (as it always has been). No, Mozilla is a nonprofit and the decision would also regard whether it is good for the web, or not. I'm surprised to see John Resig not realize that - he used to work at Mozilla. edit: And regarding the main point: jQuery worked in a space that was not standards-based. There were multiple JS libraries, and they fought for market share. No one tried to develop a standard that there would be multiple implementations for. Comparing jQuery to WebKit is odd.
- zobzu 14y ago
  "On mobile. Mobile isn't everything." And.. mobile is not nothing. mobile is huge.
  - azakai 14y ago
    Agreed.
deleted 14y ago
[deleted]
podperson 14y ago
I'd say the big risk with webkit which no-one is addressing is that it's LGPL not GPL. Someone could get a dominant position and use a closed fork of it. (The fact that Apple open-sourced Webkit is to its credit.)
- dpark 14y ago
  The LGPL doesn't work that way. You can't fork WebKit and keep your changes closed unless you don't distribute your browser to anyone. Now, you could use webkit along with (for example) a closed Javascript runtime, but that really has nothing to do with WebKit itself.
  - podperson 14y ago
    Right, my mistake, but you can effectively borg it.
- dvhh 14y ago
  yeah because creating a closed fork of an open source project is really popular.
mehrzad 14y ago
https://html5test.com/results/desktop.html https://html5test.com/results/desktop.html Why does Firefox do so poorly? ;_; Mozilla is such a good organization (but to be fair can only survive with Google).
- khuey 14y ago
  Because much of what it tests isn't in HTML5. Some of what it tests isn't even standards track (e.g. WebSQL). The tests are also usually pretty superficial and test things like "does this property exist", not "does this feature work".

252 points by jimsteinhart 14y ago

Great points. Nice read.

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

k3n 14y ago
No, given that it's from ejohn.org...
gcp 14y ago
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 WebKit. I believe it comes pretty close to illustrating what I believe is so wrong about his arguments.
- jeresig 14y ago
  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 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: When you don't have to work about nit-picky cross-platform capabilities or standardization then you get to focus on performance and building sweet frameworks like Backbone and Angular.
  - oinksoft 14y ago
    I think that's an easy argument simply by looking at the numbers Popular does not imply "better."
    - breck 14y ago
      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.
      - dvhh 14y ago
        Popularity is no correlated with quality, more with "good enough for the price".
  - phpnode 14y ago
    Backbone, Angular, Meteor etc etc ALL use jQuery!
    - pestaa 14y ago
      Wrong. At least Angular JS brings its own jQuery-like functions and does not depend on jQuery by itself.
      - camus 14y ago
        angularjs uses jquery api , like zepto does it is a hidden dependency. but you are basically using a subset of jquery when you use angularjs.
        qu4z-2 14y ago
        And Gecko uses most of the WebKit api. We're talking about implementations here, not specs.
- sigzero 14y ago
  "In other words, as far as he cares things other than jQuery don't have a right of existence." I don't think he made that point at all. He is merely reflecting on the fact that jQuery has the most market share and by a long way.
- Achshar 14y ago
  I actually don't like jQuery at all and I read the headline in negative, so your theory holds true, atleast to me.
papsosouid 14y ago
Yeah, same here. I assumed this was going to be some article about why webkit is bad for the web somehow. Funny how statements like that can have such dramatically different interpretations.

cs702 14y ago

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

philbarr 14y ago
Let's hope it doesn't get that bad.
mmatants 14y ago
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.
- tericho 14y ago
  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.
  - bzbarsky 14y ago
    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.
- dasil003 14y ago
  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 foul things up for everyone. An IE6-like scenario is completely impossible with WebKit.

StavrosK 14y ago

I like the arguments: "Don't worry about <x bad thing> happening, because it's already happened!"

jeresig 14y ago
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.
- StavrosK 14y ago
  I agree with that, it's just that the way the argument was phrased was funny :)
- ZeroGravitas 14y ago
  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.
  - Turing_Machine 14y ago
    According to Statcounter.com's current numbers, Chrome is 36.9%, Safari is 8.57%, and Opera is 1.2% = 46.67%, leaving 53.3% for everything else. That's not "roughly two thirds". Also, Safari and Chrome are both trending upwards, everything else is trending downwards. http://gs.statcounter.com/#browser-ww-monthly-200807-201302 http://gs.statcounter.com/#browser-ww-monthly-200807-201302

oinksoft 14y ago

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 are skipping compatibility layers altogether and only supporting IE9+ and other recent browser versions, particularly those targeting mobile devices.

kbutler 14y ago
Perhaps he is overstating it a little, given that he's the creator of jQuery.
untog 14y ago
No, I think the vast majority of websites really do use jQuery. Certainly, Wordpress uses it, so pretty much every Wordpress blog out there does. I just tried the Spotify homepage- yep- Huffington Post- yep... I think that everyone really has standardised on jQuery unless they're doing something specialised.
phpnode 14y ago
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
- oinksoft 14y ago
  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.
  - 14y ago

shmerl 14y ago

Boring. They can switch to Gecko with IPC embedding for a change: https://wiki.mozilla.org/Embedding/IPCLiteAPI https://wiki.mozilla.org/Embedding/IPCLiteAPI

hemancuso 14y ago

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.

RaphiePS 14y ago
Correct me if I'm wrong (and I very well may be), but isn't the JS runtime separate from the rendering engine? I was under the impression that Chrome uses WebKit for rendering and V8 for JS. So, even if Opera switches over to WebKit, that shouldn't affect JS.
- ksherlock 14y ago
  Opera announced that they'll be using v8 for JS. So why opera instead of Chrome? They'll differentiate themselves with the UI, mouse gestures, ad-blocking etc.
- AdamTReineke 14y ago
  You're right. The point he is making is that there is no need to maintain a rendering engine if it is no longer a point of differentiation when you can focus your efforts on improving the features that make your browser stand out.
  - RaphiePS 14y ago
    Ahh, looks like I misunderstood, thanks. But will developers/users really flock to Opera just because it has a fast JIT? For me, Opera is just something to check for compliance.
    - 14y ago

Yaggo 14y ago

"I don’t think anyone can successfully argue that Chome/Chromium isn’t a better browser than Safari [...]" That sounds like Chrome was somehow superior to Safari. Chrome has some nice features that Safari lacks (and vice versa) but from browser engine perspective they are definitely on par.

nicholassmith 14y ago
That stuck out for me as well, I could argue that Chrome isn't a better browser than Safari for me, but functionally they're both using WebKit so they render sites identically in most cases.
- jeresig 14y ago
  Except when it comes to the JavaScript engine. Safari's JS engine is the slowest out of Chrome/Firefox/Safari: http://arewefastyet.com/ http://arewefastyet.com/
  - nicholassmith 14y ago
    I'd still argue that Chrome isn't a better browser for me, irregardless of JS processing speed.
  - deleted 14y ago
    [deleted]
- untog 14y ago
  Aside from JS performance, I'd argue that Chome's rapid updates make it a better browser. Safari as at best months old.
  - nicholassmith 14y ago
    Sure, there's a lot going on that makes Chrome a great browser, but it's still not my daily driver as I prefer Safari for a myriad of non-technical reasons. I like the iCloud tab sync, the Twitter integration, the fact it looks significantly nicer than Chrome in terms of blending with the system style (which is arguable given how little else tries these days from Apple's own applications).

dinkumthinkum 14y ago

I wouldn't say mobile is the only world we live; that's a bit of a stretch for me.

addlepate 14y ago

I wish stagnation was Safari's problem. I wish.

petercooper 14y ago

I don't disagree but I also see it more as WebKit as the "Linux kernel" of browser engines. Safari and Chrome both use WebKit but are very different in what they offer.. so they're like the Ubuntu and RedHat. Is it a bad thing that AIX and Solaris fell by the wayside in a rush to Linux? I don't think so. So neither should adopting WebKit as a sort of common kernel in browsers, IMHO. But that's all it is.. MHO ;-)

MatthewPhillips 14y ago
But Linux isn't even close to being the only kernel being worked on. Neither absolutely nor from a marketshare perspective.
- maratd 14y ago
  But WebKit isn't even close to being the only engine being worked on. Neither absolutely nor from a marketshare perspective. Hence, the comparison. Firefox and IE both comprise a major chunk of the market.
- tombooth 14y ago
  So Firefox would be Mach, Trident Windows and the assorted other smaller browser engines other 'kernels'?
- snprbob86 14y ago
  What's your point? There's also Trident (IE) and Gecko (FF), just like there's NT and BSD.
  - MatthewPhillips 14y ago
    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.
    - 14y ago

snarfy 14y ago

"This page best viewed in Internet Explorer". Remember those days? This is not a good thing. The HTML spec should be the standard, not WebKit's bugs.

ripter 14y ago
The difference is that WebKit is open source with several large companies contributing to it. If it doesn't follow the HTML spec you (or anyone else) can fix the bug. IE was closed source and Microsoft disbanded the team that developed it (IE6). If it had a bug, there wasn't anything you could do about it. You just made your site work around the bug, possibly breaking it on other browsers.

pcwalton 14y ago

Increasingly, jQuery is not just an implementation, but is rather an API. That's why we're seeing the rise of alternatives like zepto.js that match the jQuery API de-facto standard but are implemented better (smaller, dropping IE6 compatibility). Replace "jQuery API" with "Web API" and this actually argues against John's point. Multiple implementations are better for everyone.

jeresig 14y ago
I'm not sure Zepto could be defined as "better" considering that it only implements a small subset of the jQuery API. In the browser world you can't get away with implementing a small subset of a specification, it'll be consider broken and people won't use it. I'm not arguing against multiple implementations. If Mozilla were to switch to WebKit, rewrite its DOM implementation to be 20x faster, and then release that -- that would be absolutely stupendous! Much in the same way that the Chrome team created a new JavaScript engine that was much faster than Safari's JS engine. I am arguing that the writing is on the wall for the common parts of a browser. A browser vendor's time will be used much more efficiently by collaborating with each other on the implementation instead of writing a number of separate implementations.
- pcwalton 14y ago
  "If Mozilla were to switch to WebKit, rewrite its DOM implementation to be 20x faster, and then release that -- that would be absolutely stupendous!" Rewriting WebKit's DOM implementation to be 20x faster wouldn't be possible without rewriting WebKit. The DOM implementation is one of the most central parts of any rendering engine. We're working on doing that (Servo), but not by building on top of WebKit for precisely this reason. "Much in the same way that the Chrome team created a new JavaScript engine that was much faster than Safari's JS engine." They did that by replacing JavaScriptCore wholesale, rather than building on top of it. This was only possible because JavaScript is a standard, not defined by JavaScriptCore's implementation. If JSC had had a monopoly and the Web started relying on JSC's quirks, then V8 might never have happened.
- goldfeld 14y ago
  In as much as I consider jQuery a kitchen sink approach, anyone who tries to trim it down to the core (and dropping old browsers which need lots of ifs and elses) may well be better in my opinion.

kenjackson 14y ago

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 still strongly believe that being tied to JavaScript as really the only client side language is a mistake. It's not a great IL and limiting the language for such a pervasive platform is scary. I powerful plugin model would be, IMO, one of the best things to a truly powerful web. I wish the web was more open. I wish that browsers were a truly extensible runtime that specified lower level abstractions, that allowed more innovation at the top of the stack. It feels like we're walking into the dark age of the internet.

etherealG 14y ago
if the code for the de facto implementation is open source, does it matter? i see the code and the standard as the same thing in different languages personally.
- tolmasky 14y ago
  They are different things because its unrealistic to fork WebKit and get any significant market share. So even though you might make a worthwhile change to the engine, realistically you need that change to be accepted by WebKit proper for it to matter.
  - jeresig 14y ago
    Forking WebKit is effectively the same as writing your own browser, with regards to standardization. At the end of the day you want to get everyone to agree on the standard -- having an implementation that everyone can use only helps to sweeten the deal.
    - tolmasky 14y ago
      The response was more in regards to the grand-OP's desire for a lower level extensible runtime and lamentation about plugins, more than a comparison to standards now that I think about it. In other words, which web is more open: 1. One in which all the code is open source but there are huge hurdles to releasing your own browser, and any new feature is thus at the mercy of just a few big companies (Apple, Google, etc.). or 2. One in which perhaps all the browsers were closed source, but adding new features to any such browser really was just a matter of referencing a script on a web page? The questions is more or less only useful as a thought experiment by this point of course, and in particular I don't feel that the "standards" process was ever particularly open to begin with, so I don't think things have, or will, necessarily get much worse.

bobsy 14y ago

I think it is obvious that WebKit has won and by a margin when it comes to browser engines. For Opera it is the best move for them. They can now focus the majority of their development time on making the browser great instead of putting a decent chunk of their development time in effectively replicating what WebKit does. I think in the coming year or so Opera will be become a far better browser for it. As for Mozilla and IE. You would expect Microsoft have more than enough resources to keep working on Trident/Lynx whatever it is called. For Mozilla is their OS tied to their own engine? I don't know how committed they are to it. For all the releases of Firefox tabs still aren't sandboxed and phpmyadmin often freezes the entire browser when looking at monster tables... perhaps they would benefit from spending more time improving the browser and less time working on rendering. I wonder what would have happened if Microsoft, Mozilla or Opera had open sourced their browser engine with WebKit. Perhaps we would have seen a split and more competition in this area. Now it is who has the $$$ to continue to develop their own propriety engine.

gcp 14y ago
I don't know how committed they are to it. Extremely, especially in this context. The reason why Opera is switching (web compatibility issues if you're not the dominant implementation) is exactly the reason why Mozilla would fight a switch with tooth and nail - and remember that unlike Opera they cannot care for profit when doing so. Here's an extensive reply from a Firefox developer: http://www.quora.com/Mozilla-Firefox/Will-Firefox-ever-drop-its-Gecko-layout-engine-to-adopt-WebKit http://www.quora.com/Mozilla-Firefox/Will-Firefox-ever-drop-... I wonder what would have happened if Microsoft, Mozilla or Opera had open sourced their browser engine with WebKit. I have no idea what you mean.
- mtgx 14y ago
  He means that there are different parts of a browser you can focus on and innovate there. If the rendering engine was 'out of the way", and didn't have to worry about that part, they could focus a lot more on other stuff. Right now Microsoft has to focus on making Trident catch-up with webkit, and it's still 2 years behind webkit in HTML5 features. Go to html5test.com and see how far IE10 is. It's more behind than Chrome 10 was when IE9 launched 2 years ago.

dubcanada 14y ago

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

gcp 14y ago
Mobile.
- deleted 14y ago
  [deleted]

watmough 14y ago

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.

malandrew 14y ago

I know this is OT, but how hard would it be to create a thin layer so that WebKit run on bare metal?

simias 14y ago
Depends on the metal, which is why it's nice to have an OS as an abstraction layer :)
kbrosnan 14y ago
Mozilla is doing this with Gecko. Google is sort of doing this with Chromebooks (AFIK). There is little to no incentive for Apple or Google to do this on their flagship products of iOS and Android since they already have dev ecosystems using objective c and java respectively.
dvhh 14y ago
wasn't that the goal of webOS ?

azakai 14y ago

I disagree with much of this article. > as a contributor to WebKit you have the complete ability to drive it in a direction you wish (often for the better) Not really. Follow the internal WebKit politics and you see a lot of conflicts. For example, Google wanted to push multi-VM support (for Dart) and Apple blocked that. > WebKit is already a de facto standard On mobile. Mobile isn't everything. Also, should we have said "ie6 is already a de factor standard and given up"? > I think one this is clear already: WebKit has completely and unequivocally won mobile at this point. They are nearly the only rendering engine used on the vast majority of mobile browsers, including the soon-to-switch Opera Mini/Mobile browsers too. There is no reason to worry about a slippery slope, the slope has already been slid down. In order for any other browser to remain relevant in the world of mobile (which, you must admit, is quickly becoming the only world we live in) they must keep feature parity with WebKit. Again, this is utterly defeatist. Even if it were 99% true, should everyone give up? > At this point it’s honestly a business/engineering decision for Mozilla and Microsoft (as it always has been). No, Mozilla is a nonprofit and the decision would also regard whether it is good for the web, or not. I'm surprised to see John Resig not realize that - he used to work at Mozilla. edit: And regarding the main point: jQuery worked in a space that was not standards-based. There were multiple JS libraries, and they fought for market share. No one tried to develop a standard that there would be multiple implementations for. Comparing jQuery to WebKit is odd.

zobzu 14y ago
"On mobile. Mobile isn't everything." And.. mobile is not nothing. mobile is huge.
- azakai 14y ago
  Agreed.

deleted 14y ago

[deleted]

podperson 14y ago

I'd say the big risk with webkit which no-one is addressing is that it's LGPL not GPL. Someone could get a dominant position and use a closed fork of it. (The fact that Apple open-sourced Webkit is to its credit.)

dpark 14y ago
The LGPL doesn't work that way. You can't fork WebKit and keep your changes closed unless you don't distribute your browser to anyone. Now, you could use webkit along with (for example) a closed Javascript runtime, but that really has nothing to do with WebKit itself.
- podperson 14y ago
  Right, my mistake, but you can effectively borg it.
dvhh 14y ago
yeah because creating a closed fork of an open source project is really popular.

mehrzad 14y ago

https://html5test.com/results/desktop.html https://html5test.com/results/desktop.html Why does Firefox do so poorly? ;_; Mozilla is such a good organization (but to be fair can only survive with Google).

khuey 14y ago
Because much of what it tests isn't in HTML5. Some of what it tests isn't even standards track (e.g. WebSQL). The tests are also usually pretty superficial and test things like "does this property exist", not "does this feature work".