> 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