I Built 50 Browser Games Without React. Here's Why.

When I started building GamesMom, my goal wasn't to create another gaming website. I wanted to build a collection of browser games and educational games that children could play instantly without downloads, sign-ups, or apps.

Today, GamesMom includes more than 50 HTML5 games covering math, memory, typing, puzzles, word games, and classroom activities.

One decision surprised many developers.

I didn't use React.

Instead, I built every game using Astro and vanilla JavaScript.

After shipping dozens of games and testing them across desktops, tablets, and mobile devices, I'm convinced it was the right choice for this project.

This isn't an argument against React. It's simply why a lightweight approach made more sense for GamesMom.

Every Kilobyte Matters
One of my goals was simple: every game should load almost instantly.

Children don't wait for loading screens. Parents don't want to install apps. Teachers don't have time to troubleshoot slow websites in a classroom.

Adding a large JavaScript framework to relatively simple games would have increased bundle size and introduced complexity that wasn't necessary.

By keeping the JavaScript focused on the game itself, pages remained fast and responsive.

Frontend performance became a feature instead of an afterthought.

Most Games Don't Need a Complex State Manager
Many browser games have straightforward logic.

A player answers a question.

The score increases.

The timer counts down.

The next level loads.

Managing this flow with plain JavaScript turned out to be surprisingly simple. There was no need for global state libraries or deeply nested component trees.

The code was easier to understand and much easier to debug.

Astro Handles the Rest
Astro was a great fit because most pages are primarily content with a small amount of interactivity.

Navigation, layouts, metadata, and static pages are handled efficiently while each game only loads the JavaScript it actually needs.

That means visitors aren't downloading code they never use.

For a website with dozens of individual games, that makes a noticeable difference.

Simplicity Makes Maintenance Easier
As the number of games grew, maintainability became more important than writing clever code.

Reusable modules handled common functionality such as:

timers
score tracking
sound controls
dialogs
keyboard input
touch interactions

Each new game could reuse existing logic while remaining independent from the others.

When a bug appeared, fixing it was usually straightforward because there were fewer moving parts.

Accessibility Was Easier to Prioritize
Building educational games isn't only about gameplay.

Accessibility matters just as much.

I focused on:

keyboard navigation
readable typography
clear color contrast
large touch targets
responsive web design
consistent layouts

These improvements helped every player, not only users who rely on accessibility features.

Mobile Changed Everything
Most testing happened on phones and tablets.

That quickly changed how I designed games.

Buttons became larger.

Menus became simpler.

Animations became lighter.

Every interaction was optimized for touch before desktop.

This approach produced a better experience across every device.

Less Time Learning Framework APIs
Modern JavaScript has become incredibly capable.

For this project, spending weeks learning additional framework APIs offered little practical benefit.

Instead, I invested that time in:

improving gameplay
optimizing performance
refining user experience
adding new educational activities
fixing real user problems

The result was more value for players rather than more complexity in the codebase.

Would I Use React Again?
Absolutely.

React is an excellent choice for dashboards, SaaS platforms, collaborative applications, and products with highly dynamic interfaces.

But not every project requires that level of abstraction.

Sometimes the simplest solution really is the best one.

Choosing technology should always depend on the problem you're solving, not what's currently popular.

Building 50 browser games reinforced something I've believed for years.

Frameworks are tools, not requirements.

For this project, Astro and vanilla JavaScript delivered exactly what I needed: fast loading pages, maintainable code, excellent performance, and a great user experience across desktop and mobile devices.

The best technology choice isn't always the newest one.

It's the one that helps you build the right product with the least unnecessary complexity.

Have you deliberately chosen not to use a popular framework? I'd love to hear what influenced your decision and what you learned along the way.