AngularJS vs Ember

Tags: #<Tag:0x00007f52c32a4dc0> #<Tag:0x00007f52c32a49b0>


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?


Return a promise with $q. In templates, {{promises}} are treated the same way as regular values, automatically rendered when resolved. $q also finally has .always() (not needed in this case)


If by "rolling your own solution" you mean "multiple options to solve the problem", then yes. Depending on the object in question, you can just substantiate and, if necessary, cache it in the singleton service to be handed back to any controller that calls it. You can also attach it to a root controller to be accessed by any child controllers. We went a third direction and require the user object into our app from our "outside of Angular" authentication service and inject it into the controllers.

I also prefer the ability to treat models as casually or as seriously as they need to be. $scope.showModal is already bound and ready to use as is..even if it doesn't exist. The view just interprets it as false, so my ng-show="showModal" doesn't show the element until I set the value to true. Do I really need the overhead of an object class for showModal?


Cool, thanks!

Would that also let me have a loading image in the meantime which got replaced by the loaded image? (I realize I'm changing the goalposts here, but it's not because I'm trying to make one system or the other look bad, it's because I'm learning more about the frameworks and exploring their boundries…)


This is a javascript language feature, and will be the case in any weakly typed language.


I would say this is explicitly not a language feature - prototypal inheritance works on both object and primitive properties. I also have no idea how weak or strong typing (which are terms that don't really have accepted definitions) plays into this. But it's not like it's impossible to work around.


If you use a service for that, the user is just one function call away, so why bothering.


Fundamentally I think the problem implicit in this article is that is assumes that Angular is 100% responsible for solving all possible emergent problems in web development. If you take that as the standard, you end up with a much more bloated, closed system with a much larger cost to buy in.

If you don't like the implications of the non-model that is angular primitives, there are a lot of modeling code available out there that you can use to change the profile of the stores in your code.

In general my experience has been that when a system takes on too much of a given challenge as a self contained unit, it accumulates baggage that you don't want or need for any particular task, because the system, thinking that you MIGHT need a particular bundle of solutions, weighs you down with an overwhelming number of requisite practices.

There are practices that a larger-scaled project might need to take on that a smaller one does not need. It is better to let these solutions evolve as add-ons to solve particular use cases than to assume that each and every project needs a complex dynamic model system and to saddle every project in a framework with those sort of solutions.


Thanks for providing some more detail.

What you are talking about is absolutely possible in Angular without having to re-lookup the user object. We share pointers to objects between controllers all the time using Services. $rootScope is just a special type of Service. So you can store the user on the $scope or in a Service that is injected into both controllers.

Angular even takes your 'single source of truth' paradigm one step further with Directives. You can pass pointers to objects into directives exactly like linkTo. Directives are reusable DOM elements with their own logic, their own controllers (they can share controllers with other directives), their own templates. So any time i want to render a user's profile image for example, I just use my "profile-image" directive and pass in the user, `<profile-image user="resolvedUser">`</profile-image>


can you elaborate on what templating framework you use then? would be interesting to know what you find better than handlebars. I only use handlebars because I liked it's integration and it works for me, but if you know better i'd like to know what and why :) ... never to old to learn am I :)


> I observed a pattern as those developers started to build out their applications. Some were used to Rails’ large toolbox of convenience functions so they included ActiveSupport. Some needed ORMs so they included ActiveRecord. At that point, what was the advantage of Sinatra? You were basically running a Rails application.

I have seen the same thing happen as well. The problem is that developers have been brainwashed to use "The Rails Way" to solve every problem, even without realizing it. Sinatra is meant for small, modular components, while rails promotes large monolithic apps.

I think AngularJS is cool because it offers a little more than a barebones tool like Sinatra, but manages to stay modular so you can still divide your functionality into small, modular Angular apps.

As for EmberJS, I have been following it from its origins as Sproutcore, but its complexity has always been a major barrier...


You make it very clear that you agree with Ember's opinions. Congratulations. However, they are called opinions because they are not, in fact, facts. "build an app properly" can mean many different things, all depending on the application. I never could use Rails. My opinions differed. Sinatra was far more aligned to my purposes, and I didn't use any of the Action* stuff either. (I also only built really small apps.)
You noted in your article that Ember is opinionated, and several others have as well. If you would like to point out why Ember's opinions are misnamed and are in fact the One, True Way, then I would be interested to read that post. Otherwise, this is all troll fodder.
"I'm not saying Angular will never be good." -> Angular isn't good now.
"Ember encourages better practices..." -> Such as? Bloat? Required use of non-native JavaScript features?


I mainly use Jade/HAML, but something like ejs(/eco) would be totally fine.

EmblemJS looks *really* cool (a bit too much, I don't like the "implicit attributes" part). Maybe a bit slow (having to include emblem and handlebars is .. erm) but I'm definitely considering trying ember now :). Now, to finish my exams first...


Ah, I misunderstood which comment you were replying to, I thought you were lamenting the fact that that simply could be the case (hence weak typing).

That said, I am still not sure exactly what you are referring to - primitive scope properties will be inherited by child scopes but will be cloned, unlike objects which are referenced. These properties are still available in the child, but changes will not be reflected on the parent scope (which is the expected behavior with javascript inheritance).

This JSFiddle shows that effect with raw JS:
The second paragraph of the Angular doc on scopes talks about the problems with trying to '2-way bind' primitives:

Can you give a code example where angular will not behave in this way? If so, sounds like they might have a bug.

Grumpy Semantics Side Note: In spite of its generic meaninglessness, if someone says 'Weak Typing' and 'JavaScript' In the same sentence, you know what they are talking about.


I have used Ember for 3 months and Angular for 12. I even have an Ember t-shirt, and look damn hot in it. I appreciate that you took the time to write a sincere comparison, but I think these conclusions miss the boat. "In AngularJS, functions have to be specifically demarcated. This can cause maintainability nightmares down the road." A couple of parentheses are a maintainability nightmare? That gets the FUD of the Day award. Maybe you read lots about about Angular and played with it for a few weeks, but still have ended up making rationalistic projections about what MIGHT go wrong if you use it on a big project. I use it in a big project, your projections do not align with our experience. In a way there is little difference between the frameworks in usage ... EXCEPT that Angular is much more intuitive and easier to use, as you noticed. By the way, your model should be handled by application logic code, I see no great reason to get a framework involved in that except for the purpose of over-engineering (many examples of this in other frameworks, many horror stories from software engineers). Which is my takeaway of Ember: it will tend to push people in the direction of over-engineering.


Just a random update a few days later, but Angular definitely has some pretty poor documentation for non-basic features as well. The one that comes to mind is their $http service which feels like a mess which involved having to read the source to understand rather than the docs which is kind of unreasonable.

I'm not sure why they didn't just declare a dependency on jQuery and use the very robust, documented, and well understood API that comes with it rather than inventing their own. Having an explicit dependency on jQuery would have reduced their code base as well - no need to support "jqLite" and the rat's nest of edge cases that come with supporting a DOM library. That's one decision that the Ember team definitely made the right move on - they don't seem interested in re-inventing the wheel.


"I do disagree that computed properties are not common; in an Ember application you end up using them everywhere!" is no different than a C programmer arguing against Java: "I do disagree that pointers are not needed; in a C program you end up using them everywhere!"

Speaking of Java, I wrote a small REST service using functional style. I showed it to another Java programmer. He said "That's terrible! It's not object oriented."

Who's more intelligent, you or a male weaver bird? I asked the weaver bird. "I am totally more smart that EvilTrout. He has no concept of a proper nest. He simply couldn't attract a mate with his weaving skills." The late Douglas Adams put best. “For instance, on the planet Earth, man had always assumed that he was more intelligent than dolphins because he had achieved so much—the wheel, New York, wars and so on—whilst all the dolphins had ever done was muck about in the water having a good time. But conversely, the dolphins had always believed that they were far more intelligent than man—for precisely the same reasons.”

I'm not that concerned about the accuracy of your Angular facts. I'm more concerned with your claims that Angular sucks as an Ember substitute. Of course it does. And conversely, Ember sucks as an Angular substitute. You know Ember so well that it's become the standard to measure everything else. Until you lose your heavy Ember accent when speaking Angular, you just won't hit the impartial sweet spot to truly advise others between the two approaches.

You value a single idiomatic approach and a framework to enforce it. That's not a value I share. I prefer JavaScript over Java precisely because I have more flexibility in how I can express my thoughts. I prefer freedom and flexibility over restrictions. I understand your value. Please understand that it's not a universal standard.

I find an easy trap to fall into is the false goal. Goals for a web app should not be OO or MVC or idiomatic or avoiding primitives. Those are all academic jargon. Those TEND to be good hueristics to help you get your goals, but no business succeeded because they picked a language or framework that was more objected oriented.


I don't know of open source Angular projects. In our project we keep one copy of a model in a service. Multiple controllers inject the same service to access the singleton model. Controllers can then create "view models" off of the models to bind to, if needed (to implement edit-then-cancel functionality). Or often we slap the model, or parts of it, directly onto the $scope, or behind $scope functions, to bind it in the template. When it works it works and it's damn easy.

I do think there is a valid point that devs without much software engineering skill could abuse the $scope pattern. I was surprised by the recommendations above of putting stuff right on the $rootScope to share it, that would definitely not scale into anything but a big pile of spaghetti. ... But devs who aren't strong at organizing maintainable code may have trouble using Ember successfully as well. Really I think an ambitious app can be built well with either framework IF you have a dev team who can ... build an ambitious app well. :-)


And it is worth to mention, that $watch is not the only one alternative. I'm using EventEmitter instead, and i'm finding it veery handy, since i don't expect (and i don't want) that framework decides for me, which variables are computed by some internal magic. This is the reason why i love angular... Most of it is just a raw javascript, but as markrendle said, everything here is on early stages and i saw people that are using angular wrong in soooo many ways... Framework is not something that should do your job for You, it should just help to do your job in best possible way, espacially in large scale projects.


And ;-))))