Ten years ago, when smartphones were the new thing, the message went out that you needed to have a stand-alone app to run on the phone. Mobile development was a new kind of programming with unique challenges, but there were good reasons to do it at the time, such as top performance and promotion and software updates managed through the app store. However, to get access to all the features of the mobile device, you needed to write native code.
Today, mobile development still has unique challenges and expenses. However, the good reasons to invest in it have been frittering away. An alternative model, the progressive web, looks like a better choice when you consider all the factors.
To the user, a progressive web app (PWA) looks and behaves like a native app. It doesn’t look like the software is running in a web browser; it works when the device is offline; and users launch it from an app icon just like a “real” app. But behind the scenes, the app is not running as a native program on the device but as a full-screen website in the browser.
There are many significant advantages to choosing the progressive web model over the native app model, including:
- The client-side programming on all platforms is HTML/CSS/JavaScript. All means all, meaning the same web application can work with phones, tablets, desktops, notebooks, servers, watches—anything with a standards-compliant browser. You don't need to develop expertise in Objective-C for iOS, Java for Android, and something else for desktops.
- Updating the application involves changing files on the servers under your control. Apple and Google don’t need to be involved at all. Changes go out to all users at once (assuming the users are online).
- The programming model is standards-based, not controlled by one vendor.
That last bullet point is technically accurate, and yet it raises an important issue and the main problem with adopting progressive web apps today: The driving force behind PWAs is Google.
Innovation in your inbox. Sign up for the weekly newsletter.
Implementation issues
Google is, by far, the most aggressive in adopting new browser standards behind PWAs in Chrome. Other vendors, such as Mozilla, Microsoft, and, in particular, Apple, have been much less aggressive, though the April 2018 Microsoft update brings with it EdgeHTML 17, the fifth major version of the Microsoft Edge rendering engine. This release claims new developer capabilities for websites and web apps, including the foundation for full-featured PWAs on Windows.
This presents a major practical problem, since all web browsers on Apple’s iOS operating system, including Google Chrome, have to use Apple-provided rendering and JavaScript engines (see Section 2.5.6: “Apps that browse the web must use the appropriate WebKit framework and WebKit JavaScript.”) So PWA features can work on iPhones and iPads only if Apple supports them, and many of these features are unsupported in WebKit.
These new standards go beyond what most think of as HTML and JavaScript features. They create standards for a web audio API to process and synthesize audio, a JavaScript event for handling individual keyboard presses and releases, a speech synthesis API, and an API for getting input from USB gamepads. There is very little you can do in a native app that you can’t do in a PWA.
Apple, it should be noted, has a clear business interest in keeping apps native: Such apps must be distributed through its app store, where the company takes a large percentage of the app sale price, proceeds from in-app purchases, and advertising revenue. With PWAs, there is no need for a store to distribute apps, and since the software is just webpages, the advertising is done through the conventional web advertising networks (which are dominated by Google).
However slowly, Apple is adopting many of the key standards behind PWAs. If there is one most important standard for PWAs, it is service workers. Service workers, which are web code triggered by an event, run in the background of the webpage, basically like threads. Numerous other standards have extended service workers, such as Web Background Synchronization, which allows service workers to work, or to at least stay alive, even when faced with common challenges such as a user shifting away from the browser or the network becoming unavailable.
A certain sense of inevitability
Apple added support for service workers in iOS 11.3 and macOS High Sierra 10.13.4, although so far, only for the Safari web browser and applications that use the Safari control for browsing. Version 17 of Microsoft’s Edge browser, currently in pre-release and scheduled to be released very soon, will support them. At that point, all major browsers will support service workers and their rate of adoption should increase.
The advantages of PWAs are important for enterprises, not just for app startups. The ability to have one code base serving to desktops, phones, and tablets of any brand is a major plus for development savings and software quality. And when you need to make changes, you can do so just by updating the web server. This tracks well with the mobile-first approach that many websites are already taking.
So, if these PWAs are so great, where are they? Most existing PWAs are just demo-level programs. Wikipedia has a list of some. Ginger is a WebGL morphing demo that gets the point across of how far the web has come since, well, Wikipedia. Note that, just as the PWA rules require, Ginger lets you add an app icon for itself to the home screen and runs without any browser, just like a native app.
“Web apps” for devices aren’t strictly new. More than one company, Apple among them, has tried to make the web the programming model for mobile devices. But until Google put a lot of effort into advancing HTML and JavaScript standards, web apps were just too limited in capability. This was a feature, not a bug, of early web browsers to make web software unthreatening.
Google’s major push for PWAs came at the 2016 Google I/O conference. Most of its materials on the subject still relate to that event. The company's PWA checklist is a good guide to what (Google argues) defines such an app. Its baseline requirements are:
- Site is served over HTTPS.
- Pages are responsive on tablets and mobile devices. (Google has specific time requirements for this.)
- All app URLs load while offline.
- Metadata is provided for add to home screen.
- First load is fast even on 3G.
- The site works cross-browser.
- Page transitions don't feel like they block on the network (really a variant on the responsiveness requirement).
- Each page has a URL (i.e., single-page apps beware).
That’s just the baseline. Among other things, an “exemplary” PWA:
- Dims the screen when a permission request is showing.
- Appropriately informs the user when they're offline.
- Loads very fast, even on 3G.
- In general, doesn’t annoy the user with excessive prompts and notifications.
Adherence to these standards and the standards for HTML, CSS, and JavaScript should allow PWAs to work with little or no modification across all compliant web browsers and operating systems. This is, once again, not necessarily what Apple and Google have in mind, but it’s an inevitable outcome of a good standards process.
Historically, the challenge for standards such as these has been the arrival of new hardware features (imagine a camera detail such as zoom levels) that would be available to native code but not in the standard and inconsistently supported on different hardware platforms. Eventually, the hardware features become standard enough that a JavaScript-accessible API standard is warranted. The rate of such changes in the phone and tablet market has declined markedly in the past few years, and so it is increasingly possible to write PWAs that work effectively on all important platforms.
The other major challenge has been performance. HTML, JavaScript, and CSS are all high-level conceptual languages, and browsers can consume a lot of resources. Even on a full PC, browsers can feel slow, and certainly things would be worse on a phone. This problem has been addressed by more optimal programming of the browsers themselves and, more important, better hardware. The A11—Apple’s 64-bit processor in the iPhone 8, iPhone 8 Plus, and iPhone X—has 6-CPU cores; the Samsung Galaxy S8 and newer families offer 8-core CPUs from Qualcomm and Samsung depending on market, offering processing power that would be respectable on a desktop.
Progressive standards
There are also new web standards to improve performance of web apps, perhaps the most important being WebAssembly. This standard is a (machine) assembly language for a virtual machine architecture that can be served as part of a web app from the server. A developer compiles it from C, C++, or some other high-level language. It doesn’t run directly on the phone processor, but the translation from it to native code is simple and straightforward compared with that from JavaScript. The Mozilla description of WebAssembly explains it well. WebAssembly is supported by all the major browsers, including Safari.
If Apple is really resisting PWAs, it’s no longer a full-throated resistance. PWAs are not the talk of the tech town yet, but there is a certain inevitability to them. It makes sense. The day will come when you won’t have to go to the app store to get real, professional software for mobile devices. You might still want to, and Apple and Google will want you to, but it won’t be necessary. PWAs are yet another way technology will bootstrap innovation.
Progressive web apps: Lessons for leaders
- The advantage of PWAs is simplified development that applies across platforms.
- They rely on new standards that build on existing standards and technologies.
- PWAs are a logical extension of existing trends.
来源：JavaScript中文网 ，转载请注明来源 本文地址：https://www.javascriptcn.com/post/32493