Hacker News new | comments | show | ask | jobs | submit login
Why sweet.js Matters (jlongster.com)
21 points by jlongster on Oct 26, 2012 | hide | past | web | favorite | 5 comments

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. :)

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...

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.

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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact