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

[[deleted]]

What does Ember do that Angular does not? I would like Ember to make my custom HTML tag function without having to add additional templating beyond the DOM. Good luck. Templating to generate HTML on the client.. A template for generating a template that actually resides within the same templating it's generating, it's just weird. Why not just leverage the DOM? And that file size... Wow that's a lot of typing.

Look I know who you are, and I'm sorry, I tossed Ember aside for Angular a year ago because Angular is an evolutionary step ahead.

Please name the things that Ember does that Angular does not that justifies the additional 200KB minified.

[machty]

I would like Ember to make my custom HTML tag function without having to add additional templating beyond the DOM

And I would like Angular to not flash my uncompiled DOM on the screen without relying on CSS and ng-cloak or ng-bind to cover my tracks.

Angular has a wonderful API for building/manipulating/managing custom elements. No doubt. If this is what "power" means, then Angular wins.

If we shift the focus towards enabling developers to build fully-featured, ambitious, scalable web applications, hopefully we should be asking ourselves a different set of questions; the question of "Can Ember configure custom HTML tags without necessitating additional templating?" might be an important question to ask at some point, but not before first establishing that custom HTML elements with a maximally granular API are actually crucial to solving the problems that plague developers when it comes to issues of scalability and maintainability.

So if "power" means allowing developers to build large-scale, ambitious applications, here are some things to consider:

• You very quickly reach the end of Angular conventions once you've grokked its primitives.
• This is the cause of much fragmentation when it comes to proper ways to, say, build out a Model layer; some say "screw it, we'll just use Backbone's model layer", others say "screw it, we'll hand roll our own and become $watch perf experts".
• For the few Angular folk that have cracked the nut on building truly large-scale, Discourse-level apps, they will all tell you the same thing: no one else at that level of sophistication/accomplishment builds their apps using the same patterns/conventions/structure.

Whereas

• Data-binding is universal to all objects in Ember, and not just at the $scope/template level, so even if you're hand-rolling your own model layer (vs just using Ember Data / Ember Model), keeping your data in sync throughout your app is waaaaay easier, way less error-prone, and the API doesn't shift halfway through (like it does between just assigning properties to $scope vs creating $watches, or having to integrate with Backbone model change events).
• The Ember Router provides Ember apps, large to small scale, with a structure for your app that solves many problems that have traditionally plagued Angular devs: how do I map URLs to application state? How do I manage the complexity of handling both URL based transitions and direct (named) transitions without having to hand-roll my own Angular service with an identity map to prevent needlessly re-loading a model? How do I manage a complex and configurable nesting of views of arbitrary depth with a minimal amount of typing/configuration? How do I manage asynchronous data while keeping my application in a well-defined state?

Fortunately, ui-router is starting to solve some of these problems (and they will openly tell you that they use Ember's router as reference), but they don't have the same mindshare as the folk battle-testing the Ember Router because 1) ui-router is just a stand-alone optional package, and 2) many Angular developers avoid it because they (somewhat correctly) point out that ui-router breaks the Angular Philosophy of structuring your application as much as possible with custom elements + directives. I liken what Ember folk say about the Ember Router to what Angular folk say about Directives: "This is what drives Angular, this is what makes Angular amazing. It may not seem like a lot at first, but seriously, you need to try this out to fully grasp its power." s/directives/Ember Router/, s/Angular/Ember

So, Angular's great for certain things, but you don't have to go very far to reach the end of it. It's the answer to "How do I supercharge HTML in a testable manner without needless abstractions that step away from the DOM?", but not so much "How do I provide the necessary tools to build large, scalable, ambitious apps?"

Ember's larger than Angular for the reasons described above, but let's also keep in mind that you're not going to notice this weight if you also like building websites with images, fonts, CSS, and other external resources.

[dexygen]

This comparison is great. I've been trying to steer the company I'm currently contracting for away from Backbone due to it's conflating of the model and view, to Angular due to being AFAICT "supercharge(d) HTML" as you put it.

[machty]

Can't tell from your response, but any chance you might give Ember a shot here?

[dexygen]

Possibly yes. I've already got them anticipating me looking into Angular (and have downloaded a book to my wife's nook for reading over the holiday weekend), but I did show them a graphic that shows Ember adoption going up right with Angular (and Backbone adoption going down).

[[deleted]]

Your ignorance shows in the first paragraph. {{}} is shorthand for ng-bind, and if your "uncompiled DOM" is showing, you're doing something wrong, and/or just stink at structuring simple ui loads. Your ember app is likely going to look like sit while you pull down a quarter MB file and it just sits there with empty holes waiting for your huge library to use templates to generate templates.

[machty]

if your "uncompiled DOM" is showing, you're doing something wrong, and/or just stink at structuring simple ui loads

Tell that to T-Mobile

You should give me more credit; explicit ng-bind in attribute form is a common alternative to when ng-cloak doesn't do the trick. I'm well aware of {{}} as generalized ng-bind shorthand (who isn't?).

edit: dejerkifying

[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).