Bedrock

HTML works well enough for its purpose, but its SGML heritage makes it awkward to read and write; it is implemented inconsistently and sometimes clumsily, with countless edge cases where each browser pivots a different way; and it changes far too slowly to live up to our demands.

CSS is worse: it is simply unsuited for layout. Don’t believe me? Without looking anything up, design a three-column layout where all columns have equal height even when their contents are unequal. There’s a reason this layout was called “The Holy Grail”.

I used Flex for several years, before returning to Javascript at Paperless Post, and I have to say that Flex may have been huge, may have been overengineered, may have been Flash (an unforgivable sin indeed), but it was also consistent, layered, and open. Open in the sense of open source, but also in the sense this article demands: you could subclass or monkey patch everything in the system. You could make your components do anything you want, while keeping everything that was good about the superclass.

It isn't baffling that "open web" technologies lack this kind of programmer-facing openness. That's a result of the browser wars, the underlying implementation, the original design concerns, the limitations of the early internet, and umpteen other factors both human and technological.

But our systems _should_ become open and layered, or else Javascript polyfills and libraries will be the new platform, and HTML and CSS will simply be the uneven ground upon which that level platform was built. This is very nearly the case already. It's not a future that appeals, but maybe it's what we'll have to learn to expect.

  "What would it mean to be able to subclass an HTML Element?"

"The network is our bottleneck and markup is our lingua-franca. To deny these facts is to design for failure. Because the network is our bottleneck, there is incredible power in growing the platform to cover our common use cases. To the extent possible, we should attempt to grow the platform through markup first, as that provides the most value to the most authors and provides a coherent way to describe behavior to JS.

As markup begets JS objects via a parser. DOM, therefore, is merely the largest built-in JS library.

Any place where you cannot draw a line from browser-provided behavior from a tag to the JS API which describes it is magical. The job of Web API designers is first to introduce new power through markup and second to banish magic, replacing it with understanding. There may continue to be things which exist outside of our understanding, but that is a challenge to be met by cataloging and describing them in our language, not an excuse for why we cannot or should not."

And then finally sum it up with this quote:

   "It is high time we started designing low-level stuff for the web in idiomatic JS …"

http://infrequently.org/2012/04/one-for-dave-and-david/

There's some fantastic discussion in the comments there, too.

Still waiting for someone to invent the thing that lets you write server-side code and client-side code in the same language in the same file, and magically handles the execution of what where (and the secure transmission of stuff between the two) on the server.

I can imagine something like Parse where in addition to sending them data and stuff to store, you can send them a block of code to run on the server. They would of course cache compiled versions of those blocks for speed, but the idea of blocks (as in Obj-C) is an attractive one.

As it turns out, layout and abstraction, as they relate to user interfaces, are two fairly difficult problems. I can say with some degree of confidence that current web standards kind of suck at both of these (I mean, they do an "ok" job, but could be far improved and simplified). This is not entirely anyone's fault (obviously), but rather something inherent to standards. Rather than design a fresh, sensible system, we have been using 20+ year-old standards because...they are the standard.

The first thing I would change? The web is no longer just a series of documents, and needs to be treated like a networked application. HTML and CSS should both die, and there should be only one language that dictates the behavior of a given web page (which can easily call other appropriately sandboxed languages). There is a little bit too much black magic - everything should be transparent. Really, the web browser should be the operating system, not the other way around. Everything a web browser does is beginning to look like an OS (tabs are threaded applications, etc). It seems detrimental to design to force applications to appear inside another application (even if there is a fullscreen ability).

Just my $0.02 ...

I agree with what he is actually saying. However, I am not that excited about building UIs with XML anymore though. I think we should have components that you can edit and layout with graphical designers.

I don't know how you can gradually introduce this, though. Maybe a new doctype? UI toolkits for <canvas>?