4 ms·

While it's not my opinion, I did read this quote somewhere: "CoffeeScript is only syntactic sugar. It brings very little new to the table, but perhaps worse of

While it's not my opinion, I did read this quote somewhere: "CoffeeScript is only syntactic sugar. It brings very little new to the table, but perhaps worse of all, it doesn't really fix all of JavaScript's WTF-issues while adding a few of its own. While it's an improvement over JavaScript, its advantages are sometimes outweighed by the extra hassle to compile and deploy it"

icedog 13y ago
If someone has trouble compiling coffeescript in a build sequence, then they have bigger troubles afoot. CS is well worth the switch.
- kybernetikos 13y ago
  If you have to introduce a build sequence to move to coffeescript then moving to coffeescript is definitely a net negative. I work on a >300k line JS codebase, and our tooling means you can make a change and hit f5 and you always get the latest version of the code. No file watching latency, no run-an-external-tool latency. We /could/ do the auto-reload thing, except that I think that for large applications with lots of state, that's probably the wrong choice. As far as I'm concerned visible 'builds' are the enemy to development. They take you out of your mental context, and in the worst case make even the tiniest changes painful. I've got nothing against pipelines of tasks, so long as the whole thing runs in milliseconds and is transparent to the developer. Obviously, you can do more on an occasional basis, perhaps before check in, and certainly in CI, but we need to reduce friction, and unnecessary build steps in environments that don't need them is a whole heap of friction.
  - awj 13y ago
    I'd be really interested to see what you're doing that uses >300k lines of javascript all at once.
    - kybernetikos 13y ago
      I'm not sure what you mean by 'all at once', since rather obviously not all of those lines of code are running at once. The 'S' in SLOC does not stand for simultaneous. The application has been continuously developed for nearly 10 years now, and small parts of the current codebase are 5 years old. A little while ago, I was very pleased to find and remove some code that was weird in order to work in IE4, but these days I'm enjoying removing IE6 and IE7 specific code. IE8 is the last non es5 browser we have to support and it's painful. The whole application runs in the browser, and connects to services it needs via streaming connections. Once you take into account the fact that it's not just a couple of pretty forms for a back end application, plus the fact that in the browser you have to write things that come as standard in many other environments, plus the fact that you used to have to write extra code to work on different browsers, plus the fact that the javascript ecosystem was not up to the task back then so lots of things that would be generic now had to be written in house, plus the fact that it's extremely well tested both with unit tests, acceptance tests and integration tests, then a large codebase is really not all that surprising.
  - lowboy 13y ago
    Transparent and instantaneous is my experience using grunt to watch and compile CS. It will only compile the changed file, not the entire codebase. It seems to happen instantaneously for me on file save, or at least within the time it takes for me to switch from my editor to my browser.

icedog 13y ago

If someone has trouble compiling coffeescript in a build sequence, then they have bigger troubles afoot. CS is well worth the switch.

kybernetikos 13y ago
If you have to introduce a build sequence to move to coffeescript then moving to coffeescript is definitely a net negative. I work on a >300k line JS codebase, and our tooling means you can make a change and hit f5 and you always get the latest version of the code. No file watching latency, no run-an-external-tool latency. We /could/ do the auto-reload thing, except that I think that for large applications with lots of state, that's probably the wrong choice. As far as I'm concerned visible 'builds' are the enemy to development. They take you out of your mental context, and in the worst case make even the tiniest changes painful. I've got nothing against pipelines of tasks, so long as the whole thing runs in milliseconds and is transparent to the developer. Obviously, you can do more on an occasional basis, perhaps before check in, and certainly in CI, but we need to reduce friction, and unnecessary build steps in environments that don't need them is a whole heap of friction.
- awj 13y ago
  I'd be really interested to see what you're doing that uses >300k lines of javascript all at once.
  - kybernetikos 13y ago
    I'm not sure what you mean by 'all at once', since rather obviously not all of those lines of code are running at once. The 'S' in SLOC does not stand for simultaneous. The application has been continuously developed for nearly 10 years now, and small parts of the current codebase are 5 years old. A little while ago, I was very pleased to find and remove some code that was weird in order to work in IE4, but these days I'm enjoying removing IE6 and IE7 specific code. IE8 is the last non es5 browser we have to support and it's painful. The whole application runs in the browser, and connects to services it needs via streaming connections. Once you take into account the fact that it's not just a couple of pretty forms for a back end application, plus the fact that in the browser you have to write things that come as standard in many other environments, plus the fact that you used to have to write extra code to work on different browsers, plus the fact that the javascript ecosystem was not up to the task back then so lots of things that would be generic now had to be written in house, plus the fact that it's extremely well tested both with unit tests, acceptance tests and integration tests, then a large codebase is really not all that surprising.
- lowboy 13y ago
  Transparent and instantaneous is my experience using grunt to watch and compile CS. It will only compile the changed file, not the entire codebase. It seems to happen instantaneously for me on file save, or at least within the time it takes for me to switch from my editor to my browser.