When I first decided to build tools to help manage Cuthbert, I knew I didn’t want to get distracted from developing the actual game for too long. I wanted to build something quickly, then get back to the fun bit.

(Yes. The game is the fun bit. Don’t be fooled by all my complaining.)

Now, I’d been building the main Cuthbert game in PHP – a simple programming language that gets a bit unfairly sneered down on by professional developers (you know who you are!) because it’s easy to pick up and, consequently, easy to make poor programming decisions in. I’ve made them all, and I still think it’s fantastic. (You heard me, Ruby on Rails!)

Of course, one of the reasons I think it’s fantastic is I’ve been coding in it for about eight years now and I’m old and curmudgeonly and stuck in my ways, and all you kids need to get off my lawn I’m faster using it than I am other languages – so it made sense as a quick go-to.

Get out of here, kids, with your Grails, and your Django, and your fancy hip hop music. _{Adobe Stock}

I built PHP to handle all the heavy lifting, and I added a little sprinkle of code from jQuery, a JavaScript library (think code that runs in your browser – it melts in your mouth, not in your hand), and another one I’ve been using for more years than I feel comfortable admitting to, to handle simple user interactions.

It was all prototype code, really, something I’d started coding because I knew I could write it quickly. I knew I ideally wanted to move the game to something else down the road, but I’d decided it was more important to get something made, rather than make something sexy.

So – it made sense to make the dev tools the same way. When you didn’t think about it for more than ten seconds. Like me.

I figured it seemed silly to make the tools jazzier than the actual game. (If you enjoy using the content management system more than the content, something is very wrong…)

‘This spreadsheet is the boooomb! _{Adobe Stock}

And I wanted to make them fast – I didn’t want to spend time researching solutions, trying things out. I wanted to get them built.

But the more I worked on the content management engine, the more obvious it became that jQuery was nooot the best tool for the job.

I needed to watch too many fields, to call in too much content dynamically.

I could do it. I could also write the game script by spelling it out, word-by-word, in spaghetti hoops, but it’s hardly the most convenient medium.

‘Ooooooo,’ said Cuthbert.
Look. NaNoWriMo was a trying time for me. _{Adobe Stock}

And as beautifully as I organised the code (so beautifully!), as little of a concern as speed and performance were for something designed to run offline on my laptop (so beautifully little!), it still felt like I was doing too much unneccessary work.

This feeling was not helped by the fact that, in my more-accurate-but-less-tuneful-nine-to-six work life, I was using the React.js framework – a JavaScript library built by Facebook, and ruddy well, to manage web applications with lots of changing data – to create super snazzy tools for clients to use.

I was writing less code and getting faster performance for it.

But I was reluctant to throw away what I’d done and re-code the tools, and I only got more reluctant the more work I did.

‘But I’d already categorised the loot by shininess before it sank. We need to go get it.’
Ah, sunk cost psychology. You draw me in every time, you saucy minx. _{Adobe Stock}

It was only when I was laid-off from my un-Partonable nine-to-six and decided to give up on the idea of making the game within any specific timeframe that I decided refactoring now – rather than later, when the sunk costs would be even sunkier – was probably a good idea.

And React was definitely a good thing to refactor in.

I’m planning to refactor the main game as well, before I release a demo, so it will feel more like a game and less like a website stuck in 1997, but I thought it made sense to refactor the tools first. It’s a much smaller project and it’d be easier to tell if it was all a terrible, terrible idea early on.

Good news – it wasn’t!

React – which I’m using with NuclearJS to plump it out into a Flux framework, for those nerdy enough to understand what any of those words mean – is phenomenal.

For a bit of comparison, this is a file I lovingly built in jQuery, using Webpack (oh, I’m just hurling the tech terms at you in this one), which let me build the code as separate modules, but have one single file to show at the end of it.

It took 220 lines of code to handle adding an optional field to the form so, for example, a room can have another name which you only see if you’ve been privy to a certain conversation.

The code watches for a click on a link and, when it spots one, adds the fields to the page for the name itself and for the conditions the user needs to have met to see it. It also puts out some links to remove the fields again.

It has to call the PHP to get the actual form mark-up, and then it writes that into the document view. Leave the page and come back again, and it’ll all be gone. Gone!

In React, I wrote 75 lines of code to do things in a much better way. Everything is rendered by JavaScript.

Now, I started coding professionally back in 2004, and a little bit of me still winces at both the idea of rendering everything in JavaScript, because that used to be considered a terrible, inaccessible practice back in the day, and at remembering how long ago 2004 was.

But – technology has moved in, and best practice has moved on with it, and contrary to what my snooty younger self may have believed, this is A Good Thing. Particularly in this instance – with everything in JavaScript, there’s no need to use JavaScript to call PHP to put some code back in the JavaScript.

Instead, React watches for changes in the code and re-renders what it has to. I pass it the data it needs, and it updates when that data changes. In 75 lines of code, it handles watching the links, rendering new fields, and deleting them.

And it’s fast. I lost a chunk of the day today to clicking the add field link and then deleting what I’d added, just to play with it.

Er, I mean… stress test. To stress test it. Yes.

I’ve refactored the tools back to where I’d left off with the original prototype, and I’m hoping it won’t take me too much longer to finish them off.

Then, I can start refactoring the main game the same way – making it quick, slick, and much more enjoyable to play with.

I mean, stress test.