11 ms·

AngularJS versus Ember

207 points by EvilTrout 13y ago

wc- 13y ago
Coming from someone that has used neither framework, I like the write up w/ examples. However, I wasn't convinced that "it's not even close" so maybe a bad title choice.
- jergason 13y ago
  I agree. The article is a reasonable discussion of the differences between the two frameworks from the perspective of an experienced Ember user, and does a decent job illustrating why Robin prefers Ember. The title is argumentative and inflammatory. I think lots of people will read the title on Twitter and roll their eyes at the Ember attack-marketing machine when the article itself contains some valuable points.
  - raganwald 13y ago
    You are absolutely correct. I realize I'm in the minority, but I take all blog titles with a bushel of rock salt. Probably because I like to have my own little jokes when I write titles, so I try to ignore what they appear to say and use them only to decide whether to read the post, not to decide whether the post is any good.
  - zwily 13y ago
    The title doesn't actually indicate which one wins, so at least those Twitter users would have to read the first couple sentences before clicking away...
- EvilTrout 13y ago
  I went back and forth on the title. I don't usually write sensational titles but for some reason decided to give it a try. I think it's a very good point and I doubt I'll do it again.
  - raganwald 13y ago
    It could be worse. One fellow I know wanted to write about the benefits of significant whitespace, and thought it would be funny to call his essay "White Power." I doubt he'll try that again. ;-)
- gilrain 13y ago
  "Ember vs AngularJS: I Prefer Ember and Feel that I Have Compelling Reasons for That Preference" is a bit longer, though.
- steveklabnik 13y ago
  Would it be on the top of HN if it had a more reasonable title? Is the audience just as complicit as the author in trending towards flamebait?
  - Buttons840 13y ago
    I was interested in the Ember vs Angular comparison regardless of the title. Also, I've enjoyed EvilTrout blogs in the past.
gkop 13y ago
It's not even close for what purpose? For example, there's a wide common case of simple apps hacked together by 1 or 2 developers, traditionally composed of jQuery spaghetti. Maybe Angular is a perfect tool to better organize these typical, not-particularly-ambitious apps, where Ember would be a pre-mature optimization. And perhaps Ember is the perfect tool for sophisticated apps written by teams of developers.
- steveklabnik 13y ago
  > It's not even close for what purpose? As the article says at the end: > Ultimately, I think you should examine your application’s goals. Do you want to build something that pushes the boundaries of what people expect from the web? Is your application going to be super simple, or do you want to add powerful features and maintain it well over time?
  - gkop 13y ago
    Read on > If you’re serious about front end development, I advise you to take the time to learn Ember properly. The article isn't fair to Angular. It's like saying, If you're a professional web designer, you should always use semantic markup and a CSS pre-processor, and never Twitter Bootstrap. In fact, Twitter Bootstrap and Angular both have their places alongside Sass and Ember.
pron 13y ago
...At that point, what was the advantage of Sinatra? You were basically running a Rails application. Framework simplicity is good if your application is meant to be simple. But you should be cautious when choosing simplicity if your application is ambitious and you care about supporting it for a long time. This is what I like about Clojure. It is so composable, that simplicity doesn't come at the expense of features. The language makes composing disparate libraries so easy, that it's quite trivial to mix and match different libraries and have them all work in tandem. You don't only use what you need, but for every aspect of your application you can choose the best tool for your particular needs.
- danneu 13y ago
  Clojure's namespace declaration: (ns my-app.my-namespace (:require [some-library.some-namespace :as foo]) is pretty liberating for me after working with Ruby for so long. Composition is tedious to reason about in Ruby when your only clue is a menagerie of `require`s at the top of the file. Or, more commonly, when your only clue is a Gemfile because all the gems are auto-required and omnipresent.
  - prollyignored 13y ago
    An offtopic clojure question. Today I was seeing this -- https://en.wikipedia.org/wiki/Knuth-Morris-Pratt_algorithm https://en.wikipedia.org/wiki/Knuth-Morris-Pratt_algorithm How can I begin to implement it in clojure ? Specifically, how do I _ingeneral_ deal with assignments and while loops. In common-lisp, for example I would use the `loop` macro and defvar-sefq combo, (beginning lisper). In ruby, = and while itself.
    - danneu 13y ago
      Clojure has most of the semantics you're used to in other languages. http://clojuredocs.org/clojure_core/clojure.core/let http://clojuredocs.org/clojure_core/clojure.core/let (let [username "prollyignored" karma 7] (println username "has" karma "karma points.")) ; prollyignored has 7 karma points. http://clojuredocs.org/clojure_core/1.2.0/clojure.core/loop http://clojuredocs.org/clojure_core/1.2.0/clojure.core/loop (loop [n 0] (when (< n 10) (print n) (recur (inc n)))) ;=> 0123456789 http://clojuredocs.org/clojure_core/clojure.core/for http://clojuredocs.org/clojure_core/clojure.core/for (for [x [0 1 2 3 4 5] :let [y (* x 3)] :when (even? y)] y) ;=> (0 6 12) Or just: (filter even? (map #(* % 3) [0 1 2 3 4 5])) ;=> (0 6 12) Browse the Clojure cheatsheet: http://clojure.org/cheatsheet http://clojure.org/cheatsheet
olalonde 13y ago
A higher level framework makes you more productive but a single bug can get you stuck for hours, days or weeks. A lower level framework doesn't make you as much productive but you have a better mental model of what is going on and bugs get solved quickly. Keep in mind when choosing a framework.
- ldn_tech_exec1 13y ago
  very true
- 3pt14159 13y ago
  THIS! This is exactly what I was trying to figure out how to type. Right now ember is especially hard to learn since it is constantly changing and ember-data isn't done yet. As a result there are 5 different ways of doing something and when you get stuck you finally solve it by finding someone else who had the same problem and that is when you learn that the tutorial was for rc3, not rc5. But the huge problem is that it took you forever to get there. I personally think Ember will win, and it will win hard, for the professional developer market. I think it will come down to Rails : PHP :: Ember : Angular, but in the mean time angular will get a huge head start. Once people get used to those common single bugs that keep them stuck for hours, they will be far more productive for non-trivial applications than angular devs will be.
  - steveklabnik 13y ago
    > constantly changing 1.0.0.rc1 was released on February 15, and (to my knowledge) there has been _one_ backwards-incompatible change since then. > ember-data isn't done yet You don't need to use ember-data: http://eviltrout.com/2013/03/23/ember-without-data.html http://eviltrout.com/2013/03/23/ember-without-data.html
    - 3pt14159 13y ago
      It is painful to try to learn something when different articles all say how to do a hello world differently. It doesn't matter the reasons why, it is just harder. I get it now, but don't make it like it is easy for someone to learn.
yajoe 13y ago
As a gentle reminder, Fred Brooks said "there are no silver bullets" in software (http://en.wikipedia.org/wiki/No_Silver_Bullet http://en.wikipedia.org/wiki/No_Silver_Bullet ). Even without knowing the details of this article, I believe it's unlikely that "not even close" is at all accurate. There likely are advantages, but from my experience (10k+ LOC apps on each Ember, Angular, and Backbone) no one MVC (or MV-) framework is inherently better. They all have serious tradeoffs that SO has done a much better job documenting. One nit from the essay: the author comments on the missing 'model' from Angular and provides an example of a computed property to illustrate this. In many (not all) Angular applications, the server is responsible for the model (think a Parse or other REST-style backend), and the Angular app is simply responsible for rendering it. Angular (err Restangular to be specific) has a way to do this with less code and an aesthetic (data binding in HTML) that I personally like. If, however, you were writing code that needed the client to have a lot more business logic (i.e. computed properties, browser local storage, etc) then something like Ember would be a better choice because of its 'Model.' A lot of shit crud apps, however, don't need that much business logic in the client (at least for an MVP), and that would be my narrative for why Angular appears more popular. That said, I use computed properties in a couple places with Angular, and watches have performed perfectly fine for my use (gallery of 1000s thumbnails). He should disclaim that YMMV. Neither is inherently better, and both teams working on them are full of smart, quality engineers that understand these problems in ways I never will.
- prollyignored 13y ago
  This is something else. I'd like to call it, "the appeal to the bold new future fallacy, with sensationalist titles" <template> Is X trying to change the paradigm ? No. Use Y. Is Y trying to change the paradigm ? Yes. Use Y </template> Some dumb geeks just can't handle "worse is better" !
- EvilTrout 13y ago
  > In many (not all) Angular applications, the server is responsible for the model (think a Parse or other REST-style backend), and the Angular app is simply responsible for rendering it. My question is then: why are people purposely choosing not to use the advantages of client side MVC code? All of a sudden we have access to all these awesome features of long lived applications and people are choosing patterns that don't embrace it. > That said, I use computed properties in a couple places with Angular, and watches have performed perfectly fine for my use I do say in the end that there are viable workarounds. It's an issue of maintainability and consistency. Ember embraces patterns for ambitious applications. If it works for you I'm glad, I just think we should open ourselves up more to the advantages of rich client side apps and not hold back!
camus 13y ago
> but ask yourself this: are all developers on your team going to follow the same conventions? That's the point of using a framework. You need to stick to conventions since frameworks have an opinon on how things should be(Ember does i guess). I never tried Ember ( I will ), but AngularJS comes with a lot of battery included , that's why it is really awesome.
andrzejkrzywda 13y ago
Choosing a heavier framework may put you in risk of 'typical', framework-related bugs that often appear. The bugs are not part of the framework, but they are part of the patterns around it. Discourse 'private topics' leaks (1) are good examples of typical security Rails apps bugs (the result of overusing ActiveRecord). I'm not blaming Discourse, the same kind of bugs appear in other popular Rails codebases (Diaspora, Spree, Redmine). Ember.js is very Rails-like. I didn't use Ember much, but the patterns look so similar, that it may lead to similar kind of problems as in Rails apps. I'm not saying that we shouldn't use Rails or Ember. In fact, I'm a big fan of Rails. It's just worth being careful of not falling into the trap of overusing the framework patterns. The frameworks are best for the infrastructure parts of the app - http, persistence. At the end, it's better that you can control your models. That's the part of Angular that I prefer over Ember - you own your Model part. (1) http://meta.discourse.org/t/digest-mail-ignores-secure-groups/7288 http://meta.discourse.org/t/digest-mail-ignores-secure-group... http://meta.discourse.org/t/non-authenticated-users-see-private-topics-in-404-page-was-mobile-view/7419 http://meta.discourse.org/t/non-authenticated-users-see-priv...
- EvilTrout 13y ago
  Those private topic bugs are not the result of ActiveRecord. We added a group layer on top of existing code and missed some places where queries did not respect it. Had we used raw SQL instead of an ORM we would have had the same issues. All projects are open to this style of bug. The correct thing to do is report, close them quickly and add tests to prevent them from happening again (which we do.)
  - andrzejkrzywda 13y ago
    "Those private topic bugs are not the result of ActiveRecord. We added a group layer on top of existing code and missed some places where queries did not respect it." I've seen so many of such bugs in other apps, that I treat them as part of "ActiveRecord price". ActiveRecord over-usage makes it very easy to miss the places, where queries need to respect new rules. You're doing an awesome job with Discourse and the team approach to such bugs is very good - no doubts here. Thanks for your work!
saurabhnanda 13y ago
Is there anyone out there who has written non-trivial applications (i.e. a _lot more_ than the quintessential todo app) in both, AngularJS & EmberJS and can offer a non-biased opinion? Some time ago, I started off with AngularJS, I liked what I saw (except the dirty checking part) and started building my product / startup with it. I don't have the time to stop all dev and experiment with EmberJS, but would like to know if it's really better or if it's to-mah-toh vs tom-ae-toe. I mean, how hard could it be to have an AngularJS port where the dirty-checking part is removed and Ember-style getters & setters are introduced (thus removing the only efficiency-related issue that I ever came across). On the other hand, what's the equivalent for "directives" in EmberJS? It's singularly, the most powerful concept that I've come across in AngularJS. Btw, AngularJS has an accepted way to define models -- inside "factories" (I know they just sound like Java-esque hell, but they're really simple, once you get to understand them).
- ldn_tech_exec1 13y ago
  we've built a rock solid architecture for complex AngularJS apps here: brandid.github.io/parse-angular-demo/
- camus 13y ago
  there is no directives in EmberJS , you could use any DOM templating engine ( =/= string template engine like Mustach ) with it I guess to get something similar to directives.
  - kapv89 13y ago
    Oh please, "template-engines-thingies" don't even come close to the concept of directives
  - ctvo 13y ago
    No, I wouldn't say that's something similar to directives.
  - saurabhnanda 13y ago
    You don't understand the power of directive till you actually use them.
saurabhnanda 13y ago
I just have the "feeling" that with Discourse being written in EmberJS, people are mindlessly going to flock to it without really looking at anything else. And even if AngularJS really is better, it will be left behind. Just because...
- dsego 13y ago
  It won't be left behind, it's from Google.
  - wesleyworkman 13y ago
    So true! Google never abandons technologies. At least that's what an article on my Google Reader said. :P
  - nailer 13y ago
    It's maintained by Google, but it's from Angular company (an online JSON storage service). The 'by Google' in it's name doesn't mean it's designedto be 'Google's JavaScript MVC' and I know Google employees who think expressly otherwise. http://en.wikipedia.org/wiki/AngularJS#Development_history http://en.wikipedia.org/wiki/AngularJS#Development_history
- Helianthus 13y ago
  Angular and Backbone are currently the frontrunners, by a _lot_.
  - saurabhnanda 13y ago
    Yes, but I'm afraid it might go the RoR way. Rails started off by disrupting the web-dev space and positioning itself as an alternative to Java. It really pushed the overall web-dev space forward. However, today, I feel, Python is more popular than Ruby (at least in my part of the world) because of various other reasons. Even though a lot of web frameworks are doing things the Rails way.
ohwp 13y ago
"In the above snippet, there are three models!" I'm not sure why this is a problem. A model is just a representation. Could be one, could be many objects.
kriswill 13y ago
Coming from Backbone and not really spending any time with either Ember or AngularJS; It seems to me that Ember adopts a more Backbone-like approach to managing Model changes. If only Javascript had a missing method dispatcher, these types of accessor syntax differences would be moot.
- gizmogwai 13y ago
  From what I read, the Ember model looks way closer to what KnockoutJS is providing.
ldn_tech_exec1 13y ago
This is a typical reaction from someone who hasn't used AngularJS to build a complex web app. I would strongly suggest you check out our boilerplate for building complex web apps with AngularJS, which uses Backbone for models and AngularJS for UI and data binding. http://brandid.github.io/parse-angular-demo/ http://brandid.github.io/parse-angular-demo/ "In AngularJS, every time you visit a route, it passes an idand has to resolve it in your controllers." - not true, just use nested controllers and prototypical inheritance to access the already resolved object "AngularJS doesn’t follow this philosophy; it encourages you to throw away what you already had and find it again (probably from the server!)." - not true, thats why $rootScope exists "None of the examples or blogs I read through demonstrated how to reuse object instances, for example. Is that just not done in AngularJS?" - not true, all scopes inherit from each other, javascript prototypical inheritance applies "The problem is that the $watch function belongs to the $scope and NOT the Room." - not true, you can put a $watch on the model if use Backbone for your models "If you had an array of Room instances for example, you can’t watch them all without looping through them all constantly." - not true, you can watch a collection of models, and you can do things like watch the length of the array for less processor intensive use of $watch
- EvilTrout 13y ago
  You can't possibly argue that using Backbone for models is idomatic AngularJS. If you're arguing that with a bunch of extra code on top of AngularJS it does what Ember does out of the box, that was kind of my point.
  - ldn_tech_exec1 13y ago
    ...fair. What's your take on points #1, #2, #3 and #5?
    - EvilTrout 13y ago
      You CAN make Angular work like Ember, but you have to add a lot of code to do what Ember encourages you to do off the bat. What you are suggesting is good practice but something that I suspect very few Angular developers do as it's not encouraged by the framework itself. If you follow the guides on the official Angular site, they're done none of the things you suggest.
rgo 13y ago
I personally don't like either one, but at the end I'm using AngularJS because it's simpler and has a lower entry barrier, bringing several features that I desperately wanted to have in one webapp: routing, templating and a simple mvc for pushing data from the server to the client with websockets. I have the feeling that, by choosing the simpler framework, I can better maneuver around future complexities as I better understand what sits under the hood. Ember, which seems more elaborate than Angular, tries to anticipate solutions to problems I have yet to encounter. Maybe I'll regret it later. I don't know. The reason I don't like either, or any framework in particular, is that none seems to really make a sane toolchain out of html, css and js.
moomin 13y ago
I haven't much experience of either framework, but seriously, they're both way too complicated for what they do. Knockout is about the right level of complexity for the problem space, but Angular has the right engineering. But what does it need an IoC implementation for? I'm happy to accept the problem is hard, but I doubt it's so complex it's impossible to decompose.
- steveklabnik 13y ago
  If you don't have much experience, how do you know they're too complicated?
  - moomin 13y ago
    You're right, I'm shooting my mouth off here, but this is the whole problem with these huge frameworks: they're so huge that, by the time you've spent the time to evaluate them properly, your objectivity is likely to be compromised. You'll never see an even handed comparison between the two. This isn't unique to js frameworks. There's plenty of systems like this e.g. Hibernate. At least backbone was small enough that I could seriously evaluate it in a month long project. (For the record, I didn't like it, but at least I actually can have a considered opinion on it without being well past the point of no return.)
- ww520 13y ago
  I use Knockout, too, and it has served me well. All the computed methods and model change detection are trivial in Knockout.
  - kmkemp 13y ago
    Knockout is only about data binding as far as I know, whereas Angular and Ember are full stack SPA frameworks. Also, while I'm a knockout fan, dealing with observables is not ideal when compared with plain old javascript objects that Angular allows you to bind with.
    - 13y ago
vectorpush 13y ago
At that point, what was the advantage of Sinatra? You were basically running a Rails application. I disagree. I've built many applications using both frameworks and Rails is overkill 80% of the time, especially in front-end heavy apps where most of your routes are GET/POSTing JSON data.
- onli 13y ago
  Note the "At that point". The author claims that if you use sinatra and install ActiveRecord, and basically everything else that defines Rails, you are just running Rails without running Rails. He is right. I like to write my own SQL-Queries, so Sinatra is the better choice. But if you'd want to use an ORM, why not directly use Rails?
  - vectorpush 13y ago
    But if you'd want to use an ORM , why not directly use Rails? An ORM (the only example listed by you or the author) does not a Rails app make. There are dozens of ORMs of all types across every language; DHH did not invent the Active Record pattern and Rails' implementation of it is not the only viable option, even in Ruby (consider Sequel's ORM for example).
edanm 13y ago
Interesting article. I don't have much Ember.js experience, but one of the web apps we recently built was built in Angular.js. We found it pretty good to use, but were seriously hampered by the lack of "best practices" and the not-too-hot documentation. We did try to write it in Ember first, but found it much harder, both because of a much bigger lack of documentation, and because the versions weren't very stable and broke from RC to RC.
jv22222 13y ago
Just wanted to point out it's also possible to build a highly responsive single page web app with 10,000+ lines of javascript without either Angular or Ember, or any other framework. For example: http://plugg.io http://plugg.io
- erikpukinskis 13y ago
  I appreciate the reminder. Pluggio seems pretty clean from the video tutorial! It seems like you must've had to implement a fairly big subset of something like Angular in the process, no?
blissofbeing 13y ago
> Ultimately, I think you should examine your application’s goals. Do you want to build something that pushes the boundaries of what people expect from the web? Is your application going to be super simple, or do you want to add powerful features and maintain it well over time? Yes, thats why I choose Angular over Ember every time. EvilTrout obviously wants to see Ember succeed, I would to if I spent so much time writing a big Ember app and see it loosing out in the Javascript framework wars. The one thing I will say is that his point might be true about performance now, but once Object.Observe lands we won't need dirty checking anymore. It will be easy for Angular to take advantage of it but as far as I understand, Ember will require some major changes to take advantage of it. The way I see it Angular is a forward facing framework showing you how new technologies coming like Object.Observe and Web Components could work together in a framework today.
- natmaster 13y ago
  Wait, are you saying you choose Angular for non super simple stuff? Because I couldn't even consider it due to it's lack of nested layout and routing for anything beyond something super simple.
  - skore 13y ago
    https://github.com/angular-ui/ui-router https://github.com/angular-ui/ui-router https://github.com/angular-ui/ui-router/wiki/Nested-States-%26-Nested-Views https://github.com/angular-ui/ui-router/wiki/Nested-States-%...
  - kapv89 13y ago
    Is that sarcasm ?
  - blissofbeing 13y ago
    I was saying yes to his last question "...do you want to add powerful features and maintain it well over time?" I find the concept of directives one of the most powerful and maintainable features of any framework I have ever used. It's probably the "killer feature" of Angular.
- 13y ago
a_c_m 13y ago
To read another side of the coin, someone who made the move from Ember to Angular : http://beust.com/weblog/2012/12/29/migrating-from-ember-js-to-angularjs/ http://beust.com/weblog/2012/12/29/migrating-from-ember-js-t...
rubiquity 13y ago
I haven't used either of these frameworks but I have used Batman.js[1] which has a very similar feel as Ember.js albeit it's written using CoffeeScript. The two issues that this author are singling out aren't exactly addressed fairly so I sort of feel inclined to defend Angular here. Author states that one downside of AngularJS is that it doesn't conform to the Uniform Access Principle. JavaScript the language itself doesn't conform to this either. From what I can tell from my brief review of AngularJS, it tries to be as close to the implementation of JavaScript as possible. I don't see this as a bad thing but rather as a good thing. Using methods like #get and #set drove me crazy when I was using Batman.js. I understand why they exist, but why are #get and #set acceptable ways of accessing object properties but #area isn't? I think they both have the same performance implications, don't quote me on that as I'll never claim to be a JavaScript method cache expert. His first point is that in AngularJS you don't have a true base object that your models inherit from and instead you use plain JavaScript objects. This sounds like another bonus to AngularJS in my eyes! And if it doesn't seem like a bonus to you, you can quickly create a light abstraction to serve as a Model. All in all, having not used either of these frameworks this blog post actually makes me want to use AngularJS more than it makes me want to use Ember. 1 - http://www.batmanjs.org http://www.batmanjs.org
- erikpukinskis 13y ago
  > why are #get and #set acceptable ways of accessing object properties but #area isn't? Because Ember only has to recalculate the area after set is called on length or width. If area is just a function, it gets recalculated every time it's called/get'ed.
ctvo 13y ago
Can you explain what functionality Angular is missing that makes it a less complete framework than Ember? This premise keeps getting repeated here in the form of Angular being "simpler" -- if it's more simple, but offers the same functionality, I'd take that any day.
- wmil 13y ago
  Nested views aren't in Angular. Also Angular doesn't really have models. It has data and dirty checking, but nothing a Rails dev would recognize as a model.
  - kapv89 13y ago
    can agree with the fact that angular models are really left up to you, but stating that angular can't do "nested views" just shows your ignorance
    - steveklabnik 13y ago
      You can make a much more powerful argument by showing how nested views work in angular, rather than by making strong statements with nothing to back them up. If nested views are in the basic Angular docs, it's even more strong. Don't just say someone is ignorant, show them how to not be ignorant any longer. It helps them, and makes you seem like less of a jerk.
tracker1 13y ago
What I REALLY want is a relatively clean implementation of MV* that I can re-use all parts client and server.. NodeJS is the natural platform, but I haven't really seen much that makes reusing rendering, models and business logic client and server to a natural point. I know that there are people working on this, but I think that getting closer to a solution that can easily converge on such re-use for really dynamic apps, maybe mobile being more server-side, and desktop/tablet being more client will do very well in the end.
- nailer 13y ago
  Agreed - server side rendering for the first time you hit a website, pushstate and client side rendering for subsequent navigation makes for some very smooth UX. - Derby.JS is one such a full-stack framework. - There's also Meteor but this has a little less community support. - Eyebrow.JS is coming (there's a number of blog posts and talk videos) but I'm not sure if it's released yet.
SolarUpNote 13y ago
Does this boil down to: 1) The DOM is the model. JS reads elements and data attributes and builds a model from them. Then updates the model when the DOM changes. (Angular) 2) The model is loaded from JSON. Then the App builds the DOM based on the model. (Ember) So is the question: Does it start with the DOM, or start with javascript objects? Am I understanding this debate correctly?
- erikpukinskis 13y ago
  I don't think that's the major distinction. Both store models in javascript. Some of the big things being debated are the use of getters/setters and the data lifecycle that happens when you change routes.
randomguy7788 13y ago
we're currently working on an angularjs application that has to deal with massive amounts of editable data on screen (think of purchase orders, ship notices, invoices that need to be sent out to walmart, kroger, target scale). although i have had minor issues here and there all you really need to know is what angular is currently monitoring (usually you expose the mutable parts of your models) and exposing that to the angular runtime while hiding what it doesn't need to know to get a performance boost. as for reusability angular services has been both easily and wonderful to use because of angularjs DI approach to everything. this application also has to have a pluggable(200+ different company business/validation rules) rule engine, and being able to configure angularjs services through its providers interface has been very helpful with that problem. we're not done yet so i can't give a final verdict but we've been overall pleased with the framework so far. i also agree with some of the sentiments in here where angularjs does not currently seem to have a culture of what is "idiomatic" angular which can be very detrimental in the short and long run. one of the reasons we didn't go with ember is that the decision was made at the time where in they were making huge changes to ember.
danso 13y ago
The fact that Google is backing AngularJS is a nice bit of reassurance. But are any of their current apps using AngularJS in any way? I realize most of their major apps, such as GMail and documents, pre-date Angular...but they must use it, or parts of it for something prominent, right?
- coolsunglasses 13y ago
  Doubleclick for Advertisers is AngularJS now and that's a pretty big project in terms of surface area. DFA drove a lot of early refinements in how AngularJS works. Since then, it's largely community driven.
- camus 13y ago
  > The fact that Google is backing AngularJS is a nice bit of reassurance Really? google frame ? google reader ? (...) they dont give a f.. While Angular is quite complete feature wise , the UI responsiveness of a AngularJS application is not that great. At least that's my personal experience.
  - paranoiacblack 13y ago
    What do you mean? Have you ever used http://angular-ui.github.io/ http://angular-ui.github.io/? These are all excellent in my experience.
laureny 13y ago
> I believe it's unlikely that "not even close" is at all accurate. Especially since the opening argument of the author is that AngularJS is gaining momentum because "it is simpler". My personal experience is that when I ported my application from Ember to Angular, my code base (~5,000 lines) get simplified considerably. Based on what I've been reading, I'm not the only one making these observations. My main beef with Ember was not about complexity or simplicity, just that it's not as powerful as AngularJS and it also covers only a small part of what AngularJS gives me out of the box (especially server side includes).
electrotype 13y ago
I'm mostly a backend web developer but I'm really curious to see where Google is going with Dart + AngularJS. I think there may be something interesting there, for those like me who don't like javascript!
rogerthis 13y ago
OK. While religious tech war, I'll be offering whatever my clients want and solves their particular needs.
sintaxi 13y ago
One is 272kb and the other is 78kb. This should be noted at the beginning of any article making such a comparison.
- TylerE 13y ago
  Seriously? I mean, _really_? 200k? This isn't 1998 any more. If it was 2MB, you might have something resembling a point.
  - sintaxi 13y ago
    It's not the size, it's the footprint. And it very much matters on mobile.
- wesleyworkman 13y ago
  It's not really a fair comparison for several reasons. Namely that to match Ember's functionality, you have to add several libraries to your AngularJS app. Eventually you'll reach the point where you've effectively got the same size in several libraries, as opposed to one. This is the same argument the Backbone guys use to make and it's stupid. If you don't need that level of functionality, then fine, don't pick up the framework with a few extra KBs. But keep in mind that with any luck, your app will start to grow. When it does you'll need to scale and perhaps you'll discover there was value in using a more functional framework.
- bluepnume 13y ago
  It's 55kb gzipped. Angular is 30kb. Does that 25kb make all the difference?
  - sintaxi 13y ago
    Yes. The footprint matters. All that JS has to be parsed by the browser. The difference is not negligible.
wesleyworkman 13y ago
I can't speak much to AngularJS, I've never used it in a project and only spent a few hours playing with the demos. Even if I had, making single one line knocks at either framework is not going to convince anyone of the others value. That said, I have a pretty large Ember app, I adopted Ember for my app when it was known as SproutCore 2 (before AngularJS was known). Both my app and Ember have gone through a very long, very painful maturing process. But it's finally in a really good place. Ember's patterns are the result of months (years really) of spinning, cycling, iterating and collaborating with developers using the framework. Seeing the process of evolution and open collaboration unfold in the community is just as exciting and thrilling as the state of the framework it's self. My advice is to try them both and decide for yourself. The only thing I'd ask is please don't assume one is easier or better than the other with only a few hours of use. If you're planning to build a sizable app, please take the time to evaluate them both thoroughly and decide what's best for you.
scardine 13y ago
My personal experience is the opposite. I tried Ember first. Got excited replicating the sample blog app, but got stuck trying a simple task: show the most recent post by default (see this bug: https://github.com/emberjs/ember.js/issues/1642 https://github.com/emberjs/ember.js/issues/1642). Later I started to trip into namespace clashes - you have to jump a few hoops if your model has a field named "content", "is_new" or "is_deleted" (http://stackoverflow.com/questions/16515900/reserved-atribute-names-in-ember-js-models http://stackoverflow.com/questions/16515900/reserved-atribut...). My general impression is: there is nice ideas here but Ember is too opinionated and has to many magic going on (hard to debug). In contrast, Angular shows better design everywhere. No name clashes, framework methods and attributes use special prefix $ (like python uses double underscores). Everything I got stuck with ember, I was able to achieve elegantly with Angular. I love the eviltrout but this post is lacking a bit of diligence. Angular learning curve is a little steeper but IMHO it is way more finished and well designed than Ember (Ember data has good ideas, they have a cute mascot, and it ends here).
d0m 13y ago
I know it's really not the point on the article, but I wanted to share a quick and dirty solution for a common problem, especially this: >> If you were using jQuery to do this, you’d likely bind a function to the click event on each row. When fired, your function would change the CSS class of the row to highlight it. >> You can’t stop there, though. Your function also has to remove the CSS class from any other rows that were previously selected. That’s a little crazy if you think about it! Changing which item is selected means we have to know everywhere that it’s been represented in our UI. An easy way is just to do: $('<all-row-selector..>').each(<unselect>) .find('<selected-row>').each(<select>)
gphreak 13y ago
I haven't played with EmberJS too much, but read several times that debugging can get pretty nasty (the poster mentioned something about a run-loop if I remember correctly?). Did you encounter similar issues or do you rely mostly on unit tests for debugging?
iknight 13y ago
this just in: Ember.js Fanboi tries AngularJs-- says it sucks because it's not like Ember.js

207 points by EvilTrout 13y ago

wc- 13y ago

Coming from someone that has used neither framework, I like the write up w/ examples. However, I wasn't convinced that "it's not even close" so maybe a bad title choice.

jergason 13y ago
I agree. The article is a reasonable discussion of the differences between the two frameworks from the perspective of an experienced Ember user, and does a decent job illustrating why Robin prefers Ember. The title is argumentative and inflammatory. I think lots of people will read the title on Twitter and roll their eyes at the Ember attack-marketing machine when the article itself contains some valuable points.
- raganwald 13y ago
  You are absolutely correct. I realize I'm in the minority, but I take all blog titles with a bushel of rock salt. Probably because I like to have my own little jokes when I write titles, so I try to ignore what they appear to say and use them only to decide whether to read the post, not to decide whether the post is any good.
- zwily 13y ago
  The title doesn't actually indicate which one wins, so at least those Twitter users would have to read the first couple sentences before clicking away...
EvilTrout 13y ago
I went back and forth on the title. I don't usually write sensational titles but for some reason decided to give it a try. I think it's a very good point and I doubt I'll do it again.
- raganwald 13y ago
  It could be worse. One fellow I know wanted to write about the benefits of significant whitespace, and thought it would be funny to call his essay "White Power." I doubt he'll try that again. ;-)
gilrain 13y ago
"Ember vs AngularJS: I Prefer Ember and Feel that I Have Compelling Reasons for That Preference" is a bit longer, though.
steveklabnik 13y ago
Would it be on the top of HN if it had a more reasonable title? Is the audience just as complicit as the author in trending towards flamebait?
- Buttons840 13y ago
  I was interested in the Ember vs Angular comparison regardless of the title. Also, I've enjoyed EvilTrout blogs in the past.

gkop 13y ago

It's not even close for what purpose? For example, there's a wide common case of simple apps hacked together by 1 or 2 developers, traditionally composed of jQuery spaghetti. Maybe Angular is a perfect tool to better organize these typical, not-particularly-ambitious apps, where Ember would be a pre-mature optimization. And perhaps Ember is the perfect tool for sophisticated apps written by teams of developers.

steveklabnik 13y ago
> It's not even close for what purpose? As the article says at the end: > Ultimately, I think you should examine your application’s goals. Do you want to build something that pushes the boundaries of what people expect from the web? Is your application going to be super simple, or do you want to add powerful features and maintain it well over time?
- gkop 13y ago
  Read on > If you’re serious about front end development, I advise you to take the time to learn Ember properly. The article isn't fair to Angular. It's like saying, If you're a professional web designer, you should always use semantic markup and a CSS pre-processor, and never Twitter Bootstrap. In fact, Twitter Bootstrap and Angular both have their places alongside Sass and Ember.

pron 13y ago

...At that point, what was the advantage of Sinatra? You were basically running a Rails application. Framework simplicity is good if your application is meant to be simple. But you should be cautious when choosing simplicity if your application is ambitious and you care about supporting it for a long time. This is what I like about Clojure. It is so composable, that simplicity doesn't come at the expense of features. The language makes composing disparate libraries so easy, that it's quite trivial to mix and match different libraries and have them all work in tandem. You don't only use what you need, but for every aspect of your application you can choose the best tool for your particular needs.

danneu 13y ago
Clojure's namespace declaration: (ns my-app.my-namespace (:require [some-library.some-namespace :as foo]) is pretty liberating for me after working with Ruby for so long. Composition is tedious to reason about in Ruby when your only clue is a menagerie of `require`s at the top of the file. Or, more commonly, when your only clue is a Gemfile because all the gems are auto-required and omnipresent.
- prollyignored 13y ago
  An offtopic clojure question. Today I was seeing this -- https://en.wikipedia.org/wiki/Knuth-Morris-Pratt_algorithm https://en.wikipedia.org/wiki/Knuth-Morris-Pratt_algorithm How can I begin to implement it in clojure ? Specifically, how do I _ingeneral_ deal with assignments and while loops. In common-lisp, for example I would use the `loop` macro and defvar-sefq combo, (beginning lisper). In ruby, = and while itself.
  - danneu 13y ago
    Clojure has most of the semantics you're used to in other languages. http://clojuredocs.org/clojure_core/clojure.core/let http://clojuredocs.org/clojure_core/clojure.core/let (let [username "prollyignored" karma 7] (println username "has" karma "karma points.")) ; prollyignored has 7 karma points. http://clojuredocs.org/clojure_core/1.2.0/clojure.core/loop http://clojuredocs.org/clojure_core/1.2.0/clojure.core/loop (loop [n 0] (when (< n 10) (print n) (recur (inc n)))) ;=> 0123456789 http://clojuredocs.org/clojure_core/clojure.core/for http://clojuredocs.org/clojure_core/clojure.core/for (for [x [0 1 2 3 4 5] :let [y (* x 3)] :when (even? y)] y) ;=> (0 6 12) Or just: (filter even? (map #(* % 3) [0 1 2 3 4 5])) ;=> (0 6 12) Browse the Clojure cheatsheet: http://clojure.org/cheatsheet http://clojure.org/cheatsheet

olalonde 13y ago

A higher level framework makes you more productive but a single bug can get you stuck for hours, days or weeks. A lower level framework doesn't make you as much productive but you have a better mental model of what is going on and bugs get solved quickly. Keep in mind when choosing a framework.

ldn_tech_exec1 13y ago
very true
3pt14159 13y ago
THIS! This is exactly what I was trying to figure out how to type. Right now ember is especially hard to learn since it is constantly changing and ember-data isn't done yet. As a result there are 5 different ways of doing something and when you get stuck you finally solve it by finding someone else who had the same problem and that is when you learn that the tutorial was for rc3, not rc5. But the huge problem is that it took you forever to get there. I personally think Ember will win, and it will win hard, for the professional developer market. I think it will come down to Rails : PHP :: Ember : Angular, but in the mean time angular will get a huge head start. Once people get used to those common single bugs that keep them stuck for hours, they will be far more productive for non-trivial applications than angular devs will be.
- steveklabnik 13y ago
  > constantly changing 1.0.0.rc1 was released on February 15, and (to my knowledge) there has been _one_ backwards-incompatible change since then. > ember-data isn't done yet You don't need to use ember-data: http://eviltrout.com/2013/03/23/ember-without-data.html http://eviltrout.com/2013/03/23/ember-without-data.html
  - 3pt14159 13y ago
    It is painful to try to learn something when different articles all say how to do a hello world differently. It doesn't matter the reasons why, it is just harder. I get it now, but don't make it like it is easy for someone to learn.

yajoe 13y ago

As a gentle reminder, Fred Brooks said "there are no silver bullets" in software (http://en.wikipedia.org/wiki/No_Silver_Bullet http://en.wikipedia.org/wiki/No_Silver_Bullet ). Even without knowing the details of this article, I believe it's unlikely that "not even close" is at all accurate. There likely are advantages, but from my experience (10k+ LOC apps on each Ember, Angular, and Backbone) no one MVC (or MV-) framework is inherently better. They all have serious tradeoffs that SO has done a much better job documenting. One nit from the essay: the author comments on the missing 'model' from Angular and provides an example of a computed property to illustrate this. In many (not all) Angular applications, the server is responsible for the model (think a Parse or other REST-style backend), and the Angular app is simply responsible for rendering it. Angular (err Restangular to be specific) has a way to do this with less code and an aesthetic (data binding in HTML) that I personally like. If, however, you were writing code that needed the client to have a lot more business logic (i.e. computed properties, browser local storage, etc) then something like Ember would be a better choice because of its 'Model.' A lot of shit crud apps, however, don't need that much business logic in the client (at least for an MVP), and that would be my narrative for why Angular appears more popular. That said, I use computed properties in a couple places with Angular, and watches have performed perfectly fine for my use (gallery of 1000s thumbnails). He should disclaim that YMMV. Neither is inherently better, and both teams working on them are full of smart, quality engineers that understand these problems in ways I never will.

prollyignored 13y ago
This is something else. I'd like to call it, "the appeal to the bold new future fallacy, with sensationalist titles" <template> Is X trying to change the paradigm ? No. Use Y. Is Y trying to change the paradigm ? Yes. Use Y </template> Some dumb geeks just can't handle "worse is better" !
EvilTrout 13y ago
> In many (not all) Angular applications, the server is responsible for the model (think a Parse or other REST-style backend), and the Angular app is simply responsible for rendering it. My question is then: why are people purposely choosing not to use the advantages of client side MVC code? All of a sudden we have access to all these awesome features of long lived applications and people are choosing patterns that don't embrace it. > That said, I use computed properties in a couple places with Angular, and watches have performed perfectly fine for my use I do say in the end that there are viable workarounds. It's an issue of maintainability and consistency. Ember embraces patterns for ambitious applications. If it works for you I'm glad, I just think we should open ourselves up more to the advantages of rich client side apps and not hold back!

camus 13y ago

> but ask yourself this: are all developers on your team going to follow the same conventions? That's the point of using a framework. You need to stick to conventions since frameworks have an opinon on how things should be(Ember does i guess). I never tried Ember ( I will ), but AngularJS comes with a lot of battery included , that's why it is really awesome.

andrzejkrzywda 13y ago

Choosing a heavier framework may put you in risk of 'typical', framework-related bugs that often appear. The bugs are not part of the framework, but they are part of the patterns around it. Discourse 'private topics' leaks (1) are good examples of typical security Rails apps bugs (the result of overusing ActiveRecord). I'm not blaming Discourse, the same kind of bugs appear in other popular Rails codebases (Diaspora, Spree, Redmine). Ember.js is very Rails-like. I didn't use Ember much, but the patterns look so similar, that it may lead to similar kind of problems as in Rails apps. I'm not saying that we shouldn't use Rails or Ember. In fact, I'm a big fan of Rails. It's just worth being careful of not falling into the trap of overusing the framework patterns. The frameworks are best for the infrastructure parts of the app - http, persistence. At the end, it's better that you can control your models. That's the part of Angular that I prefer over Ember - you own your Model part. (1) http://meta.discourse.org/t/digest-mail-ignores-secure-groups/7288 http://meta.discourse.org/t/digest-mail-ignores-secure-group... http://meta.discourse.org/t/non-authenticated-users-see-private-topics-in-404-page-was-mobile-view/7419 http://meta.discourse.org/t/non-authenticated-users-see-priv...

EvilTrout 13y ago
Those private topic bugs are not the result of ActiveRecord. We added a group layer on top of existing code and missed some places where queries did not respect it. Had we used raw SQL instead of an ORM we would have had the same issues. All projects are open to this style of bug. The correct thing to do is report, close them quickly and add tests to prevent them from happening again (which we do.)
- andrzejkrzywda 13y ago
  "Those private topic bugs are not the result of ActiveRecord. We added a group layer on top of existing code and missed some places where queries did not respect it." I've seen so many of such bugs in other apps, that I treat them as part of "ActiveRecord price". ActiveRecord over-usage makes it very easy to miss the places, where queries need to respect new rules. You're doing an awesome job with Discourse and the team approach to such bugs is very good - no doubts here. Thanks for your work!

saurabhnanda 13y ago

Is there anyone out there who has written non-trivial applications (i.e. a _lot more_ than the quintessential todo app) in both, AngularJS & EmberJS and can offer a non-biased opinion? Some time ago, I started off with AngularJS, I liked what I saw (except the dirty checking part) and started building my product / startup with it. I don't have the time to stop all dev and experiment with EmberJS, but would like to know if it's really better or if it's to-mah-toh vs tom-ae-toe. I mean, how hard could it be to have an AngularJS port where the dirty-checking part is removed and Ember-style getters & setters are introduced (thus removing the only efficiency-related issue that I ever came across). On the other hand, what's the equivalent for "directives" in EmberJS? It's singularly, the most powerful concept that I've come across in AngularJS. Btw, AngularJS has an accepted way to define models -- inside "factories" (I know they just sound like Java-esque hell, but they're really simple, once you get to understand them).

ldn_tech_exec1 13y ago
we've built a rock solid architecture for complex AngularJS apps here: brandid.github.io/parse-angular-demo/
camus 13y ago
there is no directives in EmberJS , you could use any DOM templating engine ( =/= string template engine like Mustach ) with it I guess to get something similar to directives.
- kapv89 13y ago
  Oh please, "template-engines-thingies" don't even come close to the concept of directives
- ctvo 13y ago
  No, I wouldn't say that's something similar to directives.
- saurabhnanda 13y ago
  You don't understand the power of directive till you actually use them.

saurabhnanda 13y ago

I just have the "feeling" that with Discourse being written in EmberJS, people are mindlessly going to flock to it without really looking at anything else. And even if AngularJS really is better, it will be left behind. Just because...

dsego 13y ago
It won't be left behind, it's from Google.
- wesleyworkman 13y ago
  So true! Google never abandons technologies. At least that's what an article on my Google Reader said. :P
- nailer 13y ago
  It's maintained by Google, but it's from Angular company (an online JSON storage service). The 'by Google' in it's name doesn't mean it's designedto be 'Google's JavaScript MVC' and I know Google employees who think expressly otherwise. http://en.wikipedia.org/wiki/AngularJS#Development_history http://en.wikipedia.org/wiki/AngularJS#Development_history
Helianthus 13y ago
Angular and Backbone are currently the frontrunners, by a _lot_.
- saurabhnanda 13y ago
  Yes, but I'm afraid it might go the RoR way. Rails started off by disrupting the web-dev space and positioning itself as an alternative to Java. It really pushed the overall web-dev space forward. However, today, I feel, Python is more popular than Ruby (at least in my part of the world) because of various other reasons. Even though a lot of web frameworks are doing things the Rails way.

ohwp 13y ago

"In the above snippet, there are three models!" I'm not sure why this is a problem. A model is just a representation. Could be one, could be many objects.

kriswill 13y ago

Coming from Backbone and not really spending any time with either Ember or AngularJS; It seems to me that Ember adopts a more Backbone-like approach to managing Model changes. If only Javascript had a missing method dispatcher, these types of accessor syntax differences would be moot.

gizmogwai 13y ago
From what I read, the Ember model looks way closer to what KnockoutJS is providing.

ldn_tech_exec1 13y ago

This is a typical reaction from someone who hasn't used AngularJS to build a complex web app. I would strongly suggest you check out our boilerplate for building complex web apps with AngularJS, which uses Backbone for models and AngularJS for UI and data binding. http://brandid.github.io/parse-angular-demo/ http://brandid.github.io/parse-angular-demo/ "In AngularJS, every time you visit a route, it passes an idand has to resolve it in your controllers." - not true, just use nested controllers and prototypical inheritance to access the already resolved object "AngularJS doesn’t follow this philosophy; it encourages you to throw away what you already had and find it again (probably from the server!)." - not true, thats why $rootScope exists "None of the examples or blogs I read through demonstrated how to reuse object instances, for example. Is that just not done in AngularJS?" - not true, all scopes inherit from each other, javascript prototypical inheritance applies "The problem is that the $watch function belongs to the $scope and NOT the Room." - not true, you can put a $watch on the model if use Backbone for your models "If you had an array of Room instances for example, you can’t watch them all without looping through them all constantly." - not true, you can watch a collection of models, and you can do things like watch the length of the array for less processor intensive use of $watch

EvilTrout 13y ago
You can't possibly argue that using Backbone for models is idomatic AngularJS. If you're arguing that with a bunch of extra code on top of AngularJS it does what Ember does out of the box, that was kind of my point.
- ldn_tech_exec1 13y ago
  ...fair. What's your take on points #1, #2, #3 and #5?
  - EvilTrout 13y ago
    You CAN make Angular work like Ember, but you have to add a lot of code to do what Ember encourages you to do off the bat. What you are suggesting is good practice but something that I suspect very few Angular developers do as it's not encouraged by the framework itself. If you follow the guides on the official Angular site, they're done none of the things you suggest.

rgo 13y ago

I personally don't like either one, but at the end I'm using AngularJS because it's simpler and has a lower entry barrier, bringing several features that I desperately wanted to have in one webapp: routing, templating and a simple mvc for pushing data from the server to the client with websockets. I have the feeling that, by choosing the simpler framework, I can better maneuver around future complexities as I better understand what sits under the hood. Ember, which seems more elaborate than Angular, tries to anticipate solutions to problems I have yet to encounter. Maybe I'll regret it later. I don't know. The reason I don't like either, or any framework in particular, is that none seems to really make a sane toolchain out of html, css and js.

moomin 13y ago

I haven't much experience of either framework, but seriously, they're both way too complicated for what they do. Knockout is about the right level of complexity for the problem space, but Angular has the right engineering. But what does it need an IoC implementation for? I'm happy to accept the problem is hard, but I doubt it's so complex it's impossible to decompose.

steveklabnik 13y ago
If you don't have much experience, how do you know they're too complicated?
- moomin 13y ago
  You're right, I'm shooting my mouth off here, but this is the whole problem with these huge frameworks: they're so huge that, by the time you've spent the time to evaluate them properly, your objectivity is likely to be compromised. You'll never see an even handed comparison between the two. This isn't unique to js frameworks. There's plenty of systems like this e.g. Hibernate. At least backbone was small enough that I could seriously evaluate it in a month long project. (For the record, I didn't like it, but at least I actually can have a considered opinion on it without being well past the point of no return.)
ww520 13y ago
I use Knockout, too, and it has served me well. All the computed methods and model change detection are trivial in Knockout.
- kmkemp 13y ago
  Knockout is only about data binding as far as I know, whereas Angular and Ember are full stack SPA frameworks. Also, while I'm a knockout fan, dealing with observables is not ideal when compared with plain old javascript objects that Angular allows you to bind with.
  - 13y ago

vectorpush 13y ago

At that point, what was the advantage of Sinatra? You were basically running a Rails application. I disagree. I've built many applications using both frameworks and Rails is overkill 80% of the time, especially in front-end heavy apps where most of your routes are GET/POSTing JSON data.

onli 13y ago
Note the "At that point". The author claims that if you use sinatra and install ActiveRecord, and basically everything else that defines Rails, you are just running Rails without running Rails. He is right. I like to write my own SQL-Queries, so Sinatra is the better choice. But if you'd want to use an ORM, why not directly use Rails?
- vectorpush 13y ago
  But if you'd want to use an ORM , why not directly use Rails? An ORM (the only example listed by you or the author) does not a Rails app make. There are dozens of ORMs of all types across every language; DHH did not invent the Active Record pattern and Rails' implementation of it is not the only viable option, even in Ruby (consider Sequel's ORM for example).

edanm 13y ago

Interesting article. I don't have much Ember.js experience, but one of the web apps we recently built was built in Angular.js. We found it pretty good to use, but were seriously hampered by the lack of "best practices" and the not-too-hot documentation. We did try to write it in Ember first, but found it much harder, both because of a much bigger lack of documentation, and because the versions weren't very stable and broke from RC to RC.

jv22222 13y ago

Just wanted to point out it's also possible to build a highly responsive single page web app with 10,000+ lines of javascript without either Angular or Ember, or any other framework. For example: http://plugg.io http://plugg.io

erikpukinskis 13y ago
I appreciate the reminder. Pluggio seems pretty clean from the video tutorial! It seems like you must've had to implement a fairly big subset of something like Angular in the process, no?

blissofbeing 13y ago

> Ultimately, I think you should examine your application’s goals. Do you want to build something that pushes the boundaries of what people expect from the web? Is your application going to be super simple, or do you want to add powerful features and maintain it well over time? Yes, thats why I choose Angular over Ember every time. EvilTrout obviously wants to see Ember succeed, I would to if I spent so much time writing a big Ember app and see it loosing out in the Javascript framework wars. The one thing I will say is that his point might be true about performance now, but once Object.Observe lands we won't need dirty checking anymore. It will be easy for Angular to take advantage of it but as far as I understand, Ember will require some major changes to take advantage of it. The way I see it Angular is a forward facing framework showing you how new technologies coming like Object.Observe and Web Components could work together in a framework today.

natmaster 13y ago
Wait, are you saying you choose Angular for non super simple stuff? Because I couldn't even consider it due to it's lack of nested layout and routing for anything beyond something super simple.
- skore 13y ago
  https://github.com/angular-ui/ui-router https://github.com/angular-ui/ui-router https://github.com/angular-ui/ui-router/wiki/Nested-States-%26-Nested-Views https://github.com/angular-ui/ui-router/wiki/Nested-States-%...
- kapv89 13y ago
  Is that sarcasm ?
- blissofbeing 13y ago
  I was saying yes to his last question "...do you want to add powerful features and maintain it well over time?" I find the concept of directives one of the most powerful and maintainable features of any framework I have ever used. It's probably the "killer feature" of Angular.
13y ago

a_c_m 13y ago

To read another side of the coin, someone who made the move from Ember to Angular : http://beust.com/weblog/2012/12/29/migrating-from-ember-js-to-angularjs/ http://beust.com/weblog/2012/12/29/migrating-from-ember-js-t...

rubiquity 13y ago

I haven't used either of these frameworks but I have used Batman.js[1] which has a very similar feel as Ember.js albeit it's written using CoffeeScript. The two issues that this author are singling out aren't exactly addressed fairly so I sort of feel inclined to defend Angular here. Author states that one downside of AngularJS is that it doesn't conform to the Uniform Access Principle. JavaScript the language itself doesn't conform to this either. From what I can tell from my brief review of AngularJS, it tries to be as close to the implementation of JavaScript as possible. I don't see this as a bad thing but rather as a good thing. Using methods like #get and #set drove me crazy when I was using Batman.js. I understand why they exist, but why are #get and #set acceptable ways of accessing object properties but #area isn't? I think they both have the same performance implications, don't quote me on that as I'll never claim to be a JavaScript method cache expert. His first point is that in AngularJS you don't have a true base object that your models inherit from and instead you use plain JavaScript objects. This sounds like another bonus to AngularJS in my eyes! And if it doesn't seem like a bonus to you, you can quickly create a light abstraction to serve as a Model. All in all, having not used either of these frameworks this blog post actually makes me want to use AngularJS more than it makes me want to use Ember. 1 - http://www.batmanjs.org http://www.batmanjs.org

erikpukinskis 13y ago
> why are #get and #set acceptable ways of accessing object properties but #area isn't? Because Ember only has to recalculate the area after set is called on length or width. If area is just a function, it gets recalculated every time it's called/get'ed.

ctvo 13y ago

Can you explain what functionality Angular is missing that makes it a less complete framework than Ember? This premise keeps getting repeated here in the form of Angular being "simpler" -- if it's more simple, but offers the same functionality, I'd take that any day.

wmil 13y ago
Nested views aren't in Angular. Also Angular doesn't really have models. It has data and dirty checking, but nothing a Rails dev would recognize as a model.
- kapv89 13y ago
  can agree with the fact that angular models are really left up to you, but stating that angular can't do "nested views" just shows your ignorance
  - steveklabnik 13y ago
    You can make a much more powerful argument by showing how nested views work in angular, rather than by making strong statements with nothing to back them up. If nested views are in the basic Angular docs, it's even more strong. Don't just say someone is ignorant, show them how to not be ignorant any longer. It helps them, and makes you seem like less of a jerk.

tracker1 13y ago

What I REALLY want is a relatively clean implementation of MV* that I can re-use all parts client and server.. NodeJS is the natural platform, but I haven't really seen much that makes reusing rendering, models and business logic client and server to a natural point. I know that there are people working on this, but I think that getting closer to a solution that can easily converge on such re-use for really dynamic apps, maybe mobile being more server-side, and desktop/tablet being more client will do very well in the end.

nailer 13y ago
Agreed - server side rendering for the first time you hit a website, pushstate and client side rendering for subsequent navigation makes for some very smooth UX. - Derby.JS is one such a full-stack framework. - There's also Meteor but this has a little less community support. - Eyebrow.JS is coming (there's a number of blog posts and talk videos) but I'm not sure if it's released yet.

SolarUpNote 13y ago

Does this boil down to: 1) The DOM is the model. JS reads elements and data attributes and builds a model from them. Then updates the model when the DOM changes. (Angular) 2) The model is loaded from JSON. Then the App builds the DOM based on the model. (Ember) So is the question: Does it start with the DOM, or start with javascript objects? Am I understanding this debate correctly?

erikpukinskis 13y ago
I don't think that's the major distinction. Both store models in javascript. Some of the big things being debated are the use of getters/setters and the data lifecycle that happens when you change routes.

randomguy7788 13y ago

we're currently working on an angularjs application that has to deal with massive amounts of editable data on screen (think of purchase orders, ship notices, invoices that need to be sent out to walmart, kroger, target scale). although i have had minor issues here and there all you really need to know is what angular is currently monitoring (usually you expose the mutable parts of your models) and exposing that to the angular runtime while hiding what it doesn't need to know to get a performance boost. as for reusability angular services has been both easily and wonderful to use because of angularjs DI approach to everything. this application also has to have a pluggable(200+ different company business/validation rules) rule engine, and being able to configure angularjs services through its providers interface has been very helpful with that problem. we're not done yet so i can't give a final verdict but we've been overall pleased with the framework so far. i also agree with some of the sentiments in here where angularjs does not currently seem to have a culture of what is "idiomatic" angular which can be very detrimental in the short and long run. one of the reasons we didn't go with ember is that the decision was made at the time where in they were making huge changes to ember.

danso 13y ago

The fact that Google is backing AngularJS is a nice bit of reassurance. But are any of their current apps using AngularJS in any way? I realize most of their major apps, such as GMail and documents, pre-date Angular...but they must use it, or parts of it for something prominent, right?

coolsunglasses 13y ago
Doubleclick for Advertisers is AngularJS now and that's a pretty big project in terms of surface area. DFA drove a lot of early refinements in how AngularJS works. Since then, it's largely community driven.
camus 13y ago
> The fact that Google is backing AngularJS is a nice bit of reassurance Really? google frame ? google reader ? (...) they dont give a f.. While Angular is quite complete feature wise , the UI responsiveness of a AngularJS application is not that great. At least that's my personal experience.
- paranoiacblack 13y ago
  What do you mean? Have you ever used http://angular-ui.github.io/ http://angular-ui.github.io/? These are all excellent in my experience.

laureny 13y ago

> I believe it's unlikely that "not even close" is at all accurate. Especially since the opening argument of the author is that AngularJS is gaining momentum because "it is simpler". My personal experience is that when I ported my application from Ember to Angular, my code base (~5,000 lines) get simplified considerably. Based on what I've been reading, I'm not the only one making these observations. My main beef with Ember was not about complexity or simplicity, just that it's not as powerful as AngularJS and it also covers only a small part of what AngularJS gives me out of the box (especially server side includes).

electrotype 13y ago

I'm mostly a backend web developer but I'm really curious to see where Google is going with Dart + AngularJS. I think there may be something interesting there, for those like me who don't like javascript!

rogerthis 13y ago

OK. While religious tech war, I'll be offering whatever my clients want and solves their particular needs.

sintaxi 13y ago

One is 272kb and the other is 78kb. This should be noted at the beginning of any article making such a comparison.

TylerE 13y ago
Seriously? I mean, _really_? 200k? This isn't 1998 any more. If it was 2MB, you might have something resembling a point.
- sintaxi 13y ago
  It's not the size, it's the footprint. And it very much matters on mobile.
wesleyworkman 13y ago
It's not really a fair comparison for several reasons. Namely that to match Ember's functionality, you have to add several libraries to your AngularJS app. Eventually you'll reach the point where you've effectively got the same size in several libraries, as opposed to one. This is the same argument the Backbone guys use to make and it's stupid. If you don't need that level of functionality, then fine, don't pick up the framework with a few extra KBs. But keep in mind that with any luck, your app will start to grow. When it does you'll need to scale and perhaps you'll discover there was value in using a more functional framework.
bluepnume 13y ago
It's 55kb gzipped. Angular is 30kb. Does that 25kb make all the difference?
- sintaxi 13y ago
  Yes. The footprint matters. All that JS has to be parsed by the browser. The difference is not negligible.

wesleyworkman 13y ago

I can't speak much to AngularJS, I've never used it in a project and only spent a few hours playing with the demos. Even if I had, making single one line knocks at either framework is not going to convince anyone of the others value. That said, I have a pretty large Ember app, I adopted Ember for my app when it was known as SproutCore 2 (before AngularJS was known). Both my app and Ember have gone through a very long, very painful maturing process. But it's finally in a really good place. Ember's patterns are the result of months (years really) of spinning, cycling, iterating and collaborating with developers using the framework. Seeing the process of evolution and open collaboration unfold in the community is just as exciting and thrilling as the state of the framework it's self. My advice is to try them both and decide for yourself. The only thing I'd ask is please don't assume one is easier or better than the other with only a few hours of use. If you're planning to build a sizable app, please take the time to evaluate them both thoroughly and decide what's best for you.

scardine 13y ago

My personal experience is the opposite. I tried Ember first. Got excited replicating the sample blog app, but got stuck trying a simple task: show the most recent post by default (see this bug: https://github.com/emberjs/ember.js/issues/1642 https://github.com/emberjs/ember.js/issues/1642). Later I started to trip into namespace clashes - you have to jump a few hoops if your model has a field named "content", "is_new" or "is_deleted" (http://stackoverflow.com/questions/16515900/reserved-atribute-names-in-ember-js-models http://stackoverflow.com/questions/16515900/reserved-atribut...). My general impression is: there is nice ideas here but Ember is too opinionated and has to many magic going on (hard to debug). In contrast, Angular shows better design everywhere. No name clashes, framework methods and attributes use special prefix $ (like python uses double underscores). Everything I got stuck with ember, I was able to achieve elegantly with Angular. I love the eviltrout but this post is lacking a bit of diligence. Angular learning curve is a little steeper but IMHO it is way more finished and well designed than Ember (Ember data has good ideas, they have a cute mascot, and it ends here).

d0m 13y ago

I know it's really not the point on the article, but I wanted to share a quick and dirty solution for a common problem, especially this: >> If you were using jQuery to do this, you’d likely bind a function to the click event on each row. When fired, your function would change the CSS class of the row to highlight it. >> You can’t stop there, though. Your function also has to remove the CSS class from any other rows that were previously selected. That’s a little crazy if you think about it! Changing which item is selected means we have to know everywhere that it’s been represented in our UI. An easy way is just to do: $('<all-row-selector..>').each(<unselect>) .find('<selected-row>').each(<select>)

gphreak 13y ago

I haven't played with EmberJS too much, but read several times that debugging can get pretty nasty (the poster mentioned something about a run-loop if I remember correctly?). Did you encounter similar issues or do you rely mostly on unit tests for debugging?

iknight 13y ago

this just in: Ember.js Fanboi tries AngularJs-- says it sucks because it's not like Ember.js