5 ms·

One of the fun differences between the Chrome and IE FUD is that the former is based upon "but what if!?!?!" (usually ignoring that there is effectively zero lo

One of the fun differences between the Chrome and IE FUD is that the former is based upon "but what if!?!?!" (usually ignoring that there is effectively zero lock-in, everything is standardized and open, etc), while the latter is based upon what actually happened. That you mention the news from yesterday, and report on some cynical, nonsensical comments as if they are fact is a perfect example. I want to be cynical about Google and Chrome. But thus far I have absolutely nothing to actually criticize them on. They literally have kept the web alive, and their attempts to try to clear up the advertising market is yet another example. Or just be cynical about it while everyone migrates to apps.

pcwalton 10y ago
NaCl and Dart are things that actually happened. They were decidedly not standardized.
- endorphone 10y ago
  Dart - ECMA-408. Open and standard. BSD grant, etc. NaCL - Completely open, patent grants, open source, etc. Not a standard, but they did everything possible to move there, and abandoned it when it didn't get interest from others. Anything else?
  - pcwalton 10y ago
    Dart and NaCl actively ignored outside feedback, even when in retrospect the feedback was clearly correct. Few Web developers wanted Dart, and this was clear at the time Google went to ECMA. They pushed ahead with a standard anyway despite no other browser vendor signing on board. You can call anything a standard, but without a multi-vendor process, and with only a single implementation, the idea of a standard is pretty meaningless. And, regarding Dart, on the WebKit side, many WebKit contributors were (quite reasonably) opposed to adding support for pluggable languages to the DOM, because of the unavoidable overheads introduced by this. As far as I recall, no solution to the problem of cross-language GC, which is one of the biggest issues here, had been even really proposed at the time. Google continued on ahead, forking WebKit into Blink, introducing Dartium, and then ending the project. Now, with Dartium dead, it has become clear in retrospect that the WebKit community was right all along: you don't want multiple incompatible languages hooked up to the DOM. NaCl may have been "open" in that Chromium was open source, but the dependency on Pepper meant that Google's implementation was Chrome-only. Google solicited feedback on Pepper back in 2010, but Apple and Mozilla engineers provided compelling arguments as to why Pepper was unnecessary. They ignored the feedback and did it anyway. Now, after seven years, NaCl is obsolete in favor of the multi-vendor Web Assembly, which uses the Web APIs instead of Pepper—exactly the approach that everyone else on the plugin-futures mailing list had advocated in the first place. A lot of unnecessary work would have been avoided if NaCl and Dart had been more receptive to feedback.
    - markdog12 10y ago
      > Few Web developers wanted Dart Do you just mean they didn't want the dart vm in browsers? Or the language? If the latter as well, I respectfully disagree. > Dart actively ignored outside feedback Again, on the language or just having the vm in browsers?
      - pcwalton 10y ago
        Few developers wanted either the language or the native support in browsers. Witness the success of e.g. TypeScript compared to Dart. There were plenty of issues in the Dart language, too. The way generics variance was deliberately unsound was bizarre, in particular, and they resisted attempts to fix it.
        markdog12 10y ago
        As I'm sure you're aware, the better language doesn't always win the popularity contest. Typescript, being a superset of js still has a lot of its warts. Dart is more of a clean break.
bzbarsky 10y ago
There's zero lock-in unless you want to use Hangouts. Or Google Earth. Or Inbox. Not everything is standardized, sadly. Even the things that are ... well, https://bugs.chromium.org/p/chromium/issues/detail?id=690195 https://bugs.chromium.org/p/chromium/issues/detail?id=690195 is an example from just earlier today where Chrome went to implement a spec, decided what the spec said was not convenient, and just implemented something else without bothering to raise a spec issue or anything. See https://github.com/whatwg/html/issues/2568 https://github.com/whatwg/html/issues/2568 for the resulting lack of interop that the standards now have to sort out. This doesn't always happen, of course, but it happens often enough. Anyway, the Chrome team itself is, by and large, pretty good to work with (some exceptions like their "let's force-install this on unwitting users' computers" marketing deals notwithstanding). Other parts of Google are very much less great. Getting Gmail to work with your browser unless you spoof the UA string of some other existing browser is an exercise in futility.
- sangnoir 10y ago
  > There's zero lock-in unless you want to use Hangouts. Or Google Earth. Or Inbox. That's not really Chrome's fault - it's the fault of the respective (Hangouts, Earth, Inbox) product teams. We didn't blame Microsoft for "lock-in" back in the IE-only website days, I think it would be fair to give Google that latitude unless you are ascribing nefarious motives above and beyond what lazy/resource-constrained web devs used to do with IE6-only web sites/apps.
  - yesbabyyes 10y ago
    wat
  - pdkl95 10y ago
    > We didn't blame Microsoft for "lock-in" back in the IE-only website days Yes, we did. Very loudly and very frequently. So loudly and frequently that the company was charged with violating the Sherman Antitrust Act. The expression "embrace, extend, extinguish"[1] was first used to describe Microsoft's attempt to "lock-in" the WWW. Introducing incompatibilities into IE and proprietary extensions (ActiveX, which Google is copying with NaCL) allowed make a show of embracing open standards as bait for the lock-in. This isn't theoretical - in Bill Gates's own words[2]: >> "One thing we have got to change in our strategy--allowing Office documents to be rendered very well by other peoples [sic] browsers is one of the most destructive things we could do to the company. We have to stop putting any effort into this and make sure that Office documents very well depends on PROPRIETARY IE capabilities. Anything else is suicide for our platform." [1] https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish [2] (pdf) http://antitrust.slated.org/www.iowaconsumercase.org/011607/2000/PX02991.pdf http://antitrust.slated.org/www.iowaconsumercase.org/011607/...

pcwalton 10y ago

NaCl and Dart are things that actually happened. They were decidedly not standardized.

endorphone 10y ago
Dart - ECMA-408. Open and standard. BSD grant, etc. NaCL - Completely open, patent grants, open source, etc. Not a standard, but they did everything possible to move there, and abandoned it when it didn't get interest from others. Anything else?
- pcwalton 10y ago
  Dart and NaCl actively ignored outside feedback, even when in retrospect the feedback was clearly correct. Few Web developers wanted Dart, and this was clear at the time Google went to ECMA. They pushed ahead with a standard anyway despite no other browser vendor signing on board. You can call anything a standard, but without a multi-vendor process, and with only a single implementation, the idea of a standard is pretty meaningless. And, regarding Dart, on the WebKit side, many WebKit contributors were (quite reasonably) opposed to adding support for pluggable languages to the DOM, because of the unavoidable overheads introduced by this. As far as I recall, no solution to the problem of cross-language GC, which is one of the biggest issues here, had been even really proposed at the time. Google continued on ahead, forking WebKit into Blink, introducing Dartium, and then ending the project. Now, with Dartium dead, it has become clear in retrospect that the WebKit community was right all along: you don't want multiple incompatible languages hooked up to the DOM. NaCl may have been "open" in that Chromium was open source, but the dependency on Pepper meant that Google's implementation was Chrome-only. Google solicited feedback on Pepper back in 2010, but Apple and Mozilla engineers provided compelling arguments as to why Pepper was unnecessary. They ignored the feedback and did it anyway. Now, after seven years, NaCl is obsolete in favor of the multi-vendor Web Assembly, which uses the Web APIs instead of Pepper—exactly the approach that everyone else on the plugin-futures mailing list had advocated in the first place. A lot of unnecessary work would have been avoided if NaCl and Dart had been more receptive to feedback.
  - markdog12 10y ago
    > Few Web developers wanted Dart Do you just mean they didn't want the dart vm in browsers? Or the language? If the latter as well, I respectfully disagree. > Dart actively ignored outside feedback Again, on the language or just having the vm in browsers?
    - pcwalton 10y ago
      Few developers wanted either the language or the native support in browsers. Witness the success of e.g. TypeScript compared to Dart. There were plenty of issues in the Dart language, too. The way generics variance was deliberately unsound was bizarre, in particular, and they resisted attempts to fix it.
      - markdog12 10y ago
        As I'm sure you're aware, the better language doesn't always win the popularity contest. Typescript, being a superset of js still has a lot of its warts. Dart is more of a clean break.

bzbarsky 10y ago

There's zero lock-in unless you want to use Hangouts. Or Google Earth. Or Inbox. Not everything is standardized, sadly. Even the things that are ... well, https://bugs.chromium.org/p/chromium/issues/detail?id=690195 https://bugs.chromium.org/p/chromium/issues/detail?id=690195 is an example from just earlier today where Chrome went to implement a spec, decided what the spec said was not convenient, and just implemented something else without bothering to raise a spec issue or anything. See https://github.com/whatwg/html/issues/2568 https://github.com/whatwg/html/issues/2568 for the resulting lack of interop that the standards now have to sort out. This doesn't always happen, of course, but it happens often enough. Anyway, the Chrome team itself is, by and large, pretty good to work with (some exceptions like their "let's force-install this on unwitting users' computers" marketing deals notwithstanding). Other parts of Google are very much less great. Getting Gmail to work with your browser unless you spoof the UA string of some other existing browser is an exercise in futility.

sangnoir 10y ago
> There's zero lock-in unless you want to use Hangouts. Or Google Earth. Or Inbox. That's not really Chrome's fault - it's the fault of the respective (Hangouts, Earth, Inbox) product teams. We didn't blame Microsoft for "lock-in" back in the IE-only website days, I think it would be fair to give Google that latitude unless you are ascribing nefarious motives above and beyond what lazy/resource-constrained web devs used to do with IE6-only web sites/apps.
- yesbabyyes 10y ago
  wat
- pdkl95 10y ago
  > We didn't blame Microsoft for "lock-in" back in the IE-only website days Yes, we did. Very loudly and very frequently. So loudly and frequently that the company was charged with violating the Sherman Antitrust Act. The expression "embrace, extend, extinguish"[1] was first used to describe Microsoft's attempt to "lock-in" the WWW. Introducing incompatibilities into IE and proprietary extensions (ActiveX, which Google is copying with NaCL) allowed make a show of embracing open standards as bait for the lock-in. This isn't theoretical - in Bill Gates's own words[2]: >> "One thing we have got to change in our strategy--allowing Office documents to be rendered very well by other peoples [sic] browsers is one of the most destructive things we could do to the company. We have to stop putting any effort into this and make sure that Office documents very well depends on PROPRIETARY IE capabilities. Anything else is suicide for our platform." [1] https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish [2] (pdf) http://antitrust.slated.org/www.iowaconsumercase.org/011607/2000/PX02991.pdf http://antitrust.slated.org/www.iowaconsumercase.org/011607/...