there were many problems with Barista during deployment. Some things that worked perfectly in development somehow stopped working later on, because of required recompilation. We were deploying in a high-security area, where there's no internet connection, and having to install Node or JS runtime was not good. But again - that was my stupidity, did not foresee that.
moreover, barista did not recompile assets until we touched / saved / modified the file.
We do not have direct access to production system, so all the bug reports are sent in JS, and we need to figure out how things happened and sometimes it was quite difficult to locate a precise place where it occurred.
now, we have to compile everything and package js files when preparing an updating version of software (again, no SSH connection, no internet connection, only tarball / zip update packages).
and, in general: even though everyone says that CS handles everything that JS does plus more, we found that it's easier to handle factories, mixins, scopes, inheritance and more with plain JS. it was always easier to read and understand, and no overhead for development or production, felt more natural. classes are not something we missed in JS, and comprehensions stuff seemed more like a syntax sugar, not something we really missed.
So - it added a complexity and made people to use CS features instead of things that fit more naturally to JS ecosystem. We've had several issues with syntax (e.q. hash assigned to a variable with a function inside or smth like that), but we worked around them on early stage.
those who care and think that they need an abstraction on top of JS / feel like it's a good approach / can't understand or find it hard to use plain JS, are free to use it.
I think people can have positive or negative opinion about things. deploying application frontend of which was written in CoffeeScript was the biggest mistake in my entire career, but I don't blame coffeescript, it was me stupid choosing a technology that doesn't suit the task.
people use many libraries that are generally bad, and asking "how do people still use it" and claiming that it's super-popular is very lame and doesn't really explain anything, and never is a counter-argument.
i don't like it, that's my opinion, it didn't work well for our projects and we have rewritten most of things, and will rewrite the rest of CS back to JS.
it's ok that people use it. some of them will face same issues we did and come to same conclusion. others will be happy, since it solves (THEIR) problem. the rest will never be smart enough to grasp why (and wether) it's good or bad. it's trendy and looks cool, so they'll stick to it.
you've done a great job when created it, but our problems are still better easier and more stably solved by plain js.
moreover, barista did not recompile assets until we touched / saved / modified the file.
We do not have direct access to production system, so all the bug reports are sent in JS, and we need to figure out how things happened and sometimes it was quite difficult to locate a precise place where it occurred.
now, we have to compile everything and package js files when preparing an updating version of software (again, no SSH connection, no internet connection, only tarball / zip update packages).
and, in general: even though everyone says that CS handles everything that JS does plus more, we found that it's easier to handle factories, mixins, scopes, inheritance and more with plain JS. it was always easier to read and understand, and no overhead for development or production, felt more natural. classes are not something we missed in JS, and comprehensions stuff seemed more like a syntax sugar, not something we really missed.
So - it added a complexity and made people to use CS features instead of things that fit more naturally to JS ecosystem. We've had several issues with syntax (e.q. hash assigned to a variable with a function inside or smth like that), but we worked around them on early stage.