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.
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.
Combining server-side code with client-side content causes
problems for HTML authors, software developers, and the
organizations that employ them.
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.
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.
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.
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.
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 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.
