What HTML5 Games Have Taught Me About JavaScript
5
minute read time
Most developers spend a lot of time focused on a single programming language. For me, that was JavaScript. One day, years ago, a thought entered my mind: "I should make a video game with this."
For most developers, their language of choice is not JavaScript. A language with enough inherent challenges and limitations as is, it is not designed to make video games, so I knew this would be at best a chore, and at worst a nightmare.
Over the past few years I have sporadically devoted my spare time to this pursuit, and in it I have learned much about JavaScript as a language, and the underlying browser technology it is built upon.
Building a Video Game with JavaScript
Modern Devices & Browsers have a Lot of RAM
Compared to the gaming consoles of the past, which had mere megabytes at their disposal, today even a cheap smartphone is likely going to have several gigabytes of RAM available. This means you don't necessarily have to limit your game to an 8-bit aesthetic...but you still might anyway because you think it looks cool....
Arithmetic is Computationally Cheap
While I first worried about running thousands of computations every second, it turns out that when it comes to arithmetic and logic, most browsers and devices can handle far more than you'd ever throw at them. This has been quite an impactful discovery for how I approach writing JavaScript on websites, since I need not fear complex computations in an environment where the load is relatively lighter than in a game.
Canvas Operations are Cheap
Almost every device today has a beefy graphics processing unit built into its motherboard; modern browsers can make use of these to quickly draw graphics to the screen when using the canvas tag. While there is certainly a learning curve when it comes to manipulating a canvas through JavaScript, the performance it offers makes it well worth the time.
DOM Operations are Expensive
While it may be tempting to move <div> tags around a backdrop (and perhaps even animate their backgrounds with css), too much of this will quickly bring your browser to a halt. This reinforces the point stated above: learning to manipulate a <canvas> is quite crucial to avoiding slowdowns.
Funny enough, this is the very same problem that has given rise to the Virtual DOM methodology used by frameworks like React and Vue, and it is the reason why jQuery as a UI framework tends to be less performant.
The Garbage Collector Lurks in the Background
Modern browsers are very good at managing the clutter you create with your JavaScript. In fact, they are so good at it, you likely don't even realize you are creating it! Anonymous functions and one-off variables within functions will remain assigned in the browser’s memory, even once they are done being used.
Periodically, your browser "collects the garbage," so to speak, to avoid an infinitely growing usage of RAM (i.e. a memory leak). For a normal website, this is not a concern, but for a game that may need to run several thousand functions per second, a garbage collection cycle can cause noticeable, and even game-breaking, delays. Code instead must be written to reuse as many variables as possible, and anonymous functions must be almost entirely avoided in order to ensure a smooth experience.
Conclusion
The biggest lesson I’ve learned from these projects is that modern browsers are quite resilient when tasked to run huge amounts of JavaScript functions, but this same resilience doesn’t apply to DOM manipulation. This goes to show that when it comes to building complex UIs and single page applications, there is a clear reason to avoid jQuery in favor of reactive frameworks like Vue, React & Svelte.
I've also learned how to really appreciate the canvas tag and look for opportunities to use them here at Atypic to deliver cutting edge highly performant 2D and 3D graphics.
