Progressive Web Applications

Transcription

1 Introduction Progressive Web Applications Progressive Web Applications (PWAs for short) are a new type of application that represents a hybrid application type. A PWA is not only able to work without a connection (offline), but it also performs relatively well on a slow network connection. In this handbook, we ll build a sample application that highlights some of the critical features of progressive web applications. To put it in simple terms, a PWA should act as a native mobile application, bringing specific features from the mobile world to the web: things like offline availability. The term progressive in the name means that the user experience for the application is progressively enhanced by other factors such as the speed of the network connection. (The term relates back to the era of progressive JavaScript when JavaScript was used as a progressive enhancement for websites. The lack of JavaScript support did not affect the user s experience, but having JavaScript enabled meant that additional things were possible). The same theory is applicable for progressive applications having a slow network connection should still allow users to interact with the application but having a faster network should progressively enhance the user s experience. PWAs are enabled by some great and recent technologies available in browsers such as Service Workers, the Push API and local storage (or IndexedDB). Reader requirements The reader should be familiar with web related technologies, including HTML, CSS and JavaScript (preferably ES 2015), Node.js and its ecosystem to entirely be able to absorb the knowledge provided by the handbook. New to JavaScript ES 2015? We got you covered. Check out this free course! / 1

2 Get the code Get the source code of the application from GitHub: The Progressive Web Application checklist Let s take a look at all the properties of Progressive Web Apps, as set out by Google: - App-like o There s a separation between the application s functionality and content. The shell of the app can load separately from the data - Connectivity independent o By using service workers, the application can work offline or on lowquality networks - Discoverable o The web application can be used as a mobile application via a manifest file, also allowing search engines to find it - Fresh o The application is always up-to-date because of the service worker update process - Installable o Users of the application should be able to place an icon to their home screens to access the app, without having to visit an app store - Linkable o The application should be shareable via a link and it shouldn t require complex installation (see earlier point) - Progressive o Regardless of what device, browser and network connection a user has, the application works and provides the same experience - Re-engageable o Engaging (and re-engaging) with the application should be available via push notifications. - Responsive o The application s design is responsive it works on desktop, mobile and tablet. - Safe o The application is served over HTTPS The above list nicely sums up what progressive web applications should try to achieve. Google has also developed a tool called Lighthouse that we can use to test our applications it takes some of the previously mentioned points into consideration, and it does give an overall score for our application (it also scores it for usability, SEO, Accessibility and Performance). / 2

3 Figure 1 - A report generated by Lighthouse Requirements of the application In this handbook, we ll put together an application to display news coming from an API. (The API is something that we ll be running locally) These are the high-level requirements for our application: On the first load of the application: o If there s no network connection (offline mode): Only display the application shell (HTML) Cache the HTML and other assets Naturally, no data is going to be displayed o If there s a network connection (online mode): Load data from the API and display news cards Cache the data Upon consecutive application loads: o If there s no network connection available (i.e. offline): The data is retrieved from the application cache, results shown If the application cache is empty, no match results should be displayed o If there s an available network connection (i.e. online): Make a call to the API to see if new data is available Add new items to the HTML Refresh the cache, if necessary The application should act as native app as well o It should be possible to add an application icon to a mobile device (Android, ios, Windows) o If the API gets a new news item added, a push notification should notify the user about this fact / 3

4 As you can see from the list above it s not a full-featured application that is not the point of this handbook but rather to show you the core principles of PWAs. You can of develop the application further to add extra functionality. Let s revise what is that we d like to achieve. We would like to create an application and make an API call and display some information. We would like to make sure that we adhere to the main points outlined earlier in this document regarding progressive web applications most importantly, in this first round, we d like to make sure that data is available in the application even when there s no network connectivity (i.e. we are working offline). Before you start Before you get started, please make sure that you have your environment setup correctly. This means that you should have the latest version of Node.js installed (either LTS or Current) and that you have cloned the source code of the application from GitHub. Please make sure that you set up the dependencies for the project, so after getting the files from GitHub make sure to execute npm i from the project s root folder. The API For this handbook, we have decided to create a simple API which is also part of the codebase provided to you. The API uses Node.js and Restify. In order to start the API, please navigate to the api folder and execute node api.js. To test the API, please use a tool like curl, Postman or Insomnia. Opening in your browser should also work, and you should see data returned by the API. / 4

5 Launching the application Figure 2 - Sample API call using Insomnia Starting the application is possible via npm scripts npm start fires up the sample application as well as the API. The command npm run server starts the HTTP server running the progressive web app, and npm run api starts the API server. Are you new to Node.js? For 15 you can learn the basics of Node.js and everything that you need to know to start being a productive Node.js developer. / 5

6 Developing the application The application shell The application is going to be a straightforward one we ll have only a few lines of HTML code and a few lines of JavaScript. Don t forget, this time we are only highlighting the fundamental concepts. This is how our HTML looks like for now: <!doctype html> <html> <head> <link rel="stylesheet" href=" beta/css/materialize.min.css"> </head> <body> <div class="navbar-fixed"> <nav> <div class="nav-wrapper"> <a href="#!" class="brand-logo">pwa News</a> </div> </nav> </div> <main id="main"> <div class="row template"> <div class="col s12"> <div class="card darken-1"> <div class="card-content"> <span class="card-title">breaking! PWA are on the rise</span> <p class="card-content-text">pwas, also known as, Progressive Web Applications are taking over the internet. Embrace this new piece of technology coming your way!</p> </div> <div class="card-action"> <a class="read-more">read more</a> </div> </div> </div> </div> </main> </body> </html> If you load this application now (providing the fact that you have an active internet connection to let the browser download the materialize CSS framework, this is what you should be presented with: / 6

7 Figure 3 - The application shell with sample, test data Now of course what we see here is some static data we did this step to verify that the application indeed looks as expected. Please go ahead and delete the sample title and the same card content. Going forward we ll be adding this data from the API. / 7

8 A call to the API It is now time to add some JavaScript code and load news data. Go ahead and create a file called app.js and add the content below. For the time being it is going to be a very simple request. Here s what we ll do: take the first div, use that as a template and we ll clone that for each news article received from the API. We will then take the returned data and populate the card title, description and read more link: const url = ' const newscard = document.queryselector('.template'); fetch(url).then(response => response.json()).then(news => { news.foreach(newsitem => { const main = document.getelementbyid('main'); const card = newscard.clonenode(true); card.queryselector('.card-title').innerhtml = `<strong>${newsitem.title</strong> by ${newsitem.author on ${newsitem.publishedat`; card.queryselector('.card-content-text').textcontent = newsitem.description; card.queryselector('.read-more').setattribute('href', newsitem.url); main.appendchild(card); ); newscard.style.display = 'none'; ).catch(error => console.error(error)); In the above code, we use the Fetch API to retrieve information from our API. Let s not forget to add the following line just before the closing </body> tag in our index.html file: <script src="app.js"></script> Take a look at the output on the screenshot below this is how our application looks like at the moment. / 8

9 Figure 4 - The application displaying data from the API At this point, we have a working application that displays information when the network is available. Bringing the network offline in the browser will, of course, present us the infamous downasaur, and no data will be visible at all. That s not an app like functionality. / 9

10 Figure 5 - The dreaded downausur - this is what we see if the application is offline You can bring the network offline by selecting the highlighted option using the Chrome DevTools under the Network tab. To get an application ready for offline functionality, we need to introduce a service worker. In light of this, let s create another JavaScript file for the sake of simplicity, let s call this file service-worker.js. The Service Worker is going to be responsible for caching parts of our application as well as making sure that data (if cached) is returned to the user so that even though there s no active network connection, the application can be visible. The first thing that we ll do in this service worker file is to give our cache a name and install the service worker itself. We will be using two caches, one to cache the application shell and the other to cache the data. We ll start by caching the application files. / 10

11 const cachename = 'pwa-news-cache'; const files = [ '/', '/index.html', '/app.js', ' beta/css/materialize.min.css' ]; self.addeventlistener('install', event => { event.waituntil( caches.open(cachename).then(cache => cache.addall(files)) ); ); Notice the usage of self. This is guaranteed to point to the ServiceWorkerGlobalScope where we can find properties related to the service worker itself (The ServiceWorkerGlobalScope is an interface of the ServiceWorker API.). We could have used this as well, but that adheres to the same binding rules that the rest of your environment, therefore since we explicitly want to access the Service Worker scope, it makes sense to use self. What we are caching during the installation of the service worker is the shell of the application: the files required the display the app itself. For this very basic application, all we need is index.html, app.js and the materialize CSS framework. Notice how we also add / to the files array this needs to be done because our application could be requested both as and Also notice that when adding files for caching, we can not only add files from the local filesystem but also files over https that our application requires. We then go ahead, open the cache (with the name of pwa-news-cache) and populate it with the files. If the promise to add the files to the cache resolves successfully, the installation of the service worker is complete. So far so good. Let s now add the functionality that would return us the application shell from the cache. To achieve this, we ll add an event listener for the fetch event. If there s a match for our request in the cache we return it, otherwise we ll attempt to fetch the data regularly. From this, we can deduce that the Service Worker acts as a proxy between the browser and the network. We can capture the network request, and act on it, for example, modify it. / 11

12 self.addeventlistener('fetch', event => { console.log( [SW] Fetching:, event.request); event.respondwith( caches.match(event.request).then(response => { if (response) { return response; return fetch(event.request); ) ); ); We can simplify the above code so that instead of the if conditional, we have an or statement in the return statement, or, even better, we can remove the curly brackets, and since we are using an arrow function, the return statement is going to be implicit:.then(response => response fetch(event.request)) We now have a service worker ready albeit very simple. (Don t worry we ll extend it soon enough). The last step that we need to make is to register the service worker. So, going back to our app.js file we need first to check if service worker is available in the browser, and if it is, we can register it: if ('serviceworker' in navigator) { navigator.serviceworker.register('./service-worker.js').then(() => console.log('registered Service Worker')).catch(error => console.log(error)); Now, if we bring the application offline, we still get some errors, but the browser can serve app.js without a problem since it s coming from the cache. Remember, earlier no files were shown in fact, we only saw downausur, now index.html, app.js as well as the materialise CSS framework are loaded from the cache meaning that the application shell is visible, without any data. / 12

13 Figure 6 - The application shell loaded from the cache Figure 7 - Network requests showing that some requests were successful / 13

14 Of course, the request to the API errors out because we haven t cached the returned data yet. To implement this, we ll be using what is called a cache-firstthen-network strategy. This strategy attempts to retrieve data from the cache, and if it s not available, it ll try the network. Please note that there are various caching strategies available and each has a different use case. For an exhaustive list of use cases, please consult this page: To develop this part of our application, we need to modify the service worker and intercept requests to our API and make sure that the response is stored in the cache remembering that this cache should be a different one. Having a cache for the application shell (the files) and another cache for the data makes sense, and it allows us to manage these caches separately. In light of this, we ll add a new cache name in our service worker: const datacachename = 'pwa-news-data-cache'; We ll then go ahead and separate the fetch request to the API from the request to the application shell files essentially we are extending the previously created event listener: self.addeventlistener('fetch', event => { console.log('[sw] Fetching:', event.request); const api = ' if (event.request.url.indexof(api) > -1) { event.respondwith( caches.open(datacachename).then(cache => { return fetch(event.request).then(response => { cache.put(event.request.url, response.clone()); return response; ).catch(error => console.error('error with cache fetch', error)); ).catch(error => console.error('error opening cache', error)) ); else { event.respondwith( caches.match(event.request).then(response => response fetch(event.request)).catch(error => console.error('error during network fetch', error)) ); ); Notice response.clone() above. We need to clone the response because it comes back as a stream and therefore it can be consumed once. Since we are going to be / 14

15 using it more than once (return it to the browser as well as add it to the data cache) we need to clone it. At the moment we are listening for fetch events, and if the event is a request to the API, we open the cache, update it and return the response itself. This is what constitutes a cache-first-then-network strategy. At this moment we can explore our service worker and see if the API requests (as well as the application shell) is cached: Figure 8 - The application shell cache Figure 9 - The application data cache Courses If you re interested in learning more about JavaScript, TypeScript, Node.js or even the MEAN stack please visit our site for a range of free and paid courses: Articles If you d like to read about the latest and greatest advancements in web related technologies, please visit our blog: Before we make our application entirely offline capable, let s do some code refactoring so that we can have a neater and cleaner codebase. It d be great to know when a network request happened so that we can differentiate between when to return data from the network (that could be more up to date) vs when to return data from the cache. / 15

16 Let s introduce a new variable in app.js: let datafromnetwork = false; Let s also create a separate function as well to create the cards for the news that arrive via the API: function generatenewscard(newsitem) { const main = document.getelementbyid('main'); const card = newscard.clonenode(true); card.queryselector('.card-title').innerhtml = `<strong>${newsitem.title</strong> by ${newsitem.author on ${newsitem.publishedat`; card.queryselector('.card-content-text').textcontent = newsitem.description; card.queryselector('.read-more').setattribute('href', newsitem.url); main.appendchild(card); Also, update the fetch call and place it within another function so that later we can call this as well: function makenetworkrequest() { return fetch(url).then(response => response.json()).then(news => { news.foreach(newsitem => generatenewscard(newsitem)); newscard.style.display = 'none'; ).catch(error => console.error(error)); This allows us to call both the makenetworkrequest() function multiple times when we are required to make a fetch call, and we can also re-use the generatenewscard() method here to render the cards. This separation of concern is going to pay off in the long term especially if we were to build a much larger, complex application. So now the last bit of making the application fully functional offline: the service worker part of our code is ready, but now we need to make sure that the application itself uses data from the cache if it s available. Therefore, the last bit that we need to modify is app.js: function start() { if ('caches' in window) { caches.match(url).then(response => { if (!response) { throw Error('No cached data!') return response.json(); / 16

17 ).then(news => { if (!datafromnetwork) { news.foreach(newsitem => generatenewscard(newsitem)) newscard.style.display = 'none'; ).catch(() => makenetworkrequest()).catch(error => console.error(error)); else { makenetworkrequest(); Remember that in the service worker we have placed a clone of the response to the cache using the URL as the key: cache.put(event.request.url, response.clone()); The start() function is going to be responsible for checking the existence of the cache in the browser. If it s available, we try to match the API request to an entry in the cache and if we have a response we serve that, iterate through them and build the cards. If the cache is not available, or if the cache does not contain data, we call the makenetworkrequest() function which attempts to make a fetch call to the API itself. Also notice how we are reusing the datafromnetwork variable if it s not false, meaning that if we do have data from the network we make sure not to overwrite this newer network data. Note the first catch block as well. This works in conjunction with the throw statement in the first promise. If the cache doesn t have a response (i.e. there s no cached data available) we throw an error, and that error is caught by the first catch block, which in turn calls networkrequest that attempts to get data from the network. This is how we can do the lookup in the start() function for the requests made in our application. Congratulations, we have just completed our first ever progressive web application that works offline and uses a service worker. We can completely disable the network, we can even stop the API (if there s one running locally), and our site still works and displays data coming from the data cache, as shown below. / 17

18 Figure 10 - The application still displays data even though the network is offline Let s also make a test. Add a new news item to the API and refresh the site in offline mode. We should not see the new item displayed of course. Once the application is brought online again, and once it is refreshed, the new news article is immediately going to be visible. Bringing the application offline again displays this latest article now since it has been placed in the cache. Discoverable Now it s time to make the application discoverable. What we mean by this is that the application should be easy to launch again by the user. This, of course, means that an app icon can be placed on the user s mobile and tapping that icon would launch the application. We can achieve this via a manifest file. manifest.json The application manifest is a JSON file that allows us to define how the application looks like when it s placed on the home screen of the user s mobile. In this JSON file, we can define many things, including the name of the application (what is / 18

19 going to be displayed on the home screen) along with the application icon as well as the URL to launch the application. { "name": "PWA News", "short_name": "News", "icons": [{ "src": "assets/news-100.png", "sizes": "100x100", "type": "image/png" ], "start_url": "/index.html", "display": "standalone", "background_color": "#fff", "theme_color": "#000" The last step is to tell the application about this manifest file, and we can very quickly do that by adding a <link> element in the <head> of our HTML page. <link rel="manifest" href="/manifest.json"> If we have done everything correctly, the details of the manifest file should also show up in the Chrome DevTools under Applications > Manifest. / 19

20 Figure 11 - The manifest file as seen by Chrome DevTools ios, Windows What we have done is excellent so far, but this manifest file is only relevant to Android devices. If we want to test against phones running ios and Windows, we need to make additional changes to our HTML file. Namely, we need to add a <meta> elements to tell the application about the apple touch icon as well as the Windows Tile Image. <meta name="apple-mobile-web-app-capable" content="yes"> <meta name="apple-mobile-web-app-status-bar-style" content="black"> <meta name="apple-mobile-web-app-title" content="shopping List"> <link rel="apple-touch-icon" href="assets/ios.png"> <meta name="msapplication-tileimage" content="assets/others.png"> <meta name="msapplication-tilecolor" content="#fff"> And now we are done. Users can add the icon to their home screens and launch the application from there. / 20

21 This free handbook has been brought to you by Tamas Piros Here are a few screenshots from an ios device. Notice how the icon from the manifest file looks like just another app installed from the App Store. Figure 12 - The application seen on a mobile device / 21

22 Push API Please note that the Push API is an experimental technology and each browser handles them slightly differently due to a lack of standards. In the list of requirements for an application to be considered progressive, we have mentioned that it should be re-engageable meaning that the user should be notified of changes to the application via push notifications. To achieve this functionality, we can rely on the Push API that is supported in the browsers. The Push API allows us to send push notifications to the users these work in the same way as notification would work on a mobile device. One of the critical requirements for an application to work with the Push API is to have an active service worker and luckily this is something that we already have. Just like how the service worker allowed us to add an event listener for fetch, we can do the same for a push as well. An active service worker can subscribe to push notifications. The process flow is simple. There s a server in place that sends a notification to the client, and if the right permissions are granted (via a popup when first initialising / launching the application), the client can receive the push event. The subscription object contains a few things amongst which we can find the endpoint and a public key. The endpoint is different for each browser, and the public key is used to encrypt the message. The endpoint URL plays an essential part in this whole process as it contains a unique identifier which identifies the route to the right device and it also helps the browser to select the appropriate service worker to handle the request. Since the Push notification contains some text, the server also adds this data as a payload which we can easily extract on the client side. Now, the Web Push API protocol is complex, and luckily there s an implementation of it already which we can use. It s a package called web-push available in npm. Note that some websites do not use Push Notifications correctly they ask for permission to send notifications upon the first load, which is usually a bad idea since the user didn t even have a chance to know what the site is about. Be wary of such user experience related quirks. Updating the Service Worker We ll need to make a few updates in our application, let s start with the easiest one the service worker. As mentioned earlier an active service worker is required for the Push notifications to work and in order to achieve this we need to add an event listener for the push events: / 22

23 self.addeventlistener('push', event => { console.log('[sw] Push received'); console.log('[sw] Push data', event.data); const payload = JSON.parse(event.data.text()); event.waituntil( self.registration.shownotification('pwa News', { body: `${payload.title (by ${payload.author)` ) ); ); Whenever the server sends a new notification, it does so with a payload. It goes without saying that it is possible to extract that payload and effectively access the properties of it providing the fact of course that it is a valid JSON object. The shownotification() method displayed above accepts a few parameters, the first one is the title of the notification, and as part of the options parameter, we pass in a body which is the notification s next. Other optional parameters include things like a badge, an icon as well as vibrate specifying a vibration pattern. Let s modify our API server so that it can be ready to handle Push Notifications for us. As mentioned earlier we need to have a signature and therefore a public and a private key pair as well. Luckily the web-push package can create that for us as well. const webpush = require('web-push'); const keys = webpush.generatevapidkeys(); webpush.setvapiddetails( ' keys.publickey, keys.privatekey ); function vapidpublickey(request, response) { response.json(keys.publickey); module.exports = { vapidpublickey ; Under the hood the Push API uses JSON Web Tokens (JWT) a detailed discussion of this topic is outside the scope of this handbook, but you can find an excellent explanation of it here: / 23

24 Next, we need to update our app.js file we need to add some push notification related checks as well, in this first round, we ll be asking for the user s permission. The push notification can only arrive if the user has authorised our application to send notifications. Note that you may not see the popup if you have, in the past, allowed the domain and port combination to display notifications. You can check this by going to Settings > Advanced > Content Settings > Notifications. We ll enable the Push Manager once the service worker has been registered. Since with every push notification that we want to send we ll also need to send a valid subscription, we ll need a way to save this subscription for later use. Therefore, we ll first modify our service worker registration code: if ('serviceworker' in navigator && 'PushManager' in window) { navigator.serviceworker.register('./service-worker.js').then(() => console.log('registered Service Worker')).catch(error => console.log(error)); navigator.serviceworker.ready.then(async registration => { serviceworkerregistration = registration; const subscription = await createsubscription(); const response = await fetch(' { method: 'post', headers: { 'Content-type': 'application/json', body: JSON.stringify({ subscription ) ); ).catch(error => console.log(error)); The above code first registers the service worker, then waits for it to be successful and then calls the function that creates a subscription: async function createsubscription() { const publickeyrequest = await fetch(`${baseurl/api/getpublickey`); const publickey = await publickeyrequest.json(); const finalkey = urlbase64touint8array(publickey); return serviceworkerregistration.pushmanager.subscribe({ uservisibleonly: true, applicationserverkey: finalkey ); / 24

25 Please note that at the moment Chrome doesn t support the vapidpublickey (the key generated by the server) in a base64-encoded string format. Therefore, we need to convert it to a Uint8 Array this function was taken from Google s implementation of the Push API. Calling savesubscription() for the first time asks the user if they want to start receiving notifications from our application. Figure 13 - Notification asking for the user's permission Once the user has accepted to receive notifications, we need to make sure that we store this subscription as we ll need to reuse that later. To achieve this, the following code needs to be added to the server: / 25

26 let savedsubscription = null; function savesubscription(request, response) { const subscription = request.body.subscription; savedsubscription = JSON.stringify(subscription); return response.json(); function getsubscription() { return savedsubscription; Note that here we save the subscription in a variable, in a production app this would have to be saved to a database for example. We d like to send notifications to the users if a new article arrives, and for demonstration purposes, we ll enable this functionality at the API level. When a new article arrives, we ll update the list of articles returned by the API, and if there s a valid subscription, we ll send a notification as well, which is going to be displayed by the browser. function addnews(request, response) { const freshnews = request.body; news.push(freshnews); const subscription = JSON.parse(pushRoutes.getSubscription()); if (subscription) { webpush.sendnotification(subscription, JSON.stringify(freshNews)).then(() => response.json(news)).catch(error => console.error('push notification error', error)); else { return response.json(news); That s all the code that we need to make our app re-engageable. / 26

27 Figure 14 - A push notification received HTTPS One last thought about progressive web applications one of the key requirements is that they should always run in a secure environment, this means that an application should always be running via HTTPS. This is an absolute necessity, and there s not much more to say about this always, always use HTTPS. Debugging tips The best way to debug service workers is to use Chrome DevTools in fact in some of the screenshots seen in this handbook show the use-cases for it. The most important tab is the Application tab, under which you can find a Service Worker menu this is where you can take a look at the service worker settings. / 27

28 Figure 15 - Chrome DevTools On the screenshot, some of the most important items are highlighted. Using the Application > Service Workers menu we see the currently active service worker as well as bring the service worker offline. Note the Update on reload option this is an important feature since this makes sure that the browser loads the latest version of the service worker upon refresh. Under Application > Manifest we can take a look at the manifest file details providing the fact that a manifest.json file has been provided to the application. Under Application > Cache we can explore the cache itself and see what it contains exactly. / 28

29 Also, note the Application > Clear Storage menu. When developing progressive web applications, we store some data in the cache, create manifest files, push notifications, register service workers. Clearing these up manually is quite a tedious task, but this option helps us to remove all storage items at one go. And last but not least, a practical thing would be to separate console.log() statements and have some prefix added to the log entries coming from the service worker vs the application so that it s easier to follow which message is logged from where. Throughout this handbook, the following notation applied: no prefix for logs coming from the application related files, [SW] prefix for logs coming from the service worker. Lighthouse Test We talked about a tool called Lighthouse before it scores an application based on a variety of things amongst which one is how progressive the application is. We can run a test on our application to see how well it s done. To get started with lighthouse, make sure that it s installed globally via npm: npm i -g lighthouse It s straightfoward to use this tool, and we can get it to auto-generate a report for us. Make sure that the application is up and running and execute the following command (replace the protocol and domain if needed): lighthouse view Figure 16 - Lighthouse PWA score The returned score for PWA is 91 and the only reason why we don t get a 100 is that the HTTP server doesn t do proper redirects to HTTPS. This is because a local development server is running. / 29

30 Conclusion Progressive Web Applications certainly have great use cases, and they help users who are not always connected to a network or who have some slow connection available to them. Over the past years there have been many ideologies around whether the application should be mobile first, element first, responsive, desktop first and probably a countless number of options. Even though this handbook is trying to highlight why progressive web applications are great they can be run on both desktop and mobile (and on mobile they do act like an actual application) as developers we need to make sure that we pick and choose the right technology to solve the right problem. In my opinion, this is the hardest thing to solve. Courses If you re interested in learning more about JavaScript, TypeScript, Node.js or even the MEAN stack please visit our site for a range of free and paid courses: Articles If you d like to read about the latest and greatest advancements in web related technologies, please visit our blog: / 30