Alex Russell had a great post this week about Web Sites in an App World, he even coined a new term “Progressive Apps” which I enjoy immensely. Progressive Apps, in Alex’s view, are (web)apps that earn their spot on our homescreens over time and preserve the URL-based nature of the Web. Best of all, they work offline.

I’ve been thinking about progressively enhanced apps with offline access quite a bit lately. Last week I was driving through rural Iowa testing Paravel’s progressively-minded¹ webapp DayTrip. It’s a travel app that needs to work in harsh conditions and be performant, even in the Texas Hill Country. However, when my data connection vanished I saw a white screen endlessly waiting for the first response. I consider that a bug.

Offline Access is probably the greatest strength for JavaScript rendering frameworks (and non-frameworks) but one advantage I don’t hear touted enough. Making a website cached and usable, able to render on the client without an Internet connection might be near the top of Maslow’s pyramid, but it’s not far-fetched. Offline Access is a great feature, unless you require high-volume/non-stale data, which seems like another usecase for a client-side rendering solution. All paths seemingly lead to client-side rendering as a big win.

It’s great to see Alex and his team at Google making contributions like ServiceWorker, which is a core feature in Alex’s vision of Progressive Apps. I’m a fan. It feels like websites and Progressive Enhancement are entering into the next decade.

1. Ruby on Rails’ RESTful routing requires JavaScript for proper HTTP verbs (GET, POST, PUT, DELETE). I like that architecture so I’m keeping the JavaScript requirement feature for now. ↩