If you haven’t heard about Hoodie yet, you should check it out.

Hoodie is a great tool for full stack development by front-end developers.

Hoodie is a progressive new library for front-end developers that adopts some remarkable new philosophies which are likely to transform both app development as well as user experience. Hoodie puts the control over full stack, front-end app development completely in the hands of the front-end developers and user-experience gurus, freeing them from the sometimes inscrutable technical objections of their back-end counterparts. In addition, Hoodie apps release users from the shackles of uninterruptible connectivity, letting them use your app on the go, in the air, or under the sea, without a care.

While the platform is still in its infancy, it already offers some powerful new tools that are worth trying out for any front-end developer who wants to get ahead of the game. The team behind Hoodie has a proven background, having worked on other highly-successful projects such as CouchDB, Async, Mustache.js and many more.

After learning about what the Hoodie full stack development library has in the works and becoming very excited about the project, I decided to try it out for myself. Let me tell you a little more about Hoodie, and show you some of the potential it has for developing great apps.

What is Hoodie?

First of all, what is Hoodie? What’s so great about it? Hoodie is an open source, fully-JavaScript platform and API that combines several powerful new paradigms in one full stack development package, to the benefit of both the developers who build Hoodie apps, and the end-users who interact with them. Chief among these concepts are the “noBackend” and “Offline First” movements, along with a strong community-driven process known as “Dreamcode” for building out the API.


Hoodie believes the key to great front-end app development lies in the hands of the user-experience experts and developers who know how to make an app look great and be a pleasure to use, but who too often are restricted by back-end technicalities that they have no control over. Fundamental server interactions that have been around forever, such as user signup/signin, data storage, or email dispatching, continue to require time-consuming custom implementations for every new app, forcing the front-end developer to learn and code for new back-end quirks each time around.

noBackend means you don't need a back-end developer!

Hoodie puts the control back in the hands of the front-end designer and developer, by abstracting away the back-end completely. With Hoodie front-end app development, instead of worrying about your server side, all you have to worry about is the simple, easy-to-learn-and-implement front-end API built into Hoodie. For example, want to sign up a new user? This can be done in one line of code:

hoodie.account.signUp(username, password);

This is the idea behind the noBackend initiative, to which Hoodie is fully committed. noBackend means you don’t need a back-end developer! Just deploy the Hoodie back-end to your server, and forget about it.

Hoodie is written entirely in JavaScript. Its self-contained back-end uses Node.JS with Apache CouchDB as its database. At this writing, the core features Hoodie has already implemented include user signup and administration, data loading, storage and emails. These core feature can be easily extended by adding additional Node.js plugins.


Hoodie is an API first and foremost - this is what makes noBackend possible. Hoodie’s implementation may change and improve over time, but the interface provided to developers will remain the same, so that you won’t ever have to worry about it.

Hoodie is still growing fast, and new features are being added all the time. Hoodie, like other noBackend projects, uses a community-driven approach to designing the API called Dreamcode. Essentially, you dream up the code you would like to write, and if it gets enough support from the community, Hoodie will make it happen.

This API-first, crowdsourced approach to designing the Hoodie API means that Hoodie code is a breeze to write and a breeze to read. It’s the code of your dreams!

Offline First

Hoodie solves a lot of problems for front-end app developers with its noBackend, Dreamcode-driven API. But one of Hoodie’s primary goals is to solve a major problem for users as well - their often crippling dependence on connectivity.

As the shift to mobile devices with mobile apps carries on, the old desktop-based assumption of continuous connectivity has remained unchanged. All this time, the promise has been that wherever you go, the internet will be there. To this day, loss of connectivity is treated as an anomaly, shutting down users’ ability to get anything done until they are back online. But as we all know, the telecom network has failed to live up this promise. Connectivity goes out the window on planes, in subways, on rural roads, and in countless other situations. And that’s in the developed parts of the world! In huge areas of the planet, stable internet access is the rare exception to the rule.

The Offline First movement seeks a graceful harmonization with this simple fact of life. With Offline First, non-connectivity is just another normal state of the application. In fact it’s the default state! Hoodie enthusiastically adopts this philosophy. Behind the API is a full front-end implementation of temporary local storage, and automatic, graceful synchronization whenever a connection becomes available.

Front-end app development with Hoodie means an Offline First model where users don’t have to rely on connectivity.

With Hoodie, you can post comments, send emails, edit accounts, and do most any other everyday activity, without worrying about having a connection. The entire storage and sync system can be interrupted at any time, without fear of losing data.

Of course, this model comes with its own set of unique design challenges and approaches, but the team at Hoodie is pioneering the techniques to solve these challenges.

Offline First is an exciting new take on app development, in its early stages of adoption. There is still a lot to be done to develop the techniques required. Take a look here to see how Hoodie does it.

A Simple App Using Hoodie

To demonstrate the usage of Hoodie as a front-end development tool, I decided to write a simple app that would allow our community members to create their own events and publish them for other engineers to browse and add to their schedule. Keep in mind the goal here is to demonstrate Hoodie and not provide an app that is production ready. You can find the code on my GitHub page.

Under the covers Hoodie is essentially the combination of a server side built in NodeJS and a client side JavaScript library. Besides the simple installation and deployment process, the developer working on the app will only work on the client side code. The built-in library can talk to the server side without the developer knowing anything about how it works.

What if our app requires us to do something custom on the server? We can always create Hoodie plugins. Here is some more information on plugins.

Getting Your Hoodie App Started

The first step with full stack development of any Hoodie app is to use the Hoodie command line tool to get us off the ground:

hoodie new toptalCommunity

This will create an initialized Hoodie app which already has some code in place, and we can already run our app! If we type

cd toptalCommunity
hoodie start

the browser will open up with a sample app from the Hoodie team:

Here is a sample front-end app provided by Hoodie.

I did a little housekeeping at this point. Hoodie apps currently come with Bootstrap and Prism, but I took the provided versions out. I didn’t need Prism and wanted to use my own version of Bootstrap so I could use the fonts and JS that I wanted to use. I also made some changes to main.css as I built the app, to give it its own style and to allow for my simple bootstrap template. I only used jQuery for DOM manipulation and events. Hoodie takes care of everything else.

Hoodie and Dreamcode

As I was working on creating this sample app I quickly realized all the benefits of working with Hoodie. So many of the regular questions that need answering when starting a project just weren’t there. Hoodie allowed me to just write code and see the app live and working.

What strategy should we use for user account management? The Hoodie account plugin is the answer. How should we store our data on the backend? Hoodie’s dead simple storage API handles that for us, giving us the Offline First functionality for free! No effort was needed to make this Hoodie app work offline, it just works.

Let’s dive a little bit deeper on some of the implementation:.

User Account Management

Hoodie has a plugin that takes care of account management for us called hoodie-plugin-users. The API couldn’t be simpler.

How do we add a new user?

function signUp() {
  var email = $('#txtEmail').val();
  var password = $('#txtPassword').val();

  hoodie.account.signUp(email, password)
    console.log('Log error...let the user know it failed');


How do we log a user in?

function signIn() {
  var email = $('#txtEmail').val();
  var password = $('#txtPassword').val();

  hoodie.account.signIn(email, password)
    console.log('Log error...let the user know it failed');


Do we have a user logged in?

if(hoodie.account.username) {
  // modify the page accordingly

This really couldn’t be simpler. Oh wait and how is our UI going to react to all of that? Hoodie has events in store for you

React as the user signs-in:

hoodie.account.on('signin', function (user) {

Data Storage

Our sample app will allow users to create their own events (private data) and publish them if they want (making data public), so that other users can join the event.

Hoodie allows us to add data to its local store without logging in, so how does it know which user this data belongs to? Well, it keeps it local and won’t sync to the server until that user has signed in. Hoodie will also make sure only that user is able to get to that data.

So here is how it works:

hoodie.account.signIn(email, password); //Let's sign in
hoodie.store.add('myevent',event); //Store the data, hoodie takes care of using the session to make sure this data belongs to our user

It’s that simple! Ok, so that would help us create an event, how will we share it with others? This is where the global share plugin will help us out. We have to install it as it’s not a default plugin:

hoodie install global-share

Now we have the plugin in place, let’s use it! We have to publish the data we have already added to our user store to the global store.


This will flag all the events saved for this user as public so that when we query the global store we will get that data as result.

hoodie.global.findAll('event'); //This is read-only

On the My Events page, the user is able to create events which are published to the global store directly.

var event = {};
event.name = $('#txtName').val();
event.date = $('#txtDate').val();
event.time = $('#txtTime').val();

Hoodie’s front-end development tools result in a clean “Create Event” configuration.

Published events are visible to everyone, so now any user is able to see the events created on the Events page.

Hoodie creates a clean, efficient full stack development process for the Toptal event calendar.

So what about data that should not be public? We store the events our user has applied to and show it on the Events page. As the user clicks the apply button, this is what the is executed:

var id = $(this).parent().parent().data('id');

The two screenshots below show two browser windows running concurrently. In the first browser, the user is logged in as user a@a.a who has applied to the A Event. In the second, the user b@b.b is logged in and has applied to B Event.

This screenshot from my Hoodie app shows one user logged in.

This screen shot shows another sample user logged into my sample app.

Long Polling

By subscribing to some events provided by Hoodie we can transparently use techniques like long polling which gives our application an interesting feature as different users are using and collaborating on it.

This is really easy to do. On our sample app a single line got the trick done:

hoodie.global.on('add:event', loadEvent);

That simple line will take care of long polling the server to check for new events that might have been added by other users and add them to the My Events page.

Some Concerns

After building this sample app to play with Hoodie and its front-end app development features, I am very excited about what it has to offer. However, a few clear issues stood out to me.

Hoodie makes it so easy for the developer to communicate with the server that any developer would be able to add things to our database just by using the console, which clearly has major security and data-integrity implications.

The library is also still missing a lot of essential things you would need in any production app, such as data validation, linkable URL’s, a testing framework, and private sharing of data (although they are already making good progress on this last one). To use Hoodie in production right now, we would have to pair it with another solution like AngularJS, Ember, or any of the many other solutions that help us make sure we have properly structured and maintainable JavaScript code for our Front-End projects. Since these frameworks are themselves approaching the complexity of back-end technologies these days, this solution would largely defeat the purpose of Hoodie.

The Future of Hoodie

Hoodie is still undergoing heavy development to solve all of these issues. The team is working hard to implement new features and improve existing ones in order to make the platform ready for mass consumption, and of course, this process takes time. If you are planning a new full-scale app right now, you may want to find a different platform to build it on this time around.

In the mean time, however, it is certainly not too early to start tinkering with front-end app development using Hoodie, as I hope I’ve just demonstrated. There are a lot of powerful new ideas already built into Hoodie, which I think are likely to become very popular. Getting ahead of the game with these things is probably not a bad idea.

If the team at Hoodie keeps up the hard work, the API should be ready for prime time in no time. If you want to keep track of the Hoodie team’s progress, just have a look at their milestone tracker.

Hoodie promises to make developing great apps for movers and shakers a breeze. If the ideas Hoodie embodies catch on, we may see the need for a team of back-end developers for every new project become a thing of the past. With projects like this, it’s easy to imagine a golden age for front-end developers in the not-too-distant future. Similarly, the benefits to users offered by the Offline First ideal are a huge step for accessibility, extending the reach of our mobile, connected lifestyle into those places where the internet itself does not go.

Head over to the Hoodie homepage to follow Hoodie’s progress, and to become a part of the exciting new changes it is preparing to usher in.

Special thanks to the Hoodie team. Hoodie logo used with permission of the Hoodie Open Source Project

About the author

Alvaro Oliveira, Brazil
member since December 10, 2012
Alvaro is a software engineer who likes to chose the best tool for the job and is not religious about any one technology. At Toptal, he has led the successful matching and hiring of thousands of developers with their respective clients as the company rapidly scales. [click to continue...]
Hiring? Meet the Top 10 Freelance Front-End Developers for Hire in October 2016
Don't miss out.
Get the latest updates first.
No spam. Just great engineering and design posts.
Don't miss out.
Get the latest updates first.
Thank you for subscribing!
You can edit your subscription preferences here.


Aleksey Tkach
One more? Oh maybe i should create one more CMS also...
Nice article but no backend validation does not make sense, this is sweet if you want to tests a prototype very fast, by the way the first link did not work.
Hey, Gregor here from Team Hoodie. Thanks a lot for the extensive and practical write up! Regarding your concerns: Hoodie starts where the JavaSript MV* libraries / frameworks like Backbone, Angular and Ember stop today. To work perfectly well together, in fact, we have store adapters for all of them today. So something like routing is out of scope for Hoodie. Validation is in fact something that we are thinking about. You'll be able to define validation rules right in the admin dashboard that comes with your Hoodie app, so you get both: secure validation on the back-end as well as errors right in the front-end for better user experience. If you have any farther questions, we gladly invite you to our daily IRC office hours: http://hood.ie/irc.html or ping us on twitter at twitter.com/hoodiehq
Could you make the access control a separate layer that sits (on server) between the client app and the back end? The backend would only be reachable through this layer (listens on port not accessible from WAN). This way you could easily choose access control that is appropriate for your app and remain in line with nobackend philosophy.
Problem is, you don't talk to the server directly, all your data is stored locally first, and a separate process keeps your data in sync with the back-end. Besides that, every user has an own database, so there is not much harm that could be done. If you want data to be shared is where you could add rules on what a user is allowed to do and what not
comments powered by Disqus