In the olden days, before Covid, there were dinosaurs. Then they died out, and the ancient people that came after them created the Internet, and on it they put something they called websites.

What was a website?

Well first you needed a server. Basically the idea was that you took a computer, like the one in your basement, and you connected it to the outlet in the wall 24/7 and never shut it off. And you took a wire and connected the computer to the Internet. And you set things up with your internet provider (like Verizon or AT&T in the US, or HOT or YES or Bezeq in Israel) so that your computer would have a fixed, unchanging address that consisted of numbers and dots, like 234.332.43.234 (an IP address). Voila, you had a server.

This server is like a building you built on a street somewhere in a busy city. It has an address and maybe stuff are happening inside, but there are no doors and windows so nobody knows about it and no one can interact with it. Which is stupid. So you cut a hole in the building and install a door. Oh crap, now people are coming to the door but there’s no one there at the reception to help them, so they’re lost, or maybe just wandering around the building making trouble and breaking shit. Oops.

You install a reception desk and a security guard. The security guard is fairly lax, because your business is open to the public. Anyone that seems to be behaving reasonable well can come to the door and ask for information. Your business is a hotel, so if they ask about rooms they’ll get a helpful answer. If they ask about tax law, the reception will politely tell them that they’re in the wrong place and there’s nothing here for them. If they try to force their way in to the employees-only area, the security guard will kick them out.

Back to your computer. In computing we don’t call them doors, we call them ports, but they’re similar. You can open a door (port) on your computer (server) but then all kinds of troublemakers will wander in. You need to put some web server software that works like a reception desk. It runs 24/7, just like your computer, and responds to requests from the public. (Microsoft has a solution for this, because they have a solution for everything…it’s called IIS. There are many alternatives out there, of course.)

How does the web server software know how to respond to requests? Well, you (the legendary webmaster) dumped a bunch of files in a specific place on your computer (probably a folder called www), and when a request comes in for hotel-info.txt the web server software looks for a file with that name inside the www folder and gives it to the requestor. If the file can’t be found, it tells the requestor “sorry, I can’t find that” (and by convention, uses the error code 404 to signify this). Depending on how you configured the software, it might have a security guard function that rejects requests if certain conditions aren’t met but that’s a separate topic for another time.

The more important question is: who is this mysterious requestor? And how do they find your website? The requestor is usually someone working on behalf of a real human, so the web server software calls it a user agent. The human probably calls it a “browser” or “Netscape” or “the blue E button thingy”. The human told the browser / agent / internet thingy to go to http://coolhotel.com/hotel-info.txt, but how did that request end up at your computer?

Wow, I’m glad you asked. We’re going to skip about a million steps, partially because I’m getting tired of typing, and partially because there’s a lot of layers to this question that I don’t actually know about myself, but I’ll tell you the short answer – the browser reaches out (over the internet) to another server somewhere called a DNS server (DNS stands for Domain Name System). The browser says “where can I find “coolhotel.com”? And the friendly reception guy/gal at the DNS server says “hang one second lemme check…that’ll be 234.332.43.234”, which is the IP address you got from your internet service provider way up there a few paragraphs ago subsequently registered with the DNS people. (All that takes like no time at all, because the reception desk at the DNS server is super-fast.) And then the browser says “ok cool, I’ll head right over there” and it goes to your server and asks for hotel-info.txt, and then it takes that file and displays it to the user right there beneath that Ask.com plugin and whatever other junk the human accidentally installed in the blue-e-internet-thingy.

But wait! There’s more. I hope you’re still with me...

What if you don’t want the users of your website to just see plain text? What if there was a way that you could tell the user-agent (browser) to format the document in some fancy way? That would be cool. So the wise-elders of the Internet go together to discuss this (it took a while, because some of them had to ride on camels, and some on horses, and some had no means of communication because their only transport had been a dinosaur and now that was gone ☹). They agreed on a kind of language that could be used to “markup” a document that browsers would know how to interpret. And they included a cool concept – “hyperlinks”, the idea that one document could point to another document and the reader would be able to click on those links and thus tell the browser to go ahead and ask for this other page. They called this language “Hypertext Markup Language” or “HTML”.

But there was a problem with HTML, namely that the poor programmer has to repeat herself soooo much. For example: HTML includes a concept of “headers” – the programmer can decide that a certain line is a header and write it like this: <h2>Some Header Text</h2> and the browser knows to format it as a header. But what if the programmer wants to tell the browser that all second-level headers should be colored neon yellow (it’s the 90s, after all)? She has to write <h2 color=”yellow”> every place she previously wrote <h2>. And then if one day she decides to switch it to a more sedated khaki color, she needs to update many places in the document. Not fun.

So CSS (Cascading StyleSheets) was born and browsers were taught to interpret CSS and apply styles to the whole page at once. It’s cool, but it’s not the topic of our story, so we’ll skip that for now and maybe come back to it another time. Anyhow, no one really knows how it works except a few geniuses. The rest of us just try all the different attributes and all the different values until the design looks more or less like the Figma and call it a day.

Let‘s recap. We have a server, we have files that form a website that is accessible to the public while being hosted on this server. The website consists of files that include HTML and CSS. Life is good. But there are two major innovations that bring us to the modern world. I’m making an effort to write this whole thing without looking anything up on the internet (for my own edification) and I admit that I honestly don’t know which of these innovations came first. Not that it matters anyway, because this whole story is filled with historical inaccuracies and literary license. For all I know both of these ideas were conceived from day one, I’m too young to actually remember. So let’s just continue with…dynamic websites, aka web-apps.

Imagine a brilliant idea: What if the files on the server don't actually exist? The user could type the name of some file path into their browser, and the browser could ask the server for that file, and the server could lie and pretend it exists, but actually just generate it programmatically on the fly. Probably not generate it from scratch, but take some template and inject some dynamic values into it. The use cases for this are endless! Maybe the server could look up some values in a database and create the page based on that, maybe the server could generate a different page based on which user is asking or what country the user is in. Genius, huh? Indeed. Somehow all anyone thought to do was keep track of how many people had visited a page and each time a person came to the page they’d see a footer that said “You are the n-th person to visit this page.” Ridiculous, I know.

To accomplish this visit-count magic, we’ll need to enhance the software that is sitting at the reception of our server. We might write another program (maybe in PHP, or VB.NET) and run it on our server, and the reception-software (eg Apache or IIS) would call that program when a request came in and have that program look at the particular request and generate a blob of HTML and CSS that the reception should hand back to the requestor. If you were a Microsoft developer during this time, you probably used a framework called Active Server Pages (ASP) to help you write this program.

The other big innovation was when someone had the idea that it would be cool if we could make butterflies fly across the page, or maybe there would be some fancy animation or whatever other useless crap, so what if there was a programming language that browsers would know how to run. The server could include some code embedded in the HTML page and the browser would run it. The code could tell the browser to modify the HTML page on the fly, add items, change the style, or other wild things. Pretty cool? They wrote this language very quickly (legend has it that it was done in a week, evidently by someone much smarter than me) and for marketing purposes called it JavaScript, so it would sound similar to the popular language Java, even though it had nothing in common with Java except four letters in the name.

In the next installment, we’ll look at the next major innovation, which was the combination of these two innovations into something called AJAX, and we’ll wonder why it isn’t called AJAJ, and then the brilliant but perhaps terrible idea of building a SPA, which is a lot less relaxing then it sounds. From there we’ll notice that we now have a “frontend” which is definitely distinct from the “backend” and we’ll finally begin to understand what a Web API project is all about, and to make life more interesting we’ll think about microservices and microfrontends and the cloud and clusters and datacenters and why it is that your bank website goes down every now and then for “scheduled upgrades” but somehow gmail never goes down, aka how is it that we can have continuous uptime if even the server in our basement needs to be upgraded every now and then? Stay tuned 😊