What's wrong with JavaScript

">thing: -> > @_thing ?= new Thing

..is … irritating."

So... having one sigil to distinguish a class variable isn't irritating, but another for a variable accessed by an accessor method is. Got it.

> It’s tempting to presume that this is a ‘feature’ of prototypal inheritance

Why would this be tempting? As the author points out, there are prototype-based languages that avoid it, and you could remove prototypes from JavaScript and still encounter the issue.

> we’re not writing Java. We’re in a highly dynamic language. We want nice things. Or, we could create setters and getters using the new ES5 syntax – but that’s not available everywhere (pre-IE9, for instance), and, I would argue, is too unwieldy to apply as a rule.

You want an easy way to create accessors? OK:

  function prop(name,gNs) {
    function undef(v) { return typeof v == 'undefined'; }
  		
    var _name = '_' + name, get = gNs && gNs.get, set = gNs && gNs.set;
  
    if(get && set) return function (x) { 
      return undef(x) ?  get.call(this,this[_name]) : (this[_name] = set.call(this,x), this); 
    }

    if(get && !set) return function (x) { 
      return undef(x) ?  get.call(this,this[_name]) : (this[_name] = x, this); 
    }

    if(!get && set) return function (x) { 
      return undef(x) ?  this[_name] : (this[_name] = set.call(this,x), this); 
    }

    return function (x) { 
      return undef(x) ?  this[_name] : (this[_name] = x, this); 
    }
  }

You're welcome. Use it like so:

  obj = {
     thing: prop('thing')
  }

when you want your accessors to do something other than getting/setting:

  obj = {
     thing: prop('thing', {
        get: function () { return foobarled(this._thing); },
        set: function (x) { this._thing = unfoobarled(x); }
     })
  }

> What we’re really saying is ‘everything is a hashtable’. Is that a good thing?

I'm more sympathetic to this criticism. There's times when the fact that everything can have arbitrary properties is convenient, but it does place some burden on the developer to pay attention.

Then again, I think that's a general charge to which any highly dynamic language is going to have to answer on some point or another. And if you're prone to typing `[]` when you mean `{}` (understandable if you've come from a language where they have different meanings), it's possible you should do the more conspicuous thing and use `new Array` and `new Object` instead.

> Nothing is an object

No. What the author is really talking about that by default, there aren't "methods" with class-bound scope. Just functions whose `this` scope is dynamic but does live by some pretty understandable rules.

> _missing

Missing method's sometimes convenient, and there are occasions when I miss it in JS too, but it's much rarer than I once would have thought. Use cases in languages where functions are less often let out on their own tend to get taken care of differently in languages where they do.

> I’ve yet to hear anyone convincingly argue that JavaScript’s version of OOP offers anything in addition to or distinction from more traditional versions;

"convincingly"

Convincing who?

Oops, I think the author meant to have copy[key] = val for the last line of this example:

  copyObject: (inputObject) ->
    copy = []
    for key, val of inputObject
      copy.key = val

As written, it uselessly sets a bunch of values to the key property in turn.

The point stands though.

Ah, that explains a lot. It certainly explains why the complaints didn't resonate with me. I know JavaScript very well, and there are things I don't like about it, but these weren't them. Or if they were, I've gotten used to them.

I think I did miss the point with my previous comment. Maybe I was confused by the title: The article isn't "What's wrong with JavaScript", but as you said it's much more about things that will confuse Rubyists who arrive at JavaScript by way of CoffeeScript.

For an article on that topic, it does make sense to have CoffeeScript examples. But it would be much better - and so easy - to include the matching JavaScript for each of the CoffeeScript files. Not only would it help JavaScript programmers understand the article, but it would show how CoffeeScript attempts to work around these issues.

Even better would be to add matching examples of similar Ruby code. Code examples in all three languages would make for an interesting article: the Ruby way, the CoffeeScript way that makes JavaScript a bit more like Ruby, and the JavaScript way.

Well, warts aside I came to like Javascript.

And by keeping to Javascript, only better and fixed, it would be easier to reuse and adapt huge parts of the browser ecosystem and toolchain.

Ruby maybe. Lua lacks proper unicode support. Python, I've used since 1998, but can't stand the lack of proper closures (and/or how the syntax makes them awkward) for web work.

And there's two more issues with all of them:

1) they are dog slow compared to modern JS JITs like V8 (and alternative implementations like PyPy are not as mature).

2) on the browsers, due to the sandbox and other issues, you can't use most of their libraries, that use native extensions and such, so you just get their syntax, not their batteries.

>So... having one sigil to distinguish a class variable isn't irritating, but another for a variable accessed by an accessor method is. Got it.

I'm not sure you did (get it).

One is part of the language's syntax. The other is an ad-hoc convention you have to remember and check for.

>You're welcome. Use it like so: obj = { thing: prop('thing') } when you want your accessors

My eyes. The goggles, they do nothing!

>(I’ve yet to hear anyone convincingly argue that JavaScript’s version of OOP offers anything in addition to or distinction from more traditional versions; "convincingly" Convincing who?*

The author. Isn't it obvious? Also me. So make us two.

And presumably ALL the other people that write frameworks and workarounds to get traditional OOP style in Javascript.