Coder Legion - Recent posts tagged pwa

Building a High-Speed School Marketplace: Why We Ditched Frameworks for Vanilla JS & PWA

Wed, 07 Oct 2026 04:14:44 +0000

This is Part 1 of a 4-part series on building a high-speed, race-condition-proof digital marketplace for schools using Vanilla JS, Supabase RLS, PostgreSQL RPC, and Cloudflare Workers.

In the modern web ecosystem, starting any web project without reaching for React, Next.js, or Vue has almost become taboo.

Yet, when our team at Setvy sat down to architect Aksara-Mart—a digital marketplace serving thousands of students and teachers across our vocational high school—we made an intentional, contrarian decision:

We threw out the frontend frameworks and built the entire client in pure Vanilla JavaScript, modern CSS, and PWA standards.

Why? Because when your user base consists of students using second-hand, $80 Android phones running on limited prepaid mobile data, developer convenience cannot come at the expense of end-user performance.

Here is what we learned, why it paid off, and how you can implement a high-speed Vanilla JS architecture.

1. The Reality of School Hardware

Before writing a single line of code, we profiled our target environment:

Hardware Constraints: 65% of students carry entry-level devices with 2GB to 3GB of RAM, powered by aging Quad-core MediaTek or Snapdragon 400-series processors.
Prepaid Data, Not Wi-Fi: Most students don't rely on school Wi-Fi at all—they browse on their own prepaid mobile data plans (kuota). Every megabyte is paid out of their pocket money, so a heavy page literally costs them. On top of that, when hundreds of phones hit the same nearby cell tower during recess—from inside concrete classroom buildings—effective speeds often drop to 2G/3G levels.
The Recess Rush: Students have a very brief window between bells to browse the canteen menu, order food, and pick it up. A 4-second loading screen means they don't eat.

The Modern Framework Tax on Budget Devices

A barebones Next.js or React e-commerce template typically ships:

250 KB – 500 KB of minified JavaScript.
JavaScript Parsing & Compilation Time: On an iPhone 16 or M3 MacBook, parsing 300KB of JS takes 15 milliseconds. On a budget Android phone, it takes 1,200 to 2,500 milliseconds.
Hydration Lag (Total Blocking Time): The page looks loaded, but clicking the "Add to Cart" button does nothing because the JavaScript thread is frozen during hydration.

On high-end dev laptops, this latency is invisible. On budget devices, it ruins the experience.

2. The Architecture: Under 50 KB, 60 FPS

By returning to web fundamentals, we achieved:

Total Initial JS + CSS Payload: < 48 KB (gzipped).
First Contentful Paint (FCP): ~320 ms on low-end 4G.
Time to Interactive (TTI): Instantaneous.

Here is how our client structure looks:

aksaramart/
├── public/
│   ├── index.html       # Semantic HTML5 shell & modal templates
│   ├── skripmart.js     # Modular Vanilla JS logic (~35 KB)
│   ├── stylemart.css    # Clean, framework-free CSS with CSS Variables
│   ├── sw.js            # PWA Service Worker for caching & offline resilience
│   └── manifest.json    # Progressive Web App configuration

3. Clean Patterns for Vanilla JS State & DOM

Building with Vanilla JS doesn't mean writing chaotic spaghetti code. We used modern ES6+ patterns, event delegation, and atomic state rendering.

Pattern A: Modular State Store

// A lightweight, reactive-free state store
const appState = {
    cart: JSON.parse(localStorage.getItem('aksara_cart') || '[]'),
    products: [],
    currentUser: null,
    activeCategory: 'all'
};

function saveCart() {
    localStorage.setItem('aksara_cart', JSON.stringify(appState.cart));
    renderCartBadge();
}

function addToCart(productId) {
    const product = appState.products.find(p => p.id === productId);
    if (!product || product.stock <= 0) return;

    const existing = appState.cart.find(item => item.id === productId);
    if (existing) {
        if (existing.qty < product.stock) existing.qty++;
    } else {
        appState.cart.push({ id: product.id, name: product.name, price: product.price, qty: 1 });
    }
    saveCart();
    renderCartUI();
}

Pattern B: High-Performance Event Delegation

Instead of attaching individual click listeners to hundreds of catalog items, we attached a single listener to the container:

document.getElementById('catalogGrid').addEventListener('click', (e) => {
    const btn = e.target.closest('[data-action="add-to-cart"]');
    if (!btn) return;
    
    const productId = btn.dataset.productId;
    addToCart(productId);
    
    // Smooth micro-animation without any animation library
    btn.classList.add('scale-bounce');
    setTimeout(() => btn.classList.remove('scale-bounce'), 250);
});

4. Making It a True App: Progressive Web App (PWA)

Most students won't go to Google Play or the App Store to install a canteen app. But with PWA standards, they can install it directly from the browser in 1 tap.

Step 1: Web App Manifest (`manifest.json`)

{
  "name": "Aksara Mart - Kantin & Koperasi Sekolah",
  "short_name": "AksaraMart",
  "start_url": "/",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#10b981",
  "icons": [
    {
      "src": "/icons/icon-192.png",
      "sizes": "192x192",
      "type": "image/png"
    },
    {
      "src": "/icons/icon-512.png",
      "sizes": "512x512",
      "type": "image/png"
    }
  ]
}

Browsers often show a subtle or clunky native install banner. We intercepted the beforeinstallprompt event to give students an explicit, high-visibility install button in the top navigation:

let deferredPrompt;
const installBtn = document.getElementById('installAppBtn');

window.addEventListener('beforeinstallprompt', (e) => {
    // Prevent default mini-infobar
    e.preventDefault();
    deferredPrompt = e;
    // Show our custom branded install button
    if (installBtn) installBtn.style.display = 'inline-flex';
});

installBtn?.addEventListener('click', async () => {
    if (!deferredPrompt) return;
    deferredPrompt.prompt();
    const { outcome } = await deferredPrompt.userChoice;
    console.log(`User install outcome: ${outcome}`);
    deferredPrompt = null;
    installBtn.style.display = 'none';
});

Step 3: Cache-First Service Worker (`sw.js`)

To guarantee instant loading even when the cellular signal drops (or a student's data quota runs out mid-week), our Service Worker caches core static shell assets—so repeat visits cost almost zero data:

const CACHE_NAME = 'aksaramart-v1.4';
const STATIC_ASSETS = [
    '/',
    '/index.html',
    '/skripmart.js',
    '/stylemart.css',
    '/manifest.json',
    '/icons/icon-192.png'
];

self.addEventListener('install', (e) => {
    e.waitUntil(
        caches.open(CACHE_NAME).then(cache => cache.addAll(STATIC_ASSETS))
    );
    self.skipWaiting();
});

self.addEventListener('fetch', (e) => {
    // Only cache static GET requests, let API requests go to network
    if (e.request.url.includes('/rest/v1/') || e.request.url.includes('/rpc/')) {
        return;
    }
    e.respondWith(
        caches.match(e.request).then(cached => cached || fetch(e.request))
    );
});

5. The Performance Verdict

Here is the Lighthouse audit comparison run on an emulated Moto G4 with a throttled 3G network:

Metric	Typical Next.js / React E-Commerce	Aksara-Mart (Vanilla JS + PWA)
Performance Score	62 / 100	99 / 100
First Contentful Paint (FCP)	2.9 s	0.34 s
Total Blocking Time (TBT)	840 ms	0 ms
Speed Index	3.4 s	0.6 s
Total Transfer Size	380 KB	46 KB

6. Conclusion

Ditching frameworks for Vanilla JS proved to be a resounding success for our students and teachers. The app launches immediately, remains completely immune to hydration freezes, and preserves scarce phone battery and memory.

However, a fast frontend is completely meaningless if the underlying database is vulnerable. How do we secure transaction data from curious IT vocational students who open Inspect Element / DevTools to try altering menu prices from $1.50 to $0.01?

In the next article, we'll dive deep into our Zero-Trust database security architecture using Supabase Row Level Security (RLS) and multi-role governance.

Project LifeOps (Part 5): 24/7 Zero-Cost Cloud Deployment ($0/month), Mobile Optimization, and PWA

Sat, 19 Sep 2026 10:13:09 +0000

We have arrived at the grand finale of our engineering series. Across the four previous installments, we designed the database architecture and FastAPI backend, crafted the Glassmorphism Dark Mode React interface, built the interactive fitness, reading, cinema, and Kanban modules, and developed the in-memory Word and Excel reporting engine.

Yet in software development, a sobering pattern exists: countless extraordinary personal projects wither and die on localhost:3000 or localhost:8000.

The obstacle is almost always the same: production cloud deployment is often perceived as a labyrinth of daunting server configurations, mounting database subscription fees, or the burden of maintaining live virtual machines. And when aiming to bring web apps to smartphones, developers frequently encounter costly gatekeepers: Apple Developer fees ($99/year), Google Play fees, opaque store review cycles, and massive hybrid frameworks.

In this final installment, we demonstrate a far more elegant, sustainable path:

Deploying the entire full-stack architecture 24/7 at exactly $0.00/month.
Seamlessly handling free cloud container sleep cycles (cold-starts) on the client side.
Engineering an ultra-ergonomic touch experience optimized for modern smartphones (Android / Samsung Galaxy and iPhone).
Transforming the application into an installable Progressive Web App (PWA) added directly to home screens.

[!TIP]
Test the live app: You can explore the final production release of LifeOps at https://datalaria.com/apps/lifeops/.

🗺️ Complete LifeOps Series Roadmap

With this post, the full 5-part blueprint is complete:

🟢 Part 1: Personal Operating System Architecture and FastAPI + Supabase Backend
🟢 Part 2: React Frontend with Glassmorphism, 360° Dashboard, and Design System
🟢 Part 3: Core Interactive Modules: Fitness, Library, Cinema, and Professional Kanban Board
🟢 Part 4: Executive Word (.docx) Reporting Engine and Multi-Sheet Excel (.xlsx) Export
🟢 Part 5 (This article): 24/7 Zero-Cost Cloud Deployment ($0/month), Mobile UX, and PWA

1. Production Cloud Topology ($0/month) 🌐☁️

To guarantee that LifeOps remains online 24/7 without recurring cloud invoices, we strategically leverage the most generous free tiers available:

┌─────────────────────────────────────────────────────────────┐
│                       CLIENT DEVICE                         │
│           Web Browser / Installed Home Screen PWA           │
│            [https://datalaria.com/apps/lifeops/](https://datalaria.com/apps/lifeops/)              │
└──────────────────────────────┬──────────────────────────────┘
                               │
                               ▼
┌─────────────────────────────────────────────────────────────┐
│               FRONTEND: Netlify Edge CDN ($0/month)         │
│   • Vite build with Rollup Code Splitting (vendor-*)        │
│   • Instant global edge delivery via Gzip / Brotli          │
│   • Transparent proxy rewrite under Datalaria domain        │
└──────────────────────────────┬──────────────────────────────┘
                               │
            JWT Bearer Tokens  │  HTTPS REST Calls
                               ▼
┌─────────────────────────────────────────────────────────────┐
│               BACKEND: Render.com Web Service ($0/month)    │
│   • FastAPI + Uvicorn container (Python 3.11 / 3.13)        │
│   • Endpoint: [https://lifeops-api.onrender.com](https://lifeops-api.onrender.com)              │
│   • Anti-DoS Rate Limiting (slowapi) + Strict CORS          │
│   • Auto-spins down after 15 minutes of inactivity          │
└──────────────────────────────┬──────────────────────────────┘
                               │
                               ▼
┌─────────────────────────────────────────────────────────────┐
│              DATABASE: Supabase Cloud ($0/month)            │
│   • Managed PostgreSQL 15+ database instance                │
│   • Isolated `lifeops` schema with Row Level Security (RLS) │
│   • Cryptographic JWT session validation                    │
└─────────────────────────────────────────────────────────────┘

1.1. Vite Bundle Optimization (`vite.config.js`)

To guarantee sub-second initial loads across 4G and 5G mobile networks, we configured Rollup manual chunking:

import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';

export default defineConfig({
  plugins: [react()],
  base: './', // Enables serving the SPA from any nested route (/apps/lifeops/)
  build: {
    rollupOptions: {
      output: {
        manualChunks(id) {
          if (id.includes('node_modules')) {
            if (id.includes('react') || id.includes('react-dom') || id.includes('react-router-dom')) {
              return 'vendor-react';
            }
            if (id.includes('lucide-react')) {
              return 'vendor-icons';
            }
            if (id.includes('@supabase')) {
              return 'vendor-supabase';
            }
            return 'vendor-libs';
          }
        },
      },
    },
    chunkSizeWarningLimit: 600,
  },
});

By segmenting vendor-react and @supabase, user browsers permanently cache stable external dependencies. When application features update, visitors download only a lightweight diff of new business logic.

2. Conquering Cold-Starts: Client-Side Resilience 🛡️⏱️

The only operational tradeoff on Render's free tier is container hibernation after 15 minutes of zero traffic.

When an end-user opens LifeOps after hours of downtime, the first HTTP request requires 25 to 45 seconds while Render allocates a container and initializes Uvicorn. Without proactive client-side handling, users face gateway timeouts (HTTP 504) or frozen interfaces.

In LifeOps, we turned this limitation into an informative, guided user experience:

// lifeops-app/src/components/Dashboard/SystemHealth.jsx
const checkHealth = async (isAutoRetry = false) => {
  setLoading(true);
  if (!isAutoRetry) setError(null);

  try {
    const data = await api.getHealth();
    setHealth(data);
    setError(null);
  } catch (err) {
    setError(err.message || 'Connecting to API...');
    
    // Auto-retry loop up to 3 times with 6-second delay while Render awakens
    if (retryCount < 3) {
      setTimeout(() => {
        setRetryCount((prev) => prev + 1);
      }, 6000);
    }
  } finally {
    setLoading(false);
  }
};

What happens behind the scenes?

The initial health check dispatches a wake-up ping to the backend.
The UI renders a friendly, transparent notification: "Render instance waking up (Cold start)... retrying automatically".
The frontend retries in the background every 6 seconds without interrupting client navigation.
As soon as FastAPI responds with HTTP 200, the badge shifts to green ("FastAPI Online • Supabase Connected"), fetching data without requiring a manual page refresh.

3. Thumb-Accessible Mobile Ergonomics (Android & iOS) 📱👍

Over 70% of daily interactions with a personal operating system occur on smartphones: logging a workout right after a run, cataloging a book during a commute, or reviewing Kanban deliverables from the couch.

On a 6.5-inch device held in one hand, forcing the user's thumb to reach all the way to the top-left corner for a hamburger menu is poor ergonomic design.

We anchored the mobile user experience on three ergonomic pillars:

┌─────────────────────────────────────────────────────────────┐
│ 📱 SMARTPHONE VIEWPORT (<= 768px)                           │
├─────────────────────────────────────────────────────────────┤
│  [Top Header]: LifeOps Logo       [Locale ES/EN] [User Icon]│
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌───────────────────────────────────────────────────────┐  │
│  │ 🪟 FLOATING MODAL (React Portal)                      │  │
│  │ ───────────────────────────────────────────────────── │  │
│  │ [=== Drag Handle: slide down to dismiss ===]          │  │
│  │                                                       │  │
│  │  Title: Log Workout Session                           │  │
│  │  • 16px font inputs (prevents iOS Safari auto-zoom)   │  │
│  │  • Smooth touch scroll (touch-action: pan-y)          │  │
│  │                                                       │  │
│  │ ───────────────────────────────────────────────────── │  │
│  │ [📌 STICKY FOOTER ACTIONS: [ Cancel ] [ Save Record ]]│  │
│  └───────────────────────────────────────────────────────┘  │
│                                                             │
├─────────────────────────────────────────────────────────────┤
│ 📌 FIXED BOTTOM NAVIGATION BAR (Height: 64px)               │
│ [ 📊 Dashboard ] [ 🏃 Personal ] [ 💼 Tasks ] [ ⚙️ Settings ]│
└─────────────────────────────────────────────────────────────┘

3.1. Fixed Bottom Navigation Bar (`BottomNav.jsx`)

Stationed permanently along the screen footer (position: fixed; bottom: 0; z-index: 1000;), it houses 5 prominent touch targets (48x48px touch bounding boxes following Apple and Google accessibility standards), allowing instantaneous section transitions with a thumb tap.

3.2. Off-Canvas Sliding Drawer

The primary navigation sidebar (Sidebar.jsx) switches behavior based on screen real estate:

On Desktop (> 768px): Expands to 260px or collapses to a slim 72px icon bar with floating tooltips, persisted in localStorage.
On Mobile (<= 768px): Becomes an Off-Canvas drawer sliding in over a frosted backdrop (backdrop-filter: blur(8px)), auto-dismissing on link navigation.

3.3. Viewport-Anchored Modals with `React.createPortal` (`Modal.jsx`)

Form modals in mobile CSS are notorious for layout bugs: getting clipped by ancestor containers, misaligning behind virtual keyboards, or burying save buttons beneath the fold.

In LifeOps, we engineered a clean architectural solution:

// Rendered directly into document.body via React Portal
export function Modal({ isOpen, onClose, title, children }) {
  ...
  if (!isOpen) return null;

  return createPortal(
    <div className="modal-backdrop" onClick={onClose}>
      <div className="modal-content" onClick={(e) => e.stopPropagation()}>
        {/* Touch drag handle for swipe-to-close */}
        <div className="modal-drag-handle-area" onTouchStart={handleTouchStart} onTouchMove={handleTouchMove} onTouchEnd={handleTouchEnd}>
          <div className="modal-drag-pill" />
        </div>
        <div className="modal-header">...</div>
        <div className="modal-body">{children}</div>
      </div>
    </div>,
    document.body
  );
}

/* Precise Mobile Viewport Anchoring (Modal.css) */
@media (max-width: 768px) {
  .modal-backdrop {
    padding: 12px 10px calc(64px + 12px) 10px; /* Terminates exactly above the bottom nav */
    height: 100dvh; /* Dynamic Viewport Height handles mobile address bars */
  }

  .modal-body {
    touch-action: pan-y !important; /* Smooth touch gesture scrolling */
  }

  .form-group input, .form-group select {
    font-size: 16px !important; /* Prevents unwanted iOS Safari viewport auto-zooming */
  }

  /* Action buttons remain permanently docked in view */
  .form-actions {
    position: sticky !important;
    bottom: 0 !important;
    background: #111827 !important;
    z-index: 30;
  }
}

With createPortal, modals break free from ancestor stacking contexts. And thanks to calc(64px + 12px) and sticky footers, the Cancel and Save buttons remain permanently anchored in thumb view, regardless of form length.

4. Progressive Web App (PWA) Transformation 📲✨

For an application to feel native on a mobile device, it must install without store middlemen.

We configured modern meta tags and web app standards in index.html:

<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no, viewport-fit=cover" />
<meta name="theme-color" content="#111827" />
<meta name="apple-mobile-web-app-capable" content="yes" />
<meta name="apple-mobile-web-app-status-bar-style" content="black-translucent" />
<link rel="icon" type="image/svg+xml" href="favicon.svg" />

Key Benefits as an Installed PWA:

Home Screen Presence: High-resolution branded icon sitting alongside native apps on Android and iOS.
Fullscreen Standalone Mode: Browser URL bars and navigation chrome disappear, reclaiming 15% of vertical screen space.
Status Bar Theming: Device battery and clock bars harmonize seamlessly with the #111827 glassmorphic palette via theme-color.
Instant Updates: New builds deploy live over Git without waiting days for third-party store approvals.

5. Retrospective: Lessons Learned from the LifeOps Blueprint 🎓💡

Architecting and engineering LifeOps from the ground up has been one of the most rewarding journeys documented on Datalaria.

To conclude our technical journey, here are the three foundational takeaways:

Relational modeling outperforms flat schemas as telemetry matures:
Structuring general events in lifeops.activities with 1-to-1 extension tables (workouts, books, films) and employing JSONB for progress timelines delivered superior maintainability over sprawling, null-riddled tables.
Deliberate design fosters consistent user adherence:
Investing in visual polish (Glassmorphism, hardware-accelerated blurs, Outfit typography, and consistent Lucide iconography) transforms daily logging into an enjoyable ritual rather than a chore.
Modern serverless tooling enables $0/month production without compromises:
The pairing of FastAPI + Supabase + React (Vite) + Render + Netlify provides reliability, speed, and cryptographic security rivaling commercial SaaS platforms charging $15/month per seat.

Series Conclusion & Complete Index 🚀

With this fifth installment, the official LifeOps series stands complete. You have access to the complete source code, architectural rationales, and production implementation details step by step.

I invite you to try the live application, experiment with its modules, and draw inspiration to build your own bespoke systems guided by Datalaria's core motto: "Learn by building".

Complete Series Reference & Links 🔗

🚀 LifeOps Live Application: datalaria.com/apps/lifeops.
🌐 Interactive OpenAPI Docs: lifeops-api.onrender.com/docs.
📚 Part 1: Personal Operating System Architecture and FastAPI + Supabase Backend.
🎨 Part 2: React Frontend with Glassmorphism, 360° Dashboard, and Design System.
📋 Part 3: Core Interactive Modules: Fitness, Library, Cinema, and Professional Kanban Board.
📊 Part 4: Executive Word (.docx) Reporting Engine and Multi-Sheet Excel (.xlsx) Export.
☁️ Part 5 (This article): 24/7 Zero-Cost Cloud Deployment ($0/month), Mobile UX, and PWA.

Thank you for following along throughout this series! If you are building your own personal operating systems or have ideas for enhancements, share your insights in the comments below. 👇

Caching Strategy for Offline Web Games: Install Group vs Lazy Group

Sat, 29 Aug 2026 01:22:38 +0000

Most of the PWA writing out there is aimed at content sites, and games break those assumptions immediately because the asset budget is an order of magnitude larger. This is the split that has worked for us, written for people who ship builds rather than blog posts.

The Three Requirements, Briefly

A browser game becomes installable when three things are true: it is served over HTTPS, it links a web app manifest, and it registers a service worker. The manifest is a JSON file describing the name, the icon set, the theme colors, the display mode and the start URL, and it is what turns the thing from a page into a home screen icon with a splash screen. The service worker is the part that does real work.

Split Your Assets Into Two Groups

The mistake is caching everything during service worker install. A 200 MB precache means the install event runs for a minute on a bad connection and the browser may kill it, so you get no offline support at all rather than partial support.

Split instead. The install group is whatever the player needs to reach an interactive first screen: the engine bundle, the UI atlas, the font, the first level, the menu music. That should be small enough to fetch in a few seconds. Everything else is the lazy group, cached on first use with a cache-first handler, so level 12 lands in the cache the first time someone reaches level 12 and is available offline afterward.

Version your cache names and delete old caches in the activate event. Without that, a shipped update leaves the previous build's assets on the device forever, and players report bugs you already fixed.

Where Saves Actually Live

Small state goes in localStorage: settings, the current level, a coin count. It is synchronous, it is capped around 5 MB, and it is fine for anything you would have put in a config file.

Anything structured goes in IndexedDB: full save states, replays, downloaded user content, large inventories. It is asynchronous and awkward to use directly, so wrap it or use a small library, but it is the only browser storage that will hold a real save file.

Both are subject to eviction. A player who installs the game to their home screen gets persistent storage in most browsers, which is a good argument for prompting the install rather than treating it as a nice extra.

iOS Is Where the Plan Breaks

Test on iOS before you commit to a PWA-only distribution plan. Storage limits are tighter and eviction is more aggressive, audio behavior around the first user gesture is stricter, and the install flow is a manual Add to Home Screen through the share sheet rather than a prompt you can trigger. None of that is fatal, but all of it is easier to design around than to retrofit.

The longer version, covering install prompts, the manifest fields that matter and the honest comparison against native, is in our guide to PWA games.

When Not To Bother

If your game is a one-off jam entry that nobody will open twice, the service worker is wasted work. PWA pays off when players come back, and the return visit is the whole reason to spend the effort on cache versioning and save durability.

The Web needs a Save button.

Thu, 07 May 2026 10:53:44 +0000

Every web app today behaves like it has short-term memory loss.

You type something, switch tabs, get a call, refresh the page… and everything is gone.

We accepted this like it’s normal. It’s not.

The Idea

I’ve been building something around a simple concept:

What if web apps had a Save button?

Not autosave. Not background sync. Not “hope the browser keeps it.”

A real, intentional Save button — like in desktop apps.

Click it, and your app state is preserved.
Close the tab, reopen it later, and you continue exactly where you left off.

Why this matters

The modern web is powerful, but fragile:

Page refresh = data loss
Tab crash = lost work
Mobile background kill = reset state
Poor connectivity = broken flow

We keep rebuilding “state persistence” in every app like it’s a custom problem.

It shouldn’t be.

⚙️ What I’m working on

A small persistence layer for web apps that acts like a Save button for state:

Manual or automatic save triggers
Restore exact UI state on reload
Works with modern browser storage APIs
Designed to be lightweight, not a framework

Think of it as:

Not a backend replacement
Not a full database layer
Just a reliable memory switch for web apps

The goal

To make persistence:

obvious
reusable
boring (in a good way)

So instead of every developer reinventing state recovery, they just… press Save.

Why I’m posting this

Because if this idea is useful, it shouldn’t stay hidden in one project.

If you build web apps, you’ve probably rebuilt this problem in your own way already.

Now imagine if it was standardized as a simple pattern:

"Just add a Save button.”

Final thought

The web doesn’t need more complexity.

It needs better memory.

Enhancement on service worker and caching

Sat, 07 Feb 2026 17:00:46 +0000

title: "Enhancement on Caching and Service Workers"
published: true

tags: video, youtube, devcommunity, javascript, cache, performance

Welcome to My Video Post

Following my previous article on getting started with service workers and caching,
I’ve created a video explaining how to update an already existing cache.

Enjoy!

Final Thoughts

Thanks for watching!
If you’ve tried similar caching strategies, share your experience in the comments—I’d love to compare notes.

Bad UX every website/PWA overlooks — the mobile navigation

Wed, 04 Feb 2026 20:18:33 +0000

Building a progressive web app is different from building a regular website, because every part of it has to be treated like a native app.

I’ve built several progressive web apps, and the most important thing to get right is the mobile navigation. Once a user installs your PWA (hopefully), they expect it to behave exactly like an app.

Have you ever been on a website on a mobile device, tapped something that opened a modal, and then the moment you pressed or swiped back, the whole site just closed?

Yes! Not even the ChatGPT website handles mobile navigation properly. After clicking the login button, a dialog appears. On mobile, the expected way to close a dialog is by pressing or swiping back, but that wasn’t considered, you’re expected to tap the overlay or the close button instead.

Compare that to this progressive web app, which handles navigation properly: Pluxscore.

We’ve been building the web with a huge focus on mobile responsiveness, while quietly ignoring mobile navigation.

Mobile users, especially Android users, are used to swiping back to close modals or dialogs, navigate between pages, or interact with a website or PWA in different situations.

It was while building Pluxscore, the first progressive web app I worked on, that I ran into this problem.

In plain JavaScript, when a user swipes back on mobile, the current location is removed from the history stack. The fix is to control UI elements by storing their visibility state as part of navigation.

That means when a user triggers a dialog, we navigate to the same URL, but with a different state.

I had two ways to approach this: using the history.state API, or using URLSearchParams.

https://developer.mozilla.org/en-US/docs/Web/API/History/pushState#examples

/* When using history.state */
function openSidebar(){
  const state = { open_sidebar: true };
  history.pushState(state, "");
}

/* When using URLSearchParams */
function openSidebar(){
  const url = new URL(location);
  url.searchParams.set("open_sidebar", "true");
  history.pushState({}, "", url);
}

I tried URLSearchParams at first, but it makes the URL look like this:

https://example.com?open_sidebar=true

Using history.state is much better, because the URL doesn’t change and you can store serializable values in it.

Since I use React for my progressive web apps, I have to manage this state through React Router.

A basic example of that would look like this:

import { useLocation, useNavigate } from "react-router";
import { useCallback } from "react";

export default function App() {
  const navigate = useNavigate();
  const location = useLocation();

  /** Track sidebar state */
  const isSidebarOpened = location.state?.isSidebarOpened || false;

  /* Open sidebar */
  const openSidebar = useCallback(() => {
    navigate(location, {
      state: {
        ...location.state,
        isSidebarOpened: true,
      },
    });
  }, [location, navigate]);

  /* Close sidebar */
  const closeSidebar = useCallback(() => {
    navigate(-1);
  }, [navigate]);

  return (
    <>
      <button onClick={openSidebar}>Open sidebar</button>
      {isSidebarOpened ? (
        <div>
          {/* Sidebar content */}
          <button onClick={closeSidebar}>Close sidebar</button>
        </div>
      ) : null}
    </>
  );
}

But in a complex UI, there are usually more elements that trigger a modal/dialog within a single page, e.g. a sidebar dialog, login dialog, post edit dialog, etc.
So I created two hooks specifically for this: useLocationState.ts and useLocationToggle.ts

useLocationState.ts
This hook exposes an API similar to useState, allowing you to push any serializable value into the history stack. It accepts a default value if the item doesn’t exist in the current location state.

Removing an item is as simple as navigating back or setting the value to undefined. If the app is reloaded in this state, it falls back to navigating to the root.

//useLocationState.ts
import { useCallback, useMemo } from "react";
import { useLocation, useNavigate, type NavigateOptions } from "react-router";

export default function useLocationState<T>(
    key: string,
    defaultValue: T,
): [T, (value?: T, options?: NavigateOptions) => void] {
    const navigate = useNavigate();
    const location = useLocation();
    
    /** Current value */
    const value =
        typeof location.state?.[key] !== "undefined"
            ? location.state?.[key]
            : defaultValue;

    /** Set value */
    const setValue = useCallback(
        (newValue?: T, options?: NavigateOptions) => {
            if (typeof newValue !== "undefined") {
                navigate(location, {
                    ...options,
                    state: {
                        ...location.state,
                        ...options?.state,
                        [key]: newValue,
                    },
                });
            } else {
                if (location.key !== "default") {
                    navigate(-1);
                } else {
                    navigate("/", { ...options, replace: true });
                }
            }
        },
        [key, navigate, location],
    );

    return useMemo(() => [value, setValue], [value, setValue]);

}

useLocationToggle.ts
This is a wrapper around the useLocationState hook. It stores a boolean and provides a method to toggle the state.

//useLocationToggle.ts
import { useCallback, useMemo } from "react";
import { type NavigateOptions } from "react-router";
import useLocationState from "./useLocationState";

export default function useLocationToggle(
    key: string,
): [boolean, (status: boolean, options?: NavigateOptions) => void] {
    /** Current State */
    const [show, setShow] = useLocationState(key, false);

    /** Toggle Location */
    const toggle = useCallback(
        (status: boolean, options?: NavigateOptions) => {
            if (status) {
                setShow(true, options);
            } else {
                setShow(undefined);
            }
        },
        [key, setShow],
    );

    return useMemo(() => [show, toggle], [show, toggle]);
}

When put into use, it behaves much like useState(), which makes it easy to replace existing code that already relies on useState().

export default function App(){
  const [opened, setOpened] = useLocationToggle("homepage-sidebar");
  return (
    <>
      <button onClick={()=>setOpened(true)}>Open sidebar</button>
      {opened ? (
        <div>
          {/* Sidebar content */}
          <button onClick={()=>setOpened(false)}>Close sidebar</button>
        </div>
      ) : null}
    </>
  );
}

In the demonstration above, the sidebar is controlled by its own state in the location, and the same applies to the matches being displayed. We can end up with a state that looks like this:

/* Sidebar */
{
    sidebar: true,
}

/* Match details */
{
    ['match-1234-details']: true,
}

Ever since then, I’ve been implementing this across all the progressive web apps I build.

As the creator of PWABucket, I believe we can build progressive web apps that are fast, responsive, indistinguishable from native apps, and deliver a solid user experience across platforms.

You can see the same implementation in Parcel (https://parcel.pwabucket.com
).

Another example shown in the Tracker PWA (https://tracker.pwabucket.com/)

The modern web offers a ton of rich APIs, and if you build a progressive web app carefully and pay close attention to detail, you can create truly engaging experiences.

I specialize in pixel-perfect progressive web apps. If you’re looking for someone to bring your app ideas to life, I’m currently open for work. Hire me: https://sadiqsalau.com.

Comprehensive guide on getting started with caching using service workers

Mon, 26 Jan 2026 10:28:13 +0000

Ever wondered why some sites loads slow when you first visit them, but after loading the full page when you get back the next time the site loads instantly fast, in today’s guide I will be walking you through the beauty of service worker by demonstrating how you can reduce you’re site loading time in the users browsing device the next time they visit you’re site.

Prerequisites
What is a service Worker
Caching
Basic caching implementation using Service worker
Starting Cache operations
Wrap Up
Final Thoughts

Prerequisites:

To follow along this guide, you must be familiar with the following JavaScript concept:

Promises
Events in JavaScript

What is a service Worker:

service workers is a JavaScript technique of running tasks in the background from the page main thread to help us developers, intercept request, cache resources from the client and even allows the app to run even offline, we will be focusing on how to cache resources/assets of the site in this article today.

Caching

caching is to save resources and assets of the site that takes too much time to load to the browser’s memory so the next time we try to access them we won’t need to re-download them from the server rather but on the browser's memory which is instantly first than getting them from the server.

Basic caching implementation using Service worker

I have a created a simple site of space tourism which contains information about different location on the space you can visit in the space and the details about it; is a frontend mentor challenge which you can find using this link if you want to try it out and follow along with.

this project is the perfect scenario to explain how we can cache the resources to reduce the load time on our site, and to be clear a site with a lot of visuals like images can be slow so I want to cache the home page to show how you can cache the site if you find site loading slowly and give you an insight on how service worker and caching works.

Looking at this image below, I am displaying all the time and size each file is taking to load the full homepage or index page

Image showing the network status when I first load the site on my device for the first time

You can see that I am fetching files with 264 KB in 266ms as the time it takes to load the whole landing page which means when I again visit the site it will take the same amount of time and size to load which is not ideal, again you find this information by going to the devtools→network tab

We start by registering a service worker in the app entry or main file mine is index.js

if("serviceWorker" in window.navigator){
window.navigator.serviceWorker.register('/sw.js').then(registeredSw => console.log(registeredSw).catch(err => console.log(err))
}

We start by checking if the current browser the app/site running on supports the service Worker, serviceWorker is a property of the navigator object of the windows object.

we use the register() on the serviceWorker to register a service worker in the browser, which takes in 2 arguments the first one is the destination where we’ve created a file which we will be writing in all our caching logic it is advised to put the service worker file in global directory in order to have access to all files

and the second argument is optional, the scope of files the service worker will track if you’ve saved it in a certain folder, it’s scope would be that given directory that why it advisable to put in the global directory.

The register() returns a Promise we use then to display the registered service worker and catch to catch any errors that may occur while registering the service worker

if it is successfully registered will be returned its instance in console which will look like this

The console shows the registered service worker

To view the created service worker, you will need to navigate to:

devtools
application and choose the Service workers pane on the left panel of the application section

service worker takes 3 phases it passes through to be installed which are:

installation: which have completed in the first step when we register a new service worker
Activation: activation of the service worker to start operating
wait: Still waiting for the service to be activating

Starting Cache operations:

In service Workers we use event driven approach to cache and fetch our resources and assets; in this section we will look each one of events needed to start service worker and cache your assets and resources and explain its part in caching resources/assets.

install event:

Exploration of the event

this is the first event to be fired, remember when we registered a new service worker that’s when the event is triggered

in this event we create a cache storage in the browser and add the resources that we will need to be cached in the cache.

Implementation of the event

to implement switch to the sw.js you have registered as you're service worker file and then implement the following snippet

const resourcesToCache = [
  "/",
  "/index.html",
  "src/JavaScript/index.js",
  "src/output.css",
];
const cacheName = "version-1";

self.addEventListener("install", (event) => {
  event.waitUntil(
    caches
      .open(cacheName)
      .then((cache) => {
        cache.addAll(resourcesToCache);
      })
      .catch((err) => console.log(err)),
  );
});

The above snippet declare resourcesToCache array to keep track of multiple resources and assets we want to cache and cacheName is the name that will use as the cache name.

event setup:

the self is service worker we have registered, essentially it is attaching event to itself that’s why they call it self
we attach an event of install as well as a callback function that will trigger when service worker is first registered on any device browser our site/app is running in.

Cache setup:

The waitUntil() on the install event ensures that the service worker is installed after the operation inside the waitUntil() has completed.
The caches object helps create, manage the browser’s cache storage.
We start by opening a new cache with open() which takes a string as an argument that will act as a cache name, we used the cacheName variable.
The open() returns a promise we chain then() to access the created cache.
The .addAll() to add multiple resources we would like to cache and finally a catch block to handle any errors that may occur in caching.

you’ve just cached you’re first assets/resources in your browser cache, to view the changes go to devtools(application→Service workers) and you should see you a button labeled as skipWaiting

Service worker panel in the browser

click on skipWaiting and then look on the left and then expand to Cache Storage tab you should see the name of you cache and when you click on it you will see resources cached insider there

created cache in the browser

and this should be it for setting up the cache for the site

NOTE: that to make testing easier it is better to enable the checkbox for Update on reload in service workers’ section; to test without needing to click on skipWaiting every single time you make changes to the page.

activate event:

Exploration of the event

this event fires every time there is a new change in a service worker file, its responsible is to activate a service worker.

Implementation of the event

self.addEventListener("activate", (event) => {
  console.log("Activated service worker");
});

we use the activate event to trigger activation of our service worker every time there is a change in service worker file, so the next time you change something from the sw.js the activate event will be triggered and in console you will see the message ‘Activated service worker’.

Fetch event:

Exploration of the event:

This event is fired every time you make a request to the server requesting resources/assets, and this is where we intercept the request and first check if the data we are trying to download from the server includes in our cache if we have it in our cache we can directly return them if not we can continue with the request.

Implementation of the event:

self.addEventListener("fetch", (event) => {
  event.respondWith(
    caches.match(event.request).then((response) => {
      return response || fetch(event.request);
    }),
  );
});

in above snippet we have:

attached fetch event to service worker that will trigger any time we make a request
we access the respondWith() of the fetch event, the respondWith() method will help intercept the request before it sends to the server requesting some assets/ resources
we access the request property on the event object.
inside the respondWith() we then use match() and pass our request to find the matching resources/assets in cache similar to the request we are sending to the server.
the caches.match() returns a promise, we attach then() to handle the resolve the promise and if it has found some assets/resources in our cache we then return them instantly if not we continue with the request.

to see the effects of this let’s compare the network of the first image when we had no service worker and now, when we have a service worker

Figure A: Before service worker implementation network report

network request report of site with not service worker and cache

Figure B: After service worker implementation network report

network request report of site with service worker and cache

With this you can see the difference, the file that we are getting from our service worker have a low load time compared to before the service worker and you can see they are taking up 0 size compared to before.

before we had a load time of 266 and after service worker, we have a load time of 124 which is less than half of the first load time we had before we cache.

we also had 264Kb of our resource size before we apply service worker but now, we only have 116Kb of resource size.

Wrap Up

In this guide we covered how to apply cache to static resources that may cause long load time which can be a bad user experience on the site,

Final Thoughts

Service workers are not only limited to caching resources they can be used for push notifications, enabling site accessibility in offline mode which is commonly known as PWA (Progress web app)

This guide helps you get started working with service worker, basic implementation and fundamental explanation of how caching works, in future articles I am planning to dive deep of how we can use service worker not only for caching but also for offline accessibility and background sync techniques.

PWA and Django #4: Installing a PWA as a native application

Sun, 23 Feb 2025 10:58:34 +0000

Welcome to the fourth entry on the Progressive Web Application with Django series. In this chapter we will learn how to install our webapp as a native application. Very useful and really easy.

Allowing native installation

With a small change to the source code, we can ask the user if they want to install our supercool webapp as a "native" app.

let beforeInstallPromptEvent = null;
let installed = false;

async function installPWA() {
   if (beforeInstallPromptEvent === null || installed) {
       return;
   }

   try {
       beforeInstallPromptEvent.prompt();

       const { outcome } = await beforeInstallPromptEvent.userChoice;
       if (outcome === 'accepted') {
           console.log("App install dialog accepted!");
           beforeInstallPromptEvent = null;
           installed = true;
       }

   } catch(e) {
       console.error(e);
   }
}

We can also listen to a couple of events to customize the responses and behavior of our webapp in every step of the process:

window.addEventListener('beforeinstallprompt', (e) => {
   beforeInstallPromptEvent = e;
});

window.addEventListener('appinstalled', () => {
   installed = true;
});

The user needs to fire the event, so an install button is a good place to call the new code:

When clicked, the user will see a browser dialog asking for the installation like this:

If accepted, the webapp will be registered on the operating system, with its own launcher icon:

Executing as a standalone app

Once installed, the web app will launch in its own window, providing a more integrated experience with styling based on the manifest (see previous chapters). Like this:

Note that you can customize the icon, the behavior of the webapp, colors, etc. in the PWA manifest. You can read more about this here:

About the list

Among the Python and Docker posts, I will also write about other related topics, like:

Software architecture
Programming environments
Linux operating system
Etc.

If you found some interesting technology, programming language or whatever, please, let me know! I'm always open to learning something new!

About the author

I'm Andrés, a full-stack software developer based in Palma, on a personal journey to improve my coding skills. I'm also a self-published fantasy writer with four published novels to my name. Feel free to ask me anything!

PWA and Django #3: Online and offline resources in a PWA - Developing Progressive Web Applications with Django

Wed, 27 Nov 2024 22:52:48 +0000

Welcome to the third entry on the Progressive Web Application with Django series. In this chapter, we'll learn how to cache resources for our PWA to be able to use them offline, without an active internet connection.

Implementing Offline Functionality

In the previous chapters we defined an small PWA application with every required part: the manifest and the ServiceWorker. We learned how to register the PWA and developed a very simple interface with some images:

Now we will learn how to store data in the PWA cache and how to choose from where to load every image: from the internet or from the local cache.

To store one or more resources on the PWA cache we use a function like this on the ServiceWorker:

const CACHE_NAME = "DJANGO_PWA_TEST"
const MAIN_URL = "https://laboratorio.alvarezperello.com/djangopwa/";

self.addEventListener("install", (event) => {
   console.info("*** PWA event *** install", event);
   event.waitUntil(activateApp());
});

self.addEventListener("activate", (event) => {
   console.info("*** PWA event *** activate", event);
   event.waitUntil(activateApp());
});

async function activateApp() {
   // When a service worker is initially registered, pages won't use it
   // until they next load. The claim() method causes those pages to be
   // controlled immediately.
   console.log('Claiming control...');
   clients.claim().then((ev) => {
       console.log('...claimed!', ev);
   })

   manageCache();
}

self.addEventListener("sync", (event) => {
   console.info("*** PWA event *** sync", event);
   manageCache();
});

async function manageCache() {
   const cache = await caches.open(CACHE_NAME);
   if (!cache) {
       console.error("Error storing resources in cache!");
       return;
   }

   storeResourceInCache(cache, MAIN_URL+"static/demo/img/snake1.jpg");
   //storeResourceInCache(cache, MAIN_URL+"static/demo/img/snake2.png");
   //storeResourceInCache(cache, MAIN_URL+"static/demo/img/snake3.png");
}

async function storeResourceInCache(cache, element) {
   console.log("Storing resource in cache: "+element);
   cache.add(element).then(event => {
       console.info("Resource stored successfully! "+element);
   }).catch(event => {
       console.error("Error storing resource! "+element, event);
   });
}

Now, when we execute our PWA, we can read the cache messages in the developer console:

Registering service worker...
...register completed!
The service worker is active!

serviceworker.js: Claiming control...
serviceworker.js: Resource already in cache! static/demo/img/snake1.jpg

Our PWA cache is working!

Choosing from where to load each resource

When the PWA loads a resource, calls the fetch event, like this:

self.addEventListener("fetch", async (event) => {
   console.info("*** PWA event *** fetch", event);
  
   let url = event.request.url.toString();
   console.info("The PWA is loading a resource from: "+url);
});

We are in control of the request now, and can choose from where return the requested resource: from cache or from internet.

Here is an example of how to check if we have a resource cached and return it from cache. And, if not cached, request it from the Internet instead.

self.addEventListener("fetch", async (event) => {
   let url = event.request.url.toString();
   if (!url.includes("static/demo/img/snake")) {
       return false;
   }

   const cache = await caches.open(CACHE_NAME);
   if (!cache) {
       console.error("Error loading resources from cache!");
       return false;
   }

   let fetchResponsePromise = await cache.match(url).then(async (cachedResponse) => {
       if (cachedResponse && cachedResponse.ok) {
           console.warn("Loading from cache: "+url);
           return cachedResponse;

       } else {
           console.error("Error! the cache does not have this url! "+url);
           console.error(cache.keys());

           remoteFetchResponsePromise = await fetch(event).then(async (networkResponse) => {
               console.warn("Loading from internet: "+url);
               return networkResponse;
           });

           return remoteFetchResponsePromise;
       }
   });


   return (await fetchResponsePromise);
});

We can read the developer console to know from where every image has been loaded, like this:

In the next chapter

We now have a PWA. Now we will learn how to make an installable PWA, that will show as a native application in the operating system. That's one of the greatest functionalities of the PWAs: we can use them to create "almost native" applications using Django.

See you in the next chapter!

About the list

Among the Python and Docker posts, I will also write about other related topics, like:

Software architecture
Programming environments
Linux operating system
Etc.

If you found some interesting technology, programming language or whatever, please, let me know! I'm always open to learning something new!

Coder Legion - Recent posts tagged pwa

Building a High-Speed School Marketplace: Why We Ditched Frameworks for Vanilla JS & PWA

1. The Reality of School Hardware

The Modern Framework Tax on Budget Devices

2. The Architecture: Under 50 KB, 60 FPS

3. Clean Patterns for Vanilla JS State & DOM

Pattern A: Modular State Store

Pattern B: High-Performance Event Delegation

4. Making It a True App: Progressive Web App (PWA)

Step 1: Web App Manifest (manifest.json)

Step 2: Custom "Install App" Topbar Trigger

Step 3: Cache-First Service Worker (sw.js)

5. The Performance Verdict

6. Conclusion

Project LifeOps (Part 5): 24/7 Zero-Cost Cloud Deployment ($0/month), Mobile Optimization, and PWA

🗺️ Complete LifeOps Series Roadmap

1. Production Cloud Topology ($0/month) 🌐☁️

1.1. Vite Bundle Optimization (vite.config.js)

2. Conquering Cold-Starts: Client-Side Resilience 🛡️⏱️

What happens behind the scenes?

3. Thumb-Accessible Mobile Ergonomics (Android & iOS) 📱👍

3.1. Fixed Bottom Navigation Bar (BottomNav.jsx)

3.2. Off-Canvas Sliding Drawer

3.3. Viewport-Anchored Modals with React.createPortal (Modal.jsx)

4. Progressive Web App (PWA) Transformation 📲✨

Key Benefits as an Installed PWA:

5. Retrospective: Lessons Learned from the LifeOps Blueprint 🎓💡

Series Conclusion & Complete Index 🚀

Complete Series Reference & Links 🔗

Caching Strategy for Offline Web Games: Install Group vs Lazy Group

The Three Requirements, Briefly

Split Your Assets Into Two Groups

Where Saves Actually Live

iOS Is Where the Plan Breaks

When Not To Bother

The Web needs a Save button.

The Idea

Why this matters

⚙️ What I’m working on

The goal

Links

Why I’m posting this

Final thought

Enhancement on service worker and caching

tags: video, youtube, devcommunity, javascript, cache, performance

Welcome to My Video Post

Final Thoughts

Bad UX every website/PWA overlooks — the mobile navigation

Comprehensive guide on getting started with caching using service workers

Table of Contents

Prerequisites:

What is a service Worker:

Caching

Basic caching implementation using Service worker

Starting Cache operations:

install event:

event setup:

Cache setup:

activate event:

Fetch event:

Wrap Up

Final Thoughts

PWA and Django #4: Installing a PWA as a native application

Allowing native installation

Executing as a standalone app

About the list

About the author

PWA and Django #3: Online and offline resources in a PWA - Developing Progressive Web Applications with Django

Implementing Offline Functionality

Choosing from where to load each resource

In the next chapter

About the list

About the author

Step 1: Web App Manifest (`manifest.json`)

Step 3: Cache-First Service Worker (`sw.js`)

1.1. Vite Bundle Optimization (`vite.config.js`)

3.1. Fixed Bottom Navigation Bar (`BottomNav.jsx`)

3.3. Viewport-Anchored Modals with `React.createPortal` (`Modal.jsx`)