Offline Frameworks: Choose your weapon

14:15


Web applications seem to be at the center of our lives now more than ever it. These complex applications constantly have numerous actions taking place behind the scenes that make up their intense functionality. They are designed to be as easy to use as possible for the user. For example, a person on a transatlantic flight with their IPad in the Airplane mode will not have access to internet connection but they would like to check a message that may have been received while they were last online. We all know that we can't use web applications offline, not without the use of an offline framework. It is simply a framework that provides various application functionalities without requiring an internet connection. There are many libraries available which implement this feature into our web apps however we have cherry picked a few that we are partial to:
  1. Firehose:  Described as "a minimally invasive way of building reatime web apps", Firehose claims to keep its JavaScript models in sync with the server. It also works with RESTful design patterns ensuring that you will end up with a sustainable API after your application is created. Firehose also supports integration with Backbone.js and Ember.js.
  2. Backbone.localStorage: Working as a replacement for Backbone.Sync(). This is a local storage adapter for Backbone.js, essentially this is an adapter for a local storage database. The implementation of this technology isn't too difficult as it only requires some simple includes.
  3. Upup: This is an open source offline framework the boasts a robust range of offline features, everything from showing messages to providing functionality for SPA's (Single Page Applications) offline. By simply including one tiny script, it is insanely easy to add Upup's robust offline funcitonality to our applications.
  4. PouchDB: Inspired by CouchDB, PouchDB is a opensource JavaScript database that is designed to run smoothly in the browser. It allows users to store information locally while off-line and then synchronizes it with CouchDB when it gets back online. The aim always being to keep users data up-to-date at all times.
So all of these libraries have some hefty selling points. Before we go in-depth with each of these frameworks, there are a few necessities we are looking for to begin with:

FirehoseBackbone.localStorageUpupPouchDB
Open Source****
File size173kb194kb13.3mb148kb
Easy to learn**
Cross Browser****
So as seen above we are are comparing these frame works based on whether they are open source for easy customization, file size for performance reasons, how easy they are to learn and if they are compatible over a range of different browsers. In no particular order, we're going to examine each of these frame works. Lets look at the PouchDB framework:

PouchDB

PouchDB is one of the offline tools that is designed with the intention of helping developers build applications that performs well just as good offline as they do online. Simply put it is an in-browser database that saves data locally, making it possible for users to access features of web applications offline. Lets go through a very basic steps of setting up PouchDB in a project.
  1. First we need to create the project folder. Create this folder on your desktop and call it something simple like pouchTut, something that's easy to remember.
  2. Next install PouchDB by either downloading it from the main website, installing it using bower or installing using npm. For this example we simply download it from the site and paste it into our project. 
  3. Create a file named index.html in your project folder. In that file we have:
    
    
  4. <!DOCTYPE html>
    <html>
    <head>
     <title>PouchDB Tutorial</title>
    </head>
    <body>
    <script src="pouchdb-5.0.0.min.js"></script>
    </body>
    </html>
    
  5. Finally, all we need to do is set up a new PouchDB as so:
  6. var db = new PouchDB('my_database');
    
And that's all we need do to get a new PouchDB setup within our project. This is however only a very brief look at pouch as a whole. It is a great offline tool and very easy to implement but it is dependent on CouchDB which is not a bad thing, it's just not a viable solution for the platform we are building as we are dependent on MongoDB.

Pros:
  • Open source
  • low file size
  • Easy to set up
Cons:
  • Only works with CouchDB

UpUp.js


Following Upups setup tutorial just to see if it is as easy as it boasts, as it left me questioning it's suitability as a solution for providing offline functionality for single page web applications. The tutorial available on Upup's website claims that it will have you up and running in less than ten minutes, this however was not the case. Below is a step by step walk through of how the tutorial should be set up as opposed to how it is displayed on UpUp's website.
  1. For this tutorial you will need to have XAMPP or a similar application installed. The tutorial on UpUp's site doesn't mention this and will probably lead to confusions down the line.
  2. Create a folder for all the files you will need, name it something like upupTut, something simple and easy to remember. 
  3. You will need two .js files called upup.min.js and upup.sw.min.js, they are available to download from upup's site. After you've download these files place them in the folder you created in step 1.
  4. A glaring problem with UpUp is that all the files you wish to include as part of the offline functionality, will need to be  placed in the root of the project. This is a problem as it means that UpUp will not work correctly without all assets, such as scripts and style sheets being included in the same folder.
  5. In your project folder create an index.html file. I have placed an example of what this file should contain below:
  6. <!DOCTYPE html>
    
    <html>
    
    <head>
      <meta charset="UTF-8">
      <title>Lonely Globe Advisor</title>
    </head>
    
    <body>
      <h1>Top Hotels in Rome</h1>
      <ol>
        <li>Villa Domus - Via Piacenza 9, Rome, Italy</li>
        <li>Hotel Trivelli - Piazza Barberini 11, Rome, Italy</li>
      </ol>
      <script src="/upup.min.js"></script>
      <script>
        UpUp.start({
          'content': '<html><body><h1>Top Hotels in Rome</h1><p>Villa Domus</p><p>Hotel Trivelli</p></body></html>'
        });
      </script>
    </body>
    
    </html>
    
We have our main content consisting of a header and a simple list followed by the necessary UpUp scripts. We have a small script at the very bottom that will inject what we should see when the user is offline. Try and run this example. You will see the following displayed in the browser window.


However, how do we test to see whether UpUp actually works? This is where XAMPP comes in. Take the folder we created in step 2 and place it within the htdocs folder. The path to this folder will look something like: C:\xampp\htdocs.

After this start the XAMPP Apache server like so: 


Now in your browser URL bar type: localhost/nameOfYourFolder, this will open the index.html file and we will see the same output as earlier. After this stop the Apache server and reload the page. You should see this:


With those few steps, we have added the very basic offline functionality to a web page. However this doesn't seem like a sustainable solution for much more complex applications, so lets look at our next option.

Pros:
  • Open source
  • Easy to set up
Cons:
  • Bad tutorial
  • Big file size
  • All assets must be in one folder

Firehose


How easy is to set it up? Well lets give it a try to answer that. I followed the github documentation as it was and I encountered an error after doing everything it said. Example below: 


I am not a ruby expert so I try to find what it was wrong with it and I found that I was missing a package called rainbows. But what is rainbows? Why is it needed? The answer was on the gem package installer online. Rainbows is a HTTP server for sleepy Rack applications. It is based on unicorn, but designed to handle applications that expects long request/response times and/or slow clients. After running gem install rainbows, Firehose was running without any problem and no errors whatsoever.


To run this framework, you should be more familiar with Ruby than actual JavaScript.

In conclusion, this framework isn't very easy to understand or use, you must have certain knowledge about Ruby on Rails to make it work, and the documentation for this is very poor. The only suggestion that I have to the JavaScript, Node and Ruby community, is that their tutorials and example codes should be more well documented and explained to any type of audience. In the end, Firehouse seems very blurry and quite hard to understand in my opinion so on to the next one.


Pros:
  • Open source
  • Low file size
Cons:
  • Tutorial is hard to understand
  • Depends on different frameworks

Backbone.localStorage

Following the tutorial on https://github.com/jeromegn/Backbone.localStorage. It isn't very easy for people who are new to the backbone world. There are some important parts missing and the examples that are presented are very hard to understand. I did my best to understand the complex logic behind backbone and how to wrap this adapter to its logic. First of all we need to include the adapter to our program:

<script src="/bower_components/backbone.localStorage/backbone.localStorage.js"></script>


Once this is done the adapter gets wrapped in backbone automatically (My example was using the global scope of the window with no private functions or methods).

var Heroes = Backbone.Collection.extend({
   model: Hero,
   localStorage: new Backbone.LocalStorage("justice-league")
});

The line of code localStorage: allows the Backbone model to make RESTful requests with local storage instead of the server. That means you can call var heroesList = new Heroes(); heroesList.fetch() , heroesList.save() and heroesList.destroy() to deal with data in local storage. This could be a very useful technique for web applications to allow users to use both on-line and off-line.

By appending that call to my collection, I was able to use localStorage from the browser without any problem. The only thing was, the explanation for building the view was quite blurry and here is where all the logic to make it work is suppose to be, like so:

var HeroView = Backbone.View.extend({
     template: _.template('<b><button id="remove">X</button> <b><button id="edit">Edit</button> <%= name %></b>'),
     editTemplate: _.template('<input class="name" value="<%= name %>" /><button id="save">Save</button>'),


    events: {
    "click #remove": "deleteItem",    
    "click #edit": "editItem",
    "click #save": "saveItem",
    },

    deleteItem: function(){
      console.log('deleted');
            this.model.destroy();
            this.remove();
    },

    editItem: function(){
     console.log('editing');
     this.$el.html(this.editTemplate(this.model.toJSON())); 
    },

    saveItem: function(){
     console.log('saved'); 
     var editTitle = $('input.name').val();
     console.log(editTitle);
     this.model.save({name: editTitle});
     this.$el.html(this.template(this.model.toJSON()));
    },

    render: function(){
      var attributes = this.model.toJSON();
      this.$el.append(this.template(attributes));
      return this;
    }
 }); 

Pros:
  • Allow web applications to be used off-line
  • Reduce requests with server
  • Fast response
Cons:
  • User could lose all data if she/he accidentally clears local storage
  • For instance, if a user thought that the data had been sent to the server but it had not, she/he could lose all that information.
  • Might be out of sync with the server
Final Screen Shot with the functional local Storage.


Overall, I think this is a very nice offline functionality technique for web applications. It could improve the user experience with fast response times by submitting the final changes at the end when applications need to do a lot of data exchange in coordination with the server. One scenario is, an educational application that allows users to take exams on a mobile device or tablet while they are riding the subway and without Internet access. The users can submit their exam responses later when they have Internet again on their device. In addition, the users will not have long wait times, thus improving their experience.

Conclusion


Now that we've had a chance to see all of these frameworks in action, we can safely say that the best option is Backbone.localStorage. It seems to be the easiest to implement while still being sustainable for larger projects. Firehose rely's on Ruby, which is a problem as we are only working with JavaScript. Firehose also isn't as straight forward as UpUp or PouchDB, however even though these frameworks are easy to use they are drawn back by there limitations.

Thank you for reading, and don't forget to like, comment and share this post 
- José Oduber & Cormac McCann

You Might Also Like

0 comments

Couch Jumping