Client-Side vs. Server-Side JavaScript

Episode Sponsor - Wix Studio

We'd like to thank this episode's sponsor for their support!

Wix Studio: The Web Platform for Agencies and Enterprises

Wix Studio is the new web platform tailored to designers, developers and marketers who build websites for others or for large organizations. The magic of Wix Studio is its advanced design capabilities which makes website creation efficient and intuitive.

Check out Wix Studio today.

How to support the show

Patreon

Prices subject to change and are listed in USD

• Support the show from as little as ~$1/month
• Get a shoutout at the end of the episode (while supplies last) for just ~$3/month
• Help support the HTML All The Things Podcast: Click Here

Show Notes

Introduction:

• JavaScript is everywhere hese days, running both in the browser and on servers. But what are the actual differences between these two environments, and why do they matter?
• Quick overview of what listeners can expect to learn:
  • Key differences in purpose and functionality.
    • Common use cases for each.
    • Tips on when to choose one over the other.
    • Highlight who this episode is for: beginner devs curious about JS environments, and experienced devs looking for a refresher.

Segment 1: The Basics

Introduction to Client-Side and Server-Side JavaScript:

Client-Side JavaScript:

• Runs in the browser.
• Handles interactions with the user, DOM manipulation, and dynamic content updates.
• Examples: form validation, UI/UX enhancements, animations.
• Tooling: Popular frameworks like React, Vue, and Angular.

Server-Side JavaScript:

• Runs on the server, usually with Node.js.
• Handles data processing, APIs, authentication, and database operations.
• Examples: Building REST APIs, managing user sessions, rendering server-side HTML.
• Tooling: Frameworks like Express.js, Nest.js, and Next.js (SSR features).

Segment 2: Key Differences

Environment Constraints with Examples:

• Client-Side JavaScript:
  • Runs in the browser, which is sandboxed for security reasons.
  • Cannot: Access the file system, run low-level OS commands, or directly connect to databases.
  • Examples: form validation, UI/UX enhancements, animations.
  • Tooling: Popular frameworks like React, Vue, and Angular.
  • Examples of APIs that work only on the client side:
    1. DOM API (e.g., document.querySelector, addEventListener): These are browser-specific APIs for interacting with the HTML and CSS of the webpage.
    2. Canvas API: Used for rendering graphics and animations directly in the browser.
    3. Geolocation API: Allows access to the user’s location but is restricted to the browser’s environment.
• Server-Side JavaScript:
  • Operates on the server, with full access to the underlying OS and hardware resources.
  • Can: Perform file operations, handle network requests directly, and manage databases.
  • Tooling: Frameworks like Express.js, Nest.js, and Next.js (SSR features).
  • Examples of Libraries/Features Exclusive to Server-Side:
    1. fs Module in Node.js:
       • Provides access to the file system (e.g., reading and writing files).
       • Why it’s server-side only:
         • Browsers don’t allow file system access for security reasons, to prevent malicious actions like modifying local files without the user's permission.
    2. http Module in Node.js:
       • Handles creating servers, sending and receiving HTTP requests directly.
       • Why it’s server-side only:
         • Browsers can send HTTP requests via fetch or XMLHttpRequest, but they don’t allow creation of servers or direct low-level HTTP handling.
    3. Database Libraries (e.g., Sequelize, Mongoose):
       • Libraries for interacting with databases like PostgreSQL, MySQL, and MongoDB.
       • Why it’s server-side only:
         • Databases are typically hosted on remote servers, and exposing database credentials or logic directly in the client would be a massive security risk.
    4. child_process Module in Node.js:
       • Executes system commands or spawns subprocesses.
       • Why it’s server-side only:
         • Allowing browsers to execute system commands could lead to devastating vulnerabilities like privilege escalation or running malicious code.

Segment 3: When to Use What?

• Client-Side Strengths:
  • Interactive, responsive experiences.
  • Reduces server load for certain tasks.
• Server-Side Strengths:
  • Handles complex logic, large datasets, and secure operations.
  • Centralizes control over application logic.

Segment 4: Current Trends and Tools

• Rise of serverless environments and their impact on JavaScript.
• JAMstack and client-side-heavy architectures vs. server-rendered apps.
• Tools making waves: Astro, Deno, and Vite.

‍