HTML and CSS often feel like they are poor fits for the purposes we put them to.
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.
It appears to me that one the author's points is that the problem is not with HTML or CSS, but basically with Web IDL. We are forced to use JavaScript for HTML and CSS manipulation, but it could be avoided with better interfaces. E.g., if we could painlessly create <input type="location"> and describe its API and behavior from our JS… which apparently isn't possible with current implementation. See also another author's post at http://infrequently.org/2011/10/real-constructors-webidl-las....
> Without looking anything up, design a three-column layout where all columns have equal height even when their contents are unequal.
I can see your point, but this particularly is not that hard: http://jsfiddle.net/fbJ6J/. I know, I know, but it does comply with your requirements. =)
"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 …"
Every year we’re throwing more and more JS on top of the web, dooming our best intended semantic thoughts to suffocation in the Turing tar pit. JS libraries are the “fuck it, we’ll do it live!” of the web.
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.
Check out nowjs[1]. It's not quite what you want, but I think it's in the same spirit. I haven't used it personally, but I've heard only good things about it.
I'm not sure that it lets you share code between sever and client entirely seamlessly (it might--I honestly don't know), but it has another advantage: it lets you share objects between different clients seamlessly.
I'm working on such a thing during my free time, it's very interesting and I don't understand why nobody implemented this idea, but there are frameworks which do it, like vaadin for Java (it generates JavaScript through GWT )
I would be very pleased to hear from people who would be interested in such a language - what features they will want from it.
As someone who has written several GUI systems from the ground up (including lower-level stuff like font rendering and GPU-accelerated rasterization) I think the author has many good points.
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).
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 think he's saying that the open web needs to be designed from the viewpoint that JavaScript is the lowest level of abstraction (not C++), and that HTML is the highest level of abstraction.
In other words, design the entire platform from the point of view of web developers, not browser developers.
The symptom here is the way how, every so often, you run across comments saying "The DOM sucks, browsers should standardise and ship jQuery". But jQuery doesn't solve every problem and might not age gracefully. The obvious response is to go in the other direction, and have all the layout code specified by the page.
I don't know how you can gradually introduce this, though. Maybe a new doctype? UI toolkits for <canvas>?
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.