AngularJS vs Ember

Tags: #<Tag:0x00007f52bf50ce68> #<Tag:0x00007f52bf50cc38>

#61

Just use `{cache: true}`


#62

Main thing I *really* dislike dislike in Ember is handlebars. The first step would be to kill it - I really can't handle something like that. The syntax, the way you - for example - create inputs, the implicit *crap* (sorry, but that's really how it feels) when you loop ... Plus it's not really readable :(.

Now, to get me used to `.property` and "Ember objects" will be another thing, but certainly possible.


#63

So your main critic is not that you can't share objects in Angular but that the documentation is not that great. Well, Ember's documentation is close to non-existent and its API keeps changing every other day which makes the little documentation there is useless. So I don't think that's a great argument you have here, it's the pot calling the kettle black.

> Most of my post is actually about working towards the "single source of truth" to avoid duplication of objects and sync issues.

Why would you get duplication of objects or sync issues in Angular? Have you ever used it? Sounds like concern trolling to me. Angular gives you plumbing tools like watch so you can do your own stuff, kind of like git gives you powerful tools. This sounds like git vs hg again where clueless hg users pick random git commands and start spreading FUD on it without understanding them. Why do you care so much about Angular? If you love Ember so much, talk to us about Ember, don't talk about something you obviously have no clue about. It only makes you look insecure. Ember people's obsession with criticizing Angular only make them look insecure. Stop obsessing about it. Most Angular people I meet don't care at all about Ember and never mention it.

tl;dr if you love Ember then for the love of God use it and write about it and why it should stand on its own merit but please stop spreading FUD and lies about other projects you obviously know very little about.


#64

The router ticket, which you mentioned is mostly internal refactoring and adding a few features, at least a few apps were upgraded with it and they work just fine (personally I've tested it on Travis and one of my pet projects). Although I agree that the situation was quite bad in 0.9.8 times upgrade-wise, Ember.js now is rather stable, there was only one small breaking change since releasing the RC.


#65

If you want complex dependencies and computed stuff, knockout easily beats both angular and ember. However, my impression is that knockout is otherwise much more limited than ember/angular, so things like routing/persistance will need other plugins/frameworks. Although there are somewhat idiomatic libraries for that stuff, it adds some scary uncertainty.
I wish there was something like Angular but with knockout's models...


#66

Someone earlier mentioned using Angular with Backbone's models, perhaps you could use Angular with Knockout's models?


#67

As long as scope.thing is an object, not a primitive. Which is pretty confusing.


#68

If you don't like $rootScope (and I don't) you can use services and factories to share variables; this seems much cleaner to me.


#69

I have seen similar blog posts arguing how AngularJS is a better framework than Backbone, vice versa, how X is greater than Y, etc.

To me this just proves one thing: most Javascript developers are whiny as hell and generally incapable of adapting beyond the first tool they use.


#70

worst article about angularjs-ember ever...when I sniff the hate in the title I knew than it had been written by a ember guy...why the ember community want gain popularity talking bad and poorly argumented about angularjs??...what is the fear?...I guess this article will be share a lot in the emberjs community...


#71

That's good news indeed. I really think that once 1.0 is officially released and the testing capabilities are improved, dev teams will be more confident about diving into Ember


#72

You could actually let the services that can be injected to any controllers handle model instances. I would assume the only thing a controller needs to do with a model instance is pass it to view which is really the core idea of having a thin controller and fat model(services).


#73

I had the same question when I was coding on backbone and using marionette and handlebar extensively.

I think when it comes to picking up a web framework/library, the simplest one that can get your project out the door the fastest is always the better choice. How many times a framework have been made obsolete because there are better way of doing things. Prototype and scriptaculous was the way to go back in the days, then along came jQuery. Then came mootools, yui, dojotoolkit, backbone, knockout, angular, ember, etc.

It is really hard for a framework to be one-size-fits-all. Web technologies and the underlying platform evolve so fast that what is elegant now could no longer be elegant in a few years, even between versions of the same framework/library.

Community, ease-of-use, learning curve, documentation, along with the team and business factor ultimately decides the framework to choose for a project. If you have a room full of emberjs dev, then it's a no brainer to choose ember as the starting point.


#74

This past week, I published a screencast and article on "Ember.js Tutorial With Rails 4" (http://www.railsonmaui.com/blo.... It builds upon Tom Dale's intro screencast using Rails 4 for persistance. It's gotten some good press, such as from Michael Hartl @railstutorial. It's super simple and includes a git repo of carefully crafted incremental commits that demonstrate using Rails4 and going from the static application to including serialization: https://github.com/justin808/e....


#75

I guess my advice to you would be this. If you're serious about front end development, I advise you to take the time to lean Angular properly. Once you figure out how all the pieces fit together, you won't be able to live without them.


#76

Try emblemjs.com, by an Ember enthusiast who hates Handlebars / raw HTML.


#77

"I think that overall Angular is a hard to learn as Ember, is just that in Ember you have to learn a lot more upfront."

Ember has a longer path to productivity. Whereas you may be doing things "wrong" in Angular initially...you're being somewhat productive while you do it. There's no shortcut to really learning your framework, but at least Angular gives you something to show your boss while you're doing it.


#78

Ember without all the boilerplate. http://jsbin.com/unesel/1/edit.


#79

There is a great alternative to $resource: https://github.com/FineLinePro...
It's basically a base class for your models, which handles serialization/deserialization and networking.


#80

That's not a good idea, because a watch on the root scope to my understanding needs to be re-checked every time anything happens anywhere.
You are probably better off subscribing the scopes of the controllers to changes by exposing RoomService.subscribe($scope)