At the end of the first part, I said that my replacement for GMS is Dart using the StageXL library. In this post, I’ll talk about why.

As I said, I’m a web developer as my day job. For the job, we’re generally creating web apps to replace our client’s old and outdated workflows. We keep things simple and usually choose a PHP MVC backend with an Angular JS frontend.

Even though I use it every day for work and depend heavily on it for my job, I don’t really like JavaScript. It has… problems.

JavaScript has a very small subset that is considered “good”. This bothers me quite a bit. I understand that JavaScript can’t just excise the “bad” parts because it has to maintain backwards compatibility, but I don’t have to like it.

I’m also not a fan that when it comes to web development the only language that works across all browsers is JavaScript. This is in contrast to computer applications where the number of languages available is mind-boggling. C, C++, Java, C#, Rust, Go, Python and the list goes on.

Of course, if you’d like, you can program your application using assembly to get that closest-possible-to-the-metal experience, but since there’s more choices, you can use whatever you’d like.

I like to think of JavaScript as the assembly language of the web. Granted, it’s not even close to as difficult as assembly programming, but it’s the closest to the metal that the web can get (at least for now, there’s an effort going on right now on something that actually aims to be the assembly for the web called WebAssembly that I’m excited about).

Just like I wouldn’t choose to create a new Windows program in assembly, I like to choose something that fits my style much better than JavaScript. At work I’m stuck doing JavaScript, but that doesn’t mean I have to be stuck with it when I program on my own.

Dart was announced a few years ago and it was love at first sight. It was created at Google to be a better structured replacement for JavaScript. I personally think it started as a response to Oracle’s threats with Java. Google had a lot invested in Java and it looked like Oracle was going to make them regret that decision. To hedge their bets, they decided to start up a few language projects to solve current and future problems.

I took to Dart right away because they did so many things right. It was designed for speed. It had a stronger type system. It had modules. It didn’t have the warts.

Google started off with big plans. Dart would be integrated into Chrome to run even faster. Dart would become the lingua franca of the web. Those plans were ambitious and ultimately untenable. But not all was lost.

The big plans fizzled out as uptake wasn’t huge and immediate. But it allowed the team to refocus their efforts to make a great language.

To me, personally, Dart is really attractive for a few key reasons. One is built-in promise support. Anyone who has worked with Angular is familiar with promises. Promises make asynchronous programming much easier and Dart has it built in.

With any JavaScript project, you’ll need to decide how to bring in promises: whether they come with your framework like Angular or perhaps include a library. But which library out of the many?

Dart takes this problem away with a standard library. All code uses the same standard. You don’t have to worry about possible incompatibilities.

And then they took it beyond promises with async/await. If you haven’t heard about this, it’s a paradigm shift. It makes promises even easier. I was writing some code yesterday at work and cried a little because I wanted to use async/await.

Another great feature is a standard package manager and task runner. Unlike JavaScript where you’re torn between npm and bower and between grunt and gulp, it’s a breath of fresh air to have everything working together in a standard way.

Just a couple more things that are standouts. The module system is well done and makes composition easier. Also the JavaScript interop system recently got an overhaul to make it much easier to “reach outside” Dart and talk to JavaScript.

Dart, for me, makes a lot of sense as a JavaScript replacement. I know there are a ton of different choices once you decide to go the “compiles to JavaScript” route, but Dart hits all the right points.

This post is already long enough. With my next one I’ll talk about why I chose StageXL as my game framework and about how I planned to build and distribute my mobile game.

Next: Part 3: Embracing StageXL