 Thank you everyone. Fun fact, you know how they say that when you work on to a stage, sometimes everything just blacks out? I can vouch for that. Okay, so anyway, I'm Ipsha. I come from India and I'm here to speak about progressive web apps, how they are different from normal web applications, what technologies lie at the core of progressive web apps and how it all works so seamlessly well, especially from a perspective of the user experience. Today is a great time to be building something for the web. It's the largest software platform ever and we are seeing bounds of improvement in its industry basically on daily basis. So I'm really excited to be here and talk about progressive web apps. Before we go any further, I'd like to introduce myself. Professionally, back in India, I work in the domain of digital security with Jamalto as a software engineer. I'm also a part of Mozilla India Community. I have been involved with Mozilla since my college years when I first interned with them and eventually became a part of their technical speaker community and a mentor for their open leadership progress. Today I stand here to talk about something that is close not only to Mozilla but to all the major mobile browser makers like Google Chrome, Microsoft Edge, Opera, etc. So before we start, how many of you here actually know what exactly progressive web apps are? Okay, thanks. It makes my job simpler. Great, so I'm Ipsha. So to start with, when we're developing applications, we are basically doing that for majorly two platforms, the web and the native. Now, how do you decide which one to go with? Yes, the life-old discussion between the native and the web and thousands and thousands of statistics and statistical data telling us which one is better. I mean, how do you decide? Not all decisions are as easy as this, right? And clearly, we are left with two major options and not one valid choice. So when we talk about the native app and the web app, they are like the flora and the fauna of an ecosystem. Both are equally essential to drive the ecosystem and we just cannot thrive with either one of them. So what if I tell you there's a way to combine the flora and the fauna and in the sense that we can combine the best of the web and best of the native? That's exactly what progressive web apps do. We come up with an application that leverages the low friction of the web, but at the same time, they're as readily and easily available as native applications. So progressive web apps are experiences that combine the best of the web and the best of the native apps. Now, why is this important? When we talk in a general sense, we may develop application for different purposes, but the one thing that remains constant in all our applications is that we want more and more people to use our applications, right? And that can be measured in two parameters, the reach of the application and the user engagement. When we talk about the reach of an application, we are basically looking at the number of time a user opens up an application or visits the website. Now, think of a situation when you need some quick random information of your mobile browser or on your mobile device. What do you use? You'll most likely not want to go to the app store and search for the right app, download the app, accept permissions, and eventually be low on both data and storage, right? When you just need some random information of your mobile phones, you'd most likely rather just get it off the mobile browser. That's why we see the mobile web is two times as good as the native application in reaching the users. However, when it comes to the user engagement, people are more likely to spend much more time on a few selective apps that they really like and that aligns with their interests, right? As compared to, you know, when they're just perhaps just browsing through the web. So that's why we see that users are much more engaged with the native application, and we can see from the data here that it's almost 16x as compared to the web. So now we see a contrasting data here, right? The web applications are good at user reach, but not very good with the user engagement, but the native applications are brilliant with the user engagement and not so much with the user reach. When it comes to progressive web apps, we somehow just combine the best of the both worlds, and we end up with a higher user engagement and a higher user reach. So that's all great. We can see why we need progressive web apps, but now what exactly are progressive web apps? So progressive web apps or PWAs is a term coined by Alex Russell in 2015 from Google, and the idea of progressive web apps is that in addition to normal applications, progressive web app uses modern web capabilities like providing offline experiences, push notifications, background sync to deliver an app-like user experience. They evolve from browser tabs into immersive top-level applications leveraging from web's low friction. Now, what does that mean? When you start using an application on your browser, you'll be prompted an add to home screen button. You can simply click on the add to home screen button and you can get that application on your home screen. Or with the latest release of Mozilla last month, you can now get a small home icon next to the URL and you can just click it to get the application on your home screen. This is done by using the web manifest app, which is just simply a basically a JSON file that gives you the developer control over how the application is launched by the user and how it looks to the user at places they might want to find it like at the home screen or at the app selector or the app drawer. So it's basically a simple JSON file which gives you the metadata about the background theme, the display mode, the icon description, etc. So you can just simply click on it and have the icon on the home screen. When you click on it, you can experience the standalone version of the application. And honestly, this is so much better than what we were offered earlier with the continue in the app and download the app in the station which won't allow us to continue browsing the app, continue browsing the website unless and until we downloaded the app. And sometimes we just want to experience the lighter version of the application and you know just click on a URL and just get out of there. Not necessarily download the application every time. And by the way, Google Plus came up with their interstitial and found that 69% of their users abandoned their application rather than download the application because of this. So at least they would watch for that that it was a terrible idea and this leaves us with progressive web apps. Now we have been talking about how progressive web apps leverage the low friction of the web. Now what does that exactly mean? There's a study by Google that says each step to download an application reduces 20% of the users. So in a consumer mobile app you can see the number of users decreasing with each step that it takes in the installation process. So when it comes to the native app installation user flow we see that we go to the app store we look for the right app we download the app we accept the permission, install it and there are a lot of steps involved in it and with each step we are losing users. But when it comes to progressive web apps we are just one step in a way. We click on the URL and we get to use the application. So why not just click on the application use it and install it installing it first and then using it. This is the basic concept behind progressive web apps and you can see the time difference and the inconvenience it causes. So to sum up the progressive web app experience there's a list of features that the app must support to be qualified as a progressive web apps. Now let's just quickly look at that. So these are a few features that progressive web apps should support. The first as the name suggests they are progressive in nature which means that the basic content and the functionality of the application is available for every user regardless of the browser choice or the bandwidth while at the same time providing an enhanced version of the application to users with modern browsers or better connectivity. So progressive web apps are made with progressive enhancement as they co-tenant. They feel app like they are designed with the app shell model which discriminates between the content and the functionality of the application. So the basic content of the application the interface or the shell model is already cached on the device and we can use it as the native web application. We already saw the add to home screen feature. Progressive web apps are linkable in the sense that you only need to link the application with a URL and you can use it at one go. You can use the link to open and use the application and it's easy to share just at one go. Next we have a discoverable progressive web apps are identifiable as application by browsers so they can find them, rank them, catalog them, etc. PWAs are re-engageable because they support features like web push notification which can be used to deliver notifications to user even when the user is not using the application. They are responsive in the sense that they follow the Wateris content philosophy and they are designed to fit any form factor, desktop, mobile, tablet, whatever is next. Connectivity independent so they are enhanced with service workers to provide offline first experiences and work even on low quality networks. They are safe because they are served over HTTPS which means it prevents snooping and it ensures that data has not been tampered with. So when we talk about progressive web apps being served only over HTTPS, the main reason is that they make use heavily of service workers which are served only over HTTPS. So most of the amazing features that we saw about progressive web apps are made possible because of service workers. They sort of form the background to progressive web app. So to get started with service workers what exactly are they? Well to begin with service workers are simple worker scripts that run in the background. They come with the ability to do two things best intercept network request and cash responses. So what exactly are service workers? They are persistent fully asynchronous separately threaded event based workers. That's a lot of words. So let's go through that one by one. Persistence that means that they exist outside the browser tabs and they know when to expire. They are separately threaded. They run on a different global script context in the background. They are fully asynchronous. They make heavy use of promises and are hence non-blocking. They are event based workers. Since they have no direct control from the main thread they respond only to events like push, sync, fetch, install etc. So this is the definition of service workers. But now how does the service worker work? Service workers essentially act as client side proxy servers. That's it between the application and the browser. It takes the form of a JavaScript file and can control web pages which is associated with them. So they can intercept and modify navigation and resource request by sitting in the middle of the page and the server. So it gives you complete control of how your application behaves in certain situations. The most obvious one being when you're offline of the network. Now Jeff Posnick from Google describes service workers as air traffic controller. So it's like the web request are like the plane sticking off and service workers are like the air traffic controller. So when they act as air traffic controller, service worker gives you complete control over each and every request that is made from your site. In the same way as air traffic controller may redirect a plane to land at some different airport or even delay a landing, service worker enables you to redirect your request or even stop them completely. So to quickly recap service workers are number one in JavaScript file. They act as proxy servers between the web app and browser. They run in the background on a different thread. They have no direct DOM access so they cannot modify the elements on the web page. They are fully asynchronous and non-blocking. They work with HTTPS because when you're using service workers you're basically hijacking the connection, creating and filtering responses. That is a lot of powerful stuff and while you may do that for good reasons, the man in the middle might not and so to prevent snooping and to ensure that the data is not tampered with, service workers are strictly served with HTTPS and we cannot use it in private browsing mode. So this was the basic introduction to service worker. When we come to the lifecycle of service worker it includes three major steps register, install and activate. Let's look that in a bit detail. Once you register a service worker with your browser there can be two cases. Either it's an absolutely new service worker or a service worker already existed and it's an updated service worker. So now when we get a new service worker it goes straight to installation and activation but if it's an updated service worker which by the way is found out a bitwise comparison between the new and the old service worker. So when we get an updated service worker it sits ideally after the download and is not activated unless and until all the pages associated with the older version of the service worker are closed because at a given time for a given scope they can only be one active service worker. So if there's already one active your service worker has to wait and it eventually begins to activate after all the tabs are closed. Now once your service worker is at a stage to control the clients and handle the request the activation event. The activation event is where the service worker sits idle unless and until it is received by a network request in which case it loads the subsequent pages and if it's not then it terminates to save some memory. So this is the life cycle of how a service worker works. Now let's look at that from a code point of view So the first step with working with service worker is registering a service worker. Now this all code is basically in JavaScript because service workers are written that way but we'll go through it step by step. So the code starts by checking for browser support with navigator.serviceworker If the browser supports the service worker we can then register the service worker using navigator.serviceworker.register which basically returns a promise that is resolved when once the service worker is successfully registered. We can also log the scope of the service worker with registration.scope The scope of a service worker determines which files the service worker can control or in other word from which path the service worker will intercept request. The default scope is the location of the service worker and it goes down and extends down to all the directories below that. So this is how we register a service worker. Next we come to installation Installation is the step where we cache all our resources. So when we come to the installation step we can go to the network and cache all the resources that we might require to make that app work in an offline mode. So it's the great place to cache all the resources and then go to the next state which is the activate state. So to do the installation thing we add an event listener to the event install. Now we see caches.open cache.addall they both are async operations. So this means that the service worker might actually terminate before they successfully are done operating. So because of that we add an event .wait until which tells the service workers to wait until the promise is resolved or rejected. So we can simply use cache.addall to add all the assets to the cache and it's also good to remember and keep in mind that if any one of the file fails to be added to the cache the installation process would not complete. Next we come to activating the service worker. So once your service worker is ready to control the clients and handle all sorts of network requests we get the activate event. So this is the stage where it can handle events like push and fetch and sync. So this is the idle place to do all the things which we couldn't do when an older version of service worker was still in use which means we can migrate all the database and delete all the cache associated with the older version of service worker at this step here. So to look at code we created the activate event. So we are just filtering the cache and using the cache name and deleting the resources that is stored in that particular cache. Now this ability to cache files using service worker basically forms the background or the backbone of providing offline experiences in progressive web apps. Now offline experiences you all might know are experiences with application when there is no network. So if you have already viewed some page of a website you can go back and review it even when you are not connected to the internet. So let's take an example of offline experience. This is Flipkart. This is India's largest online shops. They use Flipkart light as their progressive web apps and they are showing us here how the offline first experience work for their case. And I really like this example because of how they just gray out everything to show you that you are actually offline even when you can see the content of the application. So that's great and the general idea behind service workers to provide an enhanced version of your application to improve performance or provide offline experience is this. So your app makes some requests to the service worker. The service worker checks if it's online or not. If it's online it can go to the backend fetch the response and give it to your app. If it's not it can go to the offline cache. But this general idea can be extended to improve the performance of an application. How do we do that? With this workflow. So the page makes some requests to the service worker. The service worker goes to the cache. If it does not find any saved response for the request then it would go to the network and fetch the response. So this is how you can improve the performance. But when it comes to offline experience what we do is we go to the cache first. Look if we have any stored response for that request. If we do not we go to the network. But since you're offline you won't have any response from the network. In which case we can go back to the cache and just fetch some offline.html file that we might have saved to provide in case of the offline experience. When you use Google Chrome and you are not connected to the network you see that little dinosaur coming up. That's basically what is stored in the cache as the default offline behavior. So we can just go to the cache and fetch that response. So looking at the code for doing this service workers come with a function called fetch. So we can add an event listener to the fetch event. And what we are trying to do here is basically we are first trying to reach the cache and see if we have any stored response. If the cache match is a success we return the response. If however it's not we fall back to the network. Now the network would not return any response. So in the case when both of them fails we just go back to match with an offline.html and then return that response. So that's how we can actually improve the performance of an application by relying on the cache first and then going to the network because cache is definitely faster than network. So the first step is to go to the cache. If you can't find anything there go to the network. If you can't find there go come back to the cache and just load the offline version. That's how it's done. Now next coming to another great feature of progressive web apps which are push notifications or web push notifications. Web push notifications get their name from the fact that the notifications are pushed from the server to the client even when the user are not using the browser because they are enhanced with service workers which run in the background so they do not necessarily need the browser to be up and running. We can just push messages or notifications even when the user is not using the application. So the popup messages that we get on our mobile devices all the time from the native applications that is now possible with the web as well and we make use of that in progressive web apps. So why does push matter? They are used to obviously engage more user because even when they are not using the application you can send them updates or notifications to make them come back on your application. They have been proven to retain a lot of users. They are strictly permission based which means that the user explicitly has to opt in or subscribe to receiving notifications from your website. So you cannot just send notifications to anyone unless and until they accept that. They are used to send timely updates to the user with relevant information and of course there are no forced commitments in the sense that the user does not have to share any contact information be it the email ID or anything. The messages are just routed to the capability URL associated with the service worker for that particular page. And of course the user can opt out of receiving notification any time that they want. So no commitments. Service workers are used for web push so definitely even this is done over HTTPS. So now when we say that web push notification works over HTTPS we mean that we have a server, we have a client a server that sends the message, a client that receives the message and a web push service that sits in between them. Now being HTTPS only ensures that the communication channel between the server and the push service and that between the client and the push service is secure. However, it does not ensure that the push service itself is secure. So that's why we encrypt the push message at the service side using the client's public key. So that when finally the message reaches the client only they can decrypt the message and read it. So the push service that actually sits in between them has no capability to read the actual message. It's encrypted. So a basic overflow or the workflow of how everything works for push notification is this. The client registers for push notification with the push service sends the identifier to the app server whenever there's a new message the server sends the message to the push service at the identifier URL or the service redirects or reroutes the message to the client that is associated with that URL. Now if anything that I said in the last 30 seconds seemed like a verbal comparison of this then I sincerely apologize but let's look at it one by one. So what makes push notifications? Two APIs, the push API notification API. Push API is invoked when a server supplies information to the service worker and allows service worker to handle it. Notification API is used by the service worker to determine how it's going to show the message to the users. So the first step in the entire workflow is to subscribe to the push service. So this is done by the client or the user clicking on the allow notification on the web pages. So that is basically the user saying hey there website I would like to receive messages from you. So when it subscribes to the push service it gets in response a subscription object. Now this subscription object is basically a combination of two things. The endpoint URL that is sent to the client and the client's public key. So the client then sends the subscription object to the server where the subscription object is stored in the database and can be used whenever there's a new message to be sent to the client. So the object looks something like this. It has an endpoint URL which tells particularly it is unique to a subscription. So each client has a unique endpoint URL and then there's obviously the client public key which the server would use to encrypt the data like we talked earlier. When coming to the push when coming to the server side the server now has the client's public key and the endpoint URL. So whenever the server has a new message delivered to the client it just simply uses that endpoint URL and sends it to that particular location after encrypting it with the client's public key. So it just sort of routes the message to the push service at the endpoint URL. Now remember the push service cannot actually read the message because it's encrypted using the client's public key. So you can redirect or reroute the message to the correct client. Correct client which is associated with that particular endpoint URL. Now coming back to the client side when a service worker receives the message push event is triggered. It wakes up and executes the listener associated with the push event. This is where we handle displaying the notification of using the notification API. So when we add the listener to the push event we can do a whole bunch of stuff under that. We can set the title, options etc etc which is basically how we want to display the notification to the user. And we can then use registration.show notification to show the notification to the client. So that's it. This completes the cycle and you get a real-time web push notification from the app server to the client via service workers. Now this is how web push notification works. And even though I can point out a lot of data and statistics that proves that push notifications effectively re-engage users and retain a substantial user to your website, they still act as a double-edged sword. And by that I mean that sending unnecessary messages or untimely messages to users can result to be really destructive. So let's not be too pushy with the push notifications. And that's a wrap. So these were a few things to show what progressive web apps do. If any of this has caught your attention or if any of this interests you, you can check out this website. It's a really cool website listing a bunch of progressive web apps. It can give you a lot of inspiration to go ahead with them. So do check out this website PWA rocks. And then there's this website which shows incredible statistics about improvement of website use progressive web apps. PWA stats. If the technology of service worker somehow resonates with the work that you're doing and if you want to go ahead and play around with them this is a really nice place to start off with the service worker's cookbook. It is an amazing compilation of code which is feature-wise distinguished in the application and you can use it to look at the code and see what all features service worker support. If you're wondering what all the service worker can currently do at a particular browser do check out this website. It tells you where the browser is in the supporting service worker so there are a lot of things associated with service worker and not all browser support each of the features. So if you want to check out the service worker supported before trying your hands on something this is a really nice place to start. Okay, so these were a few things related to progressive web apps and how service workers are used to get the maximum benefit out of the web. Progressive web apps are undoubtedly one of the best things to have happen to the web lately and we all are crazily excited about what's in store next. So until then, thank you very much.