Ask HN: What was it like writing web apps / sites in the 90's and early 2000's?

I started with Perl CGI's and then used PHP some. It was't particularly beautiful stuff, and web programming was perhaps not looked on with as much favor, as 'real' programmers were doing things with C or C++.

The first commercial app I wrote was in 1997/early 1998. Previous ones I wrote were all in-house CGI scripts. I learned perl in 1994 because of the CGI examples at NCSA, the one in perl was the most readable.

It was a turn-key bioinformatics app. The back-end would pull in the latest data sets from a few ftp servers, index the records for fast lookup, prepare indices for several specialized bioinformatics search methods (FASTA, BLAST, etc.), etc.

The front-end took user queries, did a search using the back-end command-line tools, and marked up the search results to include links to the actual records. Each record had links for further search. Users were used to the command-line output, so this UI was a refinement of what they expected rather than develop a new report interface.

It was all CGI driven behind NCSA httpd, using perl4 because that's what would be on the likely user machines. (Eg, SGI IRIX shipped with perl4, and we had strong user feedback from another product that everyone was migrating to perl from awk, sed, etc.) This meant URLs like /program.cgi?db=xyz&id=123 instead of /db/xyz/123 because there was no routing other than the file system. During this time I tried learning Perl5, but couldn't understand its object system.

This also means I used cgi-lib.pl and not the later CGI.pm. You can still see my name in the lib-cgi credits at http://cgi-lib.berkeley.edu/ .

There was no widely used templating language. Of course, it's not hard to write one, which is what I did, but that's extra maintenance and development overhead.

There was no database, because those were expensive, and hard to use. (Postgre95 was available, but I had tried to use it in '95 and ran into problems getting it to work; or perhaps into difficulties in understanding the concept.) In any case, Perl4 had only limited access to SQL. I think it required a special patched version of Perl, which influenced how Perl5 supports extensions. Plus, I don't think it was until Greenspun's "Database Backed Web Sites: the thinking person's guide to web publishing" in 1997 that people in general started really looking into database-backed web sites. A year or two later was the big question of mSQL vs. MySQL. Nowadays a SQL database comes with Python.

This also meant no user accounts or configuration, which wasn't a design requirement.

But it also meant I had to figure out a way to look up 100s of thousands of records. I eventually created an index file of alphabetically sorted identifiers with start/end positions, and wrote Perl code to do a binary search on the data.

I looked into dbm and variants, but they weren't effective for what I wanted. Either the portability to different endian machines wasn't there, or the performance wasn't there. A couple of years later I would likely have used Sleepycat's dbm for the task. Now I use sqlite.

It had one piece of JavaScript. The back-end had different CGI scripts for different tasks. The front-end had a pull-down menu to select the task. The JS changed the target URL, rather than having either a redirect CGI script or merging the back-ends to have a central call point.

My development environment then, as now, was an emacs variant, primarily on a unix desktop, with a Windows box for testing on IE. QA used IE, because automation tools were available to help build a test suite.

There may have been free form text search. I don't fully recall now, but I have a memory of waiting for a license for a text engine from a university-based project (in Arizona?)