Disrupting the browser
The Web browser technology began its life in early 1990s. That's already 25 years ago, and its age shows:

- The main mechanism for addressing a piece information is to pretend it's a file in a subdirectory, for example http://math.harvard.edu/pub/www/~raoulbott/papers.html. Modern web sites are not based on files or paths anymore; but the URLs are still constructed as if they were paths in a filesystem, and the entire mechanism of HTTP is still based on the concept of static information transfer, one static file at a time. As these limitations have become intolerable, the HTTP protocol has been enhanced with features such as chunking, compression, request pipelining, caching, and Web sockets. Most of these new features contradict the basic HTTP design (one piece of static information at a time) and so are difficult to use.
- The main mechanism for presenting information to the user is treat information as "multimedia content", that is, plain text with occasional formatting mark-up, embedded images, and hyperlinks to other texts. However, modern web sites need to present a dynamic GUI to the user, for which HTML and CSS is a very poor fit.
- The main mechanism for adding behavior to the Web site is to add Javascript code. But Javascript as a language is not designed for extensive use. It cannot be well optimized, verified, or made safe.
- The Browser was not designed to perform any serious calculations, and thus it is necessary to interact with a remote Web server. In principle, this interaction amounts to asking the remote server to deliver the results of computing some function that would be too difficult for the browser to compute. The HTTP protocol provides at least 6 different incompatible methods of passing arguments to the remote function. (For example:
PUT¹ https://host.org/path/index.html²?query=string³,
with custom cookies⁴, custom request headers⁵, and custom request body⁶.) The 6 different methods of passing arguments to functions cannot be replaced by one, because they are limited in different ways by different browsers and in various usage scenarios.
- The users of the Web were supposed to download content and then spend the majority of their time reading or viewing it on the local machine. It was assumed that a Web client will only connect to a Web server briefly while downloading data, and will disconnect right away after that. Thus, no session state was supposed to be kept by Web connections. This goes directly against the modern usage of the Web as an application platform with a persistent user state. It is far from straightforward to overcome this mismatch while designing a Web site. (You see this mismatch whenever you find yourself logging in to a Web site only to discover that all your previous work, e.g. filling out forms, has been discarded and needs to be started anew.)

Here's how the Web and the Almighty Browser can be disrupted.

1. The Web needs to be understood primarily as a delivery platform for interactive GUI applications running on remote servers, and not as a platform for publishing static texts with hyperlinks. The Web Browser needs to be understood not as a way for users to download and view ("browse") some previously available multimedia content, but primarily as a "GUI server" in the sense of the X Window system, that is, a delivery platform for some user interface-related graphics. The "GUI client" (in the sense of the X Window system) will be the remote Web server.

2. Therefore, the Web Browser will need to connect to remote sites and to serve arbitrary GUI content to the human user. The Browser will be, in effect, a rendering engine for a certain domain-specific constraint layout language for the GUI content. This layout language can be based on Cassowary constraints, or can be similar to what Apple now uses in its iOS applications. Visual designers could then create visual layouts directly in this language, without any application programming. The GUI application architecture could be "reactive", in the sense that the GUI representation is a pure function of some model data (residing in the Web server), and a stream of changing model data results in a stream of GUI values being fed into the rendering engine.

3. Any non-declarative computations should be separate from the Web page - either reside on the server, or provided by the local machine in a way that's separate from the Browser. The Browser cannot be trusted to run any computations that cannot be statically verified to terminate and to use only the allowed resources. This means, in particular, that the Browser cannot download any resources that contain Turing-complete programs, or more generally, programs whose termination properties cannot be statically verified before running them.

So, the function of the Web Browser should become quite analogous to the function of a computer screen. The screen merely shows the graphical information sent to it by the computer. The screen might perform some trivial computations itself, but nothing complicated enough that it could not be statically verified before running it, or could be a security risk.

The use of HTML, CSS, or Javascript is to be abolished in the long term.

4. The user should cryptographically authenticate all remote web sites. There cannot be a situation when a remote web site pretends to be another web site. The user implicitly agrees to run applications from certain web sites but no others.

5. The session between the client and the server needs to be persistent and stateful, at least on the server side. It is quite possible to implement stateful sessions on today's stateless HTTP, and this needs to become the default protocol.

The result of implementing this will be, as I imagine, a much more secure and resilient Web, and a much improved productivity of programmers.