7 ms·

It constantly amazes me how many people do not understand this. So many web standards advocates will cry foul the moment any vendor tries something out that ha

It constantly amazes me how many people do not understand this. So many web standards advocates will cry foul the moment any vendor tries something out that has not already been standardized. Even Brendan Eich cried foul about Dart even though JavaScript was out in the wild for a year before Netscape even submitted it to a standards body. Committees are not the right process for innovation. 10 years of overly complicated and unneeded standards from W3C should have taught us this.

ootachi 15y ago
Brendan Eich cried foul about Dart because other browser manufacturers, and web developers themselves, said they didn't want it, and Google did it anyway.
- haberman 15y ago
  I was unaware that a poll had been taken of all web developers asking whether they wanted Dart. If developers really don't want it, they'll vote with their feet, so what's the big issue? Also: > The big issue I have with Dart, which you > seem to consider inconsequential, is whether > Google forks the web developer community, > not just its own paid developers, with Dart, > and thereby fragments web content. > > "A Dart to JS compiler will never be "decent" > compared to having the Dart VM in the browser. > Yet I guarantee you that Apple and Microsoft > (and Opera and Mozilla, but the first two are > enough) will never embed the Dart VM. > > "So "Works best in Chrome" and even "Works only > in Chrome" are new norms promulgated intentionally > by Google. We see more of this fragmentation > every day. As a user of Chrome and Firefox (and > Safari), I find it painful to experience, never > mind the political bad taste. > > Ok, counter-arguments. What's wrong with playing > hardball to advance the web, you say? As my blog > tries to explain, the standards process requires > good social relations and philosophical balance > among the participating competitors." --Brendan Eich, http://news.ycombinator.com/item?id=2982949 http://news.ycombinator.com/item?id=2982949 Basically he's arguing that the browser vendors of today (not developers/users) are the gatekeepers of what new technologies can be tried. It's like making browser innovation a UN Security Council where every member has a veto over doing anything. If you value progress and innovation, I do not see how you can support such a position. If Google introduces something like Dart or NaCl, is willing to support standardization of it and even release a free implementation, but other browser vendors don't want to integrate it because they don't like it, that's their problem, not Google's. If that means popular apps become "Works best in Chrome," that is a self-inflicted wound.
  - mbrubeck 15y ago
    "Basically he's arguing that the browser vendors of today (not developers/users) are the gatekeepers of what new technologies can be tried." Anyone's free to try things. But those things will never become a part of the web platform if other vendors don't think they will benefit from implementing them. The people who make the browsers are gatekeepers of what ends up in the browsers. That's not a statement about how things should or shouldn't be; it's just a tautology. The job of anyone who wants to create a web standard is to accept that fact, not ignore it. Ignoring it leads to single-browser "standards", which may get adopted by developers but will not become part of the open, interoperable web platform.
    - tptacek 15y ago
      What are the things Webkit has "proposed" by releasing builds that you don't think should be part of the web platform? And, what are the things Webkit has built that were "overridden" by the standards process? Where did Webkit actually get things wrong? Just what comes to your mind.
      - mbrubeck 15y ago
        First of all, I don't want to come off as argumentative. I think we agree on the fundamentals: Implementation should come before standardization. Vendors should feel free to experiment. The W3C should focus more on quickly standardizing things that are already working in the field. Today, experimental and prefixed features used in the wild are creating real problems for interoperability and competition. But I don't think there's a villain here, and I'm not blaming WebKit. Both the browser vendors and the W3C are using processes that were designed to certain solve problems. Now those processes are creating new problems and might need to change in response. But, to answer your direct question (although I think this is getting on a tangent from the original post): > "What are the things Webkit has "proposed" by releasing builds that you don't think should be part of the web platform?" Dart is an example of something that Google has proposed (not "WebKit" as a group) that I and many others - even others like Oliver Hunt within the WebKit community - do not think benefits the web platform. Some people would put Web SQL Database in this category; I don't have an informed opinion about that one. (Though I do know it's the reasons some versions of Gmail wouldn't even load in mobile Firefox.) > "Where did Webkit actually get things wrong?" Apple's "meta viewport" tag is something that they released in Safari and evangelized to developers without specifying it or getting community feedback. I had the pleasure of reverse-engineering it for Gecko. Among other things, it's not even implemented in a layer where it makes sense. (It should be part of style, not markup.) Apple never proposed it as a standard; other people eventually did and are trying to fix some of the problems. Unfortunately, the basic design is locked in by legacy content (and has been since soon after Apple shipped this feature in the first release of mobile Safari). But frankly, I don't care so much whether they get things "right" or "wrong." As bad as meta-viewport is, at least Firefox and Opera and Android and IE can implement support for it without controversy, and be compatible with sites that use it. The way that prefixed CSS properties are (a) released to market by browser vendors, (b) evangelized to web developers, and (c) deployed on production web sites is creating a situation where new browsers are either locked out of existing sites or have to implement each others' prefixes. This is not a stable equilibrium.
- batista 15y ago
  I am a web developer and I very much want it. I don't want Javascript to be the only game in town for front end programming. But this is beside the point: Eich never asked if web developers want it or not.
mbrubeck 15y ago
"So many web standards advocates will cry foul the moment any vendor tries something out that has not already been standardized." While some misinformed people might make this argument, I don't think you'll find anyone making it at Mozilla or other groups that actually participate in web standards development. We all know that the normal process is to implement first and then standardize. That's what Mozilla has done in the past with features like Geolocation and WebGL, and it's what we're doing today with new work like Audio Data, Game Pad, and Telephony. In fact, the W3C process requires two interoperable implementations before a specification can reach the Recommendation stage. But there's a difference between a standard that is developed in the open, with the opportunity for all parties to provide feedback and influence development, and one that is developed and implemented in secret, and then deployed to production browsers and evangelized to content authors before anyone else has a chance to comment on it -- or even on whether the fundamental approach is a good idea. (And obviously these are two extreme ends of a spectrum, with a lot of gray area between them.) The problem with many of Apple's "contributions" (and some of Google's) is that they never write specs for them or bring them to standards bodies. (This is the case for Aplle's -webkit-text-size-adjust.) In some cases they actively fight efforts to standardize them. (This is the case with Apple's touch events.) Or sometimes they do push specs to standards bodies, but only after a highly complex specification has been fully developed behind closed doors. (Google's Dart, NaCL, and Pepper have this problem to some extent.) That's fine if what they really want is a proprietary ecosystem that works in their own browsers. But if they actually want these efforts to be part of the web, and if they want to be seen as stewards of an open web, then just implementing something is not enough. The web has lots of stakeholders, and the initial implementer needs to find a way to bring them to the table.
- haberman 15y ago
  mbrubeck and I, who are good friends IRL, just had a spirited discussion about this over IM; I'll just repeat a few of my points here for other readers. :) NaCl was first announced in 2008, along with a research paper and and source code (http://googlecode.blogspot.com/2008/12/native-client-technology-for-running.html http://googlecode.blogspot.com/2008/12/native-client-technol...). The next year Google sponsored the NativeClient Security Contest that awarded prizes to security researchers who could break out of the sandbox. A lot of the design surrounding PNaCl has happened in the open (see http://www.chromium.org/nativeclient/pnacl http://www.chromium.org/nativeclient/pnacl). I don't think it's accurate to say that NaCl was developed behind closed doors. Also, other browser vendors seem to oppose NaCl in principle, and it seems unlikely that any other process Google could have taken to get buy-in would have resulted in other browsers accepting it. I agree that there is a continuum of behavior here; in the NaCl case in particular though, it really seems like Google has done the right thing.
cageface 15y ago
I'd go further than that. I think the era of the technology standard as a formally specified, committee-managed, cross-platform entity is coming to an end. What we're seeing instead is the emergence of open-source implementations that are themselves the de-facto standard. This is particularly true of languages. Look how Apple has managed to run circles around the C++ committee in their single stewardship of Obj-C. Or think how ridiculous it sounds to think of a "standard" definition of Python or Ruby.
- fpgeek 15y ago
  If it is true that we have moved past the era of formal standards, we will have lost something that is important. More important than most people understand. If a technology has only implementation, even an open source implementation, that implementation will have all sorts of hidden assumptions and biases. No one will know about or understand those assumptions and biases until the time comes to use that technology in a new context. In my work, I've dealt with multiple implementations of things like simulators, models and even languages. The additional implementations usually had some specific reason behind them (performance, alternative features, supporting different execution environments, different mathematical properties and so on). Nevertheless, the value of each alternative implementation (in terms of surfacing hidden assumptions, finding bugs, illuminating more general and flexible alternatives, etc.) went well beyond the specific reason that implementation was made. These considerations are even more important in the case of software that is part of a large, chaotic, heterogeneous system like the Web. Imagine where the mobile web would be today if there hadn't been a W3C and, at the turn of the century, the Web really had been "what Internet Explorer renders" with no attempt to document and codify anything else. Or, to take your example of Objective C, how much does Objective C matter outside of Apple's ecosystem? Contrast this with: - How much does JavaScript matter outside of Netscape's ecosystem? - How much does Java matters outside of Sun's? - Or, to take the granddaddy of examples, how much does C matter off of the PDP-11 and outside of Bell Labs? None of those languages would be anywhere near where they are today without standards. On the other side of the coin, there is a reason languages like Python, Ruby and Haskell have had (and, each to a varying extent, continue to have) a "bus problem". Standards matter and even just the standardization process itself matters. I wish more people understood that.

ootachi 15y ago

Brendan Eich cried foul about Dart because other browser manufacturers, and web developers themselves, said they didn't want it, and Google did it anyway.

haberman 15y ago
I was unaware that a poll had been taken of all web developers asking whether they wanted Dart. If developers really don't want it, they'll vote with their feet, so what's the big issue? Also: > The big issue I have with Dart, which you > seem to consider inconsequential, is whether > Google forks the web developer community, > not just its own paid developers, with Dart, > and thereby fragments web content. > > "A Dart to JS compiler will never be "decent" > compared to having the Dart VM in the browser. > Yet I guarantee you that Apple and Microsoft > (and Opera and Mozilla, but the first two are > enough) will never embed the Dart VM. > > "So "Works best in Chrome" and even "Works only > in Chrome" are new norms promulgated intentionally > by Google. We see more of this fragmentation > every day. As a user of Chrome and Firefox (and > Safari), I find it painful to experience, never > mind the political bad taste. > > Ok, counter-arguments. What's wrong with playing > hardball to advance the web, you say? As my blog > tries to explain, the standards process requires > good social relations and philosophical balance > among the participating competitors." --Brendan Eich, http://news.ycombinator.com/item?id=2982949 http://news.ycombinator.com/item?id=2982949 Basically he's arguing that the browser vendors of today (not developers/users) are the gatekeepers of what new technologies can be tried. It's like making browser innovation a UN Security Council where every member has a veto over doing anything. If you value progress and innovation, I do not see how you can support such a position. If Google introduces something like Dart or NaCl, is willing to support standardization of it and even release a free implementation, but other browser vendors don't want to integrate it because they don't like it, that's their problem, not Google's. If that means popular apps become "Works best in Chrome," that is a self-inflicted wound.
- mbrubeck 15y ago
  "Basically he's arguing that the browser vendors of today (not developers/users) are the gatekeepers of what new technologies can be tried." Anyone's free to try things. But those things will never become a part of the web platform if other vendors don't think they will benefit from implementing them. The people who make the browsers are gatekeepers of what ends up in the browsers. That's not a statement about how things should or shouldn't be; it's just a tautology. The job of anyone who wants to create a web standard is to accept that fact, not ignore it. Ignoring it leads to single-browser "standards", which may get adopted by developers but will not become part of the open, interoperable web platform.
  - tptacek 15y ago
    What are the things Webkit has "proposed" by releasing builds that you don't think should be part of the web platform? And, what are the things Webkit has built that were "overridden" by the standards process? Where did Webkit actually get things wrong? Just what comes to your mind.
    - mbrubeck 15y ago
      First of all, I don't want to come off as argumentative. I think we agree on the fundamentals: Implementation should come before standardization. Vendors should feel free to experiment. The W3C should focus more on quickly standardizing things that are already working in the field. Today, experimental and prefixed features used in the wild are creating real problems for interoperability and competition. But I don't think there's a villain here, and I'm not blaming WebKit. Both the browser vendors and the W3C are using processes that were designed to certain solve problems. Now those processes are creating new problems and might need to change in response. But, to answer your direct question (although I think this is getting on a tangent from the original post): > "What are the things Webkit has "proposed" by releasing builds that you don't think should be part of the web platform?" Dart is an example of something that Google has proposed (not "WebKit" as a group) that I and many others - even others like Oliver Hunt within the WebKit community - do not think benefits the web platform. Some people would put Web SQL Database in this category; I don't have an informed opinion about that one. (Though I do know it's the reasons some versions of Gmail wouldn't even load in mobile Firefox.) > "Where did Webkit actually get things wrong?" Apple's "meta viewport" tag is something that they released in Safari and evangelized to developers without specifying it or getting community feedback. I had the pleasure of reverse-engineering it for Gecko. Among other things, it's not even implemented in a layer where it makes sense. (It should be part of style, not markup.) Apple never proposed it as a standard; other people eventually did and are trying to fix some of the problems. Unfortunately, the basic design is locked in by legacy content (and has been since soon after Apple shipped this feature in the first release of mobile Safari). But frankly, I don't care so much whether they get things "right" or "wrong." As bad as meta-viewport is, at least Firefox and Opera and Android and IE can implement support for it without controversy, and be compatible with sites that use it. The way that prefixed CSS properties are (a) released to market by browser vendors, (b) evangelized to web developers, and (c) deployed on production web sites is creating a situation where new browsers are either locked out of existing sites or have to implement each others' prefixes. This is not a stable equilibrium.
batista 15y ago
I am a web developer and I very much want it. I don't want Javascript to be the only game in town for front end programming. But this is beside the point: Eich never asked if web developers want it or not.

mbrubeck 15y ago

"So many web standards advocates will cry foul the moment any vendor tries something out that has not already been standardized." While some misinformed people might make this argument, I don't think you'll find anyone making it at Mozilla or other groups that actually participate in web standards development. We all know that the normal process is to implement first and then standardize. That's what Mozilla has done in the past with features like Geolocation and WebGL, and it's what we're doing today with new work like Audio Data, Game Pad, and Telephony. In fact, the W3C process requires two interoperable implementations before a specification can reach the Recommendation stage. But there's a difference between a standard that is developed in the open, with the opportunity for all parties to provide feedback and influence development, and one that is developed and implemented in secret, and then deployed to production browsers and evangelized to content authors before anyone else has a chance to comment on it -- or even on whether the fundamental approach is a good idea. (And obviously these are two extreme ends of a spectrum, with a lot of gray area between them.) The problem with many of Apple's "contributions" (and some of Google's) is that they never write specs for them or bring them to standards bodies. (This is the case for Aplle's -webkit-text-size-adjust.) In some cases they actively fight efforts to standardize them. (This is the case with Apple's touch events.) Or sometimes they do push specs to standards bodies, but only after a highly complex specification has been fully developed behind closed doors. (Google's Dart, NaCL, and Pepper have this problem to some extent.) That's fine if what they really want is a proprietary ecosystem that works in their own browsers. But if they actually want these efforts to be part of the web, and if they want to be seen as stewards of an open web, then just implementing something is not enough. The web has lots of stakeholders, and the initial implementer needs to find a way to bring them to the table.

haberman 15y ago
mbrubeck and I, who are good friends IRL, just had a spirited discussion about this over IM; I'll just repeat a few of my points here for other readers. :) NaCl was first announced in 2008, along with a research paper and and source code (http://googlecode.blogspot.com/2008/12/native-client-technology-for-running.html http://googlecode.blogspot.com/2008/12/native-client-technol...). The next year Google sponsored the NativeClient Security Contest that awarded prizes to security researchers who could break out of the sandbox. A lot of the design surrounding PNaCl has happened in the open (see http://www.chromium.org/nativeclient/pnacl http://www.chromium.org/nativeclient/pnacl). I don't think it's accurate to say that NaCl was developed behind closed doors. Also, other browser vendors seem to oppose NaCl in principle, and it seems unlikely that any other process Google could have taken to get buy-in would have resulted in other browsers accepting it. I agree that there is a continuum of behavior here; in the NaCl case in particular though, it really seems like Google has done the right thing.

cageface 15y ago

I'd go further than that. I think the era of the technology standard as a formally specified, committee-managed, cross-platform entity is coming to an end. What we're seeing instead is the emergence of open-source implementations that are themselves the de-facto standard. This is particularly true of languages. Look how Apple has managed to run circles around the C++ committee in their single stewardship of Obj-C. Or think how ridiculous it sounds to think of a "standard" definition of Python or Ruby.

fpgeek 15y ago
If it is true that we have moved past the era of formal standards, we will have lost something that is important. More important than most people understand. If a technology has only implementation, even an open source implementation, that implementation will have all sorts of hidden assumptions and biases. No one will know about or understand those assumptions and biases until the time comes to use that technology in a new context. In my work, I've dealt with multiple implementations of things like simulators, models and even languages. The additional implementations usually had some specific reason behind them (performance, alternative features, supporting different execution environments, different mathematical properties and so on). Nevertheless, the value of each alternative implementation (in terms of surfacing hidden assumptions, finding bugs, illuminating more general and flexible alternatives, etc.) went well beyond the specific reason that implementation was made. These considerations are even more important in the case of software that is part of a large, chaotic, heterogeneous system like the Web. Imagine where the mobile web would be today if there hadn't been a W3C and, at the turn of the century, the Web really had been "what Internet Explorer renders" with no attempt to document and codify anything else. Or, to take your example of Objective C, how much does Objective C matter outside of Apple's ecosystem? Contrast this with: - How much does JavaScript matter outside of Netscape's ecosystem? - How much does Java matters outside of Sun's? - Or, to take the granddaddy of examples, how much does C matter off of the PDP-11 and outside of Bell Labs? None of those languages would be anywhere near where they are today without standards. On the other side of the coin, there is a reason languages like Python, Ruby and Haskell have had (and, each to a varying extent, continue to have) a "bus problem". Standards matter and even just the standardization process itself matters. I wish more people understood that.