As long as the Dart specification is not governed gy a body encompassing all major browser vendors, this is a very dangerous development (And yes, I know that being governed by a standards body seriously hampers the evolution of a standard, but everything is a tradeoff...)
This is nothing like IE, which is actually proprietary and closed-source. In contrast, there is absolutely nothing about Dart that's proprietary. Dart is 100% open source, including patents grants, it's completely developed in the open and for the last 2 years has seen steadily progress with feedback from the public mailing list. It's actually a goal for the project that everyone is able to freely use Dart in any capacity. Lars Bak already said that after 1.0 is shipped they're going to work on getting the language standardized. There is nothing legal or technical stopping other browser vendors using Dart, any hesitations are 100% political.
Dart is finally the first real alternative where we may be able to progress beyond JavaScript, that as a core objective also compiles to first-class JavaScript, i.e. many features dismissed because it couldn't be efficiently transpiled to JS. I care about progress, the current state of web development is fragmented and broken, we need to be encouraging more initiatives like Dart that challenges the status-quo and is able to progress past the fragmented inconsistent mess we have to deal with now in trying to develop complex, rich, high-performance web apps.
Also Google has shown signs of embrace, extend extinguish when it comes to essential parts of Android, which makes me a bit wary.
I would love nothing more that Dart superseding JS as the goto language (and compile target) for browser development, as it is doubtless a step forward. But there are pitalls hidden on the way there and the outcome is determined by the path we will take.
Of course hesitations are political, because the outcome will be determined by political actions of everybody involved, Google, MS, Apple and Mozilla. Technical merits alone don't guarantee a happy outcome, sadly.
Luckily unlike other walled gardens, the quality of Dart2JS, i.e. first-class source-maps support and many benchmarks showing it even outperforms hand-crafted JS, ensures that Dart apps will continue to benefit and run in other modern browsers even without their support, where the only difference will be the start-up and runtime performance of the running code, so we end up getting it back down to technical merits.
> Dart maybe open source but it still a proprietary, non-standard solution
You use the word 'proprietary' but I don't think it means what you think it means. It doesn't mean you have complete access to the entire source code implementation and freedom to use all of it or any of it, in anyway you see fit. It doesn't describe a project that's driven by feedback in a public mailing list, that welcomes external feedback and contributions, and it's rarely used to describe a project with a core goal for it to have no-legal-or-technical-barrier, free access, encouraging its wide-spread adoption.
By your definition most Open source projects are proprietary and non-standard, where most programming languages aren't even standardized, the difference with Dart is that it actually has the commercial backing that can justify the effort in actually getting it standardized, which it plans to do now that Dart 1.0 is shipped, just as Lars Bak announced at Google IO.
Again like many OSS projects, the Dart project has taken external contributions, but the brilliant minds that Google have brought in to work on Dart full-time are indeed being paid to do so. It's not uncommon, to accept Q/A verified external contributions but to ensure only employees have free reign and project-wide commit access. Even Dart's internal contributions still have to go through a Q/A code-review process.
Web Components and polymer is a good example of the power and re-use enabled by encapsulation. The http://www.polymer-project.org goal is that you can integrate and re-use Dart web components, Angular JS components, Firefox x-tags, etc within the same web app. Which is unprecedented in the fragmented world of JS.
Why would anyone do that? We have a super nice solution for that. It's called "site-specific browser" or SSB.
It's like a browser without address bar, which automatically opens a specific URL on start up.
You can have one per intra-/extranet application and you can update them individually on a as-needed basis.
You get all of the benefits of a fixed platform without any of the downsides. Well, you'll need a little bit more RAM and and a little bit more HDD space, but that really shouldn't be an issue.
These situations can sometimes happen by accident or for technical reasons. And for me the web is far too important to take the risk.
> 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.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)Exactly right. We need to do that, or numeric code would be impossibly slow when compiled to JS.
Sometimes it pays off to watch the sessions. :)
A good developer should try to get as much information as possible about his/her tooling.
I remember the days where all I could learn about computers was trial and error, helped by what the local library could offer, if anything.