This Dot Blog
This Dot provides teams with technical leaders who bring deep knowledge of the web platform. We help teams set new standards, and deliver results predictably.
The Renaissance of PWAs
What Are PWAs? Progressive Web Apps, or PWAs, are not a new concept. In fact, they have been around for years, and have been adopted by companies such as Starbucks, Uber, Tinder, and Spotify. Here at This Dot, we have written numerous blog posts on PWAs. PWAs are essentially web applications that utilize modern web technologies to deliver a user experience akin to native apps. They can work offline, send push notifications, and even be added to a user's home screen, thus blurring the boundaries between web and native apps. PWAs are built using standard web technologies like HTML, CSS, and JavaScript. However, they leverage advanced web APIs to deliver enhanced capabilities. Most web apps can be transformed into PWAs by incorporating certain features and adhering to standards. The keystones of PWAs are the service worker and the web app manifest. Service workers enable offline operation and background syncing by acting as network proxies, managing requests programmatically. The web app manifest, on the other hand, gives the PWA a native-like presence on the user's device, specifying its appearance when installed. Looking Back The concept of PWAs was introduced by Google engineers Alex Russell and Frances Berriman in 2015, even though Steve Jobs had already discussed the idea of web apps that resembled and behaved like native apps as early as 2007. However, despite the widespread adoption of PWAs over the years, Apple's approach to PWAs drastically changed after Steve Jobs' 2007 presentation, distinguishing it from other tech giants such as Google and Microsoft. As a leader in technological innovation, Apple was notably slower in adopting PWA technology, much of which can be attributed to its business model and the ecosystem it built around the App Store. For example, Safari, Apple's web browser, has historically been slow to adopt the latest web standards and APIs crucial for PWAs. Features such as push notifications, background sync, and access to certain hardware functionalities were unsupported or only partially supported for a long time. As a result, the PWA experience on iOS/iPadOS was not - and to some extent, still isn't - on par with that provided by Android. Despite the varying degrees of support from different vendors, PWAs have seen a significant increase in adoption since 2015, both by businesses and users, due to their cross-platform nature, offline capabilities, and the enhanced user experience they offer. Major corporations like Twitter, Pinterest, and Alibaba have launched PWAs, leading to substantial increases in user engagement and session duration. For instance, according to a 2017 Pinterest case study, Pinterest's PWA led to a 60% increase in core engagements and a 44% increase in user-generated ad revenue. Google and Microsoft have also championed this technology, integrating more PWA support into their platforms. Google highlighted the importance of PWAs for the mobile web, while Microsoft sought to populate its Windows Store with PWAs. Apple's Shift Towards PWAs Despite slower adoption and limited support, Apple isn't completely dismissing PWAs. Recent updates have indicated some promising improvements in PWA capabilities on both iOS/iPadOS and MacOS. For instance, in iOS/iPadOS 16 released last year, Apple added notifications for Home Screen web apps, utilizing the Web Push standard with support for badging. They also included an API for iOS/iPadOS browsers to facilitate the 'Add to Home Screen' feature. The forthcoming Safari 17 and MacOS Sonoma releases, announced at June's WWDC, promise even more significant changes, most notably: Installing Web Apps on MacOS, iOS, and iPadOS Any web app, not just PWAs, can now be added to the MacOS dock from the File menu. Once added, these web apps will open in their own window and integrate with operating system features such as the Stage Manager, Screen Time, Notifications, and Focus. They will also have their own isolated storage, and any cookies present in the Safari browser for that web app at the time of installation will be transferred to this isolated storage. This means many users will not need to re-authenticate to web apps after installing them locally. PWAs, in particular, can control the appearance and behavior of the installed web app via the PWA manifest. For instance, if your web app already includes navigation controls, or if they're not necessary in the context of the app, you can manage whether the navigation buttons are displayed by setting the display configuration option in the manifest to standalone. The display option will also be taken into consideration in iOS/iPadOS, where standalone web apps will become *Home Screen web apps*. These apps offer a standalone, app-like experience on iOS, complete with separate cookies and storage from the browser, and improved notification handling. Improved Notifications Apple initially added support for notifications in iOS/iPadOS 16, but Safari 17 and MacOS Sonoma take it a step further. If you've already implemented Web Push according to web standards, then push notifications should work for your web page as a web app on Mac without any additional effort. Moreover, the silent property is now taken into account, and there are several improvements to the Notifications API to enhance its reliability. These recent updates put the support for notifications on Mac on par with iOS/iPadOS, including support for badging, and seamless integration with the Focus mode. Improved API Over the past year, Apple has also introduced several other API-level improvements. The enhancements to the User Activation API aid in determining whether a function that depends on user activation, such as requesting permission to send notifications, is called. Safari 16 updated the un-prefixed Fullscreen API, and introduced preliminary support for the Screen Orientation API. Safari 17 in particular has improved support for the Storage API and added support for ReadableStream. The Renaissance of PWAs? With the new PWA-related features in the Apple ecosystem, it's hard not to wonder if we are witnessing a renaissance of PWAs. Initially praised for their ability to leverage web technology to create app-like experiences, PWAs went through a period of relative stagnation, especially on Apple's platforms. For a time, Apple was noticeably more conservative in their implementation of PWA features. However, their recent bolstering of PWA support in Safari signals a significant shift, aligning the browser with other major platforms such as Google Chrome and Microsoft Edge, both of which have long supported PWAs. The implications of this shift are profound. This widespread and robust support for PWAs across all major platforms could effectively reduce the gap between web applications and native applications. PWAs, with their promise of a single, consistent experience across all devices, could become the preferred choice for businesses and developers. The cost-effectiveness of developing and maintaining one PWA versus separate applications for multiple platforms is an undeniable benefit. The fact that all these platforms are now heavily supporting PWAs might suggest an industry-wide shift toward a more unified and simplified development paradigm, hinting that indeed, we could be on the verge of a PWA renaissance....
Aug 18, 2023
5 mins
What Does the Future Hold for PWAs?
Intro We're talking about Progressive Web Applications (PWAs), a hot topic in today's developer community. Many are just realizing what is it, and some have been developing it for a while as it's been slowly gaining a reputation. For many companies today, finding the right starting point for a new application takes time and careful planning, and often the question is "where do we start?" PWAs are worth considering for many businesses, and will likely become the web standard in the near future. To begin, we need to know what a PWA is. After that, we can understand its relevance in today's shifting tech landscape. What is a PWA? A PWA could be described simply as "apps for the web". It is a website disguised as an app without being stuck in the browser. For the developer, this approach reduces the number of architectural headaches in app development. > PWA is a brand for the modern web with a set of standards for creating native app-like experiences. The developer uses the browser to deliver an application, but to the end user, it's just an app. The *progressive* part of this is the on-going engagement from browser with the end user as they continue to use the application. Engagement could look like asking the end user if they'd like to install the wen app locally without the need for the browser. While this is true for the end user, PWAs can be thought of as more than one thing: it's a brand for the modern web, and it's also a movement for creating native app experiences that are installed on devices similarly to native apps. From a technical perspective, it's a set of standards defining information about the app, where and how it launches, with what themes, and a service worker handling network connection. Information about the app comes from a web manifest and can specify where the app launches and its UI, and the service worker can handle a number of tasks including enabling offline capabilities for an app. Whether as a brand, a movement, or a technical standard, all of these parts come together to create an experience that's indistinguishable from native apps. What is a service worker? For PWAs, "installing" an app isn't like your typical install. In fact, you're not actually installing anything. It's a combination of adding an icon to your systems desktop or screen while performing route navigations like typing a url in a web browser. The things that control how the app handles network traffic events is the Service Worker. It's like a proxy that exists between your app and the network. For example, while process network traffic, the app could stop and do something else as a side effect- performing other network calls, fetching more assets, etc- and serving them back to the user. Before there were service workers, there was app cache, but it didn't keep the app synced. Service worker can be extended to do other things as well. It's a process that's not running all the time. If the app is idle, the service worker shuts down after a few seconds of inactivity, but it can launch very quickly. For instance, if a user isn't in the app, but a notification comes in, that will trigger the service worker, perform any checks, and show the notification bringing the user back into the app. > Workbox is a tool that helps with groups of service worker tasks, background syncing, and app refresh, helping developers avoid the pitfalls building these patterns from scratch. One thing to note as a common pitfall of implementing a service worker from scratch, is a PWA opened with multiple tabs. Since the service worker is attached to each instance of the app (that is, every tab that's opened), you have multiples of the same service workers running, so you would have to account for that scenario. Why are PWAs important today? Technologies like HTML5 spec, CSS3, geolocation, just to name a few, help establish the idea for the modern web. But where these tehcnologies failed to meet a company's needs, a new "brand" must step in to take its place. This new brand helps companies re-engaged with the web in an attempt to rebuild trust with the web. > What PWAs bring to the table is a new way of defining how the modern web works, how it's used by the end user, and how companies re-engage with the web under a newer, better brand. Buy-in from a company is a huge factor in an apps success. While some companies can look at examples of great apps, and decide that that experience is, or what they would like, does the web provide all the features needed to succeed now and in the future? Company buy-in is often based in future successes, whether or not today's technology will meet that goal, or if competitors buy into another technology. Any company can choose a product for mobile development, like Flutter, and potentially lose business. Regaining trust in the web also involves comapanies being aware of available features, and roadmapping what technologies that company needs. Some of the trust has been lost in the work because you don't know if technologies will keep up. Where are we now with PWAs? One can say that we're in an early Renaissance. We are just now starting to get the capabilities that we need to be able to build real apps using web tech. However, the awareness for what's available or in development is lacking. So how can we build awareness while we're still in development in the modern web? Build cool stuff with the technology we have available to show off what's possible! Every big company has at least three dev teams, which is detrimental from a business cost perspective, and they're all building the same experience with three different technologies - web, Android, and iOS. Yet, many apps don't need all those variants. > PWAs are a great cost-effective strategy for companies to consolidate web, Android, and iOS apps into one. Additionally, for the end user, they may get a great web expereince, but end up with a poor native mobile app experience. The different sets of work required to make the other experiecnes (Android and iOS) consistent results in wasted effort, especially if the app doesn't work, leaving the user to run back to their laptop, only to see that the web version works as expected. With PWAs, you minimize the cost to create the same product for different platforms because it works independently of the operating system- one of the greatest advantages for PWAs. Companies can begin to develop for a single application with a consistent experience. Caveats for developing PWAs Today, Apple's Safari browser is impacting the web because it doesn't offer the same features as other browsers- which is ok for them to do- but they restrict other apps on their devices as well. Chrome, and any other browser, on iOS devices, is simply a wrapper for Webkit. They're not different browser engines, so they lack the capabilites that other browsers already have. This doesn't mean that we can't built experiences for iOS users that are progressively enhanced as those capabilities become available. What it means for the end user and developer is that the web on this browser will eventually become irrelevant, and both parties will have to move on because they aren't met where they are. Perception is another factor that can hinder progress as well. In the case of Apple products, Apple users may not be aware of what's missing unless they're looking for specific features. A user might need a specific feature that a certain set of hardware can't provide. How do we advance web standards? A side note for those who've experienced roadblocks from unavailable features: it helps to complain or submit requests, even repeatedly, for features to arrive. Big company names will stand out among all of the requests for features on webkit. How can we make the switch to PWAs? Regardless of whether or not a company has a released product, here are a few things to keep in mind for implementing PWAs today: Use HTTPS Websites must be served over HTTPS. Where many APIs can be split and accessed from different domains, all new APIs should come from a single domain or origin, keeping with the good security models for the web. Take for instance a user who clicks a link an it directs them to another domain. That might take them out of your PWA. So you should, in theory, only have one origin. Configure service worker for offline mode Requirements for a service worker have now changed to include offline capailities. It used to be that you just need to have a service worker: it was good to go. Now, you need to have some kind of offline experience. We're moving towards having an offline experience, but it's still in progress. For now, service workers should provide a page or notification to the user that they're offline. Have a manifest for the app Lastly, have a web manifest, typically in JSON, where you describe your app. The manifest determines how the app launches and with what themes. Does versioning matter with PWAs? When it comes to version control, PWAs have the advantage of already being installed. Because they're already installed, you can provide a couple ways to get the user onto the latest version. One solution is to provide an opt-in strategy, or update on navigation, but another is a true analogous experience. This can be accomplished during the first time somebody opens the app, immediately showing them content while in the background, prepare newer content, or experiences. Part of that is achieved by caching assets locally. Then next time when the app boots up, if it already has a service worker installed, it begins serving from the cache immediately. The way the model can be built or designed is to immediately show the old experience on launch, and then perform updates in the background that are prepared for the next launch. Deciding the best approach doesn't come without its pitfalls too. There is a chance of locking a user into an older experience if a rollout strategy isn't implemented correctly. Ultimately, whatever strategy makes the most sense to a business is the correct approach. There are tools for helping with version management, like WordBox, which helps with pre-cache assets. Keeping the app experience consistent App consistency is key to a successful PWA. Unfortunately, there are limitations with them on iOS devices, but with Android devices, there's no telling the difference. Frameworks, like Ionic, the closest to the desired web solutions for distribution, are marketing for usage in PWAs. They have capacitor, a tool for getting an app into a native package, and into the app store quickly. However, that brings up a concern about awareness for PWAs that isn't the standard download from an OS's app store. To keep awareness up for new apps as PWAs, developers take advantage of Google's offerings for wrapping their websites to be displayed in the Google Play store. The same rules of the app store still apply as the do for other apps. There are other services being worked on for assisting app store launch like Cordova. App distribution channels Software distribution is hard. Fundamentally, it's one of the more difficult problems as a developer in general. The web model for publishing new versions of a PWA stays intact. It's as simple as pushing your code to a new server, with some of the work, as part of that effort, goes to generating a service worker that has information about that built. It extremely easy to throw a webpage on the internet, and that's really all that needs to be done while having additional amazing web capabilities. Standard app distribution is difficult because there's all the code form for the specific platforms- signing and buying validation certificates, for example. This is the reason that PWAs are so important and valuable. Best of all, updates can be published at any time. Apps aren't stuck in a review queue, companies aren't losing business, and no middle entity is standing between the company and the user. What makes a successful PWA? Just like any web application, a successful PWA is one that users want, and that works seamlessly between desktop and mobile experiences. Think about what the user is doing, and how they might use an app. That will often guide the design and experience. Over-designing experiences for different platforms becomes a headache when you consider the different platforms and dedicated launguages you have to work with. As in Swift for Apple, you're restricted to what the platform allows, but a PWA opens up the ability to design consistanly across devices. A button remains the same button it was as described in the manifest, and because it all comes from a single code source, there aren't multiple configurations needed. Implement what you need In thinking about what the user is doing, enabling features that aren't needed or not providing features that work similarly to most common native app experiences, will prove an unsuccessful app for the end users. If web capabilites don't exist that an app absolutely needs to succeed, these features that aren't ready can always be enabled when they are. Lower the bar to entry Make it easy for a user to access an app. If a user is on a Starbucks line and sees a notice for a rewards program, but they don't have the app installed, it wouldn't be effective for the user to download the app and have to wait for the download to finish. Once the download is finished, they'd still have to login, whereas, the website remembers their credentials. Companies spend so much money trying to figure out how to get a user to download an app, but the conversions happen when products are made easily accessible. Consistent app experience A successful PWA means that users shouldn't be made aware of differing experiences from a native app to PWA. On that line of thought, the thing that should be different is the security. Again, users shouldn't be able to tell the difference here, but there are differences between native apps and PWAs regarding authentication. In the browser, we can take advantage of Cors to secure a site over https. In native apps though, you can just hit the network without asking for security. This means that PWAs, with a good authentication path, are more secured right away, and without extra configuration. For native apps, the default strategy was to make sure it's safe, and then run the app, but the web default says that it's probably not safe, so let's make sure that the browser protects the user as much as possible. Conclusion PWAs' benefits far outweigh any arguments against them. They are a great cost effective strategy for minimizing codebases across web and mobile platforms. What we've seen, so far, only scratches the surface on what we can do with the web, and there's so much more on the horizon that's being released. Thanks to my guests Kenneth Rhodes, Adriana Salazar, and Henrik Joreteg for their thoughts and experience on PWAs, and for helping to build up awareness in the community with the work....
May 5, 2021
10 mins
History of Mobile Web Development and the rise of PWA
In this post, we are going to cover the history of Mobile Development, provide insightful details of current trends and uses of Progressive Web App development...
Feb 28, 2020
10 mins
How to do social Media sharing in your PWA
PWA using Web Share API Have you wondered how you can make a use of the "social" sharing API PWA? You know, when you want to share something, and it gives you the option to share via email, Twitter, Instagram, etc? Well, it's actually very easy! Take a look at the demo app to test it on your device. LIVE DEMO https://pwa-share-api.firebaseapp.com/ About the project I have built the sample project that can be found in this repo. In this project, you can see how I added the share functionality to the PWA , but you don't need a service worker or a PWA to add this functionality. I added it to this project because I wanted to show you how to do it specifically in a PWA, but you can add my code to any web app easily! Web Share API The bland definition of what a WSA is: > The Web Share API is meant to help developers implement sharing functionality into their apps or websites, but using the device’s native sharing capabilities instead of having to resort to scripts from the individual social platforms and DIY implementations. The API surface is a simple as it gets.- alligator.io The Web Share API has two share methods: share() and canShare(). The ShareData dictionary of the web share v1 consists of several optional members: text member: Arbitrary text that forms the body of the message being shared. title member : The title of the document being shared. May be ignored by the target. url member : A URL string referring to a resource being shared. The canShare() method contains an extra field which is the files property. files member: A File array referring to files being shared. To read more about it, check out this link So let's have a look at how it actually works. First, let's collect data to make our ShareData dictionary. ` Then, after we have declared what we want to share, we can use it in the .share() method. ` We can put that inside of a function, called onShare(), for example. ` Then pass the onShare() as a click handler to the share button. ` If you want to take it to the next level, you can check to make sure the *web share api* is supported by your browser. Your code will look as follows: ` If you want to use the canShare(), to send files, your code might look like this ` Browser Support If you go to canisue.com, you can see that browser's support for the share() method. Pretty much every major browser supports it. What about the canShare() method? Not as good as the share() method, hopefully it gets to more browsers soon. Resources https://www.w3.org/TR/web-share/#sharedata-dictionary https://alligator.io/js/web-share-api/ https://web.dev/web-share/...
Feb 7, 2020
3 mins
PWA Push Notifications with Firebase (Cloud Messaging)-pt1
Push Notification In Your PWA Have you ever wondered how to add the famous/annoying push notifications to your app? Well, in this tutorial I'm going to show you how to do it using Firebase Cloud Messaging. *Note:* This tutorial requires some basic knowledge on PWAs and Service Workers. You can take a look to my Intro to PWA and Service Workers here and About PWA and notifications here. Before we begin, I need to clarify that the Notification API, and the Push API, are not the same. People get them confused all the time. Push API: The Push API gives web applications the ability to receive messages pushed to them from a server, whether or not the web app is in the foreground, or even currently loaded, on a user agent. This lets developers deliver asynchronous notifications and updates to users that opt in, resulting in better engagement with timely new content. Let's doooo it!! The final code is in the FINAL branch inside of the repo. 1) Clone this repo: https://github.com/devpato/pwa-FCM-notifications-tutorial As you can see, I already have the basic structure of the app created for you, since we are only going to worry about how to send the messages via push notifications using the Firebsae Cloud Messaging service. 2) Navigate to the index.html file. Notice I imported Firebase for you: ` 3) Navigate to Firebase.com, and create an account if you don't have one. 4) Once you are in the Firebase console, navigate to project settings (in case you don't have a project yet - just create it there) 5) Inside of project setting, under the General tab scroll all the way down to find your Firebase SDK snippet (if it's not there yet - this means that you've created a new project, and need to add there an app. Either way, this can be done in the same place where you then will have your SDK snippet - under the General tab). Copy paste it in a safe place. The snippet should look like this: 6) Go to your index.js file, and copy paste the following after the global variables I declared for you. Replace it with your project's customized code - the snippet from step 4. ` 7) Right after - initialize the firebase instance. ` 8) Then, we are going to create a constant called messaging, and will set it to firebase messaging service. ` 9) Time to request permission from firebase cloud messaging. Once we get the thumbs up, they will give us a token as a promise. ` 10) Then, we are going to use the messaging.onMessage() method. This is used for receiving data, and notification payloads, by all users that are currently viewing the page (the page is in the foreground). To do so, we add the following code: ` 11) Notice a firebase-messaging-sw.js file. This file name is going to be searched by the Firebase SDK. The file needs to be in the ROOT of your project. The Firebase SDK will do some magic in the background to register the file as a service worker. 12) Inside of your firebase-messaging-sw.js, initialize the Firebase app by passing in the messagingSenderId. The sender id can be found inside of your project settings as the following image shows. ` 13) Retrieve an instance of Firebase Messaging so that it can handle background messages. ` 14) Background message handler (this one will be invoked when the page is in the backround) ` Test The Notification 15) Run the app using any http server 16) Inside of your Cloud Messaging settings (a tab in the Firebase Console > Project Settings), copy the server key. 17) If you have a Postman http client, do the following: POST URL:* https://fcm.googleapis.com/fcm/send * HEADERS: Content-Type - application/json Authorization - key=server_key BODY: ` Then, click the Send button. At this point, if our app is in the foreground (it is currently opened tab in your browser), then you'll see the message we've sent in the console - handled by messaging.onMessage. But if it is in the background, then it will be handled by messaging.setBackgroundMessageHandler in the service worker, and you'll see something like this: Test your app on a real device by deploying to Firebase or any other hosting provider. If you want to host your app on the Firebase - take a look at my other tutorial. In the next tutorials, I will show you how to successfully subscribe to notifications and push them using the Firebase console....
Feb 3, 2020
5 mins
How to add Notifications to your PWA
Have you ever wondered how to add those annoying (but useful) notifications to your progressive web app? Well in this tutorial, I'm going to show you how! What are we building? Live Demo https://pwa-notification-td.firebaseapp.com/ Before We Start We will make use of the Notification API Notification API: The Notification interface of the Notifications API is used to configure and display desktop notifications to the user. These notifications' appearances, and specific functionalities, vary across platforms, but generally provide a way to asynchronously provide information to the user. *Note: *The notification API is not the same as the Push API. Time To Get Your Hands Dirty 1) Clone this repo: https://github.com/devpato/pwa-notifications 2) You will see 3 folders. The ones that matter are the START and the FINAL folder. In the FINAL folder, you can see the final code, but for the purpose of this tutorial, and for you to learn, just focus on the START folder. 3) Navigate to the main.js file inside of the scripts folder 4) add the following code ` The notificationButton is the button that will trigger the notification in our app. If you go to the index.html, you will see the button there that I've already created for you. The swRegistration is just a global variable that will store our service worker. 5) Now let's create a function called initializeApp. This function will handle everything that needs to be triggered when the app first loads. ` To learn more about the PushManger, visit : https://developer.mozilla.org/en-US/docs/Web/API/PushManager 6) When the app first loads, we need to call the initializeApp(). function. To accomplish this - add the call before the declartion of the function itself. 7) Now we need to create a new function called initializeUi. This function will look as follows: ` The only purpose of this function is to attach a click event to the notificationButton. So when the user clicks on the button, something will happen. 8) Now inside of the initializeApp() (function we previously created), we invoke the initializeUi();, right after the swRegistration = swReg; expression: ` By doing this, we will initilize the UI once the registration of the service worker has been successful. 9) Time to create a new function called displayNotification. The function will look like this: ` 10) Go back to the initializeUi() inside of the click callback, where it says "Do something here". Replace that line with: ` Your code will look like this: ` 11) Finally, we are going to create a notification function that will contain the information we want to display in our notification. ` 12) Inside of your displayNotification() function, you will see we are calling the notification(), but it's commented out. Simply uncomment it , so the code can be triggered. 13) The final code will look like this: https://github.com/devpato/pwa-notifications/blob/master/final/scripts/main.js 14) Test the notification in your browser. If you want to test it on a real device, you need to deploy it, and make sure that the deployed app gets served using https. You can you use firebase hosting for this. As you might have noticed, we registered a service worker, but we didn't add any code to it becaue it wasn't necessary. In the the next tutorial, we will actually be doing more with the service worker. In that tutorial, I will show you how to send push notifications from the server using Firebase Cloud Messaging. So, wait a bit and we'll explore much more about Service Worker features ;)...
Jan 21, 2020
3 mins
Intro to PWA and Service Workers
Progressive Web Apps Progressive Web Apps, aka PWAs, are becoming more and more popular everyday. In this tutorial, I'm going to tell you what a progressive web app is, and how to create one using a service worker. What is a PWA? A PWA is an app that is intented to behave like a native app on your phone. It's a regular web app that, when you open it on your browser, displays a message saying "Add to Home Screen" once you click on the message, your app will be intalled on your phone and you will see the logo on your device's home screen. PWAs are becoming very popular because they help incresing the user experience when visiting a website. When visiting a traditional website, it can take several seconds. A PWA's loading time, however, is significantly faster thanks to the use of Service Workers. There are 3 types of apps you can have on your device: -Native -Hybrid -PWA Native: in my opinion unless you are using high graphics, and performing heavy user interaction with the a device (like playing games), I would go with a Native app. Native Apps are expensive to build since they require double effort and time - two separate apps need to be built for Android and iOS. Hybrid: a good way to go, since you have one stack that creates separate builds for Android and iOS platforms from the same sources. I would use hybrid apps if you don't require high speed and graphics on your app. With hybrid apps, you do have access to the device hardware via plugins that are built with native code. What about PWA? PWA: They are cheaper than the previous types of apps when it comes to developing, quick to develop, and they work offline! The same way that you develop a regular responsive web app, you can develop a PWA with the difference of adding a service worker to enable offline support, and things like installing the app on your home screen. What is a Service Worker? A service worker is a script that is running separetly from our website - in the background. Service workers are awesome, they can help us reach different things like caching pages, caching API calls, push notifications, background sync, and more. - A service worker can cache network requests. - A service worker can handle how network requests are done in your website. - A service worker can make the use of the Background Sync API which allows you to defer actions until the user has stable connectivity. - A service worker can't access/interact the DOM directly. - A service worker can cache your things from your website, like static assests. - A service worker can receive push notifications when the app is not active. - A service worker stays inactive when it's not in use. When it gets the "signal" to be used, it reactivates again. - A service worker can be used to make your app work offline. Service Worker's Lifecycle -Register the service worker: The first step into the service worker's lifecycle is to register the service worker. You can do so using the following code: ` Jeff Posnick from Google taught me a little trick in one of his articles about service workers. This trick is a simple way to improve the registration of the service worker. ` This code will register the service worker once the whole page has loaded, but keep in mind that you might delay the registration of the service worker this way. -Installing the service worker: This process is only called once after the service worker has been loaded. If you modify the existing service worker, the browser will update, and install the service worker again. There is an install event that gets emitted while the service worker is being installed. You can handle this event, and perform some async actions if needed (e.g., caching static assests). For this purpose, you can use *event.waitUntil()*. This method will keep the service worker in the install phase until the promise passed to *event.waitUntil()* is settled. Depending on whether that promise is resolved or rejected, the install phase will either finish successfully, or won't. In order to install the service worker, we need to do the following: 1) Open a cache. 2) Cache our files. 3) Confirm whether all the required assets are cached or not. ` The following are instruction on how to check if your service wokers have been successfully installed and registered directly in the browser. In Chrome (duhhh) 1) Open dev tools 2) In the toolbar click on *Application* 3) On your left side, you will see a sidebar. Click on service worker. 4) You should see something like the following: -Activating the service worker: The service worker can get into the activating state in different scenarios. Here are some of those scenarios: - we don't have the existing service worker in our app - we run the *self.skipWaiting()* method in the service worker - the user has navigated away from the page, releasing the previous active worker - a set period of time has passed, releasing the previous active worker -Active service worker: When a service worker is active, you can check its status inside of the register object. ` -Redundant service worker: A Service Worker can be redundant (aka something went WRONG) because of the following reasons: - the installation of the service worker failed - the service worker failed when it was getting activated - a new service worker replaces the existing service worker as the active service worker That's all folks! Sources: -https://developers.google.com/web/fundamentals/primers/service-workers -https://bitsofco.de/the-service-worker-lifecycle/ -https://developers.google.com/web/fundamentals/primers/service-workers/lifecycle...
Jan 17, 2020
4 mins