Frontend and Backend Web Development

Nick Wurzer

This topic may be old news for most readers, but I feel that a general overview of frontend and backend web development is missed by the computer science program at UVic. There are many resources on Google about the topic, however I found that after reading a few of them carefully I still couldn’t fully understand what these terms meant. I aim to save somebody like me the googling when they start working on their first web application.

Many resources will give examples of languages and frameworks used for either end and give a high level description of the functional differences. The description of functional differences usually says something like: Frontend development is used for creating the appearance of the website, while backend devopment handles the logic. This is a huge oversimplifaction which left me with a lot of silly questions like:

  • How can javascript be both a frontend and backend language?
  • If frontend code has nothing to do with the server, then how does the client actually get the frontend code in the first place?
  • So are frontend developers just graphic designers?

I will do my best to describe the two sides of web development in more detail and use examples to help create a more clear understanding of this topic.

Introduction

I’d like to start with describing which information gets transferred for either end because to me this a core difference between the two. Both client side and server side require information to be sent from the server to the client, however most if not all frontend code and data gets sent to the client, whereas only some of the server side data and limited if any code is sent the client. To help visualize this transfer of data I’d like to consider only one page of a website

Frontend

Let’s consider the About page for the ZooDB website which is still under development. When you click a link to the page, the client sends an HTML GET request to the server. The client requests to get all of the client code and data as well as the initial server data for that page. The server responds and the page is rendered by the browser.

The frontend is like an empty container for the data that the server side will provide. The empty container may provide a predefined structure of the document through HTML, text to display, and also provides CSS styling which moves HTML elements around, colours them or gives them other display properties. In this case the page gets it’s HTML mainly from three Django templates. Django uses Python to parse HTML code and piece together different templates, allowing HTML to be compartmentalized and reduce repetition of code. The three main templates are as follows: The base template which includes everything for the navigation bar at the top of the page and displays the ZooDB logo (1), a template which defines the structure of a simple page with content that is editable by administrators(2), and a template which defines the structure of a piece of editable content(3). The first two templates contain mostly client code/data with little server data while the third contains both. In the third template, the edited content itself is not predefined as it is entered by an adminstrator, so it is serverside data held in the server’s database. The image below shows the about page with the different templates (each template is actually a subtemplate of another, so the base template for example contains all other templates on the page).

ZooDB About Page

While the templates define some of the content and give structure to the different elements, CSS defines how to display this structure. It controls the colour of the text, navigation bar, and layout of the page along with much more. It is also sent to the client after the GET request.

So far we have talked only about static content. What about the moving parts of the page? When we click the pencil icon to edit the page we see the a modal window with markdown text which an administrator has entered, along with a few buttons(shown below). If backend development handles logic, then was the opening of this modal backend code? In this case no. The HTML for this modal was already sent with first response to the GET request. So this modal would still open when the pencil icon is clicked if your internet connection was interrupted. It requires no new information from the server. This is where Javascript comes in. On this page there is Javascript which links the click event on the pencil icon to a CSS class that shows the modal. We can see another example of this exact behaviour when we click the button to insert media (Second image below).

Edit Modal

Insert File Modal

Backend

So where does the backend come in then? Well, the administrators enter markdown into the editable content window, but browsers cannot render markdown. So the server is needed to convert the markdown content to HTML. When new content is submitted, a POST request is sent to the server. The server converts the markdown to HTML, then responds with the new HTML and a redirect to the new about page. The server will handle any reads or writes to the database, respond to requests with appropriate resources and do any logic which the browser cannot reliably handle. This could be Javascript, Python, PHP or some other serverside language.

For your reference the full list of requests and corresponding response codes is shown below for opening multiple modals, editing some content and submitting the edit. You’ll notice there are no requests for opening the modals, just initially getting the page, submitting the new content and then getting the page again after the redirect.

[30/Jun/2023 20:24:59] "GET /zooapp/about/ HTTP/1.1" 200 35631
[30/Jun/2023 20:25:08] "POST /zooapp/editable_content/5/ HTTP/1.1" 302 0
[30/Jun/2023 20:25:08] "GET /zooapp/about/ HTTP/1.1" 200 35614