How running websites has changed in the last two decades

Written by Jason Marlin / Courtesy of ArsTechnica

I was a true nerd growing up in the 1980s—not in the hipster way but in the 10-pound-issue-of-Computer-Shopper–under-my-arm way (these things were seriously huge). I was thoroughly addicted to BBSes (Bulletin Board Systems) by the time I was 10. Maybe it’s no surprise I ended up as a technical director for a science and tech site.

In fact, I’d actually draw a direct line between the job of managing your own BBS (aka SysOping) to managing a modern Web infrastructure. And with everyone around Ars looking back given the site’s 20th anniversary, let’s make that line a bit clearer. It won’t be an exhaustive history of websites, but here’s how my own experiences with managing websites have evolved in the past two decades—plus how the tools and thinking have changed over time, too.

LOAD “*”, 8, 1

My first SysOp experience was powered by a Commodore 128 (in 64 mode, of course) running Greg Pfountz’s Color 64 software. I sent Greg my check—well, my mom’s check—and received back a single 5.25-inch floppy diskette along with a hand-bound dotmatrix-printed manual. It was on.

Color 64 was an amazing feat of ANSI-colored ASCII, not like most of the BBS software available at the time, which was bland and colorless text. With Color 64, it felt like you were crafting a user experience. I can’t recall the name of my BBS anymore, but I can assure you the theme was dragon and/or kung-fu related. I’m vaguely ashamed to admit that my handle was DragonMaster, but I was doing my part to solidify nerd stereotypes.

Unfortunately, my network infrastructure consisted of a single phone line, meaning I had to disable any ringers (read: unplug the rotary-dial hanging wall phone) and operate between the hours of 11pm and 5am. This also meant the BBS wasn’t terribly interactive. With only one line, and a single Commodore 1571 disk drive, users could neither chat nor download more than a single game at a time.

The Commodore 1670, still makes the heart race.

In my dreams, I’d soon be running a real BBS, like the famous Fear & Loathing in Las Vegas to which I was a very frequent dialer. I’d have 10 lines so users could chat in real-time, all connected to 1200—nay!—2400 baud modems. And there’d be an endless supply of games stored on the mythical 10 MB Lt. Kernal hard drive.

Alas, this was all far out of my reach, but I had definitely been bitten by some kind of new bug that included the unusual desire to build digital places where users could gather.

1990s

I continued to tinker with BBS software, including a very interesting precursor to HTML with Excalibur BBS. Take a gander at this Google image search to get a feel for just how ahead of the curve this software was.

$: cd ~/public_html

I first became familiar with HTML in college in the mid-’90s when I would compose assignments and load them up to my public home directory where professors could view them with Netscape or Mosaic at their leisure. The bonus +10 points for “use of technology” was a great motivator.

Apache + Perl + XML + Shared Hosting

One of the first actual “applications” I wrote as a Web developer was a newsroom for a telecommunications company. The underlying technology was a common stack at the time: Apache as the HTTP server, Perl for the server-side language, and a flat-file database. I didn’t have any familiarity with real databases at this point, but I knew how to write and parse XML files. All of this was hosted on a surprisingly capable shared platform where any serving rules I needed could be included in an .htaccess file. I soon learned that .htaccess gave my inexperienced hands far too much power!

While shared hosting did the trick, developers at the time were at the mercy of admins when it came to software versions and extensions. You also had to worry about what your neighbors were doing within those same shared resources, including various unsavory ventures. A hack into a single machine could easily compromise hundreds of sites.

IIS, FrontPage Extensions, and Access

Eventually, the agency I worked at had enough clients to necessitate its very own server. To my chagrin, this was a Windows machine running IIS (Internet Information Services). This was completely foreign territory for me, but after firing up the Frontpage IDE (integrated development environment), I was blown away to see how simple Microsoft had made the ordinarily complex task of saving validated input to a database. (Seriously, amazing.) This sent me on a real tangent of pursuing the perfect graphical IDE, including a brief and regrettable dalliance with Macromedia Dreamweaver. I soon learned that tools that generate code for you tend to produce a significant amount of spaghetti that could then only be untangled by the same tool.

Managing IIS within Windows NT 3.51 also seemed dangerously easy for someone coming from a Unix background. At the same time, it felt limiting—where were the .conf files that made granular customizations (and phenomenal screwups) possible?

This became my platform for a while, as we built a number of custom CMSes (content management systems) for clients, never with any forward-looking consideration for managing a common codebase, long-term upkeep, or even version control. The horror.

Early 2000s, starting with ColdFusion

I realize at this point, I’ll be alienating myself, but I really liked Allaire’s ColdFusion environment and used it for at least four years to build some fairly large-scale applications and intranets. The underlying language was CFML (ColdFusion markup language). It was like HTML, but it made trivial work out of querying databases and integrating with external technologies like Java Servlets or CORBA components. ColdFusion had plenty of haters, but I’ve always been fairly agnostic with technology, choosing whatever would get the job done fastest.

Enter Web Frameworks

ColdFusion’s very low barrier to productivity earned it infamy as a simpleton’s language that brought poorly trained programmers into the arena, much like PHP. While I can’t argue with that, it’s ironic that my first real exposure to a proper Web framework came in the form of Fusebox. Fusebox began as a way to organize your application with simple file naming and directory layout conventions. This sounds obvious, but, like most Web developers at the time, I tended toward a constantly evolving personal approach to application layout and struggled with separating concerns such as database queries and display components. I had tinkered with Struts, but since Java wasn’t an option at my day job, I never fully grokked it. Fusebox however, opened my eyes to the language-transcending paradigm of MVC (model view controller) frameworks. This was years before the mind-blowing Ruby on Rails 15 minute blog demonstration by David Heinemeier Hansson.

These days, I would never consider starting a large application without choosing a framework, and there are many exciting options to choose from. Laravel is a personal favorite for PHP.