Dynamator Pure HTML for every page generation technology.

The Server Pages Maintenance Problem

Server pages are fundamentally unmaintainable because they combine code that should be developed and maintained by people in two different roles with two different skill sets.

Page Generation Technologies Don't Separate

Every page generation technology claims to separate program logic from HTML. But there's a simple test for separation, and nearly every page generation technology fails the test:

Does the technology require the same file to contain both server-side program code and client-side page content?

Regardless of how technology providers may define "separation", this is the definition that matters most. Any file that needs to be maintained by people in two different roles is not maintainable.

Simplifying the programming language doesn't solve the problem. Assuming that a simpler language enables non-programmers to program is like assuming that a simple painting program confers artistic skills.

Using an HTML-like syntax doesn't solve the problem. A programming language that looks like HTML is still a programming language.

Enhancing HTML with a small set of language extensions doesn't solve the problem. Although fewer is better, even one non-standard HTML construct means that the resulting file is not standard HTML.

The truth is, server pages technologies and template languages are designed to combine program logic and static content, not to separate them.

The Effects of Non-Separation

Combining server-side code with client-side content causes problems for HTML authors, software developers, and the organizations that employ them.

Effects on HTML authors

HTML authors have difficulty working with server pages because they are not HTML:

  • Server pages usually don't display correctly in browsers, so HTML authors have to deploy them to a server to see the effects of their changes.
  • Server pages are incompatible with most HTML authoring tools.
  • Server pages usually can't be validated by HTML validators.
  • Server pages have program logic that an HTML author has to wade around.
  • Server pages that use a language (like taglibs) similar to HTML can be very confusing, especially when the language provides elements that are just slightly different from standard HTML.

Claims that server pages are designed to be maintained by HTML authors are completely unfounded. Even when a programming language is made to look like HTML, HTML authors still need to learn the semantics of the language. This is a much larger task than most programmers realize.

There are HTML authors who can maintain server pages, just as there are programmers who can paint. But assuming that all HTML authors can maintain server pages is as invalid as assuming that all programmers can paint.

Effects on Software Developers

Few software developers consider server pages a problem, at first. Software developers enjoy challenges, so complexity doesn't bother them. Software developers relish new technologies, and server pages have seen more than their share. And server pages (or their older cousins, template languages) are certainly superior to programs that embed static content.

The problem for software developers is much more subtle. The problem is that software developers usually end up maintaining the HTML in server pages.

Now any software developer is capable of maintaining HTML. But few software developers aspire to be HTML authors. And the rate of change to the static content of most commercially produced web applications is so high that server page developers can spend most of their time tweaking HTML.

That wasn't the theory. The theory was that HTML authors would maintain the HTML. But in practice, once HTML has been converted to server pages, software developers typically own the server page.

Problems for Organizations

The problems caused by combining server-side logic with client-side content worsen when HTML and program logic are created by two different organizations or companies.

An organization responsible for HTML development does not want to support every possible page generation technology. The changes in JSP syntax alone over the past few years have been much greater than the changes in HTML. Nor would such an organization want to be held accountable for introducing programming errors, since it doesn't have the means to test for them.

An organization responsible for server pages development probably does not want to export program logic to a different organization responsible for HTML. Nor would such an organization want to be held accountable for programming errors that might have been introduced by the HTML-producing organization.

Both kinds of organizations are less efficient than they could be. The organization responsible for server pages development bears the larger burden, since it is employing software developers to fill essentially HTML authoring roles.

Effects on Product Quality

Because server page source code is less testable than pure HTML, quality is more difficult to achieve. Browser compatibility testing, standards compliance validation, and accessibility validation are all much easier with pure HTML.

Because this kind of testing is repetitive, time-consuming, and tedious, it tends to not be performed by programmers, who own server pages code.

A Software Engineering View

The combination of server-side code with client-side content violates a basic software engineering principle: modularity.

It's bad enough that server pages interpose two (or more) languages that execute at different times and places with different execution models.

The real problem is that a single file contains code that should be developed and maintained by people in two different roles with two different skill sets.

This is so fundamental a violation of modularity that it is not even addressed in the software engineering literature. David Parnas gets as close as anyone in his classic article, On the Criteria to be used in Decomposing Systems into Modules, when he states that one benefit of modularity is that "development time should be shortened because separate groups would work on each module with little need for communication."

Dynamator: A Solution to Separation

Dynamator was invented specifically to solve the Server Pages Maintenance Problem. With Dynamator, server-side code and client-side content are stored in separate files so they can be maintained independently.

With Dynamator, HTML authors can maintain pure, standard HTML even after a site goes live. Pure HTML is much easier to work with than server pages. It is easily validated, and can be tested in a browser without deploying to a server. With Dynamator, HTML authors are more productive.

With Dynamator, software developers don't even have to touch HTML. Instead, they maintain Dynamator files, which specify how to transform an HTML file into a server page. Dynamator provides a loosely coupled HTML interface, making server code much more resilient to change.

With Dynamator, teams and applications become more agile. HTML is decoupled from server code, and server code dependencies on HTML are minimized, with the result that HTML authors and software developers can work in parallel with minimal interactions.

Dynamator's approach to separation has other benefits beyond just solving the Server Pages Maintenance Problem. For example, server code can be modularized to enable a high degree of reuse. And architects are free to choose the right technology for the job: it's as easy to use Dynamator to generate Java servlets as it is to generate JSP.