Hacker Newsnew | comments | show | ask | jobs | submit login

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.

Anyway here's a performance comparison: http://jsperf.com/angular-vs-knockout-vs-ember/82

AngularJS does need some work. But so does every framework. Far better to be honest and upfront about your faults so you don't waste your user's time.

-----


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.

1: https://plus.google.com/112439678898563138768/posts/RZKRBiGX...

-----


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

-----


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.

-----


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 can confirm this. Oh boy, can I ever confirm this.

Tom, do you know if anyone has written extensively about tests in Ember? Or is the source still the best go-to?

-----


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.

-----


> Just as an example, Rails is not fully unit tested by any stretch of the imagination

And boy does it show.

-----


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.

https://github.com/collin/taxi/blob/master/src/taxi.coffee#L...

-----


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 think this is true. For example, AngularJS, as far as I'm aware, does not offer a persistence story at all.

It does have angular-resources for restful interfaces. Which are straight forward and easy to use.

I'll let ember ferment.

-----




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: