This article explains what web development is, by exploring how it started and how it evolved. This is not an exact chronicle of the web’s evolution, but focuses more on what the needs for this evolution were, so we can understand the technology.

It all started with information. Humans have always needed to find ways to share information with others. As you are aware, before the internet, information was shared via letters, newspapers, radio and television. Each had its own disadvantages, which allowed the internet’s information highway to come to the forefront.

1. What is the Web?

–ADVERTISEMENT–
What if you can publish information in a place where whoever is interested can go and read that information? That’s exactly what the web does. You keep the information on a web server, and people can read that information using clients (browsers). This architecture is called ‘server-client architecture.

Why HTTP?

Initially, this information was all stored as text — that’s why the name hyper-text transfer protocol has stuck even though now text, media and files are all exchanged via this protocol.

2. How Is Information Kept, Retrieved and Saved?
The most basic and long-lived way of storing information on the web is in HTML files. To better understand, let’s take a simple example of company publishing its price information so its vendors can download and view the list, which consists of products with a price and effective date. This was kept as a HTML file on the server, which can be viewed using a web browser. The browser requests the file from the sever, and the server serves it up and closes the connection.

HTML is a standard markup language used to create web pages. In other words, it’s a simple text file with tags that help the browser figure out how to display the information.

<!DOCTYPE html>
<html>
<body>
<h2>Price List</h2>
<hr>
<table>
  <tr>
    <td>Product Name</td>
    <td>Sku</td>
    <td>Price</td>
  </tr>
  <tr>
    <td>KTree Web Service</td>
    <td>1234566</td>
    <td>60.USD Per Hr</td>
  </tr>
  <tr>
    <td>KTree Web Service</td>
    <td>1234566</td>
    <td>60.USD Per Hr</td>
  </tr>
</table>
<hr>
</body>
</html>

CSS

Cascading Style Sheets (CSS) is a style sheet language used for describing the presentation of a document written in a markup language. Basic formatting and styling can be done via HTML, but it’s better to use CSS for this.
A web application contains many pages, either dynamic or static. If we use HTML tags for styling the information we have to repeat this information in every page. Suppose we want to change the background color — we have to edit the HTML for every page that is part of the site.
Instead, we can use CSS to store our style definitions in one location, and refer each HTML page to that location. By changing the CSS file, we can change the background color on every page that looks to the stylesheet for style defintions.
CSS does more than just setting the background color, of course: it allows us to set colors for all sorts of elements, fonts, page layouts, and much more.
We have styled our previous example using CSS. Let’s say we are using tables on different pages, but using the same CSS styles. We can move all this style information out to its own file.

<!DOCTYPE html>
<html>
<head>
<!–– for simplicity we have kept the CSS in inline in the HTML –  you can keep the css in any file with a .css extension and include it using <link rel="stylesheet" href="styles.css"> –>
<style>
table {
    font-family: arial, sans-serif;
    border-collapse: collapse;
    width: 100%;
}
td, th {
    border: 1px solid #dddddd;
    text-align: left;
    padding: 8px;
}
tr:nth-child(even) {
    background-color: #dddddd;
}
</style>
</head>
<body>
<h2>Price List</h2>
<table>
  <tr>
    <td>Product Name</td>
    <td>Sku</td>
    <td>Price</td>
  </tr>
  <tr>
    <td>KTree Web Service</td>
    <td>1234564</td>
    <td>60.USD Per Hr</td>
  </tr>
  <tr>
    <td>KTree Web Service</td>
    <td>1234565</td>
    <td>40.USD Per Hr</td>
  </tr>
  <tr>
    <td>KTree Web Service</td>
    <td>1234566</td>
    <td>50.USD Per Hr</td>
  </tr>
</table>
</body>
</html>

JavaScript

JavaScript is the third pillar of the web, alongside HTML and CSS, and it is normally used to make web pages interactive. To understand JavaScript (JS), we need to know what the DOM is.

The Document Object Model (DOM) is a language-independent application programming interface that turns the HTML document into a tree structure. The nodes of every document are organized in that tree structure, called the DOM tree, with the topmost node called the “Document Object.”

Sample DOM Tree (Source: Wikimedia Commons)

When an HTML page is rendered in the browser, the browser downloads the HTML into local memory and creates a DOM tree to display the page on screen.

Using JS, we can manipulate the DOM tree in several ways:

  • JS can modify the DOM tree by adding, changing, and removing all of the HTML elements and attributes in the page.
  • JS can change all of the CSS styles on the page.
  • JS can react to all of the existing events on the page.

JS can create new events within the page and then react to all of those events.
In our JavaScript example, we continue with our price list example by adding another column — Special Price — which is hidden by default. We’ll show it once the user clicks on it. In technical terms, we use a click event attached to the web element (anchor tag) and change the existing text of the web element, in other words manipulating the DOM. To do this, we have to use the browser’s accepted scripting language, which is always JavaScript.

<!DOCTYPE html>
<html>
<head>
<!–– for simplicity we have kept the CSS in inline in the HTML –  you can keep the css in any file with a .css extension and include it using <link rel="stylesheet" href="styles.css"> –>
    <style>
        table {
            font-family: arial, sans-serif;
            border-collapse: collapse;
            width: 100%;
        }
        td, th {
            border: 1px solid #dddddd;
            text-align: left;
            padding: 8px;
        }
        tr:nth-child(even) {
            background-color: #dddddd;
        }
        #specialprice {
        }
    </style>
</head>
<body>
<h2>Price List</h2>
<table>
    <tr>
        <td>Product Name</td>
        <td>Sku</td>
        <td>Price</td>
        <td>Special Price</td>
    </tr>
    <tr>
        <td>KTree Web Service</td>
        <td>1234564</td>
        <td>60.USD Per Hr</td>
        <td id="specialprice"> <a href="" onclick="return false;"> Click Here  </a> </td>
    </tr>
    <tr>
        <td>KTree Web Service</td>
        <td>1234565</td>
        <td>40.USD Per Hr</td>
        <td id="specialprice2"> <a href="" onclick="return false;"> Click Here  </a> </td>
    </tr>
    <tr>
        <td>KTree Web Service</td>
        <td>1234566</td>
        <td>50.USD Per Hr</td>
        <td id="specialprice3"> <a href="" onclick="return false;"> Click Here  </a> </td>
    </tr>
</table>
<script>
    document.getElementById("specialprice").onclick = function() {myFunction()};
    function myFunction() {
        document.getElementById("specialprice").innerHTML = "20% Off";
    }
</script>
</body>
</html>


Forms

Up til now, we’ve only discussed getting data from the server. Forms are the other side of HTML, which allows us to send information to the server. We can use forms to either update existing information or add new information. The most commonly used methods in HTML forms are GET and POST.

<!DOCTYPE html>
<html>
<body>
<form action="createproduct.php" method="post">
  First name:<br>
  <input type="text" name="Product Name" value="KTree Service">
  <br>
  Last name:<br>
  <input type="text" name="SKU" value="234555">
  <br><br>
  <input type="submit" value="Submit">
</form>
<p>If you click the "Submit" button, the form-data will be sent to a page called "createproduct.php".</p>
</body>
</html>

Have a glance at the code above — we have two input fields where the user can enter data and hit the submit button. Once the submit button is hit, the browser sends the data values of those two input fields along with some other information to the PHP script createproduct.php.

In our example it’s PHP, but it can be JSP, Python or any server-side script. The server-side script can read the values sent by the browser via POST, and then process it or store it in a file or database. In a nutshell, this is how data is pushed to the server and then eventually stored in a file or database.

Note: Let’s say we want to add validations before submitting — for example, the product should contain a minimum of 5 characters, or the SKU field should be not empty. We can use JavaScript for these validations. We need to react to the Submit Click event, and check if the web elements have the data we need. If anything is missing, we can display an error message and stop sending the data to the server.

Databases

As soon as information begins to grow, getting the right information from files can become a real pain, not to mention painfully slow. For example, let’s take the same price file, assume the company has thousands of products and we want to know the info for the last product in the list — which means we need to read all the products until we find the one we’re after. This isn’t an optimal way of retrieving information, and so to solve this problem, databases were born.

In a database (DB), we store the data in tables (a structured set of data) and as such we can perform search, sort and other operations easily.

Server-side Scripting Languages & Frameworks

We need programming languages:

  • To store to and read from a database or file
  • To GET the information from the server by doing certain processing.
  • To read the POST information from the client and do some processing to store/push that information.

Typical programming languages like C and Java can write to and read from databases, but they cannot be directly run on the web server. This gave birth to server-side scripting languages.

Server-side scripting languages do all regular processing and can talk to databases, and can be run directly on the web server. Popular server-side scripting languages are PHP, Perl, JSP, Ruby on Rails, and so on.

Developers started using these languages and soon they realized they were writing the same boilerplate code for all the projects, which led to the development of frameworks, which make it easier and faster to develop web applications.

Some notable frameworks:

PHP: Zend, YII, Symfony, CakePHP, Laravel
PHP products also used as frameworks: Drupal, Joomla, SugarCRM, WordPress
Java: J2EE, Hibernate, Struts, Spring
JavaScript: Node.js

MVC Architecture & Sessions

MVC architecture helps us to divide the code into multiple files and lets us separate business and presentation logic so it’s easier to modify them in later stages.

By taking the example of a blogging platform, we will revisit all the topics we’ve discussed so far, and see how we can code using MVC architecture.

A blog platform manages dynamic content and could contain a few modules such as:

  • Users
  • Blog posts
  • Tags
  • Categories

Before we discuss other functionalities, let’s come up with basic database design for the Blog Posts table. The important fields would be:

tbl_blog_post

IDTitle ContentCreated by First Name Last nameCreated On
 Hello World 1 Hello World 1User AUserA10 Jan 2016  
2Hello World 2Hello World 2User BUserB10 Jan 2016  

As you can see, we are storing duplicated user information such as ‘First Name’ & ‘Last Name’. If we have 10,000 Blog Posts we will store all the duplicated user information in all 10,000 Blog Post records. There might be more information about the user to store, for example his designation, last logged in time, etc.

The alternative, as you might have guessed, is to store ‘User’ information in another table and relate to it here with the ‘Related’ Id as in below.

tbl_user

ID  UsernameFirstName lastnameCreated On
101User AUser A10 Jan 2016
102 User B User B10 Jan 2016

tbl_blog_post

ID TitleContent Created by  Created On
1Hello World 1Hello World 110110 Jan 2016
2Hello World 2Hello World 210210 Jan 2016

This division of data into multiple tables is one amongst many principles of normalization of data.

The next important part is letting the user create the data in these tables via an HTML form. Please remember we’re doing this dissection to understand the concepts — this isn’t by any means a complete programing tutorial.

Create new blog post by authenticated user

For this we need a HTML form with two input fields (Title, Content) through which the user can create a blog post.

After the user enters the information and clicks on the submit button, ‘Create Post’, these form values are sent to the web server using POST. The POST values can be read using any server-side scripting language. The server script (PHP, Ruby on Rails, Python, etc.) reads the value from the FORM and pushes it to the database.

The script can also do processing, which could range from getting the server date and time or it could be some calculation field based on the values retrieved from another table or web service.

Another point to note: the script can also perform validations, also known as server-side validations, to make sure data is valid. If the data is valid then only FORM data is persisted to tbl_blog_post, or it sends a message back to the client to enter the missing information and the process continues.

In our table tbl_blog_post, along with title and content, we also have a field named created_by. How do we get the value for this field?

User Login

Typically, most web applications have login functionality. Whenever a user authenticates successfully, the user information is stored in sessions so that this information can be reused at a later time.

What is a Session?

The HTTP protocol is a stateless protocol, which means any request by the client made using GET or POST to the web server isn’t tracked. If the client (browser) makes two requests, the web server doesn’t know or care if both of them are coming from the same user. This also means that, for example, if you are logged in to an eCommerce application and you are adding products to your cart, the server doesn’t know both of you are same user.

In order to overcome this statelessness, clients need to send additional information in every request to retain session information for the duration of multiple requests. This additional information is stored on the client side in cookies, and on the server side in sessions.

A session is an array variable, which stores information to be used across multiple pages. Sessions are identified by an unique ID with a name that depends on the programming languages — in PHP it’s called ‘PHP Session ID’. the same Session ID needs to be stored as a cookie in the client browser to relate.

Display individual blog posts

The next item for us is to display individual blog posts. We need to read the data from the database based on the requested blog post ID, and then display the contents of the Title and Content fields.

High-level pseudo-code for displaying a single blog post:

Read the data from the database for the blog post ID
Insert the data into the HTML template along with CSS and JS
All the above code can be written in a single file. This is how it was done in the early days, but the development fraternity realized this is not optimal. For any new feature to be added, the whole code needed to be changed, and it wasn’t that easy to work in a multi-developer environment.

This caused web developers to adopt the MVC architecture, which essentially decouples the code into three components listed below.

Model: Model is the domain/business logic, independent of the user interface. In our example, the code to get individual posts from the database can be kept here.
View: A view can be any outputted representation of information. Our HTML code to the display the post can be kept here, so the data comes from the model, but the HTML is in the view.
Controller: The third part, the controller is what gets called if we click on the view post link. It gets the data from the model and, using that data, renders the view.
Let’s examine a typical URL in an MVC application to understand it better.

http://www.abc.com/blogpost/id/1

Here the blogpost is the controller name and the view is an action (method) in that controller. id is the ID of the blog post. If we enter this in the browser, the request goes to the action ‘View’ of the ‘BlogPost’ controller, and here it calls the model to get the content of blogpost ID ‘1’ as a Model object. This object is passed to the ‘View’ to render it.

Ajax & Single Page Applications (SPA)

If you were born in the last millennium you may remember that in the 90s and 00s, Hotmail and Yahoo! were very popular web email providers. If you click on the inbox or a single email in the inbox, the entire page would be refreshed. Around 2004, Gmail came with one important feature, Ajax. With Ajax, the whole page was not refreshed — only only the portions that needed to change were. So if you got a new email, instead of having to refresh the whole page, you simply saw a new email on top. This gave users a desktop-like experience, and it became a very popular way of building applications.

What is Ajax?

The term Ajax has come to represent a broad group of web technologies that can be implemented in an application that communicates with a server in the background, without interfering with the current state of the page.

With Ajax, you send a GET request to a server, and the server sends its response as an output all without blocking the current web page, which means the user can continue doing whatever they were doing without interruption. The output is appended or added to the current webpage.

In non-Ajax websites, each user action required a complete full page be loaded from the server. This process was inefficient and created a bad user experience. All page content disappeared, then reappeared.

Ajax is one of the techniques we can use to build Single Page Applications (SPAs). As the name suggests, the whole application is in a single page and all content is loaded dynamically. JavaScript frameworks such as Angular, React, and Backbone.js can be used to build SPAs.

Web Servers & Browsers

Browsers are the interpreters of the web. Browsers request data from web servers, and web servers process that request and send the response to the browser in HTML (including CSS, JS, images and so on), which is then displayed.

We can make a request of the web server using any of these three important methods:

  • GET: Get the requested resource as Response.
  • HEAD: The same as GET, but the response comes in Head instead of Response.
  • POST: Submit form data to the server, or any data via Ajax.

For example, when you type google.com into your browser, in the background the browser is sending this command to the google.com server.

GET: http://google.com

The Google web server will process its main/index file and send the response back to the client. It typically sends HTML content and CSS files, along with any other media files.