6 ms·

I'll pipe up with one thing nobody seems to be emphasizing. A lot depends on how good Dart turns out to be. Suppose it turns out so good that we get all four of

by gruseom 15y ago

I'll pipe up with one thing nobody seems to be emphasizing. A lot depends on how good Dart turns out to be. Suppose it turns out so good that we get all four of the following: 1. No worse a user experience in any browser; 2. A much better user experience in Chrome; 3. A much better developer experience; 4. A much better server-side platform than V8. If we get all that, standards or not, I will be jumping for joy. If Dart is that good, it will become standard, either de jure or de facto as alternatives fall by the wayside. Of the four, #1 (a good enough Dart->JS) seems problematic. #2 may be bad for other browser vendors, but if it's good for users and programmers, why should I care? I see no virtue in a lowest common denominator. #3 and #4 are hardly objectionable. Only those who like them need bother. I don't know how likely this win-win-win-win is, but here's why I'm indulging in the hope. These guys have been gods of fast dynamic VMs since Strongtalk. If Dart is their chance to build what they always wanted, but this time with 20 years of experience to draw on and the institutional support of a Google behind them... well, we have the chance of something insanely great. Greatness sets its own standard. Comparisons to VBScript and Flash only kick in if what they come out with is lacklustre.

BrendanEich 15y ago
The comparison to VBScript is not technical at all. It is about single-vendor control. Your item 1 is obviously problematic. If Dart and JS have close semantics, it's just a transpiler like CoffeeScript, which intentionally sugars JS semantics with leaner syntax. But this does not match the leaked info and hype about Dart, and even then, such warm beer still requires you to run a tool over your primary source, which costs adoption. Lots of languages already contending in this transpiling space. More likely, a Dart-to-JS compiler (making non-local transformations) and a JS-implemented Dart runtime (to support the novel runtime semantics, e.g. new numeric types) will be required. This means a worse user experience in browsers that don't have the native Dart VM, because performance will lag (especially depending on the new numeric type details) and bug-for-bug compatibility will be lost. The native VM will be the super-fast source of truth. The compiler/runtime will be a stop-gap. This brings us back to the standards table, unless the idea is to corner the browser market. See https://news.ycombinator.com/item?id=2983157 https://news.ycombinator.com/item?id=2983157 under "On Dart: ..." about what the standards table would look like if it is anywhere near today's mix of browser vendors and other interested parties.
bzbarsky 15y ago
#2 is bad for users unless Chrome is shipping on all hardware and operating systems users use. In fact, that's the same reason any sort of web-related monopoly is bad. Where's Chrome for PPC processors? Chrome for ARM (being worked on, but no there yet)? Chrome for whatever architecture or OS users might want tomorrow? The right comparison here in your success scenario may not be VBScript but ActiveX, except without the security issues ActiveX had. If ActiveX were required for use of gmail today, how would you feel about it? How would you have felt about it in 2002?
- gruseom 15y ago
  If ActiveX had been insanely great, not only would I feel fine about it, it would be ubiquitous by now.
  - BrendanEich 15y ago
    Isn't "insanely great" a Steve Jobs phrase? I like Apple's hardware (modulo the fans running all the time on my latest dual-core i7 MBP), and some of its software (but WTF happened to Mail.app on Lion?). Still, "insanely great" didn't make Apple-only web tech ubiquitous. That took hard, open-standards spec-work in the CSS WG. And that, to the extent it happened with help from Apple, is the opposite of the Dart plan in the leaked memo. Stop worshipping i.g. It's never that great. Native apps on iOS use Objective-C, for crying out loud. Everyone's sh*t stinks. I.g. is no excuse for monopoly behavior. The greatness goes away, leaving only insanity.
    - m-k-s 15y ago
      Well said Brendan! Like I said in a tweet this morning, I know those Googlers know way more about JS than I do, but if they think as per the leaked mail) that devs are choosing iOS over browsers because of JS, they have their heads in the sand. Those choices are happening due to iOS as a platform not because devs are somehow so much more happier learning/using objective-C! The best thing that Google could do is to KEEP working hard on improving the browser platform like you guys are doing with B2G and they started to do with ChromeOS. For example, I'd love to hear from the ChromeOS team exactly what in JS is blocking them delivering all the kinds of APIs that B2G is promising to deliver. And on the server-side, some one should tell the hordes flocking to Nodejs that they are all wrong! As you pointed out, serverside everyone can choose to use whatever they want and given that choice, just look at everyone jumping on the Nodejs bandwagon. I'd love to see all those thousands of module that dev around the world have written in Go recently! (npmjs.org) maks.

by gruseom 15y ago

BrendanEich 15y ago

The comparison to VBScript is not technical at all. It is about single-vendor control. Your item 1 is obviously problematic. If Dart and JS have close semantics, it's just a transpiler like CoffeeScript, which intentionally sugars JS semantics with leaner syntax. But this does not match the leaked info and hype about Dart, and even then, such warm beer still requires you to run a tool over your primary source, which costs adoption. Lots of languages already contending in this transpiling space. More likely, a Dart-to-JS compiler (making non-local transformations) and a JS-implemented Dart runtime (to support the novel runtime semantics, e.g. new numeric types) will be required. This means a worse user experience in browsers that don't have the native Dart VM, because performance will lag (especially depending on the new numeric type details) and bug-for-bug compatibility will be lost. The native VM will be the super-fast source of truth. The compiler/runtime will be a stop-gap. This brings us back to the standards table, unless the idea is to corner the browser market. See https://news.ycombinator.com/item?id=2983157 https://news.ycombinator.com/item?id=2983157 under "On Dart: ..." about what the standards table would look like if it is anywhere near today's mix of browser vendors and other interested parties.

bzbarsky 15y ago

#2 is bad for users unless Chrome is shipping on all hardware and operating systems users use. In fact, that's the same reason any sort of web-related monopoly is bad. Where's Chrome for PPC processors? Chrome for ARM (being worked on, but no there yet)? Chrome for whatever architecture or OS users might want tomorrow? The right comparison here in your success scenario may not be VBScript but ActiveX, except without the security issues ActiveX had. If ActiveX were required for use of gmail today, how would you feel about it? How would you have felt about it in 2002?

gruseom 15y ago
If ActiveX had been insanely great, not only would I feel fine about it, it would be ubiquitous by now.
- BrendanEich 15y ago
  Isn't "insanely great" a Steve Jobs phrase? I like Apple's hardware (modulo the fans running all the time on my latest dual-core i7 MBP), and some of its software (but WTF happened to Mail.app on Lion?). Still, "insanely great" didn't make Apple-only web tech ubiquitous. That took hard, open-standards spec-work in the CSS WG. And that, to the extent it happened with help from Apple, is the opposite of the Dart plan in the leaked memo. Stop worshipping i.g. It's never that great. Native apps on iOS use Objective-C, for crying out loud. Everyone's sh*t stinks. I.g. is no excuse for monopoly behavior. The greatness goes away, leaving only insanity.
  - m-k-s 15y ago
    Well said Brendan! Like I said in a tweet this morning, I know those Googlers know way more about JS than I do, but if they think as per the leaked mail) that devs are choosing iOS over browsers because of JS, they have their heads in the sand. Those choices are happening due to iOS as a platform not because devs are somehow so much more happier learning/using objective-C! The best thing that Google could do is to KEEP working hard on improving the browser platform like you guys are doing with B2G and they started to do with ChromeOS. For example, I'd love to hear from the ChromeOS team exactly what in JS is blocking them delivering all the kinds of APIs that B2G is promising to deliver. And on the server-side, some one should tell the hordes flocking to Nodejs that they are all wrong! As you pointed out, serverside everyone can choose to use whatever they want and given that choice, just look at everyone jumping on the Nodejs bandwagon. I'd love to see all those thousands of module that dev around the world have written in Go recently! (npmjs.org) maks.