Mixbook sees 'perfect storm' for Google's Dart language (Q&A)

Google's Dart programming language, an attempt to outdo JavaScript for writing Web apps, has had a polarizing effect on the Web.

Mozilla and Microsoft don't like it, preferring to focus on improvements to the incumbent technology, JavaScript. But Google, which just released Dart 1.0, aims to speed up Web-based software and the programmers who write it.

One company, Mixbook, which is firmly in the pro-Dart camp, is betting on Dart with a service that stands to offer millions of dollars in annual revenue.

"Google has set up a perfect storm for a new language," said Mixbook co-founder and Chief Executive Andrew Laffoon. The company picked Dart to power Montage, its new online tool for creating photo books, after comparing it to JavaScript and Microsoft's TypeScript, which extends JavaScript with more advanced programming options.

The Dart debate may seem like something only coders need to care about, but it affects anyone who uses the Web.

Annoyed at how primitive a Web app interface is compared to native software? Tired of waiting for slow Web pages to load on your phone? Worried about "drive-by attacks" that load malware onto your computer just by visiting a Web site? These issues are at the heart of the matter.

Dart exists separately from the Web, running in a special-purpose Google variation of Chrome called Dartium. Ultimately, Google hopes to build Dart into Chrome, but for now, it offers a tool called dart2js that compiles Dart source code into ordinary JavaScript. That lets Dart software run in non-Dart browsers -- and that's what is prompting Mixbook to embrace Dart.

"When it natively compiles to JavaScript, its performance is the same or better," Laffoon said. "And it's better for programmers."

CNET News' Stephen Shankland discussed Dart and the Montage tool with Laffoon and with Dan Schultz, who as chief front-end engineer is responsible for Mixbook's online tools. Here's an edited transcript.

Stephen Shankland: Let's start with some background on Mixbook. Can you give me the thumbnail sketch?
Andrew Laffoon: We started the company seven years ago with the vision to build the best experience to create photo books. At the time it was a small, new market. The books themselves were interesting, but the interfaces to create the products were terrible. We created our first service, Mixbook.com, and grew that to significant scales. We did $25 million in revenue last year.

Now mobile is the most popular camera in the world. iPhone and Android are now significantly more popular to take photos than Canon and Nikon. People are taking many, many more photos than they did in history and doing more things with them. Montage is somewhere between Mosaic (the company's mobile book-making app) and Mixbook (the company's original online tool). Our original interface was all built using Flash. It was the rich Internet technology of the day back in 2007. Today, that's not the case. It's not useable outside PCs, so we have been looking for a new technology.

With Montage, are you reproducing what you had with Flash? Has the vision changed, or just the platform?
Laffoon: When we started, the photo book market was small. We did a lot of research and found that there's this under-served niche of people who want to make the books exactly the way they want. We came out with this tool for that. We went the direction of the scrapbooking people. They loved it. They're viral -- they love to tell family about it -- and they're happy to spend 10 hours making a book.

Most of us do not want to spend 10 hours. So we've been focused for the last two years on the 90 percent of people who do not take 10 hours to make a book. That's why we did Mosaic: What if you could make one in 2 minutes? The same philosophy underlies Montage. With Montage, we built a deep technological understanding of photos. We developed a technology called photo relational mapping. It looks at something like 20 different elements of every photo and how they relate to other photos and uses that to arrange photos.

Just the content, or the metadata, too -- things like time stamps and geotags that say when and where a photo was shot?
Laffoon: It uses them all together -- the people in the photo, the content in the photo or a group of photos. If you have 5 photos in a row of a newborn and in only one she's smiling, we detect that. We can tell emotions. There are 20 or so different essential aspects of photos to really understand to solve the core challenges. You get a book in 10 minutes, but it's beautiful. It knows which to use, how to crop them, how to arrange them on a page.

All that processing happens on the server?
Laffoon: Right.

So now let's find what's happening on the browser in JavaScript.
Dan Schultz: When we started Montage, we want to transition away from (Flash programming language) ActionScript to the open Web. We wanted something we would feel productive in, something mature enough to build a large Web app today, and something we felt would be the right tech platform for the future. We looked at JavaScript, briefly looked at TypeScript, and looked at Dart.

With JavaScript, we felt it didn't have the right ingredients to build a large-scale Web app. It doesn't have namespaces, and there were language surprises, which for programmers is a bit frustrating. TypeScript adds classes and interfaces and namespaces, but you still have to deal with the language quirks of JavaScript.

Then we started looking at Dart and were excited about what it brings to the table. If you're a Java developer, C or C# developer, even a Ruby developer, you can pick it up really quickly. It gives you classes, something new called mixins, and optional typing. I can type in the arguments for my functions and the properties for variables and classes. Another programmer can pick it up and understand what my code is. And it's got support for libraries. You can break up your app into a lot of different modules.

And Dart can be compiled down to JavaScript so we can target Web browsers today. Also cool is that Dart supports tree shaking. With tree shaking, the compiler is analyzing the code when it's converted to JavaScript and asking, "Is this piece of code even needed by the app?" So our app, when it gets delivered to the Web, has only the code it needs.

What's the performance of a Dart app compiled to JavaScript with dart2js versus the performance of native JavaScript?
Schultz: Google tracks Dart on three benchmarks. On two of the three, dart2js code is faster than handwritten JavaScript code. What they're able to do is optimize code that a normal programmer isn't necessarily worried about or thinking about.

Do you want Google to build Dart into Chrome, not just into the experimental Dartium browser?
Schultz: Oh, yeah. That's where I feel the future is. That's what I'm really excited about. On those benchmarks, the Dart virtual machine is something like two times faster than JavaScript or maybe more. With the JavaScript VM (virtual machine), browsers have made most of the performance they can get out of it. You need something new to push the performance boundary. That's what the Dart virtual machine brings.

What about the downsides, like introducing new potential security vulnerabilities or dividing programmers' attention so they have to write duplicate versions of the same supporting library software? You'd have two different runtimes on the Web doing the same thing, so resources would be split across them. Are you concerned about negative side effects?
Schultz: Not really. We feel pretty confident about the Dart platform. I feel like it's the future of the Web. If the Dart VM doesn't pan out, we still have a great language and we can compile it down to JavaScript.

Mozilla and Microsoft have shown no interest in Dart. Are you planning on banging on their doors? Developer demand would be important to convince them to support it.
Schultz: Once Google puts the Dart VM into Chrome and more developers start using Dart to build applications and start seeing the benefits of the more 'performant' VM and pushing the Web boundaries, that's going to influence the other browser vendors. It's going to be a wakeup call. They need to do something else to make the Web programmer's life easier.

Google is taking a lot of steps in the right direction for other vendors to include the Dart VM, like sending Dart language specification to ECMA (the standards group that oversees JavaScript). Hopefully Dart becomes a standard.

The Web moves fast, but not that fast. What's your hope for when you'll see Dart in Chrome and other browsers?
Schultz: I have a feeling we'll see the Dart VM in Chrome pretty soon, but I wouldn't know any details.

Google thinks Dart is production-ready. How ready do you think it is?
Schultz: We think it's very ready. We built a whole app on it. When we picked up the language, some of the [application programming interfaces] were in flux. They were racing hard to fix the APIs and make sure the language was good enough to build Web apps on. Now the APIs are stable and it's very ready for production

JavaScript has an enormous collection of supporting libraries already written so programmers can add new abilities to their code easily. How's the expanded ecosystem of Dart?
Schultz: It's very healthy. There are over 500 packages on Dart's package manager. That will only continue to grow with the excitement for Dart out there.

Google has another runtime for the Web, Native Client and Portable Native Client, which are designed for letting C and C++ software run fast in browsers. What do you think of it?
Schultz: In general, I'm excited about taking native code and bringing it to the Web. A lot of our image-processing code is done in C. If we could bring that to the client (running on a browser, not on Mixbook's servers), that would be awesome, so we wouldn't have to bring images up to the server. It's not something we're actively pursuing now, but I'd like to do more research on that subject.

Do you see a role for Mozilla's Emscripten and asm.js projects for running faster JavaScript?
Schultz: If you're a C developer. I'm not. I want an environment that I'm productive in. C is not that environment.