When changes occur gradually, step by step, it is sometimes difficult to notice how dramatic and comprehensive they are. It would seem that just a few years ago, the web platform was playing with the native application on almost all fronts, and the gulf between what could be done in the browser and what was available for applications downloaded from stores such as Apple App Store or Google Play Store, was terribly huge. One evidence of this gap is that in 2007 the web was in fact the main platform for developing applications for the first iPhone, but this platform clearly did not take off. The App Store appeared only a year later with the second version of the operating system, and immediately there was a boom of native applications, which formed the market landscape the way we know it now.
Much has changed since then, and web technologies have not stood in place. They took the path of removing restrictions, and what was previously impossible in principle - working offline, background data synchronization, push notifications, support for one-click logins and payment by credit card, Apple Pay, Google Pay and other methods built into the browser is now a reality. These functions organically complement the main part of the platform - HTML / CSS and JavaScript, which in recent years has been developing at a more than active pace. For example, a new project Houdini , which is still at a rather early stage, removes almost all restrictions on what can be done with CSS, allowing you to create your own layouts and use them along with Grid and Flexbox, among other things, and open programmatic access to CSS internals engine. But even without Houdini, you can already create CSS animations running at 60 FPS (frames per second).
The development of web standards, which is underway now, was liked by developers. Many, not without reason, believe that developing using web technologies is faster, simpler and cheaper, so if you look, for example, at modern desktop applications, we will see that most of them are written in Electron, a framework that allows you to write applications for Windows, Linux and macOS based on web technologies. Examples of Electron applications are Visual Studio Code, Slack, Skype on the desktop, etc.
On the other hand, cross-platform, which is an integral part of web technologies, is now more relevant than ever. Support for separate independent code bases for iOS and Android is very expensive. Therefore, even for native applications, developers are increasingly choosing cross-platform technologies, such as React Native, Xamarin, or Flutter from Google (if you are a mobile developer and have not yet looked at Flutter , I highly recommend doing it, even for educational purposes). And with PWA, we got something that everyone had long dreamed of - truly cross-platform applications.
Speaking about the lifting of the limitations of the web platform, it is impossible not to mention WebAssembly. Now, thanks to this technology, there are virtually no restrictions on the speed of code execution in the browser and the programming languages used. Already, you can achieve performance just half the size of a native C code that runs directly in the operating system, and this is not the limit. Of course, this does not mean that you need to throw away JavaScript and switch to writing user interfaces to C or Rust, as a bunch of JavaScript + Angular, React or Vue.js is extremely effective for this purpose, and JavaScript itself (ECMAScript), available to us today - This is in fact a completely new, convenient and modern language with support for async / await, the usual class syntax, destructuring, patterned strings, and much more. But WebAssembly brings performance in critical segments like games, AR / VR, artificial intelligence, audio and video processing to native performance, and it costs a lot. In addition, it is now much easier to port existing code to C, C ++, Rust, C # and other programming languages in the browser. A good example of such porting is the recently introduced AutoCAD, running in a browser using WebAssembly.
Having a fast runtime environment (with direct access to the video card) on the device is also important for the reason that taking into account modern requirements for privacy and security, when some data simply cannot leave the client and go to the server, all processing of this data needs to be done in the client application. For example, if we listen to a microphone in anticipation of a key phrase, or analyze the stream from the camera, users are unlikely to agree to transfer to the server all the sound and video for processing. Now we have access to such libraries as TensorFlow.js , which allow us not only to launch trained models (neural networks) in the browser, but also to perform additional training of these models directly on the client. Which in many scenarios increases security and privacy and reduces the load on the server.
Another area in which the limitations of the web platform traditionally manifested itself was access to the operating system and the hardware capabilities of the user's device. But even here the restrictions are gradually erased, although it must be admitted that on iOS they are erased much more slowly than on Android. If we talk about interaction with the operating system, the Clipboard API for working with the clipboard recently appeared, the Presentation API for detecting the connection of a second monitor / projector and controlling what is displayed on it, the Web Share API for integrating with the system sharing dialog (while the web application can act only as a source, but work is underway on receiving data, the Web Share Target API can be tested in Chrome by including the Experimental Web Platform features in about: flags). And if we talk about sensors and data transfer, then we have the Web Bluetooth API available for working with physical devices located nearby (which is very actively used in IoT solutions), as well as the new Generic Sensor API for working with various sensors, such as an accelerometer, a gyroscope , light sensor, compass and others. And I have not yet mentioned the web standards that have been around for quite some time, such as working with the camera and microphone, supporting vibration, obtaining information about the battery, the type and speed of the network, and the available memory of the user's device.
Thanks to all these changes and innovations, now the web and native applications no longer share the chasm. Now they stand shoulder to shoulder.
But do not take my words as a sign that the capabilities of native applications and web platforms have become equal. Roughly speaking, if five years ago, the web platform provided opportunities that were sufficient for 20% of applications (here I mean applications that require complex logic, and not websites with content - for such cases there is AMP - Accelerated Mobile Pages and similar technologies, covering content scenarios from blogs and news sites to online stores and websites of various institutions and organizations, almost one hundred percent), and in other cases it was necessary to create native solutions, now there is enough 70-80% of web platform capabilities Uchaev. And for more and more applications, developers have a choice. Often this choice is the coexistence of PWA and the native application, as is the case with Uber, Starbucks, Aviasales, Twitter, Tinder, Google Maps, AliExpress and others.
Source: https://twitter.com/necolas/status/829128165314306048
What are these features that require the creation of native applications, or at least packing web applications using Apache Cordova or other means, for distribution through application stores?
- Work with contacts and calendar on the user's device.
- Sending / receiving SMS, making phone calls directly from the application. Interaction with the phone's SIM card.
- Work with NFC
- Geofencing
- Work with flash and non-standard sensors, such as pressure sensor, pulse meter, etc.
- Low-level work with the system - management of applications, system settings, full access to the storage.
- Creating keyboards and widgets.
- Register an application as a default application for opening any type of file or type of link.
Naturally this is an incomplete list. On the other hand, I have no doubt that many of these features will be available for the web platform in the very near future. But you should not expect that the operating systems and their platforms will also stand still. Yes, the gap will narrow, but there will always be something that is available only for native applications. Therefore, if you are a mobile developer with a focus on iOS or Android, then it is vital that you always be one step ahead in order for your applications to be the best on the market.
Do not forget that web applications have features that are inaccessible to the native. This primarily relates to the distribution of applications, the cost of attracting users and the lack of dependence on the will of the owner of the application store and the speed of checking for updates by the store. Yes, according to statistics, users on mobile devices spend much more time in applications and less in the browser, but on average, half of users set 0 (zero) new applications per month, and most of the time spent in applications falls on giants, such as Facebook . On the other hand, users visit more than one hundred different sites per month and easily visit new sites. Therefore, the cost of attracting a user to the site (web application) could be up to ten times less than the cost of attracting a user to an application downloaded from the store. The Google Play Instant technology partially solves this problem, allowing you to launch native Android applications via a link from the browser, bypassing the store and without installation. Such applications naturally have limited functionality, but give a very good conversion. That only confirms the hypothesis that the distribution model of web applications is rather an advantage. Although the presence in the app stores, especially at the top of the ratings, also allows you to attract users, but now it works much worse than a decade ago, as there are significantly more apps in the stores.
If you need the presence of your web application (PWA) in the app stores, this is also possible. Microsoft Store already supports adding PWA. In the case of other stores, you can pack the application manually or use a ready-made tool, such as the pwabuilder.com website which, among other things, allows you to generate Apache Cordova-based packages from the PWA for the Apple App Store and Google Play. In addition, in future versions of Chrome for Android, the system will be able to embed PWA into Android applications using the Trusted Web Activities mechanism.
Progressive Web Apps in 2018
When they talk about web applications that are close to the native user experience, interface, speed and capabilities, use the term PWA - Progressive Web Apps . PWA is not some kind of framework or SDK. It is rather an approach, or, if you will, a philosophy of how to build modern web applications.
From a technological point of view, PWA uses modern web standards available in browsers, and nothing more. The PWA approach does not impose any particular restrictions on the web applications themselves. For example, PWA may or may not be one-page (SPA - single page applications) applications. It is only important that all users interact with your application, and the approach of gradual (progressive) improvements is used - the more modern the user's browser, the more opportunities it will receive.
The main feature of PWA and the fact that it allows us to call the web application the proud name of Progressive Web App is support for offline work using the Service Workers mechanism and the associated ability to add application icons to the start screen of the user's device (we don’t want to add the device start screen of the application that will not load without an Internet connection?).
Service Workers provide a unique opportunity to run the code separately from the pages of your site, even when the pages themselves may be closed (but it will still not work for a long time, the restrictions are significant). And this opportunity finds more and more applications in new web standards.
In the field of implementation of web standards related to PWA, in the spring of 2018, a revolution occurred. The term PWA has been widely used for several years, but before that all this only referred to the Google Chrome browser, and offline work was initially supported on both the desktop and Android, but application installation worked only on Android. Many developers still perceive PWA as a purely Android technology. But in iOS 11.3, which was released in March 2018, Apple added support for Service Workers to mobile Safari. Support has also been added to Safari for macOS. Microsoft, in turn, already a month after Apple, in April 2018, added support for Service Workers to its Microsoft Edge browser. In addition, on Windows 10, PWA distribution through the Microsoft Store is now supported. At the next stage, we expect the possibility to install PWA on the desktop from browsers on all platforms, and not only on Chrome OS, where it already works.
You can test the installation on the desktop by turning on Desktop PWAs and App Banners or Experimental app banners in about: flags. After enabling these experimental features, the PWA installation interface in Chrome on the desktop will look like the one shown in the screenshot below.
With the arrival on the desktop, PWA will most likely occupy a part of the niche in which Electron now dominates.
Thus, it is already possible to provide offline work using the Service Workers mechanism on iOS, Android, Windows, Linux, macOS and Chrome OS in Chrome, Safari, Firefox, Edge and Samsung Internet browsers. And on all mobile platforms, adding an application icon to the start screen is already supported.
Source: https://caniuse.com/#feat=serviceworkers
Half a year ago, it was difficult to even imagine that the introduction of technologies related to PWA would proceed at such a rapid pace. In the screenshot below, you can see part of the iOS start screen with PWA icons that are indistinguishable from native applications installed through the store. And I would like to separately note that speaking of iOS, I mean both the iPhone and the iPad - there is no difference in PWA support between the tablet and the phone.
Source: https://medium.com/@firt/progressive-web-apps-on-ios-are-here-d00430dee3a7
In addition to the introduction of modern web standards in various browsers, there are changes and improvements in the work of PWA in Chrome. And if the display of the PWA installation icon in OmniBox (address bar and search bar) in Chrome is still under development, then the installation of PWA on Android using the WebAPK mechanism (APK - Android Package, container of Android applications) is already working. Initially, PWA after installation was just a browser shortcut on the start screen. Now this mode is also supported. PWA labels contain a small browser icon in the corner. But now the main installation method is WebAPK. Essentially, PWA on Android is becoming full-fledged applications that are generated on the fly during installation. And PWA is now displayed not only as a shortcut on the start screen, but also appears along with other installed native applications in the list of all applications. So far, the WebAPK mechanism does not allow access to any native features of the operating system that would be inaccessible from the browser (except for support for opening links of the domain from which the PWA was downloaded, in PWA itself, and not in the browser), but the fact that PWA are from the point of view of the operating system full-fledged applications, can not but rejoice.
The maturity of the Service Worker technology also confirms the fact that all popular SPA (single page applications) creation tools either support the generation of Service Workers into one command, as done in the Angular CLI, or even generate the default Service Worker, as in case with create-react-app. On the other hand, many developers want to better understand what, how and when they are cached in the application, so they have a desire to write the code for the Service Worker themselves. But this is not the best idea, fraught with difficult reproducible errors, and as a result, users can stay with the outdated cached version of the application. Intermediate, and the best option from my point of view, is the use of libraries, out of the box providing the implementation of caching and background synchronization strategies, but providing maximum freedom for developers. The most popular of these libraries at the moment is the Workbox . For example, with the Workbox, caching images, and thus, so that there are no more than sixty of them in a cache, for a period of up to thirty days, looks like this.
workbox.routing.registerRoute( /\.(?:png|gif|jpg|jpeg|svg)$/, workbox.strategies.cacheFirst({ cacheName: 'images', plugins: [ new workbox.expiration.Plugin({ maxEntries: 60, maxAgeSeconds: 30 * 24 * 60 * 60,
Do not think that the implementation of work offline and caching implies the support of one hundred percent of the application functionality in offline mode, although this is also possible and can be a good long-term goal. The main thing is that in the absence of an Internet connection, users do not have the impression that the application is not working (worst of all, if they see a dinosaur in Chrome, speaking about the impossibility of downloading). Therefore, everything will be a good option, from displaying the application in gray with a message about the absence of an Internet connection to the implementation of all functionality in offline mode.
Being carried away by caching, you should not forget that it significantly speeds up only the second loading of your application (and of course allows you to add support for working offline). Therefore, if you really want to improve the user experience, you need to speed up the first download as much as possible. One way to do this is Server Rendering. Thanks to rendering on the server, the user will be able to immediately see the content of the application, which reduces the likelihood that the application will be closed before being loaded, because the user is tired of waiting. And it increases the likelihood of re-entry, and as a result gives hope that the efforts spent on caching support will be really in demand. Therefore, your web applications must be isomorphic - so that the same JavaScript code can work both on the client side and on the server side.
So, you have decided that your next web application will be PWA. The question arises, and what opportunities other than Service Worker'ov implement? If you are developing a new application, I recommend starting to add features in the order as listed in the list below. All of these features make sense to the user both together and separately.
But first, read the checklist from Google , which describes the main features of good web applications.
If you already have an existing application, and if you are in the process of developing a new web application, I recommend starting with an audit. This can be done using the Lighthouse tool, which is available to run from the Chrome Developer Tools (Audits tab), as well as the NPM package. Lighthouse automates many checks from a check list. Ideally, you should not only start with an audit using the Lighthouse, but you also need to embed it in the build process. Lighthouse allows you to see the strengths and weaknesses of your web application, and also helps you get ideas on what other features, web standards and best practices can be implemented.
If you want to try very experimental features, use the Origin Trials mechanism in Google Chrome. With this mechanism, you can, after submitting and approving the application, include new experimental web standards for users of your web application. Such a mechanism is used to test web standards not for the entire Internet (since in this case it will be very difficult to make changes or abandon the standard altogether), but only for a limited number of selected sites that are interested in these standards. At the time of this writing, origin trial was available, for example, for WebXR Device API — a new standard of mixed reality (mixed reality) implementing AR (augmented reality) and VR (virtual reality) support.
Conclusion
Over the past decade, web technologies have gone from the stage of hopes and expectations of the universal dominance of Web 2.0 and HTML5 (I wonder if any people are using these hacks right now?) When Steve Jobs in 2007 declared that “you do not need the SDK. You have everything you need (if you know how to write applications using the latest web standards) to write awesome iPhone apps today. ”To the 2010-2013 disappointment stage when Chris Anderson of Wired magazine in 2010 said that“ As much as we love an open, unlimited web, so much we abandon it in favor of simpler, more elegant services [native applications] that just work. ”, And Mark Zuckerberg in 2012 noted that“ The biggest mistake we made as a company is HTML5 bid, not naive. ”
But the darkest night happens before dawn, and for web technologies in competition with native applications, such a dawn was the movement associated with Progressive Web Apps. Now, in 2018, all browsers already support the basic PWA capabilities — working offline and installing on the start screen on mobile devices. PWA work everywhere, do not depend on application stores and provide close to the native user experience. And so Gartner predicts that “PWA will replace 50% of user applications for general use.” But it is not necessary to overestimate expectations, it can almost be said for sure that one hundred percent of the PWA market will not occupy.
Now the presence of PWA is a competitive advantage. For example, PWA Twitter has increased the number of pages viewed per session by 65% . Thanks to PWA, Lancome increased conversion by 17% . OLX showed even more impressive results, and increased re-engagements by 250%. And there are many such examples. Soon, the presence of PWA will be simply necessary for any serious business, and the absence will be perceived as a significant drawback.
Sergey Pugachev, Google Developer Developer
Ps. The article is the personal opinion of the author and may not coincide with the opinion of past, current or future employers;)