that's not the direction language and programmers should follow
Now, macros do have some shortcomings. I've used Racket (a variant of Scheme) a fair bit, and I'm now very wary of using macros too much. However, when they are useful, I've found they're very useful: writing the same program in a language without macros would often be extremely awkward.
Of course, if you're willing to entertain radical changes to your language, you can get many of the benefits of macros with a minimalist syntax, laziness and a simple mechanism for controlling how statements get evaluated. Which ultimately just amounts to Haskell. And I've even found good use cases for macros in Haskell, albeit far less than in any other language.
- debugging such code is a nightmare(node.js itself makes it hard enough)
- static analysis of such code is not possible.. yet?
JS and programmers should target Java-like experience imo, static analysis, code assist, dependency check - all of it performed on-the-fly. We won't get it by creating yet another layer above main language, because IDE vendors simply can't cope.
coolness of JS and safety of static analysis, that would be great
macros are just lame workaround:)
Now imagine if every JS codebase use a slightly different convention for class/function declaration with slightly different behaviours. It can become a nightmare to understand even the most simple function definition, just because you don't this particular "def" has some side-effects.
Now, I agree that in some cases, macros can be useful and reduce the complexity of the program, but declaring classes and functions certainly isn't the best use case for them and it's a bit sad those are the two first examples on the page.
It's one of those things that just ends up in utterly huge amounts of excruciating pain with respect to performance, debugging, support, fungibility and value over a long period of time.