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
AngularJS versus Ember
41–50 of 163 posts
Re: AngularJS versus Ember
#42> 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.
Re: AngularJS versus Ember
#43To 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...
Re: AngularJS versus Ember
#44As 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…
> 10k+ apps on each Ember, Angular, and Backbone
Have you written about them? I haven't come across anyone who has enough experience with more than one of them to comment broadly.
Re: AngularJS versus Ember
#45I 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.
Re: AngularJS versus Ember
#46> 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.
Re: AngularJS versus Ember
#47A 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!
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.
Re: AngularJS versus Ember
#48Earlier quoted context omitted.
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 serv…
Thank you for the excellent and succinct answer! > My question is then: why are people purposely choosing not to use the advantages of client side MVC code? I didn't understand this question (it seemed too obvious to me and felt like a bait to get into a broader discussion). In both Ember and Angular apps you still have a 'model' that is stored outside of the DOM, the only difference is how the model is works, which…
This is a pretty ridiculous conspiracy theory. (Is it a conspiracy if there's only one actor?)
To spell out the question in a different way:
I have an object that represents some kind of object, like a User, for example. On every page, I display the user's name.
With the 'long lived object' strategy, I fetch the User on the first page load, and display it. The JS object then sticks around, and as I navigate, the same User object in memory is used on each 'page' to put in the username. No difference.
With the 'mostly server side' strategy, I fetch the User on the first page load and display it. When I navigate around, I then re-fetch the User on every single 'page'.
I am not familiar enough with the details of Angular (and, frankly, Ember, which I'm still new to) to tell you if this maps 1-1 with the way that they work, but it's the two different approaches in a general sense.
Re: AngularJS versus Ember
#49Coming 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.
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.
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...
Re: AngularJS versus Ember
#50Earlier 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…
What we're really talking about here is an advanced form of caching. "Long lived objects" doesn't mean you do no validation, or that you don't hit the server to save something permanently.
The point is that due to the difference in architecture between an SPA and a more traditional all-server-side app, there's no reason to hit the server every single time. Isn't this the advantage of writing so much JavaScript? If you're going to make a bunch of requests on every page, why not just ditch the JavaScript and write it all server side?