The project that I'm working on has functional abstractions, contexts, and node-fibers flying all over the place. It gets hairy at times but (I claim) it's none

The project that I'm working on has functional abstractions, contexts, and node-fibers flying all over the place. It gets hairy at times but (I claim) it's nonetheless workable precisely because I don't use libraries like Sugarless -- every abstraction is designed for its specific purpose. If input processing is complicated enough to have annoying syntax, it gets its own special-purpose class (if not a separate module) written in the language of the domain. Frankly there's probably several things that look like Sugarless in the codebase already. But I consider this a Good Thing: If I want to change the way operations distribute over an Input object, I can do it in an arbitrary, appropriate way. If I'm using someone else's convenience library, I'm limited to what the library author decided I should be able to do. This happens surprisingly often in my use case and more often than not it means going back to throw away the library in question, and reimplementing what I needed in the first place. This isn't actually a comment on Sugarless itself -- I haven't gone out and used it. But I'm quite jaded by all of the times I've had to deep dive into other people's 'convenient' JS library when it was subtly broken (or wasn't working as I'd like) to the point that I try to avoid them as best as I can.