Ok, now I see what you meant. So basically we don't want to limit audience of that idea to just CoffeeScripters. Also: maybe we'll switch to JS some day - if community show the need.
So the switching your mindset to hexagonal.js is quite hard at the beginning and I think it's the most time consuming part. Then you are very productive - gameboxed.com developed > 20 small and large apps using hexagonal.js last year.
To be honest most of project I developed with hexagonal.js have Rails as a backend and it's really powerful with sprockets on board. So give it a try, maybe in toy project.
Good question. In hexagonal.js approach client side is full app - so there's model part (use case is part of model), glue ~ controller and views are GUI and other adapters.
I scoped my blog just to unit tests, because it's short note rather than article. DI can be useful on integration and acceptance level too - for simple apps you should be able to configure whole app or its parts as easy as you run it on production. Without DI you have to do some magic with class / module constants, which can populate on other parts.
I think the basic difference between library and framework is that if you use framework it's responsible for bootstrap of your application, and library does not.
But also framework drives structure of result codebase - filenames convention, directory structure, maybe way you implement your features.
I really try to find which part of this post could alienate any of our customers and I can't. I just described why we decided not to use ORM and I find it quite interesting for others - they can disagree, show why I'm wrong. They're (and also you) smart guys, know what to choose and if ideas are worth to apply.