3 ms·

Hr is like a backbone-on-steroids, it uses the same code structure: models/collections/views but also brings a base structure and a build system for the applica

Hr is like a backbone-on-steroids, it uses the same code structure: models/collections/views but also brings a base structure and a build system for the application using require.js, less, etc. 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)

calebgilbert 13y ago
What I really like is that hr.js isn't built on Backbone, it rather is highly-inspired by it. That's a BIG advantage over things like Marionette/Chaplin/etc, because Backbone has certain holes/assumptions (see my comment elsewhere) which cannot be completely negated in an elegant/simple way, or even at all. Overriding the heck out of everything, or adding a gazillion new classes/sub-classes, or tossing the original component is not simple and elegant when done on a grand scale, imho. 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 :)
- SamyPesse 13y ago
  Before building HappyRhino, I tried a lot to improve Backbone because we were using it for building FriendCode (friendco.de) but the code base of Backbone is really not modular and hard to extend (the all backbone code is in one unique file, model/view/collection don't inherit from a "class", etc...)
  - thenerdfiles 13y ago
    Yes, I ran into this problem as well when building the first version (0.0.1) of ePantry (epantry.com). 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?)
- thenerdfiles 13y ago
  Also to mention: A fun name. Let's think of the Happy Rhino's Backbone for a bit.
lazerwalker 13y ago
If that's the case, I'd love to hear how hr differs from all of the other "backbone-on-steroids" projects like Marionette and Chaplin.
- thenerdfiles 13y ago
  Agreed. Marionette has been somewhat of a pain to gain consensus on in terms of application architecture (considering RequireJS integration as well).
  - lazerwalker 13y ago
    For what it's worth, it takes very little work (< 20 lines of code, IIRC) to stub out the require() function so that you can use Marionette without RequireJS. (Sadly, the project I was working on that required that wouldn't allow me to open-source that bit of glue code). Of course, that doesn't address all the other incidental complexity you inevitably have to deal with when using Marionette.

calebgilbert 13y ago

What I really like is that hr.js isn't built on Backbone, it rather is highly-inspired by it. That's a BIG advantage over things like Marionette/Chaplin/etc, because Backbone has certain holes/assumptions (see my comment elsewhere) which cannot be completely negated in an elegant/simple way, or even at all. Overriding the heck out of everything, or adding a gazillion new classes/sub-classes, or tossing the original component is not simple and elegant when done on a grand scale, imho. 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 :)

SamyPesse 13y ago
Before building HappyRhino, I tried a lot to improve Backbone because we were using it for building FriendCode (friendco.de) but the code base of Backbone is really not modular and hard to extend (the all backbone code is in one unique file, model/view/collection don't inherit from a "class", etc...)
- thenerdfiles 13y ago
  Yes, I ran into this problem as well when building the first version (0.0.1) of ePantry (epantry.com). 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?)
thenerdfiles 13y ago
Also to mention: A fun name. Let's think of the Happy Rhino's Backbone for a bit.

lazerwalker 13y ago

If that's the case, I'd love to hear how hr differs from all of the other "backbone-on-steroids" projects like Marionette and Chaplin.

thenerdfiles 13y ago
Agreed. Marionette has been somewhat of a pain to gain consensus on in terms of application architecture (considering RequireJS integration as well).
- lazerwalker 13y ago
  For what it's worth, it takes very little work (< 20 lines of code, IIRC) to stub out the require() function so that you can use Marionette without RequireJS. (Sadly, the project I was working on that required that wouldn't allow me to open-source that bit of glue code). Of course, that doesn't address all the other incidental complexity you inevitably have to deal with when using Marionette.