vsavkin

Framework a la carte.

Why I prefer Angular to Ember.

Abstract

When comparing Angular and Ember, people often say that frameworks like Ember enforce a strict structure, which frees you from making the same decisions all over again, and makes you more productive. In this article I will explore if it is the case.

On structure and conventions

vsavkin

The author has a few good points, but I think he doen't see the whole picture.

1. Even if the DartVM is not deployed to any other browser, there is still a lot of value in having it:
* The VM can be used on the server side.
* The VM can be used to speed up development process (no compilation).
* Just the fact that it can be shipped with the mobile Chrome, I think, is a big deal.

2. I would not compare the Dart/JS interop with the COM interop. It is closer to the Java/Scala interop or to the JRuby/Java interop. It is not completely seamless, but not too bad.

3. Optional/gradual types are often criticed because they do not provide certain guarantees. But it is actually a great thing! Gilad Bracha gave a great presentation a few years ago, where he talks about the benefits of optional types (the section on optional types is somewhere in the middle of the talk):

vsavkin

All the Dart tools (e.g., the analyzer) can be used without any IDEs. There is also a VIM plugin for Dart. So you can definitely do that.

Having said that, I think a huge part of what makes the Dart experience nice is tooling (autocompletion, navigation, analysis).

Whereas for JS/Ruby going from a text editor to an IDE does not make a huge difference, for Dart, mostly due to type annotations, it's definitely a win. 

So if you don't like Dart Editor because of its Eclipse nature (which I can totally understand), try WebStorm. WebStorm also has a VIM plugin. If you, however, dislike IDEs in general, then try the VIM plugin.

vsavkin

import 'dart:mirrors';

class Person {
  hello() => "hello";
}

// you can define the send function as follow:

send(obj, message, [args = const []]) =>
    reflect(obj).invoke(message, args).reflectee;

vsavkin

Injector inj = ngDynamicApp().addModule(new MyApp()).run();
Router r = inj.get(Router);
r.root.addRoute(name: 'newRoute',path: '/new-route');

vsavkin

library rest_api_spec;

import 'package:guinness/guinness.dart';
import 'package:unittest/unittest.dart' hide expect;
import 'dart:async';
import 'dart:mirrors';
import 'dart:convert' as cvt;

import 'package:angular/angular.dart';
import 'package:angular/mock/module.dart';

vsavkin

Hammock

I released a library based on this spike. You you can find it here: https://github.com/vsavkin/hammock.

SPIKE: AngularDart REST Client

Every client-side applications has to talk to REST APIs. At the moment AngularDart does not provide any high-level abstractions to help you do that. You can send http requests, but that's it.

This post is about a spike I did a few days ago to explore possible ways of building such a library. It also shows that you can do quite a bit in just one hundred lines of Dart.

vsavkin

library mapper;

import 'package:hammock/hammock_types.dart';
import 'dart:mirrors';



//----------------------------
//----------- META -----------
//----------------------------

vsavkin

Hammock.Mapper (Spike)

A few weeks I released Hammock - an AngularDart service for working with Rest APIs. You can read more about it here. This post is about a small library called Hammock.Mapper I built on my flight from Toronto to SF. It uses conventions and a bit of meta information to generate all the serialization and deserialization functions required by Hammock.

Hammock

First, let's look at a small example of using Hammock.

Suppose we have the following model defined:

vsavkin

library angular.benchmark.directive_injector;

import 'package:angular/angular.dart';
import 'package:angular/application_factory.dart';
import 'package:angular/mock/module.dart';
import 'package:benchmark_harness/benchmark_harness.dart';

import 'dart:html';
import 'dart:js' as js;