Enjoy!

ElementList $(String query) => document.queryAll(query);

Now in your UI code, you can write simply

$('h2').first.text = 'Heading 2';

This got me thinking. What if you wanted to emulate jQuery even further, like:

$('h1').addClass('blue'); // call methods on matching elements
$('h1').each((Element e) => e.text = "Heading");
$('h1').onClick((Event v) => window.alert('hi'));

Here’s a tiny library that lets you do the above. It’s just a starter, but hopefully shows some of Dart’s potential for convenient DOM manipulation.

#library('dartQuery');

#import("dart:html");

typedef void ElementFunction(Element e);

/**
 * jQuery-like syntax returns an ElementListWrapper on which methods can be called
 */
ElementListWrapper $(String query) => new ElementListWrapper(document.queryAll(query));

/**
 * jQuery-like interface providing convenience methods which
 * operate on multiple Elements returned by document.queryAll()
 * A TODO in dart:html's Element.dart suggests that some methods
 * may eventually make it into Dart's ElementList, possibly eliminating
 * the need for a wrapper.
 */
class ElementListWrapper {

  ElementList _elements;

  ElementListWrapper(ElementList this._elements);

  // invoke a function for each element
  void each(ElementFunction f) => _elements.forEach(f);

  // add a style classname to each element
  void addClass(String className) {
    each((Element e) => e.classes.add(className));
  }

  // add a click handler to each element
  void onClick(EventListener h) {
    each((Element e) => e.on.click.add(h, true));
  }

  // allows $('#id').first
  Element get first() => _elements.first;

}

Warning: this was working earlier in frog and dartc, but something seems to have changed this afternoon. Either I broke it while reformatting for the blog or my Dart build is hosed. YMMV.

1. edit your Dart script
2. save
3. refresh in browser
4. see changes in 1 or 2 sec

You can already do this in the Dart Editor, but if you want the latest libs from Dart source, you’ll need to use frog instead. Here’s how to do it:

1. Install node as per the frog README
2. Pull latest from bleeding_edge
3. > cd dart/frog
4. > ./minfrog tip/toss.dart
5. Browse to a Dart sample under the http address you get back (like http://localhost:1337/client/samples/spirodraw/spirodraw.html). Navigation from the home page may not work yet, so you may have to append the path to the URL as shown here.
6. Now open dart/client/samples/spirodraw/Spirodraw.dart in the Dart Editor or your favorite text editor (probably vi).
7. Make a change (say, replace a color) and save it.
8. Hit refresh in the browser.

Note: currently, the server only serves up code under the dart source hierarchy. An option to point to an external location is coming soon.

How it works

Toss.dart is a tiny Dart script that runs an http server. When you request an html page that contains <script type=”application/dart”>, the server invokes the frog JS compiler on the fly and serves up the resulting JS inline.

You can also run frog on the command line. The compiler has been renamed from frogsh to minfrog and is checked into the Dart source repo so you don’t need to build it first. Just add the dart/frog directory to your PATH.

> cd dart/client/samples/spirodraw
> minfrog –compile-only –out=spirodraw.js Spirodraw.dart
Edit the <script> tag in spirodraw.html to point to the compiled JS
> open spirodraw.html (to launch the browser, works on Mac, anyway)

If you run frog directly like this, make sure the <script> tag in your html points to your compiled JS. If you instead run the frog toss server, the <script> tag should point to the Dart script directly with type=”application/dart”.

Coming soon

Running the frog server (toss.dart) is an easy way to see your changes quickly. Even better will be Dartium, a special Chromium build with the Dart VM integrated. With Dartium, no JS compilation is needed at all. Just edit, save, and refresh in the browser to see your changes “instantly.”

Building Mobile and Enterprise Apps with HTML5 and GWT

The talk is very similar to the combined GWT and Dart talk I gave at SenchaCon last month, which you can find at www.dartlang.org/slides/.

Sunflower:

• dartc: 109,612 bytes
• frog: 12,131 bytes

Spirodraw:

• dartc: 121,799 bytes
• frog: 24,320 bytes

The dartc results were obtained by running “dartc –optimize sample.dart”. The unoptimized JS is much larger.

Frog optimizes by default. I had previously built dart on my Mac as per the wiki and installed node.js per the frog README. From there, I ran:

> cd dart
> ./tools/build.py --arch=ia32 -m release
> cd frog
> mkdir bin
> ln -s ~/code/bleeding_edge/dart/xcodebuild/Release_ia32/dart_bin bin/dart_bin
> ./frog.py --js_out=frogsh -- frog.dart
> export PATH=$PATH:$PWD

Then I compiled the sunflower sample with frog:

> cd ../client/samples/sunflower
> frogsh --compile-only --out=sunflower.js Sunflower.dart

Because the samples are designed to be compiled with htmlconverter.py, I also had to modify the script tag in sunflower.html to reference sunflower.js instead of Sunflower.dart (and removed type=”application/dart”).

Frog runs about 10x faster than dartc –optimize on the command line! This is comparable to dartc performance in the editor, which has the advantage of a warm JVM (frog, on the other hand, runs in the Dart VM). The dramatic difference in code size is likely because dartc had not yet implemented dead code elimination. And, unlike dartc, frog does not support incremental compilation so was able to take an entirely different approach. Also, frog is not finished, so there may be gotchas that appears as more corner cases are implemented. But for the moment, it looks very promising.

I had lots of fun watching developers interact with the Chromebooks on display in the Chrome booth. Many folks mentioned getting one for their kids or grandmas this Christmas (“and give yourself the gift of no tech support”). I am personally more attracted to the Chromebook than tablets, but that’s mostly because I’m so keyboard-focused (the trackpad on the Samsung Chrombook, by the way, is one of the better I’ve used apart from a Mac–I haven’t tried the Acer Chromebook yet). One place where a tablet would excel is crammed in the back of an airplane, where there’s not really enough room to open my 15″ MacBook Pro. Speaking of which, flights are much more bearable with a laptop and wi-fi. I think I’m addicted to work.

Back to Dart. I regrettably did not leave any time for questions, but was pleasantly surprised at feedback from JS developers after my talk who expressed frustration with Javascript’s lack of typing and scoping and were cautiously optimistic about Dart as a better way to build large-scale apps in the browser. I also met folks who are currently building large apps in JS by compiling from ActionScript. The fact that people are doing this (along with compiling from Java using GWT) definitely points to the need for better languages in the browser.