Forem: Sapinder Singh

The Easiest Introduction To CSS

Sapinder Singh — Wed, 17 Aug 2022 10:07:00 +0000

Here I'm back with the next topic in my Web Development Intro series, where I introduce to you the fundamentals of web development; and clarify some of the core concepts that ain't easy enough for beginners to grasp.

So in this post, we're going to learn about CSS, which stands for Cascading Style Sheets. Cascading Style Sheets (CSS) is a stylesheet language used to describe the presentation of a document
written in HTML or XML. Basically, it describes the styling properties of elements inside a document.

Think of a web page like a room in your house. If you never painted the walls, windows and doors of that room, you would find it to be too boring to sit in. However, if you paint and decorate the room, the same room will attract you much more than before. This is true for web pages too. A web page without CSS is too boring (or even hard) to be able to convey information to the reader. And it's not just about colors; it also defines the layouts, positions, transitions, animations, and much more.

The Way CSS Works

The name Cascading Style Sheets alone describes itself really well. The styles here are applied from top to bottom in the order they are defined, just like a cascading waterfall. Any repeated style would override its previous corresponding values, as in the following example.

button {
  color: white;
}
/* The the style below will override the value 'white' for property 'color' */
button {
  color: black;
}

These styles come from different origins, also known as stylesheets. There're mainly two types of stylesheets that are applied to a web page- User Agent Stylesheets and Author Stylesheets. Let's discuss them individually:

User Agent Stylesheets - These stylesheets are applied by the browsers to give default styles to a document. The styles often differ slightly across different browsers. For example, the button below has no custom styles, and uses the default styles from user agent stylesheets used by your current browser.

Try opening this page in a different browser, and you would see this button with slightly different styles.

Author Stylesheets - These are the stylesheets that are used by web developers to apply custom styles to a document. The author stylesheets have higher preference over user agent stylesheets. For example, the following button uses the custom styles that I provided, which overrode the styles from user agent stylesheet.

How Do We Actually Use CSS In A Web Page?

We have 3 ways to use CSS in a web page. Let's take a look at each of them:

Internal CSS - We can declare the styles using the <style> tag anywhere inside the HTML document but the thing to note is that these styles are not applied to elements that come before the <style> tag because those elements will get parsed before this tag while rendering the web page. For this reason, this tag is often declared before any other element inside the body.

<body>
  <style>
    button {
      color: black;
    }
  </style>
</body>

Inline CSS - We can also declare style for an element by providing the style attribute to it. Inline styles have the highest preference over any other styles. We'll actually discuss about something known as specificity in the next article. Here's an example of inline style:

<body style="background-color: aliceblue;">
  Hi! I'm a button
</body>

External CSS - The last and most efficient way to declare CSS in large projects is using external .css files. We declare the styles in different .css files, and link them in the HTML document using link tag. Below is an example:

/* index.css */
body {
  background-color: aliceblue;
}

<!-- index.html -->
<head>
  <link rel="stylesheet" href="./css/index.css" type="text/css">
</head>

The text between / and / is called a comment in css. The same goes for  in html. A comment is made just for the reader to understand the code better, and it is ignored by the compiler. Here're some of the best practices that you should adopt while writing comments in any language.

Elements of Style Declaration

So, now that we can link our stylesheets to HTML document, it's time to know how to actually write these stylesheets. Any style declaration consists of 2 parts- selector(s) and property-value pairs. Each pair of property and value must be separated by a semicolon at the end of the line. You've already seen property-value pairs; hence, I want you to focus on just the
selectors for now.

Selectors

In order to apply any styles to an HTML element, we need to use a selector that would select the target element. A selector is kind of an identifier that tells the browser what HTML element are the styles for. The simplest type of selector is the type selector, i.e., the name of the element itself. We can, in fact, use a list of selectors if we want to declare the same styles for multiple elements.
An example could be-

/* The font-size will 16px for each of button, a, input and small elements  */
button, a, input, small {
  font-size: 16px;
}

Classes And IDs

Then we have class and id selectors. If you're unfamiliar with class and id attributes in HTML- the values given to class and id attributes provide us a way to identify an HTML element when making a JavaScript query, or specifying CSS styles for that element.

The only major difference between class and id attributes is that an id is unique to an element, whereas multiple classes can be assigned to multiple elements; you can think of it as a many-to-many relationship. 😅 For more details, you can read this article by css-tricks.

In most cases, using class selectors is preferred than using id selectors for a reason that we would discuss in the next article. A class selector must begin with a . character; for example-

/* This style would be applied to any elements that have the `txt` class assigned to them. */
.txt {
  color: red;
  text-align: center;
}

An id selector must begin with a # character; for example-

/* This style would be applied the element that has the `btn` id assigned to it. */
#btn {
    color: red;
    text-align: center;
}

Attribute Selectors And Combinators

Now come the attribute selectors, which basically select the elements that have the specified attributes in their HTML. HTML attributes can be in the form key="value" or just key depending on the type of attribute. For example:

/* this style will apply to anchors pointing to "https://developer.mozilla.org" */
a[href="https://developer.mozilla.org"] {
    text-decoration: underline;
}

/* this style will apply to only those buttons that have the `btn` class and have the `disabled` attribute. */
.btn[disabled] {
    background-color: grey;
}

Next, we have combinators, which are used to target specific elements based on their relationship to the surrounding elements. Take a look at the following snippet:

/* 1. Descendant Combinator */
body p {}

/* 2. Child Combinator */
body > p {}

/* 3. Adjacent Sibling Combinator */
h1 + p {}

/* 4. General Sibling Combinator */
h1 ~ p {}

These are the only four combinators available in CSS. Here's what each of the selectors are supposed to do in the snippet above:

Descendant Combinator - selects the any p element found inside the body element.
Child Combinator - selects only those p elements that are direct children of body. It doesn't select any other descendant p elements in the heirarchy.
Adjacent Sibling Combinator - selects a p element that is a sibling of h1 element, and comes right next to it, i.e., is an adjacent sibling.
General Sibling Combinator - selects any p element that is a sibling of an h1; it doesn't matter if it's adjacent to h1, or not.

Wrapping Up

Alright, so we now know how CSS works, how we can use stylesheets in HTML, and the type of selectors that we have in CSS. But there's a lot more to CSS than what we have just learned. Stay tuned to learn more!

If you enjoyed this post, feel free to follow me so you never miss any of my future posts!

See you in the next one! 😉

The HTML And The Web Pages

Sapinder Singh — Fri, 05 Aug 2022 00:01:00 +0000

In my earlier posts, The Static Fundamentals and The Dynamic Web, I made a overall introduction to the field of web development but in this post, we'll take a foundational but deeper look at HTML and web pages. So are you ready for the ride? Here we go! 🚀

To start off, let me say it straight- HTML stands for HyperText Markup Langauge, and it's not a programming language. (Oops... debate triggered 🤦.) We should, first of all, understand what exactly a markup language is.

A markup language is a way of encoding a document that, along with the text, incorporates labels or marks that contain additional information about the structure of the text or its presentation.

Simply put, a markup language is used to present a certain piece of data in a specific structure; may it be text, images, tables, etc. It can't be used to program any task, as opposed to what a programming language must be capable of. HTML, XML, SVG are all examples of a markup language.

Now getting back to HTML, the text you read on webpages isn't just plain text but a whole lot of information about that text is contained within itself, which tells about the structure of the text, and how it shall be presented. Consider the following sentence as an example-
My Name is Sapinder Singh. I'm a content creator.

The HTML code for the sentence above is-

<b>My Name is <i>Sapinder Singh</i>. I'm a <i>content creator</i>.</b>

As you can see, the tags <b>(for Bold) and <i>(for Italic) have their own way of presenting the data that they hold. Consider another example-
"I use VS Code for coding."

This text contains a link to another web page that you can navigate to by clicking on the highlighted text. And, this is basically what the "Hypertext" in HTML means. 🫢 Hypertext is any text that contains reference to some other text, which can be accessed by interacting with the Hyperlink
(which in this case is "VS Code"). So essentially, that's how we jump from one webpage to another.

The Syntactical Overview Of HTML

HTML is the building block of a webpage. It identifies different types of text and media with different tags, where each tag is in a pair of opening and closing tag. For example, if we want to write a paragraph of text, we would open the p tag as in <p>; insert the text; and then close the tag as in </p>. Then we have the attributes for each tag.

An attribute is just a property of a tag that holds a certain type of value. We define an attribute in the form name="value"; for example, look at the following snippet that defines a hyperlink named "VS Code". The a (anchor) tag is used define a hyperlink, and it requires the attribute href that
should point to a URL.

<a href="https://code.visualstudio.com">VS Code</a>

Now, there are some tags that don't need to be closed, and these are called self-closing tags. We don't provide any value but just the attributes
to these tags. The most basic example of a self-closing tag is <!Doctype html> that all HTML5 documents must begin with. It tells browsers to follow the most relevant specifications for rendering the page. You can find a brief & really nice explanation of Doctype on this page by MDN. Nonetheless, everything else in an HTML document goes inside the html tag; which is why it is called the root element of a webpage. This html tag comprises of two parts- head and body.

<!DOCTYPE html>
<html>
    <head></head>
    <body></body>
</html>

head

The head of a webpage is not directly visible to the user because it contains information not to be read by the user but the browser instead. It contains information such as:

title of the page that is used in browser's title bar and for search engine optimizations.
styles for styling the web page. These styles are written in CSS.
scripts for adding executable code to the web page. The sole purpose of scripts is to handle user interaction on web pages.
other meta tags for additional information such as character set, favicons, and other types of metadata.

Here's an example of what we usually see inside the head tag-

<head>
    <!-- defines the character set of the web page -->
    <meta name="charset" content="UTF-8">

    <!-- defines the title of the web page -->
    <title>The Theory Of HTML</title>

    <!-- links the styles.css file to the web page -->
    <link href="./styles.css" rel="stylesheet" type="text/css">

    <!-- links the fonts from Google Fonts -->
    <link 
        href="https://fonts.googleapis.com/css2?family=Poppins:ital,wght@0,400;0,600;0,700;0,800;1,600&display=swap" 
        rel="stylesheet preload">

    <!-- links the script.js file to the web page -->
    <script src="./script.js"></script>
</head>

body

The body tag represents the visible portion of a web page. Anything that you read, see or interact with on a web page is
placed inside the body of that page. Each type of content is represented by a specific tag; some of the common tags are:

p - represents a paragraph of text.
img - represents an image. It requires the src attribute that should contain the path to the image.
section - represents a section of a page.
h1 to h6 - represent the Heading-level for a section. The smallest acceptable heading level is <h6>.
button - represents a button.
form - represents a form for submitting some information.
input - represents an input field. It can accept different types of input depending the value of the type attribute.

You can read more about the different kinds of HTML elements on MDN's HTML reference page.

Fun Fact
If you omit, misspell, or misplace any of the tags in HTML, the browser would, silently, just render the page with incorrect or broken layout. Unlike a programming language, HTML won't throw any error; hence the proof of it being just a markup language. 😉

How A Web Page Is Rendered

Alright, now you know how we write HTML; but you must also know how a web page is actually rendered along with the sources that are linked to the HTML file. So, as soon as the HTML file is received by the client's browser, it starts creating what is called Document Object Model. The DOM is an inverted-tree like object model, the sole purpose of which is to represent the HTML document in memory and make it understandable to the browser's JavaScript engine. The root of this tree is the html element, which branches out into head and body, which further branch out into their children, and so on and so forth.

The DOM represents a document with a logical tree. Each branch of the tree ends in a node, and each node contains objects. DOM methods allow programmatic access to the tree. With them, you can change the document's structure, style, or content.
MDN

While building the DOM tree, the browser encounters several linked resources that were defined in the head of the document. Considering the snippet I provided in the head section, here's what happens next:

When it encounters the link for ./styles.css file, it pauses parsing the document; requests the the file from the server; parses the styles; and resumes the process.
Then it encounters a link for fonts; again, it requests the fonts first; parses them; and resumes the process.
Finally, it encounters the script tag that it downloads and executes depending on the attributes provided. (Read more here)

Once the browser finishes parsing the document and styles, it combines them into a Render Tree, and it figures out the layout of web page. Then it finally paints the document, and we're able to see the web page in the browser window. All of this process is known as the Critical Rendering Path. If you want to learn more about it, you can read this guide
by MDN.

Wrapping Up

Alright, I hope you found this guide helpful to deepen your knowledge about HTML and web pages! If you liked it, be sure to follow me so you never miss any of my future posts!

The Common Loops In JavaScript

Sapinder Singh — Wed, 20 Oct 2021 13:57:10 +0000

Looping is one of my favourite programming concepts that I learned as a beginner. It's simple; yet an effective way to avoid code repetition. If you are struggling to grasp the various kinds of loops that we see in JavaScript, this article is made for you indeed. 😉 Also, I've tried to keep it as general as possible so that anyone could understand even if they don't know JavaScript. So, let's jump right into it!

What's the need for loops?

Loops help us avoid code repetition. In other words, they allow us to execute the same set of instructions for a specified number of times. Usually, we have to deal with large sets of data for which, we have to perform same tasks over and over again. Loops are made for this job because we can just avoid typing the same statements again and again with our lazy hands 🥱. But there are many kinds of loops in JavaScript; how would you know which one to use in what case? I'm going to discuss the three common loops in this post- do...while, while and for. So, let's see what these are, and when to use each of them.

The Different Kinds of Loops

do...while

I chose this loop to be discussed first because it seems closer to the way I want you to start thinking about loops. Its syntax is simple enough to comprehend-

do {
  ...
} while (...)

The instructions to be performed go inside curly braces {} after the do keyword, whereas, parentheses () hold the condition that will be checked before repeating those instructions each time. Unless if we were talking to a human, we can't just say "Print 'hello' 5 times". The way loops work is that they check some condition before repeating the task each time. If the condition evaluates to true, the
task is performed again; otherwise it exits the loop. Consider this example that prints Hello! 5 times to the console/terminal-

1. let index = 1;
2. 
3. do {
4.   console.log('Hello!');
5.   index = index + 1;
6. } while(index <= 5)

Notice the use of index variable in the snippet above. Firstly, we declare this variable and assign the integer value 1 to it. Then we tell the computer to run the statements inside do{} block; then evaluate the condition index <= 5; and run those statements again if it's true; or exit the loop if not.

If we forget to include the line number 5 in our code, the loop will become infinite because the value of index will always be 1; hence the condition will be true forever. Therefore, it is necessary to increment the value each time the loop is run. When the value of index equals 5, the condition will turn to false; hence, it will exit the loop.

The increment operator) (++) is a shorthand operator that allows us to write index++ instead of index = index + 1. There's also a decrement operator (--) as its counterpart. Look them up! 👍

while

The while loop is exactly the same as do...while. Just have a look at the syntax of both loops-

// do...while loop
do {
  ...
} while (...)

// while loop
while (...) {
  ...
}

Can you spot the difference? The do...while loop runs the statement first, then checks for the condition; whereas while loop checks the condition first, then runs the statement. In short, the former checks condition for the next iteration, while the latter checks condition for the current iteration.

The answer to the question "Which of these loops should we use?" is quite opinionated. I personally don't remember the time that I used do...while loop, except while I was learning it. while loop is used much often in such cases. But there's another type of loop that is the most common among all others- the for loop.

Before introducing for loop, I want you to understand the concept of scope in programming. The scope of a variable can be defined as the range of statements in which that variable can be accessed. Consider the following snippet for example-

1. let name = 'Sapinder';
2. 
3. {
4.   let name = 'Singh';
5.   console.log(name);
6. }
7. 
8. console.log(name);

What do you think line number 5 and 8 would print to the console? The first console.log statement will print Singh but the second one will print Sapinder because the scope of variable holding the value Singh is limited to the inner block. It can't be accessed out of the those curly braces. Hence, when the compiler reaches line number 8, it only knows of the variable name that holds the value Sapinder. Also, notice that I used let keyword instead var because a variable declared with var is always globally scoped regardless of where it is declared. Now that you know what scoping is, let's learn about the for loop.

for

I like to think of the for loop as a more concise version of while loop. Both of these are almost the same except for a few things that we'll see later. First, take a look at an example of for loop-

for(let index = 1; index <= 5; index++) {
  console.log('Hello!');
}

Yes! It's just the same as the following while loop-

let index = 1;

while (index <= 5) {
  console.log('Hello!');
  index++;
}

The initialization of variable, the condition and the upgrading of value, all of these things can be achieved in single line of code in a for loop. Moreover, the variable index is initialized as block-scoped, unlike as in the example of while loop. This is major benefit of using a for loop because it avoids any chance of conflicting names at the global level. To understand another difference between both the loops, I would like to introduce two keywords-

break - The keyword break is used to terminate/exit a loop. The compiler will terminate the loop as soon as this keyword is encountered.
continue - The keyword continue is used to skip the rest of statements left in the current iteration, and start the next iteration in the loop.

Now, consider the following example where I want to print the numbers from 1 to 5 excluding the number 3-

for(let index = 1; index <= 5; index++) {
  if(index === 3) {
    continue;
  }
  console.log(index);
}

Here, I'm saying, "If index is equal to 3, don't run rest of the statements; and just skip to the next iteration." Hence, it will not print the number 3 to the console. It will continue the loop with upgraded value of index, i.e. 4. Now, let's go for the same approach using while loop-

let index = 1;

while(index <= 5) {
  if(index === 3) {
    continue;
  }
  console.log(index);

  index++; // upgrading needs to be done here in the end, unlike in `for` loop
}

Do you think this solution will work out? Can you spot the bug? Well, it is an infinite loop because once the value of index reaches 3, it skips the rest of the statements including index++. Hence, its value is never upgraded beyond 3; and the loop keeps running infinitely.

Such a case can easily be handled using a for loop because the upgrading expression of the loop is specified at the very beginning; and it is always executed at the end of each iteration. But if we move this upgrading expression from the first line of loop to just before the end of loop, as in the following example, we will again get the infinite loop problem.

for(let index = 1; index <=5;) {
  if(index === 3) {
    continue;
  }
  console.log(index);
  /* This will cause the same issue of infinite loop */
  index++;
}

So, to conclude, I would say that both the for and while loops can be used interchangeably except for some cases, where we're more likely to cause bugs using while loop, as compared to the other one. There're other kinds of loops too in JavaScript, such as- for in, for of, etc., but they are literally dead simpler than the ones discussed above; and don't need to be included in this post.

Ending it all, If you like my writing style, you can follow me to never miss any of my future posts. See you in the next post! 😉

Why do we have APIs in JavaScript?

Sapinder Singh — Fri, 01 Oct 2021 13:56:42 +0000

You've most likely heard of the term API if you have ever worked with JavaScript. There're a ton of them such as- DOM, Storage, Fetch, Canvas, History, and so forth. But have you ever wondered, "Can't we have JavaScript without APIs? Why do we even need them?". Well, I heard you!

Let's first of all understand what an API is. The term API stands for Application Programming Interface, which basically refers to an interface that different programs use in order to communicate with each other; in short, to send & receive data. APIs are like the fictional cars, which can carry the same passengers (data) by different means- land, air and water. They know exactly what medium to use when commuting to different places (programs).

The use of the term API can slightly vary across different programming areas. A server-side API is just another web server; but in place of a web page, it serves a certain piece of data when we make a request to its server. For example, if you visit this endpoint of TheCatApi, you shall receive an object that consists of a URL for some random cat's image, along with other data. We can utilize this API in a project to get random cat images. Such APIs play a crucial role in apps like weather, music, shopping, news, etc., because they provide data that these apps can utilize.

Client-side APIs (or APIs in JavaScript) are similar to server-side APIs. The difference is that these APIs are not publically available endpoints, but internally available data to JavaScript. Let me ask you- "What could you do with JavaScript if there was no DOM API, Fetch API, Storage API, Event API or any other kind of API? Can you think of any use-case of JavaScript in such scenerio?" Ya, you could just create your own variables and play with them until you realize that it won't help in interacting with the HTML page.

JavaScript is just the language we speak when communicating to browsers, whereas the various APIs provided by browsers help us communicate with different things like HTML, CSS, Storage available on client's system, Events captured by client's system, etc. For example, DOM API is a JavaScript Object that gives us information about what is there in the HTML document. CSSOM API is another JavaScript Object that gives us information about the styles that are present in CSS form.

Each of these APIs present their data to us in the language we speak, JavaScript. Hence, as you see, APIs help different pieces of software to communicate with each other by providing data in their native forms. All of these APIs are provided by JavaScript Runtime Environment to the JavaScript Engine present in browsers that interprets and executes our code. Without these APIs, we could just play around with our manually created data, but we won't be able to cause any effect outside of JavaScript's reach; i.e. everything else.

Ending it all, If you like my writing style, you can follow me to never miss any of my future posts. See you in the next post! 😉

The Dynamic Web

Sapinder Singh — Fri, 30 Jul 2021 04:46:33 +0000

In my previous post, I introduced to you the basics of how websites work. But that was just the static form of websites. In this post, we'll learn what that "static" actually means as well as other important concepts that are used in modern web development. And you'll also get the answer to that question I left you with in the previous post. 😎

We learned previously that a website is a collection of web pages, which are just plain HTML files. When we visit a website, we receive an HTML file that is rendered inside the browser. These are static pages; meaning that the same pages are served to a client each time. Those pages are present on the server in their entire form. They never change no matter what request is received from a client. But this is not desirable at all times.

Server-side Rendering

Suppose that I have a page where I ask you to enter your name in a form. After you submit the form, I want to render your name on the page with a message, for example- "Hello <your-name>". If you remember from the previous post, we (mostly) make a POST request to the server when any form is submitted. The server is supposed to do something with the submitted data (your name), and send a new page to you with updated information.

We can't do that with static pages, because the new page is supposed to be different each time we submit a different name. We have no fully pre-coded page on the server, because the data to be rendered is not static. This is why we need to render/generate our page on the server each time a request is received along with necessary data, and then send it to the client. This is called server-side rendering where the pages are dynamic. Here is a live example of a dynamic page if you want to check out, where you have to submit an API endpoint to receive some response, (or just enter anything to receive an error response).

The concept is pretty simple- wherever some data is not pre-defined, we use template values as placeholders; wait until a request is received along with the data; and then inject it into the page before sending to the client. There are template engines like EJS and Pug that ease our job to generate HTML via template pages.

Drawbacks Of SSR

There are two major limitations of SSR as listed below-

Slow Navigation - You know that when we navigate through different routes (/home to /about-me), the browser makes a new GET request to server asking for associated page. This makes navigation really slow because a whole new request is initiated for each page transition. This happens for both static and server-side rendered pages.
High Server-Load - Because the required page is rendered on server for each request, the load on server increases with significant traffic; resulting in high latency rate.

But wait a minute... if we can generate pages on server-side, why not try doing that on client-side instead? 🤔 Yes, meet CSR!

Client-side Rendering

If you notice, this site doesn't refresh when you navigate from one route to another, and the pages load instantly; meaning that it doesn't ask the server for any other page once the website loads initially. This is called client-side rendering.

In this technique, the client receives a single HTML file only, with a bunch of JavaScript code. Based on what page/route was requested, the content for that page is injected into HTML via JavaScript. Hence, if you navigate to a different route later, only the necessary page content is re-rendered. No request is made to the server, and all of the routing stuff is handled on client-side that makes navigation super fast! 🚀

Websites using this approach are categorized as Single Page Applications.
But we need not be too happy with this approach because it has its own downsides.

Drawbacks Of CSR

Poor Search Ranks - Because the client receives just an empty page initially, there's nothing to read on the page. And hence, search engines aren't aware of our content. Even though Google claims that they do crawl pages generated using JavaScript, the search ranking can be really poor for these websites.
Slow Initial Load - Because there's a lot of JavaScript code coming along with HTML, the initial load time increases significantly. Furthermore, the time for the page to be interactive also increases as it is being generated by the browser.
JavaScript Mandatory - Many of the users keep JavaScript disabled in browser settings for security reasons. But this also blocks JavaScript from generating page content, and therefore, their browser renders nothing but blank page. 🥴

Now, you guessed it; we have another approach to take over! 🥳

Pre-Rendering

This approach is simply a blend of both static and client-side rendered sites. Before we go further, let's first recall a few points-

In the simplest approach, that is Static Sites, we have manually coded HTML pages on server. One of the page is served when a request is received for that page.
In server-side rendering, we have template pages. When a client requests a certain page, we first render it on server by injecting the received data into page content; and then send it to the client.
In client-side rendering though, we serve just a single template page. All of the routing & page rendering stuff is handled on client-side.

Now coming to Pre-rendering or Static Site Generation, the development process is similar to CSR. The only difference is that we pre-render/pre-generate all of the static pages on server. This is done during build/compile time. So we have the entire site pre-rendered on the server.

Unless it reaches client-side, it behaves just like a static site where a certain page is served on request. Now in order to understand what happens on client-side, you should first know about the term hydration.

Hydration or rehydration is a technique in which client-side JavaScript converts a static HTML web page into a dynamic web page by attaching event handlers to the HTML elements.
Wikipedia

Once that static page is rendered inside browser, the only job left is to transform it again into a dynamic SPA page so that all further navigation events are handled on client-side. So we hydrate the page by attaching event handlers. This is really powerful as it takes benefits from both Static Sites and CSR approaches in order to remove/minimize their drawbacks.

But there are two huge limitations of Pre-rendering-

Unsuitable For Highly Large Websites - The reason for this limitation is that because all of the pages are pre-built on server-side, the build time goes on increasing with the number of pages added. A few hundred pages are fine for this approach based on server resources.
Unefficient For Too Frequently Changing Content - In addition to large build time, every change in these sites, even if it's a minor one, requires to re-build/re-compile the entire site! This consumes more time and resources. Thus this approach is not suitable for websites where the content changes too frequently.

So, this was all about the approaches adopted for dynamic websites. The use of each of these methods depends on the scale and requirement of a website, and therefore, a thorough comparison should be made before choosing any of these approaches.

Now let me shed some light 🧙 on a few other important concepts used in modern websites.

Frameworks

We all know that humans are compelled by their nature to combine simple things to make crazy stuff; then take that crazy stuff to make even crazier stuff, and so on. This is how we got things around us that we see today. The same is with libraries.

There's a large number of brains in every programming community that work together to create re-usable and life-saving libraries for the benefit of their community. In Node.js world, these are interchangably referred to as packages because they are hosted by package managers like NPM and Yarn.

Frameworks use multiple libraries to take the game to the next level. A framework is an extra layer of abstraction that makes building applications easier in a certain way. For example, my blog is built with Gatsby.js framework instead of plain JavaScript, which follows SSG approach. Then there's Next.js, Angular, Vue, Svelte, and many other frameworks that follow one or another approach.

You don't need to rush toward these frameworks unless you get comfortable at building websites with plain JavaScript, because foundational understanding does matter before stepping up a layer of abstraction. Frameworks have their own place in today's world, but they are not mandatory. With this, let's head toward the last section of this post!

Progressive Web Apps

I have nothing much to say on this topic except, "They are an attempt to make websites act like a native app on your phone". Try visiting twitter.com in your browser; close the tab; disconnect from internet; visit the site again; and boom 💥, the web app loads without an internet connection! Twitter.com is an example of a Progressive Web App.

Progressive Web Apps focus on things like-

Caching pages for offline availability.
Caching other resources like images, etc., for faster loading from the server.
Handling things like "Add To Home Screen" by providing necessary amount of information about the website.
Utilizing APIs like Push Notifications, etc.

PWAs are getting much popular nowadays because they provide an app-like experience to websites; hence, justifying the title "web applications".

Wrapping Up

So that's all I wanted to include in this post. If you like my writing style, feel free to follow me for more posts like this!

Web Development: The Static Fundamentals

Sapinder Singh — Sat, 10 Jul 2021 11:47:00 +0000

This is the first part in the series where I will provide a foundational understanding of the websites that you see around, and use daily. In the first part, we'll get to know the fundamentals of static web development. I won't focus much on implementation, because this is to get an idea about the kind of things that exist in this field. So, I think we're ready to begin now! 👨‍🏫

In the most basic sense, a website is no different from a native app, e.g. android/ios app; except that it can only do things that a web browser allows it to. It can't run on the client's system like other apps do, because it is rendered inside a web browser; and it is the thing that only a web browser understands.

There are two major parts of web development- frontend (client-side) and backend (server-side). Let's discuss the front end first.

Frontend Web

A website is a collection of web pages, which are just plain HTML files. When you make a request to a website's server, your browser receives a ton of data in response; but one thing that is never going to be missing is HTML.

Each web page is an individual HTML file. Every time we navigate to a different route, the browser makes a new request to get the HTML file for that page. For example, if you navigate from /home to /about-me route, it would make another request to the server to get HTML file for /about-me page.

The best way to check is to notice the loading indicator in your browser. If it indicates that it's loading, you have essentially made a request to the server; and it's waiting for the response. In case you wonder why it doesn't happen on this site, you'll get to know the reason in the next part of this series. 😉

HTML stands for HyperText Markup Language, where HyperText refers to text that contains references to some other text. So essentially, that's how you jump from one web page to another.

Now, do you like the way this button looks?

Most likely not! But what about this one?

The first one is a plain HTML button with default styles, but the second one utilizes CSS to apply custom styles. Below is a sample code for this fancy button-

<!-- HTML -->
<button>I'm a Fancy Button!</button>

/* CSS */
button {
  color: value; /* consider 'value' as a placeholder */
  background: value;
  border: value;
  padding: value;
  border-radius: value;
  box-shadow: value;
}

CSS stands for Cascading Style Sheets, which actually states what it does. The styles are applied from top to bottom in the order they are defined, just like a cascading waterfall. Any repeated style would override its previous corresponding values, as in the following example.

button {
  color: white;
}
/* This will override the previous value for 'color' */
button {
  color: black;
}

JavaScript

Now, just HTML & CSS ain't enough for a modern website. For example, that Fancy Button above does nothing when you click on it. But a button is really meant to trigger some action. Now click on the button below to see what happens.

You guessed it- it's JavaScript! 😄 It adds functionality to these showpieces. Just like HTML & CSS, JavaScript is a client-side language; meaning that it is interpreted and executed by a web browser. It can't run natively outside a web browser, unlike C++, Java, Python, and other commonly used server-side languages.

Working in JavaScript is similar to many other languages, for example, the following statement declares a variable named myName that we can do anything with.

var myName = 'Sapinder Singh';

We can use and manipulate this variable as and when needed. But in JavaScript, we don't want to work with these variables only; we instead want to operate on HTML elements present on the page! So how do we operate on HTML elements in JavaScript?

You must have at least heard of the term API (Application Programming Interface). As the name suggests, an API serves as an interface for different pieces of software to communicate with and provide data to each other.

When it comes to interacting with HTML, JavaScript needs DOM API
that stands for Document Object Model. It provides the HTML document to JavaScript in the form of an Object Model. The root of this inverted tree-like object is the document itself. Each element in the document gets its own node that goes as deep as the number of children elements it holds.

So if I want to select that "Fancy Button" in JavaScript using DOM API, I would do this-

// assuming the button does have an id
var fancyButton = document.getElementById("fancy-button");

Instead of assigning a regular value to some variable, I would have to assign it a DOM element. I can then treat this variable like an actual element on the page. The following statement implements a part of that 'click' thing on the button.

/* Don't worry if you don't understand the syntax, 
  you're here just to understand what it does. */
fancyButton.onclick = () => alert("I've been clicked! :)");

So in essence, HTML, CSS and JavaScript form the basis of front end of a modern website. We can-

have one or more HTML files (and other optional files such as .css, .js, etc., linked from within HTML)
open the root HTML file in any web browser
and see it render in the form of a web page

But as you may guess, it's totally useless as long as only we can see the web pages. That's why we now need to head to the next section. 😛

Backend Web

A web server is needed in order to serve our web pages to the world. For this task, we have a lot of server-side languages such as Java, PHP, Ruby, Python, C++, etc. I mentioned earlier that JavaScript is a client-side language, because it can not be run outside a web browser to act like a web server. Now I'm ready to admit- that was kind of a lie! 😅

Meet Node.js

We have Node.js that is a JavaScript runtime environment. A runtime environment combines different tools and technologies to provide a suitable environment that enables it to run a certain program or application.

Your web browser too provides a runtime environment for JavaScript that supplies various APIs to the core JavaScript engine like DOM for parsing HTML, Storage API for storing website's data on client's system, CSSOM for manipulating styles using JavaScript, etc. But the core part of a JavaScript runtime environment is the JavaScript engine.

Google Chrome and other Chromium-based web browsers use Google's V8 engine for running JavaScript, which is written in C++. Interestingly enough, Node.js also uses the same engine. But instead of providing APIs like DOM or so, it uses other tools that allow access to Operating System, File System, Networking, etc. This, as a result, enables us to use JavaScript as a server-side language.

Node.js is a popular choice among other backend languages nowadays. A major advantage for those coming from frontend part
is that you don't have to learn another language to setup a server! You're all set if you know JavaScript well enough.

Working of a Server

A server is always up and running (if not crashed! 🙄), listening to requests and sending appropriate responses to its clients. The type of response depends on what type of request a user makes. These are called methods. Following are the two most commonly known request methods used over HTTP:

GET - This method should be used for retrieving a resource from the server. As an example, when you visit any website, the browser makes a GET request to the server asking for a web page present on that route.
POST - This method should be used for posting/submitting data to the server, usually when creating a new resource. When you fill up a web form, that form mostly uses POST method as shown in the snippet below.

<!-- HTML -->
<form method="POST">
  <!-- The form fields go here -->
</form>

I can't show you the actual implementation of how a server handles requests and responses in Node.js because it might be a little complex for beginners; but here's a Pseudo code for this job-

CREATE an http server using http.createServer()
CALL server.listen() to activate the server

// Now handle requests from different routes, e.g. '/home' or any route
IF request.url EQUALS '/home'
  SEND '/home.html'

ELSE IF request.url EQUALS '/create-user'
  // the user wants to visit the page where it can create a new account
  IF request.method EQUALS 'GET'
    SEND '/create-user.html'

  // if the method is POST, it means the user submitted a form on '/create-user' route
  ELSE IF request.method EQUALS 'POST'
    SEND newlyCreatedAccount

This was to give you a brief idea of a server. If you notice the handler for POST method on /create-user route, we're trying to create a new user based on the data received via request object; and then provide that newlyCreateAccount to the user. But we actually need to store that account to remember it in the future. So, it's time to head to the next section.

Databases

You may already have an idea of what a database is. A Database is like a store with a certain way of organizing and working with data. A common term you would hear relating to databases is CRUD; an abbreviation for Create, Read, Update and Delete. These four are the most basic operations that a database performs.

There are many types of databases, but the two major categories are Relational and Non-Relational. Sometimes they are also referred to as SQL (Structured Query Language) and
NoSQL respectively. Let's take a look at each of them-

Relational/SQL Databases - These types of databases store data in a table-like format, where each row represents an entity while each column holds certain data about that entity such as Name, Address, etc. MySQL and PostgreSQL are two popular relational databases to consider when working with Node.js.
Non-Relational/NoSQL Databases - The 'No' in NoSQL means Not only, meaning that it can be of any form. These are more flexible than their SQL counterparts. The most popular NoSQL choices with Node.js are MongoDB and Redis.

Choosing a database depends on the type of data you're going to store, and it is advised to research about different options before making a choice to get optimal performance.

Server-side APIs

Ever wondered how the weather app on your cell phone collects so much amount of weather info? And how does google maps know what place is where? And where does this little ip-address-tracker-app get all the data from?

It's all done via APIs. A server-side API is similar to a web server, but instead of serving a web app, it serves data to other apps so they could make use of it. That ip-address-tracker-app utilizes IP Geolocation API by IPify to collect data about different IP addresses.

An endpoint can be thought of a final destination that we can visit to get data or perform some other action related to that data. Endpoint may be considered a fancy name for URL. Visiting any of the endpoint of an API should return some data rather than a web page. For example, if you visit this endpoint of TheCatApi, you shall receive an object consisting of a URL of some random image, along with other details about the it.

We can have any number of endpoints in a server-side API, but the API has to follow some well-thought architecture to be accessible and maintained in a large scale project. The standard protocol for web APIs is to use a RESTful architecture. If you wish to learn more, refer to this post about RESTful API.

To summarize so far-

We have HTML, CSS & JavaScript working together on client-side
We have a Server handling client's requests/responses, using Node.js
We can also use Databases to store data
We can also serve an API instead of an application

Now let's head to the next section.

Hosting Providers And Domains

The so-called web server that we know about so far yet is on our local machine only. We can run the server in background, and open, for example localhost:8000, in the browser to see our website. 8000 is a port number. But instead of hosting our server locally, we now need to host it somewhere else to make it available to the world. We want to deploy our app to a hosting
provider that would run our server 24*7 on its huge machines.

There you would also need a domain name for people to be able to access your server on the internet, because now it can't be reached via localhost. A domain name is the *.com part of a url. For
example, in my website's url https://blog.sapinder.dev, the domain name is sapinder.dev where dev is a top-level domain just like com, org, etc. If you wonder, the blog part is a sub-domain.

Fun Fact

You can have any number of subdomains once you own the domain name. Also, www is a subdomain too!

Apart from buying a domain name, we also have to pay regular charges to our hosting providers because they run our server 24*7. But most of the hosting providers offer free tier services with limited resources, and we can upgrade our accounts as our requirements grow. Meanwhile, free tier services are mostly more than enough for beginners, and they also provide a free domain! The main caveat is that it ends with their default domain names. For example, *.herokuapp.com for Heroku, *.netlify.app for Netlify, and so on. If you want your own domain name, to look actually professional, you will have to buy one.

Version Controlling

Maintaining the code is also really important, as it's the only way to identify & fix currently present bugs, as well as to bring new features to an app. Version Control Systems allow us to track & add changes, and even revert the whole app back to a previous version! Now you know how powerful these systems can be.

The most widely used VSC is Git. There are a few terms that you should know when using Git, a few of which are-

Branch - Branching allows developers to keep their code repositories into separate branches, each for a specific purpose. For example, I usually maintain two different branches for my code, namely main and development. main is the default branch when git is implemented, whereas I keep a separate development branch for development purposes. The number and purpose of branches may increase in large scale projects.
Stage - There is a staging area in git that holds all the ready-to-be-made changes in our code. We add the changed files in our code to staging area via git add <file-name> command in order to be able to review the changes before making a final commit, which leads us to the next point.
Commit - After we have reviewed the changes, we're ready to run git commit command that finally creates a new version in the git history for our code repository.
Merge - We can merge the changes made to any branch into another branch. Say I made changes to development branch, and I've tested them as well, now I can merge them into my main branch to publish changes to the server.

We can also revert our current version to any of the earlier commits by using that commit's ID. There are many other things that version control systems allow us to do that you would get to know as you use them.

Remote Repositories

What is the probability that your app code, saved in some location on your local system, is going to be safe forever? What if it gets deleted, or accessed by someone else? You get it- we need to store it online so that only we could access it anytime and on any system.
If somehow we loose the local repository, we can clone it from our remote respository along with all of the git history!

Remote repositories are not always private, but public too. They are known as Open Source projects that anyone can contribute to because their source code (or just code) is openly available to other developers in the community. For example, Firefox, Node.js, VLC Player, Linux, etc., are all open-source projects that anyone can contribute to.

Speaking of cloud-based/remote repository platforms, two of the most popular ones are Github and Gitlab, the former being the leading solution. These are like Facebook for developers and programmers to showcase their projects, as well as to maintain them. If you want to take a look, here's my Github profile (No, I don't mean it! 😅).

Wrapping Up

So, this was my attempt to give you the best overview of fundamentals of web technologies. In the next part of this series, we will learn about the dynamic part of web that powers modern websites we see around. So stick around if you like my writing style!
You can follow me if you want to never miss any of my future content!