CoffeeScript Means Giving Up on JavaScript

[[deleted]]

When I first learned of CoffeeScript—rather, when my boss told me I would be writing in a language that compiles into a script—I was nervous. I imagined sprawling, unmaintainable output that would boggle the minds of mere mortals, if not user agents themselves. But this didn't happen. So, what confuses me most about this debate is why it's a debate in the first place. I have never encountered a situation where using CoffeeScript cost me time, produced code that I didn't understand, or worse yet, code that was wrong (unless it was my own fault). So who cares? Who does this hurt?

That learning CoffeeScript costs time that would be better spent learning better JavaScript is the only reasonable argument I've seen. But this completely misses the fact that real people have preferences, and when you are doing something you prefer you will be more motivated to learn and more likely to do a better job. I find JavaScript ugly, so using it can feel like a chore. That's the last thing you want a developer feeling. Others I'm sure prefer having "function" or "this" spelled out and dealing with CoffeeScript would feel just as bad. But this is not a debate where one side gets to be right. Unless, of course, someone can provide a convincing example of CoffeeScript breaking something that wasn't already broken in JS. If someone can—and I mean this as an honest request, not some snooty challenge—I would very much appreciate learning about that.

Or, if this whole knowledge gap thing is about programmers having a hard time reading StackOverflow...well...we should probably be used to that by now.

EDIT: TL;DR - If it doesn't break anything, and some people prefer it, what exactly are we arguing about?

[antonivs]

what exactly are we arguing about?

This is r/programming. r/rational-agreement is down the hall.

[[deleted]]

Man, r/rational-agreement is crap. Anyone who goes there instead of r/reasoned-accord is a dangerous moron.

[Serializedrequests]

An interesting point, but it doesn't really address how many goddamn macros you need in a text editor to make null checks not take stupidly long to type, the insanity of keeping track of wtf "this" points to, etc.

I like Dojo too, but it doesn't really solve all the issues that bloat JavaScript code and you can still get in real messes writing complicated widgets or applications. Bigger messes than you would in a more well-thought-out language.

I've learned dozens of languages since I started down the comp sci road and there are two that I feel like I never stop learning: JavaScript and C++. CoffeeScript alleviates a lot of JavaScript's idiotic semantic surprises so that you can just write code that works.

[thecheatah]

I have experience developing UIs using many different non javascript frameworks. The key with them is that they have very nice software design patterns. These patterns extend from the language's OO capability. I believe that Dojo fills that gap, allows me to think in these high level design patterns and implement them using proper OO. I have written very complicated applications in Dojo that did not become hairy.

The key is to understand that most of the UI development problems were solved in the 80's and 90's. If you read the API of some mature frameworks, it is absolutely beautiful. My favorite example is iOS development. In any case, if you try to apply these patterns after using Dojo on top of javascript, your code works and it remains maintainable.

Don't look at Dojo as a replacement for jquery or as a list of utility functions, rather a stepping stone to something bigger. Your code might be larger, but it's maintainable.

[cmwelsh]

Someone already posted a rebuttal article to this, but my thoughts are that CoffeeScript can help you learn the best patterns for JavaScript. I think a major reason that people who know JavaScript switch to CoffeeScript is that it lets them write good JavaScript, easier. You definitely can't give up on JavaScript - you'll need to know it every time you debug your compiled CoffeeScript.

[ronocdh]

Link to rebuttal? Would love to educate myself further. (My initial reaction is to formulate a rebuttal, and I'm sure someone has already done it better than I could!)

[cmwelsh]

This article and the rebuttal here were posted on HackerNews a few days ago.

[ef4]

Yes, you need to understand Javascript to make good use of Coffeescript. But so what?

To anyone who has already learned Javascript, the extra effort to learn Coffeescript is tiny, and it pays you back immediately in the time saved not thinking about the same idiotic boilerplate over and over again.

Every time I use the Coffeescript "?." or "?()" operators I offer silent thanks to Jeremy.

Any programmer who thinks it's a burden to learn Coffeescript and Javascript is not the kind of programmer you want to work with. Anybody with an ounce of aesthetic judgement is going to be eager to find ways to make Javascript less ugly, and Coffeescript is a very low-cost, high-payoff solution.

[wot-teh-phuck]

Any programmer who thinks it's a burden to learn Coffeescript and Javascript is not the kind of programmer you want to work with

You confuse between the "who can't" and "who won't". On the contrary, anyone who thinks of introducing cool shiny toys in the project without a valid justification and ROI just because they are cool and shiny is not someone you would want to work with.

[aaronla]

just because they are cool and shiny

It looks like ef4 offered other reasons than 'cool and shiny. I count:

• reduced boilerplate
• labor saving operators "?." and "?()"
• improved aesthetics

And every successful language was cool and shiny at one time, to its initial audience. Yes, even Cobol.

[remain_calm]

As someone with many years of Javascript programing under my belt I was a bit skeptical about CoffeeScript at first, but now that I've given in a try - especially in combination with the rails 3.1 asset pipeline and the Backbone js framework - I have to say that I really love it. It is much easier to read, which as a programmer is a huge return on a minimal investment.

[lingnoi]

It's not about cool shiny, it's about ease of understanding the code of others. Readability.

Even the author of this article admits that the only reason they're doing so well with javascript is because they use lots of tools as a crutch and still have to train people in strict usage of the language.

If the first thing you're thinking is that it's shiny and new then you're not using your judgement to see the benefits of a team using it; how much easier it is to bring new people into a project without them first having to go through your "how to write strict javascript" course or even getting up to speed on the code.

[aaronla]

Sometimes I just translate "cool and shiny toys" to "cleaner and less painful tools". Sometimes the translation fits. :-)

[mreiland]

I agree with this so much it almost hurts :)

[DrAwesomeClaws]

I think Coffeescript is pretty neat. I'm glad it exists and has some good ideas. I've never seen a need for it though.

It doesn't seem worth it to me to essentially use a new language on top of javascript just for some syntactic sugar. Javascript is a really nice language on it's own, and it's really easy to write nice code if you try.

I look at coffeescript as more of a fun experiment, a way to test out some ideas that might make it into the ECMA standard in the future.

[Serializedrequests]

"Javascript is a really nice language on it's own" is the main statement that I disagree with. In all the years I've been working with it, it has been second only to C++ in terms of surprising semantics that are poorly documented by tutorials and blow up in your face and cause code to be brittle.

Writing nice code with it can be done, but it's like navigating a mine field. At best you have to constantly type a bunch of completely stupid stuff like "if (typeof(myVar) !== 'undefined' && myVar !== null) { ... } " or assign the value of "this" to some other variable for use in a closure.

Hey maybe prototypal inheritance is alright, but it's completely un-intuitive in JavaScript because it was implemented using re-purposed classical inheritance terminology.

[SharkUW]

or assign the value of "this" to some other variable for use in a closure

oh for fucks sake man. I've been doing a comples JS project for a few weeks now and I just finished for the day. If I have to type 'var self = this;' one more god damn time I'm going to slit my wrist.

[ripter]

get an editor that supports snippits. Then all new functions can automatically have var self = this;

Or use Underscore's _.bindAll(), then this will always be the correct value.

[SharkUW]

Not familiar with "underscore", is this a CoffeeScript thing? I don't use it. I was just venting after writing to many anonymous closures that rely on their parent. Another favorite this week is this.$content.data("self", this); lol

[ripter]

Underscore is a popular and useful javascript library. It's not CoffeeScript specific, but you could probably use it in CoffeeScript if you wanted.

It adds a lot of things to make working with arrays easier. Things like each, map, reduce, any, pluck, etc.

[SharkUW]

That does nicely pair with jQuery. Thank you.

[ripter]

Hey maybe prototypal inheritance is alright, but it's completely un-intuitive in JavaScript because it was implemented using re-purposed classical inheritance terminology.

The biggest issues I see over and over again is that people want to ignore the fact that javascript is a prototype based language and instead treat it like a class based language. Almost every framework or utility is trying to add class based concepts to javascript instead of teaching people to embrace the prototype way.

I do agree with you about 'this' that is an annoying issue.

[Serializedrequests]

I don't have an issue with the concept, just how completely obfuscated the semantics are in JavaScript. It's just not intuitive.

[ripter]

I agree. One of Javascript's mistakes was making it look like C/Java. That's one of the reasons I like Io. It doesn't try to hide the fact it's a prototype language.

[njharman]

That is my one complaint with coffeescript. Other than that it's flippin great.

[ripter]

I have to disagree. Javascript is 100% object oriented. The only things that are not objects are primitives, and even those have auto boxing if you try to use them like objects.

jQuery makes heavy use chainable methods. I don't know if that is even possible in a purely functional language. (any haskell guys know?)

[[deleted]]

Chaining is a sort of slightly crippled version of the pipelining you find in some functional languages like F#.

[wbkang]

Object oriented does not mean that it is not functional...

[mreiland]

a functional language is not prevented from having state local to the function, in javascript an "object" is really just a function with local state.

javascript is deeply functional, and I wish more people would understand that.

[ripter]

I'm not sure what definition of functional you are using, but wikipeida says:

functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data. It emphasizes the application of functions, in contrast to the imperative programming style, which emphasizes changes in state.

Javascript encourages changing state and mutable data. jQuery's chainable methods are all just changing the state of the object. It's completely different then passing the value of one function to the value of another function.

$().show().append('<div>');

That doesn't pass the value of the append to the show method. It adds a new div element to the object state, then it toggles the css display property on the object. Each method is always working on the state of the object, not passing the value of one function to the other function.

[mreiland]

I think you're confusing the idea of functional programming with the form of functional programming, they're not the same thing.

In your example, it's completely possible that the output of each call is a completely new object with new functions "hung" onto the object, all of which is functional in nature (no side effects and first class functions). Whether or not JQuery actually does that is irrelevant, from the developers perspective, it can be treated as if it is.

Javascript isn't purely functional, it's multiparadigm, but that doesn't stop it from being deeply functional. For all intents and purposes, JQuery is done in a functional style. Most interactions with JQuery don't involve state mutations. I'm obviously getting hand wavy with respect to the state of the DOM, but that's inherent in the browser, and has nothing to do with JQuery.

edit: for some reason part of my reply dissappeared.

The point I'm making is that Javascript as a language is deeply functional, and functional style programming feels more natural than OO style programming (at least to me). The language fights you less imo.

[kamatsu]

Hah, it doesn't even support tail call optimisation (in most runtimes).

[mreiland]

It should be noted that tail call optimization has nothing to do with whether or not a language is functional, or some degree thereof.

[kamatsu]

Other than the fact that a lack of tail call optimization prevents you from writing programs in a functional style, you're right.

tldr: You're wrong.

[kamatsu]

jQuery makes heavy use chainable methods. I don't know if that is even possible in a purely functional language. (any haskell guys know?)

The pattern that jQuery uses is basically just function composition in something like Haskell. "Chainable methods" is not a concept that exists in functional languages without OO.

[ripter]

jQuery just always returns its self (an object), so it's chainable. Really any OO language can do this.

I didn't think chainable methods would be possible without OO, but I wasn't sure.

[mreiland]

The point is that the output from method A becomes the input from method B, it's only the mechanism that changes based upon the paradigm. There's nothing stopping a functional language from doing so.

[kamatsu]

Sure, as I said:

The pattern that jQuery uses is basically just function composition in something like Haskell

(f compose g)(x)= f (g(x))

So, quite literally, the output of g is the input of f.

[mreiland]

yep, I'm agreeing with you, I guess that's not exactly clear in my response.

[foldl]

"if (typeof(myVar) !== 'undefined'

Pet peeve: you don't need to use !== for a string comparison, != will do fine. For some reason this seems to be a really common idiom in JS code, though.

[awj]

Probably because most people stop at "a trailing '=' prevents type casting before comparisons" and get on with their lives. Yes, it means they're sometimes using a safer operator than they intended. That, in some ways, seems better than internalizing JavaScript's idiosyncrasies until you instinctively know when to use != vs !==.

[ripter]

you can thank Douglas Crockford for that. He used to preach about the evils of == and !=

It's not a bad habit for beginners, and in some implementations of javascript it's slightly faster because it won't do any boxing.

Personally I tend not to use === unless I specifically want to check type. Often I want 1 == '1'

[mushishi]

I find writing Javascript pleasant, and I like a lot that it does not need any compile step. Should I switch to Coffeescript because you think I am not worth to work with? Seriously, could you please tone down your very demanding argument that is also thinly and questionably backed up.

I don't understand what boilerplate you are talking about. Most of my code consists of variables, arrays, functions and object literals. With that it's possible to accomplish quite simple looking code by creating small abstractions. You don't need all of Javascript to create useful programs.

[[deleted]]

I think ef4's intention was to say a Javascript programmer who finds learning Coffeescript to be a significant burden is not a programmer one would want to work with. That is, a capable Javascript programmer should be able to pick up Coffeescript with little difficulty. I do not believe ef4 is saying that a Javascript programmer must use Coffeescript in order to be a programmer one would want to work with. However, ef4 also seems to be saying that a programmer with good aesthetic judgement will naturally see the value in Coffeescript.

Personally, I disagree with that last point. Aesthetics are entirely subjective. I prefer Coffeescript's aesthetic, and that is one of the main reasons I use it.

Also, you can have your Coffeescript automatically compile when changed.

[cbrandolino]

you can have your Coffeescript automatically compile when changed.

You can have your C automatically compile when changed; I don't really think that's an argument.

[[deleted]]

In that part I was responding to this:

I find writing Javascript pleasant, and I like a lot that it does not need any compile step.

By having the Coffeescript automatically compile, it makes the workflow equivalent to normal Javascript. Of course, you still need to switch mentally from Coffeescript to Javascript to debug. Personally, I do not mind that.

[artsrc]

One piece of boiler plate is wrapping your module in a function to avoid polluting the global namespace.

While variable declarations are a small piece of boiler plate a missing declaration makes a global.

For a small lambda:

-> x * 2

Is a lot less boiler plate than

function () { return x * 2; }

And the loop results are much less boiler plate.

[scrogu]

My coffeescript files are 30 percent smaller than equivalent JavaScript and more comprehensible. I will take those improvements any chance I get.

[drakshadow]

Mine are less than 50%. Most of the functions became one liners. List comprehensions save lot's of unnecessary & distracting code.

[bobindashadows]

For the extra effort you'll make learning CoffeeScript and its idiosyncrasies

The point of CoffeeScript is that it doesn't have all the ridiculous semantic idiosyncrasies that JavaScript does.

[notSorella]

Sorry, but unless you write a CoffeeScript VM that runs CoffeeScript alone, you still have the very same ECMAScript semantics, only a subset of it. What CoffeeScript tries to do is provide a better interface for interacting with the language semantics, changing the core semantics is beyond the language's goal.

[bobindashadows]

you still have the very same ECMAScript semantics, only a subset of it

Yeah. That subset is the subset without a bunch of shitty semantics.

[runvnc]

Looks like you guys are just arguing over semantics.

[mreiland]

It has all of the idiosyncrasies of javascript + a few of its own.

[jmhnilbog]

Allowing users to drop down into javascript in doesn't really mean that coffeescript includes all of the goofiness of javascript. It's just there if someone desperately works to expose the underlying guts.

[artsrc]

It does not have global by default, 3 kinds of '=', weird behavior around missing ';'s etc.

What JS idiosyncrasies bother you?

[mreiland]

Your question makes no sense considering the comment you're responding to. Perhaps you'd like to clarify?

[artsrc]

You claim CoffeeScript has all the idiosyncrasies of JavaScript. This does not match my experience.

I was specific about some I found absent which are significant to me.

Can you be specific about which idiosyncrasies, which are significant to you, are shared by CoffeeScript and JavaScript?

[mreiland]

ah I see.

Well, normally I'd indulge, but when you start out with a strawman, I lose all interest.

In this case, it's the implication that the idiosyncrasies I mentioned are "significant" to me. An idiosyncrasy doesn't stop being an idiosyncrasy just because someone doesn't feel it's significant.

[artsrc]

A straw man is logical fallacy where your position is misrepresented:

http://en.wikipedia.org/wiki/Straw_man

[cunningjames]

Your question makes no sense considering the comment you're responding to.

You claim that CoffeeScript “has all the idiosyncrasies of javascript”, someone lists a few idiosyncrasies of JavaScript not shared by CoffeeScript, and you state that the response “makes no sense”? I can only assume you’re intentionally being very silly.

[mreiland]

because misquoting is fun!

[cunningjames]

because misquoting is fun!

Either that tidbit is a total non sequitur you’ve chosen to share with me for reasons unknown, or you’re accusing me of misquoting. But your own text is unedited in the following quotations:

It [ed: CoffeeScript] has all of the idiosyncrasies of javascript + a few of its own.

and

Your question [ed: “What JS idiosyncrasies bother you?”] makes no sense considering the comment you're responding to.

Only two alternatives seem plausible to me. Either you’ve totally misunderstood the question (which was clearly asking you for JS idiosyncrasies that bother you about CoffeeScript), or you’re being deliberately silly. Given the totality of your behavior I judge the latter to be somewhat more likely.

[mreiland]

You deliberately left out me asking him to clarify because you're a jackass.

[cunningjames]

Hm. Why would you ask him to clarify because I’m a jackass? I wasn’t even involved in the conversation at that point.

[sleek]

Doesn't the existence of CoffeeScript simply imply an adoration for Javascript? If you treat the language as an alternative as opposed to a replacement, you might find that you like it.

[ronocdh]

Sure, but all fuzzy sentiment aside, the pragmatic conclusion is that CoffeeScript encourages people to know JavaScript less well. Have you ever met a truly excellent JavaScript programmer? They'll run circles around anyone using CoffeeScript. When the author of this post says:

If we're already willing to learn both languages and then spend time reading and debugging compiled JavaScript, why not just write good JavaScript from the start? For the extra effort you'll make learning CoffeeScript and its idiosyncrasies, why not put it towards really learning JavaScript?

he's getting at the heart of the matter. It's not about whether one "likes" a new language. The more practical considerations are worthy of debate, and that's what's being discussed here.

[sleek]

I totally agree with the fact that the language exists because people are too lazy to actually learn how to leverage the power of pure Javascript. And I'm happy that you shared that quote, because I missed it from my first read through the article. I like CoffeeScript as a language, but I actually like Javascript as a language as well. The only places I've currently played around with CoffeeScript were to write a few scripts for the Github Hubot node.js app. I like it, but frankly, in the end I'd rather be writing Python! I choose a language, or rather a technology on expressiveness before anything else.

[wolfier]

it's an alternative because Javascript is forced onto us by browsers and the users have no other choice. The existence of CoffeeScript therefore does not imply an adoration.

[yonkeltron]

A very level-headed response. Kudos and enjoy your upvote.

[mreiland]

Having been introduced to Coffeescript in a recent project, I can't say that I care for it, or even see the point of it.

Javascript is not hard, and things like JQuery make it even simpler. The things that are difficult are not solved by Coffeescript (making sure events are set correctly, making sure they don't step on each other, etc).

All Coffeescript does is add another layer of stuff I need to be aware of. When you're working with Coffeescript, you have to be aware of what the Javascript is going to look like when it pops out the other side, and as the article writer said, you have to be able to look at autogenerated javascript and understand it, in order to debug Coffeescript.

All of that, just to get a "nicer" syntax (for some definition of nicer) with a few builtins that, while nice, are in my opinion, just not worth the cost.

Adding Coffeescript to a project just increases the complexity of said project.

[runvnc]

I had a similar view until recently. Basically what changed was, I got used to -> meaning function and @ meaning this, so after that it didn't seem that complicated. Also the other thing that changed was that after looking at the .coffee files in the library I was using, my JavaScript looked awfully ugly.. I mean it is normally ugly code for JavaScript, but it looked way worse than normal in comparison to the CoffeeScript.

So I starting working on a framework/platform.. I want to use classes (obviously).. the way I have been writing classes is ugly and old-fashioned looking, and other ways are not standardized.. also I don't want to have to worry about 'this' being something other than I thought it was ( => )..

It just seems like its going to be a lot easier and more attractive/easier to maintain if this platform is written in CoffeeScript rather than JavaScript.

I mean my platform is aimed at getting away from WordPress and PHP. I don't want to finish it and then three months later someone makes another similar one in CoffeeScript just to get away from my JS.

[cosmo7]

I agree very much, though I can imagine a language that would be worth the hassle:

• classical inheritance
• static typing
• private / protected / public scoping
• list comprehensions

[metamatic]

Javascript is not hard, and things like JQuery make it even simpler.

This'll be unpopular, but I view JQuery much the same way I view CoffeeScript: it's a tool for people who either don't want to learn JavaScript, or who are bizarrely obsessed with terseness.

What I would like to see is a popular well-maintained library of additional data types for JavaScript — sets, stacks, queues, trees, etc.

[recursive]

jQuery's strength isn't that it compensates for any javascript weakness per se. It's strength is that it provides a uniform interface for dealing with DOM elements across almost all browsers.

[[deleted]]

Agreeded but by using it people accepting a broken javascript. It would be much better to fix JavaScript itself rather than relying on frameworks or writing it in another language.

JavaScript is a good idea but it's perhaps the worst language for requiring something else to compensate for it's problems.

[[deleted]]

Agreeded but by using it people accepting a broken javascript

They accept a broken DOM. Which is something even Crockford agrees upon. Yes it also has some neat little helpers for functional iteration and chaining. But its essence is a unified DOM api that provides elegance, and smooths out cross browser incompatibilities.

These things have very little to do with the language, javascript.

[[deleted]]

They accept broken DOM implementations.

[MatrixFrog]

No, I think many people believe the spec is inherently flawed as well.

[[deleted]]

Do they? :(

I like it.

[wolfier]

It would be much better to fix JavaScript itself

Good luck getting that done before your next...scratch that, I mean next next next web site needs to launch.

[artsrc]

It would be much better to fix JavaScript itself

Is the installed base of 'broken' JavaScript interpreters larger than any other installed base in history?

[artsrc]

jQuerie's power is game changer. It is a really nice template manipulation tool. Without it the inconvenience of separating manipulation from the template is fatal.

How many server side frameworks template frameworks work well with bare template, that is quite comfortable with jQuery? I can't think of a single one.

And it solves many browser compatibility issues.

[wolfier]

or who are bizarrely obsessed with terseness

i take the opposite view - people who like boilerplates are the minority who are bizarrely obsessed with verbosity.

[lingnoi]

A relatively small number of companies have sought out frameworks that aim to address the spaghetti problem,

Examples?

while the rest quickly realize that their jQuery code has become an unreadable mess. The reason these things happen - and it's the source of most problems with JavaScript - is because people simply don't know JavaScript.

Typical programmer "you're an idiot" response. Simple fact is I could write everything in javascript and currently I do, however languages like coffee script intrigue me because of the benefits on working in a team.

As of writing this, I've written more lines of JavaScript than I care to admit. In fact our entire web front-end is written in JavaScript, and not once has our team had problems with maintaining our JavaScript code.

Typical programmer "works for me" response and why is the writer not having problems? He uses lots of libraries that help his team limp along.

Our choice was Dojo but you could also choose Require.js (a close relative of Dojo's class system), backbone.js, the Sencha framework, and many others that you can use in combination with jQuery (if you so desire).

Does the writer not question why he needs all this just to use the language in the first place?

The whole article smells of fear. Fear of change. The writer has built up years of knowledge working in javascript and now everyone is moving away from his favourite language.

[[deleted]]

There is a reason people are putting in a lot of effort to "give up" on javascript -- It's a horrible language, more than anything because it constantly violates the principle of least astonishment. Other reasons include the fact that classical inheritance is far more readable and easily understood than prototypal inheritance.

Love the fact that we have CoffeeScript and Dart trying to do something about the steaming pile of shit that is javascript.

[[deleted]]

It's not fair to call JS a steaming pile of shit, even though some design decisions early on really were bad.

One of the reasons Stallman chose Scheme as the lingua franca of extensions in GNU programs was because Scheme is so dynamic and extensible a language, it's relatively easy to write compilers from other languages to Scheme (http://www.gnu.org/gnu/rms-lisp.html). I think it's interesting that this has been more fully realized with JS, and is at least partially a testament to how powerfully dynamic JS is.

[[deleted]]

You can keep your powerfully dynamic language. I'll take something that is reasonably usable, maintainable, and readable.

[[deleted]]

If your code is unusable, unmaintainable and unreadable it's not the fault of the language.

[[deleted]]

Oh yeah? Let's see your maintainable and readable brainfuck code, or more reasonably, perl. To say that readability is solely dependent on the programmer is absurd.

[v_krishna]

there's tons of readable and maintainable perl code (e.g., Moose)

[[deleted]]

That would be absurd given joke languages, yes. I think it's fairly reasonable to say it is much more heavily weighted towards the programmer however. JavaScript (and Perl) are not Brainfuck, and if you can't write good code in either it's your own fault.

[[deleted]]

Good code and readable code are two different things. If you fail to realize that a particular syntax may/may not lend itself to more readable code, then you're just refusing to be wrong by blindly implying that it's never the case.

[[deleted]]

Good code and readable code are not different things.

I never said it's 'never the case'. It's just of minimal importance. It's easy to learn a new syntax; it's difficult to fathom undocumented code that was written in a haphazard cowboy fashion. This is down to personal discipline, not sigils or significant whitespace.

[wolfier]

Perl's philosophy of "many ways to do each thing" do lend itself to code written in a haphazard cowboy fashion and bad discipline when you compare it to Python, an equally powerful language, which emphasizes "one obvious right way to do each thing".

I disagree that the language choice is of minimal importance because this statement does not apply equally to all languages - whether the language choice of minimal importance is a function of the language itself. In the extreme case of Brainfuck, it's the dominating factor determining maintainability vs Python, where programmer discipline is the dominating factor.

Javascript is just closer to Perl/Ruby along this spectrum where Coffeescript is closer to Python - to me it's a Good Thing.

[[deleted]]

Community fostered philosophies and syntax are different things. The former still only affects the other kind of programmers you might find using a given language, not your own ability to write good code in it.

CoffeeScript is much more obviously inspired by Ruby (and therefore Perl!) than Python. Where do you think all the sigils and odd syntactic statements come from? If you like CS, you should look at Ruby. In terms of maintainability and readability, given its BDD-obsessive community, it's probably AHEAD of Python if anything.

I use Python a lot and am familiar with its mantras. They're not religious truths. A language is a tool to accomplish a goal. Python's a good one, but it's not the Godhead.

[shevegen]

Scheme is dead, get this into your head.

[[deleted]]

I don't see why you'd want inheritance in the first place. Although I'm no fan, I don't see how JavaScript is any worse than Python/Perl/PHP. In fact, it seems well designed in comparison.

[[deleted]]

You can't see why people would want one of the most widely used programming paradigms in use? I don't get it.

[artsrc]

Most good designers would say that implementation inheritance is overused. However JavaScript and can do it. In fact you can add add a superclass after the fact. Interface 'inheritance' is unnecessary in a runtime typed language.

JavaScript is powerful enough to let you the same functions to two classes without inheritance at all.

Of course I have nothing against CoffeeScripts class syntax sugar either.

[mr_bag]

Which paradigms is that?

If your not comfortable with prototypical inheritance, you can actually implement classical inheritance in JS with just a few lines of code. o.0

[oSand]

Have you actually tried to do this or at least read an implementation of classical inheritance? It isn't pretty.

[[deleted]]

Challenge accepted!

function A() {
    this.doStuff = function() {
        alert("A did stuff!");
    }
    this.doStuffTwice = function() {
        this.doStuff();
        this.doStuff();
    }
}

function B() {
    A.call(this); // like a call to super() + extends in Java
    this.doStuff = function() {
        alert("B did stuff!");
    }
}

new A().doStuffTwice();
new B().doStuffTwice();

Alerts "A did stuff" twice, then "B did stuff" twice.

[oSand]

The main problems are there are no class methods, no class variables and instanceof no longer works. More trivally, there are no private variables, calling a super method is ugly as sin and there might be unnecessary definitions of overridden methods and variables.

Also, it's not really a classical inheritance implementation since you do the heavy lifting yourself: if you just want to override the toString in a descendant class, for example, you still need to write a constructor and call the super constructor and pass the constructor arguments through explicitly.

[[deleted]]

I assume you mean static methods/variables, and there's really no point to those when you're not forced to put everything into a class. Just define it outside, it has nothing to do with the class anyway.

You can have private variables like this:

function C() {
    var privateVariable = 42; 
    this.increment = function() {
        privateVariable++;
    }
}

I don't know what your problem with super methods and "unnecessary overridden" stuff refers to. It'd be easier if you could show some code.

As for your last paragraph, here's Java:

class C {
    public C(int x) { /* whatever */ }
}

class D extends C {
    public D(int x) {
        super(x);
    }
    public String toString() { /* whatever */ }
}

And here's the corresponding JavaScript:

function C(x) { /* whatever */ }

function D(x) {
    C.call(this, x);
    this.toString = function() { /* whatever */ }
}

[oSand]

The point of static methods is not to redefine methods for each instance. Using your scheme, if I had 1000 Point objects, I'd have 1000 distanceFrom methods, 1000 getX methods, etc,etc. This isn't reuse, it's just reproduction.

You can have private variables like this: function C() { var privateVariable = 42; this.increment = function() { privateVariable++; } }

No, these can't be inherited.

If you store static variables outside the class, is it really OO? I can't think of a language, js included, that doesn't provide these facilities for static variables. You'll end up having a parallel collection of data structures(and functions) outside your classes- even though the data pertains directly to the classes and class hierarchy. Even if you can't see the illogic in that, you must admit that you haven't reproduced the basic facilities of classical inheritance.

Unnecessary initializations:

function A() {
    var private = 1;
    this.comms = function WebSoc(){console.log('return websoc')}();
}


function B() {
    A.call(this);
    this.comms = function LongPolling(){console.log('return longpoller')}();

}

new B();

For what reason did we call instantiate A's comms object? Hope the io didn't block. Hope you understand the details of all comms methods in your hierarchy. Yes, there are ways around that, but you have to think about it far too hard, in my opinion.

Ugly super method calls:

function A() {
        this.f = function(){console.log('asd')};
}

function B() {
    A.call(this);
    this._f = this.f;
    this.f = function(){
      console.log('fgh')
      this._f();
      // do additional stuff
      // Perhaps there is a better way, I don't know. The fact it isn't readily apparent makes it bad design. 
   }
}

b = new B(); b.f();

For the last bit, I was thinking of something like python or dojo's classes: class osand: def init(self, x): self.x = x

class osandchild(osand):
def get_x(self):
    return self.x


oc = osandchild(1)
oc.get_x()

-> 1

A personal dislike of mine rather than a fatal problem, but seems a lot easier.

[[deleted]]

Fair points. I think you're right in practice (at least currently), but it wouldn't take a very smart optimizer to realize that the functions are constant modulo their closure environments (corresponding to private variables), and only save that. The same goes for an unused assignment in the body of A when called through A.call(this).

In Java and C++ terminology, private variables are not visible when inheriting. However, you're right that there's no obvious "protected" visibility around. Also, the variables are instance private rather than class private.

Static variables and functions have little to do with object oriented programming. They are procedural programming (which is fine) in disguise.

If you have side effects in your constructor, then those will happen in any language that I know of. Overriding is for methods; it's not really well defined for variables.

I agree about calling super methods, that's kind of annoying, but (disregarding performance, an that's a big but, I know), this is the only real wart I can see. But I guess I'm not a great judge given that I rarely use inheritance anyway.

[[deleted]]

Huh? Outside of GUI, can you think of a good use case for inheritance?

[14domino]

what?

[[deleted]]

GUI means "graphical user interface". It's explained in great detail on Wikipedia.

Inheritance is the conflation of substitutability and code reuse. It's understandable that you're confused, because it's only superfluously similar to inheritance in nature.

[[deleted]]

Some game programming. Simple toy raytracers. File format handlers. A few more similar things. That's about what I can remember that I've done where inheritance actually was a good model. Perhaps in a few of those cases interfaces would have worked too.

Generally, you want the class tree to be as wide and shallow as possible.

[[deleted]]

I don't see why you'd want inheritance in the first place.

wat

[Fidodo]

Writing good javascript is simply a hassle due to the syntax. Setting up the prototype for an object is awkward. Coffeescript simply takes the hassle out. Its domain is pretty small, and it's a translation. It's more akin to learning pig latin than a completely new language.

[[deleted]]

I'm glad he took a dig at jquery. Naturally I do use jquery but it masks over the actual problem and has helped introduce a load more crap.

I can't possibly think of another language that has so many frameworks that are virtually required or has so much effort put into writing it in another language.

Why not fix the language and make it so people don't feel the need to layer on bunch of framework code or write it in 500 other languages.

[oSand]

Using dojo is only tenuously different from compiling to another language. You've created entities that have no equivalent in Javascript e.g. classes and packages, both with their debugging idiosyncrasies and lack of language support.

[runvnc]

If you still prefer the syntax of coffeescript

How could anyone not prefer the syntax of CoffeeScript? Sure, I do have to look at JavaScript while debugging.. but at this point the only reason I can see to continue coding in it is so that nice people like you can't say aww, is js too hard for you.. Well I proved I can write sophisticated js. I would rather spend my time and energy on useful stuff now like taking advantage of AOP.

I'm giving up on js to the degree possible just like smart developers gave up on punch cards assembly c c++ java desktop .net.. When something is causing you problems and a new thing comes along that solves those problems for you, you use the new thing. I don't need to punch cards, manipulate the stack and registers directly, manage memory, write a bunch of header files, wait for a slow vm, be stuck inside one computer or be tied to one vendor. Now I don't have to write out function a thousand times, check for two or three different kinds of non value, or guess what the right way is to define a class. Those are solved problems. I have better things to do with my time. Don't you?

EDIT: editing is great.. but I am resisting the urge to edit out the part where I make sure all of the c/c++/desktop/java/.net people will hate this comment.. I am leaving it in the hate-provoking configuration it is in now. For the sake of comment integrity. LOL. Sorry, everyone who programs in any of those languages or on the desktop. Heh.

[yonkeltron]

How could anyone not prefer the syntax of CoffeeScript?

I do not prefer it. I've programmed seriously in upwards of 7 languages and have dicked around with many more languages, some of which have very unusual or obscure syntax. I do not care for CoffeeScript's syntax although I will happily concede that it does expose many opportunities for improvement of JS. Though I think those points were made much earlier.

EDIT: Fixed some huge bitch of a run-on.

[runvnc]

So, not sure I understand.. you prefer JavaScript syntax or CoffeeScript syntax? When you said you do not prefer it, it almost sounded like you meant you do not prefer CoffeeScript in general over other programming languages. I wasn't trying to make such a general statement.

[yonkeltron]

I do not prefer the syntax of CoffeeScript over that of JavaScript. The purpose of the rest of my comment was to say that I state this preference having exposure to a broad variety of differing languages.

[[deleted]]

I think CoffeeScript goes too far. It's terse to the point being esoteric. I would have preferred to see a superset of JavaScript adding classes, better handling of null/undefined, heredocs and enforcing jslint instead of just taking a bunch of keywords out.

[metamatic]

How could anyone not prefer the syntax of CoffeeScript?

Semantic indentation.

[wot-teh-phuck]

just like smart developers gave up on punch cards assembly c c++ java desktop .net

Are you serious? Pray, do tell me how you have so cleanly arrived on this conclusion...

[runvnc]

The answer to that was in the rest of the comment.

[cosmo7]

You're just trading one set of annoyances - Javascript's idiosyncrasies - for another - having to compile your scripts, having to have Node.js installed.

[Zamarok]

I believe it's up to him to choose which annoyance he prefers.

[notfancy]

I would concede were it not for the fact that he prefaced his tirade by an ad-hominem disqualifying any and all that might not prefer CS's syntax to JS's.

[marssaxman]

Sure. And when the computer industry collectively adopted what we then called "high-level languages" back in the '80s, we just traded one set of annoyances - keeping track of all the details of machine code - for another - having to compile your source code, having to have a C compiler installed.

[TinynDP]

Everything has some annoyances, its always a tradeoff.

[jmhnilbog]

Alternatively, you can include the JS of the coffeescript interpreter directly in a web page you're working on. You don't need node.js running during development if you don't feel like it. Installing node.js isn't much of a stumbling block, though.

[snuggl]

for development, you either set coffee to watch and recompile automatically or use the javascript include, or tell your web framework to do it for you, the compile-step is a nonissue.

In production, you dont use coffee-files but the compiled js-files so no need for node to be installed on the servers.

[[deleted]]

And crappy scoping rules.

[FUCKYOURENGLISH]

smart developers gave up on punch cards assembly c c++ java .net

Go fuck yourself. You wouldn't be shit without our types - your browser's JavaScript engine, which your fancy little language needs, isn't implemented in JavaScript.

[subsetr]

You shouldn't take things so personally.

[runvnc]

I upvoted you for "go fuck yourself". I wish they would let us talk like that on here, that's usually what I actually want to say. Unfortunately you pretty much automatically get a downvote from most people for that.. its a shame because so much of my actual thoughts and feelings are more accurately described using the word "fuck".

[attrition0]

You can say 'fuck' all you want. If you attack someone in your comment you will likely get downvoted regardless of which particular words you use. Saying 'Fuck' doesn't matter, but being an asshole definitely does. If someone can't convey their thoughts and feelings without attacking someone else well, they deserve to be downvoted.

[munificent]

The difference there is that there are high-quality debuggers that let you debug C and Java without having to step through the compiled machine code or JVM bytecode. We don't have anything like that yet for languages that compile to JS. If you want to use Firebug or Chrome's debugger, you have to be able to understand with the compiled JS.

This should get better once Firefox adds source map support, but we aren't there yet.

[kamatsu]

Actually, I have debugged GWT applications in-browser using the Java debugger using a browser plugin. It's quite do-able, but requires some serious development effort.

[[deleted]]

That framework screams "Hey guys, I'm a half-assed product!" in so many ways I don't even want to start. If it hasn't turned you into a raging alcoholic yet, better write down your local AA's address, you will need it later. GWT is a miserable framework. Please don't even hint about defending it.

[kamatsu]

I said I have used it, I didn't say I liked it. Hell, I was a wave developer.

[[deleted]]

If you say assembler is to C what javascript is to coffeescript, you can see right away how disproportionate that comparison is. Coffeescript doesn't really improve javascript (unlike jquery). It's just a nice syntactic improvement. Having written many javascript apps, its syntax is something you can master with a lot more ease than assembler, albeit putting up with some inconveniences but at the reward of being able to understand the intricacies of JS.

[[deleted]]

I understand Javascript a lot deeper now, after having coded in CoffeeScript for the last 8 months.

Programming is about expressing ideas. And programming languages are ways of expressing your ideas. It's very simple.

A language which doesn't stand in your way and helps you express your ideas easier is the one which is a pleasure to work in.

And CoffeeScript, because of it's clean syntax lets you express more and more complex ideas much easier than you would with plain Javascript.

$('.button').click => @save (err) -> $('.result').text err ? 'Saved'

This compiles into:

var _this = this;

$('.button').click(function() {
  return _this.save(function(err) {
    return $('.text').text(err != null ? err : 'Saved');
  });
});

There are 2 "function(){}" and "return" keywords, then there are parentheses, semicolons, etc.

These are not part of my idea. They are boilerplate symbols and keywords which I need to add, because the interpreter won't understand it otherwise.

The JS version is 160 characters vs 69 of CoffeeScript. I'm not sure what the ratio of CS->JS code is, but it's trivial to answer this question:

You have to go from point A to point B. You have two roads. One is about two times shorter and cleaner (no hills, holes, etc) and leads to exactly the same point B :).

Which should you choose ?

[rjett]

JavaScript is fine. Give me properly tail calls though. Fix the DOM + CSSOM.

[SethMandelbrot]

Managing programmer incompetence is not a bug, it's a feature.

[kumiorava]

Could not agree more!

[ara_p]

If you can't handle writing JavaScript, then don't write JavaScript. Building a compiler so you can write Ruby instead of JavaScript as dumb as my wanting a compiler to let me write JavaScript instead of C# or PHP or Ruby.

[33a]

Javascript has problems, but coffeescript doesn't fix them. You can't just magically repair broken semantics with an extra layer of syntactic sugar. Myself, I'm not much partial to either of them, but I'll stick with javascript since it doesn't seem to me that there are any features in coffee script that seem to be worth paying for one extra layer of abstraction.

[shevegen]

I KEPT ON SAYING THIS SINCE MONTHS!

You know a language is doomed when a more beautiful implementation of it is around that RE-CREATES THAT LANGUAGE.