100 Days of Code

Hit the button to see my dev profile.

View developer profile

Day 20 - Freecodecamp - HTML Forms and Tables - 100% COMPLETE!

Day 19 - Freecodecamp - Build a Book Catalog - 100% COMPLETE!

View code

Behind-the-code

Book Catalog Code Commentary

0:00

/130.046871

This is the first coding project that I've done in weeks, and it was made in a fit of rage, mainly because I'm really sick of these platforms taking advantage of us indie authors, and I want to make my own platform.

And so, I figured I needed to get back to doing some code.

I won't be doing a lot of it, because I'm currently writing a book and organizing other things.

I've got a lot on my plate, but this was done with just VS Code.

VS Code pretty much has AI baked in, which is actually helpful, because I just jumped back in after pretty much a month from thinking about anything related to code for pretty much.

So it was helpful to just have the AI give me examples, but I really want to learn the code.

What I did was I re‑typed what the AI gave me.

This is still basic—it's just HTML—so it's not that complicated, but I re‑typed it in, and that was helpful in just getting me, "Okay, I forgot the tag for how to make a row in a table."

That was with this project.

And of course, you can see I snuck one of my titles into the mix of the classic works—you have a Keith Hayden classic in there as well, next to Tolkien and Orwell and old if Scott, old if Scotty in there—so it was fun.

I keep having to go back to reminding myself how to get my projects on GitHub, because any project that I do in VS Code I like to put on my GitHub, because it is sort of a developer résumé, and it's good to even put small projects on there, because you never know who's gonna check it out.

And that's the end of this commentary.

-Keith

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.