6 ms·

If you like Python, you will love CoffeeScript. :) I have not used Underscore/Lodash in production, but I use jQuery a lot with CoffeeScript. CoffeeScript does

If you like Python, you will love CoffeeScript. :) I have not used Underscore/Lodash in production, but I use jQuery a lot with CoffeeScript. CoffeeScript does not replace jQuery, although it can make your jQuery a lot nicer. As far as other libraries, there really are no restrictions; CoffeeScript compiles transparently to JavaScript. The only thing holding it back would be poor support in the specific ecosystem you are working with, such as a lack of plugins that automate the build process. In that case, you may need to compile manually or set up your own build script. But other than that, you can use CoffeeScript in place of JS pretty much anywhere.

no_wizard 9y ago
I figured jQuery would be fine. Now that I think about it, I can't imagine why most things wouldn't really, since all javascript libraries are just extensions of those things. Does CoffeeScript just convert the modules methods/functions accordingly when needing to be called? Just curious how that works. Since so much of JavaScript development, especially nowadays, ties into a lot of frameworks/libraries (modules? I'm not always sure what we want to call it), I just didn't see a reference (maybe I missed it) on their page in regards to what it actually looks like to invoke module/framework/library specific things.
- ralmidani 9y ago
  CoffeeScript does not do anything framework- or library-specific. It simply compiles your code to JavaScript, which is then parsed and executed as usual.
  - no_wizard 9y ago
    Good point. I guess I'm not making myself clear. If I'm working with jQuery, for instance, do I need to do anything different than I do now in terms of invoking say, the simplest thing, $(function({_..code here.._}) (or for you old schoolers $document.ready({_..code here.._}). Thats what I guess I mean. Maybe I just need to toy with it. I suspect I might be overthinking this in my head.
    - maxscam 9y ago
      Its actually a great example of Coffeesctipt conciseness, the jQuery ready function is just $ ->
    - ralmidani 9y ago
      Yeah, play around with the online compiler on the website. Your jQuery example would simply be written: $ -> _..code here.._
- syntheticcdo 9y ago
  I work with a 100% CS code base and lodash chains are a dream working in CS as opposed to vanilla JS, something like: capitalStringsWithX = _.chain array .map (item) -> item.toUpperCase() .filter (item) -> item.includes "X" .value() as opposed to: var capitalStringsWithX = _.chain(array) .map(function(item) { return item.toUpperCase(); }) .filter(function(item) { return item.includes("X"); }) .value();
deleted 9y ago
[deleted]
nickm12 9y ago
I love Python, but I always found CoffeeScript took Python's stylistic choices too far. Making {} around object literals and () after function calls optional led to code that was very difficult to visually parse.
- jononor 9y ago
  My style guides to avoid this: - Only use {}-free object literals in assignment - Always add () to nested single-line function calls, and calls with expressions.
- molszanski 9y ago
  My friend that is using cs every day now was also using () around every function call back in the day. Now he doesn't. I think it is more of a preference that _changes_ over time. Just saying that you might like it the other way one day
  - nickm12 9y ago
    Maybe. I only used CS for one project, after years of primarily programming Python. I could also believe that, if applied judiciously, the characters could be dropped without harming clarity. However, the codebase I was working in had no clear style guidelines about when it was acceptable to drop braces/parens and so it left me wanting for Python's "there's one way to do it" aesthetic.
    - molszanski 9y ago
      I agree. It is not advised to introduce confusing syntax if there is a chance that somebody outside of the group would use the code. It is even more frustrating in .js repositories today. People use various ESXX flavours and syntaxes that might not compatible with each other. Just look at this list: https://babeljs.io/docs/plugins/ https://babeljs.io/docs/plugins/ My favorite is: babel-plugin-transform-decorators-legacy (A plugin for Babel 6 that (mostly) replicates the old decorator behavior from Babel 5) Talk about code reuse
galfarragem 9y ago
IMO Python is way easier to read though.. def foo(bar): a = bar + 1 vs foo = (bar) -> a = bar + 1

no_wizard 9y ago

I figured jQuery would be fine. Now that I think about it, I can't imagine why most things wouldn't really, since all javascript libraries are just extensions of those things. Does CoffeeScript just convert the modules methods/functions accordingly when needing to be called? Just curious how that works. Since so much of JavaScript development, especially nowadays, ties into a lot of frameworks/libraries (modules? I'm not always sure what we want to call it), I just didn't see a reference (maybe I missed it) on their page in regards to what it actually looks like to invoke module/framework/library specific things.

ralmidani 9y ago
CoffeeScript does not do anything framework- or library-specific. It simply compiles your code to JavaScript, which is then parsed and executed as usual.
- no_wizard 9y ago
  Good point. I guess I'm not making myself clear. If I'm working with jQuery, for instance, do I need to do anything different than I do now in terms of invoking say, the simplest thing, $(function({_..code here.._}) (or for you old schoolers $document.ready({_..code here.._}). Thats what I guess I mean. Maybe I just need to toy with it. I suspect I might be overthinking this in my head.
  - maxscam 9y ago
    Its actually a great example of Coffeesctipt conciseness, the jQuery ready function is just $ ->
  - ralmidani 9y ago
    Yeah, play around with the online compiler on the website. Your jQuery example would simply be written: $ -> _..code here.._
syntheticcdo 9y ago
I work with a 100% CS code base and lodash chains are a dream working in CS as opposed to vanilla JS, something like: capitalStringsWithX = _.chain array .map (item) -> item.toUpperCase() .filter (item) -> item.includes "X" .value() as opposed to: var capitalStringsWithX = _.chain(array) .map(function(item) { return item.toUpperCase(); }) .filter(function(item) { return item.includes("X"); }) .value();

deleted 9y ago

[deleted]

nickm12 9y ago

I love Python, but I always found CoffeeScript took Python's stylistic choices too far. Making {} around object literals and () after function calls optional led to code that was very difficult to visually parse.

jononor 9y ago
My style guides to avoid this: - Only use {}-free object literals in assignment - Always add () to nested single-line function calls, and calls with expressions.
molszanski 9y ago
My friend that is using cs every day now was also using () around every function call back in the day. Now he doesn't. I think it is more of a preference that _changes_ over time. Just saying that you might like it the other way one day
- nickm12 9y ago
  Maybe. I only used CS for one project, after years of primarily programming Python. I could also believe that, if applied judiciously, the characters could be dropped without harming clarity. However, the codebase I was working in had no clear style guidelines about when it was acceptable to drop braces/parens and so it left me wanting for Python's "there's one way to do it" aesthetic.
  - molszanski 9y ago
    I agree. It is not advised to introduce confusing syntax if there is a chance that somebody outside of the group would use the code. It is even more frustrating in .js repositories today. People use various ESXX flavours and syntaxes that might not compatible with each other. Just look at this list: https://babeljs.io/docs/plugins/ https://babeljs.io/docs/plugins/ My favorite is: babel-plugin-transform-decorators-legacy (A plugin for Babel 6 that (mostly) replicates the old decorator behavior from Babel 5) Talk about code reuse

galfarragem 9y ago

IMO Python is way easier to read though.. def foo(bar): a = bar + 1 vs foo = (bar) -> a = bar + 1