This is the only intelligent comparison I have seen of Ember & Angular (or actually of Angular with any other modern framework). Thanks!<p>I am wondering if the uniform access principle is mostly a dynamic language issue: you end up screwing up whether you need a parentheses invocation and you don't know until runtime. If you type everything with TypeScript then you know at compile time if you messed it up. Relatedly, Ember's get/set is more difficult to make strongly typed. In the TypeScript definitions I am looking at, property access is only typed as a string. One could define an enum for each object to be used in place of the string, but overall there is a price to pay with set/get since it isn't baked into the language (like Ruby).
Having just dug into Angular while wondering if I really wanted to be working with Ember, this was a great comparison. It's obvious to me now I have to look at both frameworks. While done by an Ember.js creator I found the presentation also provided me with a much deeper knowledge of Angular at the same time - well done.<p>As for the Google popularity, one could snidely remark that Angular's documentation and taxonomy requires significant amounts of searching to solve the problems you are after. While the community is active, it's quite difficult to find examples of the right solution or effective documentation for newbies at times.
I hate that Google Docs modifies your history when you go to the next slide. This presentation clocks in at 57 slides and Firefox history defaults to truncating after 50 entries, meaning I can only go back to slide 7 and not back to HN.<p>Is it really better that I can use my browser forward and back buttons to navigate slides? Especially when there are forward/back buttons on the presentation anyway?
I <i>really</i> liked this. Although I prefer to work with Ember.js, Emblem and EmberScript (as the latter addresses some of Ember's syntactical faults), Angular seems very interesting when you view it as more of a toolset for building your own framework than a "complete" framework in and of itself.<p>When you bring the <i>entire</i> Ember toolchain into the mix, outside of the already-complete framework, it begins to smooth Ember's rough edges in development. It's just the same with Rails, I'm a Ruby developer and we're used to dealing with dependencies already, so it's not really a huge leap outside the box for us to be using tools that will compile down to HTML/CSS/JavaScript to build the frontend to a Rails backend API application.<p>I still understand Angular as a toolchain/framework/whatever for people who do not understand JS to the point where they want to begin extending it. Angular is a "safe zone", something that frankly JavaScript as a language (without Ember's additions to the object model and such) needs right now. When you write apps in Ember, I feel like a deeper understanding of how JS is working is necessary before you begin to abstract that portion away. Is this still a correct assumption to have? I'm not trying to insult anyone, frankly JS is a pretty screwed up language so I feel like it's a natural tendency to want to just get what you need out of it quickly and safely and then move on to more fun projects. In my opinion, it's simply a different way of doing things, not better and not worse.
One thing that I like about Knockout is that you can easily drop it into a legacy site, allowing you to have some pages that use it and others that don't. Forgive my naivete, but is this something that is easy to do with Ember or Angular as well?
Kudos to the author - I am impressed how well Alex Matchneer understands Angular.<p>Few thoughts of my own:
- Ember is a long term relationship with one particular way of doing web FE, a way invented by someone else for you. Ember philosophy is "one size fits all".
- On directives and transclusion - it's like Lisp's dotted pair.
these new concepts may be hard to understand, but experiments like that often fascinate programmers, and for a good reason - one day those experiments will revolutionize the way we build software.<p>The debate of a small set of flexible tools vs one tightly integrated system is not new. We had Linux vs Windows, Django vs Flask, etc. It's funny to see it pop up in yet another area.<p>Thank you for this great write up and raising a bar of this long going discusiion on Ember vs Angular.
I've been working with Ember for a while now, and I love it. Convention over configuration is a big deal, and the Ember team has done it right. I think if you like Rails then you'll like Ember.
I use angular a ton, and just learned more about Ember from this. thanks. I'll have to check it out someday. Ember looks like it has good testing now too :-)
That was a really informative comparison, kudos to the Ember author for injecting minimal bias.<p>I've been on the fence about switching from jQuery + Coffeescript to Angular/Ember/etc.<p>Still am, bit of a server-side luddite here, AJAX, client-side form validation, some jQuery effects for dropdown menus, show/hide layers, etc. is as far as I go.
Do we really need either Angular's or htmlbars' (see slide 37) way of "decorating DOM elements with behavior" when it is so trivial with just ES5 and HTML? See this jsfiddle: <a href="http://jsfiddle.net/dexygen/nU8VK/" rel="nofollow">http://jsfiddle.net/dexygen/nU8VK/</a> Give me a couple/three strong JS devs and I guarantee you I could take these simple building blocks (as well as spans with data- attributes, and innerHTML, instead of templates), and I could build out a framework way faster than either Angular or Ember.js and would validate as HTML5 to boot. Doubt me? I pretty much did the same thing for PHP; see <a href="http://dexygen.com/ria/#!/docs/jackrabbitmvc" rel="nofollow">http://dexygen.com/ria/#!/docs/jackrabbitmvc</a>
So technically what the presentation is trying to say is that you should use Angular to build Ember like framework. hahah<p>I personally like Angular, the Google support and the community are strong points to it. The documentation used to be hard to find, but now, specially with StackOverflow, finding what you need is easy.