I don't drink much, but I couldn't help but notice that the 2008 Hibya Oktoberfest is under way across the street from my office.That's right: they have Oktoberfest in Japan.
In May, no less.
Wednesday, May 28, 2008
Oktoberfest
I don't drink much, but I couldn't help but notice that the 2008 Hibya Oktoberfest is under way across the street from my office.That's right: they have Oktoberfest in Japan.
In May, no less.
Sunday, May 25, 2008
The Perfect Web Interaction Language
I just noticed that my good friend JJ recently posted a rant regarding the mess that web application development has become. I've ranted about the same thing a couple of times in the past, but JJ's words carry more weight since he is a web developer by profession.
Most of this mess stems from the fact that user interaction via the web is defined by at least 5 different standards: HTTP, HTML, CSS,JavaECMAScript, and DOM. HTTP is a protocol; all of the rest are languages, each of which having completely different syntax from all of the rest. On top of that, each standard has multiple different versions. More importantly, each implementation of these standards has varying levels of compliance, effectively creating an ever-changing target to develop for.
Take HTML for example. It is a mess: each web browser has historically rendered the same HTML content slightly differently, supported different tags, and been accommodating of syntax errors to varying degrees. To move the web to a single, consistent, language for describing the content of web pages, the W3C wrote a new specification: XHTML.
Now, good web developers ensure that they always output conforming XHTML, but not everyone does. But then, not every browser accepts conforming XHTML, so there is good reason not to use it (and, as JJ notes in his rant, browser developers have recommended sticking with HTML 4.01 to "ensure the widest browser and search engine support").
This lesson of XHTML is important: it doesn't do any good to make a new standard because you cannot force all browser implementations to support it. In fact, it only makes the problem worse because it simply adds one more possible input a browser may be reasonable expected to accept, hence lengthening the already-too-long list of standards browsers must support (and developers will be expected to know).
CSS, ECMAScript, and DOM are all similar: each browser implements a different set of features that partially overlap each other and partially overlap the standards themselves. An experienced developer is expected to know (and keep up with) what subset of features are safe to use on all targeted browsers and which have equivalent functions and what hacks are necessary to trigger those functions on the implementing browsers. The fact the people even talk about targeting browsers shows just how far we are from having any consistent standard we can depend on to work no matter what browser the document is viewed in.
Now add to this the fact that the HTTP protocol itself, the protocol that is intrinsically linked to HTML, is 176 pages long and (from my experience) poorly understood by most web application developers. Or consider for a moment the fact that you even need to be fluent the mechanics of how the content is delivered to the user (and how input is delivered from the user) in order to write even a simple application. This is Joel's Law of Leaky Abstractions writ large.
Now, let's take a cue from John Lennon and imagine we could start from scratch -- what would the "perfect" environment for web application development look like?
At this point, the problems with the current model are pretty well understood. What if we pretend there is no baggage and we could just start over, developing a perfect language for describing user interaction. Imagine we could develop and deploy a new "browser" that understood this new language and implemented it perfectly to our specifications. Think about it. Seriously.
Not a re-implementation of HTML or XHTML. Not a better JavaScript. Not a better CSS. Those are all thinking too small. How about a single language the describes all aspects of user interaction with a single syntax?
You may say I'm a dreamer, but I'm not the only one.
In fact, as I mentioned above, the W3C has been making motions in this general direction for years. They proposed XHTML and CSS as replacements for the mess that is HTML. But if XHTML and CSS are still not properly implemented by all browsers almost 10 years after their introduction, why should we expect anyone to implement our "ideal" all-encompassing interaction specification language?
My suggestion: we don't.
May I suggest instead, a translator. One that takes a document written in our web interaction language as input and outputs all the hairy HTML, CSS, ECMAScript, etc. that is necessary to get the predominant browsers to behave the way specified by that document. That is, admit defeat and relegate the current web development paradigms to mere implementation details.
In fact, this may not be as crazy as it sounds. There are a number of XHTML templating toolkits for python that can be configured to convert generated XHTML documents into plain old HTML 4.01 documents that all browsers support. Consider extending this concept beyond just output generation, but to the whole of web application interaction.
Think of it as writing a compiler in which the output "machine code" is HTML, CSS, ECMAScript, and the server-side logic.
Is this pie-in-the-sky dreaming? Sure. Is it a hard problem? Sure. Does it risk running afoul of the Law of Leaky Abstractions? You betcha.
But codifying web best practices and cross-browser support behind a consistent high-level language and compiler is priceless. Just imagine the beauty, the joy, that web application development could be. Imagine how much more productive you could be if you weren't coding CSS hacks and having to test on 5 different browsers after each change.
Yeah, it's crazy. But what is the alternative? Convincing every browser vendor in the world to (finally!) implement standards correctly, convincing every person in the world to upgrade to the standards-implementing browsers and ensuring they stay up-to-date as bug-fixes are released for those browsers? Now who is talking crazy?
Most of this mess stems from the fact that user interaction via the web is defined by at least 5 different standards: HTTP, HTML, CSS,
Take HTML for example. It is a mess: each web browser has historically rendered the same HTML content slightly differently, supported different tags, and been accommodating of syntax errors to varying degrees. To move the web to a single, consistent, language for describing the content of web pages, the W3C wrote a new specification: XHTML.
Now, good web developers ensure that they always output conforming XHTML, but not everyone does. But then, not every browser accepts conforming XHTML, so there is good reason not to use it (and, as JJ notes in his rant, browser developers have recommended sticking with HTML 4.01 to "ensure the widest browser and search engine support").
This lesson of XHTML is important: it doesn't do any good to make a new standard because you cannot force all browser implementations to support it. In fact, it only makes the problem worse because it simply adds one more possible input a browser may be reasonable expected to accept, hence lengthening the already-too-long list of standards browsers must support (and developers will be expected to know).
CSS, ECMAScript, and DOM are all similar: each browser implements a different set of features that partially overlap each other and partially overlap the standards themselves. An experienced developer is expected to know (and keep up with) what subset of features are safe to use on all targeted browsers and which have equivalent functions and what hacks are necessary to trigger those functions on the implementing browsers. The fact the people even talk about targeting browsers shows just how far we are from having any consistent standard we can depend on to work no matter what browser the document is viewed in.
Now add to this the fact that the HTTP protocol itself, the protocol that is intrinsically linked to HTML, is 176 pages long and (from my experience) poorly understood by most web application developers. Or consider for a moment the fact that you even need to be fluent the mechanics of how the content is delivered to the user (and how input is delivered from the user) in order to write even a simple application. This is Joel's Law of Leaky Abstractions writ large.
Now, let's take a cue from John Lennon and imagine we could start from scratch -- what would the "perfect" environment for web application development look like?
At this point, the problems with the current model are pretty well understood. What if we pretend there is no baggage and we could just start over, developing a perfect language for describing user interaction. Imagine we could develop and deploy a new "browser" that understood this new language and implemented it perfectly to our specifications. Think about it. Seriously.
Not a re-implementation of HTML or XHTML. Not a better JavaScript. Not a better CSS. Those are all thinking too small. How about a single language the describes all aspects of user interaction with a single syntax?
You may say I'm a dreamer, but I'm not the only one.
In fact, as I mentioned above, the W3C has been making motions in this general direction for years. They proposed XHTML and CSS as replacements for the mess that is HTML. But if XHTML and CSS are still not properly implemented by all browsers almost 10 years after their introduction, why should we expect anyone to implement our "ideal" all-encompassing interaction specification language?
My suggestion: we don't.
May I suggest instead, a translator. One that takes a document written in our web interaction language as input and outputs all the hairy HTML, CSS, ECMAScript, etc. that is necessary to get the predominant browsers to behave the way specified by that document. That is, admit defeat and relegate the current web development paradigms to mere implementation details.
In fact, this may not be as crazy as it sounds. There are a number of XHTML templating toolkits for python that can be configured to convert generated XHTML documents into plain old HTML 4.01 documents that all browsers support. Consider extending this concept beyond just output generation, but to the whole of web application interaction.
Think of it as writing a compiler in which the output "machine code" is HTML, CSS, ECMAScript, and the server-side logic.
Is this pie-in-the-sky dreaming? Sure. Is it a hard problem? Sure. Does it risk running afoul of the Law of Leaky Abstractions? You betcha.
But codifying web best practices and cross-browser support behind a consistent high-level language and compiler is priceless. Just imagine the beauty, the joy, that web application development could be. Imagine how much more productive you could be if you weren't coding CSS hacks and having to test on 5 different browsers after each change.
Yeah, it's crazy. But what is the alternative? Convincing every browser vendor in the world to (finally!) implement standards correctly, convincing every person in the world to upgrade to the standards-implementing browsers and ensuring they stay up-to-date as bug-fixes are released for those browsers? Now who is talking crazy?
Subscribe to:
Posts (Atom)