The web has evolved immensely in the last couple years and with it, so have the technologies. In this article we explore going Native Apps v Web Apps. I visit conferences and meetups, speak with incredibly smart people, and have time to investigate new and exciting technologies to see how they fit into what we're doing.
The web has evolved immensely in the last couple of years. We're seeing new libraries, frameworks, languages, and tools coming out nearly weekly. This constant, fast, pace of change gets quite exhausting – how am I going to keep up with all these new things?
I believe that it's good to take a step back once in awhile to get a perspective on things as a whole. Understanding what the driving trends are and what problems we're trying to solve on the web will help you better understand what particular problem a new library is seeking to solve and whether or not that's relevant to you. In this post, I want to share some of my observations about web development – where we are today, how we got here, and what we might expect to see in the next few years.
The mobile revolution and the death of web
When the original iPhone came out, it set off a mobile revolution. Since then, the share of time we spend on digital media has moved overwhelmingly to mobile devices. In 2016, we spent around two-thirds of our time on mobile devices. Native apps completely dominate mobile device use. We visit about three times more sites each month than we use apps, but we spend almost 20 times more time in apps than we do on the mobile web. So, the issue isn't that people aren't using the web, rather it's that the web isn't successful in engaging these users and keeping them coming back.
So what's the problem? What makes native apps so much more engaging to users? User experience. In my opinion, the biggest factor in the success of native apps over the web on the mobile is that the web has failed to deliver the level of user experience that users expect and demand.
The struggle of web applications is in significant part because the web predates modern mobile devices by decades. It wasn't designed to build apps. It wasn't designed to deal with intermittent connections and offline situations. Native apps, on the other hand, are designed from the ground up to deal with network and size limitations, ensuring that apps deliver a solid experience.
In short, it is the lack of the tools to build the kinds of applications our users want that has held back the web.
Peak app
That isn't to say that things have been all sunshine and rainbows for native app developers either. The native app market is getting near a saturation point, with users less willing to install new applications. Gartner published a report earlier this year, predicting that up to one-fifth of companies will abandon their mobile applications because they're not getting the return on investment they were hoping.
A lot of this unwillingness to install new applications is due to what's referred to as friction – the effort required to start using an application. For native apps, this friction is high. To use an application, you need to find it in an app store, type in your password, wait for the download to finish, and so on. This effort is often significant enough that users skip the application, especially in cases where they would only use the app occasionally or even just once.
The web, on the other hand, has a very low friction thanks to links. If you have a link to an application, you can immediately start using the application without going through any additional installation steps, whether you've found it on Google or a friend shared it with you..
So we're in a tricky situation. On the one hand, native applications offer the level of user experience and engagement that users want, but users are increasingly unwilling to install them. On the other hand, web applications provide the low friction we need for getting users into our application, but they aren't able to deliver the level of user experience that keeps users engaged and coming back to our apps.
The four missing pieces of the puzzle
Perhaps one of the most important events in the recent history of the web was in 2013 when a group of industry thought leaders, browser developers, and specification workers published the Extensible Web Manifesto. Previous to this, passing new web standards was often a very long process, slowing down the speed at which the web could adapt to new needs. The manifesto advocated for adding and exposing small, low-level capabilities that allow developers to build on the already existing parts of the web, like HTML and CSS. In the following years, we've seen a tremendous growth in APIs and functionalities available in browsers.
In my opinion, there have been four major missing pieces that have prevented the web from succeeding on mobile. These are the lack of a component model, the absence of an application model, poor performance and reliability, and limited device access. Let's take a closer look at each one.
Web Components, the web's missing component model
One of the first things we tend to do when building a large application is to split that into smaller components with defined APIs. Breaking a large problem into successively smaller subproblems makes it much easier to reason about the application as a whole, and allows us to reuse common functionality throughout the application.
There have been countless implementations of component models for the web. Frameworks such as Dojo, jQuery, and YUI had JavaScript based components already a decade ago. More recently, frameworks like Angular, React, and Vue have solved the same problem, although in their own ways.
There are two main issues with these component models: they are bound to one particular framework or tool and they need to get translated into low-level DOM elements which incur a runtime overhead.
The native web solution to components is Web Components. Web Components allow developers to extend HTML Elements in JavaScript and encapsulate their implementation from the rest of the document to ensure portability and reusability.
Web Components, regardless of if you write them directly against the browser API, or use a helper library like Polymer or Stencil, will by design work together with any framework and can even be used without frameworks. The web now finally has a component model!
Progressive Web Applications, the web's missing application model
The second big piece that was missing from the web for a long time is an application model. You as a developer obviously know you're building an application, but the browser doesn't. As far as it's concerned, each page in your app is an entirely new site.
Again, this is an issue that developers have been aware of for years, and there have been countless tools, like PhoneGap and Electron, to help bring application models to the web. They have given us a way to define an application and get access to APIs on the host device we otherwise wouldn't have access to but at the cost of severing the app from the web. So even though you build these hybrid applications using web technologies, they still suffer from the high friction that native apps have.
The web's solution to this is called Progressive Web Apps. PWA is not a single technology. Rather it's a collection of web development best practices along with a few new specifications. The most important new specs are Web Application Manifest and ServiceWorker.
The application manifest is a straightforward JSON file that contains metadata about your application: its name, colors and icons. It contains mostly the same information that you have today in the meta-tags filling your website header. You then add a link to the application manifest from all pages that make up your application to let the browser know that they are all part of the same app.
The second technology, ServiceWorker, is slightly more complicated. The ServiceWorker is an event-driven piece of JavaScript code that the browser runs in a special worker thread. The ServiceWorker can intercept network traffic and provide elaborate caching and offline fallback mechanisms to ensure your app works reliably even with poor connectivity. The ServiceWorker can also receive push notifications from servers using the Web Push standard and perform tasks like background synchronization of data.
With Application Manifest and a Service Worker, the web finally has an application model.
APIs for engaging user experiences
Just having a component model and an application model isn't quite enough yet to build the level of user experience and engagement that users want. Fortunately, APIs offering device integration for things like payments, authentication, and hardware controllers are being worked on and implemented across browsers at a fast pace. It's now possible to let users pay for transactions with payment information saved on their devices, or to use game controllers for VR games just as in native applications.
WebAssembly, bringing performance to the web
Native applications have always had a significant performance edge over web applications. Even though JavaScript engines have become much faster in the past few years, the parsing, JIT compilation and runtime optimization of dynamic JavaScript cannot compete with optimized binary code that native applications run.
WebAssembly allows us to run code on the web significantly faster and more efficiently than before. WebAssembly is a bytecode format for the web. It makes it possible to take source code in a statically typed language like C or C++ and compile it to a binary format that's efficient in terms of download size, parsing, and runtime. WebAssembly can be tens of times faster than the equivalent JavaScript when executed.
The obvious uses for WebAssembly are in gaming, video and image manipulation and heavier business apps like spreadsheets, but any application running complex logic will benefit from it. WebAssebly is still a not as easily approachable as Web Components and PWA, especially for frontend developers. Fortunately, most developers will be able to benefit from WebAssembly through library code that starts using it. Your applications can start benefiting from WebAssembly by just updating the used library versions.
Enter Native Web Apps
Combining Web Components, Progressive Web Apps, and Web Assembly, we have all the building blocks for building applications that are native in a sense. But instead of being constrained to Android or iOS, the applications run natively on the web platform.
With component and application models, a solid set of device APIs and the performance offered by WebAssembly, the web can finally deliver the speed, functionality, and reliability that users expect from applications. All without the friction of having to install an app before using it.
The rise of the web as an operating system
What we're seeing is that the web browser is becoming the operating system to an increasing extent. Native applications won't be going away, but I do think that they will become more niche and specialized as time goes on. For most developers, building native applications simply won't be worth the extra cost.
If the web becomes a viable third platform for mobile, it will open up possibilities for new device manufacturers and operating systems to enter the market and to increase the pace of competition and innovation. Having common standards to build on will not only help speed up innovation but also give us a stable foundation.
Emerging markets will likely be a catalyst in the move to mobile web. The web's "only download and update the parts you need" app model is particularly well suited for developing countries where network speeds are low, and data costs are high. Native applications are struggling with users refusing to update applications due to cost, leading to a fragmented and insecure deployment base.
I predict that web frameworks will become smaller, more focused, and more modular as a result of the standardized platform. In the long term, it means that we may not use frameworks the same way we do today. Instead, we can find the UI components we want, tie them together with a router and bind data with a state management library of our choice – essentially mixing and matching pieces to get exactly the functionality we need. Since components, tools, and libraries are all based on the same standards, they're interoperable by default.
Conclusion
The web is going through an exciting period. We're seeing a lot of progress on standards that will help us build the next generation of mobile web applications. Applications that are able to deliver better user experiences to wider audiences using a diverse set of devices.
My suggestion is to spend some time and learn what the web platform can do without any additional tools or frameworks. You might be surprised over how much new functionality the web platform has gained over the last few years. Understanding what the web platform provides and how it works will help you pick up new libraries and frameworks quicker because you understand what specific issues they are trying to solve.
Comments? Tweet me at @marcushellberg, as I don't get any notifications about comments in this blog and will likely not notice them.