HTML generation is bad

June 21st, 2005 § 1 comment

In the ten years since I started to work developing Web applications, I learned something well: never trust a library to write the HTML for you. The more I work with Web applications the more persuaded I am that this is a good rule. Any library that hides the generation of the presentation layer behind complex routines or components tends to limit choice and make optimizing the resulting HTML a real pain — if possible at all.

The problem with such kind of abstractions is that they leak too easily, leaving the developer in a situation in which he must uses the abstraction only for simple things and break it every time something more complex is needed.

Take .NET, for example, since it’s especially awful in this area. Created to completely eliminate the need to write HTML by hand, it ends up uselessly complicating the job of programmers, forcing them to deal with two interfaces at the same time to achieve an objective that concerns only one of them. The result is a half-baked solution, hard to read and hard to maintain, with unpredictable results in different platforms.

Effectively, those libraries ignore the decisions made by the programmers, generating code that may, at first glance, behave the way the programmer intended it, but that is often so riddled with collateral effects that it will surely cause problems in the future.

This is fatal when Web standards come into the equation. Taking .NET as a example again, one of its components is intended to simulate a panel in a normal UI. On Internet Explorer, the component is correctly rendered as a <div>. On Mozilla, however, it comes out as a <table>, completely changing the page’s semantics, which, on its turn, will affect style sheets and scripts related to it.

When I started programming for the Web, it was the sheer boredom of creating all the widgets needed for a page by hand that lead me to create my first libraries to take care of writing HTML for me. Learning by experience that those libraries more often hindered me than helped me, I went to the opposite extreme, using templates engines that simply exposed the data coming from the business layer to the presentation layer in the form of arrays and hashes, using looping statements and simple functions to enumerate items or select between to values. That didn’t help me either.

With my recent experiences in Rails, I’m finally seeing how a framework can eliminate the boredom of writing HTML code while still keeping readability. Rails offers functions to generate HTML but those functions are generally simple and transparent, a simple layer over the presentation layer itself. This thin layer is flexible and it’s simple to customize the functions to generate only what you really need. They save time on simple tasks without preventing complex tasks from being done.

Rails, of course, is not perfect. Some of its functions can only be customized if they are overridden — errormessagesfor comes to my mind, for example.

Others tools are worse. PHP blends logic and presentation in an unacceptable way. On the other hand, .NET presumes to separate them but they remain tightly coupled behind the scenes. The various libraries and frameworks for Java make both mistakes. Rails attained a good balance of this area mainly because of its good use of MVC, but care must be employed when designing new function to avoid trying to excessively simplify things.

Anyway, it seems things are starting to get better. More and more people are thinking about those subjects, and I believe new libraries will be even more practical in this area.

§ One Response to HTML generation is bad

What's this?

You are currently reading HTML generation is bad at Reflective Surface.

meta