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...
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.
That being said, I have a couple of questions.
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.
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.
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?
To answer your second question:
First of all, hr.js build process can be integrated in another node.js process using "var hr = require('hr.js')", so you can still use Grunt (or others).
But we built HappyRhino to really simplify the creation of client-side application that can scale (modular, optimized, ...), and it seemed important for us, for having some consistency, we needed to built together the framework and the build tool. The build tool brings a lot to the client framework (a very simple example: caching uses revision number given by the build process).
But I really understand all the advantages of having build tool as a separate project. I have to think more about all of this before giving you more elements.
Comments
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...
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.
That being said, I have a couple of questions.
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.
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.
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?
To answer your second question: First of all, hr.js build process can be integrated in another node.js process using "var hr = require('hr.js')", so you can still use Grunt (or others).
But we built HappyRhino to really simplify the creation of client-side application that can scale (modular, optimized, ...), and it seemed important for us, for having some consistency, we needed to built together the framework and the build tool. The build tool brings a lot to the client framework (a very simple example: caching uses revision number given by the build process).
But I really understand all the advantages of having build tool as a separate project. I have to think more about all of this before giving you more elements.
(Sorry for my english)
Think question #1 was answered well in other comments/replies.