Last night I climbed into bed and had a eureka moment that kept me awake for a couple of hours. Basically I think I identified how HTML & web browsers need to change to encourage further innovation on the internet. The idea was still ringing around my head this morning so I thought I'd write up the following brain dump and put it out on the web, maybe start a discussion...

Reasons for change

Slow pace of change in HTML

The internet thrives on fast paced invention, but the underlying technology of the web - HTML - is a severe limitation on the ability of the internet community to innovate. Example timeline from Wikipedia:

• 1995 - HTML 2.0
• 1997 - HTML 3.2
• 1999 - HTML 4.01
• 2009 - still no HTML 5.0 - WTF?

Also incompatibilities between different browsers is a major issue, forcing website designers to implement alternative versions of features so that a website will work in multiple browsers. Note that these issues are not just across different companies browsers (IE,Mozilla,Safari) but also across different versions of the same browser (IE6,IE7,etc)

Example of how small innovations lead to major changes

In 1999 Microsoft added a small ActiveX control to IE5 called XMLHttpRequest. This control basically let you make calls back to the server to get data or scripts or HTML, without having to refresh the current page in your browser. By 2005 this technology is in Mozilla and Safari as well, and we have the birth of AJAX, which leads to rich, almost desktop like web apps such as GMail, Google Docs, and many others.

Example of how major changes encourage major innovations

In the beginning you could only write an app if you knew machine code, or C, or C++, or Java/C#, etc. Note each language being significantly easier to learn and encouraging faster productivity than it's predecessor. The same happened on the web. First you had to know HTML to do anything, but slowly desktop apps & then AJAX websites allowed anybody to do anything like read their email, share their photos, or tweet their every thought to millions of people all around the world - no programming knowledge required.

With each major innovation in language or tool, we get an increase in productivity. Witness the development teams behind todays innovative websites who are working in internet time, apps take weeks or months to release new functionality instead of years in the desktop world. Compare internet app GMail for example, which regularly releases new functionality (almost weekly it sometimes seems) to the desktop app Outlook which is stuck in an every couple of years release cycle.

Proposed HTML changes

What is a web browser?

First, lets take a simplified view of what a web browser does. Breaking it down into it's major components:

High level overview

The changes are pretty simple but there's a few steps involved, so let me scan through them first, then go into more detail on each one:

1. Expose the layout & rendering engine through a standard C API that all browsers implement consistently. The rendering engine should have functions for all the basic primitives like drawing text, images, and shapes, as well as modern effects like adding shadows, curved borders, etc.
2. Throw away all the HTML tags! Yep, you read that right, pull them out of the browsers and throw them away!
3. Let anyone with a C compiler and the rendering engine libraries implement their own custom tags. And I mean anyone!

Let's start with the easy part...

Layout & Rendering Engine

Just about every programming language out there lets you draw text, images & shapes, whether it's Apple's Cocoa, Microsoft's MFC or .NET, or even the HTML Canvas tag. Graphics libraries are a known thing these days, it's easy to define & implement them, and with the latest graphics chips we can even use hardware acceleration to make the rendering libraries super fast. Instead of worrying about 'browser wars', Apple, Microsoft, Mozilla etc should just compete in the 'layout & rendering wars'. Who has the fastest layout engine? Who can draw the fastest text with a shadow behind it? Etc.

Tags

This is the main area of innovation in this whole proposal. In order to separate the existing HTML from this proposed future HTML, I need a name for the future HTML. In the absence of a brilliant marketing name, lets just call it NGML - Next Generation Markup Language. It's lame I know, but don't get hung up on that right now, it's just a placeholder name to make the following conversation more understandable!

1. Put the rendering library API's out on the internet, for free
2. Let anyone with a C compiler write their own NGML tags using the rendering library API's.
3. It makes sense that the first tags that get written will essentially be duplicates of what we already have today in HTML. So a very simple first web page might actually look very familiar:
   <ngml>
 <body>
  <h1>Hello World</h1>
  <p>My first NGML webpage</p>
 </body>
</ngml>
   Nothing too different here from a web developers perspective, we're just substituting <ngml> for <html>
4. So if the browser doesn't know about any tags, how does it read this NGML file? Simple, in the same way as it can use DNS Lookup to find web pages, it can now lookup NGML tags. When you finish implementing the C plugin that is an NGML tag (lets use <div> as an example), maybe you submit it to a central repository on the web, or maybe you just let that central repository know how to get at your tag. Basically you're saying "If any webpage asks for my<div> tag, then you can find it at this URL..." - just like DNS.
5. Once a browser has downloaded a given tag, it stores it locally on the users machine in a 'tag cache'. Periodically, say once a day while you're having lunch, the browser can look through the tag cache and check for updated versions of any of your tags. So if I as the developer of <div> realized this morning that I could change a couple of lines around and speed <div> up by 10% then later on that day your browser will download the updated <div>and now all your pages will load and run faster.
6. As much as possible, all NGML tags implementations should be open source. Yep that's a biggie, but let's look at the benefits.
   • If an NGML tag's implementation is open source that means that anyone can look through the code and make sure that the NGML tag is not about to steal all my financial information before blowing up my PC. It's inherently secure because it's in all our best interests to check each others code. 'Bad' tags will quickly become known and abandoned by web developers.
   • Also, anyone in the NGML tag development community can now improve the speed & performance of any given NGML tag. Maybe they can just go edit the code, or maybe they can make suggestions to the original developer and it is up to them to implement or not. Either way, we see regular speed boosts in NGML tag performance.
7. This may also encourage a 'tag war'. Sure <div> is OK, but have you tried <faster_div>, it's 50% faster and smells of mint! A simple refactoring of your web page to switch it to use <faster_div> gives you a significant speed boost, and if enough developers make the switch then evolution takes it's course and <div> dies out.
8. I appreciate that not all NGML tags can or should be open source. If you are a bank and have developed an NGML tag that accesses private banking data, well that shouldn't be available for everybody to see. In this case the browser can warn a user that 'private' tags exist in the page, and I as the user can decide that yes I trust my bank's website, but no I don't trust the private tags in the nigerian-prince-needs-cash website
9. The main innovation however starts to take place as we abandon the traditional HTML tags. Look at the HTML behind any moderately complex webpage and it is a rabbit warren of DIV, TABLE and SCRIPT tags, trying desperately and confusingly to make some text and images look like a tab bar, or a data table, or your favorite desktop email reader. It's a maintenance nightmare, and stifles innovation. Imagine instead if you could simply create a set of tabs on your webpage using a handy NGML tag set that some nice developer on the web already wrote. Something like this: 
   <tab_bar><tab>Welcome</tab><tab>More...</tab></tab_bar>
   • Let's take a moment to re-iterate what happens here:
   • Some nice developer uses C & the rendering library API's to create a couple of NGML tags that look and act like a tab control bar.
   • The browser sees the <tab_bar> in your webpage for the first time, looks it up in the central repository, downloads the code plugin and adds it to the local tag cache. Any time you ever see a <tab_bar> again it comes from the local tag cache, so it's fast. The local tag cache can also be kept up to date with newer versions of <tab_bar> as the developer releases them.
   • All the complexity of acting & looking like a tab is hidden away behind the <tab_bar> tag, instead of a being giant mess of DIV/TABLE/etc tags as it would be today in HTML.
10. NGML tags could define their own attributes as appropriate. For example, an NGML tag written by Twitter to display a users tweets might look like this:
    <twitter_widget account="foo" tweet_count="10" />
    It should also be able to handle standard NGML attributes which are essentially the attributes we see in HTML/CSS today like width, height, id, style, etc. So maybe we'd end up with something like this:
    <twitter_widget account="foo" tweet_count="10" style="width:100px; color:green;" />
11. NGML tags can also throw & handle common events like clicks & mouseovers
12. NGML tags can also be containers for other NGML tags, allowing you to re-implement standard HTML tags like <div>, <table> or create much richer NGML tags like <funky_hip_magazine_layout>.
13. Let's think beyond just the visual stuff though, a tag could basically do anything. For example, what if I could easily define and talk to databases through simple tag structures like this:
    <sqlite3 id="db">
 <table id="people">
  <columns>
   <column id="firstname">
   <column id="surname">
  </columns>
  <rows>
   <row>
    <firstname>Ross</firstname>
    <surname>Cooper</surname>
   </row>
  </rows>
 </table>
</sqlite3>
    and elsewhere in the NGML I could reference this data with something like:
    <sqlite3_ngql>db.people[0].firstname</sqlite3_ngql>
    (Note: ngql = Next Generation Query Language! Go O.R.M.!) Obviously all the major database vendors could either implement a common set of NGML tags, making switching from one DB to another as easy as refactoring from <sqlite3> to <oracle>, <sqlserver> or <mysql>. More realistically, knowing this industry, they would all create their own subtly different tags, leaving a third party coding genius to write an <odbc> NGML tag that knows how to present a single interface that abstracts the subtle differences between the DB provider's NGML tags!
14. Or let's get really crazy, how about writing browser apps that run locally on your PC, like your own version of Microsoft's File Explorer that could be as simple as using some handy NGML tags that good old Microsoft implemented for you to use:
    <ngml>
 <splitter>
  <left>
   <microsoft_directories init_dir="My Computer" />
  </left>
  <right>
   <microsoft_files />
  </right>
 </splitter>
</ngml>

Proposed scripting changes

Level setting

First let me state that I'm not particularly biased about languages or technologies. I develop for Macs & PC's. I routinely switch between C, C++, C#, Objective-C, Python, Ruby and Javascript without too much of a problem. As an old friend used to say, 'they are all just tools in your toolbag.'

Secondly, I'm prepared to admit that changing the scripting engine on top of everything else, could be viewed as change for changes sake. But I do think there's some advantages which I'll explore below...

Ditch Javascript

Out of all those languages I have to say that Javascript is the worst. It's not that it's terribly bad, but it is very half-baked and convoluted, especially when you try and do anything object oriented with it. I'm not saying it can't be done, just that the syntax isn't clear or precise or elegant, and therefore doesn't lead to small, maintainable, well designed code IMHO.

Use Ruby for scripting

If the word 'Rails' jumped immediately into your head, erase it immediately. I'm just talking Ruby here. It has an incredibly great syntax, it's the most Object Oriented and Design Pattern heavy language out there, and in my experience I can write anything in Ruby in half the lines of code that it would take in any of the other languages (except maybe Python). I also found on some recent projects, that if I mocked the code up in Ruby first, I ended up with a much smaller, more elegant Object Oriented solution that I could then re-implement in C# or whatever language was required. Ruby makes you write better code. Better code makes for faster development, easier maintainability, and a more innovative internet.

Use Ruby for NGML tag development?

Well initially it may not be fast enough, or at least orders of magnitude slower than a C implementation. But look at the recent speed improvements of Javascript. At the time of writing this document, Safari 4 beta was just released with a javascript engine allegedly 42 times faster that the javascript engine in IE7. With Ruby as the main scripting engine behind web browsers, it would get the same attention that javascript is currently getting, with similar speed increase results. At some point, it becomes fast enough that you could develop NGML tags in Ruby too. Sure maybe you wouldn't do that <div> that gets used 1,000 times on your webpage, but that <twitter_widget> or <tab_bar> that gets used once? Why not?

Summary

Well that's all I've got for now. Yes there are probably a million holes and issues to be worked out, but that's for you kids to solve ;-) Basically in summary:

• Free tag definition from the shackles of the IETF.
• Let anyone either re-implement the existing HTML tags (for backwards compatibility) or create entirely new & amazing NGML tags that make web developers lives much simpler, and encourage innovation.
• As often as possible make the NGML tags open source, encouraging security and performance through peer review.
• Provide a C API to a standard web browser layout & rendering library that the NGML tags can use to draw themselves, or contain their child tags.
• Traditional browser vendors compete on the speed & performance of their rendering & layout engines
• Switch to Ruby for improved scripting capabilities.
• Allow NGML tags to be written in Ruby as well as C.

Thanks for taking the time to read this. I'd love to hear your feedback here