Category Archives: Web

See Dart … Java?

About a month ago, Google made headlines when an email describing ambitious plans to re-create JavaScript was leaked to the web. This email created quite a stir and spawned numerous debates ranging from the hubris of Google in trying to single-handedly replace such a ubiquitous staple of the web to the possible merits of Google’s decision on a technical level and the kinds of exciting innovations that could occur.

While I personally didn’t feel great about Google’s actions, I decided to reserve my public judgement for the time when Google actually released the language. Two days ago, that finally happened. So, let’s take a look:

main() {
  print('Hello, Dart!');

Ummm … ok. This chunk of code looks similar to JavaScript, so that’s not all bad. However, I was really expecting something more groundbreaking in terms of syntax. While I don’t loath semi-colons as line endings (you have to have something, right?) the new trend these days is to exclude them. Specifically coming from a JVM perspective Scala, Groovy and Clojure, three of the most popular Java alternatives, are happily semi-colonless. Also, as Google has deep Python roots, I expected they’d create something with a more “modern” syntax. But that’s ok … I can live with semi-colons. Let’s dig a bit through the Dart sample source code (can currently be found on Dart’s Google code page).

Check out (I’ve removed the comments for brevity):

class BiIterator<E> {
  ObservableValue<int> currentIndex;

  List<E> list;

  BiIterator(this.list, [List<ChangeListener> oldListeners = null]): currentIndex = new ObservableValue<int>(0) {
    if (oldListeners != null) {
      currentIndex.listeners = oldListeners;
  E next() {
    if (currentIndex.value < list.length - 1) {
      currentIndex.value += 1;
    return list[currentIndex.value];

  E get current() {
    return list[currentIndex.value];

  E previous() {
    if (currentIndex.value > 0) {
      currentIndex.value -= 1;
    return list[currentIndex.value];

  void jumpToValue(E val) {
    for (int i = 0; i < list.length; i++) {
      if (list[i] === val) {
        currentIndex.value = i;

When I first saw this code, I instantly recognized a very similar syntax to Java 5 generics. Eerily similar, in fact. As powerful as Java generics are, not too many people like the syntax. To port what many consider to be kruft to a brand new language is an odd choice.

Another interesting thing about this code is the inclusion of strict comparison operators (i.e. ‘===’ and ‘!==’, see line 31 for an example). While the use of these operators is instantly recognizable to those of us who regularly use JavaScript, I think it a very odd decision to include these operators in a brand new language. They are, essentially, a JavaScript oddity that often confuses people when they first learn the language.

So far, things aren’t looking great for Dart.

There is hope, however: Dart has great support for concurrency. It implements a version of the Actor model (see for details) placing code into Web Workers behind the abstraction. Concurrency is rarely easy and the Actor model is a great way to abstract that kind of complexity away from the developer.

So, let’s take a look at a basic Actor (Dart’s interface is called an Isolate):

class Printer extends Isolate {
  main() {
    port.receive((message, replyTo) {
      if (message == null) port.close();
      else print(message);

main() {
  new Printer().spawn().then((port) {
    for (var message in ['Hello', 'from', 'other', 'isolate']) {

Huh. It doesn’t look terrible, but I’ve been doing a lot of Scala development recently and Scala also happens to have actors. Let’s take a quick look at how Scala might implement the above code:

import scala.actors.Actor._ 
val portActor = actor {
    while (true) {
        receive {
            case msg => println(msg)
List("Hello", "from", "other", "actor").foreach( word => portActor ! word)

Granted: these are both contrived examples. However, look at the Scala version. It’s doing some tricks like importing a static Actor but it is still, at least to my eyes, much more readable and elegant than the Dart version. While it’s nice to have an actor-based model for client development, I feel like Dart’s falls short in comparison to Scala’s state of the art implementation. Again, considering this is a brand new language, this is puzzling.

Finally, Dart itself can either be executed in a virtual machine or transpiled to JavaScript for execution in a browser. Since most browsers outside of Chrome won’t have much support for a native Dart VM in the near future, let’s take a look at Dart’s transpiling overhead. This is probably all you need: Dart’s ‘Hello World’ application transpiled to over 17,000 lines of JavaScript. Wow. To be fair, this overhead has to do with setting up Dart’s optional typing system and other niceties of the language which is more akin to including a library. As such, this isn’t an apples-to-apples comparison with JavaScript itself or something like CoffeeScript which transpiles in a more one-to-one fashion.

But still. Wow.

So, at least for now, it seems like Dart is a bit of a snooze. As much as I was disappointed in Google with not being more open about the development of Dart, I was also excited in seeing something that would simply blow away JavaScript and set the stage for something ground-breaking (maybe something like “ScalaScript”). Dart is not that. Core Java developers will likely feel right at home with Dart, but I can’t see the huge community of client-side JavaScript engineers being very excited about this.

Dart, I am disappoint.

Why Chrome OS Likely Doesn’t Matter Anymore

In July of 2009, Google announced a new operating system based on the Chrome browser: ChromeOS. The idea was all applications would run inside the browser and the underlying OS would only provide enough functionality to allow the browser to load. All data would reside “in the cloud”.

I remember that announcement very clearly and how excited I was. I even went around buying up domain names of web applications I thought ChromeOS would need and I would famously build in my spare time (anyone interested in a barely used I felt ChromeOS would be the perfect solution for casual users like my parents performing relatively lightweight tasks like viewing and storing photos, music, and documents. The ultimate “thin client” had finally arrived.

On January 27, 2010, Apple announced the iPad and things began to change. Many people, including myself, grew to think that a tablet could fill the casual computer user space better than a small notebook. The iPad is cheap, light, easy to use, and gets stellar battery life. And, not only does it have a very healthy app ecosystem, it also runs modern web applications extremely well. It’s the best of both worlds. Android also stands to perhaps fill that need in the near future with the same split of a native app ecosystem and an advanced web browser.

A few days ago, Google finally released reference hardware of ChromeOS to a fair amount of fanfare. While I’m still intrigued on the concept, the overall idea is much less exciting to me. Before the iPad, I could easily picture an ecosystem that didn’t bother with native applications.

Now, I’m not so sure.

The Platform
There’s a reason the “thin client” model never really materialized and I don’t see that changing any time soon. For the end user, and especially the casual end user, the fact that the “OS is a browser!!1!!1!” doesn’t matter nearly as much as the actual experience. Browsers have come a long way, but curated and tailored experiences are still very valuable and users have demonstrated they are willing to pay a premium for them.

In short, the application platform is really irrelevant to most people. What matters is a great experience. Both the iPad and MacBook Air turn on almost as quickly as you can press a button or open a lid … just like ChromeOS. Does it matter that one is a “thin client” and the other two aren’t?

The “Cloud”
I agree that remote data storage is a valuable thing for casual users. Issues of privacy aside, it’s extremely convenient to have access to documents, photos, and media regardless of location.

But we already have that. We can view and edit documents stored on the Internet from your phone, laptop, and desktop today. We can access Facebook and Netflix from a Samsung TV or an iPhone. What exactly is ChromeOS providing that adds something unique and new? Will it do it dramatically better? So far, I’m not seeing it.

Before the iPad, the cheapest way to get into casual computing was the relatively poor experience of an entry level “netbook”. Today, you can easily get a great casual computing experience for under $500. ChromeOS may have promised a much lower price point and better quality in 2009, but the bar has moved a lot since then.

I don’t know what’s going to happen with ChromeOS, but I honestly don’t see it gaining a lot of momentum. I see a future in which casual users will connect to their data with tablets, TVs, and phones and the more advanced users will continue to use powerful laptops and desktops.

All Good Things …

A little over two years ago, while on the home stretch of my computer science degree, I decided to leave the contracting position I had been employed with for almost four years and move into full-time employment as an engineer. While I had a few reasons for doing this (less headaches with healthcare, taxes, etc.), the biggest reason was to position myself in an environment where I could gain experience working in a fast-moving (read: agile) team alongside a more “cutting edge” technology stack.

Truth be told, it wasn’t hard for me to find a new gig. I got a few different offers after interviewing around town for about two weeks. While all the positions seemed promising, my gut pushed me towards a small startup in downtown Denver that was working to grow their product and engineering staff from the ground up.

Things turned out very well for me, and I truly can’t say enough about the position and the people I worked with. The position was fast and demanding and I was able to put my hands on a large amount of great tooling and frameworks on all levels of the development stack.

However, all things eventually end and I’m happy to announce that tomorrow I start a new gig as a senior user interface engineer at Time Warner Cable.

The engineering staff that TWC has been able to assemble in the last few months is extraordinary, and they are working on projects that are, quite honestly, right up my alley.

I’m pretty excited about this move. The web user interface technologies that exist coupled with those that are quickly solidifying (HTML5, CSS3, etc.) represent some of the most exciting areas in computer science, engineering, and design today. For a guy like me, there is nothing better than working with this type of tech!