4 ms·

It is not the same I guess. Since there is dart2js, I think we can force a Dart application to run on DartVM when the browser is Chrome and run as js when it is

by Xelom 13y ago

It is not the same I guess. Since there is dart2js, I think we can force a Dart application to run on DartVM when the browser is Chrome and run as js when it is not Chrome. I might be mistaken. You'll just see performance gain, the application is the same.

threeseed 13y ago
Dart has all the perils of an embrace and extinguish situation even if it is not the intention. Developers commit to Dart only to find in the future that the DartVM/Dart2JS targets have differing behaviour or levels of attention. And then suddenly Dart apps require Chrome and we end up with same IE6 mess again. These situations can sometimes happen by accident or for technical reasons. And for me the web is far too important to take the risk.
- munificent 13y ago
  Hi, I'm on the Dart team. > Dart has all the perils of an embrace and extinguish situation even if it is not the intention. I'm not sure what you mean by "perils" here, but if it's just "by deciding to use a product, you could end up following it in a bad direction if they do that", I'm not sure how that's different from any other product. Any technology can go in unpredicted directions. > Developers commit to Dart only to find in the future that the DartVM/Dart2JS targets have differing behavior or levels of attention. Historically, the dart2js team has had as many or more resources than the VM team. If you consider the past a predictor of the future, then this shouldn't be a concern. > And then suddenly Dart apps require Chrome and we end up with same IE6 mess again. That would be pretty crazy of us, though, right? We want our language to be successful. Intentionally making it only work on a minority of browsers (and the unbelievably massive negative political repercussions of doing that) wouldn't exactly do much for Dart's adoption. I'm trying to imagine some nefarious scenario where that could happen, and I'm having trouble conjuring one up. Evil Chrome exec: Well done, minion! Dart is successful and has lots of users! Now is our chance to attack! Evil Dart exec: What have you in mind, O Master? Evil Chrome exec: Now we'll add a feature to Dart that only the VM supports. Users will have to use Chrome in order to run apps that use that feature! Mua-hahahaha! Evil Dart exec: But master, why would a developer use that feature if they know it will prevent millions of users from running their app? Evil Chrome exec: Uh... it will be such a delightful feature they won't be able to resist. Like... I don't know, currying or something. Evil Dart exec: But what happens if someone just sends us a patch to implement it dart2js too? Evil Chrome exec: Well, don't land it, obviously! Evil Dart exec: What should we say in the code review? Evil Chrome exec: Why do you bother me with these details? Just move ahead with our plan! Evil Dart exec: Remind me again what our plan is master? Evil Chrome exec: To force the world to use Chrome! Soon, we will be as successful as IE6 was! Evil Dart exec: Not to question your wisdom, master, but IE is no longer the dominant browser, so that didn't work out well for them, did it? Also, developers now universally revile IE because of their practices. We'd be shunned if we did something like that.
  - spion 13y ago
    What about features like harmony proxies? I'd like to see someone transpiling that to ES5 and getting code that isn't super-slow. Edit: Consider this dummy example: f(a, b) { return a + b; } With operator overloading, the compiler has to account for that, and must transpile to e.g. function f(a, b) { return __invokePlus(a, b); } Unless the programmer adds type hints f(num a, num b) { return a + b; } Edit: mraleph told me that I'm incorrect - apparently the transpiler does global type inference on the code and will only generate a function call if the type needs it (or if it can't figure out the type)
    - munificent 13y ago
      > mraleph told me that I'm incorrect - apparently the transpiler does global type inference on the code and will only generate a function call if the type needs it (or if it can't figure out the type) Exactly right. We need to do that, or numeric code would be impossibly slow when compiled to JS.

by Xelom 13y ago

threeseed 13y ago

Dart has all the perils of an embrace and extinguish situation even if it is not the intention. Developers commit to Dart only to find in the future that the DartVM/Dart2JS targets have differing behaviour or levels of attention. And then suddenly Dart apps require Chrome and we end up with same IE6 mess again. These situations can sometimes happen by accident or for technical reasons. And for me the web is far too important to take the risk.

munificent 13y ago
Hi, I'm on the Dart team. > Dart has all the perils of an embrace and extinguish situation even if it is not the intention. I'm not sure what you mean by "perils" here, but if it's just "by deciding to use a product, you could end up following it in a bad direction if they do that", I'm not sure how that's different from any other product. Any technology can go in unpredicted directions. > Developers commit to Dart only to find in the future that the DartVM/Dart2JS targets have differing behavior or levels of attention. Historically, the dart2js team has had as many or more resources than the VM team. If you consider the past a predictor of the future, then this shouldn't be a concern. > And then suddenly Dart apps require Chrome and we end up with same IE6 mess again. That would be pretty crazy of us, though, right? We want our language to be successful. Intentionally making it only work on a minority of browsers (and the unbelievably massive negative political repercussions of doing that) wouldn't exactly do much for Dart's adoption. I'm trying to imagine some nefarious scenario where that could happen, and I'm having trouble conjuring one up. Evil Chrome exec: Well done, minion! Dart is successful and has lots of users! Now is our chance to attack! Evil Dart exec: What have you in mind, O Master? Evil Chrome exec: Now we'll add a feature to Dart that only the VM supports. Users will have to use Chrome in order to run apps that use that feature! Mua-hahahaha! Evil Dart exec: But master, why would a developer use that feature if they know it will prevent millions of users from running their app? Evil Chrome exec: Uh... it will be such a delightful feature they won't be able to resist. Like... I don't know, currying or something. Evil Dart exec: But what happens if someone just sends us a patch to implement it dart2js too? Evil Chrome exec: Well, don't land it, obviously! Evil Dart exec: What should we say in the code review? Evil Chrome exec: Why do you bother me with these details? Just move ahead with our plan! Evil Dart exec: Remind me again what our plan is master? Evil Chrome exec: To force the world to use Chrome! Soon, we will be as successful as IE6 was! Evil Dart exec: Not to question your wisdom, master, but IE is no longer the dominant browser, so that didn't work out well for them, did it? Also, developers now universally revile IE because of their practices. We'd be shunned if we did something like that.
- spion 13y ago
  What about features like harmony proxies? I'd like to see someone transpiling that to ES5 and getting code that isn't super-slow. Edit: Consider this dummy example: f(a, b) { return a + b; } With operator overloading, the compiler has to account for that, and must transpile to e.g. function f(a, b) { return __invokePlus(a, b); } Unless the programmer adds type hints f(num a, num b) { return a + b; } Edit: mraleph told me that I'm incorrect - apparently the transpiler does global type inference on the code and will only generate a function call if the type needs it (or if it can't figure out the type)
  - munificent 13y ago
    > mraleph told me that I'm incorrect - apparently the transpiler does global type inference on the code and will only generate a function call if the type needs it (or if it can't figure out the type) Exactly right. We need to do that, or numeric code would be impossibly slow when compiled to JS.