As an avid gamer, I stumbled upon the speedrunning scene around 2017—it’s all about completing a video game (or parts of it) as quickly as possible by exploiting glitches.
"Glitches? That's nothing more than a programming error!"
As a developer, I thought, “Glitches? That’s nothing more than a programming error!” And that’s when I started to view speedruns not just through the eyes of a player, but through the eyes of a developer. One of my insights: game development and front-end development share certain concepts and ideas—enough so that there are front-end JavaScript frameworks that can be used to develop video games.
Both development environments have stores for data storage and use events to process user input, and both have similar pitfalls when a user triggers certain events at the wrong time. In both, the store should be centrally managed and able to assume only defined, clear states.
As an example of a glitch that can be replicated in front-end applications, there is one of the most famous glitches of all time—the Backwards Longjump (BLJ for short) from Super Mario 64.
In this game, the speed Mario can build up is capped—but when moving backward, he can go as fast as you want if you press the correct buttons on the controller. This allows you to go so fast that Mario can cheat his way backward through an invisible wall that’s supposed to keep sending him back to the top of a staircase.
Due to the speed, you’re in front of the wall in one frame and behind it in the next; the collision itself never actually occurs. Examples like this serve as a helpful reminder to me, as a programmer, that I shouldn’t take shortcuts when validating user input, nor should I assume that the user will only send data that I expect—theoretically, any value could be sent.
Features You Add "Just Quickly"
Other common problems in development often stem from features that are added “just quickly”—features that are well-intentioned but may not be 100% necessary or meet the usual quality standards. It’s not uncommon for this new code to have side effects that the developer didn’t anticipate. I see the game *The Legend of Zelda: Link’s Awakening* as a prime example of this—it’s full of such features. Originally, the game was intended to be a “demake” of a *Zelda* game on the Super Nintendo, but the developers implemented a few features to set it apart from the original.
One of these features is the Bomb Arrow—if you use a bomb within a few frames after firing an arrow, the bomb attaches to the arrow and explodes on contact. The glitch here is that if you manage to place two bombs in quick succession within this short timeframe (for example, through a hole in the ground or a screen transition), the game doesn’t know where to attach the second bomb and triggers a cutscene for a game object at a specific point in the code. In the case of collectible items, this means you can collect them from any distance and through walls. In other parts of the game, this can be used to unlock paths that are normally meant to be opened later or through other, more time-consuming methods. Examples like these show me that “just a quick one” is a phrase you should think very carefully about.
Whether it’s Backend, or frontend—they’re all cut from the same cloth
In addition, front-end developers should always keep in mind that the executed code can be viewed in the browser at any time, and that various build tools such as WebPack, Rollup, and Vite are often configured by the developers themselves to generate source maps, which make the code explicitly readable. This means, of course, that any security measure in the code—no matter how good—can be traced at any time, so it’s better to rely on the security in the Backend code.
In video games, this manifests in two ways. First, it’s possible to examine the game’s RAM to determine, for example, what value represents health points, ammunition, or similar elements. If you understand these values—and, in the best-case scenario, can even manipulate them—you can create “perfect” speedruns. On the other hand, there are projects that analyze the compiled code of games and explain their inner workings. This reveals, for example, internal mechanisms such as the random number generator used or the behavior of enemies and other game mechanics, allowing for the development of new glitches and strategies.
All in all, it’s clear that all programmers—whether they work on Backend, front-end, games, desktop applications, etc.—are all cut from the same cloth and have to deal with pretty similar problems. So why not tackle them with a bit of fun, games, and speed?
Questions about front-end development?
Please contact us directly if you have any questions about development.
Why the proServer Concept Still Stands Out Even After 10 Years
What began in 2016 as an evolution of our pluspunkthosting service has become a small success story: over 1,024 proServers by 2023—and the number has been growing steadily ever since. It’s time to look back and look ahead.
Girls’ Day 2026 at the punkt.de: First Programming Experiences with Micro:bit
On Girls’ Day, April 23, 2026, we welcomed eight girls between the ages of 12 and 14 to our locations in Frankfurt and Karlsruhe. The goal was clear: to make technology accessible, break down barriers, and help them experience real success by writing their very first programs.
