What will happen to the web in the era of mobile?

A study by Mary Meeker and Liang Wu of KPCB triggered a trolling explosion on the network from a mobile app hangout, as well as a heated discussion of Internet development prospects .

Repeatedly the grave bell voiced the idea that there is no future in the hypertext web, that websites will be gone in the same way as the print press disappears, and web developers will be replaced by programmers who create native apps for tablets and phones.

In this regard, I will share my point of view on our mobile future: the web will live longer than a mobile phone, which will become obsolete much earlier than we all expect. I would generally take a cell phone another 10 years, a maximum of 15 lives. But about phones in another place, and here I would like to discuss the prospects for the development of the web and mobile applications.

Undoubtedly, HTML has been and remains intended to manipulate static text and graphic information. But please pay attention to some interesting points described below.

First of all, it is the fact that graphical web interfaces appeared from a good life: processor performance, memory size and information transfer rate have grown to such an extent that it has become possible to make rich web applications with a reasonable rendering time. For example, google docs.

Prior to this, the interface ball was ruled by applications close to iron. For example, flash (mostly games and banners, but nonetheless). Even earlier, at the time of the total saving of kilobytes of traffic, desktop GUI clients reigned in the network (the same “The Bat!”, “Semagic”).

The return to GUI clients (now mobile) we see from the fact that the phones have never had a good life. RAM has grown to a size acceptable for interpreters (about 1 gb) only a year or two ago, Internet speed outside Wi-Fi coverage areas is only now becoming minimally sufficient, and processor performance is severely limited by power consumption - a revolution in power elements has still not happened .

But! As soon as all these restrictions are removed, immediately, I am sure, there will be a very quick rollback to the unified declarative languages ​​for describing interfaces like HTML. Moreover, these descriptions will certainly be stored in the clouds, and not in the form of local copies, as is now done in semi-native applications (native wrapper + HTML).

I argue: what is the weakness of local clients in relation to cloud web clients? In the problem of updating the version of the interface displayed by the user, in the deployment of new versions. The current ways to write and update native applications on mobile devices is some kind of hell.

First, we need to write an application for the device, and for each type of device we need to prepare our own application (but only one apple has 11 types of devices, and 9 of them have an active audience of more than 5%). Then we need to upload the updated version of the application to some kind of network repository. The ordeals do not end there: now it is necessary to somehow notify all users that it would be necessary to update the application, then humbly wait and hope that most of the application, nevertheless, will be updated. And okay, if this is an app upgrade, and if a version is released that corrects a critical error?

Application creators are simply more comfortable when the interface is described declaratively, does not require recompilation, and is distributed centrally. Moreover, the more centralized, the more convenient will be such packaging and distribution of works.

The process of penetration of application sites on mobile terminals is hindered solely by the reasons described at the beginning: stable communication is not always available, there is no guaranteed channel thickness, because a clean webapp is so far slower than a fully native application.

On the other hand, one should not think that everything is fine with web applications on mobile terminals. The weakness of web solutions is their extreme specialization, “sharpening”, under static content and tactile control. To interact with the interfaces described in HTML / CSS / JS, you will definitely need to point something at the active element (cursor, finger) and mechanical click (tap, click, swipe). This makes it very difficult to interact with interfaces that do not require tactile interaction: for example, hands-free navigation systems in cars with a screen projection on the windshield.

If we recall non-text-oriented interfaces, it becomes very sad. Non-textual interfaces include audio interfaces (Siri, various types of IVR), ways to dynamically mount video, create graphic collages. HTML is a text-oriented interface language. It is poorly suited to describe non-text output.

And, yes, what, after all, will become with the web in the era of mobile? I’m not afraid of such a forecast: mobile ups are still in fashion for another three or four years. Then they will be replaced by a new interpreted interface description language. Will this language be a development of a bunch of the good old HTML + JS (which is very likely), or will it be a completely new language for describing interaction interfaces (which, in my opinion, probably less) - I will not say. In any case, the creation of a new language will be required for migration from tactile-oriented control to non-contact methods of device management.