JS/CSS game development often is associated with web apps. This thread will cover my recent and some long term challenges building a game with CSS/JS in the web browser.

The modern day approach to game development uses a game engine like Unity to deploy games to be accessible in the web browser. This was something I knew back before I began development of my recent game, years ago. I didn't understand the consequences (or challenges, if you're an optimist!) of building a game inside a web-app.

My rationale to choose pure JS/CSS included two pieces: a) my perceived need to get more proficient with front end development b) user clarity of game events

Animations

One big hurdle I had to overcome and still deal with today is animations. The game I developed has many animated elements using JQuery. (a) The main issue with JQuery animations is that the web browsers will throttle or even halt animations when the user minimizes the window. Many developers suggest using set interval to guarantee an animation continues its trajectory and reaches the desired position.

SetInterval naturally would be the solution to the problem, however my animations do not persist longer than 3-4 seconds. For the time being, I am handling the issue by using SetTimeout to ensure the element made it to its position or removal upon completion depending on the case.

(b) If your game advances without user input, animations will need to occur in order and keep up with the state of the game loop. Decide whether or not animations in the queue can be skipped or if they must all be shown the user. In my case, the animations were important to the user because skipping an animation could result in the user being dissatisfied by lack of awareness in the game. Since the issue identified in my first point exist, the current animation displayed may be out of time or completely not valid anymore.

Caching Assets

Caching assets can become a behemoth of an effort to manage if you wait to do Dev Ops later, when your game gets big. From my experience, it is best to preload all of the assets before the user begins playing the game.

Preloading assets early guarantees the user can access them later. It is good practice to provide 'alt' text on every image. But is the user really going to stay on the game, let alone the site, if assets are not loading correctly? The assets may not load correctly because the content deliver network (CDN) suddenly requires human verification to fetch the asset or the web server itself could be down to fetch an asset not yet cached by the CDN.

On another note about cache, make sure to get your web server cache considerations right early. Otherwise, it could be uncomfortable for your users to clear the cache themselves to get the latest updates.

Scaling UI and Assets

Modern games have been coded with standard layouts and it may do the job well. My game however, with it's complexity, could not be coded without using absolute positioning/sizing for a lot of elements. The playing cards and chips animate across the table to certain positions. Relative layouts are king for scaling UI.

I spent a year building my game before I realized that the scaling operation wasn't as easy as setting something like: "Zoom : 2;" or "Scale : 2"; in CSS. Using that I found animations and the user clickable locations were wildly offset in position from the displayed content, with no rhyme or reason.

I overcame this problem by capturing the user's resolution profile at page load and using it everywhere the code had to set position and dimensions of an element. CSS is also able to identify the resolution profile (because the profile is a class name added by my JS) to produce dimensions and positions.

Internet Browser Limitations

Internet browsers do not always handle CSS statements the same and support content in the same way. This is something I thought we would not still be dealing with in 2026. It is what it is, as they say. To overcome this, you have to test your web app/game in multiple browsers.

Conclusion

In conclusion, JS paired with CSS is not the modern approach to game development. I don't think it is natural to assume that this would be the correct approach, but at least it is now documented why it's not a great idea. I am going to continue down this road because I've already overcome or live with these negatives on the regular.