Web components and hybrid applications: present and future of mobile apps?

The trend in mobile apps has more and more web character and less native.

Puedes leer este artículo también en Español por Manuel Saelices.

This statement is not only influenced by my background, mostly web both back-end and front-end, but for some reasons that I will explain throughout this article, such as the technological evolution of software and hardware of mobile phones, or the change in the trend of users, who increasingly install fewer applications.

The “Wonder” Years

Back in 2003, when browsers were disparate, and some did not even follow the W3C standards, developers had to become patch specialists so that the same web app could be used and be seen acceptably in different versions of Internet Explorer, but also in Netscape, Firefox, Safari, Opera, etc.

Then we were aware that most browsers were not updated automatically, so we used CSS files iefixes or other hacks frequently, and we were more conservative when it came to innovating since we had to develop compatible web apps even with Internet Explorer 5, which was the most used and the least standards followed.

Emancipation of the web

This was changing progressively but unstoppable, fortunately:

• The browsers joined the W3C standard, including IE.
• Its performance increased in a relatively short space of time, driven by new competitors such as Chrome.
• HTML5 appeared, and with it, endless possibilities, allowing, for example, to make 3D games, videoconferences or chats from the browser and enabling mobile browsers could also enjoy many of these features.
• Javascript was standardized, ceasing to be considered a “toy language” to reach a higher level.
• Web frameworks and applications such as Gmail or Google Docs were born, which showed that apps that had historically been desktop could be executed via web.

My daily work in the front-end of web development went from being something tedious and very unproductive to being something spectacular thanks to these changes. A new world of possibilities was opened: games, videos, streaming, real-time, geolocation, CSS toolkits … A world where every line of code that was written worked with a 99% probability in all modern browsers, including mobile browsers, and with a spectacular tooling thanks to the debuggers and JS and CSS inspectors.

Hello, mobile world!

I’m not reluctant to learn other technologies, so in 2010 I entered the world of mobile apps. I remember feeling a great disappointment to realize that it was like going back to the horrible past: If we wanted the app to be used by many users with devices different mobile, we had to develop differently for Android, IOS, Windows Phone, and BlackBerry. I’ve never got to try proprietary tools like Xamarin, so developing for different platforms meant multiplying the apps developments.

Besides, the debugging was tedious again since something that worked in mobile could not work in a different one, not only for the operating system but for the simple fact of having a screen of varying size. The emulators were slow, so trying the real device made you have to buy a series of phones or go testing with those that were within your reach.

Immersion in ionic

After some time the mobile devices had sufficiently powerful CPUs, and the browsers were modern enough in almost all of them so at the beginning of 2016 I opted to investigate hybrid applications. I tried ionic, and I liked the experience for the following reasons:

• The speed of development increased a lot, mainly because I could apply most of my knowledge of the web. The increase is multiplied if you take into account that practically all your code is compatible with iOS, Android and Windows Phone.
• 99% of what was programmed could be tested from Chrome simulating the screens of the devices, and it turned out that the vast majority of times when testing on real mobiles, the user experience was the same as expected. Even when you tried with the mobile, you could use the browser inspector to change styles in real time!
• The previous point implied that we could change from iOS to Android or Windows Phone in a second. This was very important because it allowed us almost to ensure that the code we had just written worked on all platforms on the fly.
• The vast majority of animations, scrolls, menus that are displayed and gestures were fluid. I remember developing a streaming application MVP that included video recording and streaming screens, with real-time chats, Periscope type, and obtaining an entirely acceptable result. Nobody noticed that it was a hybrid app!.

However, not everything in the ionic world was positive:

• The loading time of the apps was tremendous, around 12 seconds. This was getting better as the 2.0 ionic and deangular were getting closer, but they did not go down 5 seconds on a Nexus 5X.
• On older devices, the speed of execution and the lower HTML5 support of the browsers that were embedded in the WebView was noticeable. To support mobile phones with not so modern browsers, I had to use the CrossWalk WebView. However, this involved an extra 12 megabytes in the size of the app, since the Chromium rendering engine was included inside.
• There was a small percentage of screens, depending on the app, that had to access parts of the device for which the HTML5 standard did not support, or browsers did not include and had to resort to Cordova plugins. This part was again tedious, especially for the cycle of coding and testing.

In summary: for the developer (especially on the web) the productivity using ionic was excellent, far superior to the native one, and the quota of potential users that was reached was very high.

However for the end user, if we get strict and the app is complicated, it had a very high boot time, and on some critical screen, it could require you to use native components to optimize it.

To be honest, ionic has come a long way since then, as demonstrated in its Pacifica app (in Google Play and Apple Store), or MarketWatch (in Google Play and Apple Store), but I have not been able to follow it closely since those mini prototype projects in which he was involved.

Back to the native world with React

After this experience, I was lucky enough to be able to face another app project and decided to do it this time in React Native, which is sold as a technology that allows native apps to be developed on mobile, running on Android and iOS.

The experience was mixed: On the one hand, it is true that the app works on several platforms and that you write Javascript (JSX specifically), but I missed the productivity that I got in the hybrid apps since the development cycle was often very slow. It was necessary to try with an emulator or real device, so sometimes the screen went white. Also to show the error you had to activate the debugger, which made the development cycle much slower, with several seconds waiting from when you clicked until the app responded.

On the other hand, the style inspector was very poor and did not allow you to make changes on the fly or know the origin of the styles that are applied to change the sources. You also did not have the power that CSS currently allows. Therefore the workflow of testing in the inspector until finding the appropriate style to place it in the style files here does not make sense.

Other reasons why I felt that React Native was detrimental to productivity are:

• It did not allow to make the change of platform in a second, as in the hybrid. If you wanted to check in iOS what you had just tried in Android, you should use a Mac with XCode, disconnect your Android and connect your iPhone, or launch another emulator).
• Often a bug in your code, or save before the change is finished, caused the app to be in an inconsistent state that you could not leave if you did not recompile the entire JS bundle, which takes between 30 seconds and a minute. When hot reloading works, the wait is usually only 2–3 seconds.
• It was not easy to debug requests to the backend (for example through REST), not even installing react-native-debugger.
• There were no libraries of components as successful as ionic, and personalizing them was more tedious for the poor inspector. I’ve tried NativeBase, and I thought it was the most complete.

Web components and the future of mobile technology

While it is true that Apple is slowing the progress of Progressive Web Apps (PWAs), among other things to control its App Store, it is entirely viable today to make hybrid applications of almost any type where the user does not know how to differentiate a native app from one that is not.

In addition to the PWA mentioned above, a myriad of technologies such as Electron, Ionic, React, Vue, etc., as well as some standards that are added to HTML5, I would say that the trend in mobile apps has more and more character web and less of native.

A standard that can be key to take advantage of all this web synergy is Web Components, where the browser takes over the standard part of almost all web presentation frameworks regarding component rendering, getting the start speed of a mobile app developed with Web Components increase drastically.

You can find examples of the improvements that the out-of-the-box Web Components get in articles such as Marcus Hellberg’s Simplifying Performance with Web Components or in conferences like Web Components: Just in the Nick of Time, in charge of a developer of Google Chrome at the Polymer Summit this year. It is also possible to test online the native experience in the PWA called Cheese.

The results that the Ionic team observed when moving its components to web components were spectacular.

By moving to Web Components, they managed to reduce the loading time of an application from 5 seconds to one. This means that the most significant disadvantage of hybrid applications disappears, maintaining all the advantages for the developer and adding prize: allowing the use of said applications components in any JS framework such as React, Vue.js, Ember, etc.

The fact of having a library of agnostic components will contribute, to what is probably the best UI HTML toolkit for mobile applications, thousands of new developments from other frameworks.

And another of the issues that could be disturbing: the support of the Web Components in mobile browsers seems to be exceeded, as can be deduced from the Future conference, Faster: Unlock the Power of Web Components with Polymer of Google I / O ’17. In this conference, they indicate that more than 1 billion mobile devices currently support them.

My experience with hybrid apps development frameworks with Web Components support

When I set out to investigate the current state of ionic, I understood that they were still in an alpha state, and although it would not take long to have the final version, there was already another popular framework that had all its components working in web components: OnSen UI.

This framework has bindings for React, Angular and Vue.js and several applications on the market as Evento. It also has a demo app to test the toolkit. Since Angular has by far the size of the most extensive JS of all the bindings and that my Commite colleagues have a lot of experience in React (although I like even more Vue.js) I decided to continue using this technology an existing weather prediction application in an old version of Onsen UI. So I refactorized and adapted it to the latest version, adding little by little more features.

My experience in developing this mobile app led me to the following conclusions:

• Waiting times are null, and not because there is a series of tooling such as web pack that by WebSockets only compile and transmit the components that are modified in the IDE. It is almost instantaneous even the construction of the entire bundle, as well as the browser refresh with Control + R.
• The iOS / Android mobile platform change is instant by merely changing the user-agent or the device toolbar device in the browser inspector.
• The browser inspector works perfectly: Changing WYSIWYG styles on the fly, debugging REST requests on the Network tab, even the app store and actions using Redux DevTools.
• The resulting code is very readable and concise (you can check it here).

Another aspect to take into account is that after all, we are talking about a website so that you can share the final result by a simple link: https://msaelices.github.io/react-onsenui-redux-weather/demo.html

Last but not least, for the end user, the experience of using the app seems quite fluid, with loading times of just one second in a Xiaomi Mi6 without perceiving at any time that it is not a native app. In fact, the sensations were so pleasant that I decided to repeat the same app that is becoming my favorite JS framework, Vue.js: https://github.com/msaelices/vue-onsenui-weather. The online demo is here: https://msaelices.github.io/vue-onsenui-weather/

The summary of this last experience using web components is that I have enjoyed mobile programming again.

Fascinating events will begin to arrive in the mobile world, and I think they will go hand in hand with significant developments on the web such as lit-HTML or WebAssembly.

And you: What technologies do you use to develop for the mobile? What is your experience?