For some reason, Ember.js has not gained a foothold in the .NET development space. It’s a shame, really. Ember is the ideal client-side framework for modern web applications and after crossing the initial hurdles marrying Ember.js conventions with those of ASP.NET Web AP, it is downright enjoyable to build responsive and fluid web applications that will necessarily scale smoothly as the app grows and the people touching the code-base grows with it.

This is because Ember has been designed from the ground up to be a “framework” for ambitious client-side web applications. That’s unlike Angular. Or React. Or Backbone. Or Knockout.

Angular
vs
Ember

Angular	Ember
2-way data binding	2-way data binding
Flexible	Convention-over-config
Easy to start	A bit of a learning curve
Plain HTML templates	Handlebars templates
Directives 4 custom tags	Components 4 custom tags
API changes dramatically	API changes incrementally
Weak routing	Robust routing

Angular	Ember
Allows logic in templates via “expressions”	No logic allowed in templates
No class inheritance	Inheritance and mixins
HTML-based template	Non-HTML template
Plain HTML templates	Handlebars templates
Uses POJO	Uses Emberized objects
Needs to scan DOM to detect property changes	Uses observers to instantly detect property changes
Roll your own toolset	Ember-CLI

Rails CLI	Ember CI
rails new app	ember new app
rails generate stuff	ember generate stuff
rails server	ember server

Ember and large projects

Angular	Ember
Doing it wrong is easy	Doing it right is easy
Conventions thru code reviews and hope	Conventions through the framework
More boilerplate code	Does the boring stuff 4 you
Trivial to get started but messy for large apps	Harder to start but easier to grow app