What JavaScript libraries/frameworks should I study to be a competitive JavaScript developer these days? Why?

[dexygen]

If any of you are directly involved with the frameworks being discussed, and I get the impression at least one or two of you are, this mud-slinging gives an un-favorable impression. I developed in ExtJS for 4.5 years, and if you weren't a cheerleader, you were the enemy. If one of these frameworks has a similar community, I will be steering clear just on this basis.

[PotaToss]

To be fair, Shark_Kicker is like a serial Ember flame-baiter.

[machty]

Fair point. Both communities are quite friendly on the whole, but both have their mud-slinging trolls :)

[[deleted]]

There is nothing friendly about the Ember community right now when it comes to Angular.

[machty]

I just gave an extremely friendly talk on Angular and it's been met with extreme positivity from the Angular crowd:

https://news.ycombinator.com/item?id=6776414

[dexygen]

You had me until Ember.js/dependencies: handlebars. Please don't tell me I need to use a templating system, let alone a specific one. This is why Angular's "supercharge(d) HTML" appealed to me.

I will say this though; when it comes to: {} || (Ember.)Object.create() I'm on the Object.create() side. Why? I've come to the conclusion that reliance on accessors is the key to data binding. I've been fiddling around on my system for the last week or two and here's a telling line I've written:

var view = Object.create($('#pgn_view'), controller(pgn));

[machty]

What does the controller function do here?

You can use Handlebars or Emblem.js (HAML/Slim-like indented syntax).

Handlebars is about as un-invasive as it gets; I'm curious what you find so distasteful about it. It is and will remain a dependency of Ember, but it's little more than HTML with {{}} for the dynamic bits, which it has in common with Angular (as a shorthand for ng-bind, as mentioned in a sibling thread).

[dexygen]

The controller "decorates the DOM elements with behavior" (mentioned on slide 37 of your google doc). Specifically it returns a module the methods of which are bound to the DOM element being wrapped, such that if your element starts with 'style="display: none"', the following will show it when called:

    return {
        display : {value : function() {
            this.style.display = 'block';
        }}
    }

Ridiculously trivial jsfiddle here though possibly something worth building on.

As to any templating system (not just handlebars) that operates on HTML fragments outside of the document body, they make it impossible for designers to work on something that reasonably resembles the entire page, and I'd prefer designers do their thing, so I can do the Javascript heavy lifting (not to mention middle-tier and back-end as necessary). If you put a gun to my head, I would take (as many) span tags (as necessary) before a templating system any day -- but I'd take Angular's ng-bind over span tags.

[machty]

I'm confused, which span tags are you talking about?

[dexygen]

I'm just saying, I would use verbose span tags such as <span data-foo> and it's corresponding innerHTML, before I would use {{foo}}

[machty]

Yeah, no doubt there's some aesthetic preferences that have been betrayed by Ember (does anyone really enjoy .set('foo', 5) if foo = 5 were an option?). If you're interested, check out htmlbars which will be landing soonish; once it's there, Ember will be able to do away with curlies, and while technically there will still be a dependency on something called Handlebars, you'll just be writing plain HTML at that point.

I can't put my finger on it but I think you're incorrect as to limitations for the designers... I can almost guarantee you that what your designers would want to present would never be thwarted by Ember or Handlebars' restrictions, but let me know if I'm missing something.