DEV Community: Thanh Truong

React - Meet Virtual DOM

Thanh Truong — Wed, 09 Feb 2022 10:53:41 +0000

We briefly discussed the features of React in the introductory post of this series. In this article, we will dive deeper into the declarative programming aspect of React by exploring React's virtual DOM.

A major theme in React is a drive to simplify otherwise complex tasks and abstract unnecessary complexity away from the developer. React tries to do just enough to be performant while freeing you up to think about other aspects of your application. One of the main ways it does that is by promoting declarative instead of imperative programming. You get to declare how your components should behave and look under different states, and React's internal machinery handles the complexity of managing updates, updating the UI to reflect changes, etc. One of the major pieces of technology driving this is the virtual DOM.

A virtual DOM is a data structure that mimics the Document Object Model (DOM) in the browsers. React is not the only framework using a virtual DOM. Other frameworks such as Ember employ their own implementation of a virtual DOM. A virtual DOM serves as an intermediate layer between the application code and the browser DOM. The virtual DOM allows the complexity of change detection and management to be hidden from the developer and moved to a specialized layer of abstraction. React's virtual DOM handles change detection in data as well as translating browser events into events that React components can understand and react to.

The DOM

To understand virtual DOM, we first need to understand the DOM. If you're already familiar with the DOM, feel free to jump ahead to the next section.

The Document Object Model (DOM) is a programming interface that allows JavaScript programs to interact with different types of documents ( HTML, XML, SVG, etc.). There are standards-driven specifications - a standard set of features created by the public working group - for the DOM.

The DOM provides a structured way of accessing, storing, and manipulating different parts of a document. At a high level, the DOM is a tree structure that reflects the hierarchy of an XML document. This tree structure is comprised of sub-trees that are in turn made of nodes as shown in the image below. The DOM API that is exposed to JavaScript allows access and operations on each of these elements in the tree.

Whenever you use a method in JavaScript that accesses, modifies, or stores information related to something in an HTML document, you're using the DOM or its related API. Not all methods used in JavaScript are part of the JS language itself. In fact, they are part of a bigger collection of web APIs. For example, some common methods or properties that may be used to update or query a web page are: getElementById, parent.appendChild, querySelectorAll, innerHTML. These methods are provided by the host environment - the browser - and allow JS to interact with the DOM.

In the context of a large web application, interacting with the DOM in this manner could get quite complicated. That's when virtual DOM shines.😎

Virtual DOM

As mentioned in the previous section, there are certain pain points when it comes to working directly with the DOM via the regular web APIs, especially when building large and complicated web applications. Generally, these pain points arise in the area of change detection.

Particularly, when data changes, we need to update the UI to reflect that. However, doing that in a way that is efficient and easy to think about can be difficult due to the way browsers handle interactions with the DOM. When a DOM element is accessed, modified, or created, the browser is often performing a query across a structured tree to find a given element. It will then need to adjust the layout, sizing, and other actions as part of a mutation, all of which can be computationally expensive.

A virtual DOM can help with optimizing DOM updates to account for these constraints. And that's exactly what React's virtual DOM aimed to solve, i.e. implementing a virtual DOM that is **fast enough* while maintaining a robust API, simple mental model, and cross-browser compatibility.* The keyword here is "fast enough" because there is another factor that influences the design in React, which is simplicity. In other words, it must be simple enough to allow developers to defer extensive thinking about how the virtual DOM is accomplishing complicated state update logic and focus on the more important aspects of building their applications. Therefore, when building applications with React, we don't often need to directly interact with the DOM. Instead, we mostly leave that to React. But, how does the virtual DOM work?

DOM mutation done poorly can be computationally expensive, so React tries to be efficient in its update to the UI by implementing a diffing and update procedure.

React creates and maintains a virtual DOM in memory, and a renderer like react-dom handles updating the browser DOM based on changes. React solves the performance issue by implementing heuristic diffing - a method to calculate which parts of the in-memory DOM require changes to the DOM and perform intelligent updates only on the parts that have changed as shown in the image below.

To see the heuristic diffing mechanism in action, let's look at a simple example using both the native Web API and the React API for comparison purposes. To keep things simple, we will not be using components or JSX (the JavaScript extension that is used with React). Through this example, we will also learn about two core API methods: ReactDOM.render and React.createElement. These methods lay the foundation for our next article in which we get to learn about React components.

Heuristic Diffing

Before we can use the React library, we need to somehow import it into our application code. We can do that using one of the following methods as suggested on the React documentation. Once imported, the React's top-level APIs are available on the React global variable.

Load React from a <script> tag. The CDN links for both the React and ReactDOM libraries can be found on the React website.
Use import React from 'react' if using ES6 with npm.
Use var React = require('react') if using ES5 with npm.

To start off, let's render a simple HTML element to the display using two different methods: one from the native Web API, and the other from the React API as shown below.

You should see a "Hello Native Web API" box and a "Hello React" box. Let's study the code.👩‍💻

Basically, we have two nodes: mountNode1 is controlled with the DOM API directly while mountNode2 is controlled with the React API, which in turn uses the DOM API. The only major difference in how these two nodes were built is that in the DOM API version we used a string to represent the DOM tree, while in the React API version we used pure JavaScript calls and represented the DOM tree with an object instead of a string.

document.getElementById('mountNode').innerHTML = `
    <div>
    Hello Native Web API
  </div>
`;

ReactDOM.render(
  React.createElement(
    'div', 
    null, 
    'Hello React',
  ),
  document.getElementById('mountNode2'),
);

Let's focus on the React API. The ReactDOM.render and React.createElement methods are the core API methods in a React application. In fact, a React web application cannot exist without using both of these methods.

ReactDOM Render

This is basically the entry point for a React application into the browser's DOM.

ReactDOM.render(element, container[, callback])

It takes two required inputs and one optional input:

element: The first input is a React element, which we will explore in the next section. Basically, this input dictates WHAT to render to the browser.
container: A React element must be rendered inside a container, which is a valid DOM node that exists in the statically rendered HTML. In our example, it's the <div> element with the id=mountNode2 specified in the index.html file. Basically, the container dictates WHERE to render the React element in the browser.
[callback]: If provided, the callback will be executed after the component is rendered or updated.

React Element

We mentioned React element in the previous section. What exactly is a React element anyway? Well, long answer short, it's a virtual element describing a DOM element. The React.createElement API method returns a React element.

Instead of working with strings to represent DOM elements (as you've seen in the native Web API example above), DOM elements are represented as objects created by calling to the React.createElement method. These objects are known as React elements.

React.createElement(
  type,
  [props],
  [...children]
)

The above method has three arguments and returns a new React element of the given type :

type: The type argument can be either a tag name string (such as 'div' or 'span'), a React component type (a class or a function), or a React fragment type. In this example, we're passing 'div' as the type. We'll be covering React components and fragments in a future post.
[props]: Any attributes (id, href, title, etc.) we want the DOM elements to have. In this example, the div element we're using has no attributes, so we passed in null.
[...children]: This argument forms the children list for the rendered element and is the content of the DOM element. An element can have zero or more children.

No matter how complicated the UI is going to get, when using React every HTML element will be represented with a React element. React elements are created in memory. To actually make a React element show up in the DOM, we need to use the ReactDOM.render method which will figure out the most optimal way to reflect the state of a React element into the actual DOM tree in the browser.

To demonstrate how React elements can be nested, let's add a couple more elements to the current UI. Let's add a textbox to read input from the user and the current time displayed inside a <pre> tag. We'll do that to both the native Web API and React API versions. As shown below, both the <input> and <pre> tags were added by making a nested React.createElement method call inside of the top-level React element. Both versions should still be rendering the same exact HTML in the browser.

At this point, you're probably thinking that using React is a lot harder than the simple and familiar native way. What is it that React does so well that makes it worth giving up the familiar HTML and having to learn a new API to create what can be simply created using the native Web APIs? The answer is not about the initial rendering of the HTML view. Rather, it's all about updating the existing view in the DOM. And that's when the heuristic diffing mechanism comes in handy.

Heuristic Diffing

To demo this concept, let's add an update operation to the DOM trees which can be done using the setInterval method from the Web timer API. But first, we'll need to put all of our DOM manipulations for both versions into a function, which we'll name as render, and pass it into the setInterval method as a callback in order to call it every second.

const render = () => {
  document.getElementById('mountNode').innerHTML = `
    <div>
      Hello HTML
      <input />
      <pre>${new Date().toLocaleTimeString()}</pre>
    </div>
  `;

  ReactDOM.render(
    React.createElement(
      'div',
      null,
      'Hello React',
      React.createElement('input', null),
      React.createElement('pre', null, new Date().toLocaleTimeString())
    ),
    document.getElementById('mountNode2')
  );
};

setInterval(render, 1000);

Are you ready for what you're about to see next?😜 This is when React is going to blow your mind.💥 Now, try typing something into the textbox of the native Web API version. You won't be able to.😜 This is very much expected because we are basically throwing away the whole DOM node on every tick and regenerating it. However, try typing something in the textbox that is rendered with React. Magic!!!✨😎 So what's the difference?🤔

Although the whole React rendering code is wrapped inside the ticking timer, React is only changing the content of the <pre> element and not the whole DOM tree. In other words, the textbox was not regenerated, which is why you were able to type in it.

You can see the difference in how the native Web API and the React API update the DOM visually by inspecting the two DOM nodes in the Chrome DevTools. As shown below, the native Web API regenerates the entire <div id="mountNode1"> container with every tick, while React smartly regenerates only the <pre> tag in its <div id="mountNode2"> container.

This is React's smart diffing algorithm in action. It only updates in the main DOM tree what actually needs to be updated while keeping everything else the same. This diffing process is possible because of React's virtual DOM representation that it keeps around in memory. No matter how many times the UI views need to be regenerated, React will take to the browser only the needed partial updates.

Not only is this method a lot more efficient but it also removes a big layer of complexity in the way think about updating UIs. Having React do all the computations about whether we should or should not update the DOM enabled developers to focus on thinking about their data (state) and the way to describe a UI for it. Developers can focus on updates on the data state as needed without worrying about the steps needed to reflect these updates in the actual UI in the browser because React's got their backs.😉

React - Meet and Greet

Thanh Truong — Wed, 02 Feb 2022 11:09:57 +0000

You have probably heard of React in a discussion about other well-known JavaScript libraries and frameworks such as Vue, Angular, Ember, Webpack, Redux, etc. We will kick-start this series with a quick introduction to React in the first two articles of this series.

In this Part 1 article, we will:

Settle the debate on whether React is a library or a framework, for good 😜

Explore all the major ingredients that make up a React application

Explore features of React at a high-level overview

Is it a library or a framework?

Before we get started on learning about React, I think it's important that we get this question answered because it has real consequences for our development process. And the answer to the million-dollar question is:

React is a ... LIBRARY.

🎉🎉🎉👏👏👏😁

As a matter of fact, it's stated very clearly on their official website homepage.

React is written in JavaScript, but unlike other popular JavaScript frameworks such as Angular, Vue, Svelte, React is fundamentally unopinionated. But what does it even mean?

It means that React itself does not include many of the React-specific libraries you're going to need for most projects. The React and React DOM libraries give us the means of building a user interface with the JSX syntax, plus powerful state management tools via hooks, among other things. React does not enforce strict rules around code conventions or file organization allowing developer teams to set conventions that work best for them. Angular and Vue, by comparison, include many more tools all bundled within the core package itself.

For example, when you set up an Angular project, it is bootstrapped with nearly every single thing that you'll need to make a complete, large-scale app. Some built-in tools included in Angular are tools for common tasks such as creating forms, running automated tests, making network requests, etc.

That being said, it doesn't necessarily mean that React cannot be used to build complex and large-scale applications. However, the implication is that the burden is on you as a developer to choose the packages and tools that you need in order to build your applications. For example, React Hook Form or Formik are React-specific form libraries, React Testing Library and/or Jest can be used for automated testing, Fetch API or Axios can be used for making network requests.

The tools or libraries that you choose to use depend on the demands of the app and your preferences as a developer. This is one of the advantages of using React since it doesn't lock you into one choice or hold you to any specific libraries other than React itself. However, it does with a price because you will need to keep up with emerging libraries.

It's worth noting that there are frameworks out there that are based on React if you ever need it. Some of the most popular frameworks are Next.js, Gatsby, and Redwoord.js, all of which are used to create full-scale dynamic and static React applications.

React's Major Ingredients

React's mental model draws broadly on functional and object-oriented programming concepts and focuses on components as primary units for building with. In React applications, you create interfaces from components. React's rendering system manages these components and keeps the application view in sync for you.

Components often correspond to aspects of the user interface such as datepickers, headers, navbars, etc., but they can also take responsibility for things like client-side routing, data formatting, styling, and other responsibilities of a client-side application. Components in React follow a predictable lifecycle, can maintain their own internal state, and work with regular old JavaScript.

We will dive into these concepts in more detail in subsequent posts. For now, let's look at an overview of the major ingredients that go into a React application.

Components Components are _ encapsulated _ units of functionality that are the primary unit in React. They utilize _ data _ (_ properties _ and _ state _) to render your UI as output. Certain types of React components also provide a set of lifecycle methods that you can hook into. The rendering process outputs and updates the UI based on the data by interacting with the components via React's APIs.
React libraries React uses a set of core libraries, which work with the react-dom and react-native libraries and is focused on component specification and definition. Using these libraries, we can build a tree of components that a renderer for the browser or another platform can use. react-dom is a renderer that is aimed at browser environments and server-side rendering, whereas react-native focuses on iOS, Android, and other native platforms.
Third-party libraries React doesn't come with tools for data modeling, HTTP calls, styling libraries, or other common aspects of a front-end application. Therefore, developers are free to choose which additional modules or libraries they prefer to use.

React Features

Since we were browsing the React homepage, let's take a look at some of the features of React listed on the homepage to understand what this library promises to deliver.

We will discuss these features at a high level and will dive deeper into the declarative and component-based concepts in the next article.

Declarative Declarative programming is not a new concept but just got popularized by React in the JavaScript community in recent years. According to Wikipedia:

Declarative programming is a programming paradigm — a style of building the structure and elements of computer programs—that expresses the logic of a computation without describing its control flow.

Component-Based

When Facebook released React.js in 2013, it defined a new way in which front-end developers could build UI through a concept known as Component-Based Architecture (CBA), a method for encapsulating individual pieces of a larger UI into self-sustaining, independent micro-systems.

Components have their own structure, their own methods, and their own API. Components are reusable, and their "independent nature allows developers to create a UI with many moving parts, e.g. one component can refresh without affecting other components or the UI as a whole.
Learn Once, Write Anywhere

Developers can use React to build applications for whatever platform they choose, without the need to learn a fundamentally different set of technologies. React can render on the server using Node and power mobile apps using React Native.

What's Next?

For the remainder of this series, we will explore each of the core concepts of React as shown in the diagram below. Of course, listed here are just the core concepts that are typically encountered when building a React application. As we dive into each of these concepts, we will also discuss other relevant concepts as they come up.

Virtual DOM: React implements a virtual DOM that sits between your program and the browser DOM allowing for efficient updates to the DOM using a fast diffing algorithm. This is the core of React's declarative programming.
Component: Components are the most fundamental unit of React. Component composition and reusability are some of the most powerful aspects of React.
Routes: Routing is a system for resource navigation and is an important part of web applications. Different parts of your site will need their own URLs (for example, /blogs, /tags, /about, etc.), and routing facilitates page navigation as it relates to URLs and resources such as images, HTML pages, scripts, etc.
Styling and CSS: There are several options for styling a React app. We will discuss some of these options.
Data: Modern web applications are mostly dynamic and filled with data that changes over time. We will explore how data flow between components via props and states. Lifecycle events are often used to handle various effects such as fetching data on the _ mount, _ cleaning up before the component unmounts, sanitizing props when the components updates, etc. React provides lifecycle methods and hooks that can be used to "hook" into different parts of a component's lifetime.
Form: Most web applications involve forms to one degree or another. We'll look at how to implement forms in React.
Redux: Redux is a library and application architecture for state management that results in a highly predictable, testable, and debuggable application by enforcing strict ways of working with data.

Observer Pattern with Vanilla JS

Thanh Truong — Wed, 12 Jan 2022 11:07:55 +0000

In the previous article, we learned about the MVC architectural pattern using vanilla JS. In this article, we will take another step further to improve our data flow between model, view, and controller by implementing the Observer pattern.

In this article, we will:

Explore ways to improve data flow for the existing MVC pattern.

Learn about the problems that the Observer is designed to solve.

Learn what the Observer pattern is all about.

Explore how to implement the Observer pattern using example from the previous article.

In our MVC implementation, our controller mediates the interaction between the view and the model, i.e. the view triggers a change in the model through the controller, and then the model updates the view* through the controller. This setup is referred to as a two-way data flow.

With the Observer pattern, we can turn the model into an "observable" and the view into an "observer". When the observable is changed, it notifies the observer of its state, and the observer can react to that change. This makes our data flow unidirectional. The controller no longer updates the view, the view updates according to the model.

The Observer is a _ behavioral design pattern _ that lets you define a _ subscription mechanism _ to notify multiple objects about any events that happen to the object they're observing.

What problem does the Observer pattern solve?

It's sometimes helpful to use a real-world analogy in order to understand the kind of problem that this pattern is designed to solve. Let's just say that you really enjoy the content published on my blog.😉 Instead of having to visit my site every day to check for new articles (not that I'm against that idea 😜), you could choose to subscribe to my Facebook, Twitter, or Instagram pages so that you receive a notification every time I publish a new article. I'd suggest you subscribe to my blog, but it's not set up yet.😁 Anyway, you get the idea.

Use the Observer pattern when:

Changes to the state of one object require changing other objects, and the actual set of objects that are to be updated based on the state change is unknown beforehand or changes dynamically. For example, you created a custom button class, and you want to let the clients hook some custom code to your button so that it fires whenever a user presses the button. You can add the subscription mechanism to your button class, letting the clients hook up their custom code via custom subscriber classes.
Some objects in your app must observe others, but only for a limited time or in specific cases. The observer list is dynamic, so subscribers can join or leave the list whenever they need to.

What is the Observer pattern?

The Observer pattern consists of an observable/subject/publisher and an observer/subscriber.

Observable/Subject/Publisher is an object/class that maintains a list of observers/subscribers that it needs to notify when it is updated. It will also need to provide a subscription mechanism to allow the observers to subscribe or unsubscribe from its event streams. In reality, this mechanism consists of:
1. observers: This class property holds an array of observers.
2. addObserver(): This method adds an observer to the observers array
3. removeObserver(): This method removes an observer from the observers array
4. notify(): This method notifies all observers that a change has happened.
Observer/Subscriber is any object/class that wants to subscribe/listen to changes in the _ publisher _ by implementing an update() method that will be called by the _ publisher's _ notify() method.

How to implement the Observer pattern?

In real-world applications, there might be several different subscriber classes/objects subscribing to the same publisher class. So, we wouldn't want to couple the publisher to all of those subscriber classes. That's why it's crucial that all subscribers implement the same interface and that the publisher communicates with them only through that interface. However, since we will be using Vanilla JS to keep things simple, we don't have access to interfaces. We can create parent classes from which we can extend. Specifically, the Observable and Observer parent classes will have those properties and methods required in order to implement the observer pattern.

Building up from our previous example of the MVC architectural pattern in the previous blog post, we will now implement the Observer pattern in order to achieve the unidirectional data flow.

Create the Observable parent class with the addObserver() and removeObserver(), and notify() methods.

class Observable {
   constructor() {
     this.observers = [];
   }

   // Add an observer to this.observers.
   addObserver(observer) {
     this.observers.push(observer);
   }

   // Remove an observer from this.observers.
   removeObserver(observer) {
     const removeIndex = this.observers.findIndex((obs) => {
       return observer === obs;
     });

     if (removeIndex !== -1) {
       this.observers = this.observers.slice(removeIndex, 1);
     }
   }

   // Loops over this.observers and calls the update method on each observer.
   // The state object will call this method everytime it is updated.
   notify(data) {
     if (this.observers.length > 0) {
       this.observers.forEach((observer) => observer.update(data));
     }
   }
}

export default Observable;

Create the Observer parent class. At a bare minimum, it should include the update() method.

class Observer {
   // Gets called by the Subject::notify method.
   update() {}
 }

export default Observer;

Update the HeadingModel class to have it extend the Observable parent class.

import Observable from "./observable";

class HeadingModel extends Observable {
   constructor() {
     super();
     this.heading = "Hello";
   }
}

export { HeadingModel };

Update the HeadingView class to have it extends the Observer parent class. We will need to implement the update() method that is required by the parent class and is called each time the notify() method in the Observable class is called. We will also need to register the HeadingView as an _ observer _ of the HeadingModel _ observable _ via the addObserver() method.

import Observer from "./observer";

class HeadingView extends Observer {
   constructor(controller) {
     super();
     this.controller = controller;
     this.heading = document.getElementById("heading");
     this.heading.innerText = controller.modelHeading;
     this.heading.addEventListener("click", controller);
     this.controller.model.addObserver(this);
   }

   update(model) {
     this.heading.innerText = model.heading;
   }
}

export { HeadingView };

Finally, we need to update our controller's clickHandler() method to call the HeadingModel's notify() method each time the event is emitted instead of changing the innerText through the controller.

class HeadingController {
   constructor(model) {
     this.model = model;
   }

   //EVENTLISTENER INTERFACE
   handleEvent(e) {
     e.stopPropagation();
     switch (e.type) {
       case "click":
         this.clickHandler(e.target);
         break;
       default:
         console.log(e.target);
     }
   }

   get modelHeading() {
     return this.model.heading;
   }

   //CHANGE THE MODEL
   clickHandler(target) {
     this.model.heading = "World";
     this.model.notify(this.model);
   }
}

export { HeadingController };

Our main() function should still work as is.

Photo Credits

Social media photo created by jordy_pp - www.freepik.com

MVC Architectural Design Pattern With Vanilla JS

Thanh Truong — Wed, 05 Jan 2022 11:15:42 +0000

Most people assume that the meaning of MVC (Model-View-Controller) is static, but that's simply not true. MVC is not a well-defined concept, so do not assume it to be one in conversations. Instead, treat it more like a buzzword like "cloud".😉 MVC takes on a slightly different meaning depending on the specific context. Without a context, it is only a "fuzzy" concept in general.

MVC is one of the most well-known architectural patterns and is the basis of many JavaScript frameworks (such as Angular ) and several server-rendered web frameworks (such as ASP.NET Core MVC ) . As suggested by the post title, in this article, we will discuss the MVC pattern in the context of client-side development using JavaScript.

In this article, we will:

briefly explore the original meaning of the MVC pattern by looking at its history

explore the meaning of the MVC pattern in the context of JavaScript frontend development

implement the MVC architectural pattern using only Vanilla JS on the frontend to gain a deep understanding and hands-on experience with this design pattern

History of MVC

The MVC pattern was invented by Trygve Reenskaug while he was a visiting scientist at the Smalltalk group at the Xerox Palo Alto Research Center (PARC). He wrote his first paper on MVC in 1978. The MVC pattern was invented long before the first web browser and was first implemented as part of the Smalltalk-80 class library. It was originally used as an architectural pattern for creating graphical user interfaces (GUIs).

The original meaning of the Model-View-Controller pattern was very different than the meaning associated with the pattern today. In the context of a GUI, the Model View Controller pattern was interpreted as follows:

Model: A particular piece of data represented by an application, e.g. weather station temperature reading.
View: One representation of data from the model. The same model might have multiple views associated with it. The views are associated with a particular model through the Observer relationship. For example, a temperature reading might be represented by both a label and a bar chart.
Controller: Collects user inputs and modifies the model, e.g. the controller might collect mouse click events and update the model.

The primary benefit of this original version of the MVC pattern is a Separated Presentation, which was defined by Martin Fowler as:

A pattern that is used to ensure that any code that manipulates presentation only manipulates representation, pushing all domain and data source logic into clearly separated areas of the program.

In this pattern, the view is updated indirectly from the model via event handling. The controller does not interact directly with the view. Instead, the controller modifies the model, and since the view is observing the model, the view gets updated.

Why MVC?

To really appreciate the beauty of the MVC pattern, let's look at an example of code without MVC.

The traditional server-rendered web pages consist of static HTML documents. Each time the user requests a page, the server returns a new HTML page with the state of the information on the server at that moment in time. Then, AJAX came along allowing us to update page elements and send user requests back to the server without having to wait for the server. However, AJAX development and adoption also brought with it more complexity in our code that required some sort of code restructuring for separation of concern, modularity, and reusability.

Consider the following example. We have a simple form with a single textbox to allow the user to enter their email address for account registration. We will need to set up some validation logic for our form. In this case, the event handler function for the Submit button in the script loops through a predetermined list of fields and run through the validation logic for each of the fields based on the class name metadata. Go ahead and try to click Submit without any email address entered. You should see an alert dialog pop up with the warning.👇

Although this approach works, it isn't very flexible. What if we want to add fields or validate a different form on another page. We would have to duplicate most of this functionality for each new field we add. Also, what if our validation logic is much more complicated than this, e.g. a field is required only if another field is completed? You can probably imagine that our code would eventually grow out of control.😵

MVC with Vanilla JS

Most of you are familiar with Single-Page Applications (SPA) MVC frameworks such as Angular that have become increasingly popular over the past few years. However, it's possible to implement the MVC architectural pattern on the front-end without using a framework or library. One of the benefits of this exercise is that it provides you with a solid understanding of how this pattern is implemented "under the hood" so that when it's time for you to pick up a framework, you feel more comfortable understanding why it works the way it does. Without further ado, let's get started!😎

Build the View, Model, Controller

Before we dive into the code, below is a demo of what we will be building for this example. Try clicking on the word "Hello" and observe how the text is dynamically updated to "World". Feel free to look at the files to familiarize yourself with the MVC structure.👇

In the context of our frontend JS application, MVC is an architecture with three layers:

Model: is the container of our state and also performs business/domain logic.
View: is the visual representation of the models, i.e. the output displayed to the user
Controller: serves as the mediator between the model and the view and also stores some non-domain application states.

The View

For a browser-based, vanilla JS implementation, we have HTML and the DOM to worry about, so there will be two pieces to our view: the HTML itself and a View class that encapsulates relevant DOM selectors.

In our example, the HTML is very simple. It has the <h1> element with the id=heading, and references several scripts containing all of our code for the model, view, and controller. The initial value for the <h1> element's innerText will be set by the Controller as you shall see later.

<html>
  <head>
    <meta charset=”utf-8">
    <meta name="”viewport”" content="”width" ="device-width”" />
    <title>MVC Experiment</title>
    <script src="./src/index.js"></script>
    <script src="./controllers/heading.controller.js"></script>
    <script src="./models/heading.model.js"></script>
    <script src="./views/heading.view.js"></script>
  </head>

  <body>
    <h1 id="heading"></h1>
  </body>
</html>

Our View class is defined in the heading.view.js file. We're passing a controller into the constructor as a dependency. The controller will be listening for events on our relevant DOM nodes. Here, we're interested in the <h1> DOM node with the id=heading. So, we populate the initial value for the innerText of this <h1> element to the initial state of the model, and we do that via the controller.

We also register the event handler for the <h1> element via the addEventListener() method of the EventTarget interface available in the Web API. This interface can be implemented by any object that can receive events such as element, document, window, etc. The addEventListener() method sets up a function that will be called whenever the specified event is delivered by the target. In this case, we're passing in click as the event type to listen for and the controller itself as an object that implements the EventListerner interface as you shall see in the section about the controller.

class HeadingView {
  constructor(controller) {
    this.controller = controller;
    this.heading = document.getElementById("heading");
    this.heading.innerText = controller.modelHeading;
    this.heading.addEventListener("click", controller);
  }
}

export { HeadingView };

The Model

Our model is defined in the heading.model.js file. For this example, our model will be very simple. It consists of a value for the heading, which is what we used to set our <h1> element's innerText. The model will be injected into the controller so that the controller can manipulate the model as prompted by the view's events.

class HeadingModel {
  constructor() {
    this.heading = "Hello";
  }
}

export { HeadingModel };

The Controller

As mentioned in the section about the View, in order for the event handler to work as expected, the controller must implement the EventListener interface of the Web API. This interface represents an object that can handle an event dispatched by an EventTarget object (in this case, it's the <h1> element). Any object that uses this interface (in this case, it's the controller ) must implement the handleEvent method, which is a function that is called whenever an event of the specified type occurs.

Our controller is defined in the heading.controller.js file.

class HeadingController {
  constructor(model) {
    this.model = model;
  }

  //EVENTLISTENER INTERFACE
  handleEvent(e) {
    e.stopPropagation();
    switch (e.type) {
      case "click":
        this.clickHandler(e.target);
        break;
      default:
        console.log(e.target);
    }
  }

  get modelHeading() {
    return this.model.heading;
  }

  //CHANGE THE MODEL
  clickHandler(target) {
    this.model.heading = "World";
    target.innerText = this.modelHeading;
  }
}

export { HeadingController };

As shown in the code above, our controller implements three methods:

handleEvent: This method handles the click event for the <h1> element. If the event is click then the clickHandler() method is called.
clickHandler: This method updates the model as well as the <h1> element's innerText (represented as the target parameter).
getModelHeading: This method is used to retrieve the current value of the heading property of the model. As mentioned in the View section, we call this method to get the initial state of the model and assign the returned value to the <h1> element.

Wiring Up Model-View-Controller

Now that we have our model, view, and controller defined, we need to create and inject them in the correct order. We'll do that in the index.js file.

import { HeadingModel } from "../models/heading.model";
import { HeadingController } from "../controllers/heading.controller";
import { HeadingView } from "../views/heading.view";

function main() {
  var model = new HeadingModel();
  var controller = new HeadingController(model);
  var view = new HeadingView(controller);
}

main();

The model is instantiated first, injected into the constructor for the controller, and then the controller is injected into the view. Our model does not know anything about the view and vice versa. The controller can interact with both since it's injected into the view, and the model is injected into the controller. Finally, we invoke the main() function and we should be able to click "Hello" to change it to "World".

And there you have it. We've learned how to structure our code following the MVC pattern using just Vanilla JS. Sure, we ended up with more code than what we had in the example without using MVC, but the idea is that this pattern can be expanded to make your code more modular and maintainable as your application grows in its complexity.

We can stop here, but I think we can expand on these building blocks to make it even better by implementing the Observer pattern to achieve a unidirectional data flow between the model and the view. We can also add the ability to toggle between "Hello" and "World" by implementing the State pattern. Going through these exercises would also help us learn about these two design patterns ( Observer and State patterns) in the most practical way. So let's do that in the next two articles.💪

AJAX Demystified - What Is AJAX?

Thanh Truong — Wed, 29 Dec 2021 12:03:40 +0000

In Part 1 of this series, we laid the foundation for learning AJAX by digging deep into the history of web development at the time when AJAX was created. In this next part of the series, we will learn what AJAX really is.

What is AJAX?

We learned from the previous blog post that AJAX was created to solve the problem with the "annoying" delay in the responsiveness of a sovereign web application. An AJAX application, therefore, eliminates the start-stop-start-stop nature of interaction on the Web by implementing a collection of four technologies that complement one another: CSS, DOM, JavaScript, and XMLHttpRequest.

JavaScript (JS): JavaScript is the glue that holds everything together in an AJAX application. JS is used to define user workflow and business logic of the app, manipulates and refreshes the UI via the DOM to continually redraw and reorganize the data presented to the users based on user's interactions via mouse and keyboard event handling.
CSS: In an AJAX application, the styling of a UI may be modified interactively through CSS.
DOM: The DOM presents the structure of web pages as a set of programmable objects that can be manipulated with JS. Scripting the DOM allows an AJAX application to modify the UI on the fly, effectively redrawing parts of the page.
XMLHttpRequest: The XMLHttpRequest object allows data retrieval from the webserver asynchronously. The data format is typically XML , but it works well with any text-based data. Nowadays, the most common data format used for this is JSON.

It's worth mentioning that three of the four technologies listed above ( CSS, DOM, JS ) have been collectively referred to as Dynamic HTML (DHTML). DHTML offered the ability to create interactive UI for web pages. However, it never overcame the issue of the full-page refresh since without communicating with the server, there was only so much it could do. AJAX makes considerable use of DHTML, but with the ability to make asynchronous requests to the server, AJAX has a lot more to offer.

XMLHttpRequest

XMLHttpRequest is a native API in JS that encapsulates the logic of sending HTTP requests without having to refresh a loaded web page - _ AJAX request. _ Even though developers rarely use XMLHttpRequest directly now, it's still the building block that works underneath many popular HTTP request modules such as Fetch and Axios.

The complete lifecycle of loading a document using XMLHttpRequest is as follows: _instantiate the XMLHttpRequest object, tell it to load a document, and then monitor that load process asynchronously using callback handlers. _

Now that you understand the high-level concept of AJAX, let's jump into some codes.👩‍💻 Let's try to implement AJAX using Vanilla JS. Why would we want to do that if there are several frameworks out there that have out-of-the-box AJAX technology? It's because we want to learn "under the hood", remember?😉

AJAX using Vanilla JS

We will be implementing AJAX using Vanilla JS to build a simple web application as shown below. When the Retrieve button is clicked, a "Hello World!" message returned by the backend server via an AJAX call is displayed right below the button without a page refresh. Try it for yourself!👇

A simple AJAX implementation takes four steps:

Create an instance of the XMLHttpRequest (aka XHR) object
Use the open() method of the XHR to specify what kind of data you want
Create a function to process the response
Use the XHR's send() method to send the request

Now, let's look at some code. For this simple demo, we have a simple backend web server written in Node.js to process AJAX requests. For the UI on the frontend, we have a simple HTML and a script for the Retrieve button's event handling.

Node.js Backend Web Server

The code for our Node.js web server is defined in the index.js file located in the root directory.

var http = require("http");
var fs = require("fs");

function render(path, contentType, fn) {
  fs.readFile(__dirname + "/" + path, "utf-8", function (err, str) {
    fn(err, str, contentType);
  });
}

//create a server object:
http
  .createServer(function (req, res) {
    var httpHandler = function (err, str, contentType) {
      if (err) {
        console.log(err);
        res.writeHead(500, { "Content-Type": "text/plain" });
        res.end("An error has occured: " + err.message);
      } else {
        res.writeHead(200, { "Content-Type": contentType });
        res.end(str);
      }
    };
    if (req.url.indexOf("/scripts/") >= 0) {
      console.log("Serving ajax.js");
      render(req.url.slice(1), "application/javascript", httpHandler);
    } else if (
      req.headers["x-requested-with"] === "XMLHttpRequest" &&
      req.headers["x-vanillaajaxwithoutjquery-version"] === "1.0"
    ) {
      console.log("Processing AJAX request");
      res.writeHead(200, { "Content-Type": "application/json" });
      res.end(JSON.stringify({ message: "Hello World!" }));
    } else {
      console.log("Serving index.html");
      render("views/index.html", "text/html", httpHandler);
    }
  })
  .listen(8080); //the server object listens on port 8080

Here, we're using the http module to create an HTTP server. For those of you that are not familiar with Node.js, here is a brief explanation of the code.

The server is listening on Port 8080. The callback function we pass to the createServer() method is executed for each request that comes in. Whenever a new request is received, the request event is called, providing two objects: a request (an http.IncomingMessage object) and a response (an http.ServerResponse object). The request provides the request details through which we can access the request headers and request data. The response is used to populate the data returning to the client.

var http = require("http");

//create a server object:
http
  .createServer(function (req, res) {
    // callback to handle request is define here
  })
  .listen(8080); //the server object listens on port 8080

Let's look at the callback function used to handle requests.

if (req.url.indexOf("/scripts/") >= 0) {
  render(req.url.slice(1), "application/javascript", httpHandler);
} else if (
  req.headers["x-requested-with"] === "XMLHttpRequest" &&
  req.headers["x-vanillaajaxwithoutjquery-version"] === "1.0"
) {
  res.writeHead(200, { "Content-Type": "application/json" });
  res.end(JSON.stringify({ message: "Hello World!" }));
} else {
  render("views/index.html", "text/html", httpHandler);
}

This block of code checks the request URL to determine how the app should respond.

If the request came from the scripts directory, then the appropriate file is served with the application/javascript content type.
Any request with x-request-with headers set to XMLHttpRequest indicates an AJAX request. In this case, we simply return a "Hello World!" text message.
If it's neither of the two cases above, then the index.html file is served.

We haven't discussed the render() and httpHandler() functions yet, so let's do that now. The render() function asynchronously reads the contents of the requested file. It accepts the httpHandler() callback function, which is used to check for errors and write the content of the file to the response with the appropriate HTTP status code if everything looks good.

function render(path, contentType, fn) {
  fs.readFile(__dirname + "/" + path, "utf-8", function (err, str) {
    fn(err, str, contentType);
  });
}

var httpHandler = function (err, str, contentType) {
  if (err) {
    console.log(err);
    res.writeHead(500, { "Content-Type": "text/plain" });
    res.end("An error has occured: " + err.message);
  } else {
    res.writeHead(200, { "Content-Type": contentType });
    res.end(str);
  }
};

Frontend UI Code

Now, let's look at our frontend code, which contains the /views/index.html file and the /scripts/ajax.js script used for the button event handling. The index.html is straightforward. It references the ajax.js script which is called when the user clicks the Retrieve button.

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width" />
    <title>Vanilla Ajax without jQuery</title>
  </head>
  <body>
    <h1>Vanilla Ajax without jQuery</h1>
    <button id="retrieve" data-url="/">Retrieve</button>
    <p id="results"></p>
    <script src="/scripts/ajax.js" async></script>
  </body>
</html>

The ajax.js script is where most of the AJAX magic happens.

(function () {
  var retrieve = document.getElementById("retrieve"),
    results = document.getElementById("results"),
    toReadyStateDescription = function (state) {
      switch (state) {
        case 0:
          return "UNSENT";
        case 1:
          return "OPENED";
        case 2:
          return "HEADERS_RECEIVED";
        case 3:
          return "LOADING";
        case 4:
          return "DONE";
        default:
          return "";
      }
    };
  retrieve.addEventListener("click", function (e) {
    var xhr = new XMLHttpRequest();
    xhr.onreadystatechange = function () {
      console.log(
        "Inside the onreadystatechange event with readyState: " +
          toReadyStateDescription(xhr.readyState)
      );
      if (xhr.readyState === 4 && xhr.status === 200) {
        if (xhr.responseType === "json") {
          results.innerHTML = xhr.response.message;
        } else {
          results.innerHTML = JSON.parse(xhr.responseText).message;
        }
      }
    };
    xhr.open("GET", e.target.dataset.url, true);
    xhr.responseType = "json";
    xhr.setRequestHeader("X-Requested-With", "XMLHttpRequest");
    xhr.setRequestHeader("x-vanillaAjaxWithoutjQuery-version", "1.0");
    xhr.send();
  });
})();

We followed the five steps to implement AJAX described in the previous sections:

Create an xhr instance of the XMLHttpRequest object using the XMLHttpRequest() constructor.
Use the open() method of the XMLHttpRequest object to specify the kind of data being requested. It takes three arguments:
Create a callback function to process the response. XHR has two properties used to indicate a response from the server:
Finally, all we're left to do is send the request. But before we do that, we need to make sure we set the _ request headers _ accordingly to indicate that our request is indeed an AJAX request.

Tie it all together

Let's tit it all together - frontend and backend. When we start the server by running npm run start, the server returns the rendered index.html page to the browser. Since the index.html file references the ajax.js script, the browser issues another request to the server to get this file. Finally, when the user clicks the Retrieve button, the server returns the "Hello World!" message. This workflow can be observed via the server's terminal logger as shown below.

Serving index.html
Serving ajax.js
Processing AJAX request

AJAX Implementations

Below are some examples of AJAX implementations for your references:

Auto-suggestion: Almost all search engines nowadays have this feature implemented. However, it's not limited to just search engines. In fact, it can be used in any text box in web forms.
Infinite scrolling: Infinite scrolling is also implemented using AJAX. As the user scrolls downwards, more contents are fetched from the server and displayed on the page.
Self-Updating Stock Ticker: Most trading sites have the stock tickers updated with the latest rates on the market automatically without reloading the entire page.
Form Validation: For example, when a user enters an email address to sign up for an account, the user's input is sent to the database to check if it's an existing account. Depending on the server's response, the user is either allowed to proceed to the next step or an error is displayed on the screen. This whole process can be done asynchronously without reloading the whole page.

AJAX Demystified - Why Do We Need AJAX?

Thanh Truong — Wed, 22 Dec 2021 10:59:55 +0000

This two-part series came into existence after I started the JavaScript Client-side Frameworks series. While I was researching materials for my posts, I can't tell you how many times I came across the AJAX acronym. A quick Google search gave me some confirmations that I somewhat understand what AJAX does, but the more I dug, the more I realized that it's way more complicated than I thought, yet it's one of the building blocks in all JS frameworks. I was quickly convinced that understanding AJAX is fundamental to our understanding of modern JS frameworks. In this first part of this series, we will explore why we need AJAX in the first place.

First off, don't let the cover image fool you. Yes, we're talking about AJAX - the technology, not Ajax - the Greek hero.😜

Asynchronous JavaScript and XML (AJAX) is a collection of interrelated web development techniques - we can think of AJAX as design patterns - that are used for asynchronous web applications. AJAX allows web pages to send and receive data asynchronously in the background, without blocking the user from interacting with the web page while the request is being processed by the backend server.

The classic web app model was built around the notion of pages. A document is displayed to the user, containing lists of links and form elements that allow them to drill down to further documents. Most user actions in the interface trigger an HTTP request back to a web server. The server does some processing before returning a new HTML page to the client. While the server is doing its thing, the user has to wait. This server-side web architecture models the transition between pages as state transition diagrams and the site itself as a collection of pages.

It may be hard to comprehend the disadvantages of such an approach in traditional web app development since we are so used to the fast and responsive web apps as we know them today. So you will have to think of this in the context of how the Internet was being used in the years 2000's.

Before we get into the WHY behind AJAX, there are a few concepts that we need to understand first. So, let's cover these prerequisites.

Sovereign vs. Transient Applications

Software usability expert Alan Cooper has written about usage patterns and defines four distinct categories of software we use in our daily life: sovereign, transient, daemonic, and parasitic. For the purpose of this article, we will only focus on the first two usage modes: sovereign and transient.

Transient Applications A transient application might be used every day, but only in short bursts and usually as a secondary activity. When users are using these applications, they have already stepped out of their regular flow of work, and so a certain amount of clunkiness is acceptable. A calculator is a transient application, which is a type of helper program that is used for a specific task and then quickly closed again.
Sovereign Applications A sovereign application, in contrast, must cope with the user's full attention for several hours at a time. A good interface for a sovereign application must support the users _ invisibly _, without breaking their concentration on the task at hand. Microsoft Word, Excel, and Photoshop are all examples of sovereign applications.

Why is this relevant to AJAX anyway? 🤔 Valid question!😜 It's quite relevant, actually.

In the late 90s to early 2000s, the classic and dominant page-based web pages were only good enough for _ transient _ use. The browser itself is a _ sovereign _ application that is typically used for hours on end, but the web pages were mostly _ transient _ in their nature. In the early days of the Internet, users typically visited a specific website to check the weather, news, other information and then left. Desktop applications were dominant at the time when it comes to more sophisticated software that was created to solve business problems.

_ "Why couldn't we convert existing desktop applications into web applications instead?" _ is the next logical question one may ask.🤔 As a matter of fact, that was on web developers' wish list. One of the advantages of web applications is that it allows collaboration , i.e. resource sharing between team members, and flexibility , i.e. users can access applications from any computer with a browser and not have to worry about data backup. But to get there, there were a few challenges that needed to be solved first.

The challenges lie in the way users interact with existing desktop applications, which were mostly _ sovereign applications. _ With the traditional server-rendered web pages, When a user visits a web page, there is normally a small lag between when a button or a link is clicked (I'll explain where this lag in time is coming from in the next section) because a round trip to the server is needed, and the whole page needs to be redrawn.

If it's a typical weather site, the small lag doesn't bother the user much since the task itself - checking the weather forecast - is a transient task that the user doesn't have to endure for a long period of time. However, if it's an application that is typically used for a few hours at a time, i.e. a sovereign application. , it would drive the user nuts. How would you feel if there was a half of a second lag in Microsoft Word every time you press a button?😫 It would get extremely frustrating, wouldn't it? So until this problem was solved, web developers back then accepted their fate and designed their websites to be used as transient applications instead.

Now that you understand the challenges that web developers were trying to solve. Before we move on to how AJAX delivers the solution, let's first try to explore where the time lag is coming from.

Local vs. Remote Procedure Calls

Why did desktop applications have the _ richness _ and _ responsiveness _ that seemed to lack in the classic web applications? In order to understand where the time lag presented in a typical web application is coming from, we need to understand the differences between local and remote procedure calls.

In _ local procedure calls _, when a _ non-networked _ piece of code is compiled or interpreted, the various methods and functions are coded as instructions stored in the same _ local memory _ as the _ data _ on which the _ methods _ operate. Thus, passing data to a method and returning a result is pretty straightforward. Local procedures are widely used in desktop applications since the logic and data model are both executed in a _ closed environment _. Let's use an Excel desktop application as an example, a spreadsheet sits on its own little pile of data, stored locally in memory and on the local file system.

In contrast with a typical web page, in which a web browser has to contact the webserver sitting somewhere else (could be on the other side of the world) to request the pages that the user is trying to access. In _ remote procedure calls _, a lot of computation is going on "under the hood" at both ends of a network connection in order to send and receive data:

Encode and serialize (convert into a linear set of bytes) the request from the caller.
Pass the serialized data to the HTTP application protocol
The data packet is then sent across the physical transport (cable, wireless connection, etc.)
The remote machine receives the data and starts decoding and deserializing it before executing the requested procedure on the received data.
The response is then encoded, serialized before sending over the wire back to the caller.

Network Latency

The grand vision of the Internet age is that all computers in the world interconnect as one very large computing resource. The idea was that _ remote _ and _ local procedure calls _ become indistinguishable, and issuers of the calls are no longer even aware of which physical machines they are working on. Unfortunately, communications over a network are expensive as remote and local procedures are not the same thing at all. As mentioned in the section above, communications over a network are slow and unreliable.

So, making a call over a network will never be as efficient as calling a local method in memory. I used to think that the physical journey along the wire is the most time-consuming process, but it's actually the computations under the hood that slow things down. Furthermore, the unreliability of the network, which is why lost packets of information need to be resent, only makes the matter worse. This delay, which is referred to as _ network latency _, is a common cause of delayed responsiveness between users' initiated actions and the page's responses.

HTTP

As mentioned above, the HTTP protocol is used to transport serialized data between the requester (browser) and the server.

Modern JavaScript provides a number of ways to send HTTP requests to remote servers. An HTTP request consists of a request by the browser, followed by a response from the server. An HTTP request is mostly composed of headers , with the body containing some data or parameters. Think of the headers as lines of an address written on an envelope and the body as the letter inside. The headers simply instruct the receiving party what to do with the letter contents. The response typically contains the HTML markup for the returning page.

Asynchronous Requests

As mentioned above, _ network latency _ is inherent in _ remote procedure calls _ and is the common cause of delayed responsiveness in web applications. In other words, we can't get rid of network latency. So how are we going to solve this problem then? 🤔

There was only one sane solution to the network latency problem: _ we must try to make the UI responses independent of network activity. _ But HOW?🤔

Asynchronous remote event handling comes to the rescue.🦸‍♂️ Fortunately, although a half a second delay, so to speak, each time the user clicks a button is not acceptable, a slight holding response to acknowledge the receipt of a request is often sufficient, as long as it is timely. Using an example from our physical world, when you make your morning coffee, you don't stand next to the coffee machine staring at it while waiting for it to brew, do you? So why are we doing that in our computer world?😉

Seriously, there should be no reason for the user to stare at the computer screen waiting for the newly requested web page to arrive. Let's use the Amazon website as an example. After adding a new item to my shopping basket, I should be able to browse other items on the site while the total cost for all items in my basket is being calculated, right?

With any UI, it's a well-established practice to spawn an asynchronous thread to handle any lengthy piece of computation and let it run in the background while the user gets on with other tasks. The user is necessarily blocked while that thread is _ launched, _ but this can be done in an acceptably short span of time. So, _ asynchronous remote event handling _ is not a new concept, and so far, it seems like we've already figured out the solution to our problem, which is _ asynchronously processing remote calls _. So what is so revolutionary about AJAX anyway?

Here is the catch!😜 Unfortunately for us web developers, HTTP is a request-response protocol. That is, the client issues a request for a document, and the server responds, either by delivering the document, saying that it can't find it, offering an alternative location, or telling the client to use its cached copy, etc. In other words, a request-response protocol is one-way. The client can make contact with the server, but the server cannot initiate communication with the client. As a matter of fact, the server doesn't remember the client from one request to the next, and it shouldn't have to. Okay, so where is the catch again?😁

So we said earlier that the key feature of our asynchronous callback solution is that the client gets notified twice: once when the thread is spawned and again when the thread is completed. How can the server notify the client that it has completed the request if HTTP protocol is a _ one-way communication? _ Aha!😜 But don't worry! That's what AJAX is for.😎

Now that you understand AJAX's mission, we are now ready to learn what AJAX really is. See you in the next part of this series! 👋

Asynchronous JavaScript (JS) Demystified

Thanh Truong — Wed, 15 Dec 2021 11:13:13 +0000

In this article, we will look under the hood to understand how asynchronous function is executed in JavaScript. We will explore concepts such as call stack, event loop, and message queue which are the key players behind asynchronous JS.

JavaScript is a single-threaded programming language - _a language with one single call stack and a single memory heap. _ What it means is that the JavaScript engine can only process one statement at a time in a single thread.

Although single-threaded languages offer some levels of simplicity since developers don't have to worry about concurrency, applications coded in single-threaded programming languages face challenges with long operations (such as network access) blocking the main thread. For example, imagine what it feels like when the web page is unresponsive even just for a few seconds after you clicked a button to request some data from the API. It would be annoying, would it?😉

That's where asynchronous JavaScript comes into play. Using asynchronous JavaScript (callbacks, promises, async/await), we can perform long network requests without blocking the main thread. But how? 🤔

Before we dive into asynchronous JS, let's first try to understand how its counterpart, synchronous code, gets executed inside the JS engine by looking at some simple codes.

How is synchronous code executed by the JS engine?

const second = () => {
  console.log('Hello there!');
}
const first = () => {
  console.log('Hi there!');
  second();
  console.log('The End');
}
first();

When the above code executes, the following outputs are logged in the console:

Hi there!
Hello there!
The End

To understand how the above code executes inside the JS engine, we have to understand the concept of execution context and the call stack.

Execution Context

An execution context is an abstract concept of an environment where the JS code is evaluated and executed. Whenever any code is run in JS, it's run inside an execution context.

By _ environment, _ we mean the value of this, variables, objects, and functions JS code has access to at a particular time.

There are three types of execution context in JS:

Global execution context: This is the default execution context in which JS code starts its execution when the file first loads in the browser. All global code, i.e. code that is not inside any function or object, is executed inside the global execution context.
Functional execution context: This is the execution context created by the JS engine whenever it finds a function call. Each function has its own execution context. Functional execution context has access to all the code of the global execution context but not vice versa.
Eval: Execution context inside eval function.

Call Stack

The call stack is a stack with a Last In First Out (LIFO) structure, which is used to store all the execution context created during code execution. The LIFO structure implies that the items can be added or removed from the top of the stack only. Let's use the example code above to illustrate what this really means.

When the code is executed, a global execution context is created represented by the main() method and pushed to the top of the call stack.
When a call to first() is encountered, it's pushed to the top of the stack.
Since console.log('Hi there!') is called from within the first() method, it's pushed to the top of the stack, and the "Hi there!" message is logged to the console. Once finished, it's popped off the stack.
Next, we call second(), so the second() function is pushed to the top of the stack.
Since second() calls console.log('Hello there!'), it's pushed to the top of the stack, and the "Hello there!" message is logged to the console. Once finished, it's popped off the stack followed by the second() function.
The last thing that remains in the first() function is the call to console.log('The End'), so it's pushed to the top of the stack, and the "The End" message is logged to the console. Once finished, it's popped off the stack.
Since there is nothing left inside the first() function, it's popped off the stack followed by main().

How is asynchronous code executed by the JS engine?

Now that we know how synchronous code executes, let's look at how asynchronous code executes.

As mentioned above, network requests take time. Depending upon the situation, the server might take some time to process the request while blocking the main thread making the web page unresponsive. The solution to this problem is to use asynchronous callbacks to make out code non-blocking. An example of an asynchronous callback function is shown below. Here, we used the setTimeout method (available from the Web API in browsers) to simulate a network request.

const networkRequest = () => {
  setTimeout(() => {
    console.log('Async Code');
  }, 2000);
};

console.log('Hello World');
networkRequest();
console.log('The End');

When the above code executes, the following messages are logged to the console:

Hello World
The End
Async Code

So, it seems that the call to networkRequest() did not block our thread after all. But we said earlier, that JavaScript is a single-threaded language, so is that even possible?🤔 To understand how this code is executed, we need to understand a few more concepts such as event loop and message/task queue.

JavaScript has a concurrency model based on event loop, which is responsible for executing the code, collecting and processing events, and executing queue sub-tasks.

Message Queue

A JavaScript runtime uses a message queue, which is a list of messages to be processed. Each message has an associated _ function _ that gets called in order to handle the message.

At some point during the event loop when the call stack is empty , the runtime starts handling the messages on the queue, starting with the oldest one. The message is removed from the queue and its corresponding function is called. This process repeats every time the event loop detects that the call stack is empty indicating the next message in the queue (if available) can be processed.

ES6 introduced the concept of job queue/micro-task queue, which is used by Promises in JS. The difference between the message queue and the job queue is that the job queue has a higher priority than the message queue, which means that promise jobs inside the job queue/micro-task queue will be executed before the callbacks inside the message queue.

Event Loop

The event loop got its name because of how it's usually implemented, which usually resembles:

while (queue.waitForMessage()) {
  queue.processNextMessage()
}

The job of the event loop is to look into the call stack and determine if the call stack is empty or not. If it's empty, it looks into the message queue to see if there's any pending callback waiting to be executed. Each message is processed completely before another message is processed.

In web browsers, messages are added anytime an event occurs and there is an event listener attached to it.

The event loop, message queue, and web APIs are not part of the JS engine. They are part of the browser's JS runtime environment Node.js runtime environment in the case of Nodejs.

With all of that out of the way, let's revisit our example of asynchronous callback and dissect it.

When the above code loads in the browser, the console.log('Hello World') is pushed to the stack, and the "Hello World" message is logged to the console. Once finished, it's popped off the stack.
Next, the networkRequest() is called, so it's pushed to the top of the stack. Since setTimeout() is called from within networkRequest(), it's pushed to the top of the stack. This method takes two arguments: a time in ms and a callback function that is to be executed once the timer expires. The setTimeout() method starts a timer of 2s in the web API environment.
At this point, the setTimeout() has finished and is popped off the stack. Next, the console.log('The End') is pushed to the stack, and the "The End" message is logged to the console, after which the function is popped off the stack.
Meanwhile, the timer has expired, and the callback is pushed to the message queue. At this point, since the call stack is empty, the event loop pushes the callback in the queue to the top of the call stack. Since the callback calls console.log('Async Code'), it's pushed to the top of the stack. The "Async Code" message is logged to the console before it's popped off the stack.
Since the callback is finished, it's also popped off the stack and the program finally finishes.

That's it. I hope that by now, asynchronous function call in JS is no longer a mystery to you.😉

Tutorial: Build a JAMStack Blog with Gatsby and Ghost - Part 1

Thanh Truong — Wed, 08 Dec 2021 10:55:08 +0000

In this first part of the tutorial, we will spin up our blog in a local development to get it ready for deployment into the cloud in the next part of the tutorial.

1. Set up Gatsby Ghost Starter project

We will build a custom front-end for our site with Gatsby.js. Gatsby.js can be defined as a static site generator that uses React.js (for the client-side) and GraphQL (to access data) to build reliable and faster website. Static site generators can be defined as software applications that generates HTML pages from templates or components.

One of the best ways to start a new Gatsby site is with a Gatsby Starter. Gatsby starter libraries are open-source Gatby sites maintained by Gatsby and the Gatsby community. Ranging from minimal boilerplate to full proofs-of-concept, Gatsby starters enable you to dive into your nect Gatsby project faster.

The official Gatsby Starter Ghost project comes preconfigured with the gatsby-source-ghost plugin, which pulls data from the Ghost Public API (more details on that later), and a clone of the default Ghost template so that we can get started quickly. Gatsby plugins are Node.js packages that implement Gatsby APIs. Plugins allow you to modularize your site customization into site-specific functionality. For example, you can use plugins to add external data or content (CMS, REST API, etc.) to your Gatsby GraphQL data, transform data from other format (Markdown, YAML, etc.) to JSON objects, add third-party services (Google Analytics) to your site, and much more.

Now that we got some of the high-level concepts covered, let's go ahead and clone the gatsby-starter-ghost project from GitHub.

First, you will need to create a private repository in your GitHub account. Once that's done, we can start cloning the project.

git clone https://github.com/TryGhost/gatsby-starter-ghost.git

cd gatsby-starter-ghost

# Install all packages
yarn install

# Start gatsby project
yarn dev

Once ready, we should be able to access our site at http://localhost:8000/.

By default, our starter project is fetching data from the public Ghost Blog API @ https://gatsby.ghost.io/. The API endpoints configuration is the .ghost.json file located at the project root directory. Currently, our .ghost.json looks like the following:

//.ghost.json

{
  "development": {
    "apiUrl": "https://ghost-v4-server.herokuapp.com",
    "contentApiKey": "8b7f72f624963ccbe84f28777a"
  },
  "production": {
    "apiUrl": "https://ghost-v4-server.herokuapp.com",
    "contentApiKey": "8b7f72f624963ccbe84f28777a"
  }
}

What we need to do next is set up our own Ghost CMS API where we will be storing all of our site content including images, videos, blog posts, etc.

2. Set up Ghost Content API

First, we will set up a local instance of our Ghost API just for our own understanding of how it works. Since our goal is to eventually deploy our Ghost API to Heroku , we will not be using this local instance for deployment. More details on that later.

Install Ghost locally

Install Ghost CLI:

yarn global add ghost-cli

Create a new directory and initialize a new Ghost project:

mkdir ghost-admin && cd ghost-admin
ghost install local

Once finished installing, you should now have an instance of Ghost running locally at http://localhost:2368/. You can verify that your Ghost instance is running by running the ghost status command from your ghost-admin project director. You should see the following:

NOTE: When Ghost is running, you should see NodeJS running in a separate Windows command, you will need to keep this open in order for Ghost to run. You can also use the ghost start or ghost stop commands to manually start and stop Ghost. Reference Ghost documentation for more information.

Configure Gatsby to use the new local Ghost API instance

To test your Ghost API, navigate to http://localhost:2368/. You should see the default Casper theme that comes with every Ghost installation. Ghost ships with a default front-end theme layer built with Handlebars. However, based on its flexible architecture, it can also be used as a headless CMS with third party front-end frameworks, which is exactly what we're going to do for our site. The image below demonstrates the architecture for our stack. We will be using Gatsby as the static site generator and Ghost Admin as the client app to allow us to manage our blog content.

To access the Ghost Admin client, navigate to http://localhost:2368/ghost. Follow the instructions to create a user account.

Under Intergration → Custom Integrations → Gatsby Content API , copy and paste both the API URL and Content API Key into the .ghost.json file in your Gatsby project. You only need to update the "development" config for now since we're still running the project locally. Your .ghost.json file should now look like the following:

{
  "development": {
    "apiUrl": "http://localhost:2368",
    "contentApiKey": "c16cb3fb2cd6f36dea2012564d"
  },
  "production": {
    "apiUrl": "https://gatsby.ghost.io",
    "contentApiKey": "9cc5c67c358edfdd81455149d0"
  }
}

Before we test the new API, let's create a new post from Ghost Admin and see if it will be updated on our front-end site.

Test the local Ghost API

Create and publish a new post from within the Ghost Admin client. Refresh your Gatsby site at http://localhost:8000/ and you should see your new post on the home page. 🎉

By now, you should have both the front-end and back-end of your blog running locally. In the next tutorial, we will deploy both the front-end and back-end to the Cloud. See you there! 👋

Photo Credits:

Man vector created by vectorjuice - www.freepik.com

How I Created My Blog Using JAMStack

Thanh Truong — Wed, 01 Dec 2021 14:34:28 +0000

In the first two articles of this series, we explored JAMStack (what it is, its components and architecture, available tools for JAMStack development, its pros and cons, and comparison between WordPress and JAMStack). If you haven't read it yet, I highly suggest you give it a read first.

For the remainder of this series, I'll walk you through the process of how I created my personal blog with JAMStack - a modern web development practice. But before we jump into our first tutorial, let's review the entire process at the high level and some "gotchas" and challenges I discovered along the way and how I overcame those challenges.😎

Why JAMStack?

My decision to set up my own blog as well as my decision to use JAMStack came a long way. I originally started blogging on DEV Community. DEV is really a great community, don't get me wrong, but I was in need of a blogging platform that would offer some amount of flexibility and customization of how my blog should look like. Also, I thought it would be great to start growing my personal "brand", and having your own blog with your own domain name would be a good starting point.

So I set out to look for a way to cross-post content between my blog on DEV Community and my to-be-created blog with its own domain name. I quickly noticed that DEV actually has an extension that would allow you to generate a personal blog from your DEV Community posts using Stackbit. Great! "This is exactly what I need", I said to myself. I then followed some tutorials trying to set up my own blog on Stackbit.👩‍💻

However, I quickly ran into issues migrating my posts from DEV Community into Stackbit. I emailed Stackbit's support team and was told that they were aware of the issue and have been working on fixing it. Bummer!😞

I could either wait until Stackbit fixes the issue or find another solution. I decided to find another solution simply because I just don't like the fact that I have to rely on someone else to fix the problem, and that's just the nature of using a site builder like Stackbit, which is aimed toward less technical users.

So my mission now is to find another solution, which I will explain in more detail in the next section. However, I think it's important to acknowledge the fact that my decision to use JAMStack as well as what tools to use to build my JAMStack app started with Stackbit and is heavily influenced by it. After all, I learned about Netlify, Gatsby, and even Ghost CMS from my initial attempt with Stackbit because it uses JAMStack.

JAMStack components recap

Let's quickly recap all the components of our JAMStack blog and the technologies that we will be using for each of the components.

Static site generator

All websites, doesn't matter what they are, fundamentally consists of HTML, CSS, and JavaScript. It doesn't matter what tools or frameworks you use to create your website, the final result needs to be compiled into these file formats in order for the browser to understand and display on the screen. Our blog is no exception.

There are two sources of HTML for our blog: the static HTML contents (site header, logo, layout, footer, etc.) and the dynamic HTML contents from the actual blog posts. We need to somehow combine both of these static and dynamic HTML sources into a single HTML file at every single build of our app. Static site generator to the rescue!🦸‍♂️

A static site generator is a software application that creates HTML pages from templates or components and a given content source during a build process. There are many static site generators available out there. We will be using Gatsby for our blog.

During a build, Gatsby loads JSON data from GraphQL and merges it with components to create HTML pages. These generated pages are then deployed to a web server. When the server receives a request from a browser, it responds with rendered HTML.

So the question that needs to be answered now is where does the GraphQL data come from?🤔. I'm glad you asked because that's exactly what we're going to explore in the next section.😉
Content Management System (CMS)

Dynamic contents for JAMStack sites (in our case, these are our blog posts) can be controlled via a CMS, typically known as headless CMS. Once a change is made in CMS (a post is published/added/edited/deleted), a new build of our site will be triggered and deployed as static assets. Similar to static site generators, there are many options for CMS available out there, but we will be using Ghost CMS for our blog.

As mentioned above, after a change is made to either our static HTML from Gatsby or to our dynamic HTML from Ghost CMS , we will need to somehow trigger the deployment to the web server to rebuild and regenerate the HTML files. How are we going to do that?🤔 Again, glad you asked! Join me in the next section!😎
Deployment

The generated HTML pages need to be hosted on a web server somewhere in order to allow users from anywhere to access our blog. There are several services available, but we will be using Netlify for our blog.

I chose Netlify because it has an awesome free plan that comes with great features such as:

Now that you understand all these components at a high level, I'll share with you some of the challenges that I encountered as I was setting up my blog.

Gatsby static site generator

In order to get my site up and running as quickly as possible, I decided to use one of Gatsby's starter libraries. Starters are open-source Gatsby sites maintained by Gatsby that enable users to dive into their next Gatsby project with minimum effort. Starters range from minimal boilerplate to full proof of concept. Since we will be using Ghost as our content management system. It seems logical that the gatsby-starter-ghost is the best option for us.

Besides a few customizations to give the blog the look and feel of my personal brand, the following features were implemented/improved to suit my needs:

Added a Tags page that displays my posts grouped by their corresponding tags.
Added Google Analytics
Added Algolia Search
Added block code syntax highlight using highlight.js

Ghost CMS

Ghost offers Ghost(Pro) - a managed hosting service for Ghost that offers users the fastest way to get started on Ghost. It includes out-of-the-box features such as custom domain, custom themes, server maintenance and backups, CDN, etc. However, since I was looking for a low-cost option, I opted for a self-hosted instance.

Out of the box, Ghost comes with:

A core JSON API
An admin client app
A front-end theme layer using Handlebars templating languages

However, since I use Gatsby for the frontend theme layer, I had to modify a few things after installing Ghost. Ghost's Admin Client app has the page preview feature that only works if you use one of Ghost's themes. Therefore, I had to set up a proxy server with some URL redirect configuration in order to be able to preview my posts with my Gatsby theme from the Admin Client app. The page preview on the Branding setting page still doesn't work, but that didn't bother me much, so I didn't spend time fixing it. More on that later when we get to the tutorials.

Cloud hosting

As mentioned above, we will use Netlify to manage automatic build and deployment of our site. Basically, we will connect Netlify to our GitHub repo where we store our Gatsby code and configure it so that every time a change is pushed to the remote repo, a build is triggered in Netlify. In addition to that, we will integrate Netlify's build hook with Ghost so that every time a change is made in Ghost (you can configure what type of changes you want such as post added, post updated, global changes, etc.), a build in Netlify is automatically triggered.

Unless you're planning on hosting your Ghost server on your local machine, which you can if you want, you will need to pick a cloud platform ( AWS, Azure, Heroku, Digital Ocean, etc.) to host your server app. Since my goal is to come up with a low-cost solution, here is what I ended up using for my stack:

Use Heroku to host my Ghost server, which is essentially a Node.js app. I found this GitHub repo that can be used to deploy a Ghost server into Heroku with just a click of a button. However, this app is preconfigured to use JawsDB as the MySQL database where all data for our posts are stored. JawsDB does have a free plan , but it only comes with 5MB of storage. The next price tier is $10/month for which you'll get 1GB of data. I needed to come up with a lower-cost option for my data storage.
I ended up using AWS RDS for my MySQL database. If you sign up for a free tier account with AWS, you're eligible for 750 hours of RDS instances and 20GB of storage. Even if after you have used up your free tier credits, the cost to host a MySQL database on Amazon RDS is still much lower compared to JawsDB. Therefore, I needed to modify the code in the GitHub repo to re-configure the add-ons. More on that later!

As mentioned above, in order to fix the site preview issue in Ghost, I had to create a proxy server, which is essentially a Node.js app, which is also hosted on Heroku.

My blogging workflow

With this setup, here is my typical workflow just so that you can understand what it looks like:

Edit site template
- Edit and test site locally
- Commit and push changes to GitHub
- Netlify automatically builds and deploys the site
Publish new content
- Add/remove/edit posts locally and publish from the Ghost Admin Client app
- Netlify automatically builds and deploys the site based on change detection settings in Netlify's build hook. Below is an image, taken from Ghost's website, just to give you an idea of what the UI for the Admin Client app looks like.

That's it. Sounds simple, huh?😎 Well, if you like what you hear and are still interested, join me in the next part of this series where I will be sharing tutorials on how I set up my site. See you there! 👋

Photo Credits:

ASP.NET Core: What Is It?

Thanh Truong — Wed, 24 Nov 2021 13:00:00 +0000

In the first article of this series, we explored the high-level overview of the .NET platform. In this and probably the next few posts of this series, we will dive deep into the ASP.NET Core platform.

What is ASP?

ASP stands for Microsoft Active Server Pages , which is Microsoft's first server-side script engine that enabled dynamically-generated web pages. At the high level, ASP is one of the several technologies for developing Internet Information Service (IIS) Web applications.

IIS is a web server specific to the Microsoft .NET platform. on the Windows OS. IIS can be used to create web content in a variety of formats: static files, scripts, compiled DLLs, and compiled EXEs. The _ IIS development technologies _ simply provide a way to perform dynamic operations that eventually build HTML output that IIS sends in response to client requests.

In the context of IIS, a web server is essentially a software that controls how web users access hosted files.

ASP is now obsolete and replaced with ASP.NET.

What is ASP.NET Core?

Before we dive in, here is the picture of the entire .NET ecosystem that I used in the previous post. In this and future few articles, we will be focusing on the ASP.NET Core platform. If you are anything like me who find it confusing and convoluted with all the technical jargon floating around (.NET, .NET Core, ASP.NET, ASP.NET Core 😵), pictures speak a thousand words. 😉

As mentioned in the previous article, Microsoft created ASP.NET Core as a lightweight platform that runs on Windows, Linux, and macOS. .NET Core shares many of the same APIs as .NET Framework, except for it's smaller and only implements a subset of the features available in the .NET Framework.

Fundamentally, an ASP.NET Core Web app is, at its core, a console app that reads and writes information to port. The .NET Core platform provides a base console application model that can be run cross-platform using the command line interface. Adding a web server library converts it into an ASP.NET Core web app. And this is exactly what Microsoft did as shown in the image below. Additional features, such as configuration and logging are added by way of additional libraries.

Basically, we write a .NET Core console app that starts up an instance of an ASP.NET Core web server. By default, Microsoft provides Kestrel as the cross-platform web server. Our web application logic is run by Kestrel, and libraries are used to enable additional features as needed (logging, HTML generation).

What type of applications can we build with ASP.NET Core?

With .NET Core , you can write code for cross-platform ASP.NET Web apps, cross-platform console apps, cross-platform libraries and frameworks, and Universal Windows Platform (UWP) apps. But since we're only focusing on ASP.NET Core, let's see what type of web apps we can build using this framework.

Web UI

ASP.NET Core is a complete UI framework. There are three general approaches to building modern web UI with ASP.NET Core:
Web API

ASP.NET Core supports creating RESTful services, also known as web APIs, using C#. To handle requests, a web API uses _ controllers _ - classes that derive from ControllerBase.
Real-time apps

ASP.NET Core SignalR is an open-source library that simplifies adding real-time web functionality to apps. Real-time web functionality enables server-side code to push content to clients instantly (gaming, social networks, voting, collaborative apps, maps, etc.).
Remote Procedure Call (RPC)

gRPC , an open-source Remote Procedure Call framework, can be hosted on ASP.NET Core. The idea behind RPC is that a computer program can call and execute a procedure (subroutine or service) on a remote system just like it would call a local subroutine, but the network communication details are hidden from the user.

In the next two articles, we will dive deep into all the components of a typical ASP.NET Core application using a simple web UI application. See you there!👋

JAMStack vs. WordPress: Which One Is Better?

Thanh Truong — Wed, 17 Nov 2021 10:27:00 +0000

In the previous blog post, we learned what JAMStack is, its components, available tools for building a JAMStack app, and its benefits and limitations.

In this article, we will explore the core philosophy behind JAMStack architecture by comparing it to the well-known WordPress architecture.

How did JAMStack come about?

Everything created was created to solve a problem. To understand how JAMStack comes into existence, we first need to understand what problems it was trying to solve.

Prior to JAMStack, WordPress ruled the world of content management. First released in 2004, WordPress has shifted from purely a blogging platform to a multi-purpose website creator that is supported by a huge ecosystem of themes and plugins. Since it's possible to get a WordPress site up and running inexpensively and with no coding knowledge, it has become the defacto choice for many website owners. However, being overloaded with add-ons, scripts, and a lot of other stuff results in some pain points such as slow performance, higher cost, security concerns, and undesirable experiences for developers. As a result, developers have been looking for an alternative to solve these issues.

Then, JAMStack came along. JAMStack is all about fast and secure sites and apps delivered by pre-rendering files and serving them directly from a CDN, removing the requirement to manage or run web servers.

How does a WordPress website work?

To understand the differences between WordPress and JAMStack architecture, we will use the analogy of news delivery.

Imagine for a second that the only way for people to know what's happening in the world is to go to the nearby news kiosk and ask to read the latest news.

The person selling newspapers at the kiosk has no ways to know the latest news, so he passes the request on the a back room full of telephone operators. When an operator becomes available, they will take the request and phone a long list of news agencies, ask for the latest news and then write the results as bullet points on a piece of paper.

The operator will then pass his rough notes on to a scribbler who will write the final copy to a beautiful sheet of paper, arrange them in a specific layout and add a few bits and pieces such as the kiosk branding and contact information. Finally, the attendant takes the finished paper and serves it to a happy customer.

The entire process repeats for every person that arrives at the kiosk. That is essentially how dynamic website works.

When a visitor gets to a website (the kiosk) expecting the latest content (the news), a _ server-side script _ (the operators) will query one or multiple _ databases _ (news agencies) to get the content. It then passes the results to a _ templating engine _ (the scribbler) who wil format and arrange everything properly and generate an _ HTML _ file (the finished newspaper) for the user to consume.

Fundamentally, dynamic websites like those created with WordPress are built for each visitor. Of course, you can cache the website, but the system is designed in a way that is complicated and cumbersome.

How does a JAMStack app work?

A JAMStack site shifts the heavy load from the moment visitors request the content to change into content that is already there waiting for the visitors.

Going back to our kiosk analogy earlier, the new agencies would call the kiosk whenever something newsworthy happens. The kiosk operators and scribblers will compile, format, and style the stories and produce a finished newspaper immediately, even though nobody ordered one yet.

They would print out a considerable number of copies and pile them up by the storefront. When customers arrive, there's no need to wait for an operator to become available, place the phone call, pass the results to the scribbler, and wait for the final product. The newspaper is already there, waiting in a pile for the customers to read.

And this is how JAMStack websites work. They take the content, typically stored in flat files rather than databases or a clunkly webserver, apply it against layouts or templates, and generate a structure of purely static HTML files. These static HTML files are ready to be delivered to the users.

In terms of content management system (CMS), the difference between JAMStack and WordPress is that in JAMStack, CMS is used only for "content management tasks", not templating and frontend content generation, making it easier for content managers and editors (those that don't have a technical background of the server-side of things, HTML files, or web development in general) to contribute to the content of the website or the web application.

That's it for this week. In the next article of this series, I will give you an overview of how I set up my JAMStack blog before we dive into tutorials. Stay tuned!

Client-side JavaScript (JS) Frameworks - Part 1

Thanh Truong — Wed, 10 Nov 2021 18:16:15 +0000

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.

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.🤿

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.

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.
Styling

Each framework offers a way to define styles for components.
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.
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.
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.
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:

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