Vanilla JavaScript for Web Games: Faster Loads, Fewer Bugs

Mahesh built 40+ browser games in vanilla JavaScript, claiming under 50 KB file sizes. This approach demands deep technical solutions for physics stability and mobile input, prioritizing instant play.

Mahesh built GamelyByte, a collection of over 40 browser games, entirely in vanilla JavaScript. He claims this approach resulted in game sizes under 50 KB, significantly smaller than typical 5-20 MB Unity WebGL builds, enabling instant play on diverse devices. This decision shaped his technical playbook for overcoming common web game development hurdles while prioritizing user access.

Vanilla JavaScript for Performance

Mahesh reports choosing vanilla JavaScript over established game engines like Unity or Godot for three reasons: faster load times, instant gameplay, and complete control. He claims his largest game is under 50 KB, contrasting with typical Unity WebGL builds that can range from 5-20 MB. This size difference, he states, is critical for mobile users on slower connections, allowing games to load instantly without a dedicated loading screen. The founder also prioritized an "open a webpage, click, play" experience, avoiding installations or account creation. Building systems from scratch, he adds, provides full debugging transparency, eliminating engine "black boxes."

Sub-Stepped Collision for Physics Stability

Developing an 8-Ball Pool game exposed a critical physics challenge: tunneling. Fast-moving balls would pass through each other due to collision checks occurring only once per frame. Mahesh addressed this with sub-stepped collision detection. Instead of a single physics update per frame, he split each frame into multiple smaller updates. This change, he reports, eliminated tunneling in the pool game and improved the physics in other titles, including a bowling game and a physics-based merge game.

Document-Level Mobile Input Handling

A persistent bug on mobile devices involved virtual joysticks: players would drag, but character movement would stick to the previous direction. Mahesh discovered the issue stemmed from event attachment. Initially, movement events were tied only to the joystick element. When a player's finger moved outside this element, updates ceased. The solution involved attaching move and release events to the entire document. This adjustment, he claims, dramatically improved control reliability across all mobile games on GamelyByte.

Fixed Timestep for Mobile Physics

Mobile browsers frequently drop frames, which can desynchronize physics calculations if they are directly tied to rendering. This desynchronization causes objects to clip through environmental elements. Mahesh implemented a fixed-timestep physics loop using an accumulator to counter this. This method ensures simulation updates run at a consistent rate, independent of rendering performance, preventing physics glitches during frame rate fluctuations. He also clamps large frame gaps to prevent the "spiral of death" that can occur when a browser tab is backgrounded and reopened.

What We'd Change

The decision to build 40+ games in vanilla JavaScript, while demonstrating deep technical skill and yielding impressive file sizes, introduces significant trade-offs. For most founders, the development velocity offered by modern game engines or even more opinionated frameworks would outweigh the marginal load time gains. Engines provide robust tooling for asset management, animation, and cross-platform deployment, drastically reducing development time and complexity. Mahesh's approach necessitates rebuilding fundamental systems for each game or creating a custom framework, a resource-intensive task for a solo developer aiming for scale or rapid iteration.

Furthermore, while the technical solutions presented (sub-stepped collision, document-level input, fixed timestep) are sound engineering practices, they address problems that many engines solve out-of-the-box. A founder choosing vanilla JS must be prepared to invest heavily in solving foundational computer graphics and physics problems before focusing on game-specific logic and content. This requires a specific technical profile and a willingness to trade speed for granular control. The "biggest lesson" about small details, while true, is a general observation rather than a specific, actionable tactic for other founders beyond the technical solutions provided.

Mahesh's GamelyByte project demonstrates the technical feasibility of creating a large catalog of web games with minimal footprint using vanilla JavaScript. His commitment to core web technologies highlights a path for developers prioritizing extreme performance and direct control over engine abstractions. While demanding a high level of engineering expertise, this approach offers a distinct advantage in user acquisition by eliminating friction points like large downloads and lengthy loading screens, particularly relevant for casual mobile gaming.

The investor read

The rise of hyper-casual and instant-play games signals a market appetite for low-friction entertainment. Mahesh's approach, while technically intensive, addresses a core pain point: user drop-off due to load times and installation barriers. For investors, this highlights a potential niche where extreme optimization for web delivery could yield high user retention and virality, especially in emerging markets with slower internet. However, the high development cost per game in a vanilla JS environment means such projects are often lifestyle plays or require significant upfront technical investment to build a reusable framework. Investable products would need a clear monetization strategy beyond ad impressions, or demonstrate a path to significantly lower development costs per title.

Pull quote: “Instead of a single physics update per frame, he split each frame into multiple smaller updates.”