It feels a lot like Backbone.js. However when building a large application with Backbone, by time lots of things need to be added on top of it: i18n, caching, paged loading of collections, queues...<p>Looks like hr.js includes most of these things out of the box and is built in a modular way with AMD modules (no more framework in one single file like Backbone). It looks like an amazing piece of work.<p>That being said, I have a couple of questions.<p>1) Why was this not build on top of Backbone.js? This way it could benefit of a battle tested codebase used in many production systems and the Backbone apps out there could immediately benefit from the added features by just adding a few new modules (instead of rewriting to use this framework). Many core parts look very similar to Backbone, at least Models, Views and Router/History, with useful extensions on top.<p>2) Why is the build tool not a separate project? While the framework looks useful, I don't want to switch to a new toolchain to be able to use it. Many people already have some preferred way of building their apps, be it Grunt, GNU Make, r.js optimizer, a combination of those or something different. A specialized build tool can add value to the framework (e.g. sensible defaults), but IMHO the framework should no have a lock-in to any particular build tool. Provide the build tool as a separate project, but let people also use whatever they like. This is the beauty of using standardized module systems such as AMD.<p>EDIT: Looks like you answered my first question in another thread, while I was writing this and Backbone core not being modular is a good argument to break apart from it. The second question still is open, though. Why not take modularity even further and separate the framework and build tool?
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.
Seems like this page could definitely benefit from some sort of Hello World. What are the primary components, and how do I run it? Perhaps it's not meant to be a simple library, so I'm not trying to say dumb it down. But is there a more digestible way to understand hr.js without having to read the full documentation?<p>I'd love to see comparisons (as said in another comment). I like the idea of a grown-up Backbone. I'd like to see if there are any smart view rendering optimizations (like Ember has).
This seems like a step in the right direction to me.<p>I was wondering about the flexibility of templating engine and CSS preprocessing. It seems like hr.js is using it's own templating engine, which is ok and also LESS as a CSS preprocessor.<p>Is there a way to use something like Handlebars, ejs,... or maybe switch to Stylus or SASS? (is it just a matter or defining a css compiler in the build configuration)<p>Great work, keep it up.
This looks really awesome - like a fully grown up Backbone.js! The nested/complex modeling, thoughtful subview handling, and ability to use backends other than rails/rest pretty much solves some of the biggest complaints against Backbone, while keeping the good parts. (Not to mention the other considerable niceties hr.js lists)<p>I may actually give this a shot for a project of mine.
How is it going to scale, since it's using package-by-layer (as opposed to package-by-feature[1])? Most systems like that become highly annoying to work in with even a moderate amount of complexity.<p>1. <a href="http://www.javapractices.com/topic/TopicAction.do?Id=205" rel="nofollow">http://www.javapractices.com/topic/TopicAction.do?Id=205</a>
Looks very interesting.<p>The only thing I couldn't find in the introduction was how hr.js interfaces with a backend for loading and storing models. Care to explain? One of my complaints against Backbone was that it tightly coupled models/collections to REST resources, which yoru framework seems not to do, and that's obviously a good thing.