DEV Community

Cover image for I Built a Tiny Game for When Your App Takes Too Long to Load
Carlos Salamanca
Carlos Salamanca

Posted on

I Built a Tiny Game for When Your App Takes Too Long to Load

#react #javascript #opensource #webdev

Let's be honest.

Nobody likes staring at a loading spinner.

You wait.

You stare at the screen.

You wait some more.

And eventually you start wondering if the application is actually loading… or if it has simply given up on life. 😅

So I built BoredLoad.

Instead of making users stare at a spinner while waiting for your application to finish loading, BoredLoad gives them a tiny game to play.

🎮 What is BoredLoad?

BoredLoad is a lightweight, open-source loading component that turns long loading times into a small playable experience.

The idea is simple:

User starts waiting
       ↓
Loading...
       ↓
Loading takes longer than expected
       ↓
🎮 BoredLoad appears
       ↓
User plays
       ↓
Your content is ready
       ↓
Game disappears
Enter fullscreen mode Exit fullscreen mode

The goal isn't to hide slow performance.

It's simply to make the waiting experience a little less boring.

🚀 Try it

You can check out the project here:

👉 GitHub

And install it from npm:

npm install boredload
Enter fullscreen mode Exit fullscreen mode

Why did I build it?

I was thinking about something that happens constantly when using web applications:

loading screens are everywhere.

Dashboards load data.

Apps make API requests.

Authentication happens.

Files upload.

Pages transition.

Sometimes those operations take a few seconds.

And during those few seconds, we're usually given the same experience:

       ⏳
    Loading...
Enter fullscreen mode Exit fullscreen mode

I thought:

What if the loading screen actually gave you something to do?

That's where BoredLoad came from.

🧑‍💻 Built for developers

BoredLoad is designed to be easy to drop into an existing project.

It supports:

  • TypeScript
  • Vanilla JavaScript
  • React
  • Angular
  • Vite
  • Next.js
  • Touch interaction
  • Keyboard interaction
  • High scores
  • Seeded randomness
  • prefers-reduced-motion
  • Customizable loading thresholds

And the core has zero runtime dependencies.

The goal was to keep it small enough that adding a tiny game to a loading screen doesn't become a huge performance penalty itself.

⚛️ React example

For example, you can initialize BoredLoad when an operation starts:

import { BoredLoad } from "boredload";

const boredLoad = new BoredLoad({
  threshold: 1500,
});

boredLoad.start();

fetch("/api/data")
  .then((response) => response.json())
  .then((data) => {
    boredLoad.stop();

    // Render your data
  });
Enter fullscreen mode Exit fullscreen mode

The basic idea is that BoredLoad doesn't need to know what you're loading.

It simply needs to know:

"Are we still waiting?"

🕹️ Why a game?

There is actually something interesting about turning waiting into interaction.

A loading spinner is passive.

The user just watches.

A game is active.

Even a tiny interaction can change the perception of waiting.

Instead of:

"Why is this taking so long?"

It becomes:

"Can I beat my previous score?"

That's the little experiment behind BoredLoad.

🧩 Designed to be extensible

One of the things I wanted from the beginning was to avoid building a library that only supports one hardcoded experience.

The project has an extensible game architecture so new mini-games can be added over time.

The long-term idea is to have several small experiences:

BoredLoad
│
├── 🏃 Runner
├── 🐍 Snake
├── 🧠 Memory
├── 🚀 Space
└── 🧱 Breakout
Enter fullscreen mode Exit fullscreen mode

And potentially allow developers to create their own games.

Because if you're going to wait…

you might as well make it interesting.

📦 Open source

BoredLoad is completely open source and released under the MIT License.

The repository is available on GitHub:

👉 https://github.com/salamancacm/boredload

If you like the idea, I'd really appreciate a ⭐ on GitHub.

And if you find a bug, have an idea for a game, or want to contribute, pull requests and issues are welcome.

☕ Support the project

BoredLoad will remain free and open source.

If you enjoy the project, find it useful, or simply like the idea of making loading screens less boring, you can support its development on Ko-fi.

Even a small contribution helps me justify spending more time building weird little developer tools like this one. 😄

☕ Support BoredLoad on Ko-fi

What's next?

I'm planning to experiment with more mini-games, better customization, and additional integrations.

But for now, I just wanted to get the idea out there.

Maybe loading screens don't have to be boring.

Maybe we can make waiting a little more fun.

Try BoredLoad and let me know what you think.

👉 GitHub

👉 npm

⭐ If you like it, consider starring the repository.

And if you build something with it, I'd love to see it.

Top comments (2)

Collapse
 
jonrandy profile image
Jon Randy 🎖️ •

Nice, but in this day and age if the loading time of your app gives you enough time to play a game - then you have failed... very badly.

Collapse
 
salamancacm profile image
Carlos Salamanca •

Fair point, and I mostly agree — the #1 priority is always reducing actual load time, not decorating a slow one. This isn't meant to replace that.

It's for the waits that are real even after you've optimized: cold starts on serverless, processing a large file the user just uploaded, waiting on a third-party API, a bad connection on an old phone. The default threshold is 1.5s specifically so it never shows up on fast loads — it only kicks in once a wait is already happening.

It's also useful for longer background processes that have a web UI showing their progress — a deploy dashboard, a database migration status page in an admin panel, a background job (report generation, bulk import/export). Not "my app is slow," but "this specific operation genuinely takes a while and the user is staring at a screen either way.