Would be nice if they hadn't closed comments before Peter Wagenet, Yahuda, and the rest from the Ember team could weigh in.
I personally like AngularJS a lot, but I also like Rails. Rails 4 has a rails-api project along side of it, which makes it seem like they are starting to spend more time thinking of Rails as provider for a Javascript front-end. Because of Yahuda's involvement, they have also placed more bets on Ember than Angular the last few years.
I think that Angular secretly hides an affinity for backing services in Node, and this concerns me a little. I think their team needs to either provide examples and support for each major front-end framework and not just rely on volunteers to provide those examples that won't be maintained as Angular changes. Or at least be crystal clear about what is expected of a service so that as little code is required as possible on the Angular end to integrate with it. And the same goes for Ember. What good is a front-end MVC framework that depends on services to exist if you have to spend any time guessing what to use on the service-side?
> Because of Yahuda's involvement, they have also placed more bets on Ember than Angular the last few years.
To be clear: I want rails-api to work well with any JS framework that wants to work well with us. Obviously, Ember is a big target, as conceptually, Rails and Ember are very close. That said, I'm a server-side guy: I don't care what is consuming my JSON, just that I serve the JSON up well. If someone who's big in the Angular world wants to come help make Rails super badass at serving up the JSON Angular wants, I'm all for it.
AngularJS is agnostic when it comes to json format, it can work with whatever rails-api returns so it could re-use even an ember specific format which is I think the rails format. I've written a rails project to work with angular just fine, you can check it out here: https://github.com/patcito/angularjs_scaffold
Nice project, and I like that you can use regular JS with the --language=javascript option. You should make that clear in the README's title which seems to indicate it is CoffeeScript only. Might also want to get your angular dependency through a versioned gem, not jquery-rails, and have (pre) Rails 4 support branch.
Core Rails, however, isn't moving towards embracing the pure fat client model. (DHH has explicitly ruled out doing so.) That makes me a bit less interested in the benefit of any JS library's Rails integration.
I've actually been doing the opposite, migrating my app from Angular to Ember, and I'm very pleased with Ember so far. Angular is an interesting and powerful framework, but it has a lot of gotchas and requires a large amount of boilerplate code for things like object persistence. Learning how $resource and services worked took a lot of time and the documentation is not entirely clear, especially for someone new to javascript frameworks like myself.
It took me about a month and a half to learn the ins and outs of Angular and FuelPHP to get my app to the point it was at. Within a couple of days of experimentation with Ember and Rails, I was at the same point. I'm moving forward MUCH more quickly with deploying the app at this point.
I will admit that the Ember docs are sparse. They're getting better, but occasionally inaccurate or just not there. Still, there is documentation for most things you would want to do, and when there isn't the community is good help.
Both Ember and Angular are great frameworks, but after evaluating both I'm definitely sticking with Ember. Maybe it's just because it makes more sense to me, but I've been able to accomplish a lot more much more quickly.
Proprietary attributes for templating are confusing. So confusing the author put the ng-repeat in the wrong place (I think).
Can someone familiar with angular explain how you would would make a special case '<li>There are no names in the list</li>'? It is obvious to me how to do it with ember, but non-obvious in angular.
Or, if you don't want the "no names" item in the list at all when it's inapplicable, instead of merely hidden:
<div ng-switch="names.length">
<ul ng-switch-when="0">
<li>There are no names in the list.</li>
</ul>
<ul ng-switch-default>
<li ng-repeat="name in names">{{name}}</li>
</ul>
</div>
Behavior can be provided through directives via elements, attributes, css class names, and comments.
It isn't "allergic to conditionals". It just drives the logic elsewhere to keep the presentation layer looking as clean as possible to the developer so that you can either focus on the view (template) or the controller or model.
I think you described exactly what I meant by "allergic to conditionals": a philosophy that conditional logic never belongs in the presentation layer. I didn't intend to imply a value judgement.
It's a judgement call. Some people are wary that going nutty with conditionals in templates could result in littering bits of 'business logic' in them - they prefer to take an all-or-nothing stance and go for nothing.
Personally I like the sort of middle-ground approach that Handlebars [1] has, I'm fine with basic 'truthy/existence' type checks, but will avoid templating languages that allow 'any old code'.
I think this sort of discipline (picking a deliberately restrictive library) is probably more useful for teams than individuals (who are capable of limiting their own conditional crazy).
While there's great feedback here, it's interspersed with information that is either outdated or just flat-out inaccurate.
Overall, Angular is a much more extensive framework than Ember.
I don't think this is true. For example, AngularJS, as far as I'm aware, does not offer a persistence story at all.
Injection and testability.
Ember.js does dependency injection too; we just roll it into our conventions so that new developers don't need to learn what dependency injection is. If you have to learn a ton of comp sci terminology to start learning a framework, they blew it.
Additionally, Ember is fully unit tested (over 6000 unit tests at the moment) and, because of dependency injection, loading up your app in a clean state and testing individual components (models, views and controllers) is easy.
Support for partials and inclusion of templates. This is another thing I really missed with Ember.js, which offers no easy way to break down your HTML templates into smaller, more manageable files.
This is just flat-out inaccurate, and has never been true. Ember has supported breaking up templates since day one.
Documentation. While the Ember.js documentation is fairly large, I found it very unorganized and I often resorted to searching the page to find what I need.
This has been fixed and the response has been overwhelmingly positive. We still have a ton of stuff planned to make it even more friendly for beginners.
Cascading updates are being executed right away.
This is simply not true. In fact, Ember's run loop is what powers many of the nicest features, like deferred DOM updating and binding synchronization. I'm a little bit surprised that other JS frameworks haven't copied the idea, to be honest.
You need to remember to call the setter: object.set('foo', newValue)
I agree that this is not ideal, but the flip side is that frameworks like Angular have to iterate over every bound object when something in a scope has changed, and check it against previously known values to determine if a change has happened. This "dirty checking" can quickly lead to pathological performance issues. We're all about ease-of-use, but not when it turns into a footgun.
As you might be aware, Yehuda Katz is on TC39 (the committee developing the next version of ECMAScript). ES6 supports object proxies, which provide sufficiently rich semantics that we will be able to drop the get/set requirement if you are targeting ES6 browsers. We are ready to add this to Ember as soon as proxies land in popular browsers.
It's actually disappointing how much FUD is in this article. Competition is great, but let's deal with facts.
Well, the fact that you have to come on HN to refute these points means there's a problem. People aren't getting it. This could be a documentation issue, a complexity issue, or a marketing issue. But it's clear there's an issue. Just calling it FUD is disingenuous. It didn't sound like the OP was trying to smear ember.js at all, but instead give some reasons why they moved to angular. The OP doesn't write frameworks and doesn't know the intricacies of every framework that's out there. They presumably know as much as they need to to get shit done and for them angular.js was the more efficient path.
Your response is certainly fair. I just think it's kind of unfortunate that the competition between JS frameworks has heated up so much of late - I've seen a few potshots aimed at particular frameworks in the last year. I'm tempted to wish that devs/maintainers would evolve their frameworks to occupy distinct, separate niches so they wouldn't have to clash head-on, but that's pretty utopian. (Not that such competition hasn't been happening in technology and business from the very beginning.)
Misko Hevery wrote a bit about dirty checking in Angular on this StackOverflow page linked from the submission: http://stackoverflow.com/questions/9682092/databinding-in-an... I think I've also seen a speed comparison/test involving Angular updating (animating) many objects repeatedly. So I'm not sure how much of an issue dirty-checking is in practice.
I'd like to see civil discussion between maintainers of JS MVC frameworks on technical points, but the higher profile the forum, the higher the stakes and the more mindshare there is to gain/lose. In which case I doubt civility would endure. Still, it's better that people hear the cases laid out side-by-side for each framework, which supplements the reviews given by independent bloggers.
The Angular guys are incredibly smart (and good looking) and I am not above stealing their good ideas for Ember. It's great having skilled competitors, because it drives us both to build a better product.
I hope you didn't find any personal attacks in my response. I want to be firm about the fact that the article contained gross inaccuracies.
I welcome criticism of Ember.js; as with any open source project, there's plenty to criticize. I would just like that criticism to be accurate.
That StackOverflow post is hilarious. Who actually justifies slow performance by quoting the limitations of humans ?
Here's a thought for that genius. What if I am showing a dynamic graph with that table .. or I have complex rows .. or animations .. or a trillion other use cases that he can't seem to envisage ? And people on slow computers or mobile devices obviously aren't welcome.
That jsperf wasn't very accurate. The ember run loop holds all changes and waits for the program to execute before writing to the dom, which is great. Angular does this too by default unless you force it with $scope.$digest(); which is what they've got here. I edited it to show what's really happening http://jsperf.com/angular-vs-knockout-vs-ember/85
I don't find that post hilarious but good thing: they no longer need to do the dirty-checking in the latest Chrome[1], which will improve performance significantly.
Thanks Tom, the reason I submitted it here was to get some second opinion and comments. I'm going to try to give both Ember and Angular a few months of run before making a choice, and perhaps, the nice thing is that I don't have to make a choice, time permits, knowing two great frameworks is better than knowing just one. Thanks for clarifying things.
Calling this "FUD" is a bit over the top. Call it inaccurate information if you wish, but "FUD" implies willful intention to deceive, and I really don't see this in the article.
Sadly, these days, "FUD" has become synonym for "this person is saying something I disagree with".
I've used both Ember and Angular (for former more than the latter) and I can say that I agree with your assessment. When I read the article I immediately recognized a bunch of problems.
For example, I find Angular much harder to get started with and understand than Ember. The documentation is more contrived (they give small examples but don't explain why it's done that way or how to expand on the example).
Angular's $resource object is nice as Ember lacks a built-in REST adapter. While Ember-data is still baking, is there any recommended alternative to use for basic REST calls? We're using jQuery right now with Ember.
The documentation is indeed problematic because of the way it is written and the omissions mostly around Ember-Data. I don't see how I could develop a web-app without having detailed info on how the Rest adapter works.. (for example I don't know how to change the default mapping). I suggest the guide is re-written following a step-by-step approach, and maybe a screencast. (just see what the meteor guides did!) If you're a beginner, there's no way on earth you can understand what you need to do in order to build a very basic web-app. And because of the changes in syntax (makes sense, it's a pre) most of the other screencasts or guides or blog posts on the web are outdated. Seems to me, and in order to be 100% fair, that most of these frameworks are quite new, and I guess we need to give the devs the time and the space to do things right. Most of them are not even 1.0 so... Patience!
> This "dirty checking" can quickly lead to pathological performance issues.
I would say that "dirty checking" is a better approach. The code is cleaner and with Object.observe() there are no performance issues even in _edge cases_ with thousands of monitored objects.
> Ember.js does dependency injection too; we just roll it into our conventions so that new developers don't need to learn what dependency injection is. If you have to learn a ton of comp sci terminology to start learning a framework, they blew it.
I've been using Angular for months now and although I already knew what dependency injection was, I didn't have to understand the term to use Angular.
> Additionally, Ember is fully unit tested.
Not to start a flame war, but I'm not sure this is a plus. Full unit coverage is nice for confidence, but can be balls and chains when it comes time to make changes. Just as an example, Rails is not fully unit tested by any stretch of the imagination.
Not to start a flame war, but I'm not sure this is a plus. Full unit coverage is nice for confidence, but can be balls and chains when it comes time to make changes.
Ask any of our pre-1.0 users; they'll assure you that the pace of change was breakneck and certainly not hindered by our unit tests.
I will vouch for this as well. I have still, very conflicted feelings about the improvements in the router and having to rewrite large portions of the app I was (and am still) working on.
@tomdale thank you for the breakneck speed in development, it amazes me how much the project has evolved in the time I've been using it.
I lifted the run loop concept. Damn good one. I don't really spend any time pushing my work for use by others. But I agree it ought to be copied by others.
Run loops make a great partner in crime with requestAnimationFrame.
For what it's worth, the Ember run loop isn't that fires according to a step timer, but rather a loop that runs to completion in response to specific events (mouse click, keyboard press, response from ember-data). If you're talking about requestAnimationFrame there's a good chance you're talking about an entirely different kind of run loop, though I'd be curious to dig into this deeper.
ES6 supports object proxies, which provide sufficiently rich semantics that we will be able to drop the get/set requirement if you are targeting ES6 browsers. We are ready to add this to Ember as soon as proxies land in popular browsers.
Will, both, EmberJS & AngularJS become faster because of these new core-JS features?
I don't get these kinds posts really maybe because I use Ember (most of the time) but I also use Batman and Sencha Touch... I like that there is so much going on with so many projects in this area of development because it's what interests me...
And while I do feel some of your points aren't very accurate they are after all your feelings and observations and I'm not 100% of the time in love with the state of things either... and then I realize--
Ember is in its infancy and because I have faith in Tom and Yahuda, based on their pre-Ember work and the way they go about moving Ember forward now, I just know in my heart that I'm not wasting my time investing in Ember now and for the future.
Thats a far different feeling from what I get when I use Angular.
I couldn't really even get started the last time I used ember.js, their website w/ their examples were all worthless since they kept updating their code-base on literally a daily basis. I think I'm going to really take a serious look at angularJS now.
The API has been frozen and we're very close to our 1.0 release. The advantage of changing APIs frequently before 1.0 is that you get a much better product. I'd love it if you reconsider Ember.js and take another look now that it's stable.
Pre 1.0 this may have been true, but now that it's approaching 1.0, this is happening quite a bit less. Now that the new router has landed, there shouldn't be very many API changes, if I recall correctly.
I used Knockout for my last app and now that I am re-evaluating choices for a new app it's amazing to see how far everything has come.
It seems that AngularJS/EmberJS are more complete frameworks (routing, controllers, data fetching etc) and definitely seems like in either case your app will be more modular and consistent.
However AngularJS seems to have cumbersome documentation (why do I care about tests?) and far less helpful bindings e.g. conditionals. And EmberJS has terrible handling for events e.g. calling a function when clicking a link. However still learning so could be wrong on all parts.
Angular is great but it has some problems , and i dont think one framework is suitable for all use cases.
- For an app that is form/list oriented ( LOB ) angularJS is the best, plays very well with Bootstrap.
- For an app where i need full control over object lifecycle(create custom events , hook into object creating/destruction), when some animated transition between views or states are needed, i would use BackboneJS or EmberJS, these frameworks play well with require-js.
Iadapted a backbone showcase to angularJS , the whole app is opensourced on github : https://github.com/Mparaiso/silex-bookmarkly and you can test the app live here : http://markme.alwaysdata.net/application .
My 2 cents :
- AngularJS can get slow when using repeaters on large object lists , i never had that problem with Backbone or Ember.
- Directives are tricky , and some tricks( $timeout , element.ready , etc ... ) feel like you dont control anything at all.
- since angularJS uses $ to namespace it's variable on models , there is some model corruption happening while loading stuffs from the server.
- i found using requireJS was a bit hard ,and having both AMD and IOC containers is ugly ( but orthogonal ).
- AngularJS doesnt too much stuff under the hood imho.
Overall , AngularJS is one of the best framework out there for html client apps.
I personally like AngularJS a lot, but I also like Rails. Rails 4 has a rails-api project along side of it, which makes it seem like they are starting to spend more time thinking of Rails as provider for a Javascript front-end. Because of Yahuda's involvement, they have also placed more bets on Ember than Angular the last few years.
I think that Angular secretly hides an affinity for backing services in Node, and this concerns me a little. I think their team needs to either provide examples and support for each major front-end framework and not just rely on volunteers to provide those examples that won't be maintained as Angular changes. Or at least be crystal clear about what is expected of a service so that as little code is required as possible on the Angular end to integrate with it. And the same goes for Ember. What good is a front-end MVC framework that depends on services to exist if you have to spend any time guessing what to use on the service-side?