Jeremy Ashkenas's proposal for minimalist JS classes | Hacker News Reader

Jeremy Ashkenas's proposal for minimalist JS classes

gist.github.com

70 pointsakavlie16 comments

Much more concise. I was curious on Jeremy's view on getters, setters in JS - can be summed up as it is "impossible to reason about the side-effects of your code" (aside from the fact that it also does not work on IE).

http://irclogger.com/.coffeescript/2011-01-05#1294280074

How is that different than the validation / error handling in the model set method in Backbone.js (in that they can run arbitrary code)? Is it just the distinction of side-effects in the language vs the framework?

Also, why should a = obj.b need to be any more predicable than a = obj.b()?

It seems like there are benefits to using getters / setters (ie, http://ejohn.org/blog/javascript-getters-and-setters/), and I actually think the syntax is cleaner "get firstName" vs "getFirstName". Curious to understand more about the objection.

It's simply interesting that this:

  for (key in hash)
      hash[key] = null;

May or may not call a bunch of functions. It could turn out to be a debugging nightmare.

There are many popular languages for which this is the case (C#, Ruby, PHP even), and I haven't heard anyone panic yet.

The deal is that if you implement a property getter, you promise no side effects and fast execution (for some value of "fast"). If you don't do this, your code is broken.

It always did in JavaScript from day one, given host objects.

You can jump into the thread (or read back up the list for context) on ES-Discuss, if you're in the mood: https://mail.mozilla.org/pipermail/es-discuss/2011-October/t...

Out of interest do you see a noticable increase in the will to actually improve JavaScript?

Are Github's comment contrast or color adjustable? They are almost completely unreadable for me.

Nope, but perhaps the "raw" view will help: https://raw.github.com/gist/1329619/6739dd2eb9f1cf91ecca27aa...

Yes, this is what I ended up doing and reading it in my editor.

I agree completely. I hope this article has legs.

I don't understand why we are still using JavaScript at all now that we have CoffeeScript.

Seriously, can someone please explain this to me?

A lot of CoffeeScript ideas are going into the next version of the JavaScript standard. Having "JS++" languages like CS around is a good way to inform the standards process, but the browsers should all be supporting some common standard, and that happens to be JavaScript.

CoffeeScript is compiled into JavaScript both on the server and on the client.

Yeah, I know he didn't try to sell CoffeeScript on the client, but that isn't because its not better to use CoffeeScript on the client, its just because its not worth trying to sell to people if you are trying to get them into CoffeeScript. Sure it might be a bit harder to debug on the client, but not as hard as looking at a pile of JS.

I can think of a few reasons:

* Some of us are actually comfortable with and enjoy programming in JavaScript. :)

* Are we absolutely sure as of now that adding the CoffeeScript abstraction will not introduce performance regressions and/or subtle bugs?

* Are the niceties and syntactic sugar of CS really worth the time I'll have to invest in mastering it? Or is this just another programming fad that everyone finds "cool" this month?

If you mean "why isn't everyone coding in CoffeeScript and compiling to Javascript," the answer is that not everyone sees the benefit in learning a new syntax to write code they already know how to write in Javascript. "Prettier code" isn't compelling for everyone, and adding a layer of abstraction can generate its own problems.

You still have to debug your Coffeescript in Javascript, so you still have to understand Javascript. Unlike, say, HAML, where you can't possibly do anything in HAML that you wouldn't know how to do in HTML, Coffeescript lets you avoid learning about JS prototypes by using Coffeescript classes and letting it translate for you. You'd better hope the abstraction doesn't leak.

I'm not against Coffeescript - I'm excited to start using it soon. I'm just saying that I understand why not everyone is.

If you mean "why do we still have to compile to Javascript," well, we'll have to do that at LEAST until every browser supports Coffeescript natively (currently none do, so you're looking at maybe 2025 when IE9 falls out of use), and probably beyond that (since there's little chance that MS will break backwards compatability with JS).

Another reason might be toolchain. If you're coding in a Rails 3.1 application, Rails takes care of compiling your Coffeescript and SASS and such for you. If you're using a toolchain that doesn't do that for you, you have to set up watch scripts and decide where source and compilation go, etc etc. That headache has to be weighed against the perceived benefits.

Reply on news.ycombinator.com