Well, there are a number of things that make a real-time video chat application fully functional on the web. In this article, we’ll explore how you can access media content through your device’s camera. And we'll build a camera app in the course of our exploration.

Let’s face it, using the MediaStream API to build a camera application does not tell the whole story. But here’s what I can promise you: we are taking the first step in the right direction.

Before we begin, have a peek at what you should be able to create by the end of this article here. Now that you are all geared up, let’s get to work!

Prerequisites

Before we dive in, let's be sure of a few things. This article is designed to be for beginners, but having the right resources will ensure a seamless experience. Here's what you'll need:

• A very basic understanding of HTML, CSS, and JavaScript — beginner level knowledge is absolutely fine.
• A basic understanding of the Document Object Model in JavaScript.
• Last but not the least, some good background music — I’ll let you choose this one yourself, but there's always freeCodeCamp radio.

Ok, now we're all set.

What is the MediaStream API?

The MediaStream Recording API helps the browser capture audio-visual data streams. It's important for our use case, because any image we capture has to be stored in a MediaStream object.

The MediaStream API does more than capture photos and videos. It also helps process and analyze the MediaStream data right on the browser. As complex as all of this might seem, it’ll interest you to know that the MediaStream API is surprisingly easy to work with.

Our camera app makes it even easier.

Components of Our Camera App

Our camera app has a very simple user interface — heavily inspired by the Samsung Camera UI. Some notable components/features of the camera are:

• Camera Preview
• Camera mode options
• Photo Gallery

For the sake of this tutorial, only a few actions on the browser are enabled — the “photo” camera mode, the camera shutter button, and the photo gallery button just to the right of the shutter button.

Step 1: Simple HTML for Our Camera app

To begin, we'll lay the foundation for our camera application with some simple markup. Understanding the structure of our camera app is crucial as it comprises four major sections, each playing a vital role in its overall functionality:

1. <video> section
2. Snapshot <button> section
3. <canvas> section
4. Snapshot <img> section

1. <video> section

Our camera app must include a <video> tag for streaming the visual media from our webcam to our browser’s display. Let’s give it an id of camera-stream.

<video id="camera-stream" autoplay loop muted>
  <source src="" >
</video>

2. Snapshot <button> section

We'll also need a button to trigger the capture of the visual media when it is clicked. This will act as the shutter button. Let’s give it an id of shutter.

<div class="shutter-ctn">
  ...
  <button id="shutter" class="shutter">
  </button>
  ...
</div>

3. <canvas> section

A canvas tag helps us capture the image data from the video stream, while being able to export the data as an image that can be saved. The <canvas> element does not need to be visible to the user, but it must be accessible by the DOM. Let’s give it an id of canvas.

<canvas id="canvas"> </canvas>

4. Snapshot <img> section

For the final HTML section, we need a view to see all images that have been captured. Let’s identify this with an id of gallery-view.

<div id="gallery-view">
  <button id="prev">
    PREV
  </button>
  <img data-index="0" src="" alt="current viewed image">
  <button id="next">
    NEXT
  </button>
  ...
</div>

Step 2: Beautiful CSS Styles to Make Our App Pop

Adding styles to the HTML of our camera app greatly improves its user-friendliness. Don't hesitate to get creative while adding these styles, and feel free to skip this section to Step 3 if you would rather add your own styles.

First, lets add some global styles to ensure that each component fits perfectly when they are layered.

body {
  margin: 0;
  max-height: 100vh;
  overflow: hidden;
}
canvas {
  display: none;
}
button {
  border: 0;
  outline: none;
  background: #00000070;
  color: #FFFFFF;
  padding: 4px 8px;
  height: 30px;
  min-width: 30px;
  border-radius: 24px;
  display: grid;
  place-items: center;
  cursor: pointer;
}

Afterwards, we'll apply styling to the <video> element, which displays a preview of the shot to be captured.

.camera-ctn {
  position: relative;
  background: #000000;
}
.camera-view video {
  height: 100vh;
  width: 100vw;
  object-fit: cover;
  transform: scaleX(-1);
}

Lastly, the styling task left for us involves customizing the bottom section of our camera interface — the section typically housing the shutter button.

/* CAMERA BOTTOM */
.camera-bottom {
  height: 250px;
  background: #00000050;
  position: absolute;
  inset: 0;
  top: auto;
  padding: 0 5%;
  display: grid;
  place-items: center;
}
.camera-bottom > .inner {
  display: grid;
  place-items: center;
  max-width: 500px;
}

/* SHUTTER CONTAINER */
.shutter-ctn {
  display: flex;
  align-items: center;
  justify-content: space-around;
  width: 100%;
}
.shutter {
  height: 80px;
  width: 80px;
  background: #FFFFFF;
  border-radius: 50%;
}
.shutter:active {
  transform: scale(0.8);
}
.switch-device {
  height: 55px;
  width: 55px;
  border-radius: 50%;
}

To have a full view of the CSS styles originally used on this project, have a look at them here.

Step 3: JavaScript Code to Make Our App Fully Functional

Finally, after laying a solid foundation with our HTML structure and improving the usability of our camera app with some CSS styles, our focus now shifts to ensuring our camera app does what it’s supposed to do — take pictures.

We do this by heavily relying on the MediaStream API in JavaScript while following these three steps:

1. Linking our HTML elements to JS.
2. Connecting the webcam to JS code.
3. Capturing and saving media from the webcam.

1. Linking HTML elements to JS

As we proceed with adding functionality to our HTML, we must link these elements to our JavaScript code via the DOM. Recall that we assigned IDs to the primary elements we defined in the HTML step.

const cameraVideoStream = document.getElementById('camera-stream')
const shutterButton = document.getElementById('shutter')
const canvas = document.getElementById('canvas')
...

2. Connecting the webcam to JavaScript code

Upon linking our HTML elements to our JS code, we can now establish the connection to our webcam. This involves initially verifying whether the user’s browser supports this operation using the navigator.mediaDevices boolean expression.

If the expression returns a truthy value, we can invoke getUserMedia() and specify the video option by passing {video: true} as a function argument like below:

if (navigator.mediaDevices && navigator.mediaDevices.getUserMedia({ video: true })) {
  navigator.mediaDevices
    .getUserMedia({ video: true })
    .then ((stream) => {
            cameraVideoStream.srcObject = stream
            cameraVideoStream.play()
    })
}

The getUserMedia() function invokes an asynchronous operation, which means it doesn't return a response immediately. Also, it might encounter failures — this could happen if the user denies permission for us to access their webcam or if their device lacks a webcam altogether.

If the operation is successful, the video stream is collected and transferred to the video element that was earlier created.

But the video does not start playing immediately. A brief delay occurs to allow for a buffer — this delay is often unnoticed. We have to create a streaming variable in conjunction with the canplay event of the <video> element to know when a portion of the video is buffered and ready to play. We can do that like below:

let width = window.innerWidth
let height = 0
let streaming = false

cameraVideoStream.addEventListener(
  "canplay",
  (ev) => {
    if (!streaming) {
      height = cameraVideoStream.videoHeight / (cameraVideoStream.videoWidth / width);

      canvas.setAttribute("width", width);
      canvas.setAttribute("height", height);
      cameraVideoStream.setAttribute("width", width);
      cameraVideoStream.setAttribute("height", height);
      streaming = true;
    }
  },
  false
);

Notice that before streaming is set to true, the <video> element and the <canvas> height are set to match the height value (which might be a fraction of the width based on the desired dimensions). This adjustment helps prevent any glitches, particularly when capturing the image.

3. Capture and save media from the webcam

Now, the hardest work is complete. All that is left is to capture snapshots from the video stream and store them in an array as images.

To accomplish this, we use the context of the <canvas> element defined earlier, accessed through canvas.getContext('2d'). Afterwards, we transfer the current frame of data from the video stream to compose an image using the canvasContext.drawImage() function just like below.

// Capture snapshots using HTML Canvas
function captureImage () {
  const canvasContext = canvas.getContext('2d')
  canvas.width = width
  canvas.height = height
  canvasContext.drawImage(cameraVideoStream, 0, 0, width, height)

  // Convert captured data to image (base64)
  const data = canvas.toDataURL('image/png')
  currentImageElement.src = data
}

// Add click listener to shutter button to capture image
shutterButton.addEventListener('click', () => captureImage())

With the data now captured as an image, the absolute final step is to convert the image to a transferable format suitable for the <img> tag or any other image viewing resource. One of the many transferable formats is base64, and fortunately, the <canvas> element enables us to achieve this effortlessly with canvas.toDataURL('image/png').

And voilà! You've successfully constructed your own camera app. Well done, genius!

As soon as we are done implementing these three steps, all that’s left is to say “cheese” and take some nice pictures.

If you mixed up a few instructions, feel free to take a look at the complete JS code here. If that does not help much, I’m always happy to assist personally when you send a message.

The Fun Doesn't Stop Here

Wanna have fun building more features for the camera app? You can pick up where I left off on GitHub. Whether it’s your own gallery, or a quick photo editing tool in the gallery view, or a timer feature, or even if you wish to extend this to a video recorder – go for it!

If you found this article helpful, feel free to connect on favourfelix.com to see what else I'm up to.

I’m also a big fan of the Vue.js framework, and I’ve been building apps with it for three years.

So it was a delightful surprise when I realized that I could use only the Transition API in Vue.js while leveraging my decent CSS skills to animate a component’s enter and exit animations in such a fluid manner.

How fluid, you might ask? Let me show you:

In this article, we'll build a straightforward movie app with built-in filtering features. By the end, you should have a solid understanding of the <Transition> and <TransitionGroup> built-in components in Vue.js and how they seamlessly handle enter and exit animations within Vue.js.

Prerequisites

Hold on! We need a few tools in our toolkit before we dive into this adventure. This article is designed to be a breeze for beginners, but to ensure a smooth ride, here's what you'll need:

• A basic understanding of HTML, CSS, and Javascript.
• A basic understanding of Transitions and Animations in CSS.
• A basic knowledge of the Vue.js framework.
• You can also access the bare movie app without the transitions here, but only if you think it’s the boring part ;)
• Last but not least, some good background music—I’ll let you choose this one yourself, but there's always freeCodeCamp radio.

Ok, now we're ready to get started.

What is the Transition API?

The Transition API primarily consists of the built-in <Transition> and <TransitionGroup> components in Vue.

The <Transition> component is used for animating single elements or components. In contrast, the <TransitionGroup> is used for animating multiple elements in a list in conjunction with the v-for directive in Vue.

How to Add Animations with the <Transition> Component

The <Transition> component is a built-in component that is typically wrapped around any root element or component for animation benefits. The animations are triggered when the inner element or component is shown or hidden using common Vue directives like v-show or v-if.

This component is "built-in" because it does not need to be imported into the template to be functional. It's recognized by the Vue template compiler.

We can try this out by adding a v-show to our .header-filters container first and wrapping the container in the <Transition> component like below:

<Transition>
  <div v-show="filtersVisible" class="header-filters">
    <input type="search" v-model="searchQuery" placeholder="Search Movies">
    <div class="button-group">
      <button @click="query = ''" :class="{ active: query === '' }">Clear Filters</button>
      <button @click="query = '2021'" :class="{ active: query === '2021' }">2021</button>
      <button @click="query = 'Action'" :class="{ active: query === 'Action' }">Action</button>
    </div>
  </div>
</Transition>

We can then wrap up the animation by including styling specifications for the enter and exit animations. If you are familiar with CSS Animations and Transitions, the mode of operation is pretty similar. If you are not, here is a quick crash course.

.v-move,
.v-enter-active,
.v-leave-active {
  transition: 0.3s ease;
}

.v-enter-from,
.v-leave-to {
  opacity: 0;
  transform: translateY(10px);
}

And now, you should have your fluid animations for single root elements with the <Transition> component.

Illustration of the effect of the Transition component when an element is hidden and shown.

What if you want something similar to the video that I shared earlier? Something more mesmerizing? Well, let’s see the <TransitionGroup> component.

How to Add List Animations with the <TransitionGroup> Component

The <TransitionGroup> component is wrapped around a list to animate the insertion, removal, and change of order of the items that are rendered in this list. This list is typically created with the v-for directive.

Unlike the <Transition> component, the elements or components wrapped in the <TransitionGroup> component must have unique key attributes.

<TransitionGroup>
  <MovieCard v-for="movie in filteredMovies" :key="movie.title" :movie="movie" />
</TransitionGroup>

Aside from the instructions above, the <TransitionGroup> component has a similar mode of integration and operation as the <Transition> component.

How to Identify and Name Transitions

A common problem when using <Transition> and <TransitionGroup> components is having multiple instances of these components in your app and using different enter and exit transitions for specific instances. This is why we name <Transition> and <TransitionGroup> components.

The <Transition> and <TransitionGroup> components accept a name prop that helps to identify and group transitions.

<TransitionGroup name="list">
  <MovieCard v-for="movie in filteredMovies" :key="movie.title" :movie="movie" />
</TransitionGroup>

The name prop also determines the class name for styling enter and exit transitions like below:

.list-move,
.list-enter-active,
.list-leave-active {
  transition: 0.3s ease;
}

.list-enter-from,
.list-leave-to {
  opacity: 0;
  transform: translateY(10px);
}

Notice that the name prop passed in the <TransitionGroup> code above is “list”, and it is used as a prefix in the styles for enter and exit transitions in the CSS code above.

How to Customize Enter and Exit Animations With CSS

In this article, we used the CSS transition property to help with subtle enter and exit animations. But the <Transition> and <TransitionGroup> components also support the animation property in CSS for much more complex animations with multiple keyframes.

Here is an example of how we can use the animation property in our <Transition> component:

Template

<Transition name="bounce">
  <div v-show="filtersVisible" class="header-filters">
    <input type="search" v-model="searchQuery" placeholder="Search Movies">
    . . .
  </div>
</Transition>

Styles

.bounce-enter-active {
  animation: bounce-in 0.5s;
}
.bounce-leave-active {
  animation: bounce-in 0.5s reverse;
}
@keyframes bounce-in {
  0% {
    transform: scale(0);
  }
  50% {
    transform: scale(1.25);
  }
  100% {
    transform: scale(1);
  }
}

If the concept of keyframes or the animation property in CSS does not make much sense to you, feel free to get a quick introduction to animations in CSS.

Purposeful Motion on the Web

In any discussion about web animations and transitions, it's crucial to address the "why" behind them. Why should we include motion on the web, and is it genuinely indispensable?

Motion on the web serves a purpose that extends far beyond mere aesthetics. It's a powerful tool for conveying messages to your users. Whether it's to elevate your storytelling, provide user feedback, or captivate their attention, animations can play a pivotal role in enhancing your users' experience.

Gone are the days when animations were added merely for decorative purposes. In the modern web landscape, every keyframe should be thoughtfully designed with a clear purpose, and the user should always be at the heart of your design decisions.

That being said, make sure not to overuse animations – as too many moving parts can be distracting and actually detract from the user experience. It's all about balance.

Conclusion

Phew, that was an exciting ride! I hope you enjoyed it. This article shared a lot, and I'm excited to see how you use that information. I would love to know if you built something cool while reading.

Also feel free to look into the official Vue documentation to see what else is possible with the Transition API.

Finally, have fun creating delightful experiences with animation, but always remember CSS animations are only useful to your users when they are purposeful. If you found this article helpful, feel free to connect on favourfelix.com to see what else I'm up to.

But web development has evolved with the advent of JavaScript frameworks—particularly with the use of components as building blocks in developing User Interfaces.

In the component-driven world we are living in, we can see the benefits of container queries in Responsive Web Design. In fact, in some cases, we can achieve a fully-responsive webpage without using media queries.

In this article, we will explore responsive design beyond the viewport with Container Queries and analyze an example of a fully responsive site using just container queries.

So, What are Container Queries?

Container queries allow you to style HTML elements based on the size of their containers. It is similar in execution to media queries, except elements are styled based on the size of a viewport with media queries.

Image illustrating Container Queries in CSS

How to Use Container Queries

The containment context

To use container queries, you need to tell the browser which HTML element you wish to use as a container. We do this by declaring a “containment context”.

A containment context instructs the browser to start paying attention to the size of a container (or an element). This way, the browser knows when to apply the styles specified in your container query.

To declare a containment context, we use the container-type property with a value of size, inline-size, or normal. See the container-type API reference to understand what each of these values means.

Consider the following example of a soft drink card component below:

<div class="drink-card-container">
  <div class="drink-card">
    <img src="images/coke.png" alt="" />
    <div class="info">. . .</div>
   </div>
 </div>

We can then add a containment context to the container:

.drink-card-container {
  container-type: inline-size; 
}

And now, the browser pays attention to the size of .drink-card-container. Although, we still need to apply specific styles based on this container size, so we need the @container at-rule.

The @container at-rule

The @container at-rule allows you to style elements based on the size of their container. The container condition is evaluated when the container changes in size. Also, the @container at-rule is what primarily defines a container query. It takes this form:

@container <container-condition> {
  <stylesheet>
}

It has a similar syntax to the @media at-rule in media queries.

Recall our soft drink card example. We can now add a @container at-rule that modifies the flex-direction of our .drink-card when the container’s size is less than or equal to 450px.

@container (max-width: 450px) {
  .drink-card-container .drink-card {
    flex-direction: column;
  }
}

And that’s it! That’s all you need to know to start using container queries.

The container-name property

Now that you know how container queries work, let's think about it at scale—what happens when we have multiple containers or containment contexts to work with?

This introduces the need for specificity when writing container queries, which is why the container-name property exists.

Let’s reconsider the example from our soft drink card component.

<div class="drink-card-container">
  <div class="drink-card">
    . . .
    <div class="info">
          <h3>Coke</h3>
      <p>On May 8, 1886, the first glass of Coke was sold.</p>
      <h5>₦ 150 <sup>estimated RRP</sup></h5>
      <a href="<https://www.coca-cola.com/>">See Official Website</a>
        </div>
   </div>
 </div>

We can then add a containment context to the .info element by giving it a container-type property, as we did earlier. But this time, we include a container-name property to give the container a specific identity.

.info {
  container-type: inline-size;
  container-name: drink-info;
}

Our container query will then take this shape:

@container drink-info (max-width: 200px) {
  .info p {
    display: none;
  }
}

The code above tracks the size of the .info container (named drink-info) and hides the paragraph element when the container’s size is less than or equal to 200px.

Source Code for a Responsive Site Using Only Container Queries

To access the complete source code where all of the snippets in this article were extracted, you can visit this GitHub repository.

Live Preview

You can see a live preview of the GitHub code here. To see the responsiveness in action, resize the browser window. Alternatively, you can interact with the codepen below.

Browser Compatibility for Container Queries

Container queries are available on all the major browser engines and are stable in all modern browsers. This means you can use it today for personal and work projects.

I hope this article helped you learn the basics of container queries. Now, you’re won't be confined to just using media queries—container queries are also a valid way to make your websites responsive.

I hope you found this article helpful. If you did, feel free to connect with me on LinkedIn and check out favourfelix.com to see what else I'm writing and up to.

But although growth is evident in many places, others are left behind in this sprint. The big question is how do we level the web experience given this digital divide and make the web more accessible to people with less efficient computers and networks?

In many cases, an answer to this question lies in understanding how we render webpages on the browser.

Terms Used in this Article

Before you go on, I want to make sure you're familiar with the terms used in this article. Some of them might be particularly difficult to grasp for new developers. Feel free to skip to the next section if you are familiar with these already.

• Server: A server is a computer that resides in a remote location (mostly the internet). Its job is to handle requests from the client and process a response.
• Client: A client is any device communicating with a server to access resources. A client, in many cases, is any device that can access the internet. In this article, your web browser plays the role of the client.
• CDN: Acronym for Content Delivery Network. A CDN is "a network of interconnected servers that speeds up webpage loading for data-heavy applications" (from AWS).
• Build-time: During build-time, your application code is prepared for another environment. Most times — a hosted environment on the internet.

Now let's learn about the different ways websites can be rendered.

What is Client-Side Rendering (CSR)?

Client-Side Rendering generates webpages in the browser, fully relying on your JavaScript Code. The browser fully processes your JS code before your web page's content is visible to the user.

Your JavaScript code helps to dynamically define the website's architecture as soon as it is downloaded. Architecture in this context means data fetching from an API, website navigation, and simple business logic on your website.

Client-Side Rendering and JavaScript Frameworks

Client-Side Rendering gained popularity with the release of JavaScript frameworks and libraries like React, Vue and Angular. These frameworks are only functional by including a CDN at the head of an HTML page — and these CDNs typically contain JS code that is large in size.

It's no secret that large files result in increased download time, but there is a catch here: downloading large files at the initial load of the application means significantly less loading time in accessing other pages on that website.

The website primarily fetches data from an API. This data is then used to populate pages rendered on the client.

You can find common examples of a real-life application that use CSR in many of the Progressive Web Applications (PWA) we use today, like Spotify, Figma, and Google Drive.

What is Server-Side Rendering (SSR)?

Client-Side Rendering was a game-changer and still is — in many cases. Although, a closer look at performance in CSR showed that the more features a website had, the more JS code it had. Recall that more JS code means more download time.

Heavy downloads during the initial load to ensure faster access to all web pages did not seem like a trade-off some people were willing to make. This gave rise to Server-Side rendering.

SSR doesn't solve all the problems of rendering on the web. But it solved many of the issues faced by CSR like faster load times on initial visit and a few others highlighted in the Benefits and Trade-offs section of this article.

Server-Side Rendering helps generate a webpage on the server just after receiving a request from the browser. With SSR, the server renders the full HTML, CSS, and JavaScript required for the requested resource and sends it back to the browser.

This means you can always be sure that the website content contains the most recent information from the server. You can think of it as an integration of a REST API — content from the backend is always updated.

Like all other methods of rendering on the web, SSR has its fair share of drawbacks. For one, having to make network requests to the server to load a webpage could impact users with less internet bandwidth. SSR also requires a relatively higher volume of computing power to be active.

What is Static Site Generation (SSG)?

Static Site Generation is a very common approach to rendering on the web. This is because most websites, if not all before JavaScript frameworks, were statically generated.

Static sites are still very popular, but there are better ways to generate them. This goes to show how important they are in terms of performance on the web.

But, What is a Static Site?

A static site is rendered on a browser exactly how it was generated. The content of a static site is typically unaffected by the user viewing, unlike a web app rendered in CSR, or SSR, where each user can see content based on authentication or authorization.

Static sites are ideal for showing content that never changes or is updated once in a while.

Static Site Generation Explained

Static Site Generation largely involves automating the process of building webpages. JavaScript frameworks today (like Nuxt.js, Next.js, and so on), provide template engines for building multiple static webpages with one template. As you can imagine, this saves time.

Static Site Generation is different from SSR and CSR in the sense that your HTML webpages are rendered and generated during build-time — before the user attempts to access your webpage. This is why SSG is commonly referred to as pre-rendering. It does the hard work beforehand.

Though SSG seems all bliss, there are tradeoffs. A major drawback of rendering with SSG is that a page must be generated for every accessible URL on your website. This could get even more tedious when you have dynamic pages.

Recall that static sites are ideal for showing content that rarely gets updated, so this rendering method doesn't work for all use cases.

Benefits and Trade-offs of Different Rendering Methods

Now that you understand how all these rendering methods generate pages for the browser, we should consolidate all of this information and do some comparisons.

We'll look at the three major metrics — Performance, SEO, and Cost.

Performance

To build websites that are accessible regardless of the user’s internet or computer speed, we need to consider performance. Performance in this context could be how fast a website loads or fetches data from an API.

The subsequent paragraphs shows how CSR, SSR and SSG translate in terms of performance.

Client-side rendering performance

A client-side-rendered website can be relatively slow to load. This is because JS code is first downloaded and used to generate actual content that users see.

Oftentimes, JS downloads are heavy, especially with JS frameworks. Client-side rendered webpages might also need to make API calls to fetch data from the backend. This increases load time for the user.

Server-side rendering performance

SSR Rendered webpages can be very fast. This is majorly dependent on the server's speed and the user's speed. If both conditions are met, SSR could take an easy win in terms of performance.

Static site rendering performance

Webpages generated with SSG are relatively fast as actual rendering does not take place on the browser.

SSG feeds the browser with content that it requires without extra work. SSG-rendered webpages, like CSR, might also need to make API calls to fetch data from the backend. This also increases load time for the user.

Ultimately, the amount of JavaScript used in a webpage can determine its performance.

Search Engine Optimization (SEO)

Every website that needs visibility should value Search Engine Optimization. SEO determines how accessible your content is on search engines like Google. It also determines how high you rank in the Search Engine Result Pages (SERPs).

Let's see how all three rendering methods perform when they are indexed by search engines.

CSR Search Engine Optimization

Webpages rendered with CSR typically have no meaningful content and depend on JS to generate content. The downside is not all web crawlers support JS, so your website might not be indexed properly on search engines.

SSR Search Engine Optimization

SSR renders complete webpages with updated content from the server. Webpages rendered with SSR can be crawled and indexed by search engines.

SSG Search Engine Optimization

A web crawler very easily crawls webpages generated with SSG. They do not rely on JS to render fully.

Cost

It’s important that users have the best experience when they visit a website, but the bills don’t pay themselves, so the cumulative cost of this experience has to be as lean as possible.

The three rendering methods do not share the same financial implications. The paragraphs beneath takes a closer look into the cost of using each.

CSR Cost

Client-Side Rendering runs 100% on the browser. This means no additional cost is incurred.

SSR Cost

Server-Side Rendering generates a fully functional webpage remotely on the server. This means extra computing resources and extra costs.

SSG Cost

No Cost. Static Website Generation is during build-time. Hence, generated webpages are hosted, and no extra rendering is done on the server.

Conclusion

When selecting a rendering method, consider your use case and what works best for it based on what you have learned from this article. Different rendering methods are suitable for different kinds of websites.

An e-commerce website developer might choose to go the SSR route or feel more secure using static sites. A web application developer, on the other hand, might not mind a lengthy initial load as long as it means a better experience for the user in the long run.

Whichever rendering method you select, ensure your website is as accessible as possible — beyond conditions you would not necessarily experience. Finally, never forget to stay on a healthy JS diet.

I hope you found this article helpful. If you did, feel free to connect with me on LinkedIn and check out favourfelix.com to see what else I'm writing and up to.