ember vs angular, and doing the thing right vs doing the right thing

I'm looking for the best way for me to quickly become proficient in ember.js - with the additional caveat that I'd like to up-to-date. One of the reasons we picked ember over angular is that Angular seems to be in a weird 2-on-the-horizon state, but ember has some of that same issue (but the changes in syntax and best practices seem less radical.)

Currently a good bet (though I'm just starting with it) is https://www.ludu.co/course/ember/ - its approach of starting with a single, meat-y "real world" style example seems really promising for my learning style.

I liked this quote, about its use of HTMLBars (a descendent of Handlebars) for templating:

One of the advantages of using a real template engine instead of just adding "magic attributes" to your HTML elements (like in Angular) is that there's a clear distinction between the markup and the logic in your templates.

Man! That is kind of central for me, something that subconsciously really bugged me about angular.

A lot of it comes from my strength/weakness of my long history in web development...  I subconsciously map modern in-browser coding (with a library like jQuery or in some framework) to what used to happen on the server, while HTML rendering has always been HTML rendering. Angular's slamming them together as one thing never felt right to me -- similarly, JSP's "everything is a tag" had a similar semantic confusion!

But some engineers love the consistency of "we can do everything in xhtml-compliant tags". I suspect that these are the people who think in nouns and capabilities, vs other folks like me who think in terms of verbs and interactions.

Speaking of my strength/weakness routed in history: one thing about the "Libraries vs Frameworks" debate. I've done many, many projects over the years, but the bulk of them haven small scale, quick hit things. In most ways these are more forgiving than larger scale projects that have to be worked on by many people over a long term. I've learned from experience that coding libraries (such as jQuery) can "scale up" to handle more complex projects, and if you're thoughtful about it it doesn't even have to get too messy. I'm not yet convinced of the reverse however. When Ember pulls down 25,000 files - literally -  to get to a proper "Hello,World" environment, it seems like it will never be great for things simpler than its sweet spot of power CRUD-ish apps.

A final confession / point to work on: all these years and I haven't ever grown to love unit tests. I like integration tests and End to End and the like, but unit tests, meh... especially when written by the developer who wrote the code itself. (Like I wrote a year ago It's really hard to get someone to find something they don't want to find!) Here's a new variation on the the thought: it's generally not so difficult to write code to a spec. The hard part is getting that spec right for all those hidden and implied edge cases, and not realizing what assumptions you're making - in my experience, that's where bugs actually happen. But all units test do is test an implementation against the spec! They can demonstrate you're doing the thing right, but don't have much to say about whether you're doing the right thing...

Still, unit tests are an excellent way of talking to the future, telling them what the spec is, and permitting more freedom for fearless refactoring....