9 ms·

"Even Brendan Eich admitted...". As if I would not expect, nay demand, that Gilad and Lars would do better -- much better -- than JS! For the record, I'm not w

"Even Brendan Eich admitted...". As if I would not expect, nay demand, that Gilad and Lars would do better -- much better -- than JS! For the record, I'm not worried about JS being replaced by a better language. I am working to do that within Ecma TC39, by evolving JS aggressively. The leaked Google doc's assertion that this is impossible and that a "clean break" is required to make significant improvements is nonsense, a thin rationale for going it alone rather than cooperating fully. 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. Google's approach with Dart is thus pretty much all wrong and doomed to leave Dart in excellent yet non-standardized and non-interoperable implementation status. Dart is GBScript to NaCl/Pepper's ActiveG. Could Google, unlike Microsoft ten or so years ago, prevail? Only by becoming the new monopoly power on the web. We know how that story ends.

magicalist 15y ago
> We see more of this fragmentation every day I'd be curious to see this backed up. Certainly with a long enough timeline we are not at a maximum of "works only in x", and -- ignoring those beleaguered Opera users still subjected to crappy UA sniffing -- I can't think of the last time I came across a site that blocked me for whatever my choice of browser (I'm a Chrome and Firefox user as well). If, on the other hand, you're talking about fancy new CSS3 or WebGL (or whatever) demos leaving out some browser due to neglecting to add a particular prefixed property (or whatever), I don't really see that as a problem. Prototype then standardize, right? Yes, not feature detecting and prefixing properly is poor web development practice and yes, they are cutting out part of their audience, but using an experimental feature inherently means that it may break at some point, and almost certainly isn't supported in all browsers. When 3d CSS transforms land in Firefox soon, there are going to be a whole lot of demos out there that won't work. I would say that's an education and library problem, not a fragmentation one.
- BrendanEich 15y ago
  I was explicit about the problem, which is not new features that come to some browsers first, advertised in a browser-agnostic way. That is ok, provided the features are on a standards track. What I cited is fragmentation due to capital-C Chrome as a requirement. Google is doing deals and marketing web apps and add-ons as "Chrome". This is showing up all over the place, most recently in my experience on the Starbucks free wireless service agreement page. Major content publishers Mozilla has talked to are surprised that we can host their Chrome-targeted web apps and HTML5-based extensions. They think such things are exclusive to Chrome. If they use Dart and need native performance, then that'll be true. There is a slippery slope, especially when more and more of the differentiation is not on a standards track (Dart, NaCl, WebSQL). Nevertheless most of the current differentiation is bogus and any modern browser will do. There's certainly some "WebKit required" fragmentation. We saw this with Amazon's kindle web app, which is specifically built to WebSQL and not IndexedDB. But I do not believe any big player is pushing "WebKit required" as an agenda or marketing program. In contrast, Google is clearly pushing "Chrome" as a requirement or works-best-in brand. The Chrome experiments, most recently http://www.allisnotlo.st/index_en.html http://www.allisnotlo.st/index_en.html are obvious, maybe too obvious. Defenders can always play up the "experiment" hedge. That helps but only so much, especially when many of these experiments could work in other browsers with trivial changes. I'm told that people have run chrome.angrybirds.com in Firefox. So it should be html5.angrybirds.com but -- no surprise from a marketing angle -- the domain name starts with C not H.
  - foobarbazetc 15y ago
    Brendan, First, I'm a huge fan. :) ... and I was with you until the WebSQL vs IndexedDB thing. IndexedDB is a horrible, horrible thing. It should be put out of its misery and replaced with WebSQL in Firefox. Mozilla is singlehandedly holding back offline web apps with the insistance on a slow and hard to program -- yet buzzword friendly -- technology that no one actually wants to use. There's no reason what so ever to stick with a dumbed down K/V store when you're not trying to replicate data across data centers. So, IMHO, you've bought this bit of "WebKit required" onto yourselves. WebSQL is the only production ready offline web app technology available today. Take it from someone who offline enabled one of the biggest web apps on the web: I'd rather leave out offline entirely than code IndexedDB. Considering that Apple will never support it, it's pretty much dead. And I feel that Mozilla is really on the losing end of this particular battle. TL:DR; Please support WebSQL in Firefox. :)
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.
haberman 15y ago
So somehow Google is going to become a monopoly because Apple and Microsoft will voluntarily decline to support a new technology that Google will presumably license freely (as with NaCl)? I don't even know if I like Dash or not, but how is this move predatory? Did you approach a standards committee or consider the philosophical balance of your competitors before creating JavaScript and shipping it in Netscape? You don't get new good ideas from committees -- just look at the disaster of the last 10 years of the W3C.
- BrendanEich 15y ago
  Who said anything about Google being "predatory"? I said "not standard." Google is a search monopoly in some locales, but what I wrote is more about their acting like a browser monopoly. In a more balanced market, the "defect" choice in the Prisoner's Dilemma is to crank out proprietary stuff and leave your fellow prisoners twisting on the reverse-engineering treadmill (update: don't try open-washing me: NaCl being licensed freely is meaningless when Google controls this very complex pile of code that depends on a deep/wide Pepper API into only one browser; Dart may be simpler but open-source != open or "free"; some vendors such as Opera cannot use any open source). The "cooperate" choice is to bring prototypes and proposals to standards bodies and gain buy-in and interop. Yeah, Netscape did a bunch of stuff without standardizing it with w3c or any other body, definitely including JS. We made Microsoft reverse engineer JS as JScript (poor them!). We took JS to ECMA in the second year and only under some pressure from MS and non-sock-puppet web devs. Nothing I can brag about there. That was then, and everyone paid a price. Now, are you suggesting that Google is the better Netscape, the "good" monopoly? I don't think so. Again, I'm not moralizing. I'm not the dry drunk lecturing the kids to avoid having the "fun" I had. Google will do what it thinks best. My objection is that we have a non-monopoly browser market, not even a duopoly, with pretty good open-standards innovation. Dart goes the other way and puts the open web at risk. It is fragmenting. On JS evolution in Ecma TC39, no one wants design by committee. I spoke about how we strive to avoid that in TC39 at TXJS. Give my blogged video a listen if you can.
deleted 15y ago
[deleted]
- BrendanEich 15y ago
  "From a practical standpoint, all these apps are integrated with the web. How the code is delivered, or what runtime is used, are just technical details." How standards are made, what must be implemented in an interoperating browser, are not "just technical details". If that were so we could treat browsers like bespoke server installations, with different language VMs, databases, etc. That would fragment the web into non-interoperating silos. On the server side, subsidiarity is the rule. Different sources of authority over domain names can provision as they please. But the servers all speak HTTP, HTML, CSS, JS, PNG, etc. -- a relatively small set of content languages. And the browsers must all agree on how these work.
espadrine 15y ago
I don't think Dart will beg other browsers to comply to their will of adding a VM. On the other hand, I find it more likely that, in a whole year's time, the people behind Dart thought about NPAPI. They may very well produce a plugin that everyone will download. That would make Dart the new Flash, but that's the price to pay for a serious cross-browser Dart. Of course, that would also make Dart second-class citizen in the web platform, and I guess Dart people don't want that. However, I find it hard to believe that they hoped all browser vendors would bow before the new programming language overlord. Now, making browsers speak Dart will be the easy part, I think. The Enterprise will have a hard time accepting a brand-new language blindly when they have just learned that C# is slowly losing Microsoft backing. Programming languages all make mistakes, and Dart will be no exception; they had a full year and bright engineers, but that rule is sacred. No matter how hard they advocate the niceties of the language (which I assume will be closures (again!), the full funarg, yet another garbage collector, optional typing, type inference, bignums, modules, event-oriented programming, maybe lazy evaluation) but I know many programmers that won't bother learning any programming language that falls too far from the C-like tree, especially if it has odd features, especially if there are mistakes in the way those features work together. I have seen many bright programming languages that never found any serious adoption. Scheme would have been very interesting in real work environments; Perl6 has many interesting features, but is too late and slow; Haskell still has potential, but I don't see it suddenly go past Objective-C, C# or Java in popularity. I would love Dart to find success. But this is not a dream world. The platform it seeks to conquer, the competition it must overcome, the tender age it has: Dart is so very late for such a challenge.
- BrendanEich 15y ago
  This has been studied, I don't have the stats but it may have been in the context of Gears: users don't install new plugins lightly. Distribution deals could be bought and paid for, but that is a long road (see ChromeFrame). Also, NPAPI is not expressive enough to enable a new programming language VM to be integrated on par with JS. Big deal, Google can write browser/OS-specific code? They tried with Gears. It's hard, and versionitis/unfrozen APIs bite hard. Take these two points together and the NPAPI route is not going to get Dart widespread adoption outside of Chrome, any time soon. So would web developers use it if they had to compile to JS for too many visitors? I doubt it. CoffeeScript is a transpiler and it may actually speed up code compared to writing in JS. It is popular, with slick RoR integration, but it's not taking over the world from JS. Dart's new semantics (at least new number types, per the memo) will result in slower compiled-to-JS code, although the win may be programmer productivity. It depends on how much slower, but the first barrier with compiling is getting devs to put up with the toolchain pain.
bobbydriscol 15y ago
Now that Apple has successfully marginalized Flash as a cross platform development environment the browser fragmentation will ramp up and we'll see more of this type of behaviour rather than less. Apple didn't start this fragmentation but they are committed to ensuring that the web is not a level playing field with technology segmentation like canvas and css ES. Microsoft has always tried to fragment the market with IE. Take for example the current version of web based Outlook which only functions at full power in the IE browser, otherwise you get the 'lite' incarnation. And now that Google is joining the fray we're concerned? Not at all. There will always be applications that only run on one browser (or operating system like Android). This same methodology will be incorporated by Google for gmail or any of their other services which will allow them to control which environment gets the best features and allow them to leverage their technologies effectively when their competitors are already doing the same thing.
- BrendanEich 15y ago
  You're not concerned about fragmentation so long as there's a "lite" fallback. Got it. Let's see how this plays out. It may be that browser vendors with hot websites have to make the "lite" experience as good over time as their proprietary one, so they work fairly with the standards bodies. Again, for this thread, per the leaked memo, that was not the plan with Dart. Coming to a standards body late will not work -- it may get a spec, but not Dart support in other browsers -- unless Googe has near-monopoly power.

magicalist 15y ago

> We see more of this fragmentation every day I'd be curious to see this backed up. Certainly with a long enough timeline we are not at a maximum of "works only in x", and -- ignoring those beleaguered Opera users still subjected to crappy UA sniffing -- I can't think of the last time I came across a site that blocked me for whatever my choice of browser (I'm a Chrome and Firefox user as well). If, on the other hand, you're talking about fancy new CSS3 or WebGL (or whatever) demos leaving out some browser due to neglecting to add a particular prefixed property (or whatever), I don't really see that as a problem. Prototype then standardize, right? Yes, not feature detecting and prefixing properly is poor web development practice and yes, they are cutting out part of their audience, but using an experimental feature inherently means that it may break at some point, and almost certainly isn't supported in all browsers. When 3d CSS transforms land in Firefox soon, there are going to be a whole lot of demos out there that won't work. I would say that's an education and library problem, not a fragmentation one.

BrendanEich 15y ago
I was explicit about the problem, which is not new features that come to some browsers first, advertised in a browser-agnostic way. That is ok, provided the features are on a standards track. What I cited is fragmentation due to capital-C Chrome as a requirement. Google is doing deals and marketing web apps and add-ons as "Chrome". This is showing up all over the place, most recently in my experience on the Starbucks free wireless service agreement page. Major content publishers Mozilla has talked to are surprised that we can host their Chrome-targeted web apps and HTML5-based extensions. They think such things are exclusive to Chrome. If they use Dart and need native performance, then that'll be true. There is a slippery slope, especially when more and more of the differentiation is not on a standards track (Dart, NaCl, WebSQL). Nevertheless most of the current differentiation is bogus and any modern browser will do. There's certainly some "WebKit required" fragmentation. We saw this with Amazon's kindle web app, which is specifically built to WebSQL and not IndexedDB. But I do not believe any big player is pushing "WebKit required" as an agenda or marketing program. In contrast, Google is clearly pushing "Chrome" as a requirement or works-best-in brand. The Chrome experiments, most recently http://www.allisnotlo.st/index_en.html http://www.allisnotlo.st/index_en.html are obvious, maybe too obvious. Defenders can always play up the "experiment" hedge. That helps but only so much, especially when many of these experiments could work in other browsers with trivial changes. I'm told that people have run chrome.angrybirds.com in Firefox. So it should be html5.angrybirds.com but -- no surprise from a marketing angle -- the domain name starts with C not H.
- foobarbazetc 15y ago
  Brendan, First, I'm a huge fan. :) ... and I was with you until the WebSQL vs IndexedDB thing. IndexedDB is a horrible, horrible thing. It should be put out of its misery and replaced with WebSQL in Firefox. Mozilla is singlehandedly holding back offline web apps with the insistance on a slow and hard to program -- yet buzzword friendly -- technology that no one actually wants to use. There's no reason what so ever to stick with a dumbed down K/V store when you're not trying to replicate data across data centers. So, IMHO, you've bought this bit of "WebKit required" onto yourselves. WebSQL is the only production ready offline web app technology available today. Take it from someone who offline enabled one of the biggest web apps on the web: I'd rather leave out offline entirely than code IndexedDB. Considering that Apple will never support it, it's pretty much dead. And I feel that Mozilla is really on the losing end of this particular battle. TL:DR; Please support WebSQL in Firefox. :)

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.

haberman 15y ago

So somehow Google is going to become a monopoly because Apple and Microsoft will voluntarily decline to support a new technology that Google will presumably license freely (as with NaCl)? I don't even know if I like Dash or not, but how is this move predatory? Did you approach a standards committee or consider the philosophical balance of your competitors before creating JavaScript and shipping it in Netscape? You don't get new good ideas from committees -- just look at the disaster of the last 10 years of the W3C.

BrendanEich 15y ago
Who said anything about Google being "predatory"? I said "not standard." Google is a search monopoly in some locales, but what I wrote is more about their acting like a browser monopoly. In a more balanced market, the "defect" choice in the Prisoner's Dilemma is to crank out proprietary stuff and leave your fellow prisoners twisting on the reverse-engineering treadmill (update: don't try open-washing me: NaCl being licensed freely is meaningless when Google controls this very complex pile of code that depends on a deep/wide Pepper API into only one browser; Dart may be simpler but open-source != open or "free"; some vendors such as Opera cannot use any open source). The "cooperate" choice is to bring prototypes and proposals to standards bodies and gain buy-in and interop. Yeah, Netscape did a bunch of stuff without standardizing it with w3c or any other body, definitely including JS. We made Microsoft reverse engineer JS as JScript (poor them!). We took JS to ECMA in the second year and only under some pressure from MS and non-sock-puppet web devs. Nothing I can brag about there. That was then, and everyone paid a price. Now, are you suggesting that Google is the better Netscape, the "good" monopoly? I don't think so. Again, I'm not moralizing. I'm not the dry drunk lecturing the kids to avoid having the "fun" I had. Google will do what it thinks best. My objection is that we have a non-monopoly browser market, not even a duopoly, with pretty good open-standards innovation. Dart goes the other way and puts the open web at risk. It is fragmenting. On JS evolution in Ecma TC39, no one wants design by committee. I spoke about how we strive to avoid that in TC39 at TXJS. Give my blogged video a listen if you can.

deleted 15y ago

[deleted]

BrendanEich 15y ago
"From a practical standpoint, all these apps are integrated with the web. How the code is delivered, or what runtime is used, are just technical details." How standards are made, what must be implemented in an interoperating browser, are not "just technical details". If that were so we could treat browsers like bespoke server installations, with different language VMs, databases, etc. That would fragment the web into non-interoperating silos. On the server side, subsidiarity is the rule. Different sources of authority over domain names can provision as they please. But the servers all speak HTTP, HTML, CSS, JS, PNG, etc. -- a relatively small set of content languages. And the browsers must all agree on how these work.

espadrine 15y ago

I don't think Dart will beg other browsers to comply to their will of adding a VM. On the other hand, I find it more likely that, in a whole year's time, the people behind Dart thought about NPAPI. They may very well produce a plugin that everyone will download. That would make Dart the new Flash, but that's the price to pay for a serious cross-browser Dart. Of course, that would also make Dart second-class citizen in the web platform, and I guess Dart people don't want that. However, I find it hard to believe that they hoped all browser vendors would bow before the new programming language overlord. Now, making browsers speak Dart will be the easy part, I think. The Enterprise will have a hard time accepting a brand-new language blindly when they have just learned that C# is slowly losing Microsoft backing. Programming languages all make mistakes, and Dart will be no exception; they had a full year and bright engineers, but that rule is sacred. No matter how hard they advocate the niceties of the language (which I assume will be closures (again!), the full funarg, yet another garbage collector, optional typing, type inference, bignums, modules, event-oriented programming, maybe lazy evaluation) but I know many programmers that won't bother learning any programming language that falls too far from the C-like tree, especially if it has odd features, especially if there are mistakes in the way those features work together. I have seen many bright programming languages that never found any serious adoption. Scheme would have been very interesting in real work environments; Perl6 has many interesting features, but is too late and slow; Haskell still has potential, but I don't see it suddenly go past Objective-C, C# or Java in popularity. I would love Dart to find success. But this is not a dream world. The platform it seeks to conquer, the competition it must overcome, the tender age it has: Dart is so very late for such a challenge.

BrendanEich 15y ago
This has been studied, I don't have the stats but it may have been in the context of Gears: users don't install new plugins lightly. Distribution deals could be bought and paid for, but that is a long road (see ChromeFrame). Also, NPAPI is not expressive enough to enable a new programming language VM to be integrated on par with JS. Big deal, Google can write browser/OS-specific code? They tried with Gears. It's hard, and versionitis/unfrozen APIs bite hard. Take these two points together and the NPAPI route is not going to get Dart widespread adoption outside of Chrome, any time soon. So would web developers use it if they had to compile to JS for too many visitors? I doubt it. CoffeeScript is a transpiler and it may actually speed up code compared to writing in JS. It is popular, with slick RoR integration, but it's not taking over the world from JS. Dart's new semantics (at least new number types, per the memo) will result in slower compiled-to-JS code, although the win may be programmer productivity. It depends on how much slower, but the first barrier with compiling is getting devs to put up with the toolchain pain.

bobbydriscol 15y ago

Now that Apple has successfully marginalized Flash as a cross platform development environment the browser fragmentation will ramp up and we'll see more of this type of behaviour rather than less. Apple didn't start this fragmentation but they are committed to ensuring that the web is not a level playing field with technology segmentation like canvas and css ES. Microsoft has always tried to fragment the market with IE. Take for example the current version of web based Outlook which only functions at full power in the IE browser, otherwise you get the 'lite' incarnation. And now that Google is joining the fray we're concerned? Not at all. There will always be applications that only run on one browser (or operating system like Android). This same methodology will be incorporated by Google for gmail or any of their other services which will allow them to control which environment gets the best features and allow them to leverage their technologies effectively when their competitors are already doing the same thing.

BrendanEich 15y ago
You're not concerned about fragmentation so long as there's a "lite" fallback. Got it. Let's see how this plays out. It may be that browser vendors with hot websites have to make the "lite" experience as good over time as their proprietary one, so they work fairly with the standards bodies. Again, for this thread, per the leaked memo, that was not the plan with Dart. Coming to a standards body late will not work -- it may get a spec, but not Dart support in other browsers -- unless Googe has near-monopoly power.