Why WebAssembly is the future of Progressive Web Apps
13 minute read View comments
The need for businesses to target customers on mobile devices is well-established at this point. The question is no longer if they should do it but how. A business that wants to appeal to mobile-based customers has three choices: build a responsive website, develop a native app or create a progressive web app (PWA). - Forbes
The often heated debate about web apps versus native apps on mobile devices is about to rise an extra notch in 2019. The developments on both fronts have been brisk and tantalizing, giving us a peek at what the future could hold.
Did you know that a top tier gaming engine, the Unreal Engine 4 can and has run in a web browser?
I thought you should know.
The Ubiquitous Application
When Java was released publically in 1996 it was touted the “write once, run anywhere” (WORA) general purpose computing language. It appeared on early web browsers as applets embedded in HTML pages. It was in the era of network administrators, trying to install the JRE (Java Runtime Environment) and viewing of an unauthorized content was cumbersome. The rise of mobile operating systems which did not have the JRE and security concerns on desktop, put an end to the applets future
Adobe (then Macromedia) Flash was being used to build apps that could run on the desktop and in the web browser through plugins. But increasing security risks made Steve Jobs pen the famous “Thoughts on Flash” and announced that iOS would never use Adobe Flash.
Later that year, on October 12th 2010, Facebook Engineering published a note about how they had been using HTML5 for some months and were beginning to leverage Video, Geolocation, Web Storage and Web Sockets.
In 2011, Canonical released the Ubuntu Touch. The thinking at the time was that consumers wanted a convergence of experience across devices for work and play. Ubuntu would be the one OS that would run apps that would reconfigure UI and certain features based on device. But that was not to be.
The Singular Experience
We want apps that work the same across devices. As the devices become more powerful, the experience should be singular, contextual to the device and the activity.
Apple, Google and Microsoft are now playing, in varying degrees, in the device vertical. These companies seek to control the software that the user interacts with as well as the hardware the interaction is happening on, from watches to 4K monitors. Samsung, for example, controls different aspects of the hardware space while Facebook and Amazon command different sides of the web software platform space.
Browsers are at the centre of of the web experience. Thanks to the W3C, browser makers have been required to produce a uniform web experience that is based on an agreed standard. Today, we have latest “HTML5” standard.
“It is worth understanding that the term “HTML5” has come to mean more than just the single HTML5 specification, but really represents the next evolution of the web platform and thus dozens of related specifications. Many of them have already been implemented across recent versions of Chrome, Firefox, Internet Explorer, Safari, and Opera.”
- David Recordon
Progressive Web App (PWA)
“A progressive web application takes advantage of a mobile app’s characteristics, resulting in improved user retention and performance, without the complications involved in maintaining a mobile application.” Kevin Farrugia – Smashing Magazine
“Progressive” in the PWA means Web applications are “progressively enhanced” with modern web features allowing the apps to work in older browsers that don’t support the new features, but will work better and with more features in modern browsers. They are able to operate across all device types, from mobile to desktop.
For the last 3 years, PWAs have been gaining ground, leveraging the immediacy of the web and the advantages of native mobile apps. Advances in Web technology, such as on-device web storage of downloaded content, UI components in the Cache, Push Notification APIs and home screen buttons has allowed people to work on web apps when offline, especially in areas of low Internet access.
Native mobile apps provide very good device experiences. Resistance to these apps has been increasing especially when getting a native app through App stores and the constant downloads to update the app. This has allowed PWAs to be seen as a viable replacement of the native mobile app. This especially true for an app that does not require a lot of on-device functionality.
This has, in turn, made the relationship between the browser, the operating system and the device very important and this is where the device and browser manufacturers are competing. For the user, the speed at which a website or a native app responds has reached the point that beyond 3 seconds, interest will shift. Speed is of the essence.
So how can developers WORA code for PWAs that can then be used for native apps, if need be?
But wouldn’t it be nice if we could compile web apps so that they run in the browser at native app speeds? Soon we will be able to.
This question of web apps and now PWAs running at native app speeds comes up a lot. One solution has been to create a way to run compiled code inside the browser.
WebAssembly is a binary instruction format designed as a portable target for compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications.
Kotlin compiles to WebAssembly as well as iOS, macOS, Windows and Linux. As a side note, Kotlin has been built to interoperate with Java, making it the successor language for developing for Android, running your mobile app on the JVM for older Android devices. Google has made Kotlin a first-class citizen across its cloud and mobile ecosystem. Kotlin is a good WORA candidate.
What does this mean for future PWAs?
For PWAs to take advantage of WASM, a developer can begin do to a number of things:
- For existing applications, developers may reuse existing code. The business logic should be “compiled” and target WASM. Then this compile may be embedded in a HTML5 application. This should work well for Single Page Applications (SPAs).
- Invest in learning a programming language that targets WASM in its entirety. Currently these languages officially target WASM; C/C++, Kotlin and Rust. In future, other languages will support WASM and many are in the experimental stage as we speak.
If you liked this article, go ahead, click and fill out the form below and let us begin a conversation about your project.