Thoughts on using Sweet.js

[natew]

Just curious as the timing seems excellent for me to stumble on this.

I've been wanting to use sweet for a new project, but after being spoiled by Babel in my latest projects I'm hesitant. It seems if you decide to use Sweet you pretty much don't have a need for Babel, or can't use many of it's latest features.

Given then insane pace of growth and support for Babel, I'm just curious how your experience has been using sweet.

[srikumarks]

Sweet.js fills a different need for me compared to Babel or ES6. With Babel, I'm still subject to standards for the language established by other folks. With sweet, I have the freedom to tailor a language to my needs and understanding. (You get used to doing this if you've ever coded lisp :P)

For example, I've encoded patterns of error handling and resource management into cspjs that I've found effective and very hard to reliably code up otherwise. Especially the way I prefer to think of and work with catch and finally (notice no "try"). I'm also working on a couple of extensions to cspjs that have to do with data flow variables (a.k.a. "promises", and this is partially already on master) and serializable continuations for use in the backend. This is possible using sweet because I can use macros to insert state tracking code without it being visible in the source code.

In other words, I would still find tons of uses for sweet even after ES6 becomes available everywhere. In fact, I wish Ecmascript would add sweet.js to the language and be done with it :)

[natew]

I agree with you on all counts. I guess for me the only downside of sweet is it's poor support of ES6 and JSX, and more importantly, it's really quite slow. I'd love to see either Babel move towards syntactic plugins, or sweet move over towards closer integration with Babel.

[srikumarks]

@natew Guess you got your wish. Sweetjs 1.0.x now also runs babel by default.