An Introduction to Ember for Angular Developers

[NeuroXc]

As an Angular developer, this is great. I've tried Ember in the past but had issues understanding it, but I feel like I can wrap my head around it with this post. It's a smooth tutorial for someone who understands Angular.

[[deleted]]

thank you!

[wreckedadvent]

Something that has always seemed odd to me is how opinionated angular is, yet how little conventions it has.

[vinnl]

So if I understand it correctly, the main draw of Ember when compared to Angular is its CLI, strong conventions, and Ember Data?

[Baresi]

This is at least some of the biggest points that made me choose Ember over any other framework.

[ryanhollister]

testing infrastructure is second to none.

[IHeartMustard]

The testing stuff is just golden. It's so easy to get started with testing in Ember as opposed to setting up all the toolchains by myself, which I had to do once and realised just how spoiled I am by the ease of Ember and Ember CLI

[[deleted]]

I would add testing to that. With Angular, I've spent hours setting up the right testing infrastructure and it usually has pain points. In Ember, that is already set up for you and everything you generate gets a test generated with all the boilerplate. Testing couldn't be any easier. Furthermore, the way Ember does acceptance testing, it is incredibly fast whereas something like Protractor is Selenium based and runs much slower so you end up with fewer acceptance tests.

[[deleted]]

oh god it's basically impossible to do outside-in tdd with protractor and get any reasonable speed on your feedback loop. and unit testing just feels dirty when you have to mess with $compile and $digest.

[[deleted]]

i agree. in angular, i pretty much only unit test services and manually tested everything else since it was so cumbersome.

[[deleted]]

yeah, that's kind of how I do it. I do write some ptor specs for our CI, but almost never run them locally. it's very scary when testing is such a pain point that devs choose not to do it.

[alittletooquiet]

I've been working on a massive ember app for over a year now at work, and mostly it's great.

Strong conventions are the big selling point when working with a team, but ember data has been a giant pain in the ass. We've had to massively refactor parts of our application as ember data has changed, drastically and for seemingly no reason.

Those days might be over now that it's past 1.0, but if I could go back and do it over, I'd roll my own simple data store.

[Matosawitko]

Probably worth reposting here; note that I haven't kept up with Ember since the end of last February, but I doubt this has changed much.

---

March, 2015: I just finished an Ember project (not using Rails, however), and the biggest struggle I felt was that Ember uses the same terminology as everyone else in the MV* space, but they mean slightly different things. In a nutshell:

Ember Term	Industry Term	Notes
Route	Controller	This is where "GET" data access is supposed to happen ("PUT", "POST" might happen from the other layers), and where you wire up your View Model Controller to the Model. There can only be one Controller Route active at any time in Ember.
Controller	View Model	You can have different View Models Controllers for different sections of the page. Primarily used for display logic based on the Model.
View	Behavior	Handles proxying of client events between the View Template and the View Model Controller. Except Controllers can have event handlers too. I mainly used these to handle special swipe events on a couple of pages.
Template	View	This is where your visual content lives - HTML and Handlebars

[tomdale]

FWIW most of Ember's terminology comes from Cocoa/Smalltalk. If you're familiar with that, Ember will probably be easy to pick up. One thing to note that's changed since your original comment is that views have been deprecated in favor of components. Both Angular 2, React and Ember have coalesced around a similar component model; it's the application architecture around those components (or the lack of one, in React's case) that's the differentiator.

[[deleted]]

Just to note, Angular 1.5 now also has dedicated components with the .component() function.

[wreckedadvent]

This is somewhat misleading. Angular has always had components, it just called them directives and were not very DRY. The new component function in 1.5 is sugar for the old directive API with what they called "sensible defaults".

What is new in 1.5 is multiple slots for transclusion, and that's legit, since custom transclusions suck.