Conversation about "Web Applications Architecture" additional background for TAG discussion

I thought I would send out a summary of conversation with Mark Nottingham about "Web Applications" for additional background for our conversation about the IETF/IAB plenary in late March.

===============

Mark:

For me, the crux of the issue in 'Web Applications Architecture' is that the browser vendors are "dumbing down" the Web to a much lower-level interface, whether it be getting information onto screens (Canvas) or onto the wire (WebSockets). 

AIUI this is because they see such interfaces as having greater interop and therefore less QA headache, and they have an expectation that 3rd party javascript libraries (as mobile code) will build on top of these low-level interfaces to provide additional functionality, rather than standards.

As such, this is a titanic shift; Open Source is taking the place of Open Standards. Unintended reuse is probably the biggest potential casualty, in that you can no longer count on any semantics in the protocol or format; that's all buried in a library which you have to recognise and then extract information from. 

It's also a big change for vendors, whether they be big companies, startups or open source projects; what remains to be seen is how they'll adapt (or not). For example, while Google today has the resources to spider a severly fractured Web, it didn't at the start, because it was a beneficiary of the semantics in HTTP and HTML, and the simpler nature of the Web then.

It's obviously also a big change for the W3C and IETF, one that perhaps we've walked into without fully thinking through the repercussions. I'm not sure that I want to argue against it, but I do think it needs to be openly discussed and understood by the communities.

============

Larry:

 I'm not sure the problem Mark talks about hasn't always been with us -- AOL instant messaging, Flash, the web itself grew up because people could just ship implementations (plugins or installable apps) that used TCP and UDP and deploy them.  Maybe this is a scale issue? Maybe it's just a "support unintended reuse please by making URIs for things that are reproducible session state" or "in addition to your UI always make a net-accessible API to support reuse" is the new design pattern we want to encourage?

============

Mark:

I think there's a lot of truth in what you suggest, but it's a bit more. In the past, someone who wanted to get one of these applications deployed needed to convince someone to install some software. Now you can deploy increasingly capable software without realising it, just by clicking a link. 

WebSockets doesn't use URIs meaningfully, and it allows you to construct bespoke protocols. I guess what I'm concerned about is that these new efforts seem to be regressing; rather than building on top of the well-understood and shared semantics of HTTP, HTML and URIs, they're encouraging developers to re-invent them by providing much lower-level APIs. That makes things easier for those with a QA focus, but I wonder if it's better for the community as a whole.

Received on Friday, 18 February 2011 23:03:55 UTC