5 ms·

I liked Dart from the beginning... It could have been a perfect replacement for JavaScript a few years ago, but now with ES6 becoming widely available in browse

I liked Dart from the beginning... It could have been a perfect replacement for JavaScript a few years ago, but now with ES6 becoming widely available in browsers and Node.js, I feel that some of the shine of Dart has been lost. I think the biggest problem with Dart isn't related to the project itself - My biggest concern is that other browser vendors didn't embrace it. Dart has not been universally accepted by all sides, despite the massive amount of publicity which it received over the years. With ES6, I think that JavaScript has proved that it can adapt to change and that it has significant staying power. I think the Dart team made all the right moves, but, unfortunately, so did the JS team. The project hasn't had much luck either. There was no breakthrough. Getting its own native VM inside Chrome would have been nice.

mariusmg 11y ago
"With ES6, I think that JavaScript has proved that it can adapt to change" JavaScript proved squat. Those changes should have been done a long time ago and now we should have had a sane language instead of JS. Betting on JS "evolving" is the wrong way to go.
- incepted 11y ago
  > Betting on JS "evolving" is the wrong way to go. Why? It is evolving. Slowly, but it is evolving. Enough to cast a doubt on the viability of Dart and Typescript.
  - cwyers 11y ago
    I think Typescript is in a different boat. All valid JS is valid Typescript, and Typescript is adding new JS features faster than browsers can. If JS ever catches up to Typescript it'll be by becoming Typescript, basically.
  - deleted 11y ago
    [deleted]
- sudhirj 11y ago
  The rate at which JS evolves has been determined quite rightly by browser market share and aut0-updatability. When your clients need to upgrade their VM when your language changes, the only way to ensure progress is to make sure all your clients are running latest auto-updating versions. This is beginning to happen now, which is why the V8 and the language itself can start to make real progress.
- rnnr 11y ago
  If we got beaten with plain JS imagine what would happen with ES6! :)
sdegutis 11y ago
Meh. JavaScript isn't horrendous. It's not great, but every language has its flaws, even ES6. It gets the job done and lets us make stuff and go home at the end of the day having made stuff. It's good enough.
- pekk 11y ago
  Without starting any religious wars, I think we could all name at least one language that is very poorly and even dangerously designed, even though it lets you make stuff which sort-of works and earn money.
  - munificent 11y ago
    Hey now. Let's not bring COBOL/C/C++/VB/Perl/MEL/PHP/MUMPS/JS into it.
- monyr75 11y ago
  This attitude is the enemy of progress.
rbehrends 11y ago
I think it's a mistake to see Dart primarily as an alternative to Javascript in the browser. While this is certainly how Google initially tried to market it, Dart always was designed around having its own VM, and as a result, it is actually more of a competitor for Python, Ruby, or Node. Even the original move to provide an alternative to Javascript in the browser was not primarily because Dart was a different language, but because the Dart VM wouldn't be constrained in the same way that Javascript VMs were.
azakai 11y ago
> I think the Dart team made all the right moves They did do a lot right. But two big things that hampered adoption, I suspect, are * Working on Dart in secret for a while and unintentionally revealing it to the world in a leaked email. This made it look threatening from day one, since the email seemed to imply covert plans to replace JavaScript. The impression may have been partially wrong, but given those circumstances, there was a negative initial impression. * Intending to ship the Dart VM in Chrome, despite no interest - and some opposition - in standardization from all other vendors. That worried a lot of people in the web community, both because of policy reasons (vendors shouldn't ship that way; it's even against Google's own Blink principles) and technical reasons (the intent was to polyfill in other browsers, but semantic differences - e.g. in numeric types - meant that was risky). In the end Google didn't ship the VM, despite years of massive efforts towards doing so, but the damage was already done. And some more minor things that I think were problems as well: * Dart's syntax looked "Java-esque" to many people. Java isn't in fashion anymore. Yes, the goal was be a familiar and natural language, but it achieved that goal primarily for Java devs. Which is a large group inside Google, of course (hence other projects like GWT and Closure Compiler), but in the larger web dev community, "looking like Java" is a downside. * The already-mentioned semantic differences on numeric types between the VM and the polyfill. Calling it "undefined behavior" excuses the difference, but the risk of web compatibility remains - undefined behavior makes more sense for a source language like C or C++, where you ship binaries, and not for the shipped code, especially on the web. As far as I know, this was never resolved, because harmonizing those semantics had too much of a perf hit, despite attempts to optimize things. Perhaps there was too much optimism in early days that this could be achieved.

mariusmg 11y ago

"With ES6, I think that JavaScript has proved that it can adapt to change" JavaScript proved squat. Those changes should have been done a long time ago and now we should have had a sane language instead of JS. Betting on JS "evolving" is the wrong way to go.

incepted 11y ago
> Betting on JS "evolving" is the wrong way to go. Why? It is evolving. Slowly, but it is evolving. Enough to cast a doubt on the viability of Dart and Typescript.
- cwyers 11y ago
  I think Typescript is in a different boat. All valid JS is valid Typescript, and Typescript is adding new JS features faster than browsers can. If JS ever catches up to Typescript it'll be by becoming Typescript, basically.
- deleted 11y ago
  [deleted]
sudhirj 11y ago
The rate at which JS evolves has been determined quite rightly by browser market share and aut0-updatability. When your clients need to upgrade their VM when your language changes, the only way to ensure progress is to make sure all your clients are running latest auto-updating versions. This is beginning to happen now, which is why the V8 and the language itself can start to make real progress.
rnnr 11y ago
If we got beaten with plain JS imagine what would happen with ES6! :)

sdegutis 11y ago

Meh. JavaScript isn't horrendous. It's not great, but every language has its flaws, even ES6. It gets the job done and lets us make stuff and go home at the end of the day having made stuff. It's good enough.

pekk 11y ago
Without starting any religious wars, I think we could all name at least one language that is very poorly and even dangerously designed, even though it lets you make stuff which sort-of works and earn money.
- munificent 11y ago
  Hey now. Let's not bring COBOL/C/C++/VB/Perl/MEL/PHP/MUMPS/JS into it.
monyr75 11y ago
This attitude is the enemy of progress.

rbehrends 11y ago

I think it's a mistake to see Dart primarily as an alternative to Javascript in the browser. While this is certainly how Google initially tried to market it, Dart always was designed around having its own VM, and as a result, it is actually more of a competitor for Python, Ruby, or Node. Even the original move to provide an alternative to Javascript in the browser was not primarily because Dart was a different language, but because the Dart VM wouldn't be constrained in the same way that Javascript VMs were.

azakai 11y ago

> I think the Dart team made all the right moves They did do a lot right. But two big things that hampered adoption, I suspect, are * Working on Dart in secret for a while and unintentionally revealing it to the world in a leaked email. This made it look threatening from day one, since the email seemed to imply covert plans to replace JavaScript. The impression may have been partially wrong, but given those circumstances, there was a negative initial impression. * Intending to ship the Dart VM in Chrome, despite no interest - and some opposition - in standardization from all other vendors. That worried a lot of people in the web community, both because of policy reasons (vendors shouldn't ship that way; it's even against Google's own Blink principles) and technical reasons (the intent was to polyfill in other browsers, but semantic differences - e.g. in numeric types - meant that was risky). In the end Google didn't ship the VM, despite years of massive efforts towards doing so, but the damage was already done. And some more minor things that I think were problems as well: * Dart's syntax looked "Java-esque" to many people. Java isn't in fashion anymore. Yes, the goal was be a familiar and natural language, but it achieved that goal primarily for Java devs. Which is a large group inside Google, of course (hence other projects like GWT and Closure Compiler), but in the larger web dev community, "looking like Java" is a downside. * The already-mentioned semantic differences on numeric types between the VM and the polyfill. Calling it "undefined behavior" excuses the difference, but the risk of web compatibility remains - undefined behavior makes more sense for a source language like C or C++, where you ship binaries, and not for the shipped code, especially on the web. As far as I know, this was never resolved, because harmonizing those semantics had too much of a perf hit, despite attempts to optimize things. Perhaps there was too much optimism in early days that this could be achieved.