
Writing Your First Sweet.js Macro - jlongster
http://jlongster.com/Writing-Your-First-Sweet.js-Macro
======
andreypopp
I found sweet.js so much useful for scraping boilerplate out of my code.
Example — sweet-assertions [https://github.com/andreypopp/sweet-
assertions](https://github.com/andreypopp/sweet-assertions) — a set of macros
to generate assertions with nice failure messages.

Edit: another experimental macros — [https://github.com/andreypopp/react-
macros](https://github.com/andreypopp/react-macros) — a set of syntax
extensions for writing React
([http://facebook.github.io/react](http://facebook.github.io/react))
components.

~~~
alttab
Is this "gain" really worth the additional compilation step? The best thing
about javascript in my book is saving my file in VI, and then clicking
"refresh" on the browser. Having to re-process these files after each change
would be a total pain in the ass, not to mention my syntax highlighting won't
work anymore.

There may be "macros", but with vanilla javascript and without an extra step,
you can use "functions."

Also, commence having to build an adapter for your web framework, and
integrate it into the build process. And forget it if you are using asset
pipelines in Rails, what sort of crazy hack would that require?

All of this extra integration for Javascript macros?

~~~
andreypopp
If you already use build process, the additional step would be just one
additional step in the build process, "invisible" to you. So "save in Vi,
reload" still works.

If you don't have build process when writing JS code for browser, well... I
don't know how it's possible.

I suggest you to look at browserify
([http://browserify.org](http://browserify.org)). For sweet.js there's
sweetify
([https://npmjs.org/package/sweetify](https://npmjs.org/package/sweetify))
transform.

Note, that sweet.js compiler generates source maps, so you can debug your code
with comfort.

Syntax highlighting still works, because most of the syntax highlighters
highlight tokens and macros preserve token structure of the language (well it
can kinda "introduce" keywords, but if you use Vi, it's just 1 line of code to
fix your setup).

~~~
alttab
Maybe this works for server stuff, but if you are doing client-side JS I feel
like adding this sort of layering as more trouble than its worth.

But when it comes to JS, I'm a minimalist.

~~~
lowboy
I use js compilation (CoffeeScript, Browserify, React JSX, etc) and it is
definitely worth the extra layer. I have a setup with Gulp[0] that watches my
files for changes, compiles, and then LiveReload[1] automatically refreshes my
browser window, so I never have to leave my editor for non-interactive
changes.

CoffeeScript compilation with gulp-coffee is usually on the order of a few
hundred ms, and I'd expect SweetJS to be the same.

[0]: [http://gulpjs.com](http://gulpjs.com)

[1]: [http://livereload.com/](http://livereload.com/) (I use free, OSS command
line versions, not the paid OS X app)

------
davexunit
I tried a simple one. Here is my interpretation of Scheme's delay/force
macros: [https://www.refheap.com/36606](https://www.refheap.com/36606)
(forgive the messed up indentation...)

------
santialbo
I had so much fun playing with this. Here's the code I wrote for a simple
scala-like for

    
    
        macro for {
          rule { {$x <- $y:expr;} {$z:expr} } => {
            $y.forEach(function($x) { $z });
          }
        
          rule { {$x <- $y:expr; $($a <- $b:expr) (;) ... } {$z:expr} } => {
            $y.forEach(function($x) {
              for { $($a <- $b;) ... } {
                $z
              }
            })
          }
        }
        for {
          i <- [1,2,3];
          j <- [3,2,1];
          k <- [5,5,5];
        } {
          console.log(i + j + k)
        }

------
etrinh
The interactive macro editor is a great touch. I don't know if this is
prevalent, but this is the first time I've seen a tutorial interactively
modify code in the editor _for you_. Instead of "here, type this into the
editor above and see what happens," there will be a link to "click here to see
what happens" and it will change the code in the editor accordingly. I think
this is a good thing, because I rarely go and do the things that tutorials
suggest I do, even if they are as simple as typing into an editor that is 2
inches above the text I am reading.

