Single Page Apps & Realtime, a Love Story

This is the second in a series of articles on Building Realtime HTML5 Apps. In the first article, we looked at the difference between Websockets and AJAX as transport mechanisms for data. In this article, I wanted to explore why single page apps fit in so well with the new realtime paradigm.

What’s a Single Page App?

In its most basic form a single page HTML5 app is a browser-based application that doesn’t do a full page refresh as the user interacts with the page. I like to think of it as the Web’s version of a native application. Each web page is its own app, and when you start thinking about things this way, you make the leap that the browser is really a first class application platform, and not just some glorified HTML container.

With this understanding, it makes sense to think about the most natural separation of concerns for this type of environment. Currently, MVC seems to be the prevailing paradigm for understanding the browser environment, however I think it makes sense to look at the browser more in terms of inputs and outputs:

Inputs

  • Data Inbound – Websockets, AJAX, etc, received from the server/cloud.
  • User/Device Interaction – Clicks, Taps, Camera, Microphone and other events you can react to.
  • Routes – A way to recreate state in your application through bookmarkable, shareable URLs.

Outputs

  • Data Outbound – Websockets, AJAX, etc sent to the server/cloud.
  • View Manipulation – Programmatic manipulation of the DOM.

In my opinion, this conception of the most important aspects of the browser environment fits in well with realtime data flows. Realtime data is asynchronous, and it can come from either the server or the browser. And since you can’t rely on the request/response cycle as with AJAX, it makes sense to worry about data flowing in and out of your application separately. It also makes sense to think of those data flows as first class concerns, instead of automatically hiding them behind a “model” abstraction as with MVC.

Single page HTML5 applications can do just about anything that a normal “website” can do. A great example of this in case you are unaware, is the new HTML5 PushState standard, which allows you to update the address bar and browser history without ever refreshing the page.

But the more important question is, can a single page HTML5 app do anything that a “truly native” application can do?

Persistent Connections: The Realtime Lifeline

Part of what keeps any realtime application “alive” is its persistent connection back to the server.

Even though single page HTML5 apps are highly transient (downloaded and installed in seconds or milliseconds), the applications themselves should strive for persistence. That is they should be robust. Especially, when you start looking at things from the perspective of mobile HTML5 applications. Intermittent connections are commonplace in mobile environments as users switch between WiFi, 3G, 4G, etc.

Because the connection is persistent with realtime, it is easier for a single page HTML5 app to make a decision about whether or not it’s connected back to the server. There is usually only one persistent connection to keep track of, instead of a slew of isolated AJAX requests.

You Can’t Do Realtime without Single Page Apps

Realtime and single page apps are a great match out of necessity.

A Websocket connection does not persist across page reloads, so to get any benefit out of persistent WebSocket connections you need to be designing and building your Realtime HTML5 applications to be single page from the ground up. A hodge podge of page reloads and AJAX is not going to cut it. To make the next generation of great realtime applications, it helps to start looking at the browser as a truly first class application platform.

I will be posting another article in this series, Building Realtime HTML5 Apps, soon.

Brad is a badass JavaScript coder who enjoys building cool stuff and long walks on the beach. As the Founder/CTO at TechPines, he has worked with large companies and startups to build cutting-edge applications based on HTML5 and Node.js. He is the creator of Bone.io, a realtime HTML5 framework, and is the author of Embracing Disruption: A Cloud Revolution Manifesto.

Related:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Chris Missal

Oh hey, I'm a Senior Consultant for Headspring in Austin, TX. I've been working in software professionally since 2006 and I really, really love it. I'm mostly in the Microsoft world, but enjoy building computer things of all sorts (to be vague). When I'm not slinging code, I'm probably out and about slinging discs, bowling balls, or good beer with great friends.
This entry was posted in HTML5, JavaScript. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Steve

    Nice series so far. Looking forward to the next article.

  • Stacy

    Look forward to you putting some meat on those bones. Good intro!

  • Dev.

    They can’t do SEO.

  • sidazad

    Why do you say that one won’t get anything out of an app that isn’t fully SPA? What about someone transitioning an existing non-SPA to SPA slowly, or adding new pages that are SPA like while having non-SPA pages.

    One can still use Web Sockets in these situations. I am using this for a legacy app that has mostly full page reloads but some pages that are SPA-like. One of these pages is a live monitor using socket.io and talking to a Node app which uses Redis for pub-sub. This works fine.