Hacker News Reader

Comment by ryanfitz | Hacker News Reader

I would avoid even trying this framework out because its written in coffeescript. I have nothing against cs and write most of my clientside app code in cs, but I think libraries should avoid using it. Simply because it makes debugging more complicated. It adds in an extra step or 2 every time you see a js error, you need to read the compiled code and then figure out where that is actually coming from, from an unknown codebase (your framework/lib).

View on HN

1. CoffeeScript produces very readable JS. Not the same as handwritten, but close enough.

2. This is a framework. You are less likely to be debugging into it, unlike your own client-side libs written in CoffeeScript (which you mention doesn't bother you).

I don't agree with avoiding a library because it is written in CS.

When I am trying out/learning a new library or framework, I do a lot of tinkering, looking around and reading the source code. Coffeescript output is definitely readable, but you need to take a tiny bit of time to translate the coffeescript output, to the actual source so you can read it, checkout the comments etc to understand how you are supposed to do something. This added bit of time adds up quickly for me.

For example when I was first learning backbone, which is only around 1000 lines and very well documented. I was constantly reading the source code to understand why something wasn't working for me or how to implement something. Projects typically aren't nearly as well documented as backbone, making understanding the sourcecode even more essential.

If you're just reading the source of the framework, why not just read the Coffeescript source instead of reading the generated Javascript code?

Because Coffescript doesn't work in the browser, JavaScript does.

I'm very glad you posted your comment. It's a reasonable view and the one that I wanted to respond to.

To the author: I don't think you should rewrite this in JavaScript if you like CoffeeScript. I think you should write all of the examples in your README in CoffeeScript. I don't think you'll draw interest from people who aren't open to CoffeeScript, at least early on. Those who are already using CoffeeScript or are curious (I'm somewhere between the two) will prefer all the examples to be in CoffeeScript.

Besides that, there is some overhead in switching between reading the two languages. I was wondering why there were so many parens when I hit the first couple JavaScript examples.

I went kind of the opposite way and rewrote the initial example in JavaScript. I'd really prefer if people didn't get hung up on the fact that it's CoffeeScript, I don't think it should matter too much to people using the framework what language the internals are written in.

Unfortunately, it is an issue if you're not a regular CoffeeScript user yourself. If you're making significant use of any framework, at some point you're going to have to dive into the internals and figure out how it works or why is isn't working the way you expected.

With a CoffeeScript project, you either have the choice of reading code which wasn't generated with humans as its target audience, or code which actually expresses the author's intent, but using a language you don't normally read or write, which comes with its own bunch of constructs and idioms which you need to be able to transpile on the fly in your head to understand.

In that case, gods help you if the author has gone overboard on CoffeeScript's Rubyisms or used @ in a particularly esoteric way.

Reply on news.ycombinator.com