7 ms·

I give credit to CoffeeScript with really helping to push the ES specs forward and think it helped introduce more people to JS and grow the ecosystem. Heck, I u

I give credit to CoffeeScript with really helping to push the ES specs forward and think it helped introduce more people to JS and grow the ecosystem. Heck, I used it for a year, liked it, and had it change some of my approaches to writing JS. That said, I hope it slowly fades into the background as more people go back to vanilla ES6 or go with something more powerful such as TypeScript (or Flux). With the progress around es6 and es7, gradual typing, macros, and other tooling around the language, I think CoffeeScript risks becoming a drag on getting people to learn modern JS and instead sticking with a language that has a lot of ambiguous constructions and fewer and fewer advantages over JS.

ffn 12y ago
It's also possible folks will continue forking and improving CoffeeScript so that it keeps up with future releases of vanilla js (which is actually what I hope will continue to happen). Folks like me who come from a Ruby / Python background really don't like brackets and declaring variables, so things like Coffeescript, LiveScript, CoCo, etc. are wonderful tools even despite their occasional moments of weakness. That being said, you're absolutely right, folks who write in Coffee should also absolutely eventually learn all the tips and tricks behind vanilla js also if they don't want to be bogged down.
- smrtinsert 12y ago
  I almost feel like the coffeescript variants are where the action is.
  - berfarah 12y ago
    Care to list some? I'm always interested in seeing what's out there
    - Lazare 12y ago
      The big one is probably LiveScript. I feel like it removes some of CoffeeScripts rough edges (the big one is the scoping rules; in LiveScript you have to use := to modify a variable in in outer scope).
      - k__ 12y ago
        Yes, but they slowed down... The LS2 issues are from years ago and nothing is happening.
    - deleted 12y ago
      [deleted]
briandear 12y ago
I sure hope you're wrong. The unnecessary clutter of plain JS is just painful to look at. I can't remember how many times I've looked over a 40 line block of JS searching for a missing. When there are many )} )}; } ; } ; } -- it is just downright frustrating to be be wasting any time on what is effectively irrelevant syntax. With CS, it's indent and be done with it. It's like SASS vs. SCSS. Or Haml vs. ERB. I can't, for the life of me figure out why anyone would prefer more to less. To take Haml as an example: .my-div %h1 Some Text - some_ruby_code vs the ERB of <div class="my-div> <%h1> Some Text </h1> <% some_ruby_code %> </div>
- tiglionabbit 12y ago
  Ditching all the useless lines of closing brackets and parenthesis is my favorite part of using coffeescript. Matching up brackets is a pain. The less I have to do that, the better.
  - vidarh 12y ago
    My editors have had bracket/parenthesis matching for 30+ years, and automated indentation support as well. I don't get why anyone would do that manually.
    - k__ 12y ago
      Also if it works good, you can give them the same color as whitespace, which I always show, but with almost the same color as the background. This reduces the cognitive overhead a bit.
- tragic 12y ago
  > "With CS, it's indent and be done with it" As others have said, it's all fun and games until two people edit the same source file, one of whom has the dangerously incorrect opinion that tabs are better than spaces :-) I use a lot of semantic whitespace languages (CS, Haskell, Python), and it's a tradeoff: you gain in terms of redundancy, true, but there's an additional human overhead of making sure everyone's got their editors set up correctly. The larger the team, and a fortiori the number of teams, the bigger that overhead is. Smacking people about the head with PEP8 goes quite close to solving the problem in the Python world, but CS's Rubyish commitment to TIMTOWTDI militates against that. "It's like SASS vs. SCSS. Or Haml vs. ERB. I can't, for the life of me figure out why anyone would prefer more to less." Because HTML and CSS, despite their verbosity, are linguae francae. A CSS file is valid SCSS by definition - a less technical prototyper person can give you their code (perhaps even generated code from some wysiwig monstrosity) and you can refactor over it to remove redundancy, enforce conventions etc using the special SASS sauce. The SASS syntax does not. A HTML file, likewise, is already an ERB file. HAML is 'backwards compatible' with ERB/plain HTML, so far as I recall, but mixing the two syntaxes is very, very ugly and a dreadful idea, and I'm not sure if it's possible to mix the two in similar template languages (Jade etc). Point is: there is a human factor involved in picking shinier toys. I like HAML/Jade type templates, and Coffeescript for that matter, but I am far more comfortable using them on small teams or solo projects.
deleted 12y ago
[deleted]

ffn 12y ago

It's also possible folks will continue forking and improving CoffeeScript so that it keeps up with future releases of vanilla js (which is actually what I hope will continue to happen). Folks like me who come from a Ruby / Python background really don't like brackets and declaring variables, so things like Coffeescript, LiveScript, CoCo, etc. are wonderful tools even despite their occasional moments of weakness. That being said, you're absolutely right, folks who write in Coffee should also absolutely eventually learn all the tips and tricks behind vanilla js also if they don't want to be bogged down.

smrtinsert 12y ago
I almost feel like the coffeescript variants are where the action is.
- berfarah 12y ago
  Care to list some? I'm always interested in seeing what's out there
  - Lazare 12y ago
    The big one is probably LiveScript. I feel like it removes some of CoffeeScripts rough edges (the big one is the scoping rules; in LiveScript you have to use := to modify a variable in in outer scope).
    - k__ 12y ago
      Yes, but they slowed down... The LS2 issues are from years ago and nothing is happening.
  - deleted 12y ago
    [deleted]

briandear 12y ago

I sure hope you're wrong. The unnecessary clutter of plain JS is just painful to look at. I can't remember how many times I've looked over a 40 line block of JS searching for a missing. When there are many )} )}; } ; } ; } -- it is just downright frustrating to be be wasting any time on what is effectively irrelevant syntax. With CS, it's indent and be done with it. It's like SASS vs. SCSS. Or Haml vs. ERB. I can't, for the life of me figure out why anyone would prefer more to less. To take Haml as an example: .my-div %h1 Some Text - some_ruby_code vs the ERB of <div class="my-div> <%h1> Some Text </h1> <% some_ruby_code %> </div>

tiglionabbit 12y ago
Ditching all the useless lines of closing brackets and parenthesis is my favorite part of using coffeescript. Matching up brackets is a pain. The less I have to do that, the better.
- vidarh 12y ago
  My editors have had bracket/parenthesis matching for 30+ years, and automated indentation support as well. I don't get why anyone would do that manually.
  - k__ 12y ago
    Also if it works good, you can give them the same color as whitespace, which I always show, but with almost the same color as the background. This reduces the cognitive overhead a bit.
tragic 12y ago
> "With CS, it's indent and be done with it" As others have said, it's all fun and games until two people edit the same source file, one of whom has the dangerously incorrect opinion that tabs are better than spaces :-) I use a lot of semantic whitespace languages (CS, Haskell, Python), and it's a tradeoff: you gain in terms of redundancy, true, but there's an additional human overhead of making sure everyone's got their editors set up correctly. The larger the team, and a fortiori the number of teams, the bigger that overhead is. Smacking people about the head with PEP8 goes quite close to solving the problem in the Python world, but CS's Rubyish commitment to TIMTOWTDI militates against that. "It's like SASS vs. SCSS. Or Haml vs. ERB. I can't, for the life of me figure out why anyone would prefer more to less." Because HTML and CSS, despite their verbosity, are linguae francae. A CSS file is valid SCSS by definition - a less technical prototyper person can give you their code (perhaps even generated code from some wysiwig monstrosity) and you can refactor over it to remove redundancy, enforce conventions etc using the special SASS sauce. The SASS syntax does not. A HTML file, likewise, is already an ERB file. HAML is 'backwards compatible' with ERB/plain HTML, so far as I recall, but mixing the two syntaxes is very, very ugly and a dreadful idea, and I'm not sure if it's possible to mix the two in similar template languages (Jade etc). Point is: there is a human factor involved in picking shinier toys. I like HAML/Jade type templates, and Coffeescript for that matter, but I am far more comfortable using them on small teams or solo projects.

deleted 12y ago

[deleted]