Monday, November 30, 2015

How Google Uses Angular 2 with Dart

Google is always busy building new web apps, and recently a lot of that development is using Angular 2 for Dart. Just last week, the Google Fiber team launched Google’s first production Angular 2 app, written in Dart. Take a look at their just-launched Angular 2 for Dart app:

The Fiber team has lots of company within Google—Angular 2 for Dart is being quickly adopted by many other Google teams.

Dart is an open-source development platform from Google that makes web and mobile development more productive. The Dart language is a concise yet expressive language that’s familiar to developers coming from Java, C#, ActionScript, and JavaScript. The Dart platform gives you an instant edit-debug cycle, great core libraries, a canonical package manager, a powerful semantic analyzer, and IDE support via IntelliJ IDEA and WebStorm. You can run Dart code compiled to JavaScript on all modern browsers.

We’ve worked closely with the Angular team as they’ve developed Angular and Angular 2, and we’ll be working together going forward. The Angular team’s initial experiences with Dart shaped many different aspects of Angular 2—for instance, Angular 2’s new change detection system and template compilation. Both of these features dramatically sped up Angular 2 for both JS and Dart with 3x faster startup and 2.5x faster rendering than Angular 1. This sort of speedup makes a big difference for our users, especially on the mobile web.

We started our collaboration with the Angular team by working on Google’s internal CRM application, Greentea. The Angular team built the initial version of Angular 1 for Dart as Greentea was built, providing lots of feedback to the Dart team. By working with the Greentea team and the Angular team, we were able to make large improvements in Dart compilation to JavaScript, Dart-JavaScript interop, and IDE support for Dart.

Once Greentea was up and running, the Angular team started working on Angular 2. We’re thrilled to have Dart as a first-class language for Angular 2. Beyond Google Fiber, teams that have publicly announced that they’re currently moving to Angular 2 for Dart include:

  • Greentea, Google’s internal CRM system.
  • Google AdWords, the largest advertising system at Google.

The Google Fiber team told us that they chose Angular 2 for Dart because “Our engineers were highly productive as their projects scaled to many engineers. Dart’s support for strong typing, its object-oriented nature, and its excellent IDE integration really worked for us.”

We're continuing to improve the tools for writing and deploying apps that use Angular 2 for Dart. For instance, we’re adding Dart Analyzer support for Angular 2 templates, which will allow navigation and refactoring across Angular 2 templates and Dart code. We’re also dramatically cutting the JS that’s output by the Dart2JS compiler—“Hello, World” is down to 82KB gzipped, and we’re continuing work to slice that further.

We hope that sharing our experience will convince you to give Angular 2 for Dart a try. Angular 2 for Dart is available for you to try as a Developer Preview now—take a spin through the Angular 2 Getting Started tour now!

Dan Grove and Kevin Moore for the Dart team

Wednesday, November 18, 2015

Dart 1.13 brings improved JavaScript interoperability and more

Dart 1.13 is now available. With this release, you can more easily access JavaScript APIs from Dart code. We've also improved secure networking on the server.

Easier JavaScript interoperability

Dart 1.13 provides a new syntax for creating Dart API facades for existing JavaScript libraries. Facades have the benefits you expect from a Dart library: errors, warnings, and code navigation. They also provide the Dart-to-JavaScript compiler the structure needed to provide interoperability with low code size and runtime cost.

Example facade for Chart.js library

Use the js package to create Dart APIs for your favorite JavaScript libraries. We have an example port of the Chart.js library if you'd like to see how to use these new features in your code.

Graph generated with Chart.js and Dart
We're actively working on tools to generate JS facades from other typed-JavaScript implementations. To track progress, subscribe to this GitHub issue.

Improved secure networking

As we mentioned in September, Dart has transitioned to BoringSSL – a streamlined, Google-maintained implementation of OpenSSL. As part of this change we have updated related APIs to use a standard PEM file for certificates and keys. Note: Existing code that uses TLS/SSH on the Dart VM will have to be updated to use the new APIs, as described in TLS/SSL with Dart.

And more...

The SDK changelog has details about all of the updates in Dart 1.13. Get it now.

Wednesday, October 21, 2015

Highlights from the TC52 meeting on September 21, 2015

Last month we had the 9th TC52 meeting where we discussed a number of additional language features for Dart. Below is a list of the main features discussed - most noticeably the lifting of restrictions on mixins.

DEP update
There is a rich supply of Dart Enhancement Proposals under consideration, and we spent some time discussing the underlying ideas and motivations for several DEPs.

Language extensions and modifications under consideration
Several language extensions and modifications are currently being considered in more concrete terms.

  • Generic methods
    This is the most complicated DEP, in particular with respect to reification of the type arguments and other typing issues. Since the previous meeting work has been conducted on prototyping features relating to this DEP, and the impact on libraries has been explored. Among the big concerns are compatibility and implementation efforts. This might not materialize before 2016.
  • Constant context, constant functions
    One DEP is concerned with constant contexts. They would enable many occurrences of the keyword const to be omitted, based on being part of a larger const expression. An upcoming DEP proposes constant functions, i.e., functions that map constants to constants. Concern was expressed that constants are already rather complex. In general, we wish to keep things more stable than they have been recently.
  • Import configuration
    There are many proposals for how to express configurable imports, in particular with respect to the level of static checking, and the support for library interfaces. These DEPs will not be finalized in this round.
  • Metaclasses
    This DEP proposes that Type objects should have more behavior. Not much has happened in this area since the previous meeting.
  • Relaxing restrictions on Mixins
    Three restrictions on mixin have been in place since their introduction in Dart. A DEP proposal for lifting two of them is available. An implementation of both features is largely ready. In particular, it has been implemented in the virtual machine dart, but work is still ongoing for dart2js.
    The situation is as follows: There was an original proposal encompassing a rather complete feature set. This proposal was restricted, in order to make it more implementable, such that mixins must inherit from Object; mixins cannot contain super calls; and mixins cannot define constructors. We are lifting the first two of these restrictions, and keeping the third one in place at this point.
  • Null-aware operators
    This feature has been adopted into the specification and implemented. It has been very well received.
  • Generalized tear-offs
    This feature has been adopted and mostly implemented. There are still a number of known bugs.
  • Package specification
    The language specification will state that this is an implementation dependent area. The use of a file named .packages to support the semantics of ‘package:’ imports has been implemented, and the detailed approach requires a little more flexibility than the existing specification allows. In general, we do not want to constantly adjust the specification to fit the needs of tools, which means that we will add flexibility rather than detail in these areas.
  • Function
    The type Function has been used in practice as a catch-all type for functions, providing the information that a given object is intended to be used as a function, but omitting information about the number, kinds, and names of arguments as well as their types, and about the return type. Following the current language specification, Function does not have a call method, so a conforming tool (compiler, analyzer, etc.) must warn at every invocation. However, the tools have not been doing that so far. The specification will be adjusted to make Function a special case, such that the omission of these warning will be the correct behavior. We will probably treat Function as a ‘magic type’ that supports call with all shapes of argument list, and returns a value of type dynamic.
  • Function subtyping
    The proposal makes function subtyping covariant in the return type, which is required in order to support message safety and in order to make refactoring safer. We discussed whether or not this topic should be considered to be part of the DEP on generic methods.
  • Library name conflict warnings
    The issue is that many programmers leave out the library directive, which means that they give their libraries the empty name; with two such libraries there is a conflict because they have the same name. The slides suggest that the solution to the problem of conflicting library names is to give them a name based on the URI. However, the decision was actually to treat libraries whose name is the empty string specially, and not give a warning in that case.
  • ‘noSuchMethod’ type checking
    We also discussed the liberalized rule for type checking classes other than Object with an implementation of noSuchMethod(). If a class implements an interface but lacks one of the methods of the interface, or if a concrete class has an abstract method, this usually causes a warning. An exception to this rule is when the class declares a noSuchMethod(). We propose to liberalize this so that an inherited noSuchMethod() suffices (except the one from Object of course).
  • Assert messages
    A new DEP is upcoming, on adding a string message to assert.

The committee unanimously approved the proposal for a 4th edition of the Ecma-408 standard - including the lifting of mixin restrictions. We're now awaiting approval from the Ecma General Assembly in December, 2015. The next TC52 meeting will be held on January 13, 2016.

Tuesday, September 1, 2015

Dart adopts BoringSSL

Starting today, with the 1.13.0-dev.1.0 release of the Dart SDK, the Dart VM has upgraded its TLS/SSL implementation to BoringSSL. The BoringSSL library is a fork of OpenSSL that’s created and maintained by Google. Dart developers now have the same implementation of SSL as Chromium and Chrome.

The new implementation includes some breaking changes to the SecureSocket class and related classes. Dart programs that create secure servers will need to provide their server certificate chain and private key in a new, and easier, way.

We encourage you to try the dev channel build of Dart SDK and the new configurations for BoringSSL. You can learn more about Dart and TLS/SSL, and we look forward to your feedback.

--- Bill Hesse, feeling more secure

Monday, August 31, 2015

Dart 1.12 Released, with Null-Aware Operators and more

Dart 1.12.0 is now released! It contains the new null-aware operators language feature, and enhancements to pub, Observatory, dartdoc, and much more.

Null-aware operators

The new null-aware operators help you reduce the amount of code required to work with references that are potentially null. This feature is a collection of syntactic sugar for traversing (potentially null) object calls, conditionally setting a variable, and evaluating two (potentially null) expressions.

Click or tap the red Run button below to see them in action.


  if null operator. `expr1 ?? expr2` evaluates to `expr1` if not `null`, otherwise `expr2`.


  null-aware assignment. `v ??= expr` causes `v` to be assigned `expr` only if `v` is `null`.


  null-aware access. `x?.p` evaluates to `x.p` if `x` is not `null`, otherwise evaluates to `null`.

  null-aware method invocation. `x?.m()` invokes `m` only if `x` is not `null`.

Learn more about Dart's null-aware operators in our Language Tour.

.packages file

We continue in our efforts to eliminate symlinks by introducing the .packages file, which is a new way to specify where to find package dependencies. The pub package manager now writes a .packages file when getting or upgrading dependencies, and the VM and dartanalyzer use the .packages file for package resolution.

The Dart SDK still generates symlinks in 1.12, but the .packages file gets us closer to eliminating them. If you have tools that introspect packages, now is a good time to investigate the .packages file.


The dartdoc tool is a new way to generate beautiful, fast-loading API docs. It replaces dartdocgen, which we plan to remove from the SDK as soon as 1.13. dartdoc generates static docs, helps you search with find-as-you-type, and looks great on a mobile device.


Speed up your code reviews by automatically formatting your code. The dartfmt tool has been largely rewritten to support better handling for long argument lists, smarter indentation for cascades, nested functions, and collections, and fixes over 50 issues.


Help identify memory leaks with Observatory's updated allocation profiler. Turn it on for a class, and track where instances of that class are created. Also new in 1.12 is support for dart:developer's log() function, which your app can use to stream log calls into Observatory's (or any connected debugger) console.

Stepping through async/await code has been significantly improved with Observatory's new anext command. You can now step over an await call, onto the next line of your code.


The pub run commands can now toggle checked mode, with --checked. Pub now writes a .packages file when getting, upgrading, and globally activating your packages.

Lots more

The Dart SDK 1.12 CHANGELOG has lots more details about various API tweaks. We look forward to your feedback

Thursday, August 20, 2015

A New Way to Share with DartPad

Back in May, we announced the release of DartPad 1.0, a clean and zero-install tool that helps you explore Dart. To create a seamless learning experience for both experienced and new developers, today we released embeddable pads! You can now add live Dart code to web pages.

Embeddable pads have the full power of the standalone DartPad:

Tutorials and guides can use embeddings to quickly demonstrate concepts on the fly:

You can also open embedded pads in DartPad to further edit and share code. For more information, view the embedding guide.

Head over to and share your first pad! We hope you enjoy this new addition and provide us with feedback—remember, sharing is caring!

Posted by George He, Chief Sharing Operator

Tuesday, August 11, 2015

5% smaller output from dart2js

dart2js now produces up to 5% smaller output in the latest dev channel release of the Dart SDK.
We measured a 5% reduction on the minified and zipped dart2js output for one of the larger Dart-based apps in Google with source code size around 17MB. While we’ve seen a 5% reduction on a large app, your milage may vary and improvements are expected to increase with the size of your app. This improvement comes on top of a previous 3% reduction since the beginning of this year.
The idea behind the latest improvement is quite simple: The symbols that will occur most often in the generated output should be assigned the shortest minified names. So when minifying the code, we rename according to the frequency of each symbol in such a way that a high frequency results in a short name in the output.

This new frequency-based namer generally produces smaller output, which is great for deployment. It does however also result in different name allocations and thus “diffing” before/after the change will not produce useful outcomes. Furthermore, with the new scheme a small change in the Dart program might lead to major changes in the naming in the output. If output stability is more important than output size, you can still use the old namer. Simply use the option --no-frequency-based-minification when invoking dart2js.

We are making the new improved namer available on dev channel to get early feedback from you in time before the first release of 1.12 on the stable channel expected later this summer. Please give it a try and report any bugs you might find.

Posted by Stephan Herhut, Frequency-Based Minifier