Client-side JavaScript (JS) Frameworks - Part 1
Tags: javascriptclientside
Published: 2021-11-10 20:40:05

---
title: Client-side JavaScript (JS) Frameworks - Part 1
published: true
date: 2021-11-10 18:16:15 UTC
tags: JavaScriptClientside
canonical_url: https://www.underthehoodlearning.com/client-side-javascript-frameworks-part1
cover_image: https://res-1.cloudinary.com/under-the-hood-learning/image/upload/q_auto/v1/blog_images/js-frameworks-2.png
---

JavaScript frameworks are an essential part of modern front-end web development, providing developers with tried and tested tools for building scalable, interactive web applications. Before we pick a framework and start learning about it, I think it's important that we first understand **what a client-side JavaScript framework is, what it does and why it exists**. So, that's exactly what we will be learning in this article.

> In this article, we will:
> 
> * Learn a brief history of JavaScript
> * Dig deep to understand why JavaScript was created in the first place
> * Explore main features of JavaScript frameworks

## A brief history of JavaScript

**Why was JavaScript needed in the first place?** Good question!😉 Again, **everything created was created to solve a problem.** So, what problems was JavaScript created to solve?

Before JavaScript was created, web pages exist only as static documents. In the 90s, internet connectivity was very slow as we were still using dial-up connections with telephone lines and modems. Most user actions in the interface trigger an HTTP request back to a web server.

Imagine a user filling out a form on a website. The validation of the input files on any form required a full round trip to the server. The server does some processing, retrieving data to validate the form values before returning an HTML page to the client. While the server is doing its thing, the user is waiting. And at every page reload, the user waits some more. This was not only a painful exercise as the internet speed was very slow but also resulted in the loss of data if the form was not filled out correctly. It lacks the inherent responsiveness of desktop applications.

**Netscape Navigator** , one of the most popular web browsers in the 90s, sought out to solve this problem by finding a way to validate the input fields on the client-side without having to make a round trip to the server. This is how JavaScript was born, merely as a scripting language to validate forms on the client-side.

To make it happen, Netscape turned to Brendan Eich, a software engineer with lots of experience with developing programming languages. At around the same time, Netscape laid the groundwork for a deal with **Sun Microsystems**. The idea was to sign a deal with Sun Microsystems to license **Java**. The preliminary concept was to embed **Java Virtual Machine (JVM)** right in Navigator which would allow developers to build complex Java applications (later called **applets** ) and run them on the web.

However, given the nature of the web community, which was a cobbled-together community of hobbyists and enthusiasts. Some had years of experience in the computer science field. Others had none at all. Netscape realized that what they really needed was a "companion language" because Java is a very difficult language to manage without a background in computer science. It's extremely powerful, but relies on complex principles like **object-oriented programming.** Therefore, any language made specifically for the web, needed to be both **powerful** and **approachable** to the average developer. Something that would allow developers to change text, move elements around, and generally experiment without errors flashing on screen every time they messed up something. A scripting language that could easily be embedded right into the HTML of a web page, that was still powerful enough to lay down a foundation for more adventurous programmers looking to build complex applications.

That's what Eich was tasked with creating, and that was exactly what he delivered. JavaScript officially made it into the first beta version of Netscape Navigator 2.0, released in September of 1995. With just a simple `script` tag, developers were able to create fairly complex applications.

![Client-side JavaScript (JS) Frameworks - Part 1](https://res-2.cloudinary.com/under-the-hood-learning/image/upload/q_auto/v1/blog_images/script-tag-html.png)

## Why do we need JavaScript frameworks?

When JavaScript debuted in 1996, it revolutionized how the web is used. It's no longer just a place to **read things**, but to **do things**. Originally, web pages were simple text pages that were used to share information in the form of text; there were no videos, games, animations, etc. A number of tools were later developed in order to allow the web to be as interactive as we know it today. **Dynamic HTML (DHTML)** and **Asynchronous JavaScript and XML (AJAX)** are two examples of such tools that are worth mentioning in the context of helping us understand the need for JavaScript frameworks.

**AJAX** and **DHTML** are two technologies that are used in order to create more interactive web pages compared to the plain boring HTML pages. The main difference between DHTML and AJAX is that **DHTML changes the elements on the web pages depending on user's actions** while **AJAX allows the browser to request certain elements one at a time** in order to reduce the strain on the server and the Internet connection.

Although it's possible to implement DHTML and AJAX with plain vanilla JavaScript, it's cumbersome. Therefore, developers who worked with JavaScript wrote tools to solve problems they faced and packaged them into reusable packages called **libraries** , so they could share their solutions with others. This shared ecosystem of libraries eventually led to the development of several JavaScript frameworks. The development of these frameworks also redefined how the web is used. Modern, complex, interactive websites, referred to as **web applications** now allow users to do things that used to be possible only in native applications installed on the user's computer.

A **framework** is **a library that offers opinions about how software gets built.** These opinions allow for predictability and homogeneity in an application. **Predictability** allows software to scale to an enormous size and still be maintainable.

## Main features of JS frameworks

Each major JS framework has a different approach to **updating the DOM, handling browser events, and providing enjoyable developer experiences.** Below are some of the main features shared among different JS frameworks. Each framework may have its own implementation, but at the core, they all share these common features. A good understanding of these common features at a high level is very useful when it comes to deciding which framework to use for your application. So, let's dive in.🤿

1. **Domain-specific languages (DSLs)**  
All JS frameworks use **DSLs** in order to build applications. For example, **React** uses **JavaScript XML (JSX)**, **Ember** uses **Handlebars** , and **Angular** uses **TypeScript.**

> A **domain-specific language** is a computer language that's targeted to solve a particular kind of problem, rather than a general purpose language that's aimed at any kind of software problem.
> 
> DSLs can't be read by the browser directly; they must be transformed into JavaScript or HTML first. Framework tooling generally includes the required tools to handle this transformation, or can be adjusted to include the necessary tools. While it is possible to build framework apps without using these DSLs, embracing them will streamline the development process.
> 
> Examples of common DSLs are **CSS, regular expressions, SQL, etc.**

2. **Components**  
Most frameworks have some kind of component model. Regardless of their opinions on how components should be written, each framework's components offer a way to describe the external **properties** they may need, the internal **state** that the component should manage, and the **events** a user can trigger on the component's markup.  
For example, **React** components can be written with **JSX** , **Ember** components with **Handlebars** , and **Angular** and **Vue** components with a templating syntax that lightly extends HTML.

3. **Styling**  
Each framework offers a way to define styles for components.

4. **Dependency Handling**  
As with other features, each framework provides its own mechanism for handling dependencies - using components inside other components. Components tend to import components into other components using the standard JS module syntax or something similar.

5. **Rendering Elements**  
Although each framework takes a slightly different approach in how components are rendered, all of them track the current rendered version of your browser's DOM, and make decisions about how the DOM should change as components in your application re-render.

6. **Routing**  
To avoid a broken experience in sufficiently complex apps with lots of views, each of the frameworks provides libraries that help developers implement client-side routing in their applications.

7. **Testing**  
Although testing tools are not built into the frameworks themselves, the command-line interface tools used to generate framework apps provide access to the appropriate testing tools for unit and integration testing.

I hope you enjoyed a little bit of the history lesson in this article. I truly believe that the best way to learn is trying to understand the **WHY** before the **WHAT** and the **HOW** , and one of the best ways to do that is to learn through history. In Part 2 of this article, we will explore the popular JavaScript frameworks throughout the history of web development. Stay tuned!

## Photo Credits:

1. [Background photo created by wirestock - www.freepik.com ([https://www.freepik.com/photos/background](https://www.freepik.com/photos/background))