564 karma · joined March 29, 2013
Syntax is almost like a religion. You can't make everyone happy. So yes: although we changed the syntax in some areas, we kept the C-like syntax.
Fwiw you can't satisfy every feedback. There are always people that want to make Dart look and behave like their favorite language (be it Java, C#, JS, CS, Python or Ruby), then there are others that just want to boycott Dart, and finally there are simply conflicting views.
While we listened to every feedback we got, we found that feedback from people that had actually tried and used Dart to be the most helpful. They weren't always the loudest, but helped to make Dart a better language.
Most of the work is done completely in the open. See some of the language discussion writeups: https://groups.google.com/a/dartlang.org/forum/#!searchin/mi...
We went public two years ago when the language was still in its infancy so that developers could provide their feedback.
Edit: contrary to your claim we did get feedback and acted on it. Some changes were rejected (like putting the types behind the variables), but it's normal that not every request can be accepted.
If you have suggestions on how we can make Dart even more open-source I would be genuinely interested in hearing them.
Tracking the size of AngularDart: https://github.com/jbdeboer/angular-dart-js-size
I'm working on the client-side (Chrome) and my knowledge in the server area is therefore limited, but from my understanding this would be really hard.
1. Googlers have access to almost all source code. It would be difficult to hide code that just sends data to an outside entity.
2. Google continually monitors its (internal) bandwidth. This is done to optimize traffic, and detect intruders. A rogue Googler would trigger the same traps that are exist for potential hackers.
3. Google's infrastructure changes. You can't just install a gateway to the NSA and expect it to continue working for a long time. It's not as if user-data was stored in simple text-files.
Dart2js needs to see all the libraries that are used. It performs tree-shaking to remove unused parts and then compiles the rest to JavaScript. By default dart2js produces one big JavaScript file, but it can cut your program on library boundaries that can be loaded lazily. This is still work in progress (only allows to split into 2 files so far) but looks promising.
The lazy loading needs to be done by the user before parts of the lazy library are used.
I don't see how event-handlers change the game. The html-library is a library like any other.
for (int i = 0; i < list.length; i++) {
var t = list[i];
}
Things get more complicated when there are function calls in the loop-body that could potentially change the list-length: for (int i = 0; i < list.length; i++) {
foo("random call", list); // could have side-effect.
var t = list[i]; // needs to check bounds.
}
However if the element is read before the call, it should still work: for (int i = 0; i < list.length; i++) {
var t = list[i]; // no need for bounds-check.
foo("random call", list); // could have side-effect.
}
The last example doesn't need a bounds-check, but it does need to reload the length-field of the list at every iteration (in case the length changed).