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

The study of Mary Meeker and Liang Wu from KPCB initiated an explosion of trolling on the network by a mobile application tusk, as well as a lively discussion of the prospects for the development of the Internet .

Repeatedly, the thought was voiced by the grave bell that there was no future in the hypertext web, that websites would go into the past just as the print press disappears, and web developers will be forced out 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 be out of use much sooner than we are now expecting. I would even take a cell phone for another 10 years, a maximum of 15 lives. But on the phones in another place, but here I would like to discuss about the prospects for the development of the web and mobile applications.
')
Undoubtedly, HTML was and remains intended to manipulate static text and graphic information. But please pay attention to several interesting points, described below.

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

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

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

But! As soon as all these restrictions are lifted, immediately, I am sure, there will be a very fast rollback to the unified declarative description languages ​​of 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 of writing and updating native applications on mobile devices are some kind of hell.

First, we need to write an application for the device, and for each type of device you need to prepare your application (and only one apple device has as many as 11 pieces, and 9 of them have an active audience of more than 5%). Then we need to upload the updated version of the application to a network repository. This is not the end of this ordeal: now you need to somehow notify all users that you need to update the application, then wait humbly and hope that the majority of the application will be updated. And well, if this is an upgrade app, and if a version is released that fixes a critical error?

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

The process of penetration of application sites to mobile terminals is hampered solely by the reasons described at the beginning: stable communication is not always available, there is no guaranteed channel thickness, the fact that net webapp is 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, “sharpened”, for static content and tactile control. In order to interact with the interfaces described in HTML / CSS / JS, you need to point something on the active element (cursor, finger) and mechanical click (tap, click, swipe). This makes it very difficult to interact with interfaces that do not imply tactile interaction: for example, hands-free navigation systems in cars with a screen projection on the windshield.

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

And, yes, what, after all, will be with the web in the era of mobile? I am not afraid of such a forecast: mobile appy has been 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 good old HTML + JS (which is very likely), or will it be a completely new language for describing interface-interactions (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 contactless ways to control devices.