Hacker News Reader

Comment by ralmidani | Hacker News Reader

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.

View on HN

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.

CoffeeScript does not do anything framework- or library-specific. It simply compiles your code to JavaScript, which is then parsed and executed as usual.

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.

Its actually a great example of Coffeesctipt conciseness, the jQuery ready function is just $ ->

Yeah, play around with the online compiler on the website.

Your jQuery example would simply be written:

$ -> _..code here.._

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();

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.

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.

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

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.

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/ 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

IMO Python is way easier to read though..

  def foo(bar):
    a = bar + 1

  vs

  foo = (bar) ->
    a = bar + 1

Reply on news.ycombinator.com