We need a new thin client
Written by mufasa
We need to replace HTML. HTTP/HTML is an almost two decade-old prototype that has kept its basic form while many buggy and slow extensions have been mashed on top of it. It is now a hopelessly inefficient, quasi-rich client that does almost nothing well while maintaining a legacy language, HTML, that doesn’t do much and that nobody cares for. Worse, as an “open standard,” there are multiple incompatible implementations, either because the spec is vague or the implementers want to differentiate themselves. I would like to throw all this garbage out and start afresh with a new thin client. If we can get this right, maybe then we can start thinking about a rich client. Here is what I would like to see:
- Better GUI elements – The UI elements of HTML may have been appropriate to 1990 but have become dated and limiting. Why do we make designers come up with all kinds of hacks for basic elements like menus or proper spacing? A good thin client should have a limited subset of GUI elements built into the specification, those that are the most popular and easiest to secure and implement. HTML comes nowhere close to fulfilling this criteria.
- Sessions – HTTP is based on a request/response model because of the bandwidth limitations of the late 80s that no longer exist. Today, we trick the browser into a session model using AJAX or COMET or Name Your Acronym. Why not build a thin client that uses sessions as its atomic unit?
- Binary encoding – It makes sense for a research prototype like HTML to use text to encode GUI elements but why are we still using text to this day? When a widely distributed thin client employs inefficient and useless methods, it just leads to a lot of waste. Almost nobody edits HTML at the text level so there is no use for markup.
- A GUI for design, not code – No designer wants to muck around in code in order to get their GUI looking just right. A new thin client should allow designers to use a graphic design tool to design their application’s views and get them looking just right, before the views are compiled to a binary encoding.
- No standards process – The internet standards process has not helped application protocols like HTML. Rather, it has led to multiple implementations that each has their own quirks. Part of this is because of the vagueness of important sections of open standards, perhaps it is impossible to precisely detail any reasonably complex technology. Part of it is because every implementer tries to differentiate themselves by adding special features that are incompatible with the other implementations. What is important for a software platform is that it is open to reimplementation and the resultant competition, allowing developers to always have the choice of moving to another implementation, not that it conforms to some preconceived standard. I have expanded on this topic.
The essence of a thin client is to implement the most common GUI elements across multiple hardware and OS platforms while maintaining security. A thin client can be thought of as a first stab at ubiquitous network computing, where the security hassles of having the information superhighway coming into your PC- and the internet bandits and thieves who can now drive right up to your computer door- are handled by the thin client platform so that developers don’t have to. We can do much better at this than we are doing now. And finally, think of the children. If we don’t come up with a new thin client, what will we leave them?
I would like to hear more ideas on this subject from others and I will expand on each of the topics above in more detail. This blog is a place for discussion and sharing ideas, I would love to hear what others who also hold their nose at the current HTML/AJAX mess think.
Questions:
- What new GUI elements would you like to see?