Dart in December

The first Wednesday in December, our last meetup of the year. It was a packed house.

This month we got a look at Dart, a new web programming language, from two Google engineers. Seth Ladd is a web engineer, father, husband and is currently a Developer Advocate at Google.  He produced Aloha on Rails, the Hawaii Ruby on Rails and Web Development Conference and New Game, the conference for HTML5 game developers.  Way back, he wrote Expert Spring MVC book.  Seth was lucky enough to help release Angry Birds for the web.  He is current on the board for the Academy of Interactive Arts and Sciences. Steve Messick works on the Dart Editor at Google.

Think of Dart as web programming with "batteries included." It's a new language, with new libraries, even its own VM, but it's based on a simple and familiar OOP model that takes almost no time to learn. It's in an early stage, open source technology preview so you can still provide feedback and affect the direction as it develops.

So why a new language? The web has some very good things going for it. Small to medium apps are easy to develop, it's platform independent with no installation required. It supports fast, incremental development, and it's everywhere, on every computer, every device. That's quite an impressive feat! What's so difficult? Writing large programs is hard. Very large program structure, libraries, the tools to see what's happening inside a running program is simply not possible. Consider two books: the very heavy volume "Javascript" and the thin, almost pamphlet-like "Javascript: The Good Parts." Any web developer can tell you, a lot of cruft has built up since the mid 90s.

Dart is a new approach to building structured web apps. It's not intended to compete with JavaScript, but to fill the vacuum evidenced by fragmented mobile platforms. Structured, high performance, high fidelity, feature-rich apps.

Dart is a simple, unsurprising OO language with typical classes, single inheritance, and interfaces -- everything you've seen before. The most unique feature is its optional typing. Developers can check types at compile time or runtime through an assertion-like method. It also has optional static typing, lexical scoping, and is single-threaded.

Wait, single threaded? Not to worry, it uses isolates similar to Erlang. Each isolate is conceptually a process and they can communicate through a mailbox system. With isolates, you can support concurrent execution with a single-threaded language. In the browser, UI elements are lightweight isolates and heavyweight isolates manifest themselves as HTML5 web workers.

There is a much-needed DOM overhaul loosely based on HTML5 DOM, but with lots of cleanup. Gone is the XML legacy. It supports type-checking and is built using Dart lists, which makes it terse.

Dart compiles to its own VM or to JavaScript. The tools can also take a snapshot of a running Dart program, serialize it, and transmit it to another VM. Obviously this could be used to cache programs for rapid startup. Receiving that heap snapshot and running it does require a Dart VM.

Seth Ladd and Steve Messick

The Dart editor is based an Eclipse RPC program. What you think about having code completion in a language bound to your web browser?  It is in technology preview mode and there's lots of work to do yet. The current focus is getting the performance up to par with the far more mature traditional web technologies, but they are looking for feedback as far as what to work on next. Should they have reflection support? Rest arguments? Enum? Pattern matching? What's the best way to integrate with other browsers? You can provide your feedback at the Dart web site and discussion groups.

The Dart Web site (www.dartlang.org) contains the language spec, tutorials, and prebuilt binaries.

The Dart Project site (dart.googlecode.com) is where you can get source code, libraries, and sample apps.

You can watch the talk here

Update: Seth Ladd has provided the slides at http://www.dartlang.org/slides/2011/12/gtug/ and written a quick tour of the SDK on his blog at http://blog.sethladd.com/2012/01/dart-sdk-quick-tour.html

Honeycomb Highlights

Chet Haas and Romaine Guy gave us a reprise of their I/O talk, "Honeycomb Highlights" which was a good introduction to the Honeycomb UI, OS, and SDK, and links to deeper information on each.

The event was livestreamed by Jason Thrasher,

who is working to streamline the process on our YouTube channel. It went well, and soon we'll be able to livestream GTUG meetings from around the world, easily.

Here's some links:

• Their I/O talk on May 10th
• The slide deck
• Android Developer Blog, with lots more info.

Other related I/O talks of note:

• Fireside Chat
• Android UIs for Phones and Tablets
• Android Development Tools
• Memory Management for Android Apps

Thanks, Chet and Romaine!

Google I/O 2011: GTUG BarCamp

It certainly was Google I/O.

For the GTUG organizers who gathered from around the world, even more so.

The first thing that greeted us was a big red arrow at Moscone Center, which happened to be exactly what I was looking for on Google Maps. This was Tuesday, opening morning.

Our adventure at I/O began two days earlier at the Sunday GTUG BarCamp, an "unconference" for GTUG organizers on the subject of... well an unconference can cover a wide variety of topics, with no set agenda. It's exactly like a conference, except the opposite.

The rules of an unconference are:

1. The people who come are the best people who could have come.
2. Whatever happens is the only thing that could have happened.
3. It starts when it starts.
4. It's over when it's over.
5. The Law of Two Feet: If you want to go to a different session, get up and go.

We started by making up session topics right then and there, and writing them all on big colorful sticky notes. These were gathered up and distributed on a board, until we had four periods of five sessions each.

An unconference doesn't have a leader so much as a guy who moves the sticky notes around. Everything is done more or less by consensus and ad hoc. Once we had our session schedule, we broke up into groups and began discussions.

You can find all our notes on the GTUG Wiki BarCamp Page.

That's how we came up with our session list:

1A Broadcasting to Distributed Communities

1B Fragmentation and Focus

1C Running a Startup on App Engine

1D Converting Members to Presenters

1Z Getting to Know Your GTUG

2A Global Hackathon

2B Creating a Nonprofit

2C Mobile Development in the (near) Future

2D How to Present According to Batman

2Z How to Make Your Group Delicious

3A GTUG Magazine

3B How to Create a Playground for Cats

3C Writing Code Without Face Time

3D Development Experiences

3Z Tools for GTUG Managers

4A Google Involvement in GTUGs

4B Developers and Designers Collaborate

4C Android for Consumers

4Z Bootcamps and Other Hands-on Events

What seemed to excite people most was Tools for GTUG Managers, and we spent much of the time since brainstorming ideas on that topic. From geolocated android applications to a web clearinghouse, and global collaboration between the different GTUG chapters. Hopefully we'll have more to announce soon. Until then, so long from GTUG!