5 ms·

To be fair Google did happily kill Gears when HTML5 became a viable [early draft] standard.

azakai 12y ago
Agreed, Google did the right thing to remove Gears. My concern is because, overall, Google has a bad track record in this area: FileSystem is still enabled, WebSQL is still enabled, PNaCl is still enabled edit: and H.264 was never removed despite announcing the intent to do so.
- pcwalton 12y ago
  Not to mention not removing H.264 after promising to do so.
  - azakai 12y ago
    Thanks, right, I forgot that one.
- hammerandtongs 12y ago
  websql is so much nicer then the key/val firefox insisted on :(
  - thristian 12y ago
    WebSQL is nicer to use, but requiring every browser to be bug-for-bug compatible with SQLite 3.0.17 (or whatever it was) forever and ever is not nice for browser developers.
- kllrnohj 12y ago
  > PNaCl is still enabled Eh? What is the spec competitor to PNaCl? asm.js is a cute trick but it still lacks threads which is easily one of the biggest features of PNaCl. So what actual viable alternatives are there to PNaCl?
  - azakai 12y ago
    We can discuss alternatives to PNaCl, but that isn't really the issue. Even if you have something you believe has no peer at the moment, that doesn't mean you can ship it without regards for the the standards process. It's still wrong for all the usual reasons. Of course, not having a good alternative might mean that the other parties in the standards process should take another look at it. But again, that's a totally separate issue from whether it is ok to just ignore the standards process and ship whatever you want, which is what Google is doing here.
    - desdiv 12y ago
      But again, that's a totally separate issue from whether it is ok to just ignore the standards process and ship whatever you want, which is what Google is doing here. But isn't that exactly what happened with SPDY? They shipped it unilaterally first, then later on it got standardized as HTTP2.
      - azakai 12y ago
        I don't think it's the same. SPDY initially began inside Google. But rather quickly it got enthusiastic interest from multiple outside parties, and a standardization process began. We can see the (successful) end of that process now. Yes, it's true that many standards begin that way. PNaCl also began inside Google. Discussions regarding it, and the PPAPI on which it depends, were a combination of opposition (e.g. because PPAPI duplicates existing web APIs, and because it's a plugin API, which browsers are trying to move away from) to ignoring. Google continued to work on it, enabled it on the Chrome Web Store, and despite any change in the response of the community over a period of years, enabled it for web content. Over a year has passed since then, and it seems clear that (1) no browser outside Google thinks PNaCl is a good idea, and (2) no significant interest has been shown from non-browser vendors either (Google itself is the main user of PNaCl). Also, to make things even worse, during all that time, PNaCl has not been brought to any standards body. Another large difference is that, in practice, SPDY didn't pose a compatibility threat to the web. It has clear fallbacks so that content still works without browser support for it. And while it is possible bugs could still cause breakage, it didn't happen in practice. So moving forward somewhat quickly with SPDY was still arguably a responsible thing to do. Whereas, PNaCl is already showing fragmentation problems, with several Google properties using PNaCl and consequently only working in Chrome. There is therefore every reason for Google to disable PNaCl, because it is nonstandard and bad for the web to keep it on. Unless Google simply does not care about standardization here.

Agreed, Google did the right thing to remove Gears. My concern is because, overall, Google has a bad track record in this area: FileSystem is still enabled, WebSQL is still enabled, PNaCl is still enabled edit: and H.264 was never removed despite announcing the intent to do so.

pcwalton 12y ago
Not to mention not removing H.264 after promising to do so.
- azakai 12y ago
  Thanks, right, I forgot that one.
hammerandtongs 12y ago
websql is so much nicer then the key/val firefox insisted on :(
- thristian 12y ago
  WebSQL is nicer to use, but requiring every browser to be bug-for-bug compatible with SQLite 3.0.17 (or whatever it was) forever and ever is not nice for browser developers.
kllrnohj 12y ago
> PNaCl is still enabled Eh? What is the spec competitor to PNaCl? asm.js is a cute trick but it still lacks threads which is easily one of the biggest features of PNaCl. So what actual viable alternatives are there to PNaCl?
- azakai 12y ago
  We can discuss alternatives to PNaCl, but that isn't really the issue. Even if you have something you believe has no peer at the moment, that doesn't mean you can ship it without regards for the the standards process. It's still wrong for all the usual reasons. Of course, not having a good alternative might mean that the other parties in the standards process should take another look at it. But again, that's a totally separate issue from whether it is ok to just ignore the standards process and ship whatever you want, which is what Google is doing here.
  - desdiv 12y ago
    But again, that's a totally separate issue from whether it is ok to just ignore the standards process and ship whatever you want, which is what Google is doing here. But isn't that exactly what happened with SPDY? They shipped it unilaterally first, then later on it got standardized as HTTP2.
    - azakai 12y ago
      I don't think it's the same. SPDY initially began inside Google. But rather quickly it got enthusiastic interest from multiple outside parties, and a standardization process began. We can see the (successful) end of that process now. Yes, it's true that many standards begin that way. PNaCl also began inside Google. Discussions regarding it, and the PPAPI on which it depends, were a combination of opposition (e.g. because PPAPI duplicates existing web APIs, and because it's a plugin API, which browsers are trying to move away from) to ignoring. Google continued to work on it, enabled it on the Chrome Web Store, and despite any change in the response of the community over a period of years, enabled it for web content. Over a year has passed since then, and it seems clear that (1) no browser outside Google thinks PNaCl is a good idea, and (2) no significant interest has been shown from non-browser vendors either (Google itself is the main user of PNaCl). Also, to make things even worse, during all that time, PNaCl has not been brought to any standards body. Another large difference is that, in practice, SPDY didn't pose a compatibility threat to the web. It has clear fallbacks so that content still works without browser support for it. And while it is possible bugs could still cause breakage, it didn't happen in practice. So moving forward somewhat quickly with SPDY was still arguably a responsible thing to do. Whereas, PNaCl is already showing fragmentation problems, with several Google properties using PNaCl and consequently only working in Chrome. There is therefore every reason for Google to disable PNaCl, because it is nonstandard and bad for the web to keep it on. Unless Google simply does not care about standardization here.