Back to the Future
Reclaiming Human-Scale Publishing and Communication
In 1998 I went to Paul Lutus’s website, spent two days learning HTML, and started building websites on the third day. By 2000, I had built roughly one hundred websites, including a 1200-page site that I completed in about 200 hours using his simple text editing program, Arachnophilia. Every page was hand coded.
Paul Lutus, the creator of Arachnophilia and an early advocate of independent web publishing, profoundly influenced the way I thought about computers and publishing on the web. His site emphasized learning, transparency, and direct understanding rather than abstraction and dependency.
Lutus was already well known in computing circles as the creator of Apple Writer, one of the earliest and most successful word processors for the Apple II. Before that, he had worked on projects related to NASA and Apple during the formative years of personal computing.
The tools were understandable, tailored to the needs of the user, and the future appeared wide open rather than constrained and enclosed.
What strikes me now is not the celebrity or prestige of people who later became famous in the computer world, but rather the accessibility. In those years, the software world was still comparatively small and permeable. Individuals could communicate directly with the people creating the tools they used.
I had extended conversations, either by phone or in person, with the creators of Paint Shop Pro, the creator of Photoshop, and the founders of Google. There was a sense that individuals could still understand and shape the systems they used. Individuals suddenly gained publishing power, and direct informal communication with creators was possible. The tools were understandable, tailored to the needs of the user, and the future appeared wide open rather than constrained and enclosed. It was a heady time, and the possibilities were genuinely awe inspiring.
Human-Scale Publishing
Before deciding to build the system ourselves, we spoke with dozens of web developers and agencies. Again and again, we encountered the same problem: they could not seem to understand what we were actually trying to build.
What we wanted was relatively simple to describe. We wanted a small, understandable publishing system under direct organizational control. We wanted a content management system that generated static HTML pages rather than dynamic pages assembled on demand. We wanted simple publishing workflows, durable documents, direct access to our files, restrained use of analytics, and a website that functioned more like a publication than a marketing platform.
What we repeatedly received instead were proposals centered around “engagement,” “user behavior,” “SEO optimization,” “conversion,” analytics-driven redesign, and ongoing platform management. Several developers proposed extensive staff training systems, marketing-oriented copywriting, or dynamic CMS platforms even after we had explicitly stated that we were trying to avoid those approaches.
The assumptions of the modern web industry have become so standardized that it was difficult for many developers to even recognize an alternative model when it was described to them.
In one case, after we had carefully explained that we wanted a CMS capable of generating static pages, the response proposed “CMS features for your team to be able to add dynamic content,” precisely the opposite of what had been requested. Another proposal emphasized analytics intended to track “website performance and user behavior for eventual improvements,” despite our repeated explanation that we were deliberately trying to avoid surveillance-oriented optimization models.
The problem was not incompetence. Most of the people we spoke with were probably perfectly capable of building modern commercial websites. The problem was that the assumptions of the modern web industry have become so standardized that it was difficult for many developers to even recognize an alternative model when it was described to them.
Eventually, it became clear that if we wanted a human-scale publishing system aligned with our own values, we would probably have to build it ourselves.
I would estimate that the SBTH website project has already taken somewhere in the range of 1200 hours, and I would not be surprised if the real number is higher if all of the hidden work were counted.
This is not just “building a website” in the normal sense. It involved information architecture, editorial planning, custom ProcessWire development, PHP template work, CSS design and responsive behavior, static export engineering, deployment scripting, server administration, forum integration, newsletter infrastructure, image workflow integration, mobile Safari debugging, long-form writing, content migration, ecological curation, publication design, workflow design, philosophical and organizational writing, testing across devices, and recovering from false paths and dead ends.
And importantly: almost none of this was done using a turnkey “website builder” approach. I built a custom publishing system and publishing philosophy at the same time.
What I have been building is not just pages but rather a publishing system and an editorial framework. The project required creating a hosting environment and deployment workflow. The work included building the static site architecture and a long-term archival structure, and developing a philosophical alternative to mainstream web practices.
Much of the difficulty in modern web development is not that the underlying ideas are inherently harder. Rather, it is that the stack became layered, fragmented, and opaque.
In 2000, the conceptual stack was comparatively small: HTML, maybe some simple CSS, FTP, working with folders/files, images, and hyperlinks. A simple text editor like Arachnophilia was more than adequate for the work. Pages were mostly documents and the different browsers behaved more similarly. Mobile did not yet exist as a major constraint and design consideration. There were few layers of abstraction, and users were expected to understand basic web concepts. A person working alone could easily understand almost the entire system.
A disciplined, highly organized person could absolutely build a 1200-page site quickly because the work scaled linearly and the technology was transparent. The complexity we have to deal with today had not yet exploded.
Much of the difficulty in modern web development is not that the underlying ideas are inherently harder. Rather, it is that the stack became layered, fragmented, and opaque. In many ways, we are trying to recover some of the older web’s properties, including understandable systems and durable documents.
A concrete example of opacity in the modern stack that I had to deal with was an iPhone/Safari navigation problem that arose at a late stage in the project. That problem was not because mobile support is unreasonable, but because the interaction model itself became hidden and assumption-heavy. Troubleshooting and repairing one bug consumed four days and finally led to the realization that hover navigation itself was no longer a universal assumption.
Direct control of the site, self-hosting, simple publishing protocols, and human-scale architecture were all common features of the early web that have largely been lost and that we are attempting to recover. Independence from platform ecosystems was another goal.
We are not literally going back to 2000 technology, but trying to preserve those values while selectively adopting modern capabilities where they are genuinely useful.