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.
AngularJS versus Ember
21–30 of 163 posts
Re: AngularJS versus Ember
#22As 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…
This is something else.
I'd like to call it, "the appeal to the bold new future fallacy, with sensationalist titles"
Is X trying to change the paradigm ? No. Use Y.
Is Y trying to change the paradigm ? Yes. Use Y
Some dumb geeks just can't handle "worse is better" !
Re: AngularJS versus Ember
#23As 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 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!
Re: AngularJS versus Ember
#24Choosing 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,…
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.)
"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!
Re: AngularJS versus Ember
#25Is 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 kn…
we've built a rock solid architecture for complex AngularJS apps here: brandid.github.io/parse-angular-demo/
Re: AngularJS versus Ember
#26Is 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 kn…
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.
Re: AngularJS versus Ember
#27A 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.
very true
Re: AngularJS versus Ember
#28As 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…
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.
Re: AngularJS versus Ember
#29This 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/
"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
Re: AngularJS versus Ember
#30Coming 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.
From what I read, the Ember model looks way closer to what KnockoutJS is providing.