15Nov
serviceworker-trump-card-browser-web-native-app-battle

Will “ServiceWorker” be the Trump card for browser in Web vs Native App battle?

It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change.

Above Charles Darwin’s quote(sidestepping this contrary) accords not only for Bio world but in Tech world also. In the history of tech world, technologies that have failed to adapt the changes, haven’t sustained for a long period of time. However, Web technology has adapted well enough to overcome a lot of challenges since its invention by Tim Berners-Lee in 1989. One such instance was on the arrival of full scale online applications like Outlook Web App, Google Maps in early 2000s, it struggled to compete with native desktop apps in terms of responsiveness as the browser was supposed to reload the page for every HTTP request that time. But with the introduction of AJAX in 2005, it has almost replaced most of the native desktop apps and established its supremacy.

As the tech world is migrating towards mobile now, web technologies are facing the challenge of survival again and its battle is against the native apps which defines the user experience for mobiles at present. Other than notification & background sync, the fundamental challenge mobile browsers faces, is accessing the app offline/slow internet connection . Some of the workarounds like AppCache, LocalStorage/IndexedDB that are employed to address this issue weren’t up to the mark. In addition to agony of development & debug issues for programmers, main reason those attempts failed to work was, they didn’t work in right layer (Eh, what layer?)“for mobiles” (Make a note, for mobiles in quotes).

Before explaining about the layer, let’s start with later part, the word on quotes. Offline usecases for mobiles are more complex than in the desktop one. Arguably, we can articulate that network state in desktop is binary, either you have full network or no network. But, that’s not the case with mobile. There are a lot of possibilities that ranges from browsing at high speed wifi in office to browsing at BSNL 2G while travelling in electric train from Chromepet to Nungambakkam. For slower connections, it’s good enough to assume that the user is in offline but unfortunately earlier workarounds were unable to resolve that issue.

Coming back to earlier part, now it’s so clear that the problem is not in the caching layer alone. Athukkum mela!  Yes, We need to take some decisions in network layer also. To do that magic, here comes the protagonist of this blogpost, “ServiceWorker”. It should be relatively new term for most of the people even for web pros. You would have firefoxed/chromed about it on reading the blog topic (my atonements to the Grammar nazis for verbifying the browser names 😛). Because, it’s a new technology still in research stage.

So, What is this “ServiceWorker”? It’s a background script execute by the browser, isolated from web page’s process which act as a network proxy allowing developers to handle the network requests programmatically and decide the mode of response(either from cache or retrieve from online). To make it simple, it’s a layer between web page and network which can be handled by web developers (not ‘browser developer’). Since it is isolated from web page’s process, it’ll allow developers to push notification using Web Push API and perform background sync for the given page even if the web page is not active. To know more about the ServiceWorker, just go through the introduction video by Jake Archibald, Developer advocate of Google chrome.

Your’s concern is understandable. Why should the developers prefer this complicated(kind of) over the native mobile apps. Yes! I agree. Native mobile apps provide ample user experience at lesser complexity (as of now). But the cost of making user to install & update the app is more than just entering url in the browser. And another main advantage web apps have, over native apps is its ability to perform in cross-platform.

The e-Commerce giant Flipkart which has failed in its attempt of app-only strategy , now in association with browser vendors (that provides low-level API’s based on the feed of developers) has launched it’s mobile app, Flipkart Lite using serviceWorker which can perform similar as its native app.

As a web developer, it sounds so delightful to know that browser vendors are breaking the limits of web platform in mobile by providing low-level APIs not to forget Extensible Web Manifesto‘s efforts which made the feedback loop process even simpler. It’s too early to comment on how it’ll evolve but it succeeds in bringing the new dimension for solving the appification of web problem in mobile.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

© Mathan Kumar, All Rights Reserved