DEV Community: Andy

Building a Zero-Dependency, Lightning-Fast Practice Exam Platform with Vanilla JS & Modern CSS

Andy — Sun, 18 Oct 2026 21:02:38 +0000

When studying for vocational certifications like the EPA 608 HVAC Certification, students and technicians often encounter outdated practice test websites: heavy WordPress setups cluttered with ad networks, sluggish page loads, and clunky form-based quiz interfaces.

I wanted to challenge that status quo.

Instead of reaching for modern heavy frontend frameworks or bulky UI component libraries, I built the HVAC Exam Master EPA 608 Practice Test using pure Vanilla JavaScript and Modern CSS.

Here is why I chose zero-dependency development, how I designed the quiz engine, and what I learned along the way.

1. Why Vanilla JS & Pure CSS?

In an era dominated by React, Next.js, and complex build chains, going framework-free for a practice exam tool offered massive advantages:

Near-Zero Runtime Overhead: No virtual DOM reconciliation, hydration delays, or massive vendor chunks. The entire interactive bundle is just a few kilobytes.
Instant FCP & TTI: First Contentful Paint and Time to Interactive happen almost simultaneously, which is critical for mobile users studying on 4G/LTE networks in the field.
Future-Proof Stability: No framework deprecations, breaking major version bumps, or bloated node_modules.

Modern CSS (CSS Grid, Flexbox, CSS Variables) and ES6+ JavaScript have evolved to the point where standard UI interactions—like stateful quizzes and modal feedback—can be built cleanly without third-party libraries.

2. Core Architecture & Data Modeling

The exam engine relies on a clean, decoupled JSON data structure. Each question is represented with its metadata, options, correct answer index, and a detailed explanation:

const questions = [
  {
    id: "epa-core-01",
    category: "Core",
    question: "Which of the following refrigerants has the highest Ozone Depletion Potential (ODP)?",
    options: ["R-134a", "R-22", "R-11", "R-410A"],
    answerIndex: 2,
    explanation: "CFC-11 (R-11) is a Chlorofluorocarbon and has an ODP of 1.0, serving as the baseline benchmark."
  }
];

By decoupling question data from the DOM, the rendering engine can dynamically shuffle options, track score metrics, and render targeted explanations without touching the HTML markup structure.

3. Implementing the Interactive Quiz Engine

A responsive quiz interface needs three critical pieces:

Instant feedback upon selection (without a full page reload).
Preventing duplicate answer submissions while preserving reviewability.
Session persistence so learners don't lose progress if they accidentally refresh.

Handling Answer Selection with Immediate Feedback

Here is a simplified pattern of the state management and event delegation used to handle answer submissions:

function handleOptionSelect(selectedIndex, questionData, cardElement) {
  const optionsContainer = cardElement.querySelector('.options-list');
  const buttons = optionsContainer.querySelectorAll('button');
  const isCorrect = selectedIndex === questionData.answerIndex;

  // Disable buttons to lock state
  buttons.forEach((btn, index) => {
    btn.disabled = true;
    if (index === questionData.answerIndex) {
      btn.classList.add('is-correct');
    } else if (index === selectedIndex && !isCorrect) {
      btn.classList.add('is-wrong');
    }
  });

  // Reveal contextual explanation
  const explanationBox = cardElement.querySelector('.explanation-drawer');
  if (explanationBox) {
    explanationBox.classList.remove('hidden');
    explanationBox.setAttribute('aria-expanded', 'true');
  }

  // Update score & session storage
  recordAnswer(questionData.id, isCorrect);
}

4. Modern CSS Without Utility Frameworks

Instead of shipping megabytes of utility classes, the app uses CSS Custom Properties (Variables) to maintain consistent spacing, elevation, and design tokens:

:root {
  --color-primary: #0284c7;
  --color-success: #16a34a;
  --color-danger: #dc2626;
  --color-bg-subtle: #f8fafc;
  --radius-card: 12px;
  --shadow-sm: 0 1px 3px rgba(0, 0, 0, 0.05);
}

.option-button {
  display: flex;
  align-items: center;
  width: 100%;
  padding: 1rem 1.25rem;
  border: 1px solid #e2e8f0;
  border-radius: var(--radius-card);
  background: #ffffff;
  transition: transform 0.15s ease, border-color 0.15s ease;
  cursor: pointer;
}

.option-button:hover:not(:disabled) {
  border-color: var(--color-primary);
  transform: translateY(-1px);
}

.option-button.is-correct {
  background-color: #f0fdf4;
  border-color: var(--color-success);
}

.option-button.is-wrong {
  background-color: #fef2f2;
  border-color: var(--color-danger);
}

This keeps stylesheet sizes under 10 KB minified, while still providing smooth transitions, clear state indicators, and responsive layouts across mobile and desktop.

5. Key Takeaways & Try It Out

Going back to basics with Vanilla JS and CSS was a refreshing reminder that:

Web standards are capable enough on their own.
Speed is the best feature you can provide to a user who just wants to practice exam questions without distractions.
Clean DOM separation makes maintenance straightforward without the mental tax of build pipeline maintenance.

You can check out the live implementation here:
👉 HVAC Exam Master - EPA 608 Practice Test:
https://hvacexammaster.com/master-epa-608-practice-test/

Questions for the Community:

For multi-step quiz platforms, do you prefer rendering DOM elements on-the-fly via JS templates, or hydrating server-rendered static semantic markup?
What are your favorite patterns for handling lightweight client-side state without external state libraries?

Architecting Static Comparison Micro-Sites with TypeScript and JSON-LD Schema

Andy — Tue, 13 Oct 2026 19:44:35 +0000

When building vertical web applications, separating feature comparisons into standalone, fast-loading micro-sites is an effective way to keep your core application bundle lean while addressing specific user intents.

Recently, while building out supporting comparison pages for an educational test simulator, I designed a reusable data schema in TypeScript to render head-to-head feature matrices and inject structured JSON-LD data automatically.

Here is the architectural pattern and data model used to build these static comparison micro-sites.

1. Defining the Comparison Data Model in TypeScript

Instead of hardcoding HTML tables for each competitor analysis, defining a strict TypeScript interface ensures every micro-site renders consistent evaluation metrics (pricing model, learning format, regulatory updates, and pass guarantees):

export interface ComparisonMetric {
  featureName: string;
  primaryPlatformValue: string | boolean;
  competitorValue: string | boolean;
  highlightAdvantage?: boolean;
}

export interface ComparisonSiteConfig {
  slug: string;
  title: string;
  competitorCategory: 'legacy-portal' | 'career-directory' | 'trade-school';
  lastUpdatedYear: number;
  metrics: ComparisonMetric[];
}

By typing the competitorCategory, the UI components can dynamically adjust the layout depending on whether we are comparing two software tools or comparing digital self-study against an offline curriculum.

2. Live Production Deployments (Built on Lovable)

Using this modular structure, I deployed three separate micro-sites targeting different segments of the HVAC certification space:

Demo 1 (Legacy Portal Comparison): HVAC Exam Master vs EPATest.com — EPA 608 Prep Compared (2026) — Compares interactive active-recall testing (Core, Type I, II, and III modules) against static Web 1.0 study guides.
Demo 2 (Lead-Gen Directory Comparison): HVAC Exam Master vs HVAC Career Now (2026 Comparison) — Contrasts direct certification utility tools against school lead-generation portals.
Demo 3 (Offline Institution Comparison): HVAC Exam Master vs HVAC Technical Institute — 2026 Comparison — Evaluates self-paced digital exam prep ROI against traditional brick-and-mortar tuition costs.

3. Automating FAQ & Comparison JSON-LD Schema

To help search engines and AI answer engines parse the comparison matrices accurately, each micro-site injects a structured FAQPage and WebPage JSON-LD payload into the document head:

TypeScript

export function ComparisonSchema({ title, url, description }: { title: string; url: string; description: string }) {
  const schemaData = {
    "@context": "https://schema.org",
    "@type": "WebPage",
    "name": title,
    "url": url,
    "description": description,
    "specialty": "EPA Section 608 Certification Prep"
  };

  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{ __html: JSON.stringify(schemaData) }}
    />
  );
}

Key Takeaways for Frontend Builders

Decouple Content from Layout: A shared TypeScript schema lets you spin up multiple comparison landing pages in minutes.
Keep Micro-Sites Focused: Rather than building one massive table comparing ten different business models, isolating each comparison into its own deployment keeps page speed high and user intent clear.

Syncing localStorage to a Server Without Losing Data: Merges, Revisions, and Account Switching

Andy — Tue, 06 Oct 2026 20:26:57 +0000

I'm building a small web app where users practice exam questions. While practicing, they build up two lists: questions they bookmarked and questions they got wrong. Both are just arrays of question IDs.

Requirements:

Works without an account, so lists live in localStorage
After login, lists follow the user across devices
No framework and no sync library. Vanilla JS on the front end, and a backend endpoint that stores whatever JSON you send it

That last point matters. The server endpoint is deliberately simple:

GET  /sync  →  { bookmarks: [...], mistakes: [...] }
POST /sync  ←  { bookmarks: [...], mistakes: [...] }   // overwrites everything

No per-item operations, no timestamps, no conflict detection. Every POST replaces the whole snapshot. All the sync logic lives on the client.

This post covers what that client logic needs to get right. "Read from localStorage, POST it to the server" turns out to lose data in at least five different ways.

1. Keep localStorage boring and defensive

Everything starts with reading lists safely. localStorage can contain anything: malformed JSON from an old version, null, numbers where you expected strings, or duplicates.

function normalizeIdList(value) {
  if (!Array.isArray(value)) return [];
  const seen = new Set();
  const out = [];
  for (const id of value) {
    if (id === null || id === undefined) continue;
    const s = String(id).trim();
    if (!s || seen.has(s)) continue;   // drop empties and duplicates, keep first-seen order
    seen.add(s);
    out.push(s);
  }
  return out;
}

function readIdList(key) {
  try {
    return normalizeIdList(JSON.parse(localStorage.getItem(key) || '[]'));
  } catch {
    console.warn(`Invalid saved list for ${key}; using an empty list.`);
    return [];
  }
}

Every read and every write goes through normalizeIdList. That gives you one canonical form, so comparing two lists is just an element-by-element check:

const listsEqual = (a, b) => {
  const x = normalizeIdList(a), y = normalizeIdList(b);
  return x.length === y.length && x.every((id, i) => id === y[i]);
};

2. Coalesce writes: one request in flight, always send the latest state

A user can bookmark three questions in two seconds. Firing three POSTs creates two problems:

They can arrive out of order, and since every POST overwrites everything, an older snapshot that arrives last wins.
It's wasteful.

The fix: allow only one write in flight. While it runs, more change requests only set a flag. When the request finishes, if the flag is set, send the current state again.

let writePromise = null;
let writeRequested = false;

function syncToCloud() {
  if (!user.isLoggedIn) return Promise.resolve();
  writeRequested = true;
  if (writePromise) return writePromise;     // a loop is already running; it will pick this up

  const flush = async () => {
    while (writeRequested && user.isLoggedIn) {
      writeRequested = false;
      const payload = {
        bookmarks: readIdList('bookmarks'),   // snapshot taken NOW, not when requested
        mistakes: readIdList('mistakes'),
      };
      try {
        await fetch('/sync', { method: 'POST', headers: authHeaders(), body: JSON.stringify(payload) });
      } catch {
        console.warn('Cloud sync failed; local data is preserved.');
      }
    }
  };

  writePromise = flush().finally(() => {
    writePromise = null;
    if (writeRequested && user.isLoggedIn) syncToCloud();  // a request slipped in at the very end
  });
  return writePromise;
}

Because the payload is built inside the loop, every request carries the newest data. Ten quick changes turn into at most two requests: the one already in flight, plus one with the final state.

3. A revision counter: "did anything change while I was waiting?"

Coalescing handles write-vs-write. The harder race is read vs. write.

On login, the client GETs the server's lists and merges them in. But the GET takes time. If the user bookmarks something while the GET is in flight, and the response then gets merged on top of local state, the new local change can be lost or reordered unpredictably.

The fix is a counter that increases on every local change:

let revision = 0;

function writeList(key, ids, { markMutation = true } = {}) {
  const next = normalizeIdList(ids);
  const changed = !listsEqual(readIdList(key), next);
  localStorage.setItem(key, JSON.stringify(next));
  if (changed && markMutation) {
    revision++;
    localStorage.setItem('sync_pending', '1');   // see section 4
  }
  return changed;
}

The read path remembers the revision when it starts, and checks it before merging:

async function syncFromCloud() {
  if (!user.isLoggedIn) return;
  const revisionAtStart = revision;
  const wasPending = localStorage.getItem('sync_pending') === '1';

  const res = await fetch('/sync', { headers: authHeaders() });
  if (!res.ok) return;
  const remote = await res.json();

  if (revision === revisionAtStart && !wasPending) {
    // Nothing changed locally during the GET: safe to merge.
    mergeRemote(remote);
  } else {
    // Local state changed while we waited. Local is newer, so push it.
    syncToCloud();
  }
}

The write path uses the same counter to decide whether it's safe to say "we're in sync":

const revisionForPayload = revision;
const response = await fetch('/sync', { method: 'POST', /* ... */ });
if (response.ok && revisionForPayload === revision && !writeRequested) {
  localStorage.removeItem('sync_pending');   // only clear if nothing changed after the snapshot
}

Without that check, you can clear the "pending" flag for a snapshot that's already stale.

4. A pending flag that survives reloads

The revision counter lives in memory. It's gone when the user closes the tab. So the "I have changes the server hasn't seen" state also needs to be stored in localStorage:

Set sync_pending = '1' on every real local change
Clear it only after a successful POST of an up-to-date snapshot
On the next page load, if it's still set, don't merge server data over local data. Push local data first

This covers the most common data loss scenario: the user makes changes offline, or the POST fails, and they close the tab. Next time, the app loads stale server data. Without the persisted flag, a merge would treat the server as the source of truth, and the offline changes would compete with older data.

5. Merging: union, and push back if the server is behind

When it's safe to merge (nothing pending, nothing changed during the GET), the merge is a set union that keeps order:

function mergeRemote(remote) {
  const remoteBookmarks = normalizeIdList(remote.bookmarks);
  const merged = normalizeIdList([...readIdList('bookmarks'), ...remoteBookmarks]);

  // This write came from the server; don't mark it as a pending local change.
  writeList('bookmarks', merged, { markMutation: false });

  // If local had items the server didn't, push the merged result back.
  if (!listsEqual(remoteBookmarks, merged)) syncToCloud();
}

Union is the right default for the main use case. A guest bookmarks 10 questions, then logs in to an account that already has 30 from another device. They expect 40, not 10 and not 30.

Note markMutation: false. Writing server data locally isn't a user change, so it shouldn't bump the revision or set the pending flag. Otherwise every sync would trigger another sync.

6. Account switching: don't merge one person's data into another's

Union has a nasty side effect on shared devices. Alice logs out, Bob logs in on the same browser, and the merge happily uploads Alice's bookmarks into Bob's account.

The fix is to remember which account the local lists belong to:

function onLogin(nextUser) {
  const nextId = String(nextUser.id);
  const ownerId = localStorage.getItem('sync_owner_id') || '';
  const previousId = user.id ? String(user.id) : '';

  const accountChanged = (ownerId && ownerId !== nextId) || (previousId && previousId !== nextId);
  if (accountChanged) {
    localStorage.removeItem('bookmarks');
    localStorage.removeItem('mistakes');
    localStorage.removeItem('sync_pending');
    revision++;
  }
  localStorage.setItem('sync_owner_id', nextId);
  user = { ...nextUser, isLoggedIn: true };
  syncFromCloud();
}

A guest's lists have no owner yet, so they merge into the first account that logs in, which is the behavior you want. Once lists belong to someone, they never leak into a different account.

7. Evolving the stored format without breaking old clients

Eventually we needed to know where a mistake came from, practice or mock exam, so a question could be in both lists independently. Plain IDs became prefixed keys:

"q123"            → legacy format (no source)
"practice::q123"
"mock::q123"

Two rules kept this safe:

Readers accept both formats. A key without :: is parsed as { id: key, source: 'legacy' }.
Writers upgrade on touch. When a question is added or removed as a practice mistake, any legacy entry for the same ID is removed and replaced with the new key.

No migration script and no flag day. Old data upgrades itself as people use the app, and the server never needs to know the format changed, because it just stores arrays of strings.

The bug this design still has: deletions come back

Here's the honest part. A union merge can't represent deletions.

Device A and Device B both have [q1, q2].
On Device A, the user answers q1 correctly and it's removed from Mistakes. A pushes [q2]. The server now has [q2].
Device B was offline the whole time, with no pending changes. It loads, sees nothing pending, and merges: union([q1, q2], [q2]) = [q1, q2].
Device B decides the server is behind and pushes [q1, q2]. q1 is back, on every device.

The same thing happens with a "reset everything" button. The device that clears its data pushes empty lists, then any other device with stale data merges its lists back in on the next load.

The pending flag protects the device that made the change, but not the other devices. Union says "keep everything either side has," which by definition can't express "the user removed this."

How to fix it, from simplest to most robust

1. Tombstones. Store deletions as data:

{ items: ['q2'], removed: { q1: 1696500000000 } }   // id → deleted-at timestamp

The merge becomes union(items) − removed. Prune tombstones after a reasonable window, such as 90 days.

2. Per-item timestamps. Store { id, addedAt, removedAt } for every item and keep the most recent event per ID. It's a last-writer-wins element set, a simple CRDT.

3. Server-side operations. Replace "POST the whole snapshot" with POST /sync/ops [{ op: 'add', id }, { op: 'remove', id }], and let the server apply them in order. This needs a slightly smarter backend, but deletions become easy.

For a list of bookmarks, tombstones are usually enough, and they're a backward-compatible change to the payload.

The UX lesson

Since a destructive action syncs everywhere, it should say so. A reset button labeled "deletes progress only" that actually clears synced lists too is a trust problem, not just a bug. When local data is backed by a server, a "clear" action has to be honest about its scope: this device only, or every device.

Checklist

[ ] Every read and write goes through one normalizer (parse safely, dedupe, keep order)
[ ] One write in flight at a time, with the payload built from current state when it's sent
[ ] A revision counter checked before merging a GET response and before clearing "pending"
[ ] A persisted pending flag, so unsynced local changes survive reloads and failed requests
[ ] A union merge for the "guest data + account data" case, pushed back when the server is behind
[ ] Server data written locally doesn't count as a local change
[ ] Local data is tied to an owner account and cleared when a different account logs in
[ ] Readers accept old formats, and writers upgrade keys when they touch them
[ ] Deletions are represented explicitly (tombstones or timestamps), or you accept that they can come back
[ ] Destructive actions say clearly whether they affect this device or every device

This came from building HVAC Exam Master, an exam-prep web app for HVAC technicians. The front end is vanilla JS and the backend is a REST endpoint, which is why all the sync logic ended up on the client.

My first post

Andy — Sun, 06 Sep 2026 09:29:37 +0000

Just a test, my first post