DDC is meant to be used by build systems like bazel,
flutter_tools under the hood. This compiler is not meant to be used by application developers directly.
Some Dart concepts don't map directly:
Libraries. Multiple Dart libraries are mapped to a single JS module. Each library appears as a first class object in the generated JS module, with its top-level symbols as members. We currently use a heuristic (based upon file paths) to ensure unique naming of generated library objects.
Generics. Dart generics are reified, i.e., they are preserved at runtime. Generic classes are mapped to factories that, given one or more type parameters, return an actual ES6 class (e.g.,
HashMap$(core.String, core.int) produces a class that represents a HashMap from strings to ints). Similarly, generic methods are mapped to factories that, given one or more type parameters, return a method.
Dynamic. DDC supports dynamically typed code (i.e., Dart's
dynamic type), but it will typically generate less readable and less efficient ES6 output as many type checks must be deferred to runtime. All dynamic operations are invoked via runtime helper code.
Constructors. Dart supports multiple, named and factory constructors for a given class with a different initialization order for fields. Today, these are mapped to instance or static methods on the generated ES6 class.
Private members. Dart maps private members (e.g., private fields or methods) to ES6 symbols. For example,
a._x may map to
_x is a symbol only defined in the scope of the generated library.
In general, the current conventions (i.e., the Application Binary Interface or ABI in compiler terminology) should not be considered stable. We reserve the right to change these in the future.
DDC currently supports Chrome stable (though users have had success running on FireFox and Safari).