Menu
November 30th, 2015

Why Progressive Web Apps Are The Future Of Web Development

Mobile App Testing Learn tips, techniques and trends for launching great mobile apps Get It Now
Like what you're reading? Subscribe to the weekly newsletter. Subscribe For Free

Application Shell Architecture will replace the need for hybrid apps.

Apps are fast and the mobile websites are slow.

In 2015, this particular problem has been one of the prime conversations in Web and app publishing and development.

Facebook Instant Articles is theoretically predicated on speed. The Accelerated Mobile Pages Project (AMP) spearheaded by Twitter and Google and will launch in early 2016 with thousands of publishers already on board.

To a certain extent, AMP and Instant Articles are a patch on a more systemic problem in that mobile Web applications and websites are just not fundamentally built for smartphones or tablets.

Developers and designers are employing the architecture of the PC and the desktop browser-based Web and hoping to speed it up for mobile. We see this approach in the “wrappers” for native applications, epitomized by the likes of PhoneGap (IE, Apache Cordova) where Web apps and websites are written in HTML and CSS and then “wrapped” with native properties (API hooks into a smartphone operating system and hardware). The industry term for these concoctions are “hybrid” apps. After years of writing about and researching these apps, I now believe that it is the wrong approach to cross-platform development and building the best Web and native app experiences.

Mobile Beta Management Learn the benefits, best practices and toolkits for mobile beta management Get It Now

App development is ever evolving. And from the seeds and ruins of the last generation come the innovations for the next.

A new architecture is coming that will help bridge the gap between performance of Web and native apps and may finally provide the solution to building apps and websites that are fast and reliable for the mobile age.

The Idea Behind Progressive Web Apps

Progressive Web apps are an idea first espoused by Google engineer Alex Russell in June 2015. In a nut shell, progressive Web apps start out as tabs in Chrome and become progressively more “app” like the more people use them, to the point where they can be pinned on the home screen of a phone or in the app drawer and have access to app-like properties such as notifications and offline use. Progressive Web apps are linkable with an URL, fully responsive and secure.

Russell writes:

These apps aren’t packaged and deployed through stores, they’re just websites that took all the right vitamins. They keep the web’s ask-when-you-need-it permission model and add in new capabilities like being top-level in your task switcher, on your home screen, and in your notification tray. Users don’t have to make a heavyweight choice up-front and don’t implicitly sign up for something dangerous just by clicking on a link. Sites that want to send you notifications or be on your home screen have to earn that right over time as you use them more and more. They progressively become “apps”.

For speed and functionality, progressive Web apps rely on two functions: Application Shell Architecture and Service Workers.

Application Shell Architecture is explained in more detail below. Service Workers are a way to increase Web app performance by helping to cache and deliver content and background functionality (like push notifications). Service workers can make sites work offline or help speed up the content by, “intercepting network requests to deliver programmatic or cached responses.”

What Is Application Shell Architecture?

The interesting aspect of Service Workers is that if it can intercept, store and deliver content from network requests, it can do other things too.

Service Workers are the foundation of Application Shell Architecture. Instead of cache and delivering content, the Service Worker always has the basic interface and design of the Web application stored and ready to deliver almost instantly.

Hence we have the “shell” of the application delivered as soon as a person makes a request from their smartphone.

app_shell_architecture_cat

 

Think of the shell like the frame of a picture in the Harry Potter movies. The frame is always there and always stays the same. What changes is what is inside the picture as the person can move around and (apparently) come and go as they please. The frame is static while the person inside is dynamic.

In Application Shell Architecture, the shell is served up by the Service Worker and then the content is delivered—often cached by the Service Worker—dynamically from its source through API requests. Sites that people visit more often will be able to hold the shell and even the last content the person visited while waiting for the network to dynamically load the latest refresh.

Google’s Addy Osmani and Matt Gaunt described the process on Google’s developer site:

When we talk about an app’s shell, we mean the minimal HTML, CSS and JavaScript powering the user interface. This should load fast, be cached and once loaded, dynamic content can populate your view. It’s the secret to reliably good performance. Think of your app’s shell like the bundle of code you’d publish to an app store if building a native app – it’s the load needed to get off the ground, but might not be the whole story. Keep your UI local and pull in content dynamically through an API.

In tests, the Google developers found that the combination of the Application Shell Architecture and Service Workers drastically reduced the time it took to load sites over cellular connections. Loading a site from first request to meaningful “paint” (the first thing seen on the site) by asking for all the resources over the network at once was 1.2 seconds. The App Shell Architecture and Service Workers, the same request was loaded in 0.5 seconds (to note, the tests were being run on extremely simple websites).

shell_archictecture

The implementation of the Service Workers plus Shell Architecture scheme is still in its early stages. Google used progressive Web apps and progressive enhancement on its Google I/O 2015 Web app and has a couple of other examples, but no website you visit on a regular basis today will be using it. Osmani and Gaunt note that Application Shell Architecture would be best used for sites that have a lot of dynamic content that is updated frequently (think, ESPN or even ARC).

Web developers do not need to wait for an official go ahead from the likes of Google. All of the tools are available now (to varying degrees of maturity). Service Workers are supported by Chrome and Firefox and the creative use of JavaScript, CSS and HTML will help developers build the necessary shell and design elements. APIs can call the content to populate the app. All of it is there, ready to go for developers that want to take the plunge.

Update: This article originally stated that Service Workers are ready for Apple’s Safari browser. That is not the case. Certain aspects of Service Workers are in the plan Safari, but not yet available. 

  • Service workers are supported in Safari?
    Really?
    http://caniuse.com/#feat=serviceworkers

  • quazecoatl

    misleading information, Service Workers are NOT supported in Safari.

    please update the article.

    we all love the shiny new things in HTML5, but until they get supported in all web-browers, desktop and mobile, they pretty much are just toys

    • DanRowinski

      Article has been updated.

      Now, I would not call it misleading. That would imply an intent to lead one in a direction away from the truth. This was just a mistake based on research that said that certain aspects of Service Workers could function in Safari but the full integration has not yet been built.

      • quazecoatl

        wrong choice of words, sorry
        thank you for the great article.

    • Misleading/oversight from the author agreed.

      “pretty much are just toys” I’d disagree with though, service workers are a very valuable progressive enhancement to any web experience.

      • quazecoatl

        what I said was these are just toys until the time when they get implemented well in a useful/practical range of web-browsers (IE11, latest Chrome on desktop, latest Firefox on desktop, Safari 8)

        • You can use Service Worker as a progressive enhancement, so it’s definitely not a toy. It’s primary beneficiary is mobile browsers (so I’m less concerned about IE11 and Firefox). The mobile browser space is largely occupied by Chrome and Mobile Safari.

          Think of it this way: if 50% of your users are using some Chrome/Mobile Chrome, then that 50% is going to get a supercharged experience. For the rest of your users who might be using other browsers (like Safari) they’ll get the same experience they have today. Your app doesn’t stop working if Service Worker is not supported, it just continues on and does a regular http request for whatever asset it was looking for.

          You shouldn’t wait until all browsers have Service Worker support, you should just go ahead an implement it now. You’ll be upgrading the experience for a non-trivial chunk of your user base.

          • DanRowinski

            Good advice. Thanks Rob.

  • Pingback: 1 – Why Progressive Web Apps Are the Future of Web Development - Exploding Ads()

  • Pingback: Collective #198 » CSS 3 & HTML 5 Links und Infos()

  • Pingback: Collective #198 | Tech +()

  • Pingback: Collective #198 - Daniele Milana()

  • If progressive web apps will become popular and will be the future, this will directly impact the native app developments, right? It will impact the apps market place business as well. It will impact Google Store as well. How Google would allow this happen? My conceptions might be wrong too.

    • DanRowinski

      The … Google Store? You mean Google Play?

      Google would love to see the Web (where it can better serach and advertise) to be the de facto method of app delivery. The Google Play is a capitulation to market trends that has become necessary for Android app distribution.

  • Christopher Svanefalk

    Sad that what most people seem to be taking away from an otherwise great article is that the author made a mistake regarding SW support in Safari (it was a mistake, not intentionally misleading, btw. For goodness sake).

    I agree that SWs are awesome, and they are doubtlessly going to become fundamental for web apps developed in the coming years.

    However, It would be amazing to see much bigger focus on what perhaps is the biggest problem for hybrid/web apps – UX. Even in 2016, hybrid/web apps are still not on par with native apps in terms of user interaction. This manifests in everything from delayed click responses, scroll lag, and a multitude of other issues that can and will impact the user experience in a negative way, especially for users who are accustomed to the smoothness and snappiness of native apps.

    There is a lot of work being put into this of course, for example Crosswalk for Android (https://crosswalk-project.org/, not affiliated), but it would be great to see a serious push from more sides. I have looked at AMP, and it seems that many outcomes of that project may help in this regard, so it will be exciting to see what will come up over the next years.

    • jinmatt

      I think progressive web apps have better UX performance experience than native apps. Check out flipkart.com on mobile browser. Still there is a problem with browser support like only now Chrome supports all the features for SW and other progressive app features.