100 Days of Code

Hit the button to see my dev profile.

View developer profile

Day 18 - Freecodecamp - Build a Final Exams Table - 100% COMPLETE!

Day 18 - Freecodecamp - Debug a Pet Adoption Page - 100% COMPLETE!

Day 18 - Building a Mini-Startup Idea - Learned about some code concepts

Me:

What's an ES module?

ChatGPT:

ES Modules in a nutshell

“ES Module” (often shortened to ESM) is JavaScript’s built-in, standards-based system for structuring code into reusable files. Think of it as the browser-native way to say “this piece of code depends on that piece over there” without polluting the global scope.

What it is	Why it matters
A file-level scope - Every `.js` file loaded as a module has its own private scope, so variables don’t leak to `window`.	Prevents name collisions and accidental overwrites in larger projects.
Explicit `import` / `export` keywords - You pick exactly which identifiers leave a file and which come in.	Makes dependencies obvious and enables tree-shaking (dead-code removal) by build tools.
*Runs in strict mode* automatically**	Catches silent errors (e.g., assigning to an undeclared variable) without adding `"use strict"`.
Deferred by default - `<script type="module">` tags wait until the HTML is parsed, then execute in order as each import resolves.	No more `defer` or `async` juggling for most cases.
Supports top-level `await` in modern browsers.	Handy for setup code: `const data = await fetch(...);` directly in the module scope.
Works in both browsers and Node (with slight syntax flags in older Node versions).	One syntax everywhere instead of juggling CommonJS (`require`) and AMD.

Mini example

math.js

export function add(a, b) {
  return a + b;
}

export const PI = 3.14159;

main.js

import { add, PI } from './math.js';

console.log(add(2, 3));   // 5
console.log(PI);          // 3.14159

Then in your HTML:

<script type="module" src="main.js"></script>

The browser fetches main.js, sees import … from './math.js', grabs that too, wires the exports in, and runs the code—no bundler required.

How it compares to older patterns

Pattern	Typical syntax	Key downside
Script tag globals	Everything sits on `window.MyLib`	Namespace pollution. No real dependency graph.
CommonJS (Node’s `require`)	`const lib = require('lib');`	Not natively supported by browsers; needs bundling.
AMD / RequireJS	`define(['dep'], (dep) => … )`	Verbose, now largely legacy.

ES Modules replace all of these with one standard approach.

Why `type="module"` is on your Firebase snippet

When the browser sees <script type="module">, it:

Treats the file as an ES Module (scope, strict mode, etc.).
Lets you use import { … } from "https://…"; right in the browser.
Ensures that any relative imports you write (./utils.js) resolve the same way they would in modern Node or bundlers like Vite.

So in your Firebase bootstrap code, that line tells the browser: “This uses modern module semantics—please fetch any import URLs and wire everything up before running.”

When you move beyond demos

Multiple files: Put each logical chunk (helpers, UI logic, Firebase config) in its own module and export what you need.
Bundling for production: Even though browsers can load modules directly, you’ll usually run a build step (e.g., Vite, esbuild) to bundle, minify, and cache-bust for better performance.
Interop with Node: Use the same import/export syntax in your server code (Node ≥14 with "type": "module" in package.json).

That’s the gist of ES Modules—modern, explicit, and built into every evergreen browser.

Me:

Damn, this is super confusing, and there's a lot of words to use that I have no idea what they are. Yeah, I mean, I don't even know what a bundler is. Minifying, cash, busting, I have no idea. I'm pretty lost.

ChatGPT:

No worries — every web-dev doc seems to dump five new buzz-words on you at once. Let’s translate the biggest ones into plain English and show why you can safely ignore most of them for now.

1. Bundler

What it does (simple):
Takes all the little JavaScript files you wrote and squishes them into one (or a few) bigger files before you put them online.

Why people bother:

Fewer files ⇒ the browser makes fewer downloads ⇒ your site loads faster.
Lets you use fancy features (ES modules, TypeScript, Sass) even in older browsers.

Why you can skip it (for now):
You’re writing a tiny vanilla-JS app. A couple of <script type="module"> tags is fine until your project starts feeling slow or messy.

2. Minifying

What it does:
Runs your code through a compressor that removes spaces, line-breaks, and long variable names:

// before
function sayHello(name) {
  console.log('Hello ' + name);
}

// after
function sayHello(n){console.log("Hello "+n);}

Why: Smaller file size = faster downloads.
Skip it for now: Modern bundlers do it automatically. Until you use one, it’s not worth the hassle.

3. Cache busting

(“Cache” as in browser storage, not “cash”)

Problem: Browsers remember (cache) files so they don’t re-download them on every visit. Great for speed, but if you upload a new version of app.js, some users may keep loading the old cached copy.

Fix: Add a unique “fingerprint” to the filename each time you deploy, e.g. app.4f9d2.js. When the name changes, the browser treats it as brand-new and fetches the latest code. Bundlers automate this; by hand you can change the <script src> once in a while.

4. Tree-shaking (you may hear this next)

During bundling, unused pieces of a library are “shaken off the tree,” so only the parts you actually import ship to the browser. Again: automatic, not worth brain-space yet.

How this applies to Silent Reader right now

Your reality today	Fancy term	Should you care yet?
One HTML file + the Firebase snippet	Bundler	No.
File size under 100 kB	Minify	No.
You push updates by hand, readers are mostly you	Cache busting	No.
Using only the Firebase libraries you import	Tree-shaking	Already handled.