I have been contributing to the strange cousin of the macro which is the notion of inline DSL fragment. https://github.com/ngn/coffee-subscript In essence you get latex looking (\dsl) syntax to enter what ever DSL (which is just a standard node module). So this could be something as simple as an annotation style approach in which you consume the next chunk of coffee-script and simply wrap it - or something more involved like an entirely different language (this originally stemmed from the desire to have inline APL ala https://github.com/ngn/apl - which provides \apl and \apl.fn respectively).

http://github.com/shaunxcode/jsedn and http://github.com/shaunxcode/swedn also work currently. Right now they are naive e.g they just emit a call to parse at runtime, when I get the time they will actually be more clever and, well, actually compile at compile time hah.

Recently I have been toying with adding type annotations so I can easily port a code base to typescript but have them be entirely ignored by coffee.

One side note is that we have discussed adding support for sweetjs as right now these are definitely DSL hooks and not hygenic macros. In fact I would go so far as to call these toothless macros e.g. it is up to you to chew the food (parse) and swallow it (emit valid js).

I used batmanjs on a project a bit ago and enjoyed it a lot due to the API being designed specifically for CoffeScript.

It used the `class` construct instead of building its own Object.extend class system like most libraries do. Not only is that simpler, its much more powerful than the standard 'prototype = object literal' approach as CofeeScript classes have executable class bodies, so you can build macro-like class-level methods similar to ruby:

    class Alfred.Todo extends Batman.Model
      @persist Batman.LocalStorage
      @encode 'body', 'isDone'
      @validate 'body', present: true

From my brief glance at Ember it seems like the pattern to add macro behavior is to wrap property values in calls to things like `Ember.computed` which looks pretty clunky.

In EmberScript's case, sweet.js isn't sufficient for things like dependency inference (which require walking the AST).

In general, however, from the end user's perspective, why is using something like sweet.js better?

It would be fantastic if this kind of stuff was embraced by the CoffeeScript people and something like Erlang's parse transforms was implemented:

    # mycode.coffee:
    "use parse_transform('observers.coffee')"
    
    class Gradebook
        +observe scores
        gpa: ->
            sum(@scores)/@nGrades

Imagine the interesting (or perhaps chaotic) ecosystem that would develop if this kind of thing was encouraged?