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…
WebKit is the jQuery of Browser Engines
131–140 of 214 posts
Re: WebKit is the jQuery of Browser Engines
#132I 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…
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-Fir…
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.
Re: WebKit is the jQuery of Browser Engines
#133Earlier quoted context omitted.
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…
Re: WebKit is the jQuery of Browser Engines
#134Earlier quoted context omitted.
> 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, ther…
Re: WebKit is the jQuery of Browser Engines
#135Earlier quoted context omitted.
> 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, ther…
That may well be true. But what others in this thread are arguing is that it would also not be terrible if everyone else switched to WebKit too, and I believe they're wrong about that.
> can't you just submit bugfixes for the bugs that are parallelism bottlenecks?
You mean bugs like being written in C++ and not architected around parallelism?
Bolting on parallelism is _hard_. Have you ever tried doing that with an existing multi-million-line C++ codebase? I've tried with Gecko, and I've spoken with people who have tried with WebKit, as well as reading a good bit of WebKit source, and it's not really feasible unless you drop everything else and focus all your energy on it. And maybe not even then.
> are there any examples of WebKit "bugs" that prevent parallelism that you could not fix yourself
And get the patches actually accepted in WebKit? Lots.
Again, you seem to think the problem is some small issues here and there, whereas the problem is more that you have lots of code touching non-const data through C++ pointers, which means that if you try to parallelize you either get tons of data races or lock contention that kills performance or most likely both.
> At the end of the day, all you guys need to defend is the interface, not the implementation
As long as there are multiple implementations. Unless you include in "interface" everything that's web-visible, but policing that is a huge endeavor that no one working on browser implementations has the manpower for.
Re: WebKit is the jQuery of Browser Engines
#136The 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.…
So, the internet is becoming more open, not less.
Re: WebKit is the jQuery of Browser Engines
#137Earlier quoted context omitted.
Clearly you have some kind of issue with jQuery but just because you don't like it doesn't make it any less popular, useful or prevalent. Here's a fun drinking game - open up the top 1000 websites and do a shot for each one that uses jQuery. You will be in hospital by about #20 I think.
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.
Google uses jQuery (and hosts it for millions of sites), just not on their very optimized homepage. They built a very large framework of their own to power their apps, but a lot of their informational sites use jQuery. Here are some examples:
https://developers.google.com http://www.chromeexperiments.com http://developer.android.com
Re: WebKit is the jQuery of Browser Engines
#138Earlier 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…
Re: WebKit is the jQuery of Browser Engines
#139The 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 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 impossible to change that." Similarly there is absolutely nothing standing between Ken, or anyone else, preventing them from building an entirely different "web" just like Tim Berners-Lee did back at CERN. So the definition of the word 'open' here clearly is needs some additional verbiage.
The next statement helps a bit, "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'."
This deliciously captures a debate that has raged for 30 years at least. "Which came first, the standard or the code?"
Back when I was young and impressionable, the debate was something called the "ISO 7 layer networking model" and "TCP/IP". You see the international standards organization had decided that the world needed a global networking standard, and so they got their best standards engineers together to come up with what they gloriously christened the "Open Standards Interconnect" or OSI set of protocols. Meanwhile a scrappy bunch of network engineers and hacker types were in this loose knit organization called the Internet Engineering Task Force who were building networks that spanned countries and they wrote code and brought it to the meetings and debated stuff that worked well and stuff that didn't work well, and then everyone went back and wrote more code, Etc.
The forces of evil ignored the IETF and focused on the ISO working groups, since the latter were making standards and the former were just playing around with code.
As it turned out, working code tended to trump standards, and a process of debating changes to the system using working code vs debate using 'it should/it might' as opposed to 'version A does/ version B doesn't' meant that changes got made to standards based on a convincing argument that had never been tried or experienced in practice. The result was that the OSI standards had a lot of stuff in them to avoid issues that weren't issues, and were missing responses to things that actually were issues.
A number of people found the 'code first, standard later' methodology superior for that reason. Assuming that the code was available and unencumbered by patent or licensing restrictions. The latter of course became a much bigger problem when the focus switched to the IETF and the 'big guns' started their usual games.
My first response is then, "open" means anyone can implement and contribute new stuff. And by that definition the web is very open. However, since the community favors a implementation model over a theoretical standards model the 'cost' to influence change is you have to write code, as opposed to making a good argument. And that disenfranchises people without good coding skills.
The second part of this screed is prefaced with this: "And I think even worse has been the wholesale discounting of plugins." Which speaks to the other side effect of "open" as in "we don't make any boundaries we don't have to."
From a mass adoption point of view, the more variability you have in an experience the harder it is to capture the larger audience. This is why cars and motorcycles are all driven in basically the same way, Televisions have 'channels' and 'volume' and browsers have an address bar and bookmarks.
The unification of the structure allows for mass learning and talking in generalizations that remain true without device specific knowledge. Can you imagine how hard it would be to write a driver's code if every vehicle had its own customizable UI and indicators?
So as a technology matures the variability is removed and the common practices are enshrined into the structure.
What that means in a practical sense is that if you're trying to push the envelope in such a mature technology you will face higher and higher resistance. However, you are always allowed to create an entirely new way of doing things.
This isn't the 'dark age' it's the post renaissance start of the industrial revolution. Except instead of widely accessible books we've now got widely accessible information and a de-facto portal for accessing it.
Re: WebKit is the jQuery of Browser Engines
#140Earlier quoted context omitted.
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…
Yahoo uses the YUI library