Why WebAssembly is the future of Progressive Web Apps picture
Image by © 2108 Estranged Game on Unreal Engine 4 running in Firefox

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

During this period, JavaScript was marketed as “a companion language for Java” and was not taken too seriously.

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.

By this time, JavaScript had started taking on the looks of a serious programming language, and thanks to the Ecma process, JavaScript is now open and ubiquitous across the Web, both client-side and server-side.

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

This is going fairly well. Web developers increasingly need to wrestle less with variations caused by browser differences and more with “JavaScript fatigue”. Basically, JavaScript Fatigue is the result of the JavaScript ecosystem continued growth.

Now that JavaScript is running both on the “client side” on browsers and “server side” increasingly through APIs, the focus is now on performance.

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.

The pursuit of speed is two-fold, how fast a developer develops an app and how fast it runs. JavaScript have made the PWA possible and in many ways through JavaScript frameworks. Frameworks solve particular problems that have appeared in Web development. React is a UI library, Angular and Ember.js are frontend frameworks, and Meteor is an isomorphic (client and server) framework, just to name a few.

So how can developers WORA code for PWAs that can then be used for native apps, if need be?

One way is to build PWAs directly in JavaScript using the available JavaScript frameworks and reuse the code in a native app dev environment. React by Facebook tries to solve this by offering React for web UI development and React Native for Android and iOS native app development.

Typescript and CoffeeScript are “supersets” of JavaScript that transpile to plain JavaScript, thus aiding rapid development for scalable web apps.

The other way is to develop web apps using a programming language apart from JavaScript and “compiling” to JavaScript for the web or compiling to bytecode or machine code for use as native apps.

Kotlin is a programming language that be used to target client-side JavaScript, working with other libraries such as React to build web apps. This favours developers who work with other programming languages.

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.

WebAssembly (WASM)

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.

It is still early days for WASM with the 1.0 being what is currently running in browsers since ratification on 28 February 2017. However, the possibilities are immense. WASM is meant to run alongside JavaScript, being called into the runtime using the JavaScript API like any other JavaScript module. Once Webpack This means we'll be able to import compiled C/C++ files directly in JavaScript files and call WASM functions directly!

What does this mean for future PWAs?

TL; DR

For PWAs to take advantage of WASM, a developer can begin do to a number of things:

  1. 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).
  2. New PWAs should increasingly be developed by building the main application frame and business logic in WASM. The UI/UX can be developed in JavaScript frameworks. My assumption here is that React or Vue will work best in this regard.
  3. 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.

For “full stack” JavaScript developers, the future is bright.

If you liked this article, go ahead, click and fill out the form below and let us begin a conversation about your project.

Project Form

Last updated: Dec. 17, 2018, 1:28 p.m.

blog comments powered by Disqus