└── README.md


/README.md:
--------------------------------------------------------------------------------
   1 | # Vanilla JavaScript for React Developers
   2 | 
   3 | This book will guide you through re-implementing common React patterns and features using nothing but **Vanilla JS**, helping you deepen your understanding of the web platform and become a more versatile developer.
   4 | 
   5 | *Note: This book was formatted using an LLM*
   6 | 
   7 | ## Introduction
   8 | 
   9 | If you're comfortable building apps with React and its ecosystem but feel less confident working with raw JavaScript and browser APIs, this book is for you. We assume you know the basics of web development (HTML/CSS/JS) and have built React apps, but you might not have created complex apps without a framework. We'll bridge that gap by showing how React's abstractions map to plain JavaScript techniques.
  10 | 
  11 | You'll learn how to create dynamic interfaces, manage state, compose components, handle routing, and perform side effects using **just the platform** (no frameworks). We'll review JavaScript fundamentals (like closures and the event loop) to firm up your understanding. Then, we'll dive into building real projects – from a simple to-do list to more advanced apps like a movie explorer and beyond – all in Vanilla JS. Along the way, we'll emphasize a **no-build toolchain** where possible (just use a browser and editor), and then show how to prepare for production with bundlers (using Vite) and even a touch of Node.js for backend concepts.
  12 | 
  13 | Each chapter addresses a specific aspect of app development. Chapters include explanations, code examples, and comparisons to how you might do the same in React. We've included several hands-on tutorials/projects to practice the concepts. You can type the code yourself, or if you have an AI coding assistant, you'll find optional prompts to help generate or validate solutions. *(For example, after reading a project chapter, you might ask your AI assistant to "build a to-do app in vanilla JavaScript" to compare with your code.)* Use these AI prompts as a learning tool – but we encourage you to work through the code manually first for maximum learning.
  14 | 
  15 | Let's get started on our journey from React to **real** Reactivity – the kind that doesn't require a library at all!
  16 | 
  17 | ## Chapter 1. JavaScript Fundamentals for React Developers
  18 | 
  19 | Before we build anything, let's review some core JavaScript concepts. As a React developer, you've certainly used JavaScript daily, but some fundamentals might have been abstracted away by the framework. Understanding these will make it easier to implement React-like patterns in plain JS.
  20 | 
  21 | ### 1.1 Closures and Scope
  22 | 
  23 | JavaScript functions are **first-class citizens** and form closures. A **closure** is created whenever a function retains access to its lexical scope even after that outer function has finished executing. In practical terms, this means an inner function can remember and use variables from an outer function even after the outer function returns. For example:
  24 | 
  25 | ```js
  26 | function createCounter() {
  27 |   let count = 0;
  28 |   return function increment() {
  29 |     count++;
  30 |     console.log(count);
  31 |   };
  32 | }
  33 | 
  34 | const counter = createCounter();
  35 | counter(); // 1
  36 | counter(); // 2
  37 | ```
  38 | 
  39 | Here, `createCounter` returns an `increment` function. The returned function "closes over" the `count` variable. Each time you call `counter()`, it remembers the last value of `count` because of the closure. Closures are useful for **encapsulating state and creating private variables** in Vanilla JS, similar to how React components might hold state via hooks. In fact, hooks like `useState` leverage closures under the hood to retain state between renders.
  40 | 
  41 | ### 1.2 The Event Loop and Async JavaScript
  42 | 
  43 | In React, you often use effects or callbacks that rely on JavaScript's asynchronous nature (like fetching data or debouncing inputs). Understanding the JavaScript **event loop** will clarify how tasks are handled without blocking the UI.
  44 | 
  45 | JavaScript has a **single-threaded** concurrency model based on an event loop. The runtime maintains a **call stack** (for function execution) and a **message queue** (for events and async callbacks). As an example:
  46 | 
  47 | - When you call functions, each call is pushed onto the stack, and popped off when it returns.
  48 | - Asynchronous tasks (like `setTimeout` callbacks, promises, or DOM events) are placed in a queue (or *microtask* queue for promises) to be processed later.
  49 | - The event loop continuously checks the queue and moves ready tasks to the stack **when the stack is free** ([Concurrency model and Event Loop - JavaScript | MDN](https://lia.disi.unibo.it/materiale/JS/developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop.html#:~:text=Queue)). In other words, *"when the stack is empty, a message (task) is taken out of the queue and processed by calling its associated function, until the stack is empty again"* ([Concurrency model and Event Loop - JavaScript | MDN](https://lia.disi.unibo.it/materiale/JS/developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop.html#:~:text=Queue)).
  50 | 
  51 | This design ensures the UI isn't blocked while waiting for long operations – the browser can handle other work (like rendering or user input) while JavaScript awaits events. For instance, when you do a `fetch().then(...)` in Vanilla JS, the `.then` callback goes to the queue and runs only after the current call stack is clear. Knowing this helps you avoid pitfalls like updating DOM outside of an event or race conditions with state.
  52 | 
  53 | ### 1.3 Prototypes and Objects
  54 | 
  55 | React uses class components (less nowadays) and plain objects for props/state. In Vanilla JS, understanding prototypes is key for working with objects and even for creating classes.
  56 | 
  57 | **Prototypal Inheritance:** JavaScript uses prototypes for inheritance. Every object has an internal link to a prototype object, from which it can inherit properties. As MDN notes, *"Prototypes are the mechanism by which JavaScript objects inherit features from one another."* ([Object prototypes - Learn web development | MDN](https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Advanced_JavaScript_objects/Object_prototypes#:~:text=Prototypes%20are%20the%20mechanism%20by,an%20object%20can%20be%20set)). When you access a property on an object, the JS engine will first look at the object itself, and if not found, it will climb up the prototype chain to see if the property exists on the prototype, then the prototype's prototype, and so on.
  58 | 
  59 | For example, if you create an array `let arr = [1,2,3]`, `arr` automatically inherits methods like `push` and `pop` from `Array.prototype`. This is why `arr.push(4)` works even though you didn't define `push` on `arr` – it's inherited.
  60 | 
  61 | You can leverage prototypes directly (using `Object.create` or setting `MyConstructor.prototype`) or use the newer class syntax which under the hood uses prototypes. For instance:
  62 | 
  63 | ```js
  64 | class Car {
  65 |   constructor(model) {
  66 |     this.model = model;
  67 |   }
  68 |   drive() {
  69 |     console.log(`${this.model} is driving`);
  70 |   }
  71 | }
  72 | const c = new Car('Tesla');
  73 | c.drive(); // "Tesla is driving"
  74 | ```
  75 | 
  76 | Here `Car.prototype.drive` is what provides the `drive` method to instances. Understanding this will help when we create multiple components or want to structure our code with classes in later chapters. It's also useful when reading framework code – many libraries use prototypal patterns under the hood.
  77 | 
  78 | ### 1.4 The `this` Keyword
  79 | 
  80 | In React's functional components, you may not deal with `this` much (aside from maybe in class components or event handlers). But in Vanilla JS, especially when working with DOM events or object methods, `this` is still important. It refers to the context object on which a function is invoked. For example:
  81 | 
  82 | ```js
  83 | const player = {
  84 |   name: 'Alice',
  85 |   greet() {
  86 |     console.log(`Hello, ${this.name}`);
  87 |   }
  88 | };
  89 | player.greet(); // "Hello, Alice"
  90 | ```
  91 | 
  92 | In `player.greet()`, `this` refers to `player`. However, if you detach the method, e.g. `const hello = player.greet; hello();`, `this` would be `undefined` (or the global object in non-strict mode) because it's called without an owner. We'll see this in DOM event handlers: `this` inside a handler refers to the element that received the event. We'll mostly use modern arrow functions and `bind` where necessary to control `this`, but keep this behavior in mind.
  93 | 
  94 | ### 1.5 Summary
  95 | 
  96 | These fundamentals – **closures**, **event loop**, **prototypes**, and **this** – form the foundation for the patterns we'll implement. If they feel abstract now, don't worry. As we build actual projects, we'll reinforce these concepts in context. Feel free to refer back to this chapter as needed. Next, we'll start building the pieces of a user interface with Vanilla JS, much like how React composes a UI from components.
  97 | 
  98 | *(You've completed the foundational crash course! If you want a quick refresher via an AI assistant, you could ask: "Explain JavaScript closures, the event loop, and prototypes in simple terms with examples." But otherwise, onward to building UIs without React!)*
  99 | 
 100 | ## Chapter 2. Building and Updating the DOM: Views Without React
 101 | 
 102 | One of React's core strengths is abstracting the DOM and handling updates efficiently via a virtual DOM. In Vanilla JS, **you are the framework** – you'll create, update, and remove DOM elements directly. This chapter will show you how to build a dynamic UI from scratch and keep it updated when state changes, mimicking what React does with components and JSX.
 103 | 
 104 | ### 2.1 Creating DOM Elements and Rendering Content
 105 | 
 106 | In React, you'd write JSX like `<button>Hello</button>` and it magically appears. In Vanilla JS, you explicitly create a DOM node and attach it. There are two main ways:
 107 | 
 108 | - **Using HTML strings** and `innerHTML`/`insertAdjacentHTML`: e.g. `container.innerHTML = "<button>Hello</button>"`.
 109 | - **Using DOM APIs**: e.g. `document.createElement('button')` and then setting properties.
 110 | 
 111 | Let's try the DOM API approach, as it's safer (avoids parsing HTML that could include scripts, etc.):
 112 | 
 113 | ```js
 114 | // Vanilla JS render example
 115 | const appRoot = document.getElementById('app');  // assume <div id="app"></div> in HTML
 116 | const helloBtn = document.createElement('button');
 117 | helloBtn.textContent = 'Hello';  // equivalent to setting innerText
 118 | appRoot.appendChild(helloBtn);
 119 | ```
 120 | 
 121 | Three lines replaced what JSX would do in one, but it's straightforward: we created a `<button>` element and set its text content, then appended it to a container in the DOM. We can also set attributes or classes:
 122 | 
 123 | ```js
 124 | helloBtn.className = 'btn primary';      // add CSS classes
 125 | helloBtn.setAttribute('data-value', '42'); // custom attribute example
 126 | ```
 127 | 
 128 | For more complex structures, creating many elements by hand can be verbose. Alternatives include:
 129 | - Building a string of HTML and using `container.innerHTML = ...` (just be cautious about user-generated content to avoid injection issues).
 130 | - Using the `<template>` tag in HTML to define HTML fragments and cloning them in JS.
 131 | - Using libraries like lit-html or a minimal templating utility (though that drifts away from pure Vanilla JS – our focus is to do without additional libraries).
 132 | 
 133 | We'll explore a simple templating approach in projects, but for now remember: **in Vanilla JS, you control the DOM directly**.
 134 | 
 135 | ### 2.2 Updating the DOM Efficiently
 136 | 
 137 | React's virtual DOM diffing gives the illusion that you can re-render the whole UI on each state change. With Vanilla JS, you *could* do something similar (e.g. clear a list and rebuild it on update), but you can also optimize by updating only the specific parts that changed.
 138 | 
 139 | For example, imagine a simple counter displayed in a `<span>` and a "+1" button. In React, you'd call `setState` and React would update the DOM for you. In Vanilla JS:
 140 | 
 141 | - Keep a reference to the DOM node that displays the counter.
 142 | - When the counter state changes, update that node's text.
 143 | 
 144 | ```js
 145 | let count = 0;
 146 | const counterEl = document.createElement('span');
 147 | counterEl.textContent = count;
 148 | appRoot.appendChild(counterEl);
 149 | 
 150 | const incButton = document.createElement('button');
 151 | incButton.textContent = 'Increment';
 152 | appRoot.appendChild(incButton);
 153 | 
 154 | incButton.addEventListener('click', () => {
 155 |   count++;
 156 |   counterEl.textContent = count; // update only the text node
 157 | });
 158 | ```
 159 | 
 160 | This way, no unnecessary DOM nodes are created or removed – we just mutate the existing element's content. For simple apps, manual updates are fine. As apps grow, you might organize updates in a more systematic way (we'll discuss state management in the next chapter).
 161 | 
 162 | **Batching and reflows:** A quick performance tip – frequent DOM manipulations can cause reflows (layout calculations). If updating many pieces at once, batch them (e.g. use a fragment or do all changes inside a `requestAnimationFrame` callback). In practice, frameworks handle this, but as a Vanilla JS developer you should be mindful. Modern browsers are fast, though, so focus on correctness first, optimize if needed.
 163 | 
 164 | ### 2.3 Handling User Events
 165 | 
 166 | Interactivity is where "views" come to life. In React, you'd attach event handlers in JSX (e.g. `onClick={...}`). In Vanilla JS, use the DOM API `addEventListener` to listen for events on elements.
 167 | 
 168 | Example – toggling a CSS class on click (like a favorite star toggling filled/outline):
 169 | 
 170 | ```js
 171 | const star = document.createElement('span');
 172 | star.textContent = '☆';          // a star icon, could use Unicode or <svg> in real case
 173 | star.style.cursor = 'pointer';   // make it look clickable
 174 | let starred = false;
 175 | star.addEventListener('click', () => {
 176 |   starred = !starred;
 177 |   star.textContent = starred ? '★' : '☆'; // filled star vs outline
 178 | });
 179 | appRoot.appendChild(star);
 180 | ```
 181 | 
 182 | A few things to note:
 183 | - We used a closure here (`starred` variable from outer scope) to keep track of state across clicks – a Vanilla JS analog to React's internal state.
 184 | - The event callback updates the DOM (switching the star character). This is an example of a **UI update based on an event**.
 185 | - `addEventListener` attaches the handler. There's also an older way: setting `star.onclick = () => {...}`, but `addEventListener` is preferred because you can add multiple listeners and have more control.
 186 | 
 187 | **Event delegation:** In dynamic lists (say a list of to-do items), adding separate listeners to each item can be inefficient. A common Vanilla JS pattern is event delegation: attach one listener on a parent (like the `<ul>`) and in the handler, check the event target to decide what to do. This way, as items are added/removed, you don't need to constantly attach/detach listeners. We'll use this pattern in our projects.
 188 | 
 189 | ### 2.4 Comparing to React: Imperative vs Declarative
 190 | 
 191 | By now you might notice a shift in thinking:
 192 | - **React (Declarative):** You declare how the UI should look based on state, and React takes care of updating the DOM to match that state. You rarely manipulate the DOM directly.
 193 | - **Vanilla JS (Imperative):** You often explicitly tell the DOM what to do: create this element, update this text, remove that node, etc. 
 194 | 
 195 | There's no virtual DOM diff in between – *you* are effectively doing what React would do for you.
 196 | 
 197 | For instance, in React you might have:
 198 | 
 199 | ```jsx
 200 | // React pseudo-code
 201 | function Counter() {
 202 |   const [count, setCount] = useState(0);
 203 |   return (
 204 |     <div>
 205 |       <span>{count}</span>
 206 |       <button onClick={() => setCount(count+1)}>Increment</button>
 207 |     </div>
 208 |   );
 209 | }
 210 | ```
 211 | 
 212 | In Vanilla JS, we manually wrote the equivalent: keeping track of `count`, updating the `<span>` text, etc. It's more code, but it demystifies what frameworks do.
 213 | 
 214 | **Tip:** You can still structure your Vanilla JS in a declarative style by writing small functions that render pieces of UI given some data. For example, `function renderUser(user) { ...create DOM for user... }`. This can help maintain clarity as your app grows, and it's something we'll explore (essentially creating our own tiny UI library patterns).
 215 | 
 216 | ### 2.5 Chapter Challenge
 217 | 
 218 | We've covered creating and updating DOM elements and handling user interactions. As a quick exercise (before moving on to formal state management in the next chapter), try this: **build a simple like counter widget in Vanilla JS.** It has a "Like" button and a count of likes. Each click increases the count. Use what we discussed: create elements, attach event, update text. *(If you need a hint or want to verify, consider prompting an AI with "vanilla JS code for a like button with counter").*
 219 | 
 220 | In the next chapter, we'll tackle state management – how to manage and structure data (beyond trivial cases like a single counter) in a Vanilla JS app, similar to how you might use React's state and context or Redux.
 221 | 
 222 | ## Chapter 3. Managing State in Vanilla JavaScript
 223 | 
 224 | State management is the heart of any dynamic app. In React, you use `useState`, `useReducer`, Context, or external libraries like Redux/MobX to handle state. Without React, **you still need to manage state** – there's just no built-in global solution, so you'll use plain objects, closures, or custom patterns. The good news is that JavaScript is flexible enough to implement your own light state management.
 225 | 
 226 | ### 3.1 What is "State" Outside React?
 227 | 
 228 | Simply put, **state is any data that influences what's shown on the UI,** which can change over time. In a Vanilla JS app, state can live in:
 229 | - **Variables/objects in your script module:** e.g. an array of todo items in memory.
 230 | - **The DOM itself:** e.g. the checked status of a checkbox input, content of an input field, etc., are forms of state stored in DOM properties.
 231 | - **Browser APIs:** e.g. `localStorage` for persistent state across page loads, or the URL (which holds state in query params or hash).
 232 | - **In-memory singleton store:** You might create a custom object or use an ES6 class or closure to hold global state and notify parts of your app to update (similar to a Redux store but simpler).
 233 | 
 234 | Let's consider a simple global state example. Suppose we want a state object that holds a count and allows components to subscribe to changes:
 235 | 
 236 | ```js
 237 | // A simple state store in Vanilla JS
 238 | const appState = (() => {
 239 |   let state = { count: 0 };
 240 |   const listeners = [];
 241 |   return {
 242 |     getState() {
 243 |       return state;
 244 |     },
 245 |     setState(newState) {
 246 |       state = { ...state, ...newState };
 247 |       listeners.forEach(fn => fn(state));
 248 |     },
 249 |     subscribe(fn) {
 250 |       listeners.push(fn);
 251 |       return () => { // return unsubscribe function
 252 |         const index = listeners.indexOf(fn);
 253 |         if (index > -1) listeners.splice(index, 1);
 254 |       };
 255 |     }
 256 |   };
 257 | })();
 258 | ```
 259 | 
 260 | This is a very trimmed-down store (inspired by Redux patterns). It uses a closure to hold a private `state` and `listeners`. Components can call `appState.subscribe(renderFunction)` to be notified when state changes, and `appState.setState({count: 5})` to update state. For example:
 261 | 
 262 | ```js
 263 | // Component A: display count
 264 | const countDisplay = document.createElement('div');
 265 | function renderCount(state) {
 266 |   countDisplay.textContent = `Count: ${state.count}`;
 267 | }
 268 | appState.subscribe(renderCount);
 269 | renderCount(appState.getState());
 270 | appRoot.appendChild(countDisplay);
 271 | 
 272 | // Component B: increment button
 273 | const incBtn = document.createElement('button');
 274 | incBtn.textContent = "Increment";
 275 | incBtn.onclick = () => {
 276 |   const current = appState.getState().count;
 277 |   appState.setState({ count: current + 1 });
 278 | };
 279 | appRoot.appendChild(incBtn);
 280 | ```
 281 | 
 282 | Now, whenever `incBtn` is clicked, the state's count is updated and our subscribed render function updates the display. We've essentially mimicked a React `useState` + re-render in Vanilla JS! This approach uses the **observer pattern** (listeners). It's rudimentary but works for small apps. We'll refine how we organize state as we proceed.
 283 | 
 284 | ### 3.2 Module Pattern and Closures for State
 285 | 
 286 | Using closures (like the IIFE above) is one way to encapsulate state. Another common pattern is to simply use an ES module. Since each module is a singleton (evaluated once), you can have a `state.js` module:
 287 | 
 288 | ```js
 289 | // state.js
 290 | export const state = {
 291 |   todos: [],
 292 |   filter: 'all'
 293 | };
 294 | ```
 295 | 
 296 | Any module that imports `state` will get a reference to the same object. If one part of your code modifies `state.todos`, other parts see the change. This is a simple, albeit *ad hoc*, state container. The downside is you don't have an event system to notify of changes. You might combine this with custom events (discussed next) or manual function calls to update UI.
 297 | 
 298 | ### 3.3 Using Custom Events to Manage State Changes
 299 | 
 300 | Browsers provide a `CustomEvent` constructor that lets you create and dispatch your own events. This can be a lightweight way to communicate state changes without a full pub-sub implementation.
 301 | 
 302 | For example, we could dispatch a custom event whenever our state updates:
 303 | 
 304 | ```js
 305 | // When state changes:
 306 | const event = new CustomEvent('stateChange', { detail: state });
 307 | document.dispatchEvent(event);
 308 | ```
 309 | 
 310 | And elsewhere:
 311 | 
 312 | ```js
 313 | document.addEventListener('stateChange', e => {
 314 |   const newState = e.detail;
 315 |   // update UI accordingly
 316 | });
 317 | ```
 318 | 
 319 | This approach treats the `document` (or any central element) as an event bus. It's not too far from how Redux might inform subscribers (though Redux doesn't use DOM events). The benefit is decoupling – components don't need to import a specific state module; they can listen for events.
 320 | 
 321 | We mention this pattern for completeness. In our projects, we might not need to go this far – often simply calling a render function after state change is enough. But remember, as apps grow, patterns like these become useful.
 322 | 
 323 | ### 3.4 State in the DOM vs. State in Memory
 324 | 
 325 | Sometimes the DOM itself holds the state you need. For instance, the value of a text input is in the DOM (input's `.value`). You could treat that as the source of truth. Other times, you may want to sync the DOM state to your JavaScript state (e.g. on input change, save it to a `state.formData` object).
 326 | 
 327 | Deciding the single source of truth is important. A general rule:
 328 | - Use in-memory state (objects, etc.) as the source of truth for application data.
 329 | - Use DOM state for ephemeral UI state that doesn't need to be stored long term (e.g. current value of a search field, which you can always read directly when you need it).
 330 | 
 331 | If you keep multiple sources of truth, ensure they stay in sync. For example, if you have `state.filter = 'all'` and also some `<select>` with filter options, updating one should update the other.
 332 | 
 333 | We'll see this in projects, e.g. a todo app where the checkbox's checked state represents the todo's completed property – we'll update the data and the DOM together.
 334 | 
 335 | ### 3.5 Local Storage and Persistence
 336 | 
 337 | One big advantage of writing direct browser code: you have access to `localStorage`, `sessionStorage`, IndexDB, etc., without extra libraries. `localStorage` is a simple key-value store that persists data across page loads for the same domain. It's synchronous but fine for small amounts of data (5-10MB in most browsers).
 338 | 
 339 | In Vanilla JS apps, it's common to save state to `localStorage` so that if the user refreshes, they don't lose their data (e.g. keeping our to-do list saved).
 340 | 
 341 | Example: Saving and loading state from `localStorage`:
 342 | 
 343 | ```js
 344 | // Save todos array to localStorage
 345 | localStorage.setItem('todos', JSON.stringify(state.todos));
 346 | 
 347 | // Later, on page load, initialize state from storage:
 348 | const saved = localStorage.getItem('todos');
 349 | if (saved) {
 350 |   state.todos = JSON.parse(saved);
 351 |   renderTodos();  // update UI to reflect saved todos
 352 | }
 353 | ```
 354 | 
 355 | We'll implement this in our to-do app project. It's the Vanilla JS equivalent of using a persistence layer or calling an API in a React app.
 356 | 
 357 | ### 3.6 Summary
 358 | 
 359 | Managing state in Vanilla JS might seem manual, but it boils down to:
 360 | - **Where you store the data** (in-memory object, closure, etc.)
 361 | - **How you update the data** (simple assignment or through a function like `setState`)
 362 | - **How you notify the UI** to update (direct function calls, events, or re-render logic).
 363 | 
 364 | By understanding these mechanics, you could even write your own mini-state library if needed. In fact, many devs have created "framework-free" state management systems using exactly the patterns described ([Managing State in Small Apps - DEV Community](https://dev.to/vicradon/managing-state-in-small-apps-25kd#:~:text=Managing%20State%20in%20Small%20Apps,management%20because%20variables%20weren%27t%20enough)).
 365 | 
 366 | Up next, we'll discuss how to structure a larger UI by composing pieces – essentially, how to mimic React components with Vanilla JS, so our code stays maintainable as the app grows.
 367 | 
 368 | *(AI Assistant Prompt: "Show an example of a simple state store in plain JavaScript with subscribe/unsubscribe functionality." – Use this to compare with our `appState` example and deepen your understanding.)*
 369 | 
 370 | ## Chapter 4. Component Composition and Code Organization
 371 | 
 372 | One reason for React's popularity is the **component model** – breaking the UI into self-contained, reusable pieces that manage their own state and logic. In Vanilla JS, we don't have a built-in component system, but we can **create our own structures and patterns** to achieve similar modularity. This chapter explores ways to compose UIs from smaller parts using functions, classes, and web standards.
 373 | 
 374 | ### 4.1 Thinking in Components (Without a Framework)
 375 | 
 376 | Even without React, it's wise to break your UI into logical chunks. For example, a to-do app might have a header, a list, and a form. We can represent each chunk with a function that creates its DOM elements and returns an element or a set of elements.
 377 | 
 378 | **Functional Components in Vanilla JS:** You can write a function that returns a DOM node. For instance:
 379 | 
 380 | ```js
 381 | function createTodoItem(todo) {
 382 |   const li = document.createElement('li');
 383 |   li.textContent = todo.title;
 384 |   if (todo.done) li.classList.add('done');
 385 |   li.addEventListener('click', () => {
 386 |     todo.done = !todo.done;
 387 |     li.classList.toggle('done');
 388 |   });
 389 |   return li;
 390 | }
 391 | ```
 392 | 
 393 | This function takes some data (`todo`) and returns a DOM element (`<li>`). You could use it like:
 394 | 
 395 | ```js
 396 | const list = document.createElement('ul');
 397 | state.todos.forEach(todo => {
 398 |   list.appendChild(createTodoItem(todo));
 399 | });
 400 | ```
 401 | 
 402 | We've essentially made a Vanilla JS "component" for a todo list item, with internal behavior (toggling done). It's not as robust as a React component (no lifecycle beyond what we coded, and it directly uses the `todo` object), but it's a building block.
 403 | 
 404 | **Composite Components:** We can have one component use another. For example, a `TodoList` component could loop through todos and call `createTodoItem` for each, as above. Or a `Header` component could create a title element and perhaps some buttons, and return a `<header>` element containing them.
 405 | 
 406 | By composing functions, you keep each part focused and reuse them easily.
 407 | 
 408 | ### 4.2 Encapsulating Behavior with Classes
 409 | 
 410 | ES6 classes provide a convenient way to bundle state, DOM creation, and event handlers in one place. You can think of a class instance as a component instance.
 411 | 
 412 | For example, let's create a simple **Counter component** as a class:
 413 | 
 414 | ```js
 415 | class CounterComponent {
 416 |   constructor(initialCount = 0) {
 417 |     this.count = initialCount;
 418 |     // Create DOM elements
 419 |     this.el = document.createElement('div');
 420 |     this.display = document.createElement('span');
 421 |     this.display.textContent = this.count;
 422 |     const incBtn = document.createElement('button');
 423 |     incBtn.textContent = '+1';
 424 |     // Append elements
 425 |     this.el.appendChild(this.display);
 426 |     this.el.appendChild(incBtn);
 427 |     // Event handler
 428 |     incBtn.addEventListener('click', () => this.increment());
 429 |   }
 430 |   increment() {
 431 |     this.count++;
 432 |     this.display.textContent = this.count;
 433 |   }
 434 |   mount(parent) {
 435 |     parent.appendChild(this.el);
 436 |   }
 437 | }
 438 | ```
 439 | 
 440 | Using it:
 441 | 
 442 | ```js
 443 | const counter = new CounterComponent(5);
 444 | counter.mount(document.body);
 445 | ```
 446 | 
 447 | This class encapsulates the counter's state (`this.count`), the DOM (`this.el` and children), and the logic to update (`increment`). The `mount` method attaches the component to a parent. We could also add an `unmount` method if we wanted to remove it and do any cleanup (in this simple case, removing the DOM node removes the event listener automatically because it's tied to that node).
 448 | 
 449 | This pattern is similar to how one might write a component in plain JS or even using something like Stimulus or other light frameworks. It's imperative, but organized.
 450 | 
 451 | **Pros:** You keep related code together. If the component gets more complex (say a counter with +/- and reset), the class can hold all that logic.
 452 | 
 453 | **Cons:** It's a bit verbose, and you need to be careful with `this` binding (we used an arrow function for the event, which captures `this` correctly).
 454 | 
 455 | We won't necessarily use classes for every component in the book, but it's good to know this option, especially for widgets that manage their internal state extensively.
 456 | 
 457 | ### 4.3 Templates and HTML Fragments
 458 | 
 459 | Another approach to defining a component's structure is using HTML templates. The `<template>` tag in HTML is inert content that you can clone in JS. For example:
 460 | 
 461 | ```html
 462 | <template id="itemTemplate">
 463 |   <li class="item">
 464 |     <span class="title"></span>
 465 |     <button class="delete">✕</button>
 466 |   </li>
 467 | </template>
 468 | ```
 469 | 
 470 | In JS:
 471 | 
 472 | ```js
 473 | const template = document.getElementById('itemTemplate');
 474 | function renderItem(item) {
 475 |   const fragment = template.content.cloneNode(true);
 476 |   fragment.querySelector('.title').textContent = item.title;
 477 |   fragment.querySelector('.delete').onclick = () => removeItem(item);
 478 |   return fragment;
 479 | }
 480 | ```
 481 | 
 482 | This returns a DocumentFragment containing a populated `<li>` for the item. Using templates can separate HTML structure from JS logic, which some developers prefer. It's somewhat analogous to JSX – you design the structure in HTML and fill in data via JS.
 483 | 
 484 | We won't heavily rely on templates in our examples (to keep everything in one place in examples), but be aware of this tool for larger projects or when you have a lot of static HTML to generate.
 485 | 
 486 | ### 4.4 Web Components (Custom Elements)
 487 | 
 488 | Web Components are a set of web platform APIs for creating reusable custom elements with encapsulated HTML, styling, and behavior. They are truly the browser's answer to a component system. You can define a class that extends `HTMLElement` and then use your element via a custom tag.
 489 | 
 490 | Basic example of a Web Component:
 491 | 
 492 | ```js
 493 | class HelloWorld extends HTMLElement {
 494 |   connectedCallback() {
 495 |     this.textContent = "Hello, World!";
 496 |   }
 497 | }
 498 | customElements.define('hello-world', HelloWorld);
 499 | ```
 500 | 
 501 | Now in HTML/JS, you can do `<hello-world></hello-world>` and it will invoke that class. Web Components can even have their own internal shadow DOM for encapsulated styling.
 502 | 
 503 | While powerful, Web Components can be overkill for our needs here. They shine for creating UI libraries or design systems that can be used across frameworks. In our context – converting React devs to Vanilla JS – we typically won't need full custom elements. However, it's good to know that the platform offers this. If you find yourself reinventing a lot of component management, exploring Web Components might be worthwhile.
 504 | 
 505 | ### 4.5 Organizing Files and Modules
 506 | 
 507 | As you build components, consider splitting them into modules (files). Maybe you have `components/Header.js`, `components/TodoList.js`, etc., which export functions or classes. Then your main script can import those and assemble the app. For example:
 508 | 
 509 | ```js
 510 | // main.js
 511 | import { Header } from './components/Header.js';
 512 | import { TodoList } from './components/TodoList.js';
 513 | 
 514 | document.body.appendChild(Header());
 515 | document.body.appendChild(TodoList());
 516 | ```
 517 | 
 518 | Using ES module imports keeps each file focused. In a no-build setup, you can include `<script type="module" src="main.js"></script>` in your HTML and it will load imports (note: you must serve via HTTP, not file://, due to module CORS restrictions).
 519 | 
 520 | We'll use modules in later chapters when introducing bundling and for organizing project code. For now, know that the **composition doesn't only happen in code structures but in how you lay out your codebase**.
 521 | 
 522 | ### 4.6 Reusability and Parameterization
 523 | 
 524 | A Vanilla JS "component" can be made configurable by parameters. For instance, a `createButton(text, onClick)` function can generate different buttons as needed. This is similar to React props.
 525 | 
 526 | ```js
 527 | function createButton(label, onClick) {
 528 |   const btn = document.createElement('button');
 529 |   btn.textContent = label;
 530 |   if (onClick) btn.addEventListener('click', onClick);
 531 |   return btn;
 532 | }
 533 | // usage
 534 | const saveBtn = createButton('Save', () => saveData());
 535 | const cancelBtn = createButton('Cancel', () => cancel());
 536 | ```
 537 | 
 538 | By passing callbacks and other data, you make your Vanilla components flexible. Composing these, you might build an entire toolbar or form out of small pieces.
 539 | 
 540 | ### 4.7 Summary
 541 | 
 542 | We've explored multiple strategies to compose and reuse UI pieces without React:
 543 | - Functions that return DOM (like our `createTodoItem`).
 544 | - Classes to encapsulate more complex components (`CounterComponent`).
 545 | - Template-driven rendering.
 546 | - Even Web Components as an advanced option.
 547 | 
 548 | In practice, you might mix and match these. For example, use simple functions for straightforward markup and a class for something with interactive internal state.
 549 | 
 550 | The key is **modularity**: keeping code for each piece together and making it easy to assemble pieces into a full app.
 551 | 
 552 | In upcoming project chapters, we will apply these techniques. You'll see how a to-do app can be built from small functions, or how a movie app can separate concerns (search bar, movie list, movie details) into distinct units of code.
 553 | 
 554 | *(AI Assistant Tip: To experiment, ask "How can I create a reusable modal dialog component with Vanilla JS classes?" This can show you another real-world use of classes for components and reinforce the concepts.)*
 555 | 
 556 | ## Chapter 5. Routing: Single-Page Application Navigation
 557 | 
 558 | Most modern apps are **Single-Page Applications (SPAs)**, meaning they update the UI without full page reloads, even as the user navigates to different "pages" or views. In React, you might use React Router to handle this. In Vanilla JS, we can achieve routing using the **History API** (or the older hash-based approach). This chapter covers implementing client-side routing from scratch.
 559 | 
 560 | ### 5.1 The Browser History API
 561 | 
 562 | The History API lets us modify the browser's URL and history stack without reloading the page. Key parts of the API:
 563 | - `history.pushState(stateObj, title, url)` – adds a new entry to the history stack with a new URL (the domain must remain the same) ([How do you use `window.history` API? - GreatFrontEnd](https://www.greatfrontend.com/questions/quiz/how-do-you-use-windowhistory-api#:~:text=How%20do%20you%20use%20,entry%20to%20the%20history%20stack)).
 564 | - `history.replaceState(stateObj, title, url)` – replaces the current entry.
 565 | - The **`popstate`** event – fired on the window when the active history entry changes (e.g., user clicks Back or forward, or you call pushState).
 566 | 
 567 | Using `pushState`, we can change the URL as if navigating. For example:
 568 | 
 569 | ```js
 570 | // Navigate to "/about" without reloading
 571 | history.pushState({}, "", "/about");
 572 | ```
 573 | 
 574 | This will change the URL shown in the address bar to `/about`. If the user hits enter or refresh at this point, the server needs to handle `/about` (or you need a fallback to index.html). But within our SPA, after calling pushState, we should update the UI to show the "About" content. 
 575 | 
 576 | Listening to `popstate` allows us to respond to back/forward navigation. For instance:
 577 | 
 578 | ```js
 579 | window.addEventListener('popstate', (event) => {
 580 |   // event.state contains the stateObj we passed (if any)
 581 |   renderCurrentRoute();
 582 | });
 583 | ```
 584 | 
 585 | We'll likely use `location.pathname` to determine what to show.
 586 | 
 587 | ### 5.2 Implementing a Simple Router
 588 | 
 589 | Let's sketch a basic router for our Vanilla JS app. Suppose we want three "routes": Home, About, and a dynamic route for a user profile (e.g., `/user/123`).
 590 | 
 591 | We can define a function `routeTo(path)` that uses pushState and then calls a render:
 592 | 
 593 | ```js
 594 | function routeTo(path) {
 595 |   history.pushState({}, "", path);
 596 |   renderCurrentRoute();
 597 | }
 598 | ```
 599 | 
 600 | And `renderCurrentRoute` might look like:
 601 | 
 602 | ```js
 603 | function renderCurrentRoute() {
 604 |   const path = location.pathname;
 605 |   appRoot.innerHTML = ""; // clear existing UI or use a specific outlet element
 606 |   if (path === "/") {
 607 |     appRoot.appendChild(renderHome());
 608 |   } else if (path === "/about") {
 609 |     appRoot.appendChild(renderAbout());
 610 |   } else if (path.startsWith("/user/")) {
 611 |     const userId = path.split("/")[2];
 612 |     appRoot.appendChild(renderUserProfile(userId));
 613 |   } else {
 614 |     appRoot.appendChild(renderNotFound());
 615 |   }
 616 | }
 617 | ```
 618 | 
 619 | Here, `renderHome`, `renderAbout`, etc., are functions that return DOM content for those screens (these would be like our components or page modules). We clear the `appRoot` (assumed to be a container div) and append the new content.
 620 | 
 621 | We also need to handle clicks on links. Normally, an `<a href="/about">About</a>` click would do a full page load. We can intercept clicks and call `routeTo` instead:
 622 | ```js
 623 | document.addEventListener('click', e => {
 624 |   const link = e.target.closest('a');
 625 |   if (link && link.getAttribute('href').startsWith("/")) {
 626 |     e.preventDefault();
 627 |     routeTo(link.getAttribute('href'));
 628 |   }
 629 | });
 630 | ```
 631 | This uses event delegation to catch any anchor click where the href is a path (we ensure it's not an external link by checking it starts with "/"). We prevent the default navigation and instead do client-side routing.
 632 | 
 633 | Now our app can navigate between views without reload. This is essentially what React Router does behind the scenes (minus a lot of bells and whistles).
 634 | 
 635 | **Hash-based Routing:** As an alternative, you can use the URL hash (`location.hash`) to track state. E.g., `example.com/index.html#about`. This is simpler (the `hashchange` event fires when `window.location.hash` changes), and doesn't require server-side handling for different paths. However, it makes your URLs a bit uglier (`#` fragment) and is generally less powerful. Still, if you can't configure your server to handle SPA routes, hash routing is a fallback. For brevity, we focus on History API routing here.
 636 | 
 637 | ### 5.3 Dynamic Routes and Parameters
 638 | 
 639 | As shown with `/user/123`, you can parse `location.pathname` to extract IDs or names. You might create a simple router configuration:
 640 | 
 641 | ```js
 642 | const routes = [
 643 |   { path: /^\/$/, render: renderHome },
 644 |   { path: /^\/about$/, render: renderAbout },
 645 |   { path: /^\/user\/(\d+)$/, render: (id) => renderUserProfile(id) }
 646 | ];
 647 | ```
 648 | 
 649 | Then in `renderCurrentRoute`, find the first route whose regex matches the current path:
 650 | ```js
 651 | for (let route of routes) {
 652 |   const match = route.path.exec(path);
 653 |   if (match) {
 654 |     const params = match.slice(1); // capture groups as params
 655 |     const page = route.render(...params);
 656 |     appRoot.innerHTML = "";
 657 |     appRoot.appendChild(page);
 658 |     return;
 659 |   }
 660 | }
 661 | // if no match, render 404
 662 | appRoot.innerHTML = "";
 663 | appRoot.appendChild(renderNotFound());
 664 | ```
 665 | 
 666 | This way, our router can handle patterns and pass parameters. We're essentially building a mini router. For complex apps, you might consider using a small routing library even in Vanilla JS, but our goal is to demystify, so rolling our own is fine.
 667 | 
 668 | ### 5.4 Preserving Application State Between Routes
 669 | 
 670 | One tricky part: when we "navigate" (pushState) and rebuild the UI, what happens to our state? For example, if you have a list of items loaded on Home, then go to About and back, do you reload the list or keep it?
 671 | 
 672 | In a SPA, since we never truly unload the page, we can keep state in memory. Our `appState` or other global variables remain. It's up to us to decide if we recreate components or preserve them. 
 673 | 
 674 | A simple approach:
 675 | - When leaving a route, you could save some state (maybe in a global or in history state).
 676 | - When entering, check if you already have the data.
 677 | 
 678 | For instance, if our Home view fetches data, we might store it in `state.homeData`. Next time we render Home, see if `state.homeData` exists to avoid refetching.
 679 | 
 680 | Alternatively, use the History state object: `pushState({ someData }, "", "/path")` and retrieve it via `event.state` in popstate. This is more advanced and often not necessary unless you want to restore scroll positions or form data on back navigation.
 681 | 
 682 | For our purposes, we'll keep it simple: global state (or module-level state) stays alive throughout page navigation.
 683 | 
 684 | ### 5.5 Integrating Routing into Our Projects
 685 | 
 686 | When we build the movie app or others, we may incorporate routing. For example, in the movie app, clicking a movie could push a `/movie/123` route and show details. We'll apply what we learned to make that happen.
 687 | 
 688 | One thing to be careful of: If the user directly visits `/movie/123` as a fresh load, our SPA code should handle it (likely by detecting the path on load and fetching the movie details). Also, server-side should ideally serve the base page for any route (or redirect to `index.html`) to ensure the SPA can boot up. This is beyond JavaScript's scope – it's a deployment/config task.
 689 | 
 690 | ### 5.6 Summary
 691 | 
 692 | We've created a basic client-side router:
 693 | - Used `history.pushState` to change URL without reload.
 694 | - Listened to `popstate` to handle back/forward.
 695 | - Intercepted link clicks to trigger our routing.
 696 | - Parsed dynamic segments from the URL.
 697 | 
 698 | With this in place, your Vanilla JS app can have multiple views just like a React app with React Router – and users can bookmark/share URLs for specific screens.
 699 | 
 700 | This manual approach gives insight into how routing works under the hood. It's not much code, and for many cases it's enough. For extremely complex routing (nested routes, etc.), you could still bring in a tiny library, but most SPAs can be handled with patterns like above.
 701 | 
 702 | *(Try It: Use an AI assistant to ask "How do I implement a single-page app router in vanilla JavaScript?" Compare the answer to our approach – you might find similar patterns or alternative techniques to learn from.)*
 703 | 
 704 | ## Chapter 6. Managing Side Effects and Lifecycle in Vanilla JS
 705 | 
 706 | In React, effects (via `useEffect` or lifecycle methods) let you run code on mount/unmount or when certain state changes, often for things like data fetching or integrating with external APIs (including the browser APIs). In Vanilla JS, you don't have a formal lifecycle, but you still need to manage **side effects** – e.g., fetch data when a view loads, set up an interval or subscription, and clean it up when done.
 707 | 
 708 | This chapter covers how to handle these scenarios explicitly.
 709 | 
 710 | ### 6.1 What Are "Effects" in Our Context?
 711 | 
 712 | A side effect is anything that affects something outside the function's scope or is affected by the outside world. Common examples in web apps:
 713 | - Network requests (fetching data from an API).
 714 | - Timer functions (setInterval, setTimeout).
 715 | - Subscribing to events (DOM events, WebSocket messages, etc.).
 716 | - Logging, localStorage access, etc.
 717 | 
 718 | In React, an effect might run on component mount (and optionally cleanup on unmount). In Vanilla JS, we'll typically run such code when we **render or show a component**, and ensure to stop/cleanup when we **hide or remove that component**.
 719 | 
 720 | ### 6.2 Data Fetching (Async Effects)
 721 | 
 722 | Let's say we have a profile view that needs to fetch user data from an API when it loads. In Vanilla JS:
 723 | - We can call the fetch function at the appropriate time (e.g., right after creating the view's DOM, or when routing to that view).
 724 | - We then update the DOM with the fetched data when it arrives.
 725 | 
 726 | Example pattern:
 727 | ```js
 728 | function renderUserProfile(userId) {
 729 |   const container = document.createElement('div');
 730 |   container.textContent = "Loading...";
 731 |   // Kick off fetch
 732 |   fetch(`https://api.example.com/users/${userId}`)
 733 |     .then(res => res.json())
 734 |     .then(data => {
 735 |       container.textContent = ""; // clear "Loading"
 736 |       container.appendChild(renderUserDetails(data));
 737 |     })
 738 |     .catch(err => {
 739 |       container.textContent = "Error loading user.";
 740 |       console.error(err);
 741 |     });
 742 |   return container;
 743 | }
 744 | ```
 745 | 
 746 | Here, `renderUserProfile` initiates an effect (a data fetch) and returns a container that will eventually be filled. We immediately set some loading text to give feedback. When the promise resolves, we populate the content. This is analogous to a React component that on mount triggers a fetch and then re-renders with the data.
 747 | 
 748 | **Avoiding Memory Leaks:** If the user navigates away before the fetch completes, our callback still runs and tries to update `container`. In a SPA, `container` might still be in DOM if we didn't remove it, or if we removed it (on route change), updating it doesn't show anything but still occupies memory. This is generally fine, but in bigger apps you may want to abort fetches if not needed (using AbortController) or check if the element is still in DOM before updating.
 749 | 
 750 | ### 6.3 Timers and Intervals
 751 | 
 752 | Consider a component that shows the current time and updates every second. In React, you might use `useEffect` to set an interval on mount and clear it on unmount. In Vanilla JS:
 753 | 
 754 | ```js
 755 | function createClock() {
 756 |   const clockEl = document.createElement('div');
 757 |   function updateTime() {
 758 |     clockEl.textContent = new Date().toLocaleTimeString();
 759 |   }
 760 |   updateTime(); // initial call
 761 |   const timer = setInterval(updateTime, 1000);
 762 |   // we return an object with the element and a cleanup function
 763 |   return {
 764 |     el: clockEl,
 765 |     cleanup: () => clearInterval(timer)
 766 |   };
 767 | }
 768 | ```
 769 | 
 770 | Using it:
 771 | ```js
 772 | const { el: clockElement, cleanup: stopClock } = createClock();
 773 | document.body.appendChild(clockElement);
 774 | // ... later, if we want to remove the clock
 775 | stopClock();
 776 | clockElement.remove();
 777 | ```
 778 | 
 779 | This pattern explicitly returns a cleanup function. You have to remember to call it when appropriate (e.g., when navigating away or removing that UI). 
 780 | 
 781 | Alternatively, if this clock is part of a larger component class, you could make `cleanup` a method of the class (like `ClockComponent.stop()` that clears the interval).
 782 | 
 783 | There's no magic – it's on you to stop intervals, unsubscribe from events, etc., to prevent memory leaks or unwanted background tasks.
 784 | 
 785 | ### 6.4 Cleaning Up Event Listeners
 786 | 
 787 | If you attach event listeners to global objects (like `window` or `document`), be sure to remove them if they're no longer needed. For example, a component that listens to `window.resize` should probably remove that listener when the component is destroyed.
 788 | 
 789 | Example:
 790 | ```js
 791 | function createResizableBox() {
 792 |   const box = document.createElement('div');
 793 |   box.style.width = window.innerWidth + "px";
 794 |   // Handler to resize the box with window
 795 |   function onResize() {
 796 |     box.style.width = window.innerWidth + "px";
 797 |   }
 798 |   window.addEventListener('resize', onResize);
 799 |   return {
 800 |     el: box,
 801 |     cleanup: () => window.removeEventListener('resize', onResize)
 802 |   };
 803 | }
 804 | ```
 805 | 
 806 | Again, we package the `cleanup`. In a routed app, you might call all relevant cleanups when navigating away from a view. One strategy is to keep track: for each page, store an array of cleanup functions that should be called when leaving that page.
 807 | 
 808 | ### 6.5 Using MutationObserver for Automatic Cleanup (Advanced)
 809 | 
 810 | If you want to get fancy, the DOM provides a `MutationObserver` API that can watch for DOM nodes being removed. In theory, you could attach an observer to your component's root element and detect when it's removed from DOM, then trigger cleanup. This is advanced and not commonly needed, but worth mentioning.
 811 | 
 812 | For instance:
 813 | ```js
 814 | function createComponent() {
 815 |   const el = document.createElement('div');
 816 |   const observer = new MutationObserver((mutations) => {
 817 |     for(const m of mutations) {
 818 |       if ([...m.removedNodes].includes(el)) {
 819 |         // el was removed
 820 |         cleanup();
 821 |         observer.disconnect();
 822 |       }
 823 |     }
 824 |   });
 825 |   observer.observe(el.parentNode || document, { childList: true, subtree: true });
 826 |   // ... rest of component setup
 827 | }
 828 | ```
 829 | 
 830 | This is complex and assumes the element has a parent at time of observation. Usually, it's simpler to handle it in your app logic.
 831 | 
 832 | ### 6.6 Summary: Be Your Own useEffect
 833 | 
 834 | The takeaway: in Vanilla JS, **you manually manage lifecycle**:
 835 | - Run your setup code when needed (e.g., after inserting a component into DOM or when a route becomes active).
 836 | - Tear down when appropriate (before removing from DOM or on route change).
 837 | 
 838 | For small apps, you might not even need extensive cleanup – the garbage collector will clean intervals when the page unloads, and removing DOM elements removes their event listeners. But for long-running SPAs, proper cleanup is important to avoid performance issues.
 839 | 
 840 | We will implement some of these in the projects:
 841 | - In the movie app, fetching on page load and maybe clearing old content if navigating away.
 842 | - In a chat or live update scenario, we'd show how to stop intervals or WebSocket connections.
 843 | 
 844 | Always ask: "If I create this thing (timer, listener, etc.), when should I dispose of it?" If the answer is "when navigating away or removing the component," then ensure you have a code path for that.
 845 | 
 846 | *(AI practice: "How can I mimic React's useEffect cleanup in plain JavaScript?" The answer or discussion can further cement these ideas by seeing how others phrase the solution.)*
 847 | 
 848 | ## Chapter 7. Modularization: Organizing Code with ES6 Modules
 849 | 
 850 | As our Vanilla JS apps grow, organizing code into multiple files becomes crucial. In the past, before ES6 modules, we had to use global variables or module loaders. Now, browsers support ES6 modules natively, enabling a structured approach to code architecture similar to how you import/export in React projects (which usually use bundlers).
 851 | 
 852 | This chapter will show how to use JavaScript modules to structure a project, and how to load them in a no-build environment.
 853 | 
 854 | ### 7.1 Why Modules Matter
 855 | 
 856 | In a React app (with Create React App or similar), you're used to splitting code into different files and using `import/export`. This improves readability, maintainability, and reusability. The same applies to Vanilla JS:
 857 | - You can have one module handle state (`state.js`), another define a component (`TodoList.js`), etc.
 858 | - Modules help encapsulate implementation details. Variables or functions inside a module aren't global; they won't clutter the global namespace or conflict with others.
 859 | 
 860 | Without modules, if you include multiple `<script>` files, they all share the global scope, which can lead to name collisions or ordering issues. Modules avoid that by default – each module has its own scope.
 861 | 
 862 | ### 7.2 Using ES6 Modules in the Browser
 863 | 
 864 | Using modules is straightforward:
 865 | - Each module is just a JS file that uses `export` to expose things and `import` to bring in dependencies.
 866 | - In your HTML, include the main script with `type="module"`.
 867 | 
 868 | **Example:**
 869 | ```html
 870 | <!-- index.html -->
 871 | <script type="module" src="app.js"></script>
 872 | ```
 873 | 
 874 | `app.js` could import other modules:
 875 | ```js
 876 | // app.js (entry module)
 877 | import { initTodoApp } from './todoApp.js';
 878 | initTodoApp();
 879 | ```
 880 | 
 881 | And `todoApp.js` might have:
 882 | ```js
 883 | // todoApp.js
 884 | import { renderTodos } from './views/todoList.js';
 885 | import { setupEventHandlers } from './controllers/todoController.js';
 886 | // ... and so on
 887 | export function initTodoApp() {
 888 |   renderTodos();
 889 |   setupEventHandlers();
 890 | }
 891 | ```
 892 | 
 893 | This looks very much like code in a React project, except no compilation is needed – modern browsers can load these modules natively.
 894 | 
 895 | **Important:** When running via modules, you must serve the files over HTTP (from a server). If you just open the HTML file via `file://`, the imports often get blocked by CORS ([CORS blocked when I use type="module" - The freeCodeCamp Forum](https://forum.freecodecamp.org/t/cors-blocked-when-i-use-type-module/340229#:~:text=Forum%20forum,is%20because%20you%27re%20attempting%20import)). For development, this means using a simple static server (like `python -m http.server` or a VSCode Live Server extension) to serve the files. This is still "no-build" (no bundling or transpiling), but it's "needs a dev server" – which is usually fine.
 896 | 
 897 | ### 7.3 Module Import Patterns
 898 | 
 899 | You can import specific exports:
 900 | ```js
 901 | import { funcA, funcB } from './module1.js';
 902 | ```
 903 | Import everything as an object:
 904 | ```js
 905 | import * as Utils from './utils.js';
 906 | Utils.helper();
 907 | ```
 908 | Or default exports:
 909 | ```js
 910 | import myDefault from './someModule.js';
 911 | ```
 912 | We recommend using named exports (no default) for clarity, especially in large codebases (it makes searching for references easier).
 913 | 
 914 | **Re-exporting:** Modules can re-export from others. E.g., an `index.js` that re-exports all components:
 915 | ```js
 916 | export { Header } from './Header.js';
 917 | export { Footer } from './Footer.js';
 918 | ```
 919 | This way other parts can do `import { Header, Footer } from './components/index.js';`.
 920 | 
 921 | ### 7.4 Module Gotchas
 922 | 
 923 | - **Ordering:** With modules, you don't worry about script tag order. Imports handle dependency order. Just ensure you don't create circular dependencies (Module A imports Module B which imports Module A) unless they're designed to handle that (which can lead to `undefined` for one of them if not careful).
 924 | - **Hoisting:** In a traditional script, you could use a function declared later because of hoisting. In modules, imports are static and must exist at load time. But within a module, function declarations still hoist normally.
 925 | - **Async nature:** Module loading is asynchronous by default, but your code in each module runs synchronously after dependencies load. The top-level `await` is allowed in modules if needed (in modern browsers), but use with care.
 926 | 
 927 | ### 7.5 Example: Refactoring a Vanilla JS Project into Modules
 928 | 
 929 | Suppose our to-do app starts as one big `app.js`. We might refactor:
 930 | - `state.js` for state management (e.g., functions to add/remove todos and an array to hold them).
 931 | - `dom.js` for DOM references or generic helpers.
 932 | - `todoView.js` for functions to create DOM elements for todos.
 933 | - `app.js` for the main entry (wiring everything together, initial render, event binding).
 934 | 
 935 | Then:
 936 | ```js
 937 | // state.js
 938 | export const todos = [];
 939 | export function addTodo(item) {
 940 |   todos.push(item);
 941 | }
 942 | // ... etc.
 943 | ```
 944 | ```js
 945 | // todoView.js
 946 | import { todos } from './state.js';
 947 | export function renderTodoList() {
 948 |   const ul = document.createElement('ul');
 949 |   todos.forEach(todo => {
 950 |     const li = document.createElement('li');
 951 |     li.textContent = todo;
 952 |     ul.appendChild(li);
 953 |   });
 954 |   return ul;
 955 | }
 956 | ```
 957 | ```js
 958 | // app.js
 959 | import { addTodo } from './state.js';
 960 | import { renderTodoList } from './todoView.js';
 961 | 
 962 | const appRoot = document.getElementById('app');
 963 | appRoot.appendChild(renderTodoList());
 964 | 
 965 | // e.g., add a new todo and re-render list
 966 | addTodo('Learn Vanilla JS');
 967 | appRoot.innerHTML = '';                   // clear old
 968 | appRoot.appendChild(renderTodoList());    // render updated list
 969 | ```
 970 | This separation concerns: state logic vs UI rendering. This is a simplistic breakdown, but it shows that you can structure things similarly to a React+Redux separation, if you want.
 971 | 
 972 | ### 7.6 Modules and Build Tools
 973 | 
 974 | One nice aspect: if you eventually introduce a bundler (Chapter 15), it will also use these same module imports. So writing your code as modules now means it's ready for a build step later if needed. Vite, Webpack, etc., will process these `import` statements and bundle the files for production. But during development, you might not even need them if your environment supports modules.
 975 | 
 976 | ### 7.7 Summary
 977 | 
 978 | Using ES modules in the browser allows us to write organized, maintainable code. It's one of the biggest enablers of large-scale development without a framework. By splitting code into modules, you gain clarity and avoid the pitfalls of huge monolithic files or too many globals.
 979 | 
 980 | In our projects section, we'll start structuring code by features, possibly simulating what a multi-file project would look like (even if, for brevity in the book, we show code in one place, you can imagine how to separate it).
 981 | 
 982 | *(For a quick check, you could ask an AI: "How do I use ES6 modules in a browser without a bundler?" to see a summary of what we just covered and ensure all key points align.)*
 983 | 
 984 | ## Chapter 8. Dynamic Component Loading and Code Splitting
 985 | 
 986 | In React, you might use **lazy loading** (e.g., `React.lazy`) to split code for different routes or heavy components. In Vanilla JS, the equivalent is using the `import()` function to dynamically load a module at runtime. This allows you to **pull in code only when needed**, which can improve initial load times for large apps.
 987 | 
 988 | We'll also touch on dynamically creating script elements or other assets, though the module approach is usually cleaner.
 989 | 
 990 | ### 8.1 The `import()` Function (Dynamic Imports)
 991 | 
 992 | ESM (ECMAScript Modules) support a special syntax `import(modulePath)` that returns a Promise which resolves to the module exports. According to MDN, *"The `import()` syntax, commonly called dynamic import, is a function-like expression that allows loading an ECMAScript module asynchronously and dynamically..."* ([import() - JavaScript | MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import#:~:text=The%20,module%20environment)). In other words, instead of all imports being at the top (static), you can conditionally load one.
 993 | 
 994 | Example use case: We have an admin panel component that is large and only needed when the user logs in as admin.
 995 | 
 996 | ```js
 997 | function loadAdminPanel() {
 998 |   import('./adminPanel.js')
 999 |     .then(module => {
1000 |       const showAdminPanel = module.default;  // assuming adminPanel.js exports default a function
1001 |       showAdminPanel();
1002 |     })
1003 |     .catch(err => {
1004 |       console.error("Failed to load admin panel", err);
1005 |     });
1006 | }
1007 | ```
1008 | 
1009 | We could call `loadAdminPanel()` only after an admin login. Until that point, the code in `adminPanel.js` is not even loaded, saving bandwidth and parsing time.
1010 | 
1011 | If using dynamic imports for routing, perhaps in `renderCurrentRoute`:
1012 | ```js
1013 | if (path === "/admin") {
1014 |   // lazy load admin page
1015 |   const { renderAdminPage } = await import('./pages/adminPage.js');
1016 |   appRoot.appendChild(renderAdminPage());
1017 | }
1018 | ```
1019 | Using `await` (inside an async function) can make it cleaner than `.then`. Note that top-level await is supported in modules, so if `renderCurrentRoute` is at top level of a module script, you can do:
1020 | ```js
1021 | const { renderAdminPage } = await import('./pages/adminPage.js');
1022 | ```
1023 | provided your environment supports it (most modern browsers do as of 2025).
1024 | 
1025 | ### 8.2 Code Splitting without a Bundler
1026 | 
1027 | When you use dynamic import in a no-bundler environment, the browser simply makes another HTTP request for that module when needed. This means you can structure your app into many modules and not all of them will load upfront, just like code splitting in bundlers.
1028 | 
1029 | However, if you plan to eventually bundle your app, bundlers will detect dynamic imports and create separate chunk files for them. So either way, dynamic import is the way to hint "this part can be split."
1030 | 
1031 | ### 8.3 On-Demand Script Injection (Older technique)
1032 | 
1033 | Before `import()` was widespread, developers sometimes dynamically created script tags to load additional JS:
1034 | 
1035 | ```js
1036 | function loadScript(url) {
1037 |   return new Promise((resolve, reject) => {
1038 |     const script = document.createElement('script');
1039 |     script.src = url;
1040 |     script.onload = resolve;
1041 |     script.onerror = reject;
1042 |     document.head.appendChild(script);
1043 |   });
1044 | }
1045 | 
1046 | // usage
1047 | loadScript('extra-feature.js').then(() => {
1048 |   // assume extra-feature.js defines some global function we need
1049 |   extraFeatureInit();
1050 | });
1051 | ```
1052 | 
1053 | This is a more manual way and requires the loaded script to attach itself to global scope or call some global callback. With modules, you get a cleaner encapsulation (no globals needed, you get the module exports directly). So, while you might see this pattern historically or for loading third-party scripts, for your own code prefer dynamic import.
1054 | 
1055 | ### 8.4 Dynamic Loading of Non-JS Assets
1056 | 
1057 | Sometimes you might want to dynamically load a CSS file or an image. CSS can be loaded by creating a `<link rel="stylesheet" href="...">` and appending it. Images can be created or their src changed on the fly as needed.
1058 | 
1059 | For example, if your app supports themes, you might not include all theme CSS by default:
1060 | ```js
1061 | function loadTheme(themeName) {
1062 |   const link = document.createElement('link');
1063 |   link.rel = 'stylesheet';
1064 |   link.href = `${themeName}.css`;
1065 |   document.head.appendChild(link);
1066 | }
1067 | ```
1068 | This is less common in app logic and more in initial setup, but it's an option.
1069 | 
1070 | For our focus, code (JS) splitting is more relevant.
1071 | 
1072 | ### 8.5 Real-world Application: Routing with Code Splitting
1073 | 
1074 | Combining with Chapter 5, you can split each route's code:
1075 | ```js
1076 | switch(route) {
1077 |   case '/':
1078 |     renderHome();
1079 |     break;
1080 |   case '/movies':
1081 |     import('./pages/moviesPage.js').then(mod => {
1082 |       mod.renderMoviesPage();
1083 |     });
1084 |     break;
1085 |   // ...
1086 | }
1087 | ```
1088 | If the movies page code is large (maybe includes templates or a lot of logic), it won't affect initial load. The user pays the cost only when they navigate there.
1089 | 
1090 | One thing to consider: error handling. If the dynamic import fails (maybe network error), you should handle the promise rejection and perhaps show an error message or retry option.
1091 | 
1092 | ### 8.6 Performance Considerations
1093 | 
1094 | While splitting code can reduce initial bundle size, overdoing it might cause too many requests and slow down navigation if each piece is small but loads separately. It's a balance. Generally split along natural boundaries (pages, big features).
1095 | 
1096 | Browsers also often prefetch modules speculatively or you can use `<link rel="modulepreload">` to hint a module likely to be needed soon (to overlap the loading time). That's an advanced optimization.
1097 | 
1098 | ### 8.7 Summary
1099 | 
1100 | Vanilla JS supports dynamic code loading through `import()`. This means our no-framework app can still get the benefits of lazy loading features, just like a React app does with code splitting. It keeps the app lean and fast, especially the initial load. 
1101 | 
1102 | We will use this concept for any heavy optional features in our projects. For instance, maybe the TMDB app only loads the movie detail module when a movie is clicked.
1103 | 
1104 | *(AI hint: Asking something like "JavaScript dynamic import example for code splitting" could yield additional insights or patterns on using this in front-end apps, reinforcing our understanding.)*
1105 | 
1106 | ## Chapter 9. Project 1: Building a To-Do List App (Step-by-Step Tutorial)
1107 | 
1108 | Now that we've covered the core concepts of Vanilla JS development, let's put them into practice with our first project: a classic **To-Do List application**. This project will solidify basics like DOM manipulation, events, and state management. Even if you've built something similar with React, doing it in plain JS will be enlightening.
1109 | 
1110 | **Project Overview:** A simple to-do app where users can:
1111 | - Add new tasks.
1112 | - See a list of tasks.
1113 | - Mark tasks as completed or delete tasks.
1114 | - (Optional) Persist tasks in localStorage so they remain on refresh.
1115 | 
1116 | We'll build this incrementally, focusing on clean structure and Vanilla JS techniques.
1117 | 
1118 | ### 9.1 Setting Up the HTML and CSS
1119 | 
1120 | For this project, our HTML is minimal – we mostly generate elements via JavaScript, but we'll set up a basic structure:
1121 | 
1122 | ```html
1123 | <!-- index.html -->
1124 | <!DOCTYPE html>
1125 | <html lang="en">
1126 | <head>
1127 |   <meta charset="UTF-8" />
1128 |   <title>To-Do App</title>
1129 |   <style>
1130 |     /* Basic styles for a nicer appearance */
1131 |     body { font-family: sans-serif; max-width: 400px; margin: 2em auto; }
1132 |     h1 { text-align: center; }
1133 |     li.completed { text-decoration: line-through; color: gray; }
1134 |     button { margin-left: 0.5em; }
1135 |   </style>
1136 | </head>
1137 | <body>
1138 |   <h1>My To-Do</h1>
1139 |   <div id="app"></div>
1140 |   <script type="module" src="todo-app.js"></script>
1141 | </body>
1142 | </html>
1143 | ```
1144 | 
1145 | We include a `<div id="app"></div>` as a mounting point, and a `todo-app.js` module where our JS code will reside. We used a few inline styles for simplicity (a real project might use a separate CSS file).
1146 | 
1147 | ### 9.2 Structuring the App Script
1148 | 
1149 | In **todo-app.js**, we'll outline our plan:
1150 | - Maintain an array of tasks as state.
1151 | - Render the list of tasks.
1152 | - Provide a form or input to add a new task.
1153 | - Handle click events for completing/deleting tasks.
1154 | 
1155 | Let's start by defining our state and initial render:
1156 | 
1157 | ```js
1158 | // todo-app.js
1159 | let todos = [];  // state: array of { text: string, completed: bool }
1160 | const app = document.getElementById('app');
1161 | 
1162 | // Initial render function
1163 | function render() {
1164 |   app.innerHTML = "";  // clear the app container
1165 | 
1166 |   // Create the input form
1167 |   const form = document.createElement('form');
1168 |   form.innerHTML = `
1169 |     <input type="text" name="task" placeholder="New task" required />
1170 |     <button type="submit">Add</button>
1171 |   `;
1172 |   app.appendChild(form);
1173 | 
1174 |   // Create the list
1175 |   const ul = document.createElement('ul');
1176 |   todos.forEach((todo, index) => {
1177 |     ul.appendChild(createTodoItem(todo, index));
1178 |   });
1179 |   app.appendChild(ul);
1180 | }
1181 | ```
1182 | 
1183 | We used `innerHTML` for the form for brevity – injecting a small snippet. Alternatively, we could create the elements manually. The form includes a text input and a submit button.
1184 | 
1185 | For each todo, we call `createTodoItem(todo, index)` to get an `<li>` element for that todo.
1186 | 
1187 | Now, implement `createTodoItem`:
1188 | 
1189 | ```js
1190 | function createTodoItem(todo, index) {
1191 |   const li = document.createElement('li');
1192 |   li.textContent = todo.text;
1193 |   if (todo.completed) {
1194 |     li.classList.add('completed');
1195 |   }
1196 | 
1197 |   // Complete/uncomplete toggle on click
1198 |   li.addEventListener('click', () => {
1199 |     todos[index].completed = !todos[index].completed;
1200 |     render();
1201 |   });
1202 | 
1203 |   // Delete button
1204 |   const delBtn = document.createElement('button');
1205 |   delBtn.textContent = "Delete";
1206 |   delBtn.addEventListener('click', (e) => {
1207 |     e.stopPropagation();  // prevent also toggling completion
1208 |     todos.splice(index, 1);
1209 |     render();
1210 |   });
1211 |   li.appendChild(delBtn);
1212 | 
1213 |   return li;
1214 | }
1215 | ```
1216 | 
1217 | Each list item displays the todo text, and if `todo.completed` is true, we add a CSS class that crossed it out. Clicking the `<li>` toggles completion state (we update the array and re-render). We also append a "Delete" button to each item; clicking delete removes that item from the array and re-renders. Note the `e.stopPropagation()` – this ensures the click on the delete button doesn't trigger the `<li>`'s click which would toggle the item. This demonstrates event propagation control.
1218 | 
1219 | ### 9.3 Handling New Task Submission
1220 | 
1221 | We have a form in our render. We need to handle its submit event to add a new task:
1222 | 
1223 | ```js
1224 | // Attach event handler after rendering form
1225 | form.addEventListener('submit', (e) => {
1226 |   e.preventDefault();
1227 |   const input = form.elements.task;
1228 |   const newTaskText = input.value.trim();
1229 |   if (newTaskText) {
1230 |     todos.push({ text: newTaskText, completed: false });
1231 |     input.value = "";
1232 |     render();
1233 |   }
1234 | });
1235 | ```
1236 | 
1237 | We prevent default form submission (which would reload the page). We take the input's value, trim whitespace, and if it's not empty, push a new todo object into `todos`. Then clear the input and call `render()` to update the UI.
1238 | 
1239 | To attach this event, we should place that code inside `render()` right after creating/adding the form element, so that `form` is in scope. Alternatively, we could attach once and not re-create form each time – but re-rendering is simple enough here.
1240 | 
1241 | Actually, because we re-render everything on each change, note that we're recreating the form and list each time. This is a straightforward approach (similar to re-rendering in React), but it means the entire list DOM is rebuilt. For a small app it's fine. If performance was an issue, we could update only parts (but that adds complexity; our goal here is clarity). Modern browsers handle this scale easily (dozens or even hundreds of items is fine).
1242 | 
1243 | ### 9.4 Persistence with localStorage (Optional Enhancement)
1244 | 
1245 | To keep tasks across page reloads, we can utilize `localStorage`. We will:
1246 | - Load any saved tasks from localStorage on startup.
1247 | - Save the tasks to localStorage whenever they change.
1248 | 
1249 | Loading at the top of script:
1250 | ```js
1251 | const saved = localStorage.getItem('todos');
1252 | if (saved) {
1253 |   todos = JSON.parse(saved);
1254 | }
1255 | ```
1256 | After modifying `todos` (in add, toggle, delete), we can update storage:
1257 | ```js
1258 | function saveTodos() {
1259 |   localStorage.setItem('todos', JSON.stringify(todos));
1260 | }
1261 | ```
1262 | Call `saveTodos()` inside our event handlers whenever we mutate `todos`. For example, in the form submit, after `todos.push(...)` we do `saveTodos()`. Same in the toggle and delete handlers (after splicing or toggling).
1263 | 
1264 | This way, each change is persisted. When the user revisits or refreshes, the list restores.
1265 | 
1266 | ### 9.5 Testing the App
1267 | 
1268 | Time to test our to-do app manually:
1269 | 1. Open the HTML in a browser (via a local server since we used a module).
1270 | 2. Add a few tasks, see them appear.
1271 | 3. Click tasks to mark completed (they should get a line-through).
1272 | 4. Click "Delete" to remove tasks.
1273 | 5. Refresh the page – tasks should still be there (if you implemented localStorage).
1274 | 6. Check that no errors occur in console.
1275 | 
1276 | You should see something functional and straightforward, built with under ~50 lines of JS logic.
1277 | 
1278 | This small project exemplifies many things:
1279 | - Direct DOM creation (`document.createElement`).
1280 | - Event handling (`addEventListener`).
1281 | - State management via a simple array.
1282 | - Re-rendering strategy from state (similar to React's declarative approach).
1283 | - Using browser storage for persistence.
1284 | - Preventing event propagation for nested events (important detail in event handling).
1285 | 
1286 | ### 9.6 Possible Extensions
1287 | 
1288 | Feel free to extend this app as practice:
1289 | - Add a filter to show all/active/completed tasks (you'd need to add some UI and maybe a variable for current filter).
1290 | - Add an "Edit" feature to edit a task's text.
1291 | - Improve the UI with more CSS or animations on add/remove.
1292 | - Limit the scope of re-rendering (e.g., only update one item instead of full list – more complex but educational).
1293 | - Use classes or modules to organize code if converting this into a multi-file project.
1294 | 
1295 | ### 9.7 Wrap Up
1296 | 
1297 | The To-Do app demonstrates that with Vanilla JS, you can accomplish the same end result as with React for simple state-driven UI. The code is a bit more manual, but also more transparent. We explicitly manipulated the DOM and managed our data – there's no magic.
1298 | 
1299 | Now that you're warmed up, let's move to more complex projects. Next, we'll build a **Movie Explorer app** using the TMDB API, which will involve fetching data from a server, handling asynchronous flows, and possibly routing for movie details.
1300 | 
1301 | *(AI Assistant Prompt: "Generate a simple to-do app in JavaScript without frameworks, with add, complete, delete features and using localStorage." – You can use this to compare with our code or get an alternate approach. But try coding it yourself first, then see if the AI does something differently or similarly.)*
1302 | 
1303 | ## Chapter 10. Project 2: Movie Explorer (Using The Movie Database API)
1304 | 
1305 | Our second project is a **Movie Explorer** app that interacts with a real external API – The Movie Database (TMDB). This project will reinforce:
1306 | - Making network requests (fetching data).
1307 | - Rendering data-driven views (movie lists, details).
1308 | - Basic routing (to navigate between a list view and a detail view).
1309 | - Working with asynchronous operations in Vanilla JS.
1310 | 
1311 | **Project Overview:** The app will display a list of movies (e.g., popular or top-rated movies from TMDB) with their poster and title. Users can:
1312 | - Search for movies by name.
1313 | - Click a movie to view details (like description, rating, etc.) on a separate view (single page app style).
1314 | - Navigate back to the list from the detail view.
1315 | 
1316 | We'll focus on the core functionality, not every possible feature of TMDB (like paging, multi-category, etc., which you can add later).
1317 | 
1318 | ### 10.1 Setup and API Key
1319 | 
1320 | TMDB requires an API key (which you can obtain by creating a free account on their website). For the purposes of this tutorial, let's assume you have a key and store it in a variable. In a real project, you might fetch from a backend or secure it differently, but we'll just keep it simple.
1321 | 
1322 | ```js
1323 | const API_KEY = 'YOUR_TMDB_API_KEY_HERE';
1324 | const BASE_URL = 'https://api.themoviedb.org/3';
1325 | ```
1326 | 
1327 | TMDB API endpoints we'll use:
1328 | - Search: `/search/movie?api_key=...&query=SEARCH_TERM`
1329 | - Popular movies: `/movie/popular?api_key=...` (for initial list or a "Trending" section)
1330 | - Movie details: `/movie/MOVIE_ID?api_key=...`
1331 | 
1332 | Also note: Image URLs – TMDB provides poster images via a base URL and path returned by the API. E.g., `https://image.tmdb.org/t/p/w500/POSTER_PATH` to get a 500px wide image.
1333 | 
1334 | ### 10.2 HTML Structure
1335 | 
1336 | We can keep a simple HTML like:
1337 | 
1338 | ```html
1339 | <body>
1340 |   <h1>Movie Explorer</h1>
1341 |   <div id="app"></div>
1342 |   <script type="module" src="movie-app.js"></script>
1343 | </body>
1344 | ```
1345 | 
1346 | We'll dynamically create content, including a search form and results container.
1347 | 
1348 | ### 10.3 Main Views and Routing
1349 | 
1350 | We'll have two primary views in this app:
1351 | - **Home/List View:** Shows a search bar and a grid or list of movie cards.
1352 | - **Detail View:** Shows detailed info about one movie.
1353 | 
1354 | We'll implement a rudimentary router to switch between these in one page. For simplicity, using hash routing might be easiest here (to avoid server setup for different paths). We can change the URL hash to `#home` or `#movie/12345`. 
1355 | 
1356 | Using hash means we avoid dealing with pushState for now, and just listen to `hashchange`.
1357 | 
1358 | Alternatively, we could manage views internally without URL changes (just show/hide), but using the URL is nice for bookmarking.
1359 | 
1360 | Let's plan with hash:
1361 | - Default (no hash or `#home`) -> show list view.
1362 | - `#search=term` could reflect a search query (optional).
1363 | - `#movie/{id}` -> show detail for that movie id.
1364 | 
1365 | ### 10.4 Rendering the List View
1366 | 
1367 | In `movie-app.js`:
1368 | 
1369 | ```js
1370 | const app = document.getElementById('app');
1371 | 
1372 | // Elements we'll reuse
1373 | let searchInput, resultsContainer;
1374 | 
1375 | // Render the home/list view
1376 | function renderHomeView() {
1377 |   app.innerHTML = '';
1378 |   
1379 |   // Search form
1380 |   const form = document.createElement('form');
1381 |   form.innerHTML = `
1382 |     <input type="text" id="searchInput" placeholder="Search movies..." />
1383 |     <button type="submit">Search</button>
1384 |   `;
1385 |   app.appendChild(form);
1386 |   
1387 |   resultsContainer = document.createElement('div');
1388 |   resultsContainer.id = 'results';
1389 |   app.appendChild(resultsContainer);
1390 |   
1391 |   // Event: on search form submit
1392 |   form.addEventListener('submit', e => {
1393 |     e.preventDefault();
1394 |     const query = form.querySelector('#searchInput').value.trim();
1395 |     if (query) {
1396 |       searchMovies(query);
1397 |     }
1398 |   });
1399 |   
1400 |   // If no query, load popular movies by default
1401 |   loadPopularMovies();
1402 | }
1403 | ```
1404 | 
1405 | We create a form with an input and search button, and a container for results (could style as grid via CSS, but we'll skip detailed styling here). On submit, we call `searchMovies(query)` which will fetch and display results. If the page loads fresh, we call `loadPopularMovies()` to show some initial content.
1406 | 
1407 | Now, implement the functions to fetch data:
1408 | 
1409 | ```js
1410 | async function loadPopularMovies() {
1411 |   resultsContainer.textContent = 'Loading...';
1412 |   try {
1413 |     const res = await fetch(`${BASE_URL}/movie/popular?api_key=${API_KEY}`);
1414 |     const data = await res.json();
1415 |     displayMovieResults(data.results);
1416 |   } catch (err) {
1417 |     resultsContainer.textContent = 'Failed to load movies.';
1418 |     console.error(err);
1419 |   }
1420 | }
1421 | 
1422 | async function searchMovies(query) {
1423 |   resultsContainer.textContent = 'Searching...';
1424 |   try {
1425 |     const res = await fetch(`${BASE_URL}/search/movie?api_key=${API_KEY}&query=${encodeURIComponent(query)}`);
1426 |     const data = await res.json();
1427 |     displayMovieResults(data.results);
1428 |     // Update the URL hash to reflect search (optional)
1429 |     window.location.hash = `search=${encodeURIComponent(query)}`;
1430 |   } catch (err) {
1431 |     resultsContainer.textContent = 'Search failed.';
1432 |     console.error(err);
1433 |   }
1434 | }
1435 | ```
1436 | 
1437 | We use `fetch` with `async/await` for readability. We set a loading text in the results container while waiting. On success, we call `displayMovieResults`.
1438 | 
1439 | Now, `displayMovieResults(results)`:
1440 | 
1441 | ```js
1442 | function displayMovieResults(movies) {
1443 |   resultsContainer.innerHTML = '';
1444 |   if (!movies || movies.length === 0) {
1445 |     resultsContainer.textContent = 'No results found.';
1446 |     return;
1447 |   }
1448 |   movies.forEach(movie => {
1449 |     const card = createMovieCard(movie);
1450 |     resultsContainer.appendChild(card);
1451 |   });
1452 | }
1453 | ```
1454 | 
1455 | If no movies (e.g., search yielded nothing), we show a message. Otherwise, for each movie in the results array, we create a card.
1456 | 
1457 | Implement `createMovieCard(movie)`:
1458 | 
1459 | ```js
1460 | function createMovieCard(movie) {
1461 |   const card = document.createElement('div');
1462 |   card.className = 'movie-card';
1463 |   card.style.cursor = 'pointer';
1464 |   
1465 |   // Poster image
1466 |   const img = document.createElement('img');
1467 |   if (movie.poster_path) {
1468 |     img.src = `https://image.tmdb.org/t/p/w200${movie.poster_path}`;
1469 |     img.alt = movie.title;
1470 |   } else {
1471 |     img.alt = 'No image';
1472 |   }
1473 |   card.appendChild(img);
1474 |   
1475 |   // Title
1476 |   const title = document.createElement('p');
1477 |   title.textContent = movie.title;
1478 |   card.appendChild(title);
1479 |   
1480 |   // Click to go to detail view
1481 |   card.addEventListener('click', () => {
1482 |     window.location.hash = `movie/${movie.id}`;
1483 |   });
1484 |   
1485 |   return card;
1486 | }
1487 | ```
1488 | 
1489 | We create a simple card: an image and a title. We use a smaller width image (w200) for thumbnails. On card click, we set the hash to `movie/{id}` which will trigger the detail view logic (we'll write that next).
1490 | 
1491 | We also might add some basic styling via CSS (either here or in a `<style>`), e.g., `.movie-card { display: inline-block; margin: 10px; width: 120px; text-align: center; } img { width: 100%; }` for a grid.
1492 | 
1493 | ### 10.5 Rendering the Detail View
1494 | 
1495 | When the hash is `movie/12345`, we want to fetch that movie's details and display them.
1496 | 
1497 | We need a function to render detail:
1498 | 
1499 | ```js
1500 | async function renderDetailView(movieId) {
1501 |   app.innerHTML = 'Loading...';
1502 |   try {
1503 |     const res = await fetch(`${BASE_URL}/movie/${movieId}?api_key=${API_KEY}`);
1504 |     const movie = await res.json();
1505 |     displayMovieDetails(movie);
1506 |   } catch (err) {
1507 |     app.textContent = 'Failed to load movie details.';
1508 |     console.error(err);
1509 |   }
1510 | }
1511 | ```
1512 | 
1513 | And `displayMovieDetails(movie)`:
1514 | 
1515 | ```js
1516 | function displayMovieDetails(movie) {
1517 |   app.innerHTML = ''; // clear existing
1518 |   
1519 |   const detailsDiv = document.createElement('div');
1520 |   detailsDiv.className = 'movie-details';
1521 |   
1522 |   const title = document.createElement('h2');
1523 |   title.textContent = movie.title;
1524 |   detailsDiv.appendChild(title);
1525 |   
1526 |   const info = document.createElement('p');
1527 |   info.innerHTML = `<strong>Release:</strong> ${movie.release_date} 
1528 |                     <br><strong>Rating:</strong> ${movie.vote_average}`;
1529 |   detailsDiv.appendChild(info);
1530 |   
1531 |   const overview = document.createElement('p');
1532 |   overview.textContent = movie.overview;
1533 |   detailsDiv.appendChild(overview);
1534 |   
1535 |   if (movie.poster_path) {
1536 |     const poster = document.createElement('img');
1537 |     poster.src = `https://image.tmdb.org/t/p/w300${movie.poster_path}`;
1538 |     poster.alt = movie.title;
1539 |     detailsDiv.appendChild(poster);
1540 |   }
1541 |   
1542 |   // Back button
1543 |   const backBtn = document.createElement('button');
1544 |   backBtn.textContent = '← Back';
1545 |   backBtn.addEventListener('click', () => {
1546 |     window.location.hash = '';  // go back to home (no specific hash)
1547 |   });
1548 |   detailsDiv.appendChild(backBtn);
1549 |   
1550 |   app.appendChild(detailsDiv);
1551 | }
1552 | ```
1553 | 
1554 | We display the title in an `<h2>`, some info (release date and rating) in a paragraph, the overview (description), and a larger poster image if available. Finally, a "Back" button that simply clears the hash (which will bring us to home view).
1555 | 
1556 | We append everything to `app`.
1557 | 
1558 | You can style `.movie-details` and its children in CSS as needed (maybe center content or layout nicely).
1559 | 
1560 | ### 10.6 Hash-based Navigation Handling
1561 | 
1562 | We have `renderHomeView()` and `renderDetailView(id)`. Now we tie it together by listening to the URL hash changes:
1563 | 
1564 | ```js
1565 | function handleHashChange() {
1566 |   const hash = window.location.hash;
1567 |   if (!hash || hash === '#home' || hash.startsWith('#search')) {
1568 |     // Home view
1569 |     renderHomeView();
1570 |     // If hash contains a search query, trigger that
1571 |     if (hash.startsWith('#search=')) {
1572 |       const q = decodeURIComponent(hash.split('=')[1]);
1573 |       if (q) {
1574 |         // Put query in search input and perform search
1575 |         const input = document.querySelector('#searchInput');
1576 |         if (input) input.value = q;
1577 |         searchMovies(q);
1578 |       }
1579 |     }
1580 |   } else if (hash.startsWith('#movie/')) {
1581 |     const movieId = hash.replace('#movie/', '');
1582 |     if (movieId) {
1583 |       renderDetailView(movieId);
1584 |     }
1585 |   }
1586 | }
1587 | 
1588 | // Initial load
1589 | window.addEventListener('hashchange', handleHashChange);
1590 | handleHashChange(); // call on first load
1591 | ```
1592 | 
1593 | This function checks the hash:
1594 | - If empty or `#home` or a search, it renders the home view. If there's a search term in hash (like `#search=Inception`), it populates the search and runs it.
1595 | - If hash starts with `#movie/`, it extracts the ID and calls detail view.
1596 | 
1597 | We call `handleHashChange()` at startup to load the correct view based on initial URL, and again on each hash change event.
1598 | 
1599 | One caveat: after going to detail and clicking Back (our backBtn sets hash to ''), this triggers home view render, but note that it doesn't automatically restore the previous list of results. In our simple approach, going back to home will reload popular movies or the search if the hash was a search. If we wanted a smoother back (without re-fetching), we'd have to cache results. But to keep it straightforward, reloading is fine (and demonstrates idempotence).
1600 | 
1601 | ### 10.7 Testing the Movie Explorer
1602 | 
1603 | When you run this app:
1604 | - It should show popular movies initially (with images and titles).
1605 | - Searching should fetch and show relevant movies (and update URL).
1606 | - Clicking a movie card goes to detail view with info.
1607 | - The Back button returns to home (and triggers a fresh render of home view).
1608 | 
1609 | Check the console for any errors or CORS issues (for API calls ensure you use correct API key and endpoint). If images are broken, verify the poster_path and URL.
1610 | 
1611 | This project involved more moving parts:
1612 | - **Fetching data from an API** using `fetch` and promises/await.
1613 | - **Updating the UI based on async results**, ensuring loading states.
1614 | - **Minimal routing logic** to handle multiple views (list vs detail).
1615 | - **User input handling** in the search form.
1616 | - **Dynamic creation of multiple DOM elements** for lists, which we encapsulated in helper functions for clarity.
1617 | 
1618 | It's essentially a small single-page application. You can enhance it by adding features like pagination (TMDB returns page info), multiple categories (Now Playing, Top Rated etc. as tabs), or even a favorite movies list stored locally.
1619 | 
1620 | ### 10.8 Highlight: Working with Async in Vanilla JS
1621 | 
1622 | This app underscores how you manage async tasks without React:
1623 | - We manually show "Loading..." text while waiting for fetch responses. In React you might have a loading state and conditional render; here we directly manipulate DOM to show feedback.
1624 | - We handle errors similarly, by showing a message and logging.
1625 | - The code uses `async/await` which makes it look synchronous, but under the hood it's the event loop (the fetch finishes and then calls our code, as explained in Chapter 1).
1626 | 
1627 | Everything is explicit – which can actually make debugging easier since you see exactly when things happen.
1628 | 
1629 | *(AI Assistant Prompt: "Create a simple JavaScript app that uses the TMDB API to list movies and show details without using any frameworks." This can help you compare your solution or get hints if you get stuck with API usage. Always ensure to replace `YOUR_TMDB_API_KEY_HERE` with a valid key when running.)*
1630 | 
1631 | ## Chapter 11. Project 3: Notes App with Routing and Persistence
1632 | 
1633 | For our third project, we'll build a **Notes App** – a slightly more complex CRUD application that involves multiple views and client-side routing. This will combine several concepts:
1634 | - Multi-view app structure (list of notes vs. note editor view).
1635 | - Local state management and `localStorage` persistence (to save notes).
1636 | - Event handling for creating/editing/deleting notes.
1637 | - Using URL routing (History API or hash) to navigate to specific notes.
1638 | 
1639 | **Project Overview:** The app will allow users to create text notes. The main page shows a list of note titles. Clicking a note opens an editor view to edit its content. There's also a button to create a new note. All notes are saved in localStorage so they persist. We'll implement routing so that each note has its own URL (like `#note/123` or using pushState), making it a richer SPA.
1640 | 
1641 | ### 11.1 Designing the Data Structure
1642 | 
1643 | We need to store notes, each with an ID, title, and content. We can use an array of note objects or an object map. For simplicity, an array is fine, but we should generate unique IDs for notes (perhaps using timestamp or a simple counter).
1644 | 
1645 | Example note object:
1646 | ```js
1647 | { id: 1623423423, title: "Groceries", content: "Milk\nEggs\nBread" }
1648 | ```
1649 | 
1650 | We'll keep an array `notes` in memory, and also sync it to `localStorage` for persistence.
1651 | 
1652 | ### 11.2 Setting Up HTML and Basic Layout
1653 | 
1654 | Minimal HTML:
1655 | ```html
1656 | <h1>Notes App</h1>
1657 | <div id="app"></div>
1658 | <script type="module" src="notes-app.js"></script>
1659 | ```
1660 | 
1661 | We may use simple CSS: e.g., style a list, etc., but skip heavy styling in code.
1662 | 
1663 | ### 11.3 Routing for List and Editor Views
1664 | 
1665 | We will have two main views:
1666 | - **ListView:** Shows all note titles and a "New Note" button.
1667 | - **EditorView:** Shows a textarea for note content and an input for title, with Save/Delete options.
1668 | 
1669 | We'll use hash routing again for simplicity: 
1670 | - `#notes` or empty hash -> List view.
1671 | - `#note/<id>` -> Editor view for that note.
1672 | 
1673 | Let's structure our script:
1674 | 
1675 | ```js
1676 | let notes = [];
1677 | const app = document.getElementById('app');
1678 | 
1679 | // Load from localStorage
1680 | const savedData = localStorage.getItem('notes');
1681 | if (savedData) {
1682 |   notes = JSON.parse(savedData);
1683 | }
1684 | 
1685 | // Utility: save to localStorage
1686 | function saveNotes() {
1687 |   localStorage.setItem('notes', JSON.stringify(notes));
1688 | }
1689 | 
1690 | // Views
1691 | function renderListView() { ... }
1692 | function renderEditorView(noteId) { ... }
1693 | 
1694 | // Routing handler
1695 | function handleHashChange() { ... }
1696 | 
1697 | // Init
1698 | window.addEventListener('hashchange', handleHashChange);
1699 | handleHashChange();
1700 | ```
1701 | 
1702 | ### 11.4 Implementing List View
1703 | 
1704 | ```js
1705 | function renderListView() {
1706 |   app.innerHTML = '';
1707 |   const listContainer = document.createElement('div');
1708 |   
1709 |   // New Note button
1710 |   const newBtn = document.createElement('button');
1711 |   newBtn.textContent = 'New Note';
1712 |   newBtn.addEventListener('click', () => {
1713 |     // Create a new note and navigate to it
1714 |     const newId = Date.now(); // simple unique id based on timestamp
1715 |     notes.push({ id: newId, title: 'Untitled', content: '' });
1716 |     saveNotes();
1717 |     window.location.hash = `note/${newId}`;
1718 |   });
1719 |   listContainer.appendChild(newBtn);
1720 |   
1721 |   // Notes list
1722 |   const ul = document.createElement('ul');
1723 |   notes.forEach(note => {
1724 |     const li = document.createElement('li');
1725 |     const title = note.title || "(Untitled)";
1726 |     li.textContent = title;
1727 |     li.style.cursor = 'pointer';
1728 |     li.addEventListener('click', () => {
1729 |       window.location.hash = `note/${note.id}`;
1730 |     });
1731 |     ul.appendChild(li);
1732 |   });
1733 |   listContainer.appendChild(ul);
1734 |   
1735 |   app.appendChild(listContainer);
1736 | }
1737 | ```
1738 | 
1739 | This shows a list of notes. Each item clickable sets hash to that note. The "New Note" button creates a new note with a unique ID (timestamp used here; collisions unlikely if not too fast). It immediately saves and navigates to edit it.
1740 | 
1741 | We display "(Untitled)" for notes with empty title.
1742 | 
1743 | ### 11.5 Implementing Editor View
1744 | 
1745 | ```js
1746 | function renderEditorView(noteId) {
1747 |   const note = notes.find(n => n.id == noteId);
1748 |   if (!note) {
1749 |     app.innerHTML = '<p>Note not found.</p>';
1750 |     return;
1751 |   }
1752 |   app.innerHTML = '';
1753 |   
1754 |   const editorDiv = document.createElement('div');
1755 |   
1756 |   // Title input
1757 |   const titleInput = document.createElement('input');
1758 |   titleInput.type = 'text';
1759 |   titleInput.value = note.title;
1760 |   titleInput.placeholder = 'Title';
1761 |   editorDiv.appendChild(titleInput);
1762 |   
1763 |   // Content textarea
1764 |   const contentArea = document.createElement('textarea');
1765 |   contentArea.rows = 10;
1766 |   contentArea.value = note.content;
1767 |   editorDiv.appendChild(contentArea);
1768 |   
1769 |   // Save button
1770 |   const saveBtn = document.createElement('button');
1771 |   saveBtn.textContent = 'Save';
1772 |   saveBtn.addEventListener('click', () => {
1773 |     note.title = titleInput.value;
1774 |     note.content = contentArea.value;
1775 |     saveNotes();
1776 |     window.location.hash = '';  // go back to list
1777 |   });
1778 |   editorDiv.appendChild(saveBtn);
1779 |   
1780 |   // Delete button
1781 |   const deleteBtn = document.createElement('button');
1782 |   deleteBtn.textContent = 'Delete';
1783 |   deleteBtn.style.marginLeft = '10px';
1784 |   deleteBtn.addEventListener('click', () => {
1785 |     notes = notes.filter(n => n.id != noteId);
1786 |     saveNotes();
1787 |     window.location.hash = ''; // back to list
1788 |   });
1789 |   editorDiv.appendChild(deleteBtn);
1790 |   
1791 |   // Back link (if user doesn't want to save changes)
1792 |   const backLink = document.createElement('a');
1793 |   backLink.href = '#';
1794 |   backLink.textContent = 'Cancel';
1795 |   backLink.style.marginLeft = '10px';
1796 |   editorDiv.appendChild(backLink);
1797 |   
1798 |   app.appendChild(editorDiv);
1799 | }
1800 | ```
1801 | 
1802 | This creates a simple editor:
1803 | - An input for title, pre-filled.
1804 | - A textarea for content.
1805 | - Save: updates the note object and persists, then navigates to list.
1806 | - Delete: removes the note from the array and persists, then back to list.
1807 | - A "Cancel" link that just goes back (to `#` which we treat as list). Note: if user made changes and clicks cancel, those changes are lost unless they saved; handling unsaved changes is beyond our scope here, but one could add a confirmation if needed.
1808 | 
1809 | We used `window.location.hash = ''` to go home (list view).
1810 | 
1811 | We must ensure styles to make it user-friendly (maybe width 100% for input and textarea, some margin).
1812 | 
1813 | ### 11.6 Routing Handler
1814 | 
1815 | ```js
1816 | function handleHashChange() {
1817 |   const hash = window.location.hash;
1818 |   if (!hash || hash === '#') {
1819 |     renderListView();
1820 |   } else if (hash.startsWith('#note/')) {
1821 |     const noteId = hash.replace('#note/', '');
1822 |     renderEditorView(noteId);
1823 |   } else {
1824 |     // Fallback for unknown hash
1825 |     renderListView();
1826 |   }
1827 | }
1828 | ```
1829 | 
1830 | This directs to list or editor based on the hash.
1831 | 
1832 | ### 11.7 Testing the Notes App
1833 | 
1834 | When you load the app:
1835 | - You should see "New Note" and perhaps an empty list if no notes.
1836 | - Click "New Note": It should create a note and navigate to editor.
1837 | - In editor, type a title and content. Click Save: should return to list and show the new note title.
1838 | - Click the note in list to reopen, edit, save again, see updates.
1839 | - Try adding multiple notes.
1840 | - Try Delete: note should be removed from list.
1841 | - Refresh page: notes should persist (localStorage working).
1842 | - Try using the Cancel link: ensure it goes back to list.
1843 | 
1844 | This project demonstrates:
1845 | - **Routing and multi-view management** with a shared data store (notes array).
1846 | - **Creating, updating, deleting data** and keeping UI in sync by re-rendering list or updating state.
1847 | - We didn't use any fancy framework – just logic and DOM updates.
1848 | - The use of `find` and `filter` to manage array state, similar to how you'd use useState in React with new arrays.
1849 | 
1850 | We should also consider edge cases:
1851 | - If list is empty, maybe show a message "No notes yet, create one".
1852 | - If editing note and user refreshes on that hash, handle it (we do: if note not found, we say not found).
1853 | - Unique ID generation: using `Date.now()` might generate same ID if user creates two notes in the same millisecond (unlikely). Could also check and loop until find unused.
1854 | - We might also want to update the list view in memory immediately when editing: currently, we update the note object which is the same reference in array, so list view will reflect new title on next render (we re-read from notes array each time we render list).
1855 | 
1856 | ### 11.8 Reflection
1857 | 
1858 | This notes app essentially functions like a mini single-page CRUD application, akin to something you might use a framework for. But doing it in Vanilla JS shows that with careful planning, it's entirely feasible:
1859 | - We manually managed state (`notes` array) and UI updates.
1860 | - We leveraged browser storage without extra libraries.
1861 | - The code is longer than a typical React version might be, but it's straightforward and each part is understandable with basic JS knowledge.
1862 | 
1863 | *(AI Assistant Practice: "How to build a single-page notes app with JavaScript and localStorage without frameworks?" The AI might provide a solution outline; comparing it with our implementation can offer insights or alternative methods.)*
1864 | 
1865 | ## Chapter 12. Back-End JavaScript: An Introduction to Node.js
1866 | 
1867 | So far we've focused on front-end (browser) JavaScript. In this chapter, we'll briefly step into the **back-end** and see how Node.js allows you to use JavaScript on the server side. While a full Node course is beyond our scope, we'll highlight key ideas so that a React/JS developer can understand the basics of running JS outside the browser.
1868 | 
1869 | ### 12.1 What is Node.js?
1870 | 
1871 | Node.js is a runtime environment that allows JavaScript to run on the server (outside the browser) using Google Chrome's V8 engine ([Node.js — Introduction to Node.js](https://nodejs.org/en/learn/getting-started/introduction-to-nodejs#:~:text=Node.js%20is%20an%20open,almost%20any%20kind%20of%20project)). Essentially, Node.js lets you execute JS code on your machine or server just like you would run Python, Ruby, etc. It comes with built-in modules for things like file system access, networking, and more.
1872 | 
1873 | One of Node's biggest appeals: front-end developers can use the same language (JS) for server-side logic. As the Node documentation says, *"millions of frontend developers that write JavaScript for the browser are now able to write the server-side code... without the need to learn a completely different language."* ([Node.js — Introduction to Node.js](https://nodejs.org/en/learn/getting-started/introduction-to-nodejs#:~:text=Node,learn%20a%20completely%20different%20language)).
1874 | 
1875 | ### 12.2 Running a Simple Node Script
1876 | 
1877 | If you have Node.js installed, you can create a file `hello.js`:
1878 | ```js
1879 | console.log("Hello from Node");
1880 | ```
1881 | and run it with the command `node hello.js`. This will execute the code and print to your terminal.
1882 | 
1883 | Node provides `console.log` just like the browser, but no `document` or `window` (since there's no DOM). Instead, you have access to Node-specific globals like `process` (for environment info, arguments, etc.).
1884 | 
1885 | ### 12.3 Building a Simple Web Server
1886 | 
1887 | One common introductory example is an HTTP server. In Node, you can create a web server in a few lines:
1888 | 
1889 | ```js
1890 | // server.js
1891 | const http = require('http');
1892 | 
1893 | const server = http.createServer((req, res) => {
1894 |   res.statusCode = 200;
1895 |   res.setHeader('Content-Type', 'text/plain');
1896 |   res.end('Hello, World!\n');
1897 | });
1898 | 
1899 | server.listen(3000, () => {
1900 |   console.log('Server running at http://localhost:3000/');
1901 | });
1902 | ```
1903 | 
1904 | Run this with `node server.js`. It will start a server on port 3000. When you visit http://localhost:3000 in a browser, it responds with "Hello, World!" ([Node.js — Introduction to Node.js](https://nodejs.org/en/learn/getting-started/introduction-to-nodejs#:~:text=const%20,node%3Ahttp)). This example uses Node's built-in `http` module. We set headers and status, and end the response with some text.
1905 | 
1906 | This is low-level compared to using frameworks like Express, but it shows what's happening under the hood.
1907 | 
1908 | ### 12.4 Using npm and Packages
1909 | 
1910 | Node comes with **npm (Node Package Manager)**, which lets you download and manage libraries. For instance, the popular Express framework simplifies server creation:
1911 | 
1912 | ```bash
1913 | npm init -y            # initialize a package.json
1914 | npm install express    # install express package
1915 | ```
1916 | 
1917 | Then in a file:
1918 | ```js
1919 | const express = require('express');
1920 | const app = express();
1921 | const PORT = 3000;
1922 | 
1923 | app.get('/', (req, res) => {
1924 |   res.send('Hello from Express');
1925 | });
1926 | 
1927 | app.listen(PORT, () => console.log(`Listening on port ${PORT}`));
1928 | ```
1929 | 
1930 | This does the same as the raw http example but with less code, and easier routing. We won't dive deeper, but know that npm hosts thousands of packages for all kinds of functionality.
1931 | 
1932 | ### 12.5 Node and Front-end Tooling
1933 | 
1934 | Even if you don't write back-end code, you've likely used Node through tools like Webpack, Babel, ESLint, Create React App, etc. These are Node programs (often installed via npm) that automate front-end build processes. For instance, when you run `npm start` in a React project, Node is running a development server behind the scenes.
1935 | 
1936 | You can create scripts in `package.json` to run Node-based tools. E.g.:
1937 | ```json
1938 | "scripts": {
1939 |   "build": "webpack --mode production",
1940 |   "lint": "eslint src/**/*.js"
1941 | }
1942 | ```
1943 | These might execute Node commands for bundling and linting code.
1944 | 
1945 | ### 12.6 Sharing Code Between Frontend and Backend
1946 | 
1947 | One neat aspect of using JS everywhere is the ability to share logic. For example, if you wrote a validation function or utility in your front-end code, you could move it to a common module and use it in Node (for server-side validation) and import it in the front-end too (with bundlers or modules).
1948 | 
1949 | Of course, not all browser APIs exist in Node (no DOM, no `fetch` by default (though Node 18+ has fetch), etc.), but pure logic or data processing functions can be shared.
1950 | 
1951 | ### 12.7 When to Consider Node.js
1952 | 
1953 | If you extend your vanilla JS project and need a backend (say, to save data permanently or to implement user authentication), Node is a natural choice as you can stay in JS. You might use Node to:
1954 | - Build a REST API that your front-end calls (like we called TMDB API, you could create your own API).
1955 | - Serve your static files (though any web server can do that).
1956 | - Perform server-side rendering (for SEO or performance) – advanced use case.
1957 | - Write scripts or command-line tools (Node is often used to make utilities, e.g., a script to generate a file from some data).
1958 | 
1959 | ### 12.8 Quick Example: API Endpoint with Express
1960 | 
1961 | Just to illustrate, here's how an Express server might provide a simple API for a notes app (from project 3):
1962 | 
1963 | ```js
1964 | const express = require('express');
1965 | const app = express();
1966 | app.use(express.json()); // to parse JSON request bodies
1967 | 
1968 | let notes = [];
1969 | 
1970 | // Get all notes
1971 | app.get('/api/notes', (req, res) => {
1972 |   res.json(notes);
1973 | });
1974 | 
1975 | // Create a new note
1976 | app.post('/api/notes', (req, res) => {
1977 |   const newNote = { id: Date.now(), title: req.body.title, content: req.body.content };
1978 |   notes.push(newNote);
1979 |   res.json(newNote);
1980 | });
1981 | 
1982 | // Delete a note
1983 | app.delete('/api/notes/:id', (req, res) => {
1984 |   notes = notes.filter(n => n.id != req.params.id);
1985 |   res.sendStatus(204);
1986 | });
1987 | 
1988 | app.listen(3000, () => console.log('API server running on 3000'));
1989 | ```
1990 | 
1991 | This is a basic RESTful interface for notes. Your front-end could `fetch('/api/notes')` or `fetch('/api/notes', { method:'POST', body: JSON.stringify(note) })` etc., to interact with it.
1992 | 
1993 | ### 12.9 Conclusion: Full-Stack JS
1994 | 
1995 | By combining front-end skills with Node knowledge, you become a full-stack JavaScript developer. You can handle both sides and use a single language throughout – which can be efficient for both your development process and for sharing code.
1996 | 
1997 | Even if you continue focusing on the front-end, understanding Node.js is useful because so many front-end tools (and the concept of module bundling, etc.) involve Node. Plus, debugging issues like CORS or server responses is easier when you know what's happening on the server.
1998 | 
1999 | To wrap up:
2000 | - Node.js opens up JS beyond the browser, from servers to scripts.
2001 | - It uses the same language fundamentals, but has its own APIs (file system, network, etc.) and a different event loop environment tuned for server tasks.
2002 | - Experiment with Node by writing small scripts or starting a tiny server – it helps reinforce how JavaScript can be used in different contexts.
2003 | 
2004 | *(AI prompt idea: "Explain Node.js to a front-end developer and show a simple HTTP server example." The answer should align with what we covered, reinforcing understanding.)*
2005 | 
2006 | ## Chapter 13. Bundling and Build Tools: Going Production-Ready with Vite
2007 | 
2008 | Throughout this book, we've emphasized a no-build approach – writing modern JS and running it directly in the browser. This works great for development and simpler projects, but when you're ready to deploy a serious application, you'll likely introduce a **build step**. Bundling, minification, and other optimizations can improve performance and browser compatibility.
2009 | 
2010 | In this chapter, we'll discuss why bundling is useful and walk through using a modern tool like **Vite** to bundle our Vanilla JS app for production.
2011 | 
2012 | ### 13.1 Why Bundle at All?
2013 | 
2014 | Historically, browsers didn't support modules, so bundlers concatenated files into one. Now that modules are supported, do we still need bundling? Possibly, for several reasons:
2015 | - **HTTP overhead**: If your app has many small files (modules), bundling can reduce the number of network requests. (Though HTTP/2 has mitigated this to some extent.)
2016 | - **Minification**: Bundlers/uglifiers remove whitespace, shorten variable names, etc., reducing file size.
2017 | - **Transpilation**: To support older browsers, you might need to transpile modern JS (like arrow functions, etc.) down to ES5. Tools like Babel can integrate with bundlers.
2018 | - **Assets & Code Splitting**: Bundlers can handle importing CSS/images and split code into chunks for lazy loading (our dynamic imports become separate files).
2019 | - **Convenience**: You can use future JS features or different languages (TypeScript, JSX, etc.) and let the build tool convert them appropriately.
2020 | 
2021 | As the Vite docs note, bundler-based dev setups handle many tasks but can be slow on large projects ([Why Vite | Vite](https://vite.dev/guide/why#:~:text=However%2C%20as%20we%20build%20more,affect%20developers%27%20productivity%20and%20happiness)). Vite addresses dev speed by leveraging native modules and bundling only for production ([Why Vite | Vite](https://vite.dev/guide/why#:~:text=Vite%20aims%20to%20address%20these,native%20languages)). So you get the best of both worlds: fast dev, optimized build.
2022 | 
2023 | ### 13.2 Introducing Vite
2024 | 
2025 | **Vite** is a modern build tool created by Evan You (Vue.js creator). Its name means "fast" in French, and it uses native ES modules for dev (no heavy bundle on dev server) and Rollup under the hood for production bundling. It supports projects in Vanilla JS, Vue, React, etc.
2026 | 
2027 | Key features:
2028 | - Lightning-fast cold starts (because it doesn't bundle everything upfront).
2029 | - Hot Module Replacement (HMR) in dev for a great DX.
2030 | - Out-of-the-box support for TS, JSX, CSS, and more via plugins.
2031 | - Easy configuration (often zero-config for simple projects).
2032 | 
2033 | ### 13.3 Setting Up Vite for a Vanilla JS Project
2034 | 
2035 | Let's say we want to bundle our **Movie Explorer** app for production. We can use Vite to create a scaffolding:
2036 | ```
2037 | npm init vite@latest vanilla-movie-app -- --template vanilla
2038 | ```
2039 | This will create a `vanilla-movie-app` folder with a basic structure for a vanilla JS project using Vite. Inside, the `index.html` and `main.js` (or similar) will be set up. If you already have your code, you can integrate Vite by:
2040 | - Ensuring your HTML has a script type=module pointing to your main JS (like `main.js`).
2041 | - Possibly adjusting module import paths if needed (Vite supports relative imports as we wrote).
2042 | - Creating a `package.json` with Vite as a dev dependency.
2043 | 
2044 | Then install:
2045 | ```
2046 | npm install
2047 | npm run dev
2048 | ```
2049 | The dev command (preconfigured by Vite) will start a dev server (likely on port 5173) that serves your app with modules. It supports HMR, so if you edit a file, the changes reflect immediately without a full reload.
2050 | 
2051 | ### 13.4 Building for Production
2052 | 
2053 | When ready:
2054 | ```
2055 | npm run build
2056 | ```
2057 | This triggers Vite's production build. It will output files (in `dist/` by default):
2058 | - Your JavaScript bundled (maybe chunked if using dynamic import) and minified.
2059 | - An optimized `index.html` referencing the bundled files (with cache-busting hashes in filenames).
2060 | - Any CSS extracted (if you imported CSS in JS).
2061 | - Possibly smaller polyfill or manifest files if needed.
2062 | 
2063 | For example, our movie app might result in `assets/index-abc123.js` etc., and images might be copied over or inlined depending on config.
2064 | 
2065 | You can preview the production build with:
2066 | ```
2067 | npm run preview
2068 | ```
2069 | This serves the `dist` directory to test the result locally.
2070 | 
2071 | ### 13.5 Configuration Options
2072 | 
2073 | Vite allows configuration via `vite.config.js` (or `.ts`). For a vanilla project, you might not need to change much. Some useful options:
2074 | - Setting a `base` path if your app will be served from a subdirectory.
2075 | - Adding plugins (for example, a plugin to work with a templating language or to enable legacy browser support).
2076 | - Define environment variables – Vite will replace `import.meta.env.VARIABLE` in your code with values from a `.env` file or command line.
2077 | 
2078 | For instance, if we had an API key we don't want in code, we might use an env var.
2079 | 
2080 | ### 13.6 Deployment
2081 | 
2082 | After bundling, you can deploy the contents of `dist/` to any static hosting (e.g., GitHub Pages, Netlify, Vercel, an S3 bucket, or your own server). It's just static files.
2083 | 
2084 | If you used client-side routing with the History API (pushState), remember to configure the server to redirect 404s to your `index.html` (so that direct navigation works). With hash routing, that's not an issue.
2085 | 
2086 | ### 13.7 Example: Bundling Our Notes App with Vite
2087 | 
2088 | To cement the idea, let's outline bundling the Notes app:
2089 | - It has multiple modules (if we split it) or one file. Vite will handle either.
2090 | - We run `npm init vite@latest notes-app -- --template vanilla`.
2091 | - Copy our HTML/JS into that scaffold (or modify existing).
2092 | - Run dev server: ensures it still works (maybe minor tweaks if needed).
2093 | - Run build: get `dist/` output.
2094 | - Deploy `dist`.
2095 | 
2096 | One nice thing: If we used modern JS features that some older browsers can't handle, we might need to transpile. Vite, by default, targets modern browsers (it assumes roughly ES2017+). If you need IE11 support (rare these days), you'd need a plugin (`@vitejs/plugin-legacy`) to add polyfills and transpile down. This is optional and increases bundle size, so use only if needed.
2097 | 
2098 | ### 13.8 Summing Up: Modern Build Workflow
2099 | 
2100 | In 2025 and beyond, tools like Vite are becoming standard even for projects that could run without bundling, because they streamline the development and optimization process. The great part is:
2101 | - You can start without it (as we did), and only add it when needed.
2102 | - Or start with it from scratch – since it's not onerous like older bundlers.
2103 | 
2104 | For a React developer, Vite's workflow is similar to create-react-app but faster and more flexible.
2105 | 
2106 | In conclusion:
2107 | - Use bundling for production to optimize your app's load time and compatibility.
2108 | - Vite is a top choice due to its speed and simplicity for modern JS apps.
2109 | - The concepts of entry points, outputs, and plugins apply similarly if you use Webpack, Parcel, or others – but Vite's philosophy is to leverage the platform (ESM) during dev and only bundle when necessary ([Why Vite | Vite](https://vite.dev/guide/why#:~:text=Before%20ES%20modules%20were%20available,can%20run%20in%20the%20browser)).
2110 | 
2111 | Now you have the tools to go from a simple vanilla JS prototype to a fully optimized, deployable web app, all while understanding what's happening under the hood!
2112 | 
2113 | *(If curious, ask AI: "What are the benefits of using Vite over Webpack for a vanilla JS project?" to hear a reasoning similar to what we've covered, often highlighting dev experience and performance.)*
2114 | 
2115 | ## Conclusion
2116 | 
2117 | Congratulations on making it through *Vanilla JavaScript for React Developers*! We've journeyed from the fundamentals of JavaScript, through building front-end features without frameworks, and even touched on server-side JS and build tools. By now, you should feel more confident in your ability to create web applications using plain JavaScript and modern browser capabilities.
2118 | 
2119 | **When to use Vanilla JS vs. Frameworks:** This book isn't suggesting you ditch React for every project. Frameworks shine for large-scale apps or teams, ensuring consistency and offering powerful abstractions (and a vast ecosystem). However:
2120 | - For smaller projects or simpler interactive pages, Vanilla JS can be more than sufficient – no need to pull in a heavy framework.
2121 | - Knowing Vanilla JS means you can use frameworks more effectively. You'll write better React code because you understand what happens underneath (e.g., why keys are needed in lists, how state updates trigger re-renders).
2122 | - If a framework is misbehaving or limiting, you have the skill to go outside it or debug issues at a lower level.
2123 | - Sometimes integrating a bit of Vanilla JS into a React app (for a one-off dynamic behavior or integrating a non-React library) can solve problems – you now know how to do that safely.
2124 | 
2125 | **Lifelong Learning:** The web platform evolves. By staying tuned to the fundamentals and new web APIs, you can often do things natively that once required a library. Keep an eye on modern APIs (like Web Components, Service Workers, WebSockets, etc.). As you saw, using the platform directly can be rewarding and performant.
2126 | 
2127 | In the end, whether you code with a framework or without, you are now a stronger JavaScript developer. You can appreciate the conveniences of frameworks and also thrive without them. Your "toolbelt" is larger – you can pick the right tool for the job, even if that tool is just plain JavaScript.
2128 | 
2129 | Happy coding, and may your future apps be robust, whether built with 100% Vanilla JS, React, or any other library. You have the knowledge to make that choice wisely and the skills to execute it effectively.
2130 | 
2131 | **Next Steps:** Try converting one of your small React projects into Vanilla JS as practice, or vice versa. Experiment with Web Components. Dive deeper into Node by writing a simple API for one of the projects we built. The more you apply these concepts, the more fluent you'll become. 


--------------------------------------------------------------------------------