Aside from that, you're right. But JS has higher order functions and objects with ad-hoc methods, so it can be used according to many paradigms, which can make it hard for a reader unfamiliar with the dominant paradigm in code at hand.
This is not a deal-killer for macros, although with sweet.js as the prototyping tool, your assertion about "This is the job" is satisfied. Sweet.js works with node to do AOT macro expansion at present. There's effort to integrate it in the browser too, but this will be easier with ES6 module loaders (not yet prototyped in SpiderMonkey or V8).
The macro syntax is definitely not simple, and it could possibly get really complex for more elaborate syntactic definitions, thus rendering the source much less readable. Is the overall benefits of introducing macros to JavaScript really worth the costs of readability? And does the effort to integrate macros into the browser mean that it'll be possible to evaluate macros "runtime"?
True, but the same can be said of any API. Reading the definitions can help but for both complex macros and complex APIs built today out of just functions and objects you need to document your abstractions. Macros don't change this, they just give you another abstraction axis (syntactic) to work with.
As with most things it just depends on how you use it. Sure you can abuse macros to make tons of crazy, undocumented, hard to understand syntactic extensions that destroy readability. But you can already do that today. Used wisely macros can increase readability, used poorly they can decrease it.
> And does the effort to integrate macros into the browser mean that it'll be possible to evaluate macros "runtime"?
Not sure what you mean here. By definition macros are expanded at compile time (well, parse time really). The browser doesn't change this.
But by having macros directly in JS, instead of having to use a whole language that compiles to JS, you can combine syntactic features from different sources. For example, right now there's no way to use one feature you like from CoffeeScript with another feature you like from TypeScript. You just can't combine them. But with macros, you could import two different syntaxes from two different libraries and use them in the same code.
On top of that, if we actually had macros in a future version of the standard, you wouldn't even have to precompile the macros offline, and you wouldn't need a preprocessing step at all. (For latency purposes, you might want to preprocess macros offline as an optimization. But for development, not having to do a preprocessing step is more convenient.)
Dave
I don't think this can be compared to API's as they still follow the regular syntactic definitions - This will be like reading a completely new language every time I read a different repository. (Of course this is a worst-case scenario as I imagine that many macros will be used across several projects, but still.)
Is all hope gone for writing vanilla JS gone? And isn't macros kinda going in the opposite direction than the ES specs? There's no use for many of the ES6/7 features as they could just be mocked up in macros.