DEV Community: neelam devi

I Turned a One-Page Classroom Tool Into an Installable PWA (No Framework, No Backend)

neelam devi — Sun, 18 Oct 2026 07:54:56 +0000

I Turned a One-Page Classroom Tool Into an Installable PWA (No Framework, No Backend)

My name picker is a static multi-page site: hand-written HTML, one shared styles.css, one app.js, no build step, no bundler, no framework. The last thing I wanted to add was a Node toolchain.

So when teachers started asking two things — "can I get this on my classroom tablet's home screen?" and "what happens when the school wifi drops?" — I made it a Progressive Web App. It's a few files, zero dependencies, and it gives you an installable icon plus offline mode for a site that was never "an app."

The three pieces

A PWA is really just three things working together:

A web app manifest so the browser can treat it like an app (name, icons, standalone display).
A service worker so the shell and assets can be served from cache, including when you're offline.
An install prompt so the user can actually put it on their home screen.

1. The manifest — `manifest.webmanifest`

{
  "name": "Random Student Picker",
  "short_name": "Name Picker",
  "start_url": "/",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#6C63FF",
  "icons": [
    { "src": "icon-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "icon-512.png", "sizes": "512x512", "type": "image/png", "purpose": "maskable" }
  ]
}

Link it in the <head>: <link rel="manifest" href="/manifest.webmanifest">. The maskable icon matters — it's the safe-zone version Android uses so your icon doesn't get cropped into a circle.

2. The service worker — cache-first, then revalidate

The design: serve the cached file instantly, and in the background fetch the network version to refresh the cache. This keeps the classroom experience instant even before the connection is confirmed, and it self-heals when a page changes.

const CACHE = 'rsp-v1';
const CORE = ['/', '/styles.css', '/app.js', '/manifest.webmanifest'];

self.addEventListener('install', (e) => {
  e.waitUntil(caches.open(CACHE).then((c) => c.addAll(CORE)));
});

self.addEventListener('fetch', (e) => {
  if (e.request.method !== 'GET') return;
  e.respondWith(
    caches.open(CACHE).then(async (cache) => {
      const cached = await cache.match(e.request);
      const network = fetch(e.request).then((res) => {
        if (res.ok) cache.put(e.request, res.clone());
        return res;
      }).catch(() => cached);
      return cached || network; // cache-first, revalidate in background
    })
  );
});

The one rule I'd never break for a tool like this: navigation requests need an offline fallback, or a bad wifi moment throws a white screen in front of a class.

// inside the fetch handler, for navigations only:
if (e.request.mode === 'navigate') {
  e.respondWith(
    fetch(e.request).catch(() => caches.match('/'))
  );
  return;
}

3. The install banner — `beforeinstallprompt`

Chrome fires beforeinstallprompt when the app meets the installability criteria (served over HTTPS, has a manifest, has a service worker). You can't call prompt() yourself — you can only show your own button when the user is ready:

let deferredPrompt;
window.addEventListener('beforeinstallprompt', (e) => {
  e.preventDefault();
  deferredPrompt = e;
  document.getElementById('installBtn').hidden = false;
});
document.getElementById('installBtn').addEventListener('click', async () => {
  if (!deferredPrompt) return;
  deferredPrompt.prompt();
  await deferredPrompt.userChoice;
  deferredPrompt = null;
  document.getElementById('installBtn').hidden = true;
});

Why "no framework" actually helped

Because there's no build step, the service worker precaches a short, known list of files — CORE above is the whole site. With a bundled SPA you're precaching hashed chunks and juggling stale bundles. A hand-written static site makes the offline story trivial: the files don't change shape, so the cache is honest.

The tradeoff is that you wire it all by hand (the SW registration, the manifest link, the icon set, the apple-touch-icon for iOS). For a multi-page static site that's a few hours, not a toolchain migration.

The honest limits

A PWA is not an APK. On iOS the "Add to Home Screen" flow still shows a little browser chrome.
If you add real user data later, "cache-first" needs care so you don't serve stale state. (This tool stores the roster in localStorage, not the cache, which sidesteps that.)

For a static tool that teachers open on a shared Chromebook with flaky wifi, it was exactly the right amount of complexity: installable, instant, offline-capable, and still just HTML/CSS/JS I can read top to bottom.

You can see the running result at randomstudentpicker.online — the install banner and offline mode are live on it.

Full disclosure: I built this tool. If you've made a framework-free PWA, I'm curious what you'd change about the cache strategy above.

How I Built a Fair Name Spinner (and Why Math.random() Is Good Enough for Your Classroom)

neelam devi — Sun, 18 Oct 2026 06:50:06 +0000

Every classroom has the same problem: "who answers?" If the teacher picks, students audit the teacher's preferences within a week. If students volunteer, the same three hands rule the room.

The fix I wanted was a spinner wheel — but with three constraints that most "wheel of names" tools get wrong:

Zero sign-up. Teachers won't create an account mid-lesson.
Zero upload. A class roster is minor data. It should never touch a server.
Visible fairness. The class watches the selection, so the selection has to be actually random, not shuffled-looking.

I built it as a single static page — vanilla JS, one canvas, no framework — and shipped it at randomstudentpicker.online. Here's the part that matters if you're building something similar.

The shuffle: Fisher–Yates, nothing else

Randomness in a picker usually happens twice: picking one name from N, and (for "no repeats" rounds) dealing names out in order. Both are just one algorithm done right: the Fisher–Yates shuffle.

function shuffle(arr) {
  for (let i = arr.length - 1; i > 0; i--) {
    const j = Math.floor(Math.random() * (i + 1));
    [arr[i], arr[j]] = [arr[j], arr[i]];
  }
  return arr;
}

Two properties make this "fair" in the way classrooms need:

Every permutation is equally likely — no position bias, no "the first name gets a head start."
It's in-place and O(n) — a 200-student roster shuffles in under a millisecond.

The tempting wrong version is arr.sort(() => Math.random() - 0.5). It looks identical in a demo and is not uniform — the comparator-based sort skews toward certain orderings depending on the engine's sort implementation. If your wheel "feels" rigged after a few rounds, this is usually why.

Is Math.random() actually random enough?

Honest answer: it's a PRNG, not a CSPRNG. Its seed is predictable if you know the algorithm, and the sequence is deterministic.

Does that matter here? Think about the threat model. A "rigged classroom wheel" requires someone to (a) know the seed, (b) predict the next ~30 outputs, and (c) care enough to exploit it during a 5th-grade reading circle. None of those are realistic. The fairness that matters in a classroom is procedural and visible — equal slice per name, in front of the class — not cryptographic.

If you're building a raffle with real money attached, use crypto.getRandomValues(). For a classroom, Math.random() is the right tool: fast, everywhere, and statistically indistinguishable for human-scale draws.

The wheel geometry

Fairness on screen comes down to one thing: equal arc angles. For N names, each slice gets exactly 2π / N radians:

const slice = (Math.PI * 2) / names.length;
// draw arc i from i*slice + rotation to (i+1)*slice + rotation

The spin animation is just easing toward a final rotation, where the final angle is chosen so the pointer lands on the pre-shuffled winner. The wheel is theater; the shuffle decided the result. That separation — decide first, animate second — is what keeps the animation smooth and the outcome honest. Don't read the winner off the animation.

The privacy design

The whole page is static. The roster lives in a <textarea> and in localStorage on the teacher's machine — that "remembers your class" feature people ask for is just localStorage, nothing else. There's no backend, no analytics on the roster field, and no "improve your experience" checkbox hiding a data pipeline.

For minor data, the architecture is the policy: it's impossible to leak what you never receive.

What I'd do differently

The canvas rendering could move to requestAnimationFrame-driven state (it's a bit chatty during long rosters).
A "weighted" mode would be a mistake — the moment you allow weighting, you re-introduce the teacher's bias. I've deliberately left it out.
The 10-language versions were an afterthought that turned out to be the highest-ROI feature: the Spanish and Hindi pages rank in markets the English-only competitors never looked at.

If you're building classroom tools: keep the roster local, make the randomness procedural and visible, and never ship a sign-up wall in front of a 30-second task.

Try the result: randomstudentpicker.online — group generator, seating chart, and raffle tools are on the same site, same architecture.

DEV Community: neelam devi

I Turned a One-Page Classroom Tool Into an Installable PWA (No Framework, No Backend)

I Turned a One-Page Classroom Tool Into an Installable PWA (No Framework, No Backend)

The three pieces

1. The manifest — manifest.webmanifest

2. The service worker — cache-first, then revalidate

3. The install banner — beforeinstallprompt

Why "no framework" actually helped

The honest limits

How I Built a Fair Name Spinner (and Why Math.random() Is Good Enough for Your Classroom)

The shuffle: Fisher–Yates, nothing else

Is Math.random() actually random enough?

The wheel geometry

The privacy design

What I'd do differently

1. The manifest — `manifest.webmanifest`

3. The install banner — `beforeinstallprompt`