DEV Community: no momo

When I Used AI to Write an HTML Game but Was Forced to Learn WebGPU Compute Shaders

no momo — Mon, 20 Jul 2026 07:47:58 +0000

Here’s the thing.

Last week I wanted to build a simple particle firework effect – the kind where you click the screen and hundreds of colorful particles explode, fall, and fade away. I’d written something similar with Canvas 2D before, so I knew the drill. But this time I decided to be lazy: I dumped the requirements into Claude and asked it to generate a complete HTML file on the spot.

The AI gave me working code in maybe fifteen seconds. Clean, well‑commented, even with gradient‑colored particles. I opened it in the browser, clicked a couple of times – 200 particles, smooth as butter. Then I bumped the count to 2,000 – the frame rate tanked to ~35 fps. At 5,000 particles, it became a slideshow at 12 fps.

That’s when it hit me: AI can write code that runs, but it won’t help you when it runs like crap.

So I went down a frustrating but incredibly rewarding debugging rabbit hole. And the thing that finally saved me wasn’t a smarter AI – it was WebGPU’s compute shaders.

Step 1: Finding the Real Bottleneck

The AI‑generated code looked like this (simplified):

const particles = [];

function init(count) {
  for (let i = 0; i < count; i++) {
    particles.push({
      x: canvas.width/2,
      y: canvas.height/2,
      vx: (Math.random() - 0.5) * 10,
      vy: (Math.random() - 0.5) * 10 - 5,
      life: 1.0,
      color: `hsl(${Math.random() * 60 + 20}, 100%, 60%)`
    });
  }
}

function update() {
  for (let p of particles) {
    p.x += p.vx;
    p.y += p.vy;
    p.vy += 0.08; // gravity
    p.life -= 0.01;
  }
}

function draw() {
  ctx.clearRect(0, 0, canvas.width, canvas.height);
  for (let p of particles) {
    ctx.globalAlpha = p.life;
    ctx.fillStyle = p.color;
    ctx.beginPath();
    ctx.arc(p.x, p.y, 4 * p.life, 0, Math.PI * 2);
    ctx.fill();
  }
}

The logic is straightforward: update loops over 5,000 particles on the CPU, recalculating positions and velocities; draw loops over them again, calling Canvas 2D APIs to draw circles.

So where’s the problem? 5,000 calls to beginPath + arc + fill is simply too heavy for Canvas 2D. Chrome’s Performance panel showed that the draw function consumed 78% of the frame time, most of it inside fill itself.

I tried all the usual optimizations:

Batch drawing? Not possible – every particle has its own color and alpha.
Use ImageData and manipulate pixels directly? Too much hassle, and I’d lose anti‑aliasing.
Reduce particle count? Then the firework wouldn’t look impressive enough. I needed a way to offload both the computation and the heavy drawing from the CPU to the GPU.

Step 2: What the Heck Is a WebGPU Compute Shader? (In Human Language)

WebGPU has two main use cases:

Rendering (Render Pass) – drawing triangles, textures, etc. – the WebGL replacement.
Computation (Compute Pass) – running massive parallel math on the GPU and reading the results back. A compute shader is basically a “mini‑program that runs on your graphics card.” It doesn’t care about drawing – it only crunches numbers. And its superpower is that it can perform the exact same operation on thousands of data elements simultaneously, with each element completely independent.

My 5,000 particles all follow the exact same update logic: position += velocity, velocity += gravity, life -= 0.01. That’s a perfect fit for parallelism.

So I rewrote the update function as a WebGPU compute shader, submitting it once per frame to let the GPU calculate all 5,000 new particle states in one go, then either reading the results back to the CPU (or directly piping them into the render pipeline).

Here’s the core part.

Step 3: A Minimal Working WebGPU Compute Shader

First, I defined a particle data structure (in WGSL, WebGPU’s shading language):

1.// Each particle occupies 16 bytes (16‑byte aligned)
2.struct Particle {
3.    pos: vec2<f32>,
4.    vel: vec2<f32>,
5.    life: f32,
6.    pad: f32,  // alignment padding
7.};

Then the compute shader entry point:

1.@group(0) @binding(0) var<storage, read_write> particles: array<Particle>;
2.
3.@compute @workgroup_size(64)
4.fn main(@builtin(global_invocation_id) id: vec3<u32>) {
5.    let index = id.x;
6.    if (index >= arrayLength(&particles)) { return; }
7.
8.    var p = particles[index];
9.
10.    // Physics update (identical to the JS version)
11.    p.pos = p.pos + p.vel;
12.    p.vel = p.vel + vec2<f32>(0.0, 0.08);
13.    p.life = p.life - 0.01;
14.
15.    // Bounce off walls (simple)
16.    if (p.pos.x < 0.0 || p.pos.x > 1.0) { p.vel.x = -p.vel.x; }
17.    if (p.pos.y < 0.0 || p.pos.y > 1.0) { p.vel.y = -p.vel.y; }
18.
19.    particles[index] = p;
20.}

This shader gets compiled, and each frame I submit it to the GPU – one submission updates all particles. @workgroup_size(64) means each workgroup processes 64 particles; the GPU automatically schedules a huge number of threads in parallel.

In JavaScript, the invocation looks like this:

const computePass = encoder.beginComputePass();
computePass.setPipeline(computePipeline);
computePass.setBindGroup(0, bindGroup);
computePass.dispatchWorkgroups(Math.ceil(particleCount / 64));
computePass.end();

And that’s it. The GPU does the heavy lifting in the background, and the CPU no longer has to loop over 5,000 items.

Step 4: The Real Pain Wasn’t Writing the Code

At this point you might think everything went smoothly – but the hardest part of the whole process wasn’t writing the WGSL. It was debugging.

WebGPU compute shaders have almost no debugging tools. You can’t console.log a particle’s position, and you can’t set breakpoints inside the shader. You’re left with:

Reading the result buffer back to the CPU and logging it with JavaScript – which kills performance.
Guessing by visual output – for example, if particles fly off‑screen, you suspect coordinate normalization issues or buffer alignment mistakes.
I spent a solid two hours stuck on one stupid problem: WGSL’s vec2 has 8‑byte alignment, and JavaScript’s Float32Array stores data sequentially – but I forgot to set the correct stride when creating the buffer. The particles’ positions were completely scrambled, as if they’d been randomly thrown outside the canvas.

The fix came from a brutally primitive approach: I wrote a small utility to copy the GPU buffer data back to the CPU, printed the first 10 particle positions, compared them with the JavaScript version, and that’s when I spotted the misalignment.

This experience taught me a hard lesson: WebGPU is powerful, but it’s incredibly unforgiving for beginners. AI won’t help you debug, and search engines won’t find your exact error – you just have to grit your teeth and read the spec.

Step 5: The Final Result (No Made‑Up Numbers, Just My Honest Impression)

On my MacBook Pro (M1 Pro):

5,000 particles with Canvas 2D – about 12–15 fps, and the page felt sluggish.
After switching to WebGPU compute shaders + only passing the final positions back to Canvas 2D for drawing – rock‑solid 60 fps, and CPU usage dropped from ~70% to ~8%. Note that I didn’t move the drawing to the GPU (that would require a full render pipeline) – I only moved the computation to the GPU and kept using Canvas 2D’s fillRect or arc for rendering. Even so, the improvement was night and day.

If I had also moved the rendering to WebGPU (using drawIndexed to draw thousands of triangles), it could theoretically reach thousands of frames per second – but the monitor only refreshes at 60 Hz, so there’s no point.

So How Much Did AI Actually Help?

Generating the initial code – yes, it was fast, but that was the “just works” version.
Writing the WGSL syntax – I asked it to produce a compute shader template, and it did – but once something broke, the AI had zero understanding of WebGPU’s binding‑group layout errors, because it lacks runtime context.
Solving the actual problem – I had to read the WebGPU spec three times and dig through Chrome’s about://gpu error logs myself. AI is a great junior dev – but when you hit low‑level API pitfalls, it’s as blind as you are.

What This Story Taught Me

What WebGPU truly changes isn’t “graphics quality” – it’s “computational capacity.” Even for 2D games, moving physics/particle logic to the GPU can boost performance several‑fold.
In 2026, HTML game development is no longer about “knowing Canvas” – it’s about “knowing how to program the GPU.” Game engines will eventually abstract this, but if you want to squeeze every last drop of performance, you have to understand compute shaders.
AI writes code impressively, but it won’t step into the pit for you. The real value of a developer lies precisely in being able to crawl out after falling in.

Finally, I Won’t Talk About WebXR

Because I know if I started rambling about how “WebXR brings the metaverse into the browser,” I’d be back in empty‑rhetoric territory.

So I’ll just leave you with one question:

Have you ever run into a “CPU can’t keep up” wall while building an HTML game? If so, what did you do about it?
If you’re also considering WebGPU, I can put together a small repository with the complete runnable code (WGSL + JS bindings) from this article and share it with you. Now that would be real meat. 😊

How PWA (Progressive Web Apps) are Changing the Mobile Gaming Landscape

no momo — Wed, 15 Jul 2026 03:12:52 +0000

For over a decade, mobile game distribution has been held in a tight duopoly. If you wanted to get your mobile game in front of users, you had to play by the rules of the Apple App Store or Google Play Store. This meant giving up a 30% cut of your revenue, navigating opaque and tedious review processes, and forcing users to undergo the high-friction process of searching, downloading, and installing massive binary packages.

However, a quiet revolution is taking place under the hood of modern mobile browsers. Progressive Web Apps (PWAs) are bridging the gap between web convenience and native app capabilities.

In this article, we’ll explore how PWAs are changing the mobile gaming landscape, the core APIs making it possible, and why the future of casual mobile gaming might live entirely outside the traditional App Store.

What is a PWA in the Context of Gaming?

At its core, a PWA is a website that uses modern web capabilities to deliver an app-like experience. For a game, this means it can be installed on a user’s home screen, run in full-screen mode without the browser UI, and—most importantly—work offline.

To turn a standard HTML5 game into a PWA, developers rely on three main pillars:

HTTPS: Secure delivery of assets.
Web App Manifest: A JSON file that defines how the game looks on the home screen (icons, orientation, display mode).
Service Workers: Scripts running in the background that handle asset caching and network requests.

The Core Tech: Service Workers & Offline Caching

The biggest historical knock against browser games was that they required a persistent internet connection. If a user entered a subway tunnel or lost cellular signal, the game would crash or fail to load.

Service Workers solve this by acting as a network proxy. They intercept requests and can serve cached assets instantly, enabling true offline gameplay.

Here is a simplified example of how a game’s Service Worker pre-caches assets during the installation phase, ensuring the game loads instantly even when offline:

// sw.js - Game Asset Service Worker
const CACHE_NAME = 'pixel-runner-v1';
const CRITICAL_ASSETS = [
    '/',
    '/index.html',
    '/css/game.css',
    '/js/game.js',
    '/assets/spritesheet.png',
    '/assets/jump_sound.mp3'
];

// Perform installation and cache critical assets
self.addEventListener('install', (event) => {
    event.waitUntil(
        caches.open(CACHE_NAME).then((cache) => {
            console.log('Opened cache, storing game assets...');
            return cache.addAll(CRITICAL_ASSETS);
        })
    );
});

// Intercept fetch requests and serve from cache if available
self.addEventListener('fetch', (event) => {
    event.respondWith(
        caches.match(event.request).then((response) => {
            // Cache hit - return response, otherwise fall back to network
            return response || fetch(event.request);
        })
    );
});

Combined with a Web App Manifest, your HTML5 game can be installed directly from Safari or Chrome onto the user’s home screen, hiding the URL bar and browser navigation buttons to provide a truly immersive, native feel.

Disruption of the App Store Monopolies

Beyond technical features, the rise of PWAs is a major strategic shift for indie game developers.

Bypassing the “App Store Tax”

Both Apple and Google charge developers up to 30% for in-app purchases (IAP) and subscriptions. By distributing your game as a PWA, you handle payments directly through web standards (like Stripe or PayPal), keeping 95% to 98% of your revenue.

Frictionless User Acquisition

With native apps, every step in the funnel loses users:
Clicking an Ad -> Loading App Store -> Clicking Install -> Waiting for Download -> Opening App.

With a PWA, the funnel is practically non-existent:
Clicking an Ad -> Game Loads Instantly.

Once the user is playing and enjoying the game, a subtle in-game banner can prompt them to “Add to Home Screen” to install it.

4. Hardware Integration: Closing the Gap

Modern browsers have granted the web platform access to device hardware that was once exclusive to native apps. Today, PWA games can leverage:

Pointer Lock & Gamepad APIs: Full keyboard/mouse lock and native game controller support (Xbox, PlayStation controllers) are supported natively in the browser.
Vibration API: Standard haptic feedback can be triggered on mobile devices to enhance gameplay feel during explosions or impacts.
Web Audio API: High-fidelity, low-latency audio synthesis and spatial audio can be processed directly inside the web browser.

The Challenges: What’s Still Missing?

While PWAs are revolutionary, they are not a silver bullet. iOS, in particular, has historically been slower to adopt progressive web standards compared to Android, occasionally limiting background push notifications or local storage limits for web applications.

Additionally, discoverability is a double-edged sword. While you are free from App Store gatekeepers, you also lose the organic search traffic that comes from being featured on the App Store front page. Developers must rely on SEO, social media, and word-of-mouth virality to drive users to their URLs.

Conclusion

Progressive Web Apps are democratizing game distribution. By transforming the web browser into an incredibly powerful runtime environment, PWAs allow indie developers to build highly optimized, instant-play, and offline-capable games that run globally on any device.

As app store models continue to face legal scrutiny and user fatigue grows, the web is reclaiming its place as the ultimate open gaming platform.

What do you think?

Have you tried packing your web games as PWAs? How do you handle local storage or asset updates? Let’s share some insights in the comments!

WebGL vs. Canvas 2D: Which One Should You Choose for Your Next Browser Game?

no momo — Tue, 14 Jul 2026 08:11:27 +0000

When you start building a new browser game, one of the very first technical decisions you must make is choosing your rendering context. Under the hood of the HTML5 element lies a fork in the road: do you call canvas.getContext('2d') or canvas.getContext('webgl')?

While it is tempting to think “newer and faster is always better,” the reality of game development is governed by constraints—time, complexity, bundle size, and target audience.

In this article, we’ll break down the architectural differences between Canvas 2D and WebGL, compare their performance, and help you decide which rendering path to take for your next web game project.

Canvas 2D: The Reliable, CPU-Bound Workhorse

The Canvas 2D API has been around for over a decade. It provides a simple, immediate-mode rendering interface where you draw shapes, text, and images directly using JavaScript.

// Quick Canvas 2D Setup
const canvas = document.getElementById('gameCanvas');
const ctx = canvas.getContext('2d');

// Drawing a simple player sprite
ctx.drawImage(playerSprite, x, y, width, height);

The Pros:

Low Barrier to Entry: The API is incredibly intuitive. If you want to draw a rectangle, write some text, or rotate an image, you can do it in one or two lines of code.
Built-in Text Rendering: Canvas 2D handles native system fonts and text layout gracefully, which is notoriously difficult to do in pure WebGL.
Tiny Footprint: You don’t need heavy libraries or boilerplate to get started. It’s perfect for vanilla JavaScript prototypes.
The Cons:

CPU Bottleneck: While modern browsers hardware-accelerate Canvas 2D where possible, it remains heavily dependent on CPU calculations and single-threaded JavaScript execution.
The Sprite Limit: If your game requires rendering more than a few hundred moving sprites, particle effects, or complex screen-wide filters simultaneously, you will likely see your frame rate drop below 60fps.

WebGL: The Hardware-Accelerated Beast

WebGL (Web Graphics Library) is a JavaScript API that interfaces directly with the user’s GPU (Graphics Processing Unit). It is a low-level API based on OpenGL ES, meaning it gives you immense control over the hardware but comes with extreme complexity.

// WebGL Initialization is significantly more verbose
const canvas = document.getElementById('gameCanvas');
const gl = canvas.getContext('webgl') || canvas.getContext('experimental-webgl');

if (!gl) {
    console.error('WebGL not supported by your browser');
}

The Pros:

GPU Acceleration: Calculations are offloaded to the GPU, which is parallel-processed. It can handle tens of thousands of sprites, complex shaders, and real-time lighting without breaking a sweat.
True 3D Capabilities: While Canvas 2D is strictly flat, WebGL allows you to build fully immersive 3D worlds, complete with depth buffers and camera matrices.
Custom Shaders: You can write GLSL (OpenGL Shading Language) programs to create stunning visual effects, such as water ripples, heat distortion, and dynamic shadows.
The Cons:

Extreme Complexity: Writing raw WebGL is notoriously difficult. Creating a simple colored triangle requires dozens of lines of boilerplate code to set up shaders, buffers, and program states.
Asset/Engine Overhead: To make WebGL manageable, most developers rely on third-party frameworks. While powerful, these engines add to your game’s initial bundle size and load times.

Performance & Architecture Comparison

To understand the difference, imagine drawing a forest of 5,000 trees:

The Modern Solution: Hybrid Engines

Thankfully, in 2026, web game developers rarely have to write raw WebGL. The modern ecosystem has given us powerful abstraction layers that offer the best of both worlds.

For 2D Games: Use PixiJS

If you are building a 2D game but want WebGL performance, PixiJS is the industry standard. It is a super-fast 2D WebGL renderer. Under the hood, it uses WebGL for blazing-fast performance but automatically falls back to Canvas 2D if WebGL is disabled or unsupported on the user’s older device.

For 3D Games: Use Three.js or Babylon.js

If you are taking the plunge into 3D, libraries like Three.js act as excellent wrappers, giving you access to lighting, materials, and cameras without requiring a degree in matrix mathematics.

Which One Should You Choose?

Choose Canvas 2D if:

You are building a casual game: Card games, board games, word puzzles (like Wordle), or turn-based strategy games do not require GPU power.
You want to minimize bundle size: If you are targeting instant-play platforms with strict file size limits (like Telegram or WeChat mini-programs), Canvas 2D’s lack of external dependencies is a massive advantage.
You are a beginner: If you are still learning game loops and physics, start here to avoid getting overwhelmed by graphics pipelines.
Choose WebGL if:

Your game is visually intensive: Fast-paced action platformers, bullet-hell shooters, or games with heavy particle systems (explosions, smoke, rain).
You are building a 3D game: From simple low-poly runners to complex shooters, 3D requires the GPU.
You want to use custom post-processing: If your game’s aesthetic relies on retro CRT screen shaders, bloom, or dynamic lighting.
What’s your stack?

Are you a raw Canvas purist, or do you always default to a WebGL framework? Let’s talk about your rendering choices and performance optimizations in the comments!

Why Browser Games Are Making a Comeback in 2026

no momo — Thu, 09 Jul 2026 07:29:17 +0000

If you were around during the golden era of the web, you probably remember Flash. It was the undisputed king of browser gaming, powering legendary portals like Newgrounds and Kongregate. When Flash met its official demise in 2020, many predicted that browser-based gaming would fade into obscurity, replaced entirely by native mobile apps and console ecosystems.

For a few years, that prediction seemed accurate. Early HTML5 Canvas games often suffered from performance bottlenecks, awkward mobile controls, and limited rendering capabilities.

However, fast forward to 2026, and we are witnessing a massive, quiet renaissance. Browser games are not just returning; they are thriving. But what changed under the hood, and why is HTML5 Canvas suddenly the darling of modern web developers again?

Beyond the 2D Context: The Technical Leap

In the early 2010s, developers trying to build complex games using the HTML5 Canvas API quickly hit a wall. Rendering thousands of sprites simultaneously on a 2D context resulted in severe frame drops, especially on mobile browsers.

Today, the technical landscape is entirely different. The evolution of the Canvas element isn’t just about the 2D rendering context; it is about how Canvas acts as the gateway to hardware-accelerated graphics.

WebAssembly (Wasm) + WebGL/WebGPU

The modern browser game stack rarely relies on pure JavaScript for heavy calculations. Instead, developers are using C++, Rust, or Go, compiling the game logic into WebAssembly, and rendering it through the Canvas using WebGL or the newly matured WebGPU standard.

By bypassing the JavaScript garbage collector and running close to native speed, browser games can now handle complex physics, real-time lighting, and 3D environments that were unimaginable a decade ago.

Here is a look at how modern web engines optimize the rendering loop using requestAnimationFrame to ensure smooth 60fps performance without draining the user’s battery:

const canvas = document.getElementById('gameCanvas');
const ctx = canvas.getContext('2d'); // or 'webgl' / 'webgpu'

let lastTime = 0;

function gameLoop(timestamp) {
    // Calculate delta time for frame-rate independent physics
    const deltaTime = timestamp - lastTime;
    lastTime = timestamp;

    updatePhysics(deltaTime);
    renderGraphics();

    // Request the next frame only when the browser is ready
    requestAnimationFrame(gameLoop);
}

// Start the loop
requestAnimationFrame(gameLoop);

The Battle Against “App Fatigue”

While technology paved the way, user behavior drove the comeback. In 2026, mobile users are suffering from what industry analysts call “App Fatigue.”

Downloading a new casual game today is a high-friction experience:

You must visit an App Store.
You must download 200MB+ of assets over mobile data.
You have to grant various privacy permissions.
Your device storage is constantly full.
Browser-based HTML5 games eliminate this entire pipeline. They offer instant play. You click a link on social media or in a chat app, and within three seconds, you are playing the game. No downloads, no installations, no storage warnings. For casual and mid-core gaming, convenience has triumphed over native performance.

The Rise of “Instant-Social” Ecosystems

Another major driver of the 2026 browser game comeback is the integration of web games into existing communication platforms.

Ecosystems like Discord Activities, Telegram Mini-Apps, and WeChat Games have built-in web views that rely entirely on HTML5 Canvas. Instead of leaving the chat app to play a game with friends, users can launch a fully functional multiplayer game inside their group chats.

For developers, this is a massive win. You don’t need to build a user acquisition funnel from scratch; you just deploy your game to the web, and the social platforms handle the virality. High-level frameworks like Phaser and PlayCanvas have adapted to this trend, offering lightweight, modular builds specifically optimized for these instant-play environments.

The Future: A Golden Age for Indie Web Devs

The democratization of web standards has made browser game development more accessible than ever. With modern build tools, hot module reloading, and robust deployment platforms, indie developers can build, test, and launch a web game globally in a matter of days.

We are no longer limited to basic puzzle games. The Canvas has evolved into a highly optimized viewport capable of delivering immersive, multiplayer, and cross-platform experiences directly to anyone with a web browser.

If you haven’t touched game development yet, there has never been a better time to open up an editor, grab a Canvas context, and start building. The web is ready.

What are your thoughts?

Are you currently developing web-based games, or do you still prefer native platforms? What frameworks are you using in 2026? Let’s discuss in the comments below!

Optimize Your Routine: The Practical Value of a planetary hours Calculator

no momo — Wed, 23 Apr 2025 08:38:27 +0000

Have you ever felt that certain times of the day seem better suited for specific activities? Ancient wisdom suggests this isn't mere coincidence. Welcome to the fascinating world of "planetary hours" – a system that divides the day (sunrise to sunset) and the night (sunset to sunrise) each into 12 segments, ruled sequentially by the seven classical planets (Sun, Moon, Mercury, Venus, Mars, Jupiter, Saturn).
Imagine handling communications and writing during a "Mercury Hour," engaging in social or artistic pursuits during a "Venus Hour," or tackling tasks requiring energy during a "Mars Hour." Sound complicated? Don't worry! If you're interested in this ancient timing wisdom, you should definitely try our planetary hours Calculator. It automatically calculates the precise start and end times for each planetary hours based on your location and the current date. No manual calculations needed – with just a click, you can discover which planetary energy is currently dominant, helping you better synchronize with the natural rhythms of the cosmos. Use our planetary hours Calculator now and start aligning your day with cosmic energies! Read also: https://planetaryhours.org