Choosing JavaScript Or Godot For Your Next Project

Occasionally, I’ll receive this question in Discord or YouTube comments:

What do you prefer when developing a new game: Godot or JavaScript?

For context, my video viewers mostly know me as a guy who has been making games with JavaScript over the years. When I started creating videos about developing with Godot, some assumed that I’ve “switched teams” or had some kind of falling out with JavaScript. That’s not the case at all - Godot is simply another tool in my toolbox, and I’m happily balancing both.

I don’t have a clear answer or favorite. The truth is I love using both JavaScript and Godot for game development these days and reach for them at different times for different reasons.

Before we get into it, here’s a quick spoiler of my conclusion: if you are not sure which way you need to go, you can’t choose wrong. Players of your game won’t know or care how your game was made, they just want to play a fun, high quality game.

With that in mind, as developers, we should be in tune our own needs and interests to persist through deserts of a long gamedev projects. We are humans facing an uphill challenge of shipping large games. We’re at constant risk of Shiny Object Syndrome, so we need to choose tools and technologies that will age well and be a good companion through the entire journey of finishing a game. Maybe in other words, the right question to answer is “which stack will I actually finish this game with?”

So, how do you decide between the two? Let’s dive through about a pro/con list. These are just thoughts and nuances I’ve noted in my own experience.

Benefits of authoring in JavaScript

• Full time web developers/JavaScript-slingers will be right at home when writing code in the language of JavaScript. No need to balance multiple programming languages in your brain.
• Use your own tools. I am silly fast with JetBrains WebStorm IDE, for example. I have snippets, shortcuts, and workflows that save me loads of time. The productivity flow keeps me going, and it’s typically easier for me to jump back into a project that has been stagnant for a few months. Your favorite web browser also counts as a tool, by the way, where you’ll spend a lot of time testing and debugging your work.
• Text as the source. In a JavaScript/web repo, you’re usually working with a bunch of text files in a directory. Rather than full-blown GUI applications with inspector windows and things getting lost/maybe accidentally changed, every change you make happens by editing code. As a caveat, perhaps you’ve created an Editor tool to help you generate code or content… in that case, you’re probably leveraging the tool to automate some code authoring you previously were doing manually.
• Quick and easy URL sharing. While engines often have HTML5 Export, there’s nothing quite as fluid as pushing your work up to Vercel or Netlify and sharing a preview link with somebody, or plopping your work in a quick CodePen demo. There are probably ways to make it better, but I’ve found sharing Godot projects to be a bit awkward if you just want to send somebody a “play this real quick” kind of link. This is also a huge pro for Game Jams and situations where you want your game to conveniently be played right in a browser.
• Mobile support by default. If your game runs in a browser, a bit of Responsive Web Design will enable you to serve both Mobile and Desktop users with a few styling moves. Granted, you need to put thought and effort into the experience of each platform (the user input may be wildly different), but the technical side is available by default.

Drawbacks of authoring in JavaScript

• Everything is manual. JavaScript itself doesn’t give you much for making a game. It’s likely you’ll be writing a lot of code for features that would normally be “free” in a game engine. Game objects, animations, keyboard input, step loops, etc. Luckily there’s a vast ecosystem of open source libraries and frameworks ready for you to drop in.
• Decision paralysis. Along those lines, while a vast ecosystem of open source libraries exists, you will need to navigate the available options and make some choices. For example, you’ll need solutions for graphics, sound, potentially physics, rendering. Do you utilize libraries for these concerns or roll your own systems? Either path is valid, but you have to decide.
• Browser quirks. While the browser support story has never been better, some browsers will straight up be more performant than others. Something that runs great on Chrome, for example, may be slow and jittery in Firefox. Unless you explicitly choose to support only one browser, you’ll need to do a lot of cross-browser QA testing.
• Native distribution is arguably awkward. If you want your JavaScript game to be available on platforms like Steam, Electron and Tauri are two great options for wrapping your JavaScript game as a native app. While both are viable and generally easy to use, they come with their own quirks, baggage, and learning curves. And more decisions to make! The good news is that this avenue is tried and true these days, so you’ll be able to get your game packaged up after a bit of research and tinkering. That said, they are certainly not as “automatic” as exporting to native using an established game engine. There’s a lot of innovation happening in this space, so let’s all stay tuned!

Benefits of authoring in Godot

• Implementation speed. It’s wicked fast to get a prototype up and running. Godot’s pre-built Nodes likely provide everything you need to create a minimal playable version of your game idea. Physics, animations, cameras, tile sets, they are all there and ready for you. For example, a simple move_and_slide line of code in a CharacterBody2D will take care of hundreds of lines of physics code in a more manual approach.
• Built for games. While JavaScript game development sometimes feels unconventional, Godot is proudly designed and optimized for the output to be a game. You won’t spend anytime with styling tweaks or browser workarounds to make something feel like a cinematic video game experience. As you might expect, Godot has excellent runtime performance out of the box for loops, rendering, and a load of graphical configuration options.
• 3D tooling. Godot has excellent 3D tools built in at the top level. In fact, the seamless switching of 2D to 3D contexts in Godot is one of my favorite features.
• Native support by default. Rather than “wrapping” your project in a way that can be run natively on Windows/Mac/Linux, or even a console like Nintendo Switch, Godot assumes you’re interested in distributing your game in this way and has export templates for each platform ready to go.

Drawbacks of authoring in Godot

• You are a bit constrained to the Godot IDE. Godot’s editor is fantastic, in my opinion, so it’s almost unfair to put this as a drawback. But, simply in contrast to JavaScript, you’ll likely have to be firing up the Godot editor to make most of your changes. Under the hood, the Godot editor is simply writing text files to your machine, but I’ve found those impractical to modify in an external text editor. GDscript files, however, can totally be edited in your preferred IDE of choice. You’ll still be booting up the Godot IDE pretty often to change Scene configurations and other settings. Worth mentioning that it’s a big beefy window.
• Version changes are more invasive. If you start your project in 4.x, you should probably plan to stick with that version for however many months or years it takes to finish your project. Version changes are coming fast, too, so it’s easy to quickly fall behind from being on the latest version, which is where the FOMO can get ‘ya. Upgrading a minor change (Like v4.0 to v4.1) usually is pretty smooth, but could introduce unexpected problems under your feet. I personally encountered some rough bumps when upgrading my v3.1 to v3.2 project back in the day. You’ll also need to install a new version of Godot to your development machine when changing versions, where you’ll want to be careful not to override previous versions if you still have projects that use them.
• Community information is fragmented, but improving. When searching for help online, be sure to watch out for the differences between versions 2, 3, and 4. They are wildly different. It can be frustrating as a beginner. That said, this is getting better as more people adopt Godot and the community standardizes where to find latest information. It’s worth noting that resources like Chat-GPT can help you translate older versions of Godot code to whatever version you are using.

Don’t sweat it

If you’re on the fence, there’s no need to let the decision hold you up. Just pick the language you are most interested in and be on your way. Try not to agonize over the tech bits… it’s better to pour that mental energy into the actual game. If you had all the design answers and assets, I bet you could switch pretty quickly if the technology choice was too limiting.

Just answer the question, dangit

So generally speaking, what do I reach for these days?

• If it’s 3D, I’m reaching for Godot.
• If I’m just trying to make a proof of concept, and it involves physics, it’s Godot.
• If I want the lowest barrier of entry for people to try playing the game, it’s JavaScript.
• If I’m going to be working on it for multiple years, it’s JavaScript.