Show HN: hr.js - Build large client-side applications in a structured way(friendcode.github.io)
friendcode.github.io
Show HN: hr.js - Build large client-side applications in a structured way
http://friendcode.github.io/hr.js/
8 comments
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)
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)
[deleted]
Think question #1 was answered well in other comments/replies.
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.
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].
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].
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)
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)
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.
Of course, that doesn't address all the other incidental complexity you inevitably have to deal with when using Marionette.
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 :)
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?)
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.
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.
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.
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?
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).
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).
Yes... The best way to try it is to install it using "npm install hr.js -g" and to create an helloworld using: "hr.js new -d hello".
I'll work on improving the introduction of the documentation to add comparaisons with others frameworks.
Hr have a components-based rendering system: a view could be a component and component could be added directly from templates. http://friendcode.github.io/hr.js/#/template/components
I'll work on improving the introduction of the documentation to add comparaisons with others frameworks.
Hr have a components-based rendering system: a view could be a component and component could be added directly from templates. http://friendcode.github.io/hr.js/#/template/components
This seems like a step in the right direction to me.
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.
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)
Great work, keep it up.
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.
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)
Great work, keep it up.
You can use sass by defining another css compile in the build config (however I never tested with sass).
The templating engine is the templating engine from underscore.js.
Thank you
The templating engine is the templating engine from underscore.js.
Thank you
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)
I may actually give this a shot for a project of mine.
I may actually give this a shot for a project of mine.
Thank you, let me know if you encounter any issue.
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.
1. http://www.javapractices.com/topic/TopicAction.do?Id=205
1. http://www.javapractices.com/topic/TopicAction.do?Id=205
Looks very interesting.
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.
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.
Of the number of comparisons drawn here, I'm rather surprised that this hasn't been compared to ember.
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?