Web-Procreate.Com - Datafeed and WebMerge Section


In Praise of Tools

Why Hand-Coded HTML is Usually Bad Business

An article by Richard Gaskin, Fourth World Media Corporation. - Copyright ©2001-2005 Fourth World

Abstract

Deep knowledge of HTML is essential for any Web development effort, but some developers advocate hand-coding all HTML, citing code size and efficiency as benefits of this practice. But given the state of modern HTML and JavaScript authoring tools, the majority of code for robust sites is not dramatically increased by such tools, and the use of such tools can reduce development costs by orders of magnitude with little or no increase in robust production-quality code.

“When a client buys a Web site, they probably don't care whether a human
or a machine typed the majority of code. But they will care about cost.”

When was the last time you patched a roof without a hammer? Or made a smoothie without a blender? Or changed a car tire without a jack? It's possible to do all of these things without using tools, but why would you?

Yet when it comes to HTML authoring, there are still a number of holdovers from the last century who advocate hand-coding all HTML. You can often spot their Web sites at 50 yards: few graphics, poor layout, and generally only a few pages. Do these people also type PostScript directly to their printer instead of using PostScript-generating tools like Illustrator or Freehand?

It's extremely important to know HTML well, if only because tools are valuable but also imperfect.

But while advocating hand-coding may appear studly in some circles, if used exclusively it's usually a bad business decision. Exclusive hand-coding chooses a workflow that artificially lengthens the development process. "<TD>" is a four-character tag, whether typed by a machine or a human, but a human simply can't enter text as quickly as a machine. Functional HTML is functional HTML, and if well-formed there should be little difference between human- and machine-generated code.

JavaScript allows more variance, but by the time you include robust error-checking and factor the code into reusable functions suitable for heavy production work, there will not likely be a significant difference in overall code size between an authoring tool's generated code and similarly-reusable hand-written code.

Keep in mind that an authoring tool's code is indeed hand-written; it was written by professional software engineers and merely copied into your page by the tool. When you buy Adobe GoLive, Macromedia Dreamweaver, or other professional Web authoring environments, you're also buying pre-written JavaScript libraries crafted by experts.

The advantages of such libraries are many: the code is already designed, written, and tested on a wide variety of platforms and browsers. And in most modern HTML authoring tools, the code can be employed in just a few clicks by production staff, who in most companies have a lower billable rate than programmers. This leaves programming resources available for more complex or unusual tasks not commonly addressed by authoring tools.

Of course, you can almost always write specialized single-use functions with less code than a more generalized function would use, but again that raises development costs. Is reducing page load time by less than 2 seconds worth the extra several hundred dollars, or even thousands, in additional development costs to your client? Before a Web consultancy considers hand-coding to be a positive marketing message, they should ask that question of their clients.

Modern HTML authoring tools like GoLive and Dreamweaver provide options for removing white space and comments that can help further reduce the overall size of HTML and JavaScript code. In many cases, stripping alone can reduce code size below levels needed for hand-coding in a production environment, since comments and white space are essential for teams crafting production-quality code. Hand-coding advocates who do not format their code for human readability drive up costs further by slowing maintenance and enhancement, and making knowledge of the code less transferable among team members.

Authoring tools offer other cost-cutting features as well, such as reusable code snippets that can be inserted across pages throughout a site in a single move. For example, the header and foot of this page are what GoLive calls "components", snippets of HTML that updated once, and GoLive automatically copies the code throughout the 100+ pages on which they appear, modifying image paths and links as it goes. GoLive commonly does this update in under five seconds, while attempting to do it by hand would take several hours with a process that's inherently more error-prone.

For clients who requires extremely tight code, we wrote our own HTML/JavaScript stripper that does such an efficient job that the code is nearly unreadable by humans, but renders well in the browser and reduces average page size by about 30%. Our HTML authoring tool, GoLive, let us create complex pages more quickly than hand-coding, and with our internal stripper tool the resulting page is usually smaller than is humanly possible (certainly well beyond practical). Can a hand-coder make a complex layout faster and smaller?

When you buy a car, you don't expect the dealership to start smelting steel.

We expect manufacuring in any mature industry to use automated processes wherever practical (houses are still built using ancient methods, as R.B. Fuller points out in Critical Path , but that's another story). In late 2001, Web development is a maturing industry, and the quality and breadth of available tools demonstrates this.

When a client buys a Web site, they probably don't care whether a human or a machine typed the majority of code. But they will care about cost.

Humans build tools. Humans who value their time use 'em.

Completely eschewing Web automation tools is the business equivalent of mowing a yard with scissors: it only benefits the hourly contrator.

Richard Gaskin can be reached at: Ambassador@FourthWorld.com