14 ms·

I Support the WebKit Monoculture

72 points by glenjamin 14y ago

yuchi 14y ago
I think it's a good statement. But I also recognize a dangerous dystopian world with only one render implementation. The competition between Trident/Gecko/Webkit/Presto pushed the web forward, not a single one of them — the whole process has done it. At the same time I do understand from a developer perspective that a single "runtime" would be the Holy Grail at least as much as a single OS. But that's what standard stand for. In the actual situation a vendor can implement things directly in their project, trying to push things forward for its benefit, in contrast to the competitors. If we lose this appeal, will we lose the traction the web has?
- jbrooksuk 14y ago
  > But that's what standard stand for. Except that standards still tend to get implemented differently, which is a massive shame. My life long dream is to develop once, deploy everywhere. We're getting there with libraries such as jQuery and Backbone.js however we're still a long way away from that whilst there are multiple browsers to contend with.
  - rimantas 14y ago
    Thats why folks at whatwg.org spent so much time trying to define how html should be parsed. Alas, that still does not fix the problem with different vendors implementing different parts of the same specification.
    - yuchi 14y ago
      Every vendor has its own needs and priorities. Would we be happy with a single implementation with incomplete support for a spec feature and no other implementation on the table? It's a possible scenario, in a WebKit only world. Don't get me wrong, I love WebKit, I love Chrome, but I also love Gecko AND Presto. They're doing a terrific work that must be rewarded.
  - yuchi 14y ago
    Without any aggressive intent, how could Backbone improve your cross-environment problems? It's just an MVC pattern implementation, it doesn't abstract you from nothing.
    - dmnd 14y ago
      Backbone.Router working on non-pushState browsers is one example.
      - yuchi 14y ago
        _touché_ (You shouldn't resort to hash-bang, btw, it's considered a bad pattern)
        dmnd 14y ago
        Oh, I know. The main reason I'm aware of it is from having to work around and disable it!
        jbrooksuk 14y ago
        Absolutely, exactly.
- pretoriusB 14y ago
  >I think it's a good statement. But I also recognize a dangerous dystopian world with only one render implementation. The competition between Trident/Gecko/Webkit/Presto pushed the web forward, not a single one of them — the whole process has done it. What competition with Trident? Trident was already stagnant when Gecko started. And it's not like Gecko added anything significant. All of them mostly copied Webkit's innovations (canvas, css transformations, a strong push to pass the ACID3 test, JITed javascript engine, etc).
ebassi 14y ago
the usual ridiculous trope that "if only we had a single $PROJECT all the people working on the current competitors would work on $PROJECT instead and everything would be great" is enough to discount this whole lot of drivel.
starik36 14y ago
> Gecko is slow You lost me there. Latest Firefox easily rivals Chrome for both startup and initialization time.
- deleted 14y ago
  [deleted]
- saurabh 14y ago
  I use an AMD 1.6 GHZ powered netbook with 2GB RAM running Arch Linux. Chromium is unbearably slow after opening a few tabs. Firefox chugs along just fine.
  - pekk 14y ago
    I have never seen that on many systems, perhaps Arch has been configured in a strange way.
    - moystard 14y ago
      I have always noted that behavior, Chrome has a better memory management with a few tabs opened, but if you start opening a bunch of them, then Firefox clearly wins the memory battle.
      - mtgx 14y ago
        That's probably because it shares memory between tab processes, since each tab is not in its own sandbox like in Chrome. Personally, I prefer the security of tab sandboxes.
- codinghorror 14y ago
  Yeah, the latest Firefoxes are plenty fast, in both JS and DOM. And for that matter, so is IE10, though they iterate much slower and tend to fall behind over time on that basis.
Xion 14y ago
If one implementation becomes the de facto standard, it only means that the standard is written nowhere. Quirks, peculiarities or even bugs become reference points that web developers need to build upon. The pace of innovation may be greater this way (as it is evident now in Chrome especially) but the long term risk is making the whole notion of independent standard irrelevant. And if that happens, then whoever has the biggest influence over the leading browsing engine will dictate the shape of the Web. Last time this was a single corporation; at least this time it might be two. I don't necessarily think this is very much better.
greggman 14y ago
WebKit recently became slightly less open https://lists.webkit.org/pipermail/webkit-dev/2013-January/023255.html https://lists.webkit.org/pipermail/webkit-dev/2013-January/0...
- makomk 14y ago
  Ouch. Reading that, they're not just making development less open - developers are now allowed to merge code that breaks the build on non-Apple platforms. Worse, in order to merge any changes to non-Apple platform support code, developers have to have their changes approved by "owners" within Apple who have no incentive to review code promptly and no knowledge of the platform in question.
  - josteink 14y ago
    > developers are now allowed to merge code that breaks the build on non-Apple platforms So we can picture OpenWebkit available on github in a week or so then? Seriously: Apple cannot honestly believe this move is going to benefit anyone, can they?
    - ygra 14y ago
      It's benefitting them :-)
deleted 14y ago
[deleted]
deleted 14y ago
[deleted]
nbevans 14y ago
"IE attempted to follow in Microsoft’s Embrace, extend, and extinguish strategy, and that is bad for the web." Attempted and failed. And that was 10 years ago. Why are these WebKit guys always so stuck in the past? Microsoft is very clearly all about embracing the web. More importantly, when will they realise that WebKit-specific CSS styles are bad for the web?
- viseztrance 14y ago
  In my opinion, they're already trapped in a monoculture. The fact is that Github is not the only place where you can host code, nor is a macbook the only machine you can type on. Webkit is just late to the party.
- josteink 14y ago
  Yeah. It's interesting to see people who embrace WebKit-only code right now openly criticize MSIE for the damage it did to the web 10 years ago. WebKit is the new MSIE. And WebKit-only code needs to be shunned the same way we (eventually) shunned MSIE-only code.
potch 14y ago
I work for Mozilla, but I speak for me. Supporting a monoculture is trading future potential in the name of short-term convenience. This doesn't just apply to rendering engines, or even just technology. Wishing you could wave a magic wand and make everyone use the same tools, language, conventions, or coding style is something every engineer wishes from time to time, but the world would be worse off without diversity. Wishing one rendering engine "wins" over the others is a reasonable thing to say, and WebKit is a very fine engine. But the moment we start treating the Web as a zero-sum game and stop collaborating on the vision of a better online experience, nobody wins.
- spiritplumber 14y ago
  Metric system
  - supercoder 14y ago
    Laws of Physics.
  - robotmay 14y ago
    Other measurement systems definitely have their uses though. Many older measurements still exist due to them being easier to estimate with; e.g. an acre being the amount of land you could plow in a day. And you'll never have the British drinking from litre glasses, I'm afraid. It's pints or nothing.
    - nkassis 14y ago
      "an acre being the amount of land you could plow in a day" isn't that an extremely subjective way to measure something? And to almost everyone even modern farmer is that actually a good basis considering a modern farmer can most likely plow much more than an acre in a day with machinery?
      - robotmay 14y ago
        Oh absolutely, if they updated it to be based on modern farming then everyone would have significantly less acreage :D But you'll find that with most imperial measurements; they're based on physical objects or systems of measuring which make less sense today. One of my favourites being the traditional way of counting sheep in the north of England: http://www.fellpony.f9.co.uk/country/wool/count.htm http://www.fellpony.f9.co.uk/country/wool/count.htm (and here's a great explanation and song by the late Jake Thackeray: http://youtu.be/TiXINuf5nbI http://youtu.be/TiXINuf5nbI).
codinghorror 14y ago
In a world of Pepsi and Coke, how can three rendering engines be too many? 1. Trident (IE10+) 2. Gecko (Firefox) 3. WebKit (Safari, Chrome) (Yeah, Opera needs to just.. stop. So sick of all the Opera oddities, combined with their 0.5% market share.) Proposing that there be only one seems very dangerous to me. But as an argument for Opera (and other tiny-market-share) browsers dropping their proprietary engine and switching to either Gecko or WebKit, I'm all for it.
- seivan 14y ago
  Because you aren't wasting resources (developer time) when picking between pepsi and Coke.
  - wolfgke 14y ago
    But you are wasting resources when you use features that are not properly standardized.
    - curlypaul924 14y ago
      Not all features that are standardized are implemented properly on all browsers. This is what uses developer time. It's not terribly different from the situation that exists in the C++ compiler world. Different compiler vendors implement different featuresets. It took many years after the release of the 1997 standard for any compiler to implement it 100%. Is there a compiler out there that implements the current standard completely?
- gmac 14y ago
  I'm intensely relaxed about Opera support. I suspect that the 0.5% people using Opera know what they're doing, and can deal with the odd incompatibility by firing up something else. Opera compatibility is a nice-to-have, but that's it. IE6/7/8 are still a very much bigger problem, because there are still people that for whatever reason (e.g. corporate IT policy, total lack of knowledge) can't upgrade and can't use anything else.
- Jach 14y ago
fulafel 14y ago
> Gecko is old, buggy and slow - at least in comparison to WebKit Is this a widely held view? From an end user perspective Chrome and Firefox feel pretty much neck and nack. Firefox has better memory usage, Chrome JS engine is a little faster. I use both (Chrome on Ubuntu and Firefox on Android).
- efdee 14y ago
  As an end user, based on anecdotal evidence, I can say that: a) on both Windows and Linux, Firefox startup is slower than Chrome b) at least on Windows, Firefox memory usage is far worse than Chrome's c) perceptually, Chrome feels a lot faster than Firefox But yeah. Anecdotal.
  - Thainbbdl 14y ago
    As an end user, i can say that : a) Chrome memory usage is far less than Firefox. try 50+ tab and you'll see. b) Chrome is faster than firefox but it's buggy when you have many tabs c) Mozilla never try to take my personnal data
    - ladzoppelin 14y ago
      Actually this is false. Firefox is loads better when it comes to memory. Chrome is slightly faster but not when Firefox has Noscript installed.
  - klearvue 14y ago
    Depends on the number of tabs one tends to have open. On Ubuntu your (a) and (b) are far worse for me in Chrome than in Firefox (in fact that much worse that I only use Chrome on my 8GB RAM laptop but not on a 4GB one). I agree with (c).
  - lucian1900 14y ago
    Odd, these days Firefox always uses much less memory than Chrome for me.
  - curlypaul924 14y ago
cheeaun 14y ago
Even if WebKit "wins", there'll still be multiple WebKits http://www.quirksmode.org/blog/archives/2009/10/there_is_no_web.html http://www.quirksmode.org/blog/archives/2009/10/there_is_no_...
- Jach 14y ago
  This is an important point. It seems one can never quite escape fragmentation due solely to time moving on, let alone the complexities introduced when targeting multiple pieces of hardware. Reading this article I kept thinking "OpenGL and DirectX". One could argue each has its own monoculture with respect to Windows (or X-Box) and non-Windows OSes, but each monoculture is still fragmented. Windows devs still target DirectX9--initially released over 10 years ago, and the latest DirectX11.1 update will only work with Windows 8. OpenGL is just as bad with the 3.0 flop, issues with the move away from fixed function pipeline concepts, its ES version, and WebGL...
hayksaakian 14y ago
Don't get me started on WebKit fragmentation. Between browsers, webviews, and platforms, it seems like everybody's using a different version of WebKit on mobile. http://www.quirksmode.org/webkit.html http://www.quirksmode.org/webkit.html
dendory 14y ago
This is a silly argument. You cannot force others to use one product. WebKit is great, but it is still a project, governed by some people, and with certain goals. People want to create browsers who may have other goals, so either they have to convince the WebKit team to follow them, or fork, which ends up causing the same problem of multiple platforms. We have open protocols and specifications. The web uses HTML, CSS, etc. Then it's up to the various rendering engines to adhere to those.
things 14y ago
Following that logic, KHTML should have been killed back in the day.
afhof 14y ago
"standardizing on a single rendering engine would go a long way towards unifying the web." I would agree, but I don't think it would be a good thing to do. Sure, if there were only one rendering engine, all of the web would be rendered in the way. That isn't a good thing though. It would commit the web to being Webkit, warts and all, for a very long time. IE is a good example of this, except it is we who brought it upon ourselves as web developers for using IE specific behavior. "One of the core evils behind Internet Explorer is that it is a closed platform." Again, agreed. That said, being closed isn't why we dislike it; its because it has a lot of non standard behavior that people have come to rely on. If the IE source code were to be entirely open sourced tomorrow, how much easier would it be for web developers to work around its idiosyncrasies? I posit that it would still be hard. "Now Gecko is old, buggy and slow - at least in comparison to WebKit." Even if this is true, its only true today. It will eventually get better, leaving this argument irrelevant. This article seems to say that the author disagrees with the "program to interfaces, not implementations" advice. The interface (HTML & CSS) should be how we describe web documents, rather than Webkit's particular implementation of the interface. The author's article seems shortsighted - both forward looking and retrospectively.
- Ygg2 14y ago
  > "Now Gecko is old, buggy and slow - at least in comparison to WebKit." > Even if this is true, its only true today. It will eventually get better, leaving this >argument irrelevant. Even if it is true today, Mozilla is working on Servo (which will hopefully prove to be a success). There isn't a single reason to not develop competing engines. Competition will drive all sides to improve their engines. And standardizing on WebKit is like standardizing Linux (it's just a kernel not overall browser). Slow and very hard, if not down-right impossible. I wish Mozilla all the success in the future but I don't want a monoculture of any engine (Servo/WebKit/Presto/Gecko/<insert engine name> included).
forgottenpaswrd 14y ago
Competition is great. I remember the days in which a group of individuals managed to create a browser(Opera) that used 1Megabyte of memory instead of 40 of Netscape and 80 of IE. As other people said, we need standards, and for standards we need multiple implementations. In my experience creating multi platform code, the best way to multi platform is for the code to work in different platforms from the beginning. I had seen code "designed for multi platform" on a single architecture and over time(gradually slipping) become dependent on a single one, and years later we have people realizing that they can't use the new tech without rewriting the entire codebase, expending millions in the process. The same will happen with a monopoly browser engine, it will gradually slip. In the future we could need to recreate the browser internals from scratch using parallel computers, or with new text handling internals, or someone like old Opera would proof that is possible to do the same with much less, super faster and no battery consumption. who knows?
aichi 14y ago
Haha, is it really your opinion to support browser with most rendering bugs in these days? They are rushing to implement new things but they are not willing to repair old bugs even not to fight with regression. I can say that only good part is V8 engine, others are shit.
kryptiskt 14y ago
While we are wishing for things: I wish there was a fully-featured modern rendering engine written in something other than C++.
- Rooki 14y ago
  Mozilla has a prototype browser written in Rust called Servo which might be worth keeping an eye on: https://github.com/mozilla/servo https://github.com/mozilla/servo
coofluence 14y ago
Will Google open source it's core search engine? That will be good for an open web too :)
wwwtyro 14y ago
> WebKit is open source I think a critical aspect of open source code is that it can be forked. Wouldn't a Webkit monoculture stand in the way of this?
- hmbg 14y ago
  The OP's argument seemed sort of sensible to me until I read this. Ideas need to compete. If it's not Gecko vs Webkit, it'll be Webkit vs other branch of Webkit. Monoculture will only last until "Why don't you accept my pull request, when this is obviously a better way of doing it? Because it's not better. Go fork yourself."
freewizard 14y ago
I'm from China. I support the Communist Party monoculture.
AshleysBrain 14y ago
Isn't the biggest problem that it gives one engine too much power over the web? Like IE in the first browser wars, it could start ignoring the web standards and implementing its own features, which are badly thought out and harmful for the web. For example, with a WebKit monopoly, suppose the WebKit authors introduce `window.badlyThoughtOutFeature()`. It's instantly a de-facto standard, and all future browser makers are obliged to support it for backwards compatibility. With multiple engines, nobody has too much power and can get away with things like that.
tuananh 14y ago
This is more like supporting standard than supporting monoculture. monoculture is bad; standard isn't
josteink 14y ago
The fact that Google has been pushing Chrome only features onto the open web for a long time now, coupled with everyone not running Chrome currently getting ads for it pushed into their face all the time, on all Google-owned services, tells me all I need to know about Google's real stance on web-standards. I think Chrome (in what it has allowed Google to do) has been bad for the web.
- stephenr 14y ago
  I couldn't agree more.
mariusmg 14y ago
"Now Gecko is old, buggy and slow" Fuck off dude. A monoculture is ideologically bad in itself but at least you could come up with some tech args. Saying that basically nullifies the entire thing.
curlypaul924 14y ago
Nothing but FUD (regarding Gecko). Would prefer to read something more objective.
jinushaun 14y ago
I support the monoculture. We wouldn't need vendor prefixes if everyone just ran WebKit to render HTML and CSS. It's free and open source. MS can take the engine now and call it IE 12. New HTML and CSS features would be supported more quickly when everyone is working on the same rendering engine.
general_failure 14y ago
Sorry, but there is this illusion of WebKit being a totally opensource project. This is not true. It is mostly controlled by Apple. Any big decisions need to be "approved" by them. See the recent contribution changes they made about WebKit2 with no consideration for other developers. See how they oppose to any "cleanups" and "refactoring" that doesn't come from them. I am very happy there are other engines like IE and mozilla. It would be very hard to keep html5 and related standards in check without these engines.

72 points by glenjamin 14y ago

yuchi 14y ago

I think it's a good statement. But I also recognize a dangerous dystopian world with only one render implementation. The competition between Trident/Gecko/Webkit/Presto pushed the web forward, not a single one of them — the whole process has done it. At the same time I do understand from a developer perspective that a single "runtime" would be the Holy Grail at least as much as a single OS. But that's what standard stand for. In the actual situation a vendor can implement things directly in their project, trying to push things forward for its benefit, in contrast to the competitors. If we lose this appeal, will we lose the traction the web has?

jbrooksuk 14y ago
> But that's what standard stand for. Except that standards still tend to get implemented differently, which is a massive shame. My life long dream is to develop once, deploy everywhere. We're getting there with libraries such as jQuery and Backbone.js however we're still a long way away from that whilst there are multiple browsers to contend with.
- rimantas 14y ago
  Thats why folks at whatwg.org spent so much time trying to define how html should be parsed. Alas, that still does not fix the problem with different vendors implementing different parts of the same specification.
  - yuchi 14y ago
    Every vendor has its own needs and priorities. Would we be happy with a single implementation with incomplete support for a spec feature and no other implementation on the table? It's a possible scenario, in a WebKit only world. Don't get me wrong, I love WebKit, I love Chrome, but I also love Gecko AND Presto. They're doing a terrific work that must be rewarded.
- yuchi 14y ago
  Without any aggressive intent, how could Backbone improve your cross-environment problems? It's just an MVC pattern implementation, it doesn't abstract you from nothing.
  - dmnd 14y ago
    Backbone.Router working on non-pushState browsers is one example.
    - yuchi 14y ago
      _touché_ (You shouldn't resort to hash-bang, btw, it's considered a bad pattern)
      - dmnd 14y ago
        Oh, I know. The main reason I'm aware of it is from having to work around and disable it!
        jbrooksuk 14y ago
        Absolutely, exactly.
pretoriusB 14y ago
>I think it's a good statement. But I also recognize a dangerous dystopian world with only one render implementation. The competition between Trident/Gecko/Webkit/Presto pushed the web forward, not a single one of them — the whole process has done it. What competition with Trident? Trident was already stagnant when Gecko started. And it's not like Gecko added anything significant. All of them mostly copied Webkit's innovations (canvas, css transformations, a strong push to pass the ACID3 test, JITed javascript engine, etc).

ebassi 14y ago

the usual ridiculous trope that "if only we had a single $PROJECT all the people working on the current competitors would work on $PROJECT instead and everything would be great" is enough to discount this whole lot of drivel.

starik36 14y ago

> Gecko is slow You lost me there. Latest Firefox easily rivals Chrome for both startup and initialization time.

deleted 14y ago
[deleted]
saurabh 14y ago
I use an AMD 1.6 GHZ powered netbook with 2GB RAM running Arch Linux. Chromium is unbearably slow after opening a few tabs. Firefox chugs along just fine.
- pekk 14y ago
  I have never seen that on many systems, perhaps Arch has been configured in a strange way.
  - moystard 14y ago
    I have always noted that behavior, Chrome has a better memory management with a few tabs opened, but if you start opening a bunch of them, then Firefox clearly wins the memory battle.
    - mtgx 14y ago
      That's probably because it shares memory between tab processes, since each tab is not in its own sandbox like in Chrome. Personally, I prefer the security of tab sandboxes.
codinghorror 14y ago
Yeah, the latest Firefoxes are plenty fast, in both JS and DOM. And for that matter, so is IE10, though they iterate much slower and tend to fall behind over time on that basis.

Xion 14y ago

If one implementation becomes the de facto standard, it only means that the standard is written nowhere. Quirks, peculiarities or even bugs become reference points that web developers need to build upon. The pace of innovation may be greater this way (as it is evident now in Chrome especially) but the long term risk is making the whole notion of independent standard irrelevant. And if that happens, then whoever has the biggest influence over the leading browsing engine will dictate the shape of the Web. Last time this was a single corporation; at least this time it might be two. I don't necessarily think this is very much better.

greggman 14y ago

WebKit recently became slightly less open https://lists.webkit.org/pipermail/webkit-dev/2013-January/023255.html https://lists.webkit.org/pipermail/webkit-dev/2013-January/0...

makomk 14y ago
Ouch. Reading that, they're not just making development less open - developers are now allowed to merge code that breaks the build on non-Apple platforms. Worse, in order to merge any changes to non-Apple platform support code, developers have to have their changes approved by "owners" within Apple who have no incentive to review code promptly and no knowledge of the platform in question.
- josteink 14y ago
  > developers are now allowed to merge code that breaks the build on non-Apple platforms So we can picture OpenWebkit available on github in a week or so then? Seriously: Apple cannot honestly believe this move is going to benefit anyone, can they?
  - ygra 14y ago
    It's benefitting them :-)

deleted 14y ago

[deleted]

deleted 14y ago

[deleted]

nbevans 14y ago

"IE attempted to follow in Microsoft’s Embrace, extend, and extinguish strategy, and that is bad for the web." Attempted and failed. And that was 10 years ago. Why are these WebKit guys always so stuck in the past? Microsoft is very clearly all about embracing the web. More importantly, when will they realise that WebKit-specific CSS styles are bad for the web?

viseztrance 14y ago
In my opinion, they're already trapped in a monoculture. The fact is that Github is not the only place where you can host code, nor is a macbook the only machine you can type on. Webkit is just late to the party.
josteink 14y ago
Yeah. It's interesting to see people who embrace WebKit-only code right now openly criticize MSIE for the damage it did to the web 10 years ago. WebKit is the new MSIE. And WebKit-only code needs to be shunned the same way we (eventually) shunned MSIE-only code.

potch 14y ago

I work for Mozilla, but I speak for me. Supporting a monoculture is trading future potential in the name of short-term convenience. This doesn't just apply to rendering engines, or even just technology. Wishing you could wave a magic wand and make everyone use the same tools, language, conventions, or coding style is something every engineer wishes from time to time, but the world would be worse off without diversity. Wishing one rendering engine "wins" over the others is a reasonable thing to say, and WebKit is a very fine engine. But the moment we start treating the Web as a zero-sum game and stop collaborating on the vision of a better online experience, nobody wins.

spiritplumber 14y ago
Metric system
- supercoder 14y ago
  Laws of Physics.
- robotmay 14y ago
  Other measurement systems definitely have their uses though. Many older measurements still exist due to them being easier to estimate with; e.g. an acre being the amount of land you could plow in a day. And you'll never have the British drinking from litre glasses, I'm afraid. It's pints or nothing.
  - nkassis 14y ago
    "an acre being the amount of land you could plow in a day" isn't that an extremely subjective way to measure something? And to almost everyone even modern farmer is that actually a good basis considering a modern farmer can most likely plow much more than an acre in a day with machinery?
    - robotmay 14y ago
      Oh absolutely, if they updated it to be based on modern farming then everyone would have significantly less acreage :D But you'll find that with most imperial measurements; they're based on physical objects or systems of measuring which make less sense today. One of my favourites being the traditional way of counting sheep in the north of England: http://www.fellpony.f9.co.uk/country/wool/count.htm http://www.fellpony.f9.co.uk/country/wool/count.htm (and here's a great explanation and song by the late Jake Thackeray: http://youtu.be/TiXINuf5nbI http://youtu.be/TiXINuf5nbI).

codinghorror 14y ago

In a world of Pepsi and Coke, how can three rendering engines be too many? 1. Trident (IE10+) 2. Gecko (Firefox) 3. WebKit (Safari, Chrome) (Yeah, Opera needs to just.. stop. So sick of all the Opera oddities, combined with their 0.5% market share.) Proposing that there be only one seems very dangerous to me. But as an argument for Opera (and other tiny-market-share) browsers dropping their proprietary engine and switching to either Gecko or WebKit, I'm all for it.

seivan 14y ago
Because you aren't wasting resources (developer time) when picking between pepsi and Coke.
- wolfgke 14y ago
  But you are wasting resources when you use features that are not properly standardized.
  - curlypaul924 14y ago
    Not all features that are standardized are implemented properly on all browsers. This is what uses developer time. It's not terribly different from the situation that exists in the C++ compiler world. Different compiler vendors implement different featuresets. It took many years after the release of the 1997 standard for any compiler to implement it 100%. Is there a compiler out there that implements the current standard completely?
gmac 14y ago
I'm intensely relaxed about Opera support. I suspect that the 0.5% people using Opera know what they're doing, and can deal with the odd incompatibility by firing up something else. Opera compatibility is a nice-to-have, but that's it. IE6/7/8 are still a very much bigger problem, because there are still people that for whatever reason (e.g. corporate IT policy, total lack of knowledge) can't upgrade and can't use anything else.
Jach 14y ago

fulafel 14y ago

> Gecko is old, buggy and slow - at least in comparison to WebKit Is this a widely held view? From an end user perspective Chrome and Firefox feel pretty much neck and nack. Firefox has better memory usage, Chrome JS engine is a little faster. I use both (Chrome on Ubuntu and Firefox on Android).

efdee 14y ago
As an end user, based on anecdotal evidence, I can say that: a) on both Windows and Linux, Firefox startup is slower than Chrome b) at least on Windows, Firefox memory usage is far worse than Chrome's c) perceptually, Chrome feels a lot faster than Firefox But yeah. Anecdotal.
- Thainbbdl 14y ago
  As an end user, i can say that : a) Chrome memory usage is far less than Firefox. try 50+ tab and you'll see. b) Chrome is faster than firefox but it's buggy when you have many tabs c) Mozilla never try to take my personnal data
  - ladzoppelin 14y ago
    Actually this is false. Firefox is loads better when it comes to memory. Chrome is slightly faster but not when Firefox has Noscript installed.
- klearvue 14y ago
  Depends on the number of tabs one tends to have open. On Ubuntu your (a) and (b) are far worse for me in Chrome than in Firefox (in fact that much worse that I only use Chrome on my 8GB RAM laptop but not on a 4GB one). I agree with (c).
- lucian1900 14y ago
  Odd, these days Firefox always uses much less memory than Chrome for me.
- curlypaul924 14y ago

cheeaun 14y ago

Even if WebKit "wins", there'll still be multiple WebKits http://www.quirksmode.org/blog/archives/2009/10/there_is_no_web.html http://www.quirksmode.org/blog/archives/2009/10/there_is_no_...

Jach 14y ago
This is an important point. It seems one can never quite escape fragmentation due solely to time moving on, let alone the complexities introduced when targeting multiple pieces of hardware. Reading this article I kept thinking "OpenGL and DirectX". One could argue each has its own monoculture with respect to Windows (or X-Box) and non-Windows OSes, but each monoculture is still fragmented. Windows devs still target DirectX9--initially released over 10 years ago, and the latest DirectX11.1 update will only work with Windows 8. OpenGL is just as bad with the 3.0 flop, issues with the move away from fixed function pipeline concepts, its ES version, and WebGL...

hayksaakian 14y ago

Don't get me started on WebKit fragmentation. Between browsers, webviews, and platforms, it seems like everybody's using a different version of WebKit on mobile. http://www.quirksmode.org/webkit.html http://www.quirksmode.org/webkit.html

dendory 14y ago

This is a silly argument. You cannot force others to use one product. WebKit is great, but it is still a project, governed by some people, and with certain goals. People want to create browsers who may have other goals, so either they have to convince the WebKit team to follow them, or fork, which ends up causing the same problem of multiple platforms. We have open protocols and specifications. The web uses HTML, CSS, etc. Then it's up to the various rendering engines to adhere to those.

things 14y ago

Following that logic, KHTML should have been killed back in the day.

afhof 14y ago

"standardizing on a single rendering engine would go a long way towards unifying the web." I would agree, but I don't think it would be a good thing to do. Sure, if there were only one rendering engine, all of the web would be rendered in the way. That isn't a good thing though. It would commit the web to being Webkit, warts and all, for a very long time. IE is a good example of this, except it is we who brought it upon ourselves as web developers for using IE specific behavior. "One of the core evils behind Internet Explorer is that it is a closed platform." Again, agreed. That said, being closed isn't why we dislike it; its because it has a lot of non standard behavior that people have come to rely on. If the IE source code were to be entirely open sourced tomorrow, how much easier would it be for web developers to work around its idiosyncrasies? I posit that it would still be hard. "Now Gecko is old, buggy and slow - at least in comparison to WebKit." Even if this is true, its only true today. It will eventually get better, leaving this argument irrelevant. This article seems to say that the author disagrees with the "program to interfaces, not implementations" advice. The interface (HTML & CSS) should be how we describe web documents, rather than Webkit's particular implementation of the interface. The author's article seems shortsighted - both forward looking and retrospectively.

Ygg2 14y ago
> "Now Gecko is old, buggy and slow - at least in comparison to WebKit." > Even if this is true, its only true today. It will eventually get better, leaving this >argument irrelevant. Even if it is true today, Mozilla is working on Servo (which will hopefully prove to be a success). There isn't a single reason to not develop competing engines. Competition will drive all sides to improve their engines. And standardizing on WebKit is like standardizing Linux (it's just a kernel not overall browser). Slow and very hard, if not down-right impossible. I wish Mozilla all the success in the future but I don't want a monoculture of any engine (Servo/WebKit/Presto/Gecko/<insert engine name> included).

forgottenpaswrd 14y ago

Competition is great. I remember the days in which a group of individuals managed to create a browser(Opera) that used 1Megabyte of memory instead of 40 of Netscape and 80 of IE. As other people said, we need standards, and for standards we need multiple implementations. In my experience creating multi platform code, the best way to multi platform is for the code to work in different platforms from the beginning. I had seen code "designed for multi platform" on a single architecture and over time(gradually slipping) become dependent on a single one, and years later we have people realizing that they can't use the new tech without rewriting the entire codebase, expending millions in the process. The same will happen with a monopoly browser engine, it will gradually slip. In the future we could need to recreate the browser internals from scratch using parallel computers, or with new text handling internals, or someone like old Opera would proof that is possible to do the same with much less, super faster and no battery consumption. who knows?

aichi 14y ago

Haha, is it really your opinion to support browser with most rendering bugs in these days? They are rushing to implement new things but they are not willing to repair old bugs even not to fight with regression. I can say that only good part is V8 engine, others are shit.

kryptiskt 14y ago

While we are wishing for things: I wish there was a fully-featured modern rendering engine written in something other than C++.

Rooki 14y ago
Mozilla has a prototype browser written in Rust called Servo which might be worth keeping an eye on: https://github.com/mozilla/servo https://github.com/mozilla/servo

coofluence 14y ago

Will Google open source it's core search engine? That will be good for an open web too :)

wwwtyro 14y ago

> WebKit is open source I think a critical aspect of open source code is that it can be forked. Wouldn't a Webkit monoculture stand in the way of this?

hmbg 14y ago
The OP's argument seemed sort of sensible to me until I read this. Ideas need to compete. If it's not Gecko vs Webkit, it'll be Webkit vs other branch of Webkit. Monoculture will only last until "Why don't you accept my pull request, when this is obviously a better way of doing it? Because it's not better. Go fork yourself."

freewizard 14y ago

I'm from China. I support the Communist Party monoculture.

AshleysBrain 14y ago

Isn't the biggest problem that it gives one engine too much power over the web? Like IE in the first browser wars, it could start ignoring the web standards and implementing its own features, which are badly thought out and harmful for the web. For example, with a WebKit monopoly, suppose the WebKit authors introduce `window.badlyThoughtOutFeature()`. It's instantly a de-facto standard, and all future browser makers are obliged to support it for backwards compatibility. With multiple engines, nobody has too much power and can get away with things like that.

tuananh 14y ago

This is more like supporting standard than supporting monoculture. monoculture is bad; standard isn't

josteink 14y ago

The fact that Google has been pushing Chrome only features onto the open web for a long time now, coupled with everyone not running Chrome currently getting ads for it pushed into their face all the time, on all Google-owned services, tells me all I need to know about Google's real stance on web-standards. I think Chrome (in what it has allowed Google to do) has been bad for the web.

stephenr 14y ago
I couldn't agree more.

mariusmg 14y ago

"Now Gecko is old, buggy and slow" Fuck off dude. A monoculture is ideologically bad in itself but at least you could come up with some tech args. Saying that basically nullifies the entire thing.

curlypaul924 14y ago

Nothing but FUD (regarding Gecko). Would prefer to read something more objective.

jinushaun 14y ago

I support the monoculture. We wouldn't need vendor prefixes if everyone just ran WebKit to render HTML and CSS. It's free and open source. MS can take the engine now and call it IE 12. New HTML and CSS features would be supported more quickly when everyone is working on the same rendering engine.

general_failure 14y ago

Sorry, but there is this illusion of WebKit being a totally opensource project. This is not true. It is mostly controlled by Apple. Any big decisions need to be "approved" by them. See the recent contribution changes they made about WebKit2 with no consideration for other developers. See how they oppose to any "cleanups" and "refactoring" that doesn't come from them. I am very happy there are other engines like IE and mozilla. It would be very hard to keep html5 and related standards in check without these engines.