

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


======
davidw
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++.

~~~
nuwin_tim
Did you mostly use vi to edit files? What were some of your goto IDEs?

~~~
opless
For me it was mostly vi editing perl cgi on Solaris or Linux boxes. Someone
might have been using (x)emacs, but he was weird ;-)

Oh, and we didn't use source control either.

~~~
rikkus
vi with perl cgi here, too.

I played a little with Java Applets. I still remember waiting for them to
start up.

~~~
opless
Oh gosh, I forgot those!

I even wrote a airline-booking-system terminal program in Java, all before
swing reared its ugly head!

------
dalke
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/](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?)

