111–120 of 142 posts
As a year-long CoffeeScript user, I have a few points to rebut: debugging workflow: he makes a long list of bullet points, when in practice you can find the error directly in your coffeescript code 90% of the time, since you have a clear image of what it's compiling to and errors tend to happen on the piece you're working on. Hopefully source-mapping in Firebug/Inspector will be ready in a few months and end this dis…
There has always been a strong "case against using CoffeeScript", from day one. Like any other new language, it's a new, strange thing to learn, there's new tools and a new compiler, and your team doesn't already know it. In addition, CoffeeScript has it's own distinct burden to bear: the entire point is to compile (in as straightforward a fashion as we can manage) into JavaScript. That you're debugging JavaScript wh…
There has always been a strong "case against using CoffeeScript", from day one. Like any other new language, it's a new, strange thing to learn, there's new tools and a new compiler, and your team doesn't already know it. In addition, CoffeeScript has it's own distinct burden to bear: the entire point is to compile (in as straightforward a fashion as we can manage) into JavaScript. That you're debugging JavaScript wh…
JavaScript runtimes have kept on improving and with the V8/Node.JS combination have started taking over the server-side code.
With careful engineering, developers can get even further with just JavaScript the language. I wonder for instance whether using the Google Closure Tools can bring more gains there. Such tools help with checking the code for common pitfalls and the style guidelines also help a bunch. Plus, they might help with deployment, with the packaging for the specific program you've written so you don't need to package up all the library with it. Then you don't need to feel ashamed of making use of lots of library code, if only the part of it that you're using gets deployed.
Still, working with JavaScript directly can also bring debugging challenges, even more when you're trying to debug code that has been mangled since leaving your library source files.
Languages like CoffeeScript and Dart have success because the alternative in pure JavaScript is still quite painful, as I've mentioned above. It's a mistake to dismiss languages like CoffeeScript and Dart because you want that 50% extra performance.
Still, CoffeeScript is a concept. It could be said to have been over-engineered in places. Some of the stewards of JavaScript would have found it better if it was more like a JavaScript with JSLint turned on and some niceties on top of it.
There has always been a strong "case against using CoffeeScript", from day one. Like any other new language, it's a new, strange thing to learn, there's new tools and a new compiler, and your team doesn't already know it. In addition, CoffeeScript has it's own distinct burden to bear: the entire point is to compile (in as straightforward a fashion as we can manage) into JavaScript. That you're debugging JavaScript wh…
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.
thanks.
There has always been a strong "case against using CoffeeScript", from day one. Like any other new language, it's a new, strange thing to learn, there's new tools and a new compiler, and your team doesn't already know it. In addition, CoffeeScript has it's own distinct burden to bear: the entire point is to compile (in as straightforward a fashion as we can manage) into JavaScript. That you're debugging JavaScript wh…
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 technol…
> deploying application frontend of which was written in
> CoffeeScript was the biggest mistake in my entire career
While I can't say for sure, it reminds me of the days where Java programmers would try Python and complain that it was harder to write Java code in Python than it was in Java (esp. with getters and setters).
There has always been a strong "case against using CoffeeScript", from day one. Like any other new language, it's a new, strange thing to learn, there's new tools and a new compiler, and your team doesn't already know it. In addition, CoffeeScript has it's own distinct burden to bear: the entire point is to compile (in as straightforward a fashion as we can manage) into JavaScript. That you're debugging JavaScript wh…
Instead of defending it - go make it better. Address the items put forth right ?
1. work to get native debugging 2. clean up the looping mechanism
etc...
Instead of taking this guys post and saying 'negative criticism', see it as 'positive criticism' - he is reviewing it, showing what can be better, showing the obstacles.
I think part of developing a truly good library, is the ability to improve it, take criticism, expand and grow - not to cling to the original concept and defend all day long.
Personally I'd concentrate on the debugging, secondly, I'd work to improve the overall syntax, maybe providing alternative, more structured for some - others that don't like that can continue to use the same.
But again, rather than everyone just spamming here on how it 'rocks' or how it 'sucks' - would be better to take these observations and go and say 'how can we improve' - this is golden feedback here!
My biggest problem is that because it lacks firm rules in a lot of area, CoffeeScript is a language that is not always intuitive. With JavaScript it's pretty simple to know the rules; they are completely uniform. Not so with CoffeeScript. Here's my biggest gripe: greet = (greeting, person) -> "#{greeting} #{person}!" greet "Hello", "world" That's simple. A function that takes 2 parameters, separated by a comma. But w…
One wouldn't know that intuitively, because what you wrote: longRunning () -> "Yippee!" () -> "Oh noes" ... is not valid CoffeeScript. I'm not sure where you got that from. Ideally, you'd write it: longRunning onSuccess, onError Or, if you really wanted to use two inline functions instead of local variables: longRunning (-> "Yippee!"), (-> "Oh noes")
longRunning (->
###
bunch of stuff happening for success
###
), (->
###
bunch of stuff happening for failures
###
)There has always been a strong "case against using CoffeeScript", from day one. Like any other new language, it's a new, strange thing to learn, there's new tools and a new compiler, and your team doesn't already know it. In addition, CoffeeScript has it's own distinct burden to bear: the entire point is to compile (in as straightforward a fashion as we can manage) into JavaScript. That you're debugging JavaScript wh…
I think the blog post was a good one - it pointed out the problems. Instead of defending it - go make it better. Address the items put forth right ? 1. work to get native debugging 2. clean up the looping mechanism etc... Instead of taking this guys post and saying 'negative criticism', see it as 'positive criticism' - he is reviewing it, showing what can be better, showing the obstacles. I think part of developing a…
https://github.com/jashkenas/coffee-script/issues/558
Earlier quoted context omitted.
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 technol…
> deploying application frontend of which was written in > CoffeeScript was the biggest mistake in my entire career ... can you elaborate on this?
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.