The Fall and Rise of Dart, Google’s ‘JavaScript Killer’

Seven years ago, Google unveiled Dart, a general-purpose programming language. Version 1.0, released in late 2013, was meant as a replacement for JavaScript in browsers; it also had its own virtual machine (VM) for running native applications in the Chrome browser.

Dart’s syntax is C-like, meaning that developers used to C++, Java, and JavaScript should (theoretically) feel at home with it. In addition, Dart’s engineers added generics, static typing, and (later) SIMD support for greater throughput.

The big question is whether Google originally intended Dart to replace JavaScript (Google engineers were reportedly frustrated with maintaining massive JavaScript code bases for Gmail and Google Maps, and began working on an alternative language). The company even released “Dartium,” a Dart-centric browser, possibly with an eye toward eventually replacing Chrome. Whatever Google’s intentions (and despite a huge marketing push aimed at tech pros), developers still preferred to stick with JavaScript. (Although Google never outright called Dart a “JavaScript killer,” that was the moniker that some news outlets attached to it.)

But that wasn’t the end of Dart. Indeed, it might be on the upswing, thanks to the emergence of Flutter, Google’s UI framework for building native interfaces in iOS and Android. “We architected Flutter to be able to support glitch-free, jank-free graphics at the native speed of your device,” read a December posting on Google’s Developer Blog. “Flutter code is powered by the world-class Dart platform, which enables compilation to native 32-bit and 64-bit ARM code for iOS and Android.”

Google is very much “all in” on Flutter (at least for the moment), using it to develop and run internal apps such as Google Ads for iOS and Android. For third-party developers, things are a bit more problematic—for instance, it’s questionable whether Flutter will let them tap into certain native frameworks—but there’s still enormous potential for Flutter to become an essential part of new and existing projects.

If that wasn’t enough, Google’s Fuchsia (an open-source operating system) is also built with Dart, and the recently introduced Google Home Hub will possibly run Fuchsia in the future. Will Fuchsia eventually replace Android? That’s a much harder question to answer, as Android’s massive install base makes it difficult to root out.

Dart 2.0

Some developers like to compare Dart to Swift, Apple’s latest programming language (designed to replace Objective-C, which was the go-to language for iOS and macOS apps for more than three decades). You can see the similarities between the two languages on this webpage, which offers a side-by-side-by-side comparison between Dart, Swift and Kotlin.

Early 2018 saw the roll-out of Dart 2.0, which featured improvements to client-side development, including strong typing and “UI as code” (i.e., eliminating the need for context-switching, so that developers don’t have to keep flipping between the programming language and a separate UI markup language).

While those improvements no doubt made things easier for developers already using Dart, the language hasn’t yet broken into the top 20 on the PYPL Popularity index; likewise, it hasn’t penetrated the Top 20 on the TIOBE Index. All that being said, I fully expect it to eventually move up in the rankings.

Why? For starters, Flutter is easy to program in, and harried developers generally like the idea of developing cross-platform with a single code-base (especially when you can hot-load changes; either ‘Save All’ or click the ‘Hot Reload’ button, and the change is pretty much instantly live in the emulator—and after the reload, it carries on with the same values as before). Flutter/Dart also supports IDEs such as Visual Studio Code, Android Studio, and Intellij Idea.

Other strengths of Dart include the various compilation types. On mobile devices, it has to compile code Ahead-of-Time (AOT), which gives fast execution and low start-up time; but for development it also compiles in Just-in-Time (JIT) (which is what powers hot reload). This gives the best of both worlds, as purely AOT compilation makes development slower—once you’ve tried hot reload, you will not want to go back to AOT compilation during development.

Plus, Dart has a third compile option, which is compile to JavaScript, making it possible to share code between mobile and web applications.

Flutter

Dart allows Flutter to update the display at 60 or even 120 frames per second (if the hardware supports it), which are frame rates more typical of games. Flutter has adopted a similar architecture style to React Native, except that compiled Dart code deals directly with pixels. It does this through its own widgets, not those supplied in iOS or Android.

There was a saying twenty years ago that “everything in Windows is a window,” and in Flutter, the same is true: “Everything is a widget.” For iOS, Flutter includes Cupertino, a package of widgets for iOS-look-alike controls.

Flutter Widgets are immutable and only exist until they need to be changed; then a new tree of widgets is created. As a result, Flutter is able to run at high frame rates consistently, and uses Dart’s fast garbage collection to make that happen.

The MyApp class below is an example of a simple “Hello World” widget; together with the main() call, it’s the smallest Flutter application. It takes over a minute for first compile; after that, time reduces to under a second (thanks, hot reload!):

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return new Center(
        child: Text("Hello World!", textDirection: TextDirection.ltr));
  }
}

A New Programming Style

Although Dart is a typical static-typed OOP language, using it in Flutter is a bit different; for mobile developers used to Java or Swift, it requires a different approach. There is no declarative syntax akin to .xaml files in Xamarin Forms or .nib in iOS. Everything is defined by creating Dart code for widgets.

At first glance, this might sound quite tedious, but hot reload makes it very fast to experiment with complicated user interfaces. The downside is that you have some large files to define a widget; for example, in Red Brogdon’s open-source flutterflip reversi clone, the main game board widget is around 170 lines long.

Another plus: There are no issues regarding Dart formatting, as the Dart plugin includes a Dart formatter; a single right-click in one of the IDEs tidies up your code.

Conclusion

Flutter/Dart work very well together. The only problems I’ve experienced are importing projects between IDEs; the location of Dart and Flutter SDKs varies between everyone’s PCs, and so those need to be configured.

If you are a current iOS or Android developer, you may face a bit of a learning curve if you choose to embrace Flutter. However, it might be worth the jump—both for hot reload (an awesome feature), and for the opportunity to work cross-platform.

11 Responses to “The Fall and Rise of Dart, Google’s ‘JavaScript Killer’”

  1. I’m just tired of jumping from language to language. I can’t remember how to use typescript and I used it exclusively in 2016. Then 2017 was the year of cpp and emscriptem… Now I’m in go dealing with the oop is the devil crowd but don’t worry we compile to wasm and are just as good as cpp. Maybe I’ll just write everything in es6 my happy place….

  2. Jeff Jones

    I would much rather use Xamarin.Forms with C# and XAML. Native apps, cross-platform, supports using controls native to the OS, or controls that look the same across platforms. Plus the server-side WebAPI service in C#, all within the same solution.

    For me, Dart is dead, just as for me JavaScript is dead with Blazor (MS’s webassembly approach using C# and HTML).

  3. nonybrighto

    Switching from one language to the other can be really stressful but I didn’t get that feeling when switching to dart. It felt natural. Having Javascript and java knowledge was enough. The language is really easy to pick up!