Web Application Composition

I find tragic that we have only the ever-growing monolith of HTML5 on which to build web applications. Sure, it includes some good stuff like canvas and svg, but overall I find it a monstrosity. Whatever happened to XML namespaces? I know, “XML! Run for the hills!” However, the use of namespaces allowed simpler markup formats to be intermixed, and it worked rather well though a bit tedious to write by hand. Ultimately, I think the need to write these things by hand, due to bad tooling, led to the death of XML as a beloved format. Unfortunately, XML namespaces were replaced with a hack the size of Facebook. And the world cheered.

The majority of programmers are completely fine with their hacks upon hacks. I applaud these Herculean efforts. We all want to build something, and the fastest way to do so is by using what’s available. Today, we have HTML5 + CSS + JavaScript. Why do we have those? We have them because the editors given to us in the past so completely failed to work as promised. HTML nested table elements for layout anyone? (I am so sorry for you if you are still dealing with this.) The promise of XML was that machines could read and manipulate it easily (and they can) and that developers could safely ignore it. Of course, as a text-based, readable format, developers could still work out any kinks, should any arise. Unfortunately, we had kinks arising everywhere, like we were living through the Walking Dead of XML documents.

In giving up the various, independent XML formats, such as MathML, SVG, XForms, XHTML, XSLT, etc., we lost a lot of potential in the form of composition. Remember, these are data interchange formats. Yes, even XHTML, contrary to the attempts to make it an application platform. Before, you could compose multiple formats together into one. (If you would like to see one, the W3C still has one lying around.) Today, you are at the mercy of the HTML5 committee and the browser makers. We also lost the option to use XSLT rather than CSS for styling, and CSS grew from a roughly layout-oriented spec to include content insertion and animation. These hacks work, but it’s like building a skyscraper with duct tape and baling wire.

We are not without hope today. Composition reappeared through various, mostly JavaScript-based technologies, such as Web Components and React. These aren’t a true replacement for what we lost, but they certainly help make up for what was lost. What’s interesting is that these rely on browsers’ JavaScript engines, which are really fast now, and yet they keep building on HTML5. Why? Why not create something even more basic?

Think about how we might be able to right the wrongs of the past with XML by making the browser more like an app container. What if you could build up one or more formats, be they markup, JS, etc. and compose them together? What if the basic building blocks were a new DOM that defined only a few simple primitives and some rules for inter-connecting formats? (I would like to link to the experiment of re-writing HTML5 as web components, but I cannot find the link anymore.)

I’m sure at this point that many of you have flipped back into thinking of HTML as a view layer. I continue to disagree with this notion, despite the massive additions made by HTML5. In the end, HTML is a data format, and the browser knows how to parse that format and render it visually. However, HTML is still a fantastic data format. In fact, Mike Amundsen wrote a book, Building Hypermedia APIs with HTML5 and Node, describing HTML’s adaptability as a data interchange format. I used to be excited about the possibility of sending XHTML+MathML+SVG payloads as data.

Unfortunately, JSON became the standard interchange format. JSON has a lot to like. It’s small, easy to create, easy to evaluate in a JavaScript application, etc. However, it has no semantics for how to merge or include multiple, derived formats. This is mostly a problem in that everyone sends application/json as the media type, so no machine could ever understand what was included. Newer efforts, such as HAL, Siren, UBER, and JSON-LD, also fail to address format composition.

I hope the situation changes. I would like to help. After Darrel Miller‘s talk at APIStrat 2015 in Austin, I downloaded the tools necessary to write an RFC to define media type composition. Unfortunately, I am still trying to figure out exactly how that might work. If you kept to a common base format, such as XML or JSON, things would probably work out alright. But what happens if you want to allow someone to mix a YAML document into their JSON? Things get tricky, especially considering JSON has no concept of links, so you can’t even add it as an external reference or import. Another likely use of this might be to provide a mechanism for code-on-demand for multiple languages. The possibilities really are limitless, especially if you wrap this back into my desire above to replace HTML in browsers with something much more primitive.

If this strikes a chord with you, please reach out in the comments. I would love to see this move forward, and I really need help. If you know of anyone else already attempting something similar, please let me know, as I would love to help.