I had a look. The TLDR version of my response here would be “Why isn’t your teaching method using dependency injection, like the framework you love so much?”
The longer version follows:
I don’t particularly think guides are good for learners. They take the active role and control away from the learner. They bind too many of the implementation details to the things being taught. Granted that that is the “traditiional” model we have in place for education, but I think it’s really smelly, just like imperative non-DI programming. If you’re going to go to the trouble of building something like this guide, it’s definitely good to really think about its usefulness lifetime and what you’re trying to accomplish.
The cookbook approach puts the control back into the learner’s hands because it separates dependencies, and they can mix and match and stitch together bits and pieces… if the cookbook uses an “assembly” model whereby tiny recipes are reused and combined, then you can get to your “guide” at the top level by referencing a lot of composible recipes which the learner can then decide to modify because the person reading the recipes has a deep understanding of all the moving parts contained within. It’s impossible to read the cookbook recipes and work with them without understanding what’s going on because it’s general, not specific.
Stupidly Simple Point for illustration: someone asks “how do I join ‘Happy’ to ‘Birthday’ with a space between?” You can either give them the specific code, or teach them the general category: string concatenation and interpolation. “Teach a man to fish…”, as the old parable goes.
This is my two cents.
It is possible that maybe Ember’s structure might be too complicated to teach in this way, which actually would be a bit of a warning signal for Ember IMHO. As my good old friend Rich says “If you can’t easily and simply write the manual for it, maybe the thing itself is too complicated and needs simplifying.”
You asked for my opinion, so I gave it.