My opinion on the future structure of the web

With XHTML Strict we have separated content and design. Using CSS we have been able to remove much redundancy in the code delivered to browsers. We basically define snippets of design and apply them on an arbitrary amount of elements.

I believe the next step is to separate data and structure, by defining snippets of structure and applying to on arbitrary amount of data.

This can be easily achieved now using jQuery Templates, which at the time of writing is in beta.

Example:

Imagine the comment-section on YouTube or this blog. Each comment might have an image, a timestamp, username, thumbs-up/down and some wrapping. All this XHTML code is repeated for every comment.

A short comment

Using a short YouTube comment as an example, the XHTML code consists of 721 bytes of data (which has been generated in a loop on the server side and transmitted to the browser). Removing all XHTML code from the example comment - leaving only the actual information needed - yields 48 bytes of data. In other words: The XHTML code contained 6.657% information, the rest being redundant structure code which is repeated for each comment.

Visual representation:

Code of the short comment:

<li data-author-viewing="False" data-id="5mm3YzP7OX3U298MLeHm0HolNSkstTdEdfbrhWTEAnI" data-score="0" data-author="SuperWizTech" data-pending="0" data-blocked="False" data-flagged="False" data-removed="False" class="comment current"> <div class="metadata"> <div> <a class="author" href="/user/SuperWizTech" title="SuperWizTech">SuperWizTech</a> </div> <div> <span class="time">4 months ago</span> </div> </div> <div class="content"> <div class="comment-text" dir="ltr"> <p>completly awsome? :D</p> </div> <div class="metadata-inline"> <a class="author" href="/user/SuperWizTech">SuperWizTech</a> <span class="time">4 months ago</span> </div> </div> </li>

A long comment

The same comparison on a (relatively) long comment yields an information-to-structure-code-ratio of 453 / 1518 = 29.84%

Visual representation

Code of a long comment

<li data-author-viewing="False" data-id="5mm3YzP7OX2-iXk_QNRtPTEnt5jOC_kWffObtTXjW24" data-score="4" data-author="jpsieben7" data-pending="0" data-blocked="False" data-flagged="False" data-removed="False" class="comment current"> <div class="metadata"> <div> <a class="author" href="/user/jpsieben7" title="jpsieben7">jpsieben7</a> </div> <div> <span class="time">2 years ago</span> <span class="comments-rating-positive">4 <img class="master-sprite comments-rating-thumbs-up" src="http://s.ytimg.com/yt/img/pixel-vfl3z5WfW.gif"></span> </div> </div> <div class="content"> <div class="comment-text" dir="ltr"> <p>what you could do is get a rechargeable battery pack and 2 nxts. then have the base hooked up to the wall so it automatically keeps charging and then have the base use the light sensore and send out a strobe which the bartender finds and? goes and gets. a little bit more complicated but would be a bit more acurate and quick. also make the base have a gravity fed drink loader in it so when 1 is taken another takes its place.</p> </div> <div class="metadata-inline"> <a class="author" href="/user/jpsieben7">jpsieben7</a> <span class="time">2 years ago</span> <span class="comments-rating-positive">4 <img class="master-sprite comments-rating-thumbs-up" src="http://s.ytimg.com/yt/img/pixel-vfl3z5WfW.gif"></span> </div> </div> </li>

Summary

Assuming (educated guesses):

• Average comment text size: 200 bytes (justified for some Unicode encoding)
• Additional unique data per comment: 50 bytes (such as: index; special class-names)
• Data structure overhead per comment: 30 bytes (using JSON)

If we were able to represent the data (username, comment-text and timestamp) with said overhead and have its structure defined only once, the comment section on YouTube would only use less than 25% (280 / 1265 = 22.134% in this example) of it's current bandwidth for the comment section for each [page view]/[comment page-flip].

Simply put, separating structure from data on the web would first of all reduce many chunks of redundant code in repetitive sections (such as in comments- and search-result-sections). Secondly the data would - by design - be set free from their client-specific (in this case client = web-browser) delivery.

One benefit from such a separation would be the possibility of easily creating a completely different interaction to the internet service on a mobile client, without the need of making a new API for this.