Category Archives: Progressive Web Apps

Auto Added by WPeMatico

Welcoming Progressive Web Apps to Microsoft Edge and Windows 10

A little over a year ago, we outlined our vision to bring Progressive Web Apps (PWAs) to the more than half a billion devices running Windows 10. We believe PWAs are key to the web’s future, and couldn’t be more excited about their potential to enable more immersive web app experiences across all device form factors.
Today, we’re excited to take a major step from vision to reality, starting with some updates on previewing PWAs in Windows and our roadmap to bring PWAs to the Microsoft Store.
Beginning with EdgeHTML 17.17063, we have enabled Service Workers and push notifications by default in preview builds of Microsoft Edge—you can learn more about those features in Ali’s post, “Service Worker: Going beyond the page.” This completes the suite of technologies (including Fetch networking and the Push and Cache APIs) that lays the technical foundation for PWAs on Windows 10.
Over the coming weeks, we’re also kicking off some experiments with crawling and indexing quality PWAs from the Web to list them in the Microsoft Store, where users can find them just like any other app on Windows 10.
In this post, we’ll give a quick introduction to Progressive Web Apps – what they are, the problems they solve, and how we’ll be enabling them across Windows 10. We’ll explore how our indexing experiments will ramp to an end-to-end PWA discovery experience later this year, and how we’ll empower developers to differentiate their PWAs on Windows – including allowing developers to claim and monetize their PWAs in the Store, interact with customers via reviews and telemetry, and enhance the app with WinRT capabilities.
Let’s dive in!
What’s a Progressive Web App, anyway?
The excitement about PWAs in the developer community is almost palpable – but amongst all that excitement, it can be hard to pin down a single, concise, authoritative definition of a “Progressive Web App.” For the purposes of this discussion, here’s how we define a PWA:
Progressive Web Apps are just great web sites that can behave like native apps—or, perhaps, Progressive Web Apps are just great apps, powered by Web technologies and delivered with Web infrastructure.
Technologically speaking, PWAs are web apps, progressively enhanced with modern web technologies (Service Worker, Fetch networking, Cache API, Push notifications, Web App Manifest) to provide a more app-like experience.
Unlike a “packaged” web app experience, PWAs are hosted on your servers and can be updated without issuing new updates to an app store. Additionally, new web standards (such as Service Worker) enable interoperable ways to implement push notifications, support for offline scenarios, background refreshing, and more, without platform-specific code.
It’s beyond the scope of this post to give a full crash course in the component technologies of a PWA (for that, we highly encourage you to check out Progressive Web Apps on MDN for a starter). But at a high level, these features are built to enable native-like capabilities – offline, background wake/refresh, instant loading, push notifications, and installability.
Progressive Web Apps in Microsoft Edge and Windows 10
So what about PWAs in Microsoft Edge and Windows 10?
We’ve announced before in several venues that we’re all-in on PWAs. In fact, as hinted above, we want to take PWAs on Windows to the next level, by making them first-class app citizens in Windows. This follows from our general philosophy that the web platform, powered by EdgeHTML, is a core part of the Universal Windows Platform on Windows 10. Because of this any device running EdgeHTML 17 gets full access to the technologies and characteristics of Progressive Web Apps.
On other platforms, PWAs primarily originate from inside the browser, and can escape the browser in response to various prompts or menu options. We’re taking things one step further on Windows! Because a PWA can be a first-class citizen in the Windows Store, a user will be able to engage fully with an installed PWA—from discovery, to installation, to execution—without ever opening the browser.

Just for kicks, here is @davatron5000’s @godaytrip as a #PWA on a preview build of Windows 10! ????(inspired by: https://t.co/Flm63mmu6K) pic.twitter.com/t2Kr5MlTOX
— Kirupa ???? (@kirupa) February 1, 2018

On the other hand, in the browser context, all the benefits of being a PWA should still accrue to the web site, empowering the user to choose how and where they want to engage with the experience.
Progressive Web Apps in the Microsoft Store
The first and most obvious distinction here is that we believe PWAs should be discoverable everywhere apps are discoverable – this means they should appear in the Microsoft Store alongside native apps.
In the next release of Windows 10, we intend to begin listing PWAs in the Microsoft Store. Progressive Web Apps installed via the Microsoft Store will be packaged as an appx in Windows 10 – running in their own sandboxed container, without the visual or resource overhead of the browser.
This has a number of benefits to users: PWAs installed via the store will appear in “app” contexts like Start and Cortana search results, and have access to the full suite of WinRT APIs available to UWP apps. They can differentiate their experience on Windows 10 with enhancements like access to local calendar and contacts data (with permission) and more.
It also has exciting benefits to developers! Listing a PWA in the Store gives developers the opportunity to get more insight into their users with channels like reviews and ratings in the Store, analytics on installs, uninstalls, shares, and performance, and more. It also provides more natural and discoverable access to your web experience on devices where the browser is a less natural entry point, such as Xbox, Windows Mixed Reality, and other non-PC form factors.
The road from the Web to the Microsoft Store
PWAs provide a natural signal of intent to be treated as “app-like” in the Web App Manifest, which allows us to leverage Bing’s web crawler in combination with our Store catalog to identify the best candidates for indexing.
The Microsoft Store has a two-pronged approach to publishing Progressive Web Apps:
Developers can proactively submit Progressive Web Apps to the Microsoft Store
The Microsoft Store, powered by the Bing crawler, will automatically index selected quality Progressive Web Apps
Submitting to the Microsoft Store with PWA Builder
Proactively submitting a PWA to the Microsoft Store requires generating an AppX containing your PWA and publishing it to your Dev Center account.
The easiest way to generate an AppX with your PWA is the free PWA Builder tool. PWA Builder can generate a complete AppX for publishing using your existing site and Web App Manifest – both website and CLI options are available.
PWA Builder takes data from your site and uses that to generate cross-platform Progressive Web Apps.
Publishing manually gives you full access to the benefits above—fine-grained control over how your app appears in the Microsoft Store, access and the ability to respond to feedback (reviews and comments), insights into telemetry (installs, crashes, shares, etc.), and the ability to monetize your app. This also gets you access to all the other benefits of the Microsoft Dev Center, including promotion and distribution in the Microsoft Store for Business and the Microsoft Store for Education.
Automatically indexing quality Progressive Web Apps with the Bing Crawler
We’ve been using the Bing Crawler to identify PWAs on the web for nearly a year, and as we’ve reviewed the nearly 1.5 million candidates, we’ve identified a small initial set of Progressive Web App experiences which we’ll be indexing for Windows 10 customers to take for a spin over the coming weeks.
We will crawl and index selected PWAs from the web to be available as apps in the Microsoft Store
Over the coming months, we’ll be ramping up our automatic indexing in the Microsoft Store from a few initial candidates to a broader sample. Throughout this process, we’ll continue to vet our quality measures for PWAs, to make sure we’re providing a valuable, trustworthy, and delightful experience to our mutual customers on Windows devices.
Whether automatically indexed by the Store or manually submitted by the site owner, the Web App Manifest provides the starting set of information for the app’s Store page: name, description, icons, and screenshots. Developers should aim to provide complete and high-quality information in the manifest. Once in the Store, the publisher will have the option of claiming their apps to take complete control of their Store presence.
Quality signals for Progressive Web Apps
We’re passionate about making the Microsoft Store a home to trustworthy, quality app experiences. With that in mind, we’ve identified a set of quality measures for developers to keep in mind as you build PWAs.
We won’t ingest every app that meets these criteria, but will be including them in our considerations for candidates as we gradually expand our program.
Web App Manifests should suggest quality: In our initial crawl of sites looking for PWAs, we discovered over 1.5 million manifests across 800k domains. Looking at a selection of these sites, we discovered that not all are good candidates for ingestion. Some aren’t PWAs at all, and others have a boilerplate manifest generated by tools like favicon generators. We will be looking for non-boilerplate manifests that include a name, description, and at least one icon that is larger than 512px square.
Sites should be secure: Access to the Service Worker family of APIs requires an HTTPS connection on Windows and other platforms.
Service Workers should be an enhancement: We’ll look for a Service Worker as a signal for ingesting PWAs, but we also expect experiences to degrade gracefully if Service Worker is unsupported, as it may be on older browsers or other platforms. You can get started building a basic Service Worker with PWA Builder; Mozilla also has great recipes if you are looking for somewhere to start.
Sites should consider automated testing for quality: There are a number of tools out there for this, including our sonarwhal, Lighthouse, aXe, and more.
PWAs must be compliant with Microsoft Store policies: PWAs will need to meet the standards of the Microsoft Store, just like any other app. We will not ingest PWAs that violate laws or Store policies.
Once we have shipped these technologies to mainstream Windows customers with EdgeHTML 17, we will gradually expand our indexing of high-quality Progressive Web Apps into the Microsoft Store based on quality measures and the value they add to the Windows ecosystem.
PWA or UWP?
Given the overlap in terms of capabilities, we often get asked about the recommended approach: PWA or UWP. We see this as a false dichotomy! In fact, on Windows 10, the Universal Windows Platform fully embraces Progressive Web Apps, because EdgeHTML is a foundational component of UWP.
For developers who are building a fully-tailored UWP experience, building from the ground up with native technologies may make the most sense. For developers who want to tailor an existing web codebase to Windows 10, or provide a first-class cross-platform experience with native capabilities and enhancements, PWA provides an on-ramp to the Universal Windows Platform that doesn’t require demoting or forking existing web resources.
When evaluating native app development in relation to Progressive Web Apps, here are some of the questions we recommend asking:
Are there native features the Web can’t offer that are critical to the success of this product?
What is the total cost (time and money) of building and maintaining each platform-specific native app?
What are the strengths of my dev team? or How easy will it be to assemble a new team with the necessary skills to build each native app as opposed to a PWA?
How critical will immediate app updates (e.g., adding new security features) be?
In other words, the choice between PWA and native should be evaluated on a case-by-case basis. For example:
If you are looking to craft an experience that takes full advantage of each platform you release it on and you want to agonize over every UX detail in order to differentiate your product… native might be the best choice for you.
If you are maintaining a product on multiple native platforms in addition to the Web and they are all largely the same in terms of look & feel and capabilities, it may make more sense to focus all of your efforts on the Web version and go PWA.
If you are planning a brand-new product and the Web provides all of the features you need (especially when you also consider the additional APIs provided via the host OS), building a PWA is probably going to be a faster, more cost-effective option.
For a more in-depth discussion, check out our video from Microsoft Edge Web Summit 2017: PWA, HWA, Electron, oh my! Making sense of the evolving web app landscape.

Testing your Progressive Web Apps in Microsoft Edge and Windows 10
Service Worker, Push, and other technologies are enabled by default in current Insider builds in Microsoft Edge, and we intend to enable them by default when EdgeHTML 17 ships to stable builds of Windows 10 next year.
You can get started testing your PWA in Microsoft Edge today by downloading a recent build of Windows 10 via the Windows Insider Program, or using a free VM. We’ll be sharing more about Service Worker debugging features in the Microsoft Edge DevTools in a future post—stay tuned!
Service Worker features will be enabled for the UWP platform (including installed PWAs) with the upcoming release of Windows 10, but are currently not available to published apps in the Store, including on Windows Insider Preview builds. In the meantime, you can test them in Insider builds by sideloading your AppX using the install script provided by PWA Builder tools, or by running your PWA inside Microsoft Edge.
What’s next for Progressive Web Apps on Windows?
Over the coming months, we’re laser focused on polishing our initial implementation of the core technologies behind PWAs in EdgeHTML and the Universal Windows Platform—Service Worker, Push, Web App Manifest, and especially Fetch are foundational technologies which have a potentially dramatic impact to compatibility and reliability of existing sites and apps, so real-world testing with our Insider population is paramount.
In our initial implementation, we’ll be focused on those two components—the Service Worker family of technologies in Microsoft Edge, and PWAs in the Microsoft Store. Looking forward, we’re excited about the potential of PWA principles to bring the best of the web to native apps, and the best of native apps to the web through tighter integrations between the browser and the desktop. We look forward to hearing your feedback on our initial implementation and experimenting further in future releases.
In the meantime, we encourage you to try out your favorite PWAs in Microsoft Edge today, and get started testing your installable PWA on Windows, both via PWA Builder and in Microsoft Edge! We look forward to hearing your feedback and to digging in to any bugs you may encounter.
Here’s to what’s next!
– Kyle, Kirupa, Aaron, and Iqbal

#ifdef WINDOWS – Progressive Web Apps

Jeff Burtoft from the Web Apps team at Microsoft dropped by to share how web apps on Windows have evolved, all the way from regular web sites, to packaged web apps in Windows 8, Hosted Web Apps in Windows 10, and finally adopting Progressive Web Apps with support for Service Workers and native APIs.
We also covered the top 3 necessary components needed to build a PWA and the top 4 things developers can do to make sure their PWAs are successful on any platform. Check out the full video above and feel free to reach out on  Twitter or in the comments below for questions or comments.
Happy coding!

Service Workers: Going beyond the page

We’re thrilled to announce that today’s Windows Insider build enables Service Workers by default in Microsoft Edge for the first time.
This is an exciting milestone for us and for the web! These new APIs allow the web to offer better experiences when devices are offline or have limited connectivity, and to send push notifications even when the page or browser isn’t open.
This milestone also establishes the foundation for full-featured Progressive Web App experiences in Microsoft Edge and the Microsoft Store. We’ve carefully tailored our implementation together with Windows and are excited to be the only browser on Windows 10 to provide push handling in the background to optimize for better battery usage. We’ll have more to share about PWAs on Windows in the weeks ahead, so be sure to stay tuned!
We believe Service Workers are a foundational new tool for the web with the potential to usher in a new golden age of web apps. You can try out web experiences powered by Service Workers in Microsoft Edge on starting with today’s Windows Insider release, 17063.
Before we walk through how Service Workers work, let’s start with some context on how the web has tried to handle offline capabilities before Service Workers came along.
The state of the web
Not too long ago, the web’s capabilities were lagging behind what native apps could do. Browser vendors, standards bodies, and the web community have relentlessly attacked this gap over the last decade, with the goal of enabling richer web experiences.
A particularly egregious sore spot for the web has always been how it handled—or failed to handle—the lack of an internet connection, or a poor-quality connection. Offline and the web never really went well together—in most cases, we were given a frustrating error page that only made it clearer that the web’s greatest asset was also its greatest weakness: the internet. In contrast, native apps are typically designed to provide a good experience even while offline or experiencing spotty service.
On top of that, native apps can re-engage their users with push notifications. On the web, after the browser or the app disappears, so does your ability to deliver relevant information or updates to your users.
In the rearview: Application Cache
By 2012, we were able to do offline on the web by introducing a new standard: Application Cache (or App Cache for short). Developers could list URLs for the browser to keep in a special cache called the App Cache, so that when users visited the page they would see something other than an infuriating error page.
Unfortunately, this wasn’t the silver bullet we were looking for in terms of bringing offline to the web. There are more than a few well-documented limitations for App Cache that made it confusing and error prone for many users and web developers. The sum of it all was that there was little control in how the App Cache would work since most of the logic occurred behind-the-scenes in the browser.
That meant if you ran into an issue, it would be exceedingly difficult to understand how to resolve it. There was an obvious need for something that gave greater control to developers by offering the capabilities of App Cache but made it more programmatic and dynamic while doing away with many of its limitations that made it difficult to debug.
Hit Rewind
App Cache left a lot to be desired. For the next swing at enabling offline scenarios, it was clear that browsers needed to provide web developers true control over what would happen when a page and its sub-resources were downloaded, rather than having it automatically and transparently handled in the browser.
With the ability to intercept network requests from a page and to prescribe what to do with each, site authors would be able to respond back to the page with a resource that it could use. Before we get there, it seems that we would need to revisit one of the most fundamental aspects of the web: fetching a resource.
How fetching!
As you may recall from my last post on Fetch, we now have the fetch() method as well as the Request and Response primitives. As a refresher, here’s how you might retrieve some JSON data using the fetch API:
https://gist.github.com/kypflug/20cfe09274331571b545f08f273d3e7d
Every request that happens on a page (including the initial navigation, CSS, images, scripts and XHR) is defined as a fetch. The fetch() method (as shown in the code sample) is just a way to explicitly initiate a fetch, while implicit fetches occur when loading a page and all of its sub-resources.
Since we’ve unified the concepts of fetching resources across the web platform, we can provide site authors the chance to define their own behavior via a centralized algorithm. So, how do we pass that control over to you?
Service worker: the worker that serves
Web workers have long been a great tool to offload intensive JavaScript to a separate execution context that doesn’t block the UI nor interaction with the page. Given the right conditions, we can repurpose the concept of a web worker to allow a developer to write logic in response to a fetch occurring on a page. This worker wouldn’t just be a web worker, though. It deserves a new name: Service worker.
A service worker, like a web worker, is written in a JavaScript file. In the script, you can define an event listener for the fetch event. This event is special, in that it gets fired every time the page makes a request for a resource. In the handler for the fetch event, a developer will have access to the actual Request being made.
https://gist.github.com/kypflug/e39fd8caf4b5c5bff92af9478a2778f2
You can choose to respond with a fetch for the provided Request using the JavaScript APIs which returns a Response back to the page. Doing this essentially follows the typical browser behavior for that request—it’s not intrinsically useful to just do a fetch for the request, ideally it would be more useful if we save previous Response objects for later.
Cache it!
The Cache API allows us to look up a specific Request and get its associated Response object. The APIs give access to a new underlying key/value storage mechanism, where the key is a Request object and the value is a Response object. The underlying caches are separate from the browser’s HTTP cache and are origin-bound (meaning that they are isolated based on scheme://hostname:port) so that you cannot access caches outside of your origin. Each origin can define multiple different caches with different names. The APIs allow you asynchronously open and manipulate the caches by making use of Promises:
https://gist.github.com/kypflug/b45c38e3aab068e2ed73f5b6a2fcf592
These caches are completely managed by the developer, including updating the entries and purging them when they’re no longer needed – this allows you to rely on what will be there when you may not necessarily be connected to the internet.
Although the Caches API is defined as part of the Service Worker spec, it can also be accessed from the main page.
So now you have two asynchronous storage APIs to choose from: Indexed DB and the Caches API. In general, if what you’re trying to store is URL-addressable, use the Caches API; for everything else, use Indexed DB.
Now that we have a way to save those Response objects for later use, we’re in business!
Back to the worker
With a service worker, we can intercept the request and respond from cache. This gives us the ability to improve page load performance and reliability, as well as to offer an offline experience. You can choose to let the fetch go through to the internet as is, or to get something from the cache using the Cache API.
The first step to using a service worker is to register it on the page. You can do this by first feature-detecting and then calling the necessary APIs:
https://gist.github.com/kypflug/5c8946ab14d63ae1220674e973d9275f
As part of the registration, you’ll need to specify the location of the service worker script file and define the scope. The scope is used to define the range of URLs that you want the service worker to control. After a service worker is registered, the browser will keep track of the service worker and the scope it is registered to.
Upon navigating to a page, the browser will check if a service worker is registered for that page based on the scope. If so, the page will go on to use that service worker until it is navigated away or closed. In such a case, the page is said to be controlled by that service worker. Otherwise, the page will instead use the network as usual, and will not be controlled by a service worker.
Upon registration, the service worker won’t control the page that registered it. It will take control if you refresh the page or you open a new page that’s within its scope.
After initiating the registration of a service worker, it will go through the registration process. That will involve going through the different phases of its lifecycle.
The service worker lifecycle
Let’s unpack the different phases of the service worker’s lifecycle, starting with what happens once you try to register it.
Installing
This is the first step that any service worker goes through. After the JavaScript file has been downloaded and parsed by the browser, it will run the install event of your script. That’s when you’ll want to get everything ready such as priming your caches.
In the following example, the oninstall event handler in the service worker will create a cache called “static-v1” and add all the static resources of the page to the cache for later use by the fetch handler.
https://gist.github.com/kypflug/25727eb1dc9338e58b199ced638ebaa2
Installed
Once the service worker is installed, the setup is complete, and the service worker is awaiting all pages/iframes (clients) that are controlled by this service worker registration to be closed so that it can be activated. It could be potentially problematic to change the service worker for pages that are still actively using a previous version of the service worker, so the browser will instead wait until they’ve been navigated away or closed.
Activating
Once no clients are controlled by the service worker registration (or if you called the skipWaiting API), the service worker goes to the activating phase. This will run the activate event in the service worker which will give you the opportunity to clean up after the previous workers that may have left things behind, such as stale caches.
In this example, the onactivate event handler in the service worker will remove all caches that are not named “static-v1.”
https://gist.github.com/kypflug/247156862fe818bd9f66e0b5812f0502
Activated
Once it’s been activated, the service worker can now handle fetch and other events as well!
In this example, the onfetch event handler in the service worker will respond back to the page with a match from the cache if it exists and if there isn’t an entry in the cache, it will defer to making a fetch to the internet instead. If that fetch fails, it will resort to returning a fallback.
https://gist.github.com/kypflug/547194a4e5f80eb34720541e77b31d6f
Redundant
The final phase of the service worker is when it is being replaced by another service worker because there’s a new one available that is going to take its place.
There’s more to it: the big picture
So far, we’ve explored the following service worker events: install, activate, and fetch. Install and activate are considered lifetime events while fetch is considered a functional event. What if we could expand on the service worker’s programming model and introduce other functional events that could plug in to it? Given that service workers are event-driven and are not tied down to the lifetime of a page, we could add other events such as push and notificationclick which would present the necessary APIs to enable push notifications on the web.
Push it to the limit
Push notifications provide a mechanism for developers to inform their users in a timely, power-efficient and dependable way, that re-engages them with customized and relevant content. Compared to current web notifications, a push notification can be delivered to a user without needing the browser/app or page to be opened.
The W3C Push API and Notification API go hand-in-hand to enable push notifications in modern browsers. The Push API is used to set up a push subscription and is invoked when a message is pushed to the corresponding service worker. The service worker then is responsible for showing a notification to the user using the Notification API and reacting to user interaction with the notification.
A standardized method of message delivery is also important for the W3C Push API to work consistently across all major browsers where application servers will need to use multiple push services. For instance, Google Chrome and Mozilla Firefox use Firebase Cloud Messaging (FCM) and Mozilla Cloud Services (MCS), respectively while Microsoft Edge relies on the Windows Push Notification Service (WNS) to deliver push messages.
To reach reasonable interoperability with other browsers’ messaging services, WNS has now deployed support for the Web Push protocols being finalized within IETF, as well as the Message Encryption spec and the Voluntary Application Server Identification (VAPID) spec for web push. Web developers can now use the Web Push APIs and service workers to provide an interoperable push service on the web.
To start, you’ll first need to make sure your web server is setup to send pushes. The Web-Push open-source library is a great reference for anyone new to web push. The contributors have done a reasonable job in keeping up with the IETF specs. After starting up a node.js server based on the web-push library, you’ll need to setup the VAPID keys. Keep in mind that you’ll need to use HTTPS as it is required for service workers and push. You only need to set up the VAPID keys once which can be generated easily using the corresponding function in the web-push library.
https://gist.github.com/kypflug/d431c41f3b39e0e4e89e05aa59ecbaa4
Once that’s all sorted out, it’s time to take advantage of push in your site or app. Once the page loads, the first thing you’ll want to do is get the public key from the application server so that you can set up the push subscription.
https://gist.github.com/kypflug/8020af4245f5afe3ddd95cbe3527011e
With the public key in hand, as before, we’ll need to install the service worker, but this time, we’ll also create a push subscription.
https://gist.github.com/kypflug/154e8984cfc20d8820cecaa7536154a1
Before a new push subscription is created, Microsoft Edge will check whether a user granted permission to receive notifications. If not, the user will be prompted by the browser for permission. You can read more about permission management in an earlier post about Web Notifications in Microsoft Edge. From a user’s perspective, notifications from the page or from a push service appear identical, so we are using the same permission for both types of notifications.
To create a push subscription, you’ll need to set the userVisibleOnly option to “true” – meaning a notification must be shown as a result of a push – and provide a valid applicationServerKey. If there is already a push subscription, there is no need to subscribe again.
At any point when a push is received by the client, a corresponding service worker is run to handle the event. As part of this push handling, a notification must be shown so that the user understands that something is potentially happening in the background.
https://gist.github.com/kypflug/6aa49c671ce351cf6d3b67cdaecda316
Of course, after a notification is shown, there is still the matter of dealing with when its been clicked. As such, we need to have another event listener in the service worker that would handle this case.
https://gist.github.com/kypflug/bc17aa590c18753df9ca07e4c0d7b157
In this case, we first dismiss the notification and then we can choose to open a window to the intended destination. You’re also able to sort through the already open windows and focus one of those, or perhaps even navigate an existing window.
Push: The Next Generation
As part of our ongoing commitment to expanding the possibilities of the web, Microsoft Edge and PWAs in Windows will handle these service worker push event handlers in the background—there’s no need for Microsoft Edge or your PWA to be running for the push to be handled. That’s because we’ve integrated with Windows to allow for a more holistic approach to push notifications.
By leveraging Windows’ time-tested process lifetime management, we’re able to offer a system that reacts appropriately to system pressures such as low battery or high CPU and memory usage. For users, that means better resource management and battery life expectations. For developers, it means a push event handler that will get to run to completion, without interruption from user actions such as closing the browser window or app. Note that a service worker instance that is running in the foreground for the fetch event will not be the same as the one in the background handling the push event.
Notifications in Microsoft Edge and PWAs will be integrated in the Windows Action Center. If a user receives a notification and didn’t get the chance to act on it, it will get tucked away into Action Center for later, so notifications never get left unseen. Action Center will also group multiple notifications coming from the same domain, so that users have an easier time sorting through them.
Service worker: properties
I’d like to take a moment to go over some things you should keep in mind when using service workers in your web app or site. In no particular order, here they are:
HTTPS-only. Service workers will not work in HTTP; you will need to use HTTPS. Fortunately, if you’re testing locally, you’re allowed to register service workers on localhost.
No DOM access is allowed. As with web workers, you don’t get access to the page’s object model. This means that if you need to change something about the page, you’ll need to use postMessage from the service worker to the page so that you can handle it DOM changes from the page.
Executes separate from page. Because these scripts are not tied to the lifetime of a page, it’s important to understand that they do not share the same context as the page. Aside from not having access to the DOM (as stated earlier), they won’t have access to the same variables available on the page.
Trumps App Cache. Service workers and App Cache don’t play well together. App Cache will be ignored when service workers are in use. Service workers were meant to give more control to the web developer—imagine if you had to deal with the magic of App Cache while you’re trying to step through the logic of your service worker!
Script can’t be on CDN. The JavaScript file for the service worker can’t be hosted on a Content Distribution Network (CDN), it must be on the same domain as the page. However, if you like, you can import scripts from your CDN.
Can be terminated any time. Remember that service workers are meant to be short-lived and their lifetime is tied to events. In particular, service workers have a time limit in which they must finish executing their event handlers. In other cases, the browser or the operating system may choose to terminate a service worker that impacts the battery, CPU, or memory consumption. In either case, it would be prudent to not rely on global variables in the service worker in case a different service worker instance is used on a subsequent event that’s being handled.
Only asynchronous requests allowed. Synchronous XHR is not allowed here! Neither is localStorage, so it’s best to make use of Indexed DB and the new Caches API described earlier.
Service worker to scope is 1:1. You’ll only be able to have one service worker per scope. That means if you try to register a different service worker for a scope that already has a service worker, that service worker will be updated.
Recap
Service workers are so much more than an HTTP proxy! They are the foundation of a web app model that enables event-driven JavaScript to run, independent of web pages. Service workers were brought in to the web platform as a necessity to enable offline use cases, but it’s clear that they can do so much more, as we continue to extend their capabilities to other scenarios. Today we have push, but in the future, there will be other exciting capabilities that will bring the web that much closer to offering the captivating and reliable experiences we’ve always wanted.
Go put a worker to work!
So, what are you waiting for? You can get started testing service workers in Microsoft Edge today by installing the Windows Insider Preview build 17063 or higher. We’d love to hear your feedback, so please share any bugs you encounter or reach out to us on Twitter to get in touch!
— Ali Alabbas, Program Manager, Microsoft Edge
— Jatinder Mann, Program Manager, Microsoft Edge

Microsoft Edge Web Summit 2017 recordings are now available on Channel 9

Last week we welcomed hundreds of local developers and thousand of online viewers to our third annual Microsoft Edge Web Summit! Videos and slides from each session are now available to stream or download on Channel 9.
Learn about what’s new in EdgeHTML 16 in the keynote at Microsoft Edge Web Summit 2017.
Our sessions will bring you up to date on what’s in store for EdgeHTML 16, including learning how to use new and updated features like CSS Grid Layout, object-fit and object-position, WebVR, and the Web Payments API.

Learn about how to build faster websites with a fast and furious tour of web performance in the real world, and how to keep your development and testing on track with sonar, a new open-source, community-owned linting tool for the web. And make sense of the always-evolving web app landscape while blending the best of web and native with Progressive Web Apps.

Or go on a deep dive into the inner workings of the browser, to learn how we’re constantly rebuilding Microsoft Edge to be more secure, more accessible, and faster than ever, with every release we ship.

That’s just the beginning – there’s lots more to see on Channel 9, and we’ll have more to share about these topics and more in the coming weeks right here on the Microsoft Edge Dev Blog.
Thanks for joining us at Microsoft Edge Web Summit 2017 – we can’t wait to see you next year!
— Kyle Pflug, Senior Program Manager, Microsoft Edge