7 ms·

Migrating from Ember.js to AngularJS

94 points by eranation 14y ago

hakaaaaak 14y ago
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?
- mmahemoff 14y ago
  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.
  - hakaaaaak 14y ago
    Not DHH, but look at the committers: https://github.com/rails-api/rails-api/graphs/contributors https://github.com/rails-api/rails-api/graphs/contributors Carlos and Santiago are active Rails 4 core team members, and Steve K. has risen among the core team ranks as well (not to leave the others out).
    - steveklabnik 14y ago
      Yep! A lot of us care a lot about the JSON API case. Since you're mentioning Rails 4, here's the contributors list for the release: http://contributors.rubyonrails.org/edge/contributors http://contributors.rubyonrails.org/edge/contributors You can see the large overlapping of names there. Also of note, rails-api includes ActiveModel::Serializers, too: https://github.com/rails-api/active_model_serializers/graphs/contributors https://github.com/rails-api/active_model_serializers/graphs... You can also find a lot of big names there, as well.
- steveklabnik 14y ago
  > 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.
  - patrickaljord 14y ago
    Angular can take any kind of json so it doesn't really matter what rails return. It could re-use ember json format just fine.
- patrickaljord 14y ago
  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 https://github.com/patcito/angularjs_scaffold It generates everything for you scaffold style :)
  - hakaaaaak 14y ago
    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.
iheartfisting 14y ago
Yawn
tomdale 14y ago
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.
- hakaaaaak 14y ago
  > 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.
jcampbell1 14y ago
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.
- hakaaaaak 14y ago
  Like this: <ul> <li ng-repeat="name in names">{{name}}</li> <li ng-show="!names.length">There are no names in the list</li> </ul>
  - myhf 14y ago
    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> Either way you end up with an ugly dom.
    - jcampbell1 14y ago
      This is what I was looking for. I gather the framework is allergic to conditionals.
      - hakaaaaak 14y ago
        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.
        jcampbell1 14y ago
        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.
krob 14y ago
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.
- steveklabnik 14y ago
  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.
- tomdale 14y ago
  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.
ebryn 14y ago
Not sure why this is suddenly newsworthy, it's a pretty old and inaccurate blog post.
pzuraq 14y ago
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.
chrixian 14y ago
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.
camus 14y ago
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 https://github.com/Mparaiso/silex-bookmarkly and you can test the app live here : http://markme.alwaysdata.net/application 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.
programminggeek 14y ago
I've actually had a lot of success using Knockout doing some single page apps. It seems Angular is similar?
- taligent 14y ago
  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.
abhishiv 14y ago
How does an angular app deal with layouts and regions? I.e. Landing and Loggedin Layout, both with totally different regions. Marionette prefers Region managers, and I guess ember does it in a similar way. What the angular way of doing it?
craftman 14y ago
Beside the fact this guy is well know for his trolling ability, he is working for Google, which is the company supporting the angular team.
- craftman 14y ago
  My mistake, he actually has left Google: http://beust.com/weblog/2010/05/13/leaving-google/ http://beust.com/weblog/2010/05/13/leaving-google/

94 points by eranation 14y ago

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?

mmahemoff 14y ago
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.
- hakaaaaak 14y ago
  Not DHH, but look at the committers: https://github.com/rails-api/rails-api/graphs/contributors https://github.com/rails-api/rails-api/graphs/contributors Carlos and Santiago are active Rails 4 core team members, and Steve K. has risen among the core team ranks as well (not to leave the others out).
  - steveklabnik 14y ago
    Yep! A lot of us care a lot about the JSON API case. Since you're mentioning Rails 4, here's the contributors list for the release: http://contributors.rubyonrails.org/edge/contributors http://contributors.rubyonrails.org/edge/contributors You can see the large overlapping of names there. Also of note, rails-api includes ActiveModel::Serializers, too: https://github.com/rails-api/active_model_serializers/graphs/contributors https://github.com/rails-api/active_model_serializers/graphs... You can also find a lot of big names there, as well.
steveklabnik 14y ago
> 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.
- patrickaljord 14y ago
  Angular can take any kind of json so it doesn't really matter what rails return. It could re-use ember json format just fine.
patrickaljord 14y ago
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 https://github.com/patcito/angularjs_scaffold It generates everything for you scaffold style :)
- hakaaaaak 14y ago
  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.

iheartfisting 14y ago

Yawn

tomdale 14y ago

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.

hakaaaaak 14y ago
> 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.

jcampbell1 14y ago

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.

hakaaaaak 14y ago
Like this: <ul> <li ng-repeat="name in names">{{name}}</li> <li ng-show="!names.length">There are no names in the list</li> </ul>
- myhf 14y ago
  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> Either way you end up with an ugly dom.
  - jcampbell1 14y ago
    This is what I was looking for. I gather the framework is allergic to conditionals.
    - hakaaaaak 14y ago
      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.
      - jcampbell1 14y ago
        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.

krob 14y ago

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.

steveklabnik 14y ago
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.
tomdale 14y ago
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.

ebryn 14y ago

Not sure why this is suddenly newsworthy, it's a pretty old and inaccurate blog post.

pzuraq 14y ago

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.

chrixian 14y ago

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.

camus 14y ago

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 https://github.com/Mparaiso/silex-bookmarkly and you can test the app live here : http://markme.alwaysdata.net/application 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.

programminggeek 14y ago

I've actually had a lot of success using Knockout doing some single page apps. It seems Angular is similar?

taligent 14y ago
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.

abhishiv 14y ago

How does an angular app deal with layouts and regions? I.e. Landing and Loggedin Layout, both with totally different regions. Marionette prefers Region managers, and I guess ember does it in a similar way. What the angular way of doing it?

craftman 14y ago

Beside the fact this guy is well know for his trolling ability, he is working for Google, which is the company supporting the angular team.

craftman 14y ago
My mistake, he actually has left Google: http://beust.com/weblog/2010/05/13/leaving-google/ http://beust.com/weblog/2010/05/13/leaving-google/