I've used Angular, React, and Handlebars (Ember's templating engine), and I can tell you, they are all the same in "tangling." They all solve this problem by emphasizing that the view portion of the code (Angular's pseudo-HTML, React's JSX, and Handlebar's limited helpers) should be used strictly for view-related logic, not domain/business logic. So there really isn't any difference between the libraries in that respect, except for personal taste.
Angular is fast and easy for development. Very ittle boiler-plate and comes with easy UI bindings. I feel it's perfect for smaller projects where separation of logic isn't as important. Angular has the ability to grow in complexity if you need it too.
Backbone comes with a lot of boilerplate, but honestly is worth it if you have a larger front end app. Being able to have your data trickle though your models and views in a concise structured way can make changes as well as fixes much easier in the long run. Backbone's persistence functionality is pretty phenomenal as well.
Ember relies pretty heavily on Handlebars. If you're game to use that for your client side rendering than it could be a good option. Ember looks similar to Backbone but makes a few things easier such as computed properties and bidirectional bindings. I haven't touched it much yet as I'm currently working in Backbone and Ember's current lack of an "official" persistence mechanism turned me off a bit.
All three of these are great frameworks. Angular is easier to pick up but Backbone has more users and more users means someone has probably ran into a problem that you possibly will and has already asked a question on StackOverflow. That alone can be invaluable.
I have worked a bit with angular lately, and am now knee deep into my first ember project (with ember-cli).
I agree with a lot of the points made in this Series, a really good write up.
In Ember I feel I have to write a bit more boilerplate around dealing with collections, (i.e. sorting).
Can't wait for HTMLBars, the script tags littered around the dom are just not very nice, and I find myself using :last-of-type CSS selectors and the likes a lot.
I also think that the directives in angular just work nicer than the components in ember, because there is more control over what's bound into their scope.
Ember's approach to structure is great though, and the router is really nice to work with, much much nicer than ui-router.
Both are great frameworks though, and I really appreciate the work of both teams to give me great tools like this to work with.
Why do you prefer Ember? For me the killer feature of angular is ability to build custom element (directives). Backbone + React is a good competition, but what about Ember?
I spent most of the last 4 months doing all my front end work in Angular. The biggest problem I for me is that A) there are a lot of nooks an crannys and B) the views end up being pretty ugly.
I've been doing more with Ember recently, and while some things are not as easy, some other important things are much easier. On top of that the views are easy to read. So at least for now I feel like Ember is better for me.
The article is very much inclined towards angular. I find Ember much easier to develop with due to the neat separation of application logic and HTML. In Ember, most of the logic is in the javascript, templates merely serving the final result in a presentable way. In Angular I dislike to see the angular specific programming logic molded into HTML. In my opinion HTML is just a presentation layer. An example from angular:
<li ng-repeat="phone in phones | filter:query | orderBy:orderProp"> for me this is too much programming logic in html. Same goes for React.js too. Too much html + logic mixup, that requires two parsers to work in your head in parallel (html + javascript, and maybe even some css?). I find it messy.
None of it in ember. Logic is neatly separated. In ember I also really enjoy how you separate functionality on a single page into neatly defined controllers/routes/ and components.
Also the article says you add lots of <script> tags to your code. Not true. Using ember-cli you don't see any <script> tags.
What's weird is that I constantly hear the opposite. Angular's free flowing structure allows for spaghetti code in scale, while Ember might be overkill for smaller projects.
Thanks for the info. I've used Knockout but not Angular yet. I've found Knockout to be excellent in not getting in my way and being easily fitted into my existing code. One thing I don't feel comfortable with Ember & Backbone is that they come as a whole framework and require me retrofitting my app to their framework.
Angular beats Backbone like a prison rape scene. I wrote the peepcode backbone todo app in 1/3 the code using angular (over here: https://github.com/ludicast/angular-peepcode-todo, n.b. I haven't had time to update to newest Angular)
Haven't used ember, but I do mancrush ykatz, so sure he is taking it to good places.
I have nothing but praise for both Ember and Angular. Both give you real data binding, and delegation rather than events. Compared to Backbone, both are like being in heaven rather than the 4th level of "event" hell.
There are a lot of differences, but if I had to pick, it would depend on the application. If I was building something with complex front-end requirements where the vocabulary was mostly tabs/panes/switches/filter-dropdowns/etc., then I would go with Angular. If I were building something where the data domain was more important, e.g. the vocabulary is more about authors/titles/posts/tags/etc. then I'd go with Ember.
With Ember, persisting a complex model to a backend is a priority for the framework developers. With Angular, it is left as an exercise for the reader.
With Angular, extending the DOM to create new web components is a central focus, but with Ember, it is totally an after thought. Ember Components are a joke compared to Angular directives...
I was about to link to the Ember component source code showing how pointless they are. (A week ago they were useless) The devs have been furiously fixing Ember Components to have the power of Angular JS directives. I am so happy to see the good parts of Anular making their way into Ember. For those that hate Angular terminology, it appears 'isolate' has made its way to Ember. I hope 'transclusion' does as well. Need more than one way to {{yield}}
I've written 2-3 large applications in Angular, I've contributed ~1200 lines to Angular 1.3, and racked up a lot of points on StackOverflow answering questions around Angular.
However, I'm currently working on a pretty crazy real-time app for Netflix that's all in Ember, and I wouldn't have it any other way. I have the pleasure of working with @ebryn there, and it's been an awesome experience.
In this poll, there are really just those two frameworks. The others frankly aren't in the same league right now.
I've yet to read what I thought was an unbiased, honest comparison of the two. Generally, anyone that does a comparison has one favorite, and the other they barely know. I'm hoping to remedy that at some point, but I still feel my Angular experience out-weighs my Ember experience. At least for now.
However, preliminarily, I can say that both frameworks are absolutely brilliant attempts to solve similar problems in completely different ways. I think they both have a LOT they could learn from one another. I prefer a convention-based approach, which is one thing I love about Ember... That said, I prefer Angular's constructor-based DI over the setter-based DI of Ember... That said, both of them have somewhat primitive IOC containers that could be better (which is a whole blog post by itself)... THAT said, Angular allows developers to put too much logic in their templates via expressions (harder to test)... THAT said, Ember's structure and composition isn't quite as easy to pick up if you're new to the framework... THAT said, Angular doesn't require any other libraries and is very compact... THAT said Angular's directives allow for wild-west spaghetti code and give developers enough rope to hang themselves... blah blah blah
... the point is, I could go on forever. Both libraries have REAL advantages over one another, but libraries have REAL disadvantages over one another as well.
# Embular.js in 2016!! Change the world!
What I'm hoping for is that the incredibly brilliant minds behind these two efforts see the light and join forces. Even work with the folks designing ES6/7 and the future of HTML/DOM...
What I'm hoping stops is the "my framework is better than your framework because _______." silliness.
Both frameworks have their strength and weaknesses. I think Ember is a heavier and more verbose,but it's easy to integrate third party widgets without having to rewrite them.
While I was coding something to learn AngularJS https://github.com/Mparaiso/markme-silex , I spent most of my time fixing race conditions between the digest cycle and the third party widgets , and sometimes it was reaslly hard to figure out why the model wasnt updating,or why the view was when the model didnt change in appearance. ( I had to integrate masonry,bootstrap modal,tags.input,autocomplete and a few others).
But again,since AngularJS takes care of everything else,that's a tradeoff.Angular solves the architecture problem with dependency injection.
For me, Angular displays the right balance beween complexity and ease of use. After getting past some of barriers (the transclusion docs could be more easily explained, specially with some images), I find it pretty easy to use, and it's great for complex apps. Never used Ember though, after using Spring for so long, dependency injection comes naturally.
Some people mention Backbone, I think it's great if you're very comfortable with JS, otherwise you'll end up replicating bits of other frameworks by hand or using lots of 3rd parties (ex: databinding, validation, complex model interaction, view cleanup).
Anyway, take a few days to get the feel of each and choose according.
The "structured" nature of Handlebars is important if you're using Ember, because it's set up specifically to allow it to parse the interpolations in your templates and determine what attributes you're binding, and so on. But if you're not using Ember, a "colossal pain in the ass" sounds about right.
Do yourself a favor and use true logic-less templates (Mustache, in all of its myriad flavors) if you really believe in that sort of thing. Or make life easy on yourself and use a programming language you already know. Embedded Ruby, embedded JavaScript, embedded PHP (the only kind there is) -- all have the virtue of allowing as much or as little code as you need and want, and allow you to do whatever you need to get the job done.
reply