2011.08.08

Hasher: deep linking for rich-media applications

Hasher Logo

There are many available polyfills and libraries that provides deep-linking capabilities using the browser location.hash to generate a new history state. Hasher was created to do exactly the same thing but providing a cleaner API and solving a few problems present on some of the other libraries, it was also designed to make use of JS-Signals providing many advanced features like enabling/disabling the event dispatch, adding multiple listeners, etc… and to also be used together with Crossroads.js easily.

Check the README file on the project repository to understand better how does it work, why it was created, some benefits over the other solutions and also when should you favor using the HTML5 history API over location.hash to store application state and when you should avoid it.

Watch the project on Github for future updates and use the issue tracker to report bugs and ask for new features, contributors are welcome!

PS: I’ve been using Hasher for more than 1 year on a few projects but only decided to release it last week (after revising API and refactoring unit tests).

Related Posts:


Comments

Hasher + Signals + CrossRoads + Requirejs versus Backbonejs. Argl, it's difficult to choose :)

I always felt that Backbone.js is more targeted to regular CRUD operations since it has Model.fetch(), Model.save() and the Collection class. I fell that Crossroads + Hasher + Signals gives more flexibility but also less guidance, you need to know how to "glue" things together while still keeping the code organized...

I coded Crossroads + Hasher + Signals as individual libs since in many projects I don't need all the features - I use Signals way more often - and most of the projects I'm coding wouldn't benefit that much from a Collection class or the methods present on the Model class. I also don't want a strict framework that enforces that each new View should be tied to an HTMLElement and/or Model and that every change should trigger a "render", etc... - I also like to split my code into multiple different files and load them on demand (and use RequireJS for it..) so I normally code my own MVC-like structure for each project depending on the need (using an old project as starting point) - maybe I open-source it someday..

for me the most important thing on MVC is the concept of separating code by concerns and not necessarily the implementation, so even if you are not using Backbone (or any other MVC-like framework) it is still good to separate the data logic (Models) from the presentation (Views).

PS: Models shouldn't be simply data storage objects, they should be used to do most of the "heavy-work" and Controllers and Views should just consume the data - Skinny Controller, Fat Model

Cheers.

Leave a Comment

Please post only comments that will add value to the content of this page. Please read the about page to understand the objective of this blog and the way I think about it. Thanks.

Comments are parsed as Markdown and you can use basic HTML tags (a, blockquote, cite, code, del, em, strong) but some code may be striped if not escaped (specially PHP and HTML tags that aren't on the list). Line and paragraph breaks automatic. Code blocks should be indented with 4 spaces.