
AngularJS versus Ember - EvilTrout
http://eviltrout.com/2013/06/15/ember-vs-angular-its-not-even-close.html
======
yajoe
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.

~~~
EvilTrout
> 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!

~~~
btilly
_My question is then: why are people purposely choosing not to use the
advantages of client side MVC code?_

You can't trust the client. Therefore a good part of the logic MUST be built
on the server side. When you've had to build that logic once, building it
again on the client side is a maintainability problem of exactly the same kind
that you decry with Angular.js. Except worse, because frequently the client
and server are different languages and so are harder to keep in sync.

~~~
EvilTrout
I'm mostly talking about sharing data in this post. If you have a user object
from the server, why would you need to retrieve it again as you navigate
around? It's already been given to you from the server.

Secondly, client and server interfaces are not as symmetric as you indicate.
Discourse has much more validation logic on the server than the client.

We generally "assume success", because the vast majority of requests do go
through correctly. So if you submit a spam post for example, we'll show it in
the client side view right away, but once the server asynchronously replies a
failure, we'll display an error message and remove it. This can be jarring in
the case of a failure as you'll see something appear then go away, but the
vast majority of the time it doesn't happen.

The client side interface should do what it does best - display stuff quickly
and avoid server round trips as much as possible.

~~~
SolarUpNote
What you're saying is interesting - I just want to make sure I'm understanding
correctly.

So, the app functions on its own in the client, and only checks-in
periodically with the server to see if anything is not valid?

(As opposed to sending a request to the server for every change.)

So for example: when I submit a comment, it doesn't go to the server right
away. It immediately displays successfully in my browser, and could be
submitted to the server 2 seconds from now, or something?

~~~
EvilTrout
It's not as periodic as that.

Ajax by definition is asynchronous. When you submit a post, the Ajax request
is fired right away. But we don't wait for a response before showing the post
in the stream (success case). We show it right away.

Then WHEN we receive a reply, we check the error status and if it was success,
do nothing. If it failed, we revert the UI to the previous state. This is
really easy with a client side MVC framework.

The downside is the failure case can be disorienting, as something will appear
and then disappear. But the vast majority of requests, say, 99% never fail so
the user so we optimize for that case.

------
olalonde
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.

~~~
ef4
This is an important point, but I see it differently.

Want to become a truly great developer? A real one-percenter?

Get in the habit of diving into other people's big, scary codebases when you
hit a bug. Learn how things work, learn why they're breaking, and fix it.

Who has time for that? That's part of my point. Many people won't invest in
their own capabilities in this way. But once you do, you get dramatically
faster at it. Soon it's no big deal to jump into the guts of Rails or Ember
and bend them to your will.

This is also the best way to truly be able to judge the quality and usefulness
of competing projects. Instead of following the internet popularity contest,
you can go to the source and see pretty quick how good the ideas really are.

~~~
kibibu
I've been referring to the Django source nearly as much as the docs lately,
and it's actually very pleasant to "unmask the magician", as it were.

~~~
steveklabnik
As someone with commit to Rails, it also makes you have a totally different
perspective on 'magic.' You end up seeing how things work, and it no longer
feels magical. It's just code.

Rejecting 'magic' and just reading the code definitely helped me to get to
another level of coding.

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

~~~
camus
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
Oh please, "template-engines-thingies" don't even come close to the concept of
directives

------
ldn_tech_exec1
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
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
...fair.

What's your take on points #1, #2, #3 and #5?

~~~
EvilTrout
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.

~~~
ldn_tech_exec1
Umm.. nothing in #1, #2, #3 or #5 requires any extra code.

If you're argument is about what Ember 'encourages' vs what AngularJS
'encourages', that is your opinion and not a weakness in the framework.

I think it's great you've taken some time to learn AngularJS, and I think if
you dig a little deeper you will be pleasantly surprised with what you find.

------
blissofbeing
> 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
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.

~~~
blissofbeing
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.

------
scardine
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-
atribut...](http://stackoverflow.com/questions/16515900/reserved-atribute-
names-in-ember-js-models)). 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).

------
pron
_...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
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
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
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)

~~~
prollyignored
Aha !

Now in,

    
    
        while m+i is less than the length of S, do:
            if W[i] = S[m + i],
                if i equals the (length of W)-1,
                    return m
                let i ← i + 1
                ....
    

How would I implement the `return m` part ?

~~~
dizzystar
There is no explicit return value because the functions aren't functions: they
are values, thus the result of the algorithm is bound to the value that is
bound to the function.

When you write:

(defn square [x]

    
    
         (* x x))
    

You are really writing:

(def square

    
    
        (fn [x]
    
            (* x x)))
    

and x * x is bound to the value of square. There would be no logical reason to
have an explicit return value here.

------
rubiquity
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
> 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.

------
wesleyworkman
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.

------
moomin
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.

~~~
ww520
I use Knockout, too, and it has served me well. All the computed methods and
model change detection are trivial in Knockout.

~~~
kmkemp
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.

~~~
moomin
I agree, Angular has the right implementation. It's just not clear that it
needs quite so much stuff to solve one problem. And if it isn't solving one
problem, why not?

~~~
Guillaume86
Angular team is going to split the Core into several small modules, hopefully
a data-binding module will be available to replace knockout and do nothing
more ;)

~~~
KurtMueller
So what you're saying is they're trying to knockout knockout?

------
a_c_m
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-t...](http://beust.com/weblog/2012/12/29/migrating-from-ember-js-to-
angularjs/)

------
tracker1
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
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.

------
andrzejkrzywda
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-
group...](http://meta.discourse.org/t/digest-mail-ignores-secure-groups/7288)
[http://meta.discourse.org/t/non-authenticated-users-see-
priv...](http://meta.discourse.org/t/non-authenticated-users-see-private-
topics-in-404-page-was-mobile-view/7419)

~~~
EvilTrout
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
"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!

------
edanm
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.

------
wc-
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
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
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.

------
SolarUpNote
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
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.

------
ctvo
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
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
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
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.

------
d0m
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>)

------
rgo
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.

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

------
saurabhnanda
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
It won't be left behind, it's from Google.

~~~
nailer
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)

------
randomguy7788
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.

------
gkop
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
> 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
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.

------
danso
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?

~~~
camus
> 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
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.

------
vectorpush
_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
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
_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).

------
kriswill
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
From what I read, the Ember model looks way closer to what KnockoutJS is
providing.

------
jv22222
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
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?

------
gphreak
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?

------
electrotype
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!

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

~~~
bluepnume
It's 55kb gzipped. Angular is 30kb. Does that 25kb make all the difference?

~~~
sintaxi
Yes. The footprint matters. All that JS has to be parsed by the browser. The
difference is not negligible.

------
ohwp
_" 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.

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

------
camus
> 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.

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

