7 ms·

Thanks for the expanded comment on Dart. I don't fear forking the developer community in terms coffeescript vs. GWT vs. Javascript vs. Dart-to-JS. The web deve

by equark 15y ago

Thanks for the expanded comment on Dart. I don't fear forking the developer community in terms coffeescript vs. GWT vs. Javascript vs. Dart-to-JS. The web development experience, from front-end to back-end and at the language and framework level, is already incredibly fragmented. More higher level options that unify the front-end and back-end seem like a win for the web stack. I agree that there is virtually no chance that Microsoft or Apple will adopt the Dart VM. So the real question is whether the Dart-to-JS compiler combined with the Dart VM on the server side is compelling. This sounds to me like an improved GWT with server-side built in. The controversial difference is the Dart VM will be in Chrome, enabling Chrome to deliver experiences that other browsers presumably cannot. I see your worry about "works only in Chrome". But this will only come true if Dart-to-Javascript delivers a much, much worse experience. If that's true, there is a problem that other browsers need to confront not avoid. Until they do the Dart VM will presumably be like Flash -- a necessary evil that makes clear the limitations of current standards. Presumably Dart will always compile to whatever the best target is, including whatever comes out of TC39.

BrendanEich 15y ago
Yes, standards must keep up, whatever the proprietary challenger does -- this was true when Flash could do many tricks that browsers generally could not. Without further nuance, saying "standards must keep up, deal with it" is a bit too consequentialist for me, a Mozilla founder, or for anyone working sincerely in the open web standards bodies. Korean and Chinese banks still require ActiveX PKI plugins or else deny service. The end of better web tech does not justify any means, especially not single-vendor locked-in means. It seems to me Google is trying to have it both ways, which creates not just the appearance of a conflict, but an actual conflict: does their top talent work with standards bodies to make interoperable specs (based on prototypes and open source and so on), or do they go for wow-effect and sweet-talk if not strong-arm tactics? Google knows they can't standardize something like NaCl. My belief is that control flow integrity enforcement will sooner come to OSes and OS-targeted toolchains than it will to browsers via NaCl and Pepper. So, safer (but still OS-specific) binary plugins, in the next five years. But mapping Pepper, an unimpressively large and messy API tied to Chrome as well as WebKit, onto other browsers? Other vendors won't get on that treadmill, and I don't believe Google would try to "do it for them". Gears was too painful. On Dart: Google as a single entity does not know what could be done in Ecma TC39, since the Dart/V8 principals never participated, and V8 needed a fresh-thinking second team finally to get going on Harmony prototyping. But let's agree that one or two designers work better sprinting alone, not burdened by a committee (see my blog post for how we avoid design by committee). Then Dart could come to Ecma as a proposed spec with a single open source implementation, perhaps later this year or early next. This was not part of the leaked game-plan, however. Clearly Google did not, as of that document's date, intend to standardize. And who believes they would give up "design control"? Would TC39 entertain Dart as a second language? I doubt it. A whole second spec to write and get through ISO, cross-language-heap cycles to collect, mixed and possibly conflicting runtime semantics, specifically more numeric types in Dart than current JS to coerce and/or fail to convert in the native/managed bridges and API stubs, the list goes on. Would TC39 take inspiration from Dart and fold ideas and design elements into the Harmony agenda? Absolutely we would, but we need to see Dart first, and this last week does not make for an auspicious launch. Still, no hard feelings if we do get a clean pitch from Dart principals to TC39. However this plays out, Google has a lot of power. I won't quote Spider-Man's Uncle Ben, but for a company that moralizes about evil-as-in-don't-be, the standards they hold themselves to have to be high. I argue that they can't successfully and faithfully both work for interoperable and better web standards among multiple browsers, and play deep proprietary lock-in games. Pick one or the other. Innovating in the open and proposing early and often to standards bodies are fine. Delayed-open-washing and increasing piles of proprietary (open-source doesn't matter) single-vendor code, which implements features that are not ever proposed for standardization, are not. Even if any means are justified toward the end of improving web programmer productivity over what JS affords today, Dart represents a specific, clear and negative judgment on the Harmony work in Ecma, a judgment that I believe will be shown to be a mistake. It can't possibly help us make faster progress in TC39 -- it's at best a distraction and at worst a break in trust among the members. With tooling (Brightly) and massive developer and evangelism resources backing Dart, will we really have the kind of open-web-first, fair-play contest that people who thought Google was (as Paul Graham put it) "aligned with the grain of the web" have come to want and expect from Google? It looks like we won't. GOOG is acting more like MSFT of old (also like AOL, wanting sticky eyeballs and time-on-site instead of being the best search engine). The game theories of public companies, the innovator's dilemma, the Facebook challenge, and the browser-vendor Prisoner's Dilemma, all predict this ironic development. It is not a surprise. But companies are made of people, and I have hopes that Googlers on the right side of this conflict will speak up.
- asynchrony 15y ago
  I'm having a hard time understanding these objections. Suppose Dart is a new open-source language from Google for front-end web developers. Surely this wouldn't offend anyone. Now suppose they include a Dart->Javascript compiler with the language. Well, he have GWT and coffeescript and all the others. Surely this wouldn't be offensive. Pragmatic, even. Then, being in the unique position to do so, they include specialized runtime support in Chrome (and it will still compile to JS). Now they're evil and anti-open-web? As to the MSFT analogy -- I've never heard of any intentions of driving competitors to implement ActiveX or VBScript. Still, I'm curious, if Google, responding to reactions such as this one, said "our bad, it won't run any faster in Chrome. See you at the committee." and released the JS compiler only. Would that ease the objections?
  - BrendanEich 15y ago
    You set up a series of straw men based on nothing I wrote. I wrote "Then Dart could come to Ecma as a proposed spec with a single open source implementation." Nowhere did I say a single word trying to corral Google into a non-evil, artificially held back (you imply) posture of offering only compile-to-JS, with no Dart VM in Chrome. Chrome ships all kinds of non-standard or proto-standard stuff. Chrome can certainly ship Dart if it floats their boat, and if it is standards-bound, meaning Ecma TC39 bound, then I will not object categorically. The issue is whether Dart is even a proto-standard, or more a modern VBScript. Get it? "Now they're evil and anti-open-web?" Half-right. You put the e-word in my mouth, but yes, some of Google's actions are anti-open-web. Remember, I'm not the one throwing around slogans about "evil". Do you really need me to quote Uncle Ben in full? The relevant words from that quote are "power" and "responsibility". Google is acting like a monopoly power. Now, being a monopoly is not illegal or evil, it depends on actions. You bet I am objecting to proposed actions in the plan that leaked. But whether these actions are evil, I leave to others. They are definitely disruptive to Google's standards effort in TC39. The open-standards-based web does not work by following anything like the game plan in the leaked memo. "As to the MSFT analogy -- I've never heard of any intentions of driving competitors to implement ActiveX or VBScript." This is not only ignorant, but naive. We at Mozilla faced pressure to implement ActiveX and ship support for it, starting in the late '90s. Adam Lock did an implementation, still in our source tree (IIRC in chromium.org too). Without ActiveX, plugins were unscriptable until we at Mozilla founded the plugin-futures mailing list in 2004 and co-created NPRuntime with Apple, Adobe, and others. Good thing we (meaning Netscape, then AOL, which was under pressure) didn't cave and ship ActiveX support or we would have been on a very long, high-speed treadmill, reverse-engineering hundreds of COM interfaces in IE. But see my earlier comment about the PKI story in parts of Asia. That's the history. I believe that you don't need to know it in detail to game out how minority share browsers were stuck without a plugin API locked into MSCOM and Windows. Really, what were other browsers to do, without market power to get plugin vendors sinking more cost in a second plugin API? The old Netscape-1.1-era NPAPI did not include scriptability (JS debuted in Netscape 2). Ok, maybe you did need to know some details, but I still think your use of "analogy" and "I've never heard" are naive. As for VBScript, MSFT was absolutely trying to make that a de-facto standard, gunning against JS as de-facto standard from Netscape (yes, Netscape was a monopoly at first; not for long). GNU folks even offered to get on the VBScript treadmill and help Mosaic, Netscape, and other mid-'90s browsers support it. Good thing JS came out early enough to choke it off to a few microsoft.com sites. "Would that ease the objections?" More straw men. If you don't know what I meant by "consequentialist", look it up. I'm not going to play "how low can you go" if we don't agree on premises, specifically how open web standards are best made, what's wrong with the game plan in the leaked memo, and why monopoly power shouldn't be so eagerly abused. Being open is nothing like (a) delayed, single-vendor-dominated source code release; (b) sweet-talking or arm-twisting with a big ad budget; (c) hedging one's standards commitments so heavily while tossing fragmentation grenades such as standardizable-only-by-market-power new language VMs into Chrome.

by equark 15y ago

BrendanEich 15y ago

Yes, standards must keep up, whatever the proprietary challenger does -- this was true when Flash could do many tricks that browsers generally could not. Without further nuance, saying "standards must keep up, deal with it" is a bit too consequentialist for me, a Mozilla founder, or for anyone working sincerely in the open web standards bodies. Korean and Chinese banks still require ActiveX PKI plugins or else deny service. The end of better web tech does not justify any means, especially not single-vendor locked-in means. It seems to me Google is trying to have it both ways, which creates not just the appearance of a conflict, but an actual conflict: does their top talent work with standards bodies to make interoperable specs (based on prototypes and open source and so on), or do they go for wow-effect and sweet-talk if not strong-arm tactics? Google knows they can't standardize something like NaCl. My belief is that control flow integrity enforcement will sooner come to OSes and OS-targeted toolchains than it will to browsers via NaCl and Pepper. So, safer (but still OS-specific) binary plugins, in the next five years. But mapping Pepper, an unimpressively large and messy API tied to Chrome as well as WebKit, onto other browsers? Other vendors won't get on that treadmill, and I don't believe Google would try to "do it for them". Gears was too painful. On Dart: Google as a single entity does not know what could be done in Ecma TC39, since the Dart/V8 principals never participated, and V8 needed a fresh-thinking second team finally to get going on Harmony prototyping. But let's agree that one or two designers work better sprinting alone, not burdened by a committee (see my blog post for how we avoid design by committee). Then Dart could come to Ecma as a proposed spec with a single open source implementation, perhaps later this year or early next. This was not part of the leaked game-plan, however. Clearly Google did not, as of that document's date, intend to standardize. And who believes they would give up "design control"? Would TC39 entertain Dart as a second language? I doubt it. A whole second spec to write and get through ISO, cross-language-heap cycles to collect, mixed and possibly conflicting runtime semantics, specifically more numeric types in Dart than current JS to coerce and/or fail to convert in the native/managed bridges and API stubs, the list goes on. Would TC39 take inspiration from Dart and fold ideas and design elements into the Harmony agenda? Absolutely we would, but we need to see Dart first, and this last week does not make for an auspicious launch. Still, no hard feelings if we do get a clean pitch from Dart principals to TC39. However this plays out, Google has a lot of power. I won't quote Spider-Man's Uncle Ben, but for a company that moralizes about evil-as-in-don't-be, the standards they hold themselves to have to be high. I argue that they can't successfully and faithfully both work for interoperable and better web standards among multiple browsers, and play deep proprietary lock-in games. Pick one or the other. Innovating in the open and proposing early and often to standards bodies are fine. Delayed-open-washing and increasing piles of proprietary (open-source doesn't matter) single-vendor code, which implements features that are not ever proposed for standardization, are not. Even if any means are justified toward the end of improving web programmer productivity over what JS affords today, Dart represents a specific, clear and negative judgment on the Harmony work in Ecma, a judgment that I believe will be shown to be a mistake. It can't possibly help us make faster progress in TC39 -- it's at best a distraction and at worst a break in trust among the members. With tooling (Brightly) and massive developer and evangelism resources backing Dart, will we really have the kind of open-web-first, fair-play contest that people who thought Google was (as Paul Graham put it) "aligned with the grain of the web" have come to want and expect from Google? It looks like we won't. GOOG is acting more like MSFT of old (also like AOL, wanting sticky eyeballs and time-on-site instead of being the best search engine). The game theories of public companies, the innovator's dilemma, the Facebook challenge, and the browser-vendor Prisoner's Dilemma, all predict this ironic development. It is not a surprise. But companies are made of people, and I have hopes that Googlers on the right side of this conflict will speak up.

asynchrony 15y ago
I'm having a hard time understanding these objections. Suppose Dart is a new open-source language from Google for front-end web developers. Surely this wouldn't offend anyone. Now suppose they include a Dart->Javascript compiler with the language. Well, he have GWT and coffeescript and all the others. Surely this wouldn't be offensive. Pragmatic, even. Then, being in the unique position to do so, they include specialized runtime support in Chrome (and it will still compile to JS). Now they're evil and anti-open-web? As to the MSFT analogy -- I've never heard of any intentions of driving competitors to implement ActiveX or VBScript. Still, I'm curious, if Google, responding to reactions such as this one, said "our bad, it won't run any faster in Chrome. See you at the committee." and released the JS compiler only. Would that ease the objections?
- BrendanEich 15y ago
  You set up a series of straw men based on nothing I wrote. I wrote "Then Dart could come to Ecma as a proposed spec with a single open source implementation." Nowhere did I say a single word trying to corral Google into a non-evil, artificially held back (you imply) posture of offering only compile-to-JS, with no Dart VM in Chrome. Chrome ships all kinds of non-standard or proto-standard stuff. Chrome can certainly ship Dart if it floats their boat, and if it is standards-bound, meaning Ecma TC39 bound, then I will not object categorically. The issue is whether Dart is even a proto-standard, or more a modern VBScript. Get it? "Now they're evil and anti-open-web?" Half-right. You put the e-word in my mouth, but yes, some of Google's actions are anti-open-web. Remember, I'm not the one throwing around slogans about "evil". Do you really need me to quote Uncle Ben in full? The relevant words from that quote are "power" and "responsibility". Google is acting like a monopoly power. Now, being a monopoly is not illegal or evil, it depends on actions. You bet I am objecting to proposed actions in the plan that leaked. But whether these actions are evil, I leave to others. They are definitely disruptive to Google's standards effort in TC39. The open-standards-based web does not work by following anything like the game plan in the leaked memo. "As to the MSFT analogy -- I've never heard of any intentions of driving competitors to implement ActiveX or VBScript." This is not only ignorant, but naive. We at Mozilla faced pressure to implement ActiveX and ship support for it, starting in the late '90s. Adam Lock did an implementation, still in our source tree (IIRC in chromium.org too). Without ActiveX, plugins were unscriptable until we at Mozilla founded the plugin-futures mailing list in 2004 and co-created NPRuntime with Apple, Adobe, and others. Good thing we (meaning Netscape, then AOL, which was under pressure) didn't cave and ship ActiveX support or we would have been on a very long, high-speed treadmill, reverse-engineering hundreds of COM interfaces in IE. But see my earlier comment about the PKI story in parts of Asia. That's the history. I believe that you don't need to know it in detail to game out how minority share browsers were stuck without a plugin API locked into MSCOM and Windows. Really, what were other browsers to do, without market power to get plugin vendors sinking more cost in a second plugin API? The old Netscape-1.1-era NPAPI did not include scriptability (JS debuted in Netscape 2). Ok, maybe you did need to know some details, but I still think your use of "analogy" and "I've never heard" are naive. As for VBScript, MSFT was absolutely trying to make that a de-facto standard, gunning against JS as de-facto standard from Netscape (yes, Netscape was a monopoly at first; not for long). GNU folks even offered to get on the VBScript treadmill and help Mosaic, Netscape, and other mid-'90s browsers support it. Good thing JS came out early enough to choke it off to a few microsoft.com sites. "Would that ease the objections?" More straw men. If you don't know what I meant by "consequentialist", look it up. I'm not going to play "how low can you go" if we don't agree on premises, specifically how open web standards are best made, what's wrong with the game plan in the leaked memo, and why monopoly power shouldn't be so eagerly abused. Being open is nothing like (a) delayed, single-vendor-dominated source code release; (b) sweet-talking or arm-twisting with a big ad budget; (c) hedging one's standards commitments so heavily while tossing fragmentation grenades such as standardizable-only-by-market-power new language VMs into Chrome.