Tuesday, July 23, 2024
Google search engine
HomeUncategorizedThe demise of the mildly dynamic website (2022)

The demise of the mildly dynamic website (2022)

Currently available for hire — experienced software engineer with a cryptography and security background. Reach out via email or
LinkedIn. (June 2024)

Early websites. In the beginning, website HTML was crafted by
hand. Your average personal — or corporate — website might consist of
hand-edited HTML subsequently uploaded, probably via FTP, to a web server which
knew only how to serve static files.

Since web pages in a set often include shared elements like headers and
footers, maintaining this was obviously troublesome. I have no doubt each and
every person charged with maintaining such a website found their own solutions.
Maybe they wrote simple Perl scripts to generate pages with common headers. If
they weren’t programmers, maybe they used some tool like Frontpage, Dreamweaver
or Hotdog that (possibly) offered some useful functionality in this regard.
Or maybe they just stuck it out and edited every page manually when they wanted
to change the header or footer. You might think that sounds nuts, but I’m fairly
sure it was quite common.

At some point “Server Side
” (SSI) came
along, offering extremely basic file inclusion functionality to allow common
headers and footers.
CGI was developed,
allowing web pages to be produced from dynamic scripts. While groundbreaking
for enabling dynamic web applications, I got the impression most ordinary
websites did not make use of it for serving pages. Many web servers required or
at least recommended CGI scripts to be placed in a special cgi-bin directory,
making URLs rather cumbersome. One major CGI application was the blogging
platform Movable Type, which featured a CGI and Perl-based administration
webapp which automatically regenerated static files from a database whenever
changes were made.

Rise of PHP. What was really significant however was the explosion in
popularity of PHP. A great deal has been written about PHP, much of it
negative, but there are some interesting attributes of PHP to note which are
relevant here:

  • PHP has the world’s simplest deployment model for web applications: copy
    some files to a directory. This deployment model is so simple, and so
    intuitively understandable, that almost anyone capable of using an FTP
    client (the existing market of people making their own homepages, in other
    words) could deploy a PHP application.

    Of course, PHP inherited this particular attribute from CGI, but without
    the cumbersome special cgi-bin directory which was often (though not
    always) required, and often with greater performance. The lack of shebang
    lines probably also reduced compatibility issues people faced trying to
    transfer CGI scripts from Windows to Unix environments or vice versa.

  • Because PHP originated as a templating language, the initial behaviour of a
    PHP file is simply to print its contents. This means, in turn, that you can
    just “dip in and out” of PHP as you need it. Compare this in turn with even
    the simplest Perl or Python CGI script. For the latter, you’re writing a
    program which outputs HTML; with PHP, you’re writing HTML with some
    occasionally interwoven code. If a particular page doesn’t need to do
    anything dynamic, it needn’t contain any code at all.

  • PHP scripts don’t consume any resources (persistent processes, etc.) when
    they’re not being used.

Even more interestingly, these two attributes combined to create something
very special in PHP1: support for the “hackish state”, an environment optimal
for casual tinkering with server-side scripting — without having to bring out a
whole framework and take the time to set it up. If you had an idea for some
kind of dynamic, server-side behaviour, you could probably have it prototyped
in PHP in 15 minutes. It might be crude, but it would be real. But the “hackish
state” of web development that PHP supported went beyond this in a way that,
having experienced it, I find hard to describe; perhaps the closest analogy is
environments designed to enable programmatic art, like the interesting recent
development of live music programming environments. You could call it a kind of
jamming. Though there are countless server-side web frameworks, PHP is
uniquely adapted to do server-side development in a jamming state of mind.

Of course, this doesn’t mean that what you produce in such a state is going to
be something robust, maintainable, or something you want to use in production.
But these requirements can be solved later, after the initial prototyping and a
period of uninhibited, spontaneous creativity; just as a great illustration
might be preceded by, and necessarily flow from, rough concept art and pencil

The mildly dynamic website. PHP enabled dynamic web applications for the masses. But an interesting and
particular effect of the rise of PHP was that it enabled and led to the rise of
what I’m going to call “mildly dynamic” websites.

Broadly, these are websites which are still web pages, not web
; they’re pages of essentially static information, personal
websites, blogs, and so on, but they are slightly dynamic. They might have a
style selector at the top of each page, causing a cookie to be set, and the
server to serve a different stylesheet on every subsequent page load. Perhaps
there is a random quote of the day at the bottom of each payload. Perhaps each
page has a comments section. Perhaps each page load shows a different, randomly
chosen header image. Anyone remember shoutboxes?

Of course, this is all minor functionality, with the possible exception of
comments sections. It’s not a big deal. Still, these random details gave a
certain character and individuality to websites of this era that is hard to
find today. They were, inimitably, the product of jamming. (Many use the term
“indieweb” today in reaction to their own perceptions of a change in the
character of the web from how they once remembered it; these random details are
one such part of my own memories.)

(As an aside, WordPress and similar PHP blogging platforms are probably the principal
exception to the static site trend here. These are a mixed bag; while on the
one hand, they’re still oriented towards publishing static content, they do
offer mildly dynamic functionality like comments systems. On the other hand,
they’re not really oriented towards adding your own mildly dynamic
functionality. Though of course you can add custom functionality with plugins,
they’re not really an environment that encourages jamming, or, say, embedding
dynamicity inside a blog post right then and there. Others have noted that the
rise of blogging platforms such as these led to a greater uniformity in
websites, because of the rigid publishing paradigm of chronologically ordered
blog posts they imposed on those who use them. You can go against the flow and
fight the system, of course, but this takes effort, and most won’t, so the
net result is that websites become oddly samey.)

The dynamicity gap. Eventually, the era of PHP websites passed and static
site generators
became the new fad. Everything old is new again! First you had
people who made static websites discovering dynamic websites, and then you had
people who made dynamic websites discovering static websites. A consequence of
this, however, has been the demise of the mildly dynamic website.

In short, here’s the problem: the mildly dynamic functionality I mention above
is too minor to be worth bringing in a web application framework, and spawning
and maintaining persistent processes just to serve a website.

Or, to put it another way:

[Graph of two lines. The X-axis is labeled “Dynamicity” and the Y-axis is labeled “Effort”. The first line, which is dashed and labeled “PHP”, starts at the origin at the bottom left and rises linearly in a straight line to the right. The second line, which is solid and labeled “Framework”, starts at the bottom left and moves to the right slightly, but then moves straight up in a vertical line only slightly into the X-axis, and plateaus as a flat horizontal line at the top of the Y-axis for the remainder of the X-axis.]

You can read the “Effort” axis as whatever you like here; size, complexity,
resource consumption, maintenance burden. What PHP offered is an increase in
this effort proportional to the amount of dynamicity to be added to a website.
This is something no framework can do (and I include PHP frameworks in this2).
If you have a static website and you want to make it dynamic and you don’t use
PHP, pretty much all options available to you imply a massive increase in complexity
that must be paid up front before you can do anything at all. You bring in a massive
framework for the dynamic equivalent of “Hello World”, and then on top of that
(if it’s a non-PHP framework, meaning persistent processes are probably
involved) the process for deploying your website radically changes and becomes
far more complex.

It’s not surprising at all, therefore, that people tend not to do this nowadays.

This in turn has led to much of the functionality which might have previously
been implemented on the server side on a “mildly dynamic” website being moved
to JavaScript. A blog is generated by a static site generator, but then how
does one support comments? Answer: Specialist third-party services like Disqus
come into existence. Now, you can have comments on your website just by adding



Please enter your comment!
Please enter your name here

- Advertisment -
Google search engine

Most Popular

Recent Comments