Live data from Hacker News

AngularJS versus Ember

eviltrout.com

81–90 of 163 posts

Re: AngularJS versus Ember

#81

> 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 wri…

Yehuda Katz is on TC39, I'm pretty sure that Ember will be well-posed to take advantage of innovations in JavaScript as they happen. You didn't really rebut anything in his post, just asserted that Angular is 'forward-looking.' EvilTrout makes very specific claims, as someone quite familiar with Angular, you're well-poised to give a real answer, not just chest-puffing.

This may be true, but still Ember forces you to use uses get() and set() while in angular you can just use plain old javascript objects. Basically Angular does dirty checking to keep track of changes while Ember knows of your changes because you are using get() and set()(1).

In my opinion this sucks. I love being able to use plain old javascript objects in Angular. Not having to extend every object with ember.observable is a big win for me. When O.o lands Angular will be just as fast (if not faster) as Ember but without the need to instantiate new Ember objects, and always use get() and set() on them.

Of course Ember could change its API in the future, but Angular won't need an API change because its already using plain old javascript objects.

1: http://emberjs.com/api/classes/Ember.Observable.html

Re: AngularJS versus Ember

#82

> 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 wri…

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.

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.

Re: AngularJS versus Ember

#83
post #79
post #75

Earlier quoted context omitted.

I'm definitely not qualified to provide an opinion. My short summary: Backbone was tiring for me and my partner with all the files and code to set up each view. I also never liked putting templates in script tags -- it just felt dirty. We see Ember and Angular as similar (how do you pick which language you like?), and we only picked one for atheistic reasons (data-binding in HTML) in our current project. Since I have…

I also find data-binding in HTML to be aesthetically pleasing. We use knockout, which has served us well but feels like we'd rather be an Angular. What are you working on? I did a quick trawl of your history but didn't see any mention.

(this post is crazy to watch -- so many strong opinions!)

If you're like me, then you'd want to see some examples of craftsmanship to weigh the value of different opinions. Unfortunately, I can't provide links to these example works due to a very strict NDA (we did the work on behalf of a couple brand names, and ironically they wanted privacy). The projects definitely fell into the category of 'shit crud app' :)

Re: AngularJS versus Ember

#84
post #11

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

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.

Re: AngularJS versus Ember

#85
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.

Re: AngularJS versus Ember

#86
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?

Re: AngularJS versus Ember

#87
post #76
post #13

As a gentle reminder, Fred Brooks said "there are no silver bullets" in software ( 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 s…

What a cop-out. I am pretty sure you prefer Angular but are just too pussy to say it. Maybe you think people will think less of you for preferring the framework that is less complex. I assumed 'not even close' would mean this guy would be siding with AngularJS. Its sad but many people have the mistaken belief that programming languages and frameworks that are harder to use are more sophisticated and therefore better.…

Please turn down the dial a little bit. Calling a stranger a pussy may be the norm on the internet at large, but it's not appropriate here.

Re: AngularJS versus Ember

#88
post #13

As a gentle reminder, Fred Brooks said "there are no silver bullets" in software ( 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 s…

> 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 d…

I've worked with both frameworks. You're too quick to judge Angular. Secondly, I suggest you watch Angular 1.2 & beyond:

http://www.youtube.com/watch?v=W13qDdJDHp8&feature=c4-overvi...

For instance, scope will be optional in the future, not only that but the roadmap for Angular Next is very impressive (see around the 44:40 mark).

---

Angular is accelerating; it has more stars/watchers/staff than Ember. Embers' core devs barely have time for pull requests. To the best of my knowledge Ember has no full-time staffers. Angular is fully staffed by Google. Both take contribution from the community.

Re: AngularJS versus Ember

#89
post #35

Earlier quoted context omitted.

> 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 d…

I don't think your view on this is correct. Having the server contain the "single true source" is important for many reasons, most of them being the main benefits of the web in the first place - automatic backups of everything, automatic sync of everything, etc. And if you're backing up everything to the server anyway (e.g. every action requires a REST call to the server), then the server is in any case acting as the…

That's not a valid assumption for truly ambitious web applications.

For example, I have an Ember application running on both mobile and desktop that gives the user complete read/write access to their data even when the network goes down. When they get a connection again, everything synchronizes automatically.

This is an important requirement for us, and once we implemented it we realized that is has very useful side benefits as well: the entire application feels dramatically faster, because you're very rarely waiting for the server. Changes take effect instantly.

It also makes our backend infrastructure simpler. First, because we can take it down for a bit and nobody will even notice. Second, because once you have a true distributed synchronization algorithm running, adding another redundant server is no more complicated than adding another client. They're actually quite symmetric in many respects, running the same codebase.

Re: AngularJS versus Ember

#90

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.

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.

Post reply on HN