As with most new js frameworks, the first thing I'd like to see in the docs is a comparison with similar popular frameworks, and a brief description of what makes this one different and better.
We don't need comparisons. We need to see evolution. It's like the transitional species problem. We can always discover a startling fossil and [compare] them with the rest of our findings, but I believe we need to get better at understanding if we are seeing something [new].
There is a clear initiative to most gracefully integrate/weave/combine Script Loaders and MV* frameworks for On-Demand Resources that give thoughtful memory/state management. These framework developers should explain how they are achieving this with their contributions, and why we should care.
The build system brings more consistency to the application: dev or prod mode, code optimization, resources management, logging, caching, etc.
The concepts inherited from Backbone are also evolved: - models are not just key->value (models in Hr could be really complex) - joints between models - views can used templates and sub-components - better events management for classes - and a lot more
(Sorry for my english, I'm french)
This is to say that hr.js seems to be offering more out-of-the-box solutions and flexibility than Marionette/Chaplin/etc, while being a lot cleaner and more straightforward as well. Good on you hr.js :)
I had a 3,000 line CoffeeScript file with 5-6 Backbone Models, matching Collections, things called "MicroViews" and "AdHocViews". It got heavy really fast.
Thankfully I am a vim'er. But I'm not sure if my use of vim engendered this or was the effect of all of Backbone's lack of modularity. Then again, there's the ultimate question of: What is a Module? (Is it material JS files or is it what is loved into the memory states of the Browser Application?)
Of course, that doesn't address all the other incidental complexity you inevitably have to deal with when using Marionette.