Introduction to Application Development: Client Layer
Let’s talk about the Client Layer!
In the previous blog, we covered the fundamentals of Application Development.
The client layer’s main role is to create a link between the user and the application. It is the first point of contact between the user and the application and has the responsibility to present data, collect information, and establish secure communication with the server.
It can be pretty challenging to understand how modern frontend frameworks work. By running a few commands and writing a few lines of code we can get started with a basic web application that is ready to host. But have you ever wondered how did we get here?
Let’s start by discussing the evolution of web applications.
1. Primitive Web Applications
Web Application that generates static HTML output and dynamically rendered HTML are the two subcategories of primitive web applications.
Static Web Application:
Web applications started with a static HTML page exposed to the user via a web server where all the values were hardcoded into an HTML file. These types of web applications would still work for some specific use cases but then it has their own set of drawbacks.
Say we have to create a portfolio website, a static web application would be the right choice as there is no interaction with a web server that is required and generally if we want to list down our project work then we can simply even hardcode it.
But then at the same time, if we have to create an e-commerce application, it would be a nightmare to create a separate HTML for each particular product which gave rise to the server-side rendered web applications.
Server Side Rendered Web Application:
Static Web applications have evolved over time and have started using server-side rendering to tackle the problem of creating pages with the content being dynamic.
In server-side rendered web applications, each route had its corresponding HTML file with some placeholders which will be populated by the values from the database.
Once the placeholders are replaced with all the values and the server returns an HTML output, the output is then displayed to the user on the client browser.
Each request from the client is forwarded to the backend and the backend returns the computed HTML. The server may run into a bottleneck while serving multiple requests at a time.
2. Scripting Web Applications:
Scalability being a problem for the server-side rendered web applications, the introduction of JavaScript changed the landscape. It provided the developers to bind the data into its respective placeholders at the client end itself. This solved the major issue of scalability as the developers gained capabilities to host the frontend and backend for all the applications separately.
JavaScript provided implementations to:
* Change content and properties of the HTML elements in the browser itself.
* Create simple checks and validations for data collection.
* Interacting with the server.
* Capture events performed on the browser.
In basic javascript applications all the data binding was considered to be one way, i.e. when the javascript function will be called to change the content or property, then it will get updated in the HTML DOM (Document Object Model) view on the browser.
In these types of applications, routing is still handled by the server. Each request has to find an HTML page for its corresponding route which has to be then configured at the backend.
So, to handle the pitfalls of such applications, there has been a sudden rise in the frameworks and libraries of JavaScript that we see.
We’ve gone through some of the common feature sets of such applications in the following section.
3. Modern Web Applications:
Modern UI applications made the job even easier for the developer.
Here are some of the common feature sets that most of them provide:
Firstly, a package manager is used by default to handle dependencies, and a command-line interface with a pre-installed web server is used to host the application for a development environment.
Secondly, the routing logic moved towards the client’s end. This basically saved the network latency to load all the files again as everything that used to be rendered is packaged as a single-page application. The framework packs up all the code (HTML, CSS & JS) and can execute it through a single index.html file.
Also, most of the frameworks have a concept of controllers/components in which if we create a variable and bind it to a placeholder in the HTML view, then every time the variable’s value (current state) changes, it will automatically reflect it in the HTML rather than explicitly executing the implementation of javascript to amend the DOM.
As you can see Client applications have grown over the years. These developments have improved the quality of the product. We don’t even have to wait 10 seconds for the whole page to load in modern-day applications.
