Skip to main content

HTML is dying

Posted by felipegaucho on July 3, 2006 at 6:48 AM PDT

The last decade of the XXth century was marked by the HTML advent, from a simple language rendered by the Web Browsers to the standard de facto of Internet contents: web-pages, mail and business applications. Several interesting innovations were applyied to the first draft of the HyperText Implementation in order to support the e-commerce demand, including multimedia tags and dynamic web layouts. No doubt the HTML is the most sucessfuly language in the software industry but, despite this amazing supremacy in the web publishing, it seems the end of HTML life-cycle is coming.

The problems of the HTML in the nowadays business scenario

While the HTML was growing in the popularity and the browsers were becoming more sophisticated, the users were experimenting other ways of interacting with the computers. Operational systems with easy usability, real time games and desktop suites with friendly layouts had pushed the users expectative to a higher level and then the Html started suffering its own restrictions. Some of these restrictions are enumerated below:

  • Html is good for reading, not for using: text pages are very good for reading, more like a book than a software. Modern computer users are mouse centrics and usually expect to interact with the computer contents - like drag and drop, copy/paste of everything including images, sounds, etc. Html is usually showed up by browsers in a not editable way - it forces the users to use external software to edit the original contents. The exigence of using several tools to manipulate a document can be a painful task for the non-programmers users.
  • The browser dependency: HTML itself is just a text document and it requires a renderer in order to be converted in a hyperlink document - a renderer could be anything able to recognize the Html specification. Despite this generic definition, time has proved the browsers are responsible for the most part of html rendering and, unfortunately, browsers vendors don't respect the W3C definition about the html language. Different browsers produce different rendering output and some of the most popular browsers include specific tags in the html definition, converting the language in a proprietary dialect. These specific tags created by browsers vendors force the developers to re-work a page in many dialects, creating tricks in order to produce portable html pages. That's odd!
  • Colors and fonts: when the html was introduced (90'), people were happy with colored pages and text restricted to a small set of fonts. Today, operational systems come with hundred of fonts sets and the users are familiar with that. From the programmer perspective it is a nightmare because we must choose between a poor layout - based on the original small set of fonts - or a very tricky effort in order to embeed the fonts in the document. Usually, the embedding of the fonts in a Html page convert even a short text in a very large document.
  • Transparency, animation and other special effects: html documents cannot be overlaped, don't support transparency and even including interactive animations in a web page can be complex. Users are often exposed to interactive tutorials, help cartoons and to the simulations of an intelligent behaviour in the desktop applications and operational systems. It seems impossible to reproduce such so sophisticated tricks in a simple html page.
  • Html was not designed to be an application: HTML is a plain text document. The effort required to simulate a dynamic behaviour embedded in a HTML page is enourmous and sometimes a dumb and repetitive task. The other problem is that the dynamic behaviour presented by the Html pages is not even near to the usability presented by a real application. Can you imagine, for example, a person using a word processor developed in Html?

The new perspective: rich clients, desktop applications revival or GUI support on the OS?

From the browser experience, we get the Hyper Text Transfer Protocol (HTTP) and the client/server paradigm as the best results. Despite the flaws of the server centric paradigm, Http becomes a consensus as the broader used communication protocol in the world. The question now is what will be used on the client side? Several technologies are candidates for replacing the Html format and the next few years promise to be an interesting experience of marketing, technology and passion about usability on computer. It is absolutely impossible to foresee what the users will really approve, but some trends started making noise:

  • Web x.0: there is a chance that the browser and the html itself still remain usefull through the usage of innovative technologies like AJAX, JSF, WebForms, etc. Sincerely, I don't believe it will happen.
  • Rich clients: the idea of a Rich Client is simple - instead of distributing a lot of bytes with the complete application (feeling Applets?) the server distributes a description of the application. On the client side, an already installed application knows how to convert the description in a real application, with the full power of a desktop application. It is very similar of the Html concept, but instead of distributing a set of tags to be rendered as a document, it distributes tags (or other thing) to be converted in an application. Depending on the schema adopted to transfer the application description, a complex application can be downloaded in seconds and can use all performance of the local machine. The problem is: once again, vendors don't follow a pattern and every rich client framework comes with a complete different dialect to describe applications - goodbye interoperability. Recently, several Rich Client Plataforms are available for production: Eclipse RCP, XUL, Spring Rich Client, Flash MX-A, etc.
  • Desktop Application Revival: computers are getting faster every day, and the Internet connections are presenting amazing bandwiths. A user can download, install and run a heavy application in few minutes and the quality of the hardware resources is promoting a re-thinking about the usage of Dektop Applications as the best user interface for distributed systems. You can use EJB 3.0, JPA and JAX-WS to create a business core on the server and you can use Swing/SWT to create a powerful application to enlight the user experience on the client side. Swing, for example, is a mature technology that offers much more productivity and allows a much better usability than a web application embedded in a browser. I specially recommend you to check out the Aerith project about what can be done with Swing nowadays - it is simply amazing. The tools to produce desktop applications is also a remarkable aspect about the adoption of Desktop Application as user interface - NetBeans, JDeveloper and other tools are the state of the art of IDEs. The only problem here is the culture of the programmers - after a decade of web programming, many of the best programmers on the market simply don't know how to program for desktop anymore :)
  • GUI support on the OS: Microsoft Vista is coming and despite my preferences or not about the American giant company, I recognize the absolute majority of the users uses windows. The new version of the most popular operational system in the world comes with support for a script language (Gadgets) which allows programmers to produce applications based on an OS script. It is the same idea of the rich clients, but instead of an application rendering the script we get the OS doing that - supposedly more performance and better look and feel, etc. Vista is the first operational system which will render application from scripts (I guess), but the linux community is also working to get such feature available very soon (see gDesklets).

Open (old) questions: interoperability and new devices

Despite all promises, the same old questions are still alive: which technology allows me to deliver my business to every device (mobile, computers, e-paper, embedded devices, etc.)? Which technology allows me to interact with the legacy code and also provides me the opportunity to aggregate my applications to a SOA environment?
Well, my friends, I don't know the answers, this blog is simply to register the end of the Html language, at least in my own beliefs. I remember that one of my first graduation homeworks was about to create a Html page and to explain to my teacher the techniques I used to produce it - I used Notepad and a manual about the html tags, I also included some animated images and fancy buttons... It was very intersting at that time but now it seems this is the moment to accept the idea of a world without browsers. Goodbye my dear Html!

Related Topics >>