DEV Community: Achmad Junaedi

Ditched React for our school marketplace app 👇 Bundle: <50KB. Load time on a $80 Android: 320ms. Story + architecture breakdown here #DEVCommunity #webdev

Achmad Junaedi — Wed, 09 Sep 2026 08:44:07 +0000

Achmad Junaedi

Sep 9

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

#javascript #pwa #webdev #programming

4 min read

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

Achmad Junaedi — Wed, 09 Sep 2026 08:08:41 +0000

In the modern web ecosystem, starting any web project without reaching for React, Next.js, Vue, or Svelte 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:

Key Decision: We threw out all third-party frontend frameworks and built the entire user interface in pure Vanilla JavaScript, modern modular CSS, and Progressive Web App (PWA) standards.

Why? Because when your primary user base consists of students using second-hand, $80 entry-level Android phones connected to crowded school Wi-Fi, developer convenience cannot come at the expense of end-user performance.

1. The Reality of School Hardware and Campus Networks

Before writing a single line of code, we profiled our target environment in real classroom conditions:

• Hardware Constraints: Approximately 65% of students carry entry-level devices with 2GB to 3GB of RAM, powered by aging Quad-core MediaTek chips or Snapdragon 400-series processors.

• Network Bottlenecks: During recess spikes, hundreds of students connect to the campus Wi-Fi simultaneously, dropping effective bandwidth to congested 2G/3G speeds.

• The 15-Minute Recess Rush: Students have exactly 15 minutes between bells to browse the canteen menu, order food, and pick it up. A 4-second loading screen means they literally don't get lunch.

A barebones Next.js or React e-commerce template typically ships 250 KB to 500 KB of minified JavaScript. On a modern M3 MacBook or iPhone 16, parsing 300 KB of JS takes 15 milliseconds. On a budget Android phone, it takes 1,200 to 2,500 milliseconds. This latency manifests as Hydration Lag (Total Blocking Time): the page looks rendered, but tapping the 'Order' button does nothing because the main JavaScript thread is frozen during hydration.

2. The Architecture: Under 50 KB and 60 FPS

By returning to web fundamentals, we achieved blistering performance:
• Total Initial Payload: < 48 KB (gzipped JS + CSS bundle).
• First Contentful Paint (FCP): ~320 ms on real school 4G.
• Time to Interactive (TTI): Instantaneous, zero hydration lag.

The project structure remains clean, modular, and maintainable:

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

3. Clean Patterns for Vanilla JS State & DOM

Building with Vanilla JS doesn't mean writing spaghetti code. We used modern ES6+ patterns, isolated state stores, and memory-efficient Event Delegation.

Pattern A: Modular State Store Without Third-Party Libraries

● ● ●   JAVASCRIPT (SKRIPMART.JS)
// A lightweight, reactive-free state store (skripmart.js)
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: Memory-Efficient Event Delegation
Instead of binding individual click listeners to hundreds of menu cards (which bloats browser memory on low-end phones), we attach a single event listener to the parent container:

● ● ●   JAVASCRIPT (SKRIPMART.JS)
// Only 1 single event listener for the entire product catalog grid
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 native CSS micro-animation without any external animation library
    btn.classList.add('scale-bounce');
    setTimeout(() => btn.classList.remove('scale-bounce'), 250);
});

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

Most students won't download a canteen app from Google Play or Apple App Store due to limited phone storage. With PWA standards, the app installs instantly to their home screen directly from the browser in 1 tap.

a. Custom 'Install App' Topbar Trigger
We intercept the native beforeinstallprompt event to present a prominent, branded install button in the top navigation:

● ● ●   JAVASCRIPT (PWA INSTALL)
let deferredPrompt;
const installBtn = document.getElementById('installAppBtn');

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

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';
});

b. Cache-First Service Worker (sw.js)
To ensure the catalog opens instantly even when students walk through hallways with dead Wi-Fi zones, the Service Worker caches all core app shell assets:

● ● ●   JAVASCRIPT SERVICE WORKER (SW.JS)
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) => {
    // Forward Supabase database REST & RPC calls directly to network
    if (e.request.url.includes('/rest/v1/') || e.request.url.includes('/rpc/')) {
        return;
    }
    // Serve static assets directly from local cache
    e.respondWith(
        caches.match(e.request).then(cached => cached || fetch(e.request))
    );
});

5. The Performance Verdict: Real-World Lighthouse Audit

We executed Lighthouse audits on an emulated low-end Moto G4 device throttled to slow 3G network conditions:

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 students who open Inspect Element to try altering menu prices from $1.50 to $0.01?

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

I Stopped Using Gemini 3.1 Pro for Agentic Coding — Why I Moved to Gemini 3.7 Flash High Mode

Achmad Junaedi — Tue, 01 Sep 2026 11:32:50 +0000

I landed my first Point of Sale (POS) SaaS client project and built it inside Google Antigravity, trusting Gemini 3.1 Pro for all agentic coding. Bad move. Midway through, severe bugs hit—fixing sales inputs completely broke my dashboard analytics.

Frustrated, I switched to the GPT stack (Codex, GPT-5.5, GPT-5.6 Sol). But that brought a new headache: token quotas drained in minutes and API bills went through the roof.

The breakthrough? Community stats on Agent Arena showed Flash models beating 3.1 Pro in agentic tasks. Desperate, I tested Gemini 3.6 Flash and it was surprisingly solid.

1. The Beginning: Falling for 3.1 Pro Hype
When Google dropped Gemini 3.1 Pro in February 2026, tech Twitter hyped its ARC-AGI-2 benchmark scores as the ultimate problem solver.
Early on, 3.1 Pro handled high-level whiteboard concepts fine:
• System Architecture: Mapping schemas and ERDs.
• Business Logic: Outlining business logic flows.
• Edge Cases: Spotting potential edge cases.

2. Client Pressure & Regression Hell
I secured a major deal with a client who paid 50% upfront. Expectations were high, and that's where things went downhill.
A retail POS requires tight database relations: transactions, inventory sync, multi-outlet stock, and live dashboard revenue summaries. When I instructed Gemini 3.1 Pro in Antigravity to build the sales input module:

Fatal Regressions: The sales input worked, but the dashboard suddenly went crazy. The model rewrote existing SQL aggregation queries without respecting cross-module dependencies.
Lost Query Logic: It repeatedly forgot critical database filter conditions (like tenant IDs or soft-delete flags), causing messy data anomalies.
Deadline Panic: The client wanted deliverables per contract, and I was sweating because the code kept breaking.

3. Fleeing to GPT & The Token Trap
Panicking about deadlines, I switched to the OpenAI ecosystem:
• Codex / GPT-5.5 (Medium): Daily coding assistant.
• GPT-5.5 (High Reasoning): Complex SQL logic.
• GPT-5.6 Sol: Heavy artillery for deep debugging.
While reasoning was solid, a new problem popped up: tokens burned out insanely fast.

Running heavy models like GPT-5.6 Sol and 5.5 High across autonomous agentic loops burned quotas in no time. I needed a workhorse that didn't drain my wallet.

4. Community Outrage: It Wasn't Just Me
My frustration wasn't unique. On the Google AI Developers Forum , a thread titled "Unacceptable Antigravity Quotas for Gemini 3.1 Pro – Workflow Completely Blocked!" had racked up roughly 60 upvotes and 19 replies within days.

One developer, Hauke_Walden, summed up the core complaint: "...it is totally unacceptable that the quota usage is so intransparent, and even worse, the totally random 'refresh' policy... It's like a car that sometimes works, sometimes it doesn't. That's ok for a hobbyist and his vintage car, but not for a cab driver."

Another, madnz-08, described a specific bug: "Yesterday my quota dropped from 60% to 0% without any prompt, and the worst part was seeing the reset time set to 50+ hours."

A third, MrTos, put it bluntly: "It is unacceptable to be stuck at 10 prompts on Gemini 3.1."

The pattern in the thread was consistent: vanishing quotas, lockout timers reported as high as 133–167 hours, and reports of paying developers getting locked out mid-project.

5. The Pivot: Testing Gemini 3.6 Flash
Hunting for a leaner alternative, I saw rankings on Agent Arena praising Flash models for agentic tool use.
Curious, I tested Gemini 3.6 Flash in Antigravity:
• Blazing Speed: Instant feedback loops without lag.
• Quota Sanity: No panic about hitting rate limits mid-session.
• Sane Diffs: It stayed in its lane without aggressively trashing outside files.
It proved lightweight models were getting unwarranted hate.

6. August: Brother's WhatsApp Tip & The Jump to 3.7 Flash
In August, my younger brother sent me a WhatsApp message: "Bro, Google just dropped Gemini 3.7 Flash."
As reported by VentureBeat, Google built 3.7 Flash specifically for coding and agentic loops, with a 50% introductory discount ($0.75 / 1M input, $3.75 / 1M output).
Having seen good results with 3.6 Flash, I wanted to see if Google really pulled off deep reasoning on a Flash model without killing speed.

7. The Proof: Gemini 3.7 Flash (High Mode) in Antigravity
I opened Antigravity, picked Gemini 3.7 Flash, and enabled Thinking Mode: High. The leap in quality was immediate:

Blazing Fast & Token-Efficient Inference stayed snappy even with extended thinking on. In fast agent loops, code fixes felt instant without distracting pauses, while token burn remained low.
Complex Database Queries Handled Smoothly Any fear that Flash would choke on multi-table queries disappeared. It surgically edited the sales module without touching outside files, kept dashboard queries in sync, and maintained schema rules without destructive side effects.
Cleaner Code & Only Minor Tweaks There were a few minor formatting adjustments, but the code structure was clean. Those small tweaks took one quick prompt to fix—not fatal structural bugs. I delivered the client project right on time.

Conclusion
This client project taught me a valuable lesson: in daily agentic coding, diff discipline, fast inference, and token efficiency matter way more than benchmark scores on paper.
From Agent Arena tests with 3.6 Flash to the leap in Gemini 3.7 Flash, it proved Flash models with thinking mode aren't just "cheap alternatives"—they are solid workhorses that handle heavy code cleanly and safely.
If you're building a SaaS and stuck between regression bugs or sky-high token bills, give Gemini 3.7 Flash a run in Google Antigravity.

Written by Achmad Junaedi — Founder of setvy.id & Vocational Educator at SMKN 10 Surabaya, Indonesia.