

Why sweet.js Matters - jlongster
http://jlongster.com/why-sweet.js-matters

======
jpadvo
My company uses coffeescript, because it's a curated, highly documented set of
improvements to javascript syntax. It's code I can trust, and code that was
built by someone a lot better than I am at constructing languages -- so it's a
pleasure to use.

I suspect that the biggest contribution sweet.js will make is lowering the
barrier enough that more people release things _like_ coffeescript. Curated,
documented packages of syntax improvements to javascript. I suspect that will
be more common than individuals rolling new syntax for each project.

Let a thousand coffeescripts bloom. :)

------
btipling
I'm unconvinced. sweet.js is a terrible thing for JavaScript development.
JavaScript is already dynamic and capable enough to build sophisticated
applications. It is dynamic enough to help programmers avoid redundant code.
If syntax is a problem, there are alternatives like CoffeeScript, Dart and
others. There is something pretty amazing about JavaScript, for example the
various runtimes that run JavaScript adhere to the ECMA standard pretty well.
This has allowed the programming language to become what it is today, a
portable way to write apps and have them work in phones, different platforms,
servers and browsers.

Macros will:

* reduce portability

* add an extra layer of complexity to building and debugging (that abyss[1] is going to be even deeper)

* make code less readable

* increase ramp up time for new engineers on a project as they have to learn your flavor of JavaScript

I'm not saying JavaScript doesn't have room for improvement, but sweet.js is
the wrong way to do it.

[1] [http://masters.gen.nz/Blog/post/WDCNZ-Thoughts-on-Douglas-
Cr...](http://masters.gen.nz/Blog/post/WDCNZ-Thoughts-on-Douglas-Crockfords-
talk-covering-the-The-Abyss.aspx)

~~~
jlongster
I really love most of javascript. I think it's a great language. But there are
things that need to be improved syntactically. Also, syntactic extensions
could vastly improve specific apps, depending on what they are doing.

I agree that there are concerns about debug-ability, but as any Lisper will
tell you, you just need the tools to support it. That's why macros need to be
native. All the debuggers will be aware of them, so it should be a non-issue.

The whole point of macros is to make code _more_ readable, too. I'm not sure
how you can argue that its less readable. Most people agree that the tradeoff
is readability/debug-ability.

~~~
btipling
Sure, and you know what, actually after thinking about it and reading more of
the sweet.js docs, I actually want to try it out some and see where it goes. I
actually think I'm changing my mind already.

------
draegtun
For reference here are three recent HN discussions on sweet.js -
<http://news.ycombinator.com/item?id=4687442> |
<http://news.ycombinator.com/item?id=4650929> |
<http://news.ycombinator.com/item?id=4560691>

