I Thought I Understood SPAs. A Blank Screen Proved Me Wrong.

Jibola Timothy Kolawole — Sat, 23 May 2026 10:29:00 +0000

I had AI help me structure the router. It looked clean. The logic flowed. I shipped it.

Then I opened the browser and saw a blank white page.

No error. No warning. Just silence. 🦗

🧱 The Blank Screen Problem

Here's what the router was supposed to do — and what it was actually doing.

The architecture was simple enough on paper: index.html holds the landing page. A separate #app-container div catches everything else — auth screens, dashboards. The router listens to the URL and decides what to render where.

async _render(path) {
  // ...identify path...
  // ...check auth...
  // ...show loading...
  // ...render view...
}

Logical. Clean. Broken in four different ways simultaneously. 🙃

🐛 Bug #1: The `export` That Silently Killed a Module

Inside dashCustomer.js, the entire dashboard view was wrapped in a DOMContentLoaded callback:

document.addEventListener('DOMContentLoaded', () => {
  const container = document.getElementById('app');

  export const CustomerDashView = {   // 💀 fatal syntax error
    render(container) {
      // 400+ lines of dashboard code
    }
  };
});

export must be at the top level of a module. You cannot export from inside a function or callback. This is a hard syntax rule in ES modules.

The browser's response to this? It silently refuses to parse the file. 🤐 No module loads. The router tries to import CustomerDashView, gets undefined, tries to call undefined.render(), and throws an error so far downstream from the real cause that you spend twenty minutes looking at the wrong file.

The fix was just two lines — remove the wrapper ✂️:

// ✅ No DOMContentLoaded. No wrapper. Just this:
export const CustomerDashView = {
  render(container) {
    // dashboard code
  }
};

🐛 Bug #2: Calling `appendChild` on a Plain Object

With the syntax error fixed, something rendered. Then it immediately crashed with:

❌ TypeError: Failed to execute 'appendChild' on 'Element': 
   parameter 1 is not of type 'Node'.

The router was doing this:

const view = await routeLoader();
appContainer.appendChild(view);   // ❌ wrong assumption

The view files don't return DOM nodes. They return plain objects with a .render() method:

export const CustomerDashView = {
  render(container) {
    container.innerHTML = `...`;
    // attach logic, load data, etc.
  }
};

appendChild expects a DOM element. 🧩 Passing it a plain JavaScript object throws immediately. The fix required understanding what kind of thing the view actually was:

const view = await routeLoader();
if (view && typeof view.render === 'function') {
  view.render(appContainer);       // ✅ for object-style views
} else if (view instanceof Node) {
  appContainer.appendChild(view);  // ✅ for views that return DOM nodes
}

🐛 Bug #3: The Container That Was Always Hidden

After both fixes, the router was loading the view. The data was fetching. The JavaScript was running. The page was still blank. 😶

The #app-container in index.html had this:

<div id="app-container" style="display:none"></div>

The router was rendering an entire working dashboard into an invisible box. 📦 Nobody had written the line to show it.

No error. No warning. The app was working perfectly, invisibly. 👻

// 🤦 This single line was simply missing:
if (appContainer) appContainer.style.display = '';

🐛 Bug #4: A Variable Used Before It Was Declared

While adding the visibility fix, I introduced a new one:

// 🔝 Early in the function:
if (appContainer) appContainer.style.display = '';  // 💥 ReferenceError

// ...15 lines of other logic...

// 👇 Only declared down here:
const appContainer = document.getElementById('app-container');

const doesn't hoist. ⚠️ I'd moved the visibility toggle above the declaration during refactoring and didn't notice. The variable was being referenced before it existed.

The fix was simply to move the const appContainer declaration to the top of the function — before the first point it was used. 🔼

💬 The Moment That Actually Mattered

By the time I'd found and fixed these bugs, it was late. I was frustrated. I messaged someone and said something like: "I've been using AI to write this code and honestly I understand most of it but maybe not all of it." 😬

The response stopped me:

"AI writes code you don't understand. It works. Then it breaks. You don't know why. You ask AI to fix it. It breaks something else. You're stuck in a loop with no exit — which is exactly what happened with your routing bug tonight." 🔁

That was accurate. That's exactly what had happened.

But then came the part I actually needed to hear 👇:

"A basic SPA is actually just 3 ideas:
📄 One HTML file with a div that acts as a container.
🔄 JavaScript that listens to the URL and swaps content into that container.
🔗 A way to change the URL without reloading the page using history.pushState.
That's it. Everything else is just complexity on top of those 3 things."

I'd been working with a router that had auth guards, lazy loading, body class management, header visibility toggling, loading spinners, view mounting strategies. And I hadn't been able to debug it confidently because I'd lost sight of what a router fundamentally is. 🗺️

Here it is in its purest form 👇:

<div id="app"></div>

<script>
  function render(path) {
    const app = document.getElementById('app');
    if (path === '/')
      app.innerHTML = '<h1>Home</h1>';
    else if (path === '/about')
      app.innerHTML = '<h1>About</h1>';
    else
      app.innerHTML = '<h1>Not Found</h1>';
  }

  document.querySelectorAll('a').forEach(a => {
    a.addEventListener('click', e => {
      e.preventDefault();
      history.pushState({}, '', a.href);
      render(location.pathname);
    });
  });

  window.addEventListener('popstate', () => render(location.pathname));

  render(location.pathname); // 🚀 boot
</script>

That's the whole contract. 📜 Every SPA framework, every custom router, every react-router or vue-router you've ever used is this — with abstractions layered on top.

Once I saw that, the bugs from earlier became obvious in a different way 💡:

🔴 The export error broke the module so no view could load
🔴 The appendChild error meant the router didn't understand what a "view" was
🔴 The display:none bug meant the container never became part of the visible page
🔴 The hoisting bug meant the container reference didn't exist when the code needed it

Each bug was a violation of one of those three core ideas. And I couldn't see that while I was staring at 200 lines of code I hadn't fully internalized. 😔

🎯 The Honest Takeaway

I'm not writing this to tell you to stop using AI tools. I use them constantly. They're genuinely useful for scaffolding, for boilerplate, for getting a working first version fast. 🤖

But there's a specific failure mode that's easy to fall into: you ask AI to write something, it works, you move on, and you never actually learn what it does. Then when it breaks — and it will break — you're standing in front of a blank screen with no map. 🗺️❌

The process that actually works, the one I ended up doing last night whether I intended to or not:

🤖 Let AI write the first version
👀 Read every line. Ask "what does this do?"
🙋 Ask AI to explain anything you don't recognise
🗑️ Delete a piece and try to rewrite it yourself
💥 Break something deliberately and fix it yourself

Step 5 is the one that sticks. 📌 I found four bugs last night under pressure, in code I was uncertain about, and understood every fix by the time I was done. That understanding is mine now. It didn't come from reading documentation or watching a tutorial.

It came from the blank screen. 🖥️

⚙️ What I'm Doing Differently

Every time I use a significant piece of code I didn't write from scratch, I now ask myself one question before moving on:

💭 "Can I explain what breaks if I delete this line?"

If the answer is no, that's a gap. Not a crisis — gaps are fine and normal. 🙂 But I write it down. I come back to it. I poke at it until I can answer the question.

The router works now. ✅ The dashboards load. ✅ But more importantly, I know exactly why — and I know what I'd look at first if the screen went blank again.

🚚 I'm building OffScape Logistics, a delivery platform for businesses in Lagos and Ibadan with real-time GPS tracking, escrow payments, and role-based dashboards. If you're building something similar or just want to talk about SPA architecture, I'm on Twitter Creative @astra9cc

JavaScript, #WebDevelopment, #SPA, #Debugging, #LearningtoCode, #BuildinginPublic

I've audited dozens of estate agency websites. The same 5 problems show up every single time.

Jibola Timothy Kolawole — Sat, 23 May 2026 10:13:52 +0000

Estate agency websites sit in an interesting category from a technical standpoint — high commercial intent traffic, predominantly mobile, long decision cycles, and almost universally under-optimised.
After running manual performance and conversion audits on a significant number of them, the same five issues appear with remarkable consistency. This isn't a marketing post — it's a technical pattern recognition writeup.

LCP in the 6–10 second range on mobile Almost always the same root causes:

Hero images uncompressed, no WebP, no srcset

No fetchpriority="high" on the LCP image element

Render-blocking third-party scripts (GTM, chat widgets, CRM trackers) firing before first paint

Fonts loading without font-display: swap

No preconnect hints for external origins

The fix that moves the needle most consistently: compress the hero image, set fetchpriority="high", defer non-critical scripts.
One client went from LCP 8.1s → 2.3s on mobile just from image optimisation and script deferral alone.

No meaningful content above the fold on mobile This is partly a UX problem and partly a technical one. The pattern: full-viewport hero image loads, content reflows underneath it, by which point the user has already made their decision about the page. The CLS implication is real too — images without explicit width and height attributes cause layout shift as they load, directly impacting Core Web Vitals scores.

`html<!-- What we find -->
<img src="hero.jpg" />

<!-- What it should be -->
<img 
  src="hero.webp" 
  width="1200" 
  height="600" 
  fetchpriority="high"
  alt="Property search"
/>`

Form friction — too many fields, no progressive disclosure The technical pattern here is almost always a legacy CRM integration that dumps every available field into the form by default. What actually converts:

Step 1: Name + Email (or phone) — capture the lead
Step 2: Qualification questions — only shown after step 1

Multi-step forms with progressive disclosure consistently outperform single long forms. Libraries like React Hook Form or even a basic vanilla JS step controller handle this cleanly.

No micro-conversion infrastructure Most estate agency sites have exactly one conversion point: the contact form. There's no:

Property alert signup (email capture with listing criteria)
Instant valuation widget (high-intent lead capture)
Area guide download (top-of-funnel email collection)
Exit intent capture

From a technical standpoint, none of these are complex to build. Property alerts can be as simple as a Mailchimp-integrated form with conditional tagging. But they're almost universally absent.

Mobile performance debt Beyond raw load times, the structural mobile issues we see consistently:

Touch targets under 44px (Google's recommended minimum)

Fixed desktop navigation not adapted for thumb zones

Images sized for desktop served to mobile (no responsive images / srcset)

No lazy loading on below-fold images

CSS not split — full desktop stylesheet served to mobile

A real device audit almost always reveals UX debt that emulators miss. Lighthouse mobile emulation is useful but not a substitute.

The aggregate impact
Across the audits we've run, fixing the above — without rebuilding the site — consistently moves monthly enquiry volume by 30–70%.
**
The technical lift is rarely dramatic. It's almost always:

- Image pipeline cleanup
- Script load order optimisation
- Form restructuring
- Basic micro-conversion tooling

If you work on real estate sites or service business sites generally — curious what patterns you're seeing. Anything consistently missing from this list?

Built with: Lighthouse, PageSpeed Insights, GA4, manual device testing
Tags: #WebPerf #CoreWebVitals #RealEstate #ConversionOptimisation #agelessbusinessteam

DEV Community: Jibola Timothy Kolawole