I foolishly promised Amandine on Twitter that I would write about my experiences going from hard-core C++ game tech to web tech. And so, before this ends up on the pile of Things I Could Write About, let me take a stab at actually doing so.

Back in the 90s I wrote hard-core game tech in C++ (and before that in C and 68K assembler). Then, in 2001 or so, I changed careers and programming became more of a hobby. I used Python to write small tools, then later got into HTML and CSS. Then, while ostensibly being creative director of the company I co-founded, and despite being surrounded by hard-core C++ programmers whose knowledge, unlike mine, was not literally from the last millenium, I was writing a lot of tools in Python, as well all of the HTML and JavaScript and what have you.

Additionally, I developed Gameconfs and am currently developing full-stack web-based tools for Moon Collider, an AI middleware company. So I guess I'm a web developer now.

Anyway, very quickly and in no particular order, here are some of the things I found remarkable in going from C++ to web technology:

Lots of tiny parts

Web tech is many layers of simple parts adding up to a complicated whole. The individual parts are really quite simple, but it's when you're going RBDMS -> ORM -> Python -> JSON -> websockets -> JavaScript -> jQuery -> DOM -> browser that occasionally you start to feel light-headed. But it's all doable. I should probably say that every part is simple until it isn't, but it's astounding how many layers of tech written by strangers you can mash together into a working application.

Stacks

The most important thing in web tech is your stack: the combination of technologies you use to handle user (meaning browser) requests in the front end (meaning in the browser or perhaps in a mobile app's UI) and the back end (on the server).

The original stack is LAMP: Linux, Apache, MySQL, and PHP. But while solid it's also a bit... old-fashioned. (Gameconfs uses Linux, whatever Heroku uses as a web server, PostgreSQL, and Python.)

Front end and back end

Front end and back end tend to use different technologies (unless you use Node and write JavaScript on the server) and skills, so they are often done by different people. Someone who can do both parts (like me) is a full-stack developer.

Front end developers often work with "designers", meaning graphic and UX designers. Web designers often use Photoshop. Some front end developers do web design as well (like me, although I'm mediocre at it).

This is why social game companies, which grew out of web companies, often have front end and back end programmers in their teams, and their game designers are often expected to do 2D graphics.

Stateless protocols are weird

HTTP is probably the most important protocol to understand in the web world. It's fairly easy to work with but the big mindfuck coming from games is that it's stateless, meaning that the protocol requires no state to kept between requests on either the client or the server side. Every HTTP request arrives in a fresh new world of possibilities. This has advantages: HTTP is simple, you can easily send HTTP requests to a different machine from last time (great for scaling), etc. But when I first tried to "quickly" store something in a global variable only to find out it didn't work, it hit me that I was going to spend a lot of time managing state myself. And so you get to cookies, sessions, and databases.

Databases are useful - who knew?

Your technical career may not be like mine, but I had sort of vaguely heard of relational databases yet never needed to use one or knew people who did (in PC and console games, in the 90s). Well, it turns out they're useful and even cool, especially PostgreSQL, which is kind of a beast.

I'd say start with an ORM (an Object-Relational Mapping, meaning a layer between the database and your programming language). But know that there are good reasons for eventually digging deeper and getting into SQL and really using the power of your database.

And of course the kids these days like to use so-called NoSQL databases, like MongoDB, Redis, etc. My opinion on these is that they are cool, but I have not yet had a problem that *really* required a NoSQL database, especially since PostgreSQL can handle key/value and JSON data. So I prefer using a tool I know and that has been around for a long time. But, as I will explain below, that is not the typical web tech way.

Lots of Linux and OS X

For historical reasons, web development, on the back end side, is very Linux-oriented. On the client side, OS X is very popular because it is historically artist-friendly *and* has a Unix inside, so you can develop both front end and back end software.

So get used to seeing a lot of OS X, and to some software not working or not being available under Windows, or being a pain to install.

I love this aspect of web development, but then I would say that, as I switched to OS X in 2003. And I've even slowly started learning about Linux system administration.

It's all online

It's all online. By definition. That might seem obvious, but in my experience game programming tends to be very conservative, and for a very good reason: at some point you had to compile that puppy onto a CD or DVD and then it was a major pain in the ass to make any changes. That is slightly easier now, but nowhere near as easy as on the web, where by pressing a single button you can route half of your audience to a different machine on a different continent where the software is written in a different language and nobody notices and *it's not witchcraft*. And by pressing a different button you can undo all that.

(And that audience often grows slower than in games too. Being able to do *real* MVPs, where you start with a dumb website and then scale up to potentially millions is very nice.)

Lots of languages

Because game-like performance is not the highest priority for web development, there is a lot more choice in languages, and most of them are interpreted. So web development can be done in PHP, Python, Ruby, JavaScript, Java, Clojure, Scala, you name it.

This has pros and cons. Pros: languages that are easier and faster to develop in than C++ *hugs Python*, much more choice, and you get exposed to a lot of different languages and programming concepts. I learned a lot about asynchronous and functional programming by working with Pythona and JavaScript.

Cons: Pick the wrong language and you'll have trouble finding programmers, or the right programmers.

Lots of open source

Most of the software you'll work with is open source. This is very different from game development on Windows, in my experience. The downside of this is that licenses matter, so you better be aware of those, and sometimes projects get abandoned and bugs remain unfixed. But that's not *that* difference from commercial software, and in open source you can (and I do) fix bugs that bother you and even get them included back in the original software.

New technology *all the time*

Everything changes really quickly, and new frameworks and tools are developed all the time, often per language. They all have stupid names: Capistrano, Desert, Rake, Mongrel, Pip, Rails, Django, Lettuce, Jasmine.

People tend to run towards the Next Cool Thing, which can be annoying and counterproductive.

Rapid development, scalability, then maybe performance

I am not saying performance is irrelevant in the web world. I am saying that many technical choices are made to make development faster and scalability easier, rather than code faster. E.g. Python is fast for a dynamic language, but not fast compared to hand-tuned C++. But it's easy(ish) to set up a nice coding workflow with Python (say) and to quickly deploy your code to a server in the cloud, and to add additional servers to your web application.

Performance is an issue, but perhaps more in terms of page load times or server responsiveness.

Different tools and practices

Automated testing and continuous integration are popular in the web world - I think more popular, or at least common earlier, than in game tech.

I think automated testing became popular because a) as someone pointed out, HTTP is *ideal* for automated testing because it forces a clean interface, and b) if you don't have a compiler checking for a certain class of bug, it's worth doing something else to catch bugs.

You now see continuous integration in game development as well. And rightly so because it's awesome. Of course, by now the web world has moved to continuous *deployment*. Which leads us to:

DevOps

One big part of these different tools and practices is a concept called DevOps. In the Days of Old, server programmers would write server software, put it on a disk, put that disk in a capsule, put that capsule in a pneumatic tube, and send it to the IT department. The IT department would put that software on a server and curse when it crashed at three in the morning because it took up too much memory. Meanwhile the programmers were lying on a beach somewhere.

Slightly more seriously: DevOps means considering developing, deploying, and operating software as one whole. In practice, for me, it means there are awesome tools for automatically setting up AWS instances and loading my software onto it and telling me when it crashes.

A more official version is here. And if you want to read a cool story about continuous deployment from 2009, here you go. IMVU: it's not just creepy ads, they also have cool technology.

Front-end has workflows now

Maybe you've written an HTML file and a CSS file and even a JavaScript file at some point. That is now old school, the web equivalent of hand-assembling opcodes by the light of a candle made from the wax of your own bees. Hip kids these days write their JavaScript in CoffeeScript or some other -Script, or at least get the JavaScript linted and minified and concatenated using some tool like Yeoman or Grunt (stupid names, told you). Style sheets are written in LESS or SASS and then transformed into CSS. Just as you have package managers to manage software packages for your back end language (Python uses Pip to install egs, Ruby install Gems, Clojure uses a tool called Leiningen), you now have package managers for front end packages as well. One is called Jam, the other Bower. I rest my case.