A plan to rescue the Web from the Internet

So under that model, would Wikipedia, which uses javascript, be in the sandboxed-app client, and would you would be perfectly happy viewing it with javascript on, in that case?

I'm curious which sites you actually frequent which wouldn't count as "apps," but which still use javascript, and which would actually run in the static-only client you seem to prefer?

Completely agree. Declarative approaches define the palette of available options ahead of time, but if wish to do something out-of-scope, it's back to the drawing board. Imperative approaches instead give you a low-level computation environment, and hooks into manipulating the outside world.

Most facets of the original Web are declarative: HTTP is a complex state machine, HTML is a declarative language, hyperlinks are declarative ways of specifying outgoing edges of a node in a graph. Javascript enhanced that with imperativeness, which is why it's been leveraged to extend the Web in new ways -- ways that are ad-hoc reimplementations of behaviors that have not (yet) been otherwise codified.

> That said the web was hijacked, for lack of a better term, by early web browsers that intended to do things that the web was never intended to do. This is how we got JavaScript.

I'm not sure that this is accurate. Tim Berners-Lee in his 1989 proposal for the World Wide Web [1] contemplates usage that is compatible (or at least not incompatible) with the JavaScript we have today. Excerpts from his proposal:

> "Hypertext" is a term coined in the 1950s by Ted Nelson [...], which has become popular for these systems, although it is used to embrace two different ideas. One idea is the concept: "Hypertext": Human-readable information linked together in an unconstrained way.

> The other idea, which is independent and largely a question of technology and time, is of multimedia documents which include graphics, speech and video. I will not discuss this latter aspect further here, although I will use the word "Hypermedia" to indicate that one is not bound to text. [...]

> The data to which a link (or a hot spot) refers may be very static, or it may be temporary. In many cases at CERN information about the state of systems is changing all the time. Hypertext allows documents to be linked into "live" data so that every time the link is followed, the information is retrieved. If one sacrifices portability, it is possible so make following a link fire up a special application, so that diagnostic programs, for example, could be linked directly into the maintenance guide. [...]

> Many systems have been put together with little or no regard for portability, unfortunately[]. However, there are several interesting projects and more are appearing all the time. Digital's "Compound Document Architecture" (CDA) , for example, is a data model which may be extendible into a hypermedia model, and there are rumours that this is a way Digital would like to go. ['Compound document' refers to a document that combines text with non-text such as spreadsheets, pictures, video and audio, etc.]

Burners-Lee goes on to sketch out what such a system might look like, and characterizes the current browser/server architecture, emphasizing the separation between display logic and server logic, and anticipating the evolution of those display programs:

> Let us see what components a hypertext system at CERN must have. The only way in which sufficient flexibility can be incorporated is to separate the information storage software from the information display software, with a well defined interface between them. Given the requirement for network access, it is natural to let this clean interface coincide with the physical division between the user and the remote database machine.

> Therefore, an important phase in the design of the system is to define this interface. After that, the development of various forms of display program and of database server can proceed in parallel. This will have been done well if many different information sources, past, present and future, can be mapped onto the definition, and if many different human interface programs can be written over the years to take advantage of new technology and standards.

I read Burners-Lee's writing as very much anticipating the modern browser, JavaScript included.

It's also worth mentioning that Roy Fielding, one of the principal authors of the HTTP specification (along with Burners-Lee), characterized Code-on-Demand (that is, scripting/VMs, e.g. Java and JavaScript) as a core constraint of Representational State Transfer (REST) [2]. The REST architectural style, as described in Fielding's thesis published in 2000, is intended to characterize the architecture of the Web.

> A distributed hypermedia architect has only three fundamental options: 1) render the data where it is located and send a fixed-format image to the recipient; 2) encapsulate the data with a rendering engine and send both to the recipient; or, 3) send the raw data to the recipient along with metadata that describes the data type, so that the recipient can choose their own rendering engine. [...]

> REST provides a hybrid of all three options by focusing on a shared understanding of data types with metadata, but limiting the scope of what is revealed to a standardized interface. REST components communicate by transferring a representation of a resource in a format matching one of an evolving set of standard data types, selected dynamically based on the capabilities or desires of the recipient and the nature of the resource. Whether the representation is in the same format as the raw source, or is derived from the source, remains hidden behind the interface. The benefits of the mobile object style are approximated by sending a representation that consists of instructions in the standard data format of an encapsulated rendering engine (e.g., Java [45]). REST therefore gains the separation of concerns of the client-server style without the server scalability problem, allows information hiding through a generic interface to enable encapsulation and evolution of services, and provides for a diverse set of functionality through downloadable feature-engines. [...]

> The final addition to our constraint set for REST comes from the code-on-demand style of Section 3.5.3. REST allows client functionality to be extended by downloading and executing code in the form of applets or scripts. This simplifies clients by reducing the number of features required to be pre-implemented. Allowing features to be downloaded after deployment improves system extensibility.

So my take on history is that key designers of the modern Web always envisioned it as being capable of delivering and displaying dynamic content with an evolving set of capabilities.

Lastly, an excerpt from an interview with a Wired interview of Burners-Lee from 2014, characterizing JavaScript as part of the web's "fabric" and emphasizing its ability to evolve [3]:

> The good news is that the web has openness and flexibility woven into its fabric. The protocols and programming languages under the hood – including URLs, HTTP, HTML, JavaScript and many others – have nearly all been designed for evolution, so we can upgrade them as new needs, new devices and new business models expose current limitations.

[1] https://www.w3.org/History/1989/proposal.html

[2] https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

[3] http://www.wired.co.uk/article/tim-berners-lee

Unless I missed something, this article lacks a call to action (or multiple calls to action for different people). What can individual readers of this article do to help realize this plan? For example, if I have money, where can I give it?

For us "old" people who remember the internet before the web -- one of the things that's really different about the modern internet is the very limited set of protocols and applications that the average user interacts with. It really used to be that every different service type mapped to a different protocol and HTTP (and HTTPS) has just sort of subsumed everything. Back in the old days to minimally use the internet you'd have to know at least telnet, ftp, nntp, gopher (maybe), smtp, pop and maybe a handful of others.

(okay, maybe modern users use more protocols than I'm admitting to, but it's very obscured these days but so many different applications just ride on HTTP(S) anyways).

There's really nothing preventing some motivated group to just spin up an entirely new kind of service that "fixes" all that's wrong with the web, custom protocol and application stack.

"But the network effect!"

And that's something us old timers remember, we remember lots of great services spinning up and down and even when the web was just a handful of sites. The web earned its network by having better general utility than other things that were attempted, but why can't a new better service eventually earn it?

(In the meanwhile us hacker types will enjoy having a cool new playground to muck around on for a few years).