Define “What”

What is a “web application” anyways? Note the use of question marks indicating an ironic sense of sarcasm, since I’m about to answer that very question. Of course, I won’t answer it very well, since a web application is far too broad a term to say anything useful about.

Suffice to say, in the connected world we live in, a web application is something that takes requests, and gives responses. This is probably happening on the internet, but it certainly doesn’t have to. The world wide web, internal company networks, and even the darknet are all possible locations to consider.

For Our Purposes

For our purposes, we’ll assume the reader is specifically reading about modern internet applications, which:

  • users request through a web browser or mobile app
  • send nicely presented web pages or data to the user
  • will often take user input data and record it for future use
  • will often attempt to be as seamless a UX for the user as possible.

Semantics

  • User – a person, or a program, that is attempting to use a web application
  • Browser – a web browser, or similar program, that presents the web application to the User.
  • Client – the part of the web application that runs within the Browser.
  • Server – a target destination that the User is connecting to. While a machine is a common and useful abstraction, it can oftentimes be many machines, or a virtual machine.
  • Persistence Layer – a place where the Server stores information.

Quick History Lesson

We could devote pages to the growth and evolution of the internet – endless man hours, a lot of fascinating movements, and a whole lot of standards have contributed to its’ evolution. While the whole picture can be exciting (if you’re into it), we’ll focus on what aspects are important to keep in mind when building a modern web application.

Request-Response Architecture

The basis of the web is a request response paradigm. A User makes a request, and gets some response back. In the old days, there was only a Browser-Server communication, and the only requests were made directly by a User clicking a link, or typing a URL, and the only responses were sent by the Server.

Then Javascript and XHR were introduced, and part of the application all of a sudden could live on the Browser, which we’ll call the Client. The Client could make requests to the Server without User interaction, such as opening tons of popups! But also lots of useful things.

In the modern era, a balance is often the best bet. While many web applications rely on a Client, there are many users that disable Javascript and other features, for which a conventional Browser-Server paradigm should be fallen back to. This is known as Backwards Compatibility.

Standards Evolution

The internet and web have slowly grown through a series of standards.

Protocol standards describe how the actual communications work – HTTP, FTP, WebSockets.

Browser standards describe what HTML, Javascript, and CSS directives there are and how they work.

Many different Requests For Comments (RFCs) describe in intricate detail components all across the internets’ many layers, and even how to make coffee.

Home | Go back | Next up