Before I get to the code-y parts, I want to discuss a bit about the limitations of web browsers, how React works, and what Colyseus and Nodejs bring to the table. Note that I am not a “deep diver” and will not be talking about exacts; I don’t want to create a college-level course on how web browsers work. I just want to explain how the combo of React and Colyseus addresses shortcomings of the modern web browser when designing a web-based game (even one as pedestrian as mine).

BSV – Before Streaming Video

I remember the first time I learned about “HyperText Markup”. I was in college at the time, and I found myself in my dorm room reading a “magazine” (which is a ‘zine, but printed on glossy paper) interview with pre-OBE Tim Berners-Lee. Berners-Lee was explaining how the “world wide web” was going to work (yes, future tense), allowing authors to post documents that anyone could access, embedded with “hyper-links” that could take a reader to a completely different document. As I was studying biology at the time and had experience writing lab reports rife with citations and references, the idea that the humble footnote could now be embedded inside a document was something that spoke to me. As dry as the vision was, I remember that the hairs on the back of my neck stood up as I thought of the potential for what we now know as “falling down the rabbit hole” of any subject imaginable.

At college, we started out with UNIX-based terminal browsers that used the Gopher protocol, a precursor to what we know as today’s Web. With a bit of hacking through our own server accounts, we could mount a file that would give us access to the wider…world web through a graphical browser called Slipknot, and then eventually Netscape Navigator.

I mention all of this because even modern browsers can access simple, original websites like these because at their core, web browsers don’t do anything fancy. They send out requests and receive responses. Those responses are just strings, which is why you can view the source of any web page and see it pretty much exactly as it was written by the developer. The browser parses these strings and formats the content using “HyperText Markup Language” — better known as HTML.

Early browsers didn’t have a lot to work with as HTML was still in its infancy, so web pages tended to look like shit by today’s standards:

Once the web started reaching more people — and more companies jumped on the bandwagon of getting themselves out there with their own web presence — folks realized that these cheap-ass web pages wouldn’t cut it. In order to engage better, web technology needed a makeover.

Flash in the Pan

Flash. Depending on your age, that either means a second-string DC hero, an early way to watch videos online that never worked correctly 100% of the time, your first introduction to web-based gaming, or you have absolutely no idea what the hell I’m talking about.

Flash was a product from a company called Macromedia that blew the doors off the Internet. Rather than leaving a website to static text, forms, images, and maybe a “chimp-attract” animated GIF (or 30), websites could incorporate complex animation, video, and live user interaction. From the back-end, it used a NLE (non-linear editor) to provide keyframed animation, and even came with it’s own programing language that allowed developers to respond to user input in real time. When I worked at a web development company in the late 90’s, we had a dedicated Flash animator who made a kick-ass application that — wait for it — allowed users to interactively build a custom shed that they could order. I know, right? In all honesty, I was jealous of those who knew how to use Flash, and I tried it myself on several occasions but could never get the hang of it.

The problem with Flash was that it required a plug-in. Plug-ins were small applications that ran within the context of the web browser, but which didn’t really interact with the browser. They’re like in-window air conditioners. Every time we encountered a site which used Flash, we might be asked to download the latest version of the plugin. If we refused then part of the site — or the whole site, because entire sites were created as a single Flash project sometimes — would be inaccessible.

To make matters worse, as time and tech moved on and Flash began to fall out of favor, it became a bonafide security risk as Adobe, who bought Macromedia, lagged behind on updating a plugin that was quickly becoming obsolete anyway. Flash continued to be supported by many browsers until somewhat recently but no one was building new content and almost everyone wanted it dead.

What Flash left us with, though, was the legacy of high-concept user experiences. Non-Flash websites were just static forms, text, and image, while Flash gave people a taste for what a full-on interactive website could be, and a direction for the future of what people expected from the web browsing experience.

CSS, Javascript, and Web 2.0

Back when the Web was created by academics, primarily for academics, the need for systems which could do anything other than display text and images was not very high on anyone’s priority list. When the public Internet moved out from under the iron fists of AOL and CompuServe and into the realm of mom-and-pop internet service providers (ISPs), Big Business moved in. Advances in supporting technology brought greater security, Flash made the user experience more exciting, and companies quickly started opening online storefronts which put us on the road to the Internet we know and loathe in 2021.

As an old school Internaut I often times resent the Web being made over in mold of naked commerce, but one resource we looked towards when I worked at the web dev company was — honest to gawd — porn sites. Say what you want about adult content, but the modern web would not exist today if not for the heroic efforts put forth by smut-peddlers who went all out (literally and figuratively) to protect their content. Credit card processing, security, locking down content, you name it and it was probably spearheaded (these innuendos write themselves, folks) by porn sites.

Of course, the web is better for the naked (hehe) insertion (haha) of Capitalism. Cascading Style Sheets (CSS) piggybacks on top of the response string to provide the browser with advanced rules on how to present the content it’s displaying so we get much better looking websites. Javascript adds processing power to the browser itself, allowing developers to “program” behaviors once the string reaches your desktop so we get a better user experiences (a hole left in the absence of Flash). A massive uptick in CSS and Javascript adoption in the early 2000’s resulted in “Web 2.0”, which is to the web experience what the Renaissance was to art and literature, although the former is much harder to nail down and describe and actually turned out to be a douchey buzzword used to confuse rubes. Talks began on how best to update the HTML spec, which was languishing in the face of so many new and exciting ways to use a web browser. The web was evolving beyond academic articles and began trending towards desktop-application-level usefulness.

The Song Remains The Same

Despite the evolution of the Internet and expansion of our experiences with the World Wide Web, the browser remains it’s same, humble self. It’s mission has never changed; make a request, receive a response, and display the result.

That more or less brings us to the problem that I’m hoping React and Colyseus will solve: how to keep the “conversation” going when using a tool that knows absolutely nothing about how to maintain a connection to a remote server in order to facilitate rapid communication that allows us to present the kind of “always on” experience a game needs to have.

I realize this post is already hella long, so I’ll try and get through the main points of React and Colyseus, but if you’ve made it this far and intend to continue, give yourself a gold star. I love you.

React, State, and Rendering

React is a “framework” developed by Facebook. It solves part of the problem of the stateless web by allowing parts of a web page to be “re-rendered” in response to updates of “state”. Let me unpack that quickly.

The Web is “stateless”. Once your basic web page is done loading, that’s it. It doesn’t know anything about what’s going on back at the place that served it, meaning that if an admin changed a headline in the database, fixing a typo, you won’t know it unless you refreshed the page to request a new copy from the web server.

State, then, is knowing the latest information and being able to get updates in real time. React is stateful because using “asynchronous Javascript” (AJAX), it can occasionally check back with the server behind the scenes for updates.

If updates are found, then React has the ability to update your web page through “targeted re-rendering”. React is smart enough to be able to update only the parts of the page that contain content that has changed. Designed properly, that headline typo fix would only re-render the headline display, and not the body content of the article you’re reading. For developers and designers, this is a massive benefit that allows for designs that are dynamic and responsive.

The only problem with React is that there’s no way for the server to tell React that there are updates to be had. React still needs to check in with the server to make sure everything is good, or if there’s been a change. There’s another framework called Angular which does perform this “two way binding” but it’s almost too over-engineered for its own good, and we won’t ever speak of it again.

Colyseus. Nodejs and Web Sockets

Javascript is built in to all modern web browsers and gives developers enormous power to provide rich and engaging experiences for end users. At some point, some smarty decided that Javascript was too good to limit to just browsers, so it got it’s own stand-alone treatment in the form of a server technology called Nodejs, often referred to as simply Node. [1]

Node is a blank slate, meaning it does nothing until someone comes along and gives it form and purpose. Many Discord bots run on Node, and it can be used to serve up web pages, but out of the box it does neither of those things. It’s lightweight and cross-platform, so it can be deployed to Windows, Macs and Linux machines both physically and In The Cloud(tm). Because it’s a Javascript engine, Javascript skills learned in service of web development can provide a strong foundation for Node server development.

Colyseus is a Javascript library. When integrated with Node and a client, it provides that always-on communication between the two using something called web sockets. The technical details of socket programming are way beyond the scope of this post (believe it or not), but know that a web socket ultimately solves the problem that underpins the modern web browsers: constant back and forth communication between client and server.

Forging Ahead

In the end (finally), the combination of React and Colyseus with Node look to be the kind of “in-my-wheelhouse” technology that I have been angling towards piecemeal with other technologies. First there was Unity, which is battle-tested and somewhat familiar (via C#) but relies heavily on game language I could never fully wrap my head around. Then there was my attempt to use other web-centric stateless communication tech like SignalR which, while effective, ended up a spaghetti mess that frustrated me the longer I tried to untangle it.

In the following posts, I’m going to explain — quicker, I hope — with examples, the initial tests I’ve come up with using React with Colyseus and Node.

Now go binge watch something I’m done for the night.

[1] Node is not the only Javascript engine out there, but it’s one if not the one, best well known example out there.