109

In the modern web an HTML <form> element is submitted and then interpreted by scripting. Either it is interpreted by a server side programming language (usually PHP) or it is interpreted by a client side script (almost always JavaScript).

Forms existed even in the early 90s. How were they interpreted back then?

According to this Wikipedia article there was an email based HTML form submission back then, but it was unreliable. Was this all there was? Why did HTML even have forms if they were so useless without scripting? Or was it a chicken and egg sort of situation?

James Jones
  • 3,850
  • 5
  • 25
  • 44
  • 25
    i used perl with cgi –  Oct 27 '16 at 04:20
  • 67
    There was always server-side scripting – OrangeDog Oct 27 '16 at 08:43
  • 22
    To complete the picture, some early forms used `action="mailto:staff@example.com"` which told a web browser to start an e-mail client and transfer the submitted fields as the crude contents of a new e-mail. Zero programming, just some staff to process the e-mails by hand. – kubanczyk Oct 27 '16 at 09:05
  • 2
    Before forms, even, there was [``](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/isindex), which was often plugged into a [WAIS](https://en.wikipedia.org/wiki/Wide_area_information_server) server. – zwol Oct 27 '16 at 15:46

4 Answers4

184

Before server side scripting (PHP, Ruby, node.js) there was server side programming.

One of the original interfaces between web servers and back-end processes was the Common Gateway Interface (CGI). It was introduced in the early 90s by the NCSA back-end team at the same time forms was introduced into HTML by Tim Berners-Lee (who was also at NCSA at the time). So forms was introduced at roughly the same time CGI was invented.

Initially a lot of people wrote CGI programs in C. I was one of those who had to do so as a homework assignment. Instead of a giant all-encompassing framework we wrote small C programs that read from stdin and print to stdout (we printed HTTP response, not just the HTML as per CGI spec). A website had lots of these small programs each doing one small thing and updated some database (sometimes that database was just a flat file).

Almost as soon as it was introduced people also started writing CGI scripts in Perl. So there was really no transition period between C programs and scripting languages. People simply stopped writing CGI scripts in C because it was faster to do so in scripting languages.

slebetman
  • 109,858
  • 19
  • 140
  • 171
  • 4
    Great answer from both you and @Dekel. These answers and the suggested links really fill in the gap. I can't help but wonder how many websites actually bothered implementing any of this stuff before techs like JS, Perl, PHP were available for web scripting. But that's a question for another day. – James Jones Oct 27 '16 at 04:03
  • 15
    @JamesJones, **lots and lots of us** did. It wasn't all that hard to get started, although the tools to scale up to large and high-performing web apps were lacking. I read [CGI Programming on the World Wide Web](http://www.oreilly.com/openbook/cgi/) in the late '90s and started writing all kinds of CGI code as a teenager. – Dan Lenski Oct 27 '16 at 06:24
  • 12
    Actually, a _basic_ CGI program is very easy to write. Just print out some static headers, and some HTML with your data interspersed. It's just that the technology (HTML mixed with headers mixed with code...) does not scale well to complex applications. Hence frameworks were invented... – sleske Oct 27 '16 at 07:25
  • 12
    If you still want to see CGI in action, try the Swiss railway timetable: https://sbb.ch - enter a departure and destination location - press the red button - then take a look at the URL in the browser, especially the query.exe part :-) – theDmi Oct 27 '16 at 08:15
  • 8
    In re "how widespread was it": well, far more websites were completely static back then. But the two commonly-seen bits of active content were "guestbooks" (obsoleted by blogs/social media/spam) and "hit counters". – pjc50 Oct 27 '16 at 10:25
  • 3
    Essentially the whole .com bubble was CGI, mostly on Perl because that was the tech that was readily available. Inside the modern Perl community today we blame that for the bad reputation people are giving us. There were lots of people doing it, with no quality control and no real experts in the industry. – simbabque Oct 27 '16 at 10:33
  • Also, writing a server-side application in Perl is actually not much harder than in PHP, it's just a different syntax and a more general-purpose language. – The Vee Oct 27 '16 at 19:14
  • 1
    @JamesJones, Perl pre-dates CGI by about six years. – Mark Oct 27 '16 at 20:47
  • @Mark. That's why I specifically wrote 'available' rather than 'released'. Without CGI, Perl was not able to be used for web scripting - that's the impression I get at least, please do correct me if I'm wrong. – James Jones Oct 27 '16 at 22:35
  • 4
    In 1993 I worked for a guy (Andy Singleton) who wrote a minimal CGI program that did nothing but write its POST to a SQL-server table and fire off a stored procedure. My job was to generate and interpret the forms using Transact-SQL as the scripting language. The CREATE PROCEDURE statements were beyond rational description. – A. I. Breveleri Oct 28 '16 at 04:42
70

Server side was actually always in the picture.

The Apache HTTP Server was available since 1995, and in 1996 it also had Perl support (which was used as a server-side programming language).

JavaScript was created in 1996 and Netscape was the first browser supported the client-side language (other browsers vendors implementations were based on the work that was done in Netscape).

In 1993 the Mosaic browser is released with support for images, nested lists and fill-out forms.

Basically - every HTTP server that could handle request and pass it to some application (no matter in what language that application is written in) is a server-side application. It can be written in scripting language (Perl/Python/PHP/Ruby), high-level language (Java/C#) and if you really want - even assembly. All you need to do is make sure you "follow the protocol".

Dekel
  • 60,707
  • 10
  • 101
  • 129
  • 1
    Good history. Upvoted. However, forms were implemented before 1995. I can't work out just when, but in https://en.wikipedia.org/wiki/HTML there is `Dave Raggett's competing Internet-Draft, "HTML+ (Hypertext Markup Format)", from late 1993, suggested standardizing already-implemented features like tables and fill-out forms.` Is your last paragraph describing practices before 1995? – James Jones Oct 27 '16 at 03:36
  • 3
    @JamesJones: Check wikipedia entry on Common Gateway Interface – slebetman Oct 27 '16 at 03:41
  • 2
    @JamesJones, added some info regarding the Mosaic Browser and fill-out forms. You also have a great answer by slebetman regarding CGI. – Dekel Oct 27 '16 at 03:42
  • 1
    @JamesJones Standards aren't clear-cut, and it applies in full to most things around the web (though not internet as a whole). The HTML standard was (and really, still is) horrible, and everyone created their own extensions. Mosaic, Netscape and Internet Explorer were the most notorious - most of their extensions were added to later HTML standards, with Netscape and IE coöperating quite a bit on that. HTML didn't even have embedded images (`img`) back then - the author considered it unfitting to the idea of hyper-text; only the success of Mosaic/Netscape forced the change in the standard. – Luaan Oct 27 '16 at 10:54
  • 1
    RFC 1945 is as close as one gets to an original spec for form handling; it's the HTTP/1.0 spec that included form handling and descriptions of mechanisms which became (or already had become, given the speed of things in the early 90s) the Common Gateway Interface. An actual RFC for CGI wasn't approved until 2004(!), though it had been in extant as a draft by David Robinson at Cambridge since late 1995/96. (https://tools.ietf.org/html/draft-robinson-www-interface-00) (http://poincare.matf.bg.ac.rs/manuals/dwprog/cgi-spec.html) ... even then, Perl, PHP, and ColdFusion had already arrived. – Kevin_Kinsey Oct 27 '16 at 15:12
  • 3
    This answer isn't necessarily wrong, but I'm not quite sure how things introduced at least 2-3 years after forms were available in the browser is evidence that there has always been server-side support for forms. – 8bittree Oct 27 '16 at 15:59
1

JavaScript wasn't so advance (hell Ajax wasn't even out yet). So it was pure server-side. Mostly CGI (being Perl) and PHP.

There was also Coldfusion but wasn't a popular favorite.

Eventually, at the end of 1999 and early 2000s ASP.NET (aspx) and JavaServer Pages (jsp) came out, although a lot of commercial sites used aspx and jsp for obvious reasons.

Note, Java applets also existed (mostly for rendering though) but had to be separately downloaded and supported by the browser.

tfont
  • 10,891
  • 7
  • 56
  • 52
  • 3
    Actually, I did program ASPs by the beginning of 1998. Before that, there was another MS standard called `htx` templates. – Little Santi Nov 01 '16 at 20:55
  • Before asp.net, there were plain old active server pages - ASP. If you’re in a hurry and just need to throw something together, they’re pretty rad. Well, I guess it’s about the same as PHP… I just have a soft spot for ASP, because I fell in love with them during my internship. You write VBScript for server-side, intermingle HTML and JavaScript for the client-side, and it’s all in the same .asp file. No project necessary. No compile necessary. If a web server understands asp, you throw it out there and it’s ready to be used. ASP - ‘96. ASP.Net - ‘02 – PopeDarren Feb 02 '22 at 04:34
1

Additionally, I stumbled on an interesting piece of history on Wikipedia. HTML forms could also be sent by e-mail, using a mailto: address in the target attribute. Didn't seem to be popular, but still cool!

Quoting the Wikipedia article:

User-agent support for email based HTML form submission, using a 'mailto' URL as the form action, was proposed in RFC 1867 section 5.6, during the HTML 3.2 era. Various web browsers implemented it by invoking a separate email program or using their own rudimentary SMTP capabilities. Although sometimes unreliable, it was briefly popular as a simple way to transmit form data without involving a web server or CGI scripts.

And RFC 1867 (November 1995):

5.6 Allow form ACTION to be "mailto:"

Independent of this proposal, it would be very useful for HTML
interpreting user agents to allow a ACTION in a form to be a
"mailto:" URL. This seems like a good idea, with or without this
proposal. Similarly, the ACTION for a HTML form which is received via mail should probably default to the "reply-to:" of the message.
These two proposals would allow HTML forms to be served via HTTP
servers but sent back via mail, or, alternatively, allow HTML forms
to be sent by mail, filled out by HTML-aware mail recipients, and the results mailed back.

Baptiste Candellier
  • 833
  • 8
  • 17