Slack is a web application. Trello is a web application. Google Docs. Gmail Even Twitter.
The web started as a collection of hyperlinked documents. The exaggeration of "Web 2.0" in the mid-2000s referred to how the web was becoming interactive. At the beginning we were only commenting and voting on the hyperlinked documents, but in a short time, people like me could do almost all their work in what are now called "web applications". Some of those applications added collaboration or other nice things to have. Traditional tasks of the desktop application, such as creating email or documents. Others have more hyperlinks-document in nature-think that it is embedded in Slack and Twitter, or the multi-user nature of Trello.
But there is an almost golden rule about web applications: the native application is probably better.
But the web platform continues to evolve, and there are some upcoming web technologies that could give web applications a better chance to compete with their native counterparts.
Let's talk about some of them.
Progressive web applications
Microsoft made a big splash in February with its support for progressive web applications in Windows. But, did you know that iOS silently added support for PWAs to Safari in update 11.3? That means you can now create a progressive web application and send it to Android, iOS, Chrome OS and Windows.
So, what is a progressive web application?
Well, to start with, it's just a website with a special "manifest" file that defines the name of the application, the icon of the home screen and whether the application should display the typical user interface of the browser or simply take charge of the full screen. Users can add any website with a manifest file to their home screen or to their Start menu and run it as a normal mobile or desktop application.
Progressive web applications can also support push notifications and other background jobs due to a new web technology called "service workers". Service workers can help store new content and synchronize local changes to a remote server, which keeps progressive web applications progressive. up to date as a typical website, while remaining as responsive as a native application.
At this time, the best example of a progressive web application is the Twitter Lite client. It is fast, minimal and even has a button to minimize the use of data. Some stores and online publications have also taken advantage of the rapid performance of PWAs. In fact, I played a minimum of 2048 cloning of PWA on my iPhone during the last week. It works offline and remembers my highest score between sessions. Sometimes it even saves the state of the game so that it can resume a long race, but it is not perfect.
Apple support for the standards of the progressive web application is scattered and far from complete. In fact, Apple seems to have a different vision than Google for the amount that a PWA really should be able to do. We'll see how that vision evolves as PWAs become more ubiquitous and powerful on the platforms of Apple's competitors.
The good thing about WebAssembly is that you do not have to learn a new programming language to use it. High-performance code that is already written in C and C ++ can be compiled in WebAssembly. For example, both Unity and Unreal Engine have been ported to WebAssembly. That means you can play games in your browser window without worrying about installing a special add-on.
Unlike many web technology proposals that languish for years trapped in standards committees, or just enjoy irregularities or inconsistencies in support of several browsers, WebAssembly has been completely accepted by Google, Mozilla, Apple and Microsoft, and is now sent to all the major browsers if you do not have Internet Explorer.
Pairing WebAssembly with Progressive Web Apps turns a boring old website into a viable candidate for a place on the home screen next to "real" applications created with native technologies, without sacrificing any of the advantages of being an old website and bored.
To be honest, I often do not hear people say "yes, but native apps look and feel better than websites," but it sounds like something someone would say if it were the right kind of party.
I mean, of course, you can download a PWA that persists offline, it gives you push notifications when they're guaranteed and it works as well as a native application thanks to WebAssembly. But will not it look and feel like a website?
Yes, he will do it. No matter how much work you do to mimic the aesthetics and animations of iOS or Android, your hands will be bound by the basic limitations of HTML and CSS.
So, speaking of web technology proposals that languish for years trapped in the standards committees … let me introduce you to Houdini.
Houdini refers to a set of new features that allow developers to talk more directly with the CSS rendering engine of a browser. Instead of simply defining a set of style rules and letting the browser handle it, a designer working with Houdini could create incredibly personalized designs, styles and animations.
To help understand why this might be something powerful, take the development framework of the Google Flutter application as an example. Flutter can simulate the appearance of a native iOS or Android application, with a supposed perfect pixel accuracy, up to the correct scroll speeds. Flutter is not to make a website, however, it is to make iOS, Android and Fuchsia applications.
But under the hood, Fuchsia does all the design, style, and perfect pixel animation with the Skia graphics library, which is the same engine that drives Chrome browser rendering. When you create a website, you define the content in HTML and the CSS style, but it is a rendering engine like Skia that paints the actual pixels. You said "make me a red box", but Skia is in charge of exactly how.
That is a great responsibility, but that responsibility gives you a lot of power. Fortunately, the Houdini code will coexist perfectly with the design and style of traditional CSS. It is only an additional option when you need something that looks and feels in a very specific way.
It is difficult to know if Houdini's proposals will advance sufficiently in the internal parts of the browser to imitate everything that Flutter does with Skia. But it's interesting that browser vendors want to progress in that direction.
Unfortunately, at the moment most of Houdini's specifications are still in the air, and Chrome is the only browser where you can try many of these ideas. But if the web applications are going to look and feel "native", Houdini could be the way they take to get there.
But, what about the native APIs?
So, to recap:
Progressive web applications give me an icon on my home screen, offline support and push notifications.
WebAssembly gives me a native or almost native performance.
Houdini, if it ever happens, offers me extravagant animations and shadows I long for.
"But what about Feature X, my new favorite Android / iOS API?" Well, you probably do not have luck.
There will always be a role for native applications. A native iOS or Android application can take advantage of all the specific benefits offered by the platform: Apple's ARKit, Google's Visual Core chip, native graphical APIs and the multitude of other features that are added to operating systems each year for maintain its competitiveness But for applications that value ubiquity and convenience over the latest generation functionality, it seems to me that web applications will only grow in number and importance in our home screens and desktop computers in the coming years.
It is difficult to predict which next-generation web applications will have the greatest impact. At this moment, Twitter Lite is the golden example of Progressive Web Apps, and soon we will see a ton of lightweight games built with WebAssembly (usually as ads), but what happens on the horizon?
A place to start looking: anything that seems useful as an application, but that for some reason is not in the app stores.