floitsch

In JavaScript every object is basically a hashtable. In order to get acceptable performance JS engines build type descriptions ("hidden classes" or sometimes just "maps") behind your back. That is, if you create a JS object (hashtable) with fields `x` and `y` it will create a hidden class with those two fields. This way it can access the fields efficiently. See http://mrale.ph for much more information on JS engines.

These hidden classes are built on the fly: say you add `x` to a instance to get an object with a configuration that was never seen before. In that case, the engine creates a new description with that new field and remembers the transition (so that further objects with similar configurations can reuse the same hidden class).

Keeping track of these hidden classes takes time and space. If you actually use the JS object as a hashtable, then there will be lots of unnecessary hidden classes, that will never be used again. However, there is a trick to tell the engine that an object is actually a hashtable (and shouldn't be optimized as if it was an instance of a class): when deleting a field from an object v8 (and probably all other engines) assume that the object is used as a hashtable and don't create these hidden classes anymore.

Dart2js uses this trick to avoid this cost some important big hashtables (`B`, `C`, ...).

Dart2js was there from the beginning and the project was always well stuffed. It was never an afterthought and some decisions in the Dart language were taken because of the constraints we have when compiling to JavaScript.

Disclaimer: I'm the TLM of dart2js.

The dart2js team is one of the teams with the most developers on it. There is a huge effort going into it.

Dart2js generally does a good job, but a few features (like mirrors) that are still in beta-quality, are currently a constant source of grieve for the developers. We would have liked to delay their release until they were more stable, but several customers really, really needed them.

Things are getting better, though, and I hope that dart2js will fade into the background (as a simple working tool) soon.

It was recently added, but apparently removed again. (I don't know the exact reasons).

Edit. you can see the announcement here: https://plus.google.com/109866369054280216564/posts/XbjvN5QV...

Edit2. Removal of the feature: https://code.google.com/p/dart/issues/detail?id=16425

I was the TL of the libraries for almost a year, and there are good reasons we didn't go this route:

- it adds overhead. Being able to write JSON.encode(customer) would mean that every class needs to retain its field names. Minification could still work if this information is stored on the side, but it would add overhead.

- it doesn't make sense to automatically encode elements that cannot be decoded. You should have: x =~= JSON.decode(JSON.encode(x)). (where x =~= y means that the two objects are Json-equivalent).

- The Dart-Editor already provides a quick-fix to write a toJson for you. To be honest I'm not really a fan of it, since I believe that serialization information should be outside the object, and not in the object (that's what "toEncodable" is for), but that's another story.

- It's extremely easy to get the behavior you want. Just use (or write, if none exists yet) a package that has your intended behavior. This is really a one-line change... This way you pay the price when you want to, and don't force it on all users.

That's not really the problem. Web developers have learned from the past and don't just build web-pages for one browser only. On the contrary... Developers now sometimes need to support outdated browsers with little market share (IE8 for example), instead of actively pushing the users to upgrade.

The discrepancy between Dart and JS numbers is mostly an issue for the developers. When they deal with numbers in specific ranges, they need to run dart2js more frequently (to test if their code works) instead of relying on Dartium (and its F5 development cycle).

After 2 years of Dart development, numbers have rarely been an issue in practice. Developers know when they deal with numbers > 32/53bits and work around it.

According to twitter, upgrading to FF 26 fixes it.

The VM works on MIPS too.

The main repository is currently SVN. When Chromium switches over to Git, we will probably follow suit. At some point there was a clone on Github, but I don't know by heart if it still exists.

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.

Current HEAD of dart: https://code.google.com/p/dart/source/browse/#svn%2Fbranches...

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.

Are you sure you are using the latest version? Angular was an early user of mirrors (reflection) which (more or less) disabled the tree-shaking of dart2js. This was recently improved.

Tracking the size of AngularDart: https://github.com/jbdeboer/angular-dart-js-size

Disclaimer: I work at Google.

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.

This is a property of dart2js. (I wouldn't call it a limitation nor a feature). Dart2js takes your whole program and compiles it to JavaScript.

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.

dart2js does range analyses. For example the indexing in the following example will not do any bounds checks.

    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).