Hacker News Reader

Comment by thenerdfiles | Hacker News Reader

Actually, we know that these types of frameworks are not created in the dark. Instead of a comparison, I'd like to see what elements of Backbone.js, AngularJS, KnockoutJS, etc. this framework developer chose to mash up.

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].

View on HN

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)

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 :)

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...)

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?)

Also to mention: A fun name. Let's think of the Happy Rhino's Backbone for a bit.

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.

Agreed. Marionette has been somewhat of a pain to gain consensus on in terms of application architecture (considering RequireJS integration as well).

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.

Also, we see a lot of [dependency management] does this and [asynchronous module definition] does that slideshows/blogposts/tutorials/guides/stackoverflowquestions/etc.

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.

Reply on news.ycombinator.com