 |
HTML is dying
Posted by felipegaucho on July 03, 2006 at 06:48 AM | Comments (8)
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!
Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
Not so fast!
Perhaps you're tackling with two different issues. The web is a environment created for sharing documents, not for applications. Clearly, this paradigm explains all the hassles we had in the last decade (cookies, forms, session management, file uploading, and dynamic content on both client and server comes to mind).
And then people came with ideas and concepts. Servlets/JSP, Flash, Ajax, CSS, Applets, WebStart, and now there's XAML/XUL coming up.
Each technology must be carefully evaluated and analyzed in it's own paradigm. That's the point: To tell HTML is reaching it's end-of-life is to ignore the effort we had in making standards, enforcing then, publishing documents using it, and building new applications which leverage'em. Its clearly an economical question, which makes the mantra "HTML is so 90's. Lets get Rich Client Apps" look really silly.
And don't forget: Clearly, it's still beats all the other tecnologies by a *VERY WIDE* margin whenever you think about critical mass. And don't think you can convince your Marketing Department the other way. Smoke and Mirrors may confuse, but numbers restate the obvious: HTML still has a very long horizon ahead.
Posted by: aldrinleal on July 03, 2006 at 10:41 AM
-
I also think we will write less HTML every day, but HTML, JS and CSS are major building blocks of web (X.0), i don't see it going away. Just because you don't see assembly anymore, it doesn't mean it is gone.
Posted by: julio_faerman on July 04, 2006 at 05:54 AM
-
Vista will be the first operating system to render applications from scripts? Hmm? What about Apple's Dashboard?
Posted by: afishionado on July 04, 2006 at 12:34 PM
-
html is not about to die... the web is also about sharing simple documents. not everyone is trying to code the online Excel.
Posted by: ilazarte on July 04, 2006 at 01:14 PM
-
In my opinion WebStart is the answer, and it's already here! I think SUN should push more this great technology. Every time I show a jnlp application to a new person I get the same result: wonderful!
Posted by: ddpole on July 05, 2006 at 04:28 AM
-
Yeah right !
Pigs will fly too.
BTW ... Apple Dashboard which will also be intergrated in KDE 4.0 ... doesn't that ring a bell ?
But I guess Gnome and Vista steal the spotlight again ... because, you know, they are mainstream ... that sucks, doesn't it ?
Posted by: bonefry on July 05, 2006 at 01:54 PM
-
Nobody is dying. HTML won't die (not in the short-term)
and will stay as one of the most convenient way
to write web personal pages for the regular surfer.
But, sure, HTML future is limited, as I dont think HTML will be used for developping next RIA applications.
This being said,
we don't have to confuse HTML and XHTML.
To be precise, all I have written above was about HTML, and not XHTML, as IMHO,
their futures seem separated.
I have written a post about it:
Revisiting XHTML as a base (?) for XUL-like programming.
Posted by: dmdevito on July 25, 2006 at 09:00 AM
|
java.net RSS Feeds
