Refactoring - Refactoring HTML: Improving the Design of Existing Web Applications - page 16

What to Refactor To
There is one critical difference between refactoring in a programming language such as Java and refactoring in a
markup language such as HTML. Compared to HTML, Java really hasn't changed all that much. C++ has
changed even less, and C hardly at all. A program written in Java 1.0 still runs pretty much the same as a
program written in Java 6. A lot of features have been added to the language, but it has remained more or less
the same.
By contrast, HTML and associated technologies have evolved much faster over the same time frame. Today's
HTML is really not the same language as the HTML of 1995. Keywords have been removed. New ones have been
added. Syntax and parsing algorithms have changed. Although a modern browser such as Firefox or Internet
Explorer 7 can usually make some sense out of an old-fashioned page, you may discover that a lot of things
don't work quite right. Furthermore, entirely new components such as CSS and ECMAScript have been added to
the stew that a browser must consume.
Most of the refactorings in this topic are going to focus on upgrading sites to web standards, specifically:
XHTML
CSS
REST
They are going to help you move away from
Tag soup
Presentation-based markup
Stateful applications
These are not binary choices or all-or-nothing decisions. You can often improve the characteristics of your sites
along these three axes without going all the way to one extreme. An important characteristic of refactoring is
that it's linear. Small changes generate small improvements. You do not need to do everything at once. You can
implement well-formed XHTML before you implement valid XHTML. You can implement valid XHTML before you
move to CSS. You can have a fully valid CSS-laid-out site before you consider what's required to eliminate
sessions and session cookies.
Nor do you have to implement these changes in this order. You can pick and choose the refactorings from the
catalog that bring the most benefit to your applications. You may not require XHTML, but you may desperately
need CSS. You may want to move your application architecture to REST for increased performance but not care
much about converting the documents to XHTML. Ultimately, the decision rests with you. This topic presents the
choices and options so that you can weigh the costs and benefits for yourself.
It is certainly possible to build web applications using tag-soup table-based layout, image maps, and cookies.
However, it's not possible to scale those applications, at least not without a disproportionate investment in time
and resources that most of us can't afford. Growth both horizontally (more users) and vertically (more features)