Make the Web standards more fundamental, so they barely need to change. Implement the rest in terms of those fundamentals.

Some thoughts:

- HTML and CSS are reasonable from an implementation standpoint: they have pretty rigid syntax (annotated tree of text, groups of name/value pairs) so user agents can ignore whatever they don't know/care about, and give reasonable results. Even if that's just a wall of plain text.

- Javascript is awful in this regard. It has masses of syntax, keeps changing, requires incredibly specific behaviour from a truckload of APIs and likes to silently bail out completely if one thing goes wrong.

Our notions of computation don't change all that much, and certainly not quickly. There's no reason to make every user agent understand all of the human-friendly bells and whistles that the standards bodies keep bolting on. Whilst "view source" is nice, these days we often need tools to undo minification and obfuscation; let alone the rise in compile-to-JS languages.

The standards should only dictate something that won't need to be changed for a long time; say, a pure, untyped, call-by-value lambda calculus, with literals for integers, strings and symbols. APIs can be defined as reduction rules involving the symbols; for example:

- Applications of the form '((+ x) y)', when x and y are integers, can be replaced by the sum of x and y.

- Applications of the form '(array 0)', can be replaced by an empty array value (defined elsewhere); applications of the form '((array 1) x)' can be replaced by an array value containing the single element x, etc.

- Applications of the form '((object 1) (keyvalue x y))' can be replaced by an object value, with the value y for property x, etc.

- Application of the form '(XMLHTTPRequest x)' where x is an object value with properties...

Executing such programs would, like with HTML and CSS, allow implementations to ignore whatever they don't know/care about. Expressions with no corresponding reduction rule just sit there unevaluated, whilst everything around them carries on as normal. Users could implement their own overrides for how things should rewrite; like user styles, but more pervasive. Sites could supply pure reduction rules as part of their code, to enable things like fancy control flow. Effectful reduction rules could be controlled at a fine-grained level by the user agent (and hence, the user). Programmers can write in whatever language they like and compile to this simple Web language. Since we're being ambitious, let's say they'll include links to the original source, under the AGPL ;)

Fancy, state-of-the-art browsers can come with a bunch of optimisations and tricks for faster parsing and evaluation of common code patterns. They can also define their own libraries of symbols and rules, which are more amenable to optimisation (like asm.js); along with fallback "polyfills" which make them work (slowly) everywhere else.

We can probably do similar things for rendering, layout, etc. The clever, complicated algorithms dictated by the standards can be great when we've got a bunch of content and we'd like the user agent to display it in a reasonable way. On the other hand, if we've got some exact output in mind, we should be able to describe it directly, rather than second-guessing and working around those algorithms. All of this can go into libraries, leaving the "core" alone.

There's always the danger of turning the Web into the equivalent of obfuscated PostScript: a blob of software that, when executed, renders an image of the text, etc. content. However, I think that's mostly down to the choice of what APIs are included by default. If the default behaviour is similar to today's browsers: take text from the document and lay it out in a readable way; allow headers, emphasis, etc. using annotations, and so on, then I'm sure most would do that, ensuring the text and other content is easily parsed, indexed, etc.