Monthly Archives: December 2013

Stellar Alien Android Update v1.0.2

Stellar Alien v1.0.2 patches several bugs that have been crawling around for a while now. But they’re squashed! There’s also a new share button after you complete your level to share your scores. Using CocoonJS’s socal extenstion, the browser-based code I used for the Facebook API didn’t need modification while migrating to the mobile application. Good stuff.

Update summary:

Version 1.0.2:
-Now brag to your friends on Facebook about beating your high score! You can share your score on Facebook with the new Facebook intergration.
-Fixed bug causing game credits not to stay on the screen.
-There should be a noticeable performance increase.
-Several bug fixes


In other news, I’ve been hacking on my multiplayer game using WebSockets the past few days. Hopefully after I squash these bugs I can give a preview and share some of the networking issues I’ve faced so far.

Lies Your JavaScript Haters Told You

After 18 years, It’s a bit hard to believe that JavaScript expanded so much. From what seemed like a little toy language that appeared in 1995 that could add interactivity to Netscape’s web browser, to the concept of “AJAX” that some say revived the web in 2005, to the HTML5 specfication providing powerful APIs for JavaScript and fast JavaScript implementations popping up since 2009…

JavaScript has shaped up to be quite a decent tool.

“Or maybe JavaScript is just to get something done fast and never look at it again, because JavaScript is just crap.”

That quote just grinds my gears, and I’m the one who wrote it! But it’s commonly said by someone who usually has some gross misconceptions about the JavaScript programming language, even after many years of widespread use, with no sign of the popularity ever dying down. And note that I’m not trying to say that JavaScript is perfect, every language has its faults and JavaScript is by far no exception. I could get some buddies and we could write a book on how much we hate writing and reading PHP.

But if you’re gonna write JavaScript, let’s make sure you don’t have some of the biggest misconceptions about the language in your head, so you can confidently write software.

“Dude, JavaScript is just Java’s little brother.”

Oh yeah, you saw this one coming. Some people reading this might be thinking “How can people still think that?”, but it turns out an overwhelming amount of people do think JavaScript is a smaller, simpler version of Java. Especially newcomers. But it’s simply not true.

JavaScript is not Java’s little brother, it is not Java’s sister, it is not Java’s Cousin, it is not Java’s second cousin, it is not related to Java in anyway besides the unfortunate fact it has “Java” in its name. and I must clear up this insane misconception before anything else, because many of the misconceptions I’m about to correct are directly related to this one.

And so if JavaScript has hardly any relation to Java besides them both inheriting C’s syntax, why does it have Java in its name then?

The answer is that it was probably a marketing ploy. At the time when JavaScript was designed over at NetScape by Brendan Eich, the fellas at NetScape asked Eich to design another programming language for web scripting to rival the Java Programming Language, as Java Applets were taking the web by storm at that time. (which you can see today, JavaScript actually won the resulting battle of the languages of the web)

Eich decided he would want to make a functional programming language, with semantics similar to Scheme and with object oriented programming inspired by Self Programming Language. But Netscape also requested Eich to make it “look like Java” so other programmers can easily adapt to it.

While Eich did successfully make JavaScript look like Java, he also decided he wanted to be sneaky and keep all the juicy traits derived from Scheme and Self, which in my personal opinion, are some of the best parts of JavaScript.

As a result, JavaScript is now a dynamically typed, prototype-based object oriented,  functional programming language with syntax that looks like C…Basically, JavaScript is a little confused and you must understand this to confidently write software in it.

May I also add that technically, we should be referring to JavaScript as ECMAScript, the name it was given since the language became an ECMA Standard. But the name hasn’t really caught on much, mainly because I think everyone else thinks it’s a lame name I guess. JavaScript is more known to the masses. And if it helps, consider JavaScript, JScript, and ActionScript as “implementations” of the ECMAScript standard.

“Javascript performance is too slow for games.”

So when I tell someone on the Internet about finishing my first game Stellar Alien in JavaScript, I can see their faces of horror and disgust through the text they respond with, often reading “JavaScript? That’s for scripting web pages, it’s far too slow for any real games”, or something like that.

The performance of JavaScript in general is determined by how fast the JavaScript engine your user is running is, and the past few years the performance of these JavaScript engines have increased greatly. Consider Google’s V8 engine, which is used in Chromium and Node.JS. V8 compiles your JavaScript code into optimized native machine code, unlike JavaScript engines in the past that simply interpreted JS code. V8 also tries to optimize the compiled machine code at runtime as well, dynamically. As a result, JS is a lot more faster these days, with speeds close to Java 7 according to some benchmarks.

So you may be thinking, “Great, V8 is fast. But what about IE, Firefox, and Safari, which don’t use V8?”

Well it turns out just about… all of them use a similar technique V8 uses. In fact, SpiderMonkey, the JavaScript engine Firefox uses is often shown to beat V8 in benchmarks as Spidermonkey uses a JIT Compiler to compile your JavaScript into native machine code. Safari’s Nitro JavaScript engine also compiles your JavaScript into native machine code, and so does Microsoft’s Chakra JavaScript engine used in IE since version 9.

Okay, I think I made it pretty clear that while JavaScript is delivered in plain text, it still gets JIT compiled by JavaScript engines into native machine code. But how well does JavaScript handle graphics? I mean, the performance can’t be that good since it’s running in the browser, right?

I’d probably agree with that statement in 2009, when most browsers used the Software Rasterizer for HTML5 canvas. Using the CPU/Software for the graphic calls will definitely be slow. If JavaScript is going to have any hopes of being a choice for game development it needs hardware acceleration. And it does today, since a few years now.

HTML5 canvas is hardware accelerated by modern browsers now, notably Chromium/Chrome, Safari, Opera, IE9, and Firefox. So the performance increased drastically now that it runs on the system’s GPU. Microsoft did a great job with their hardware accelerated canvas in IE9, because under the hood it uses DirectX for rendering. I’ve even noticed my game running faster in IE9 than Chrome. Also, don’t forget HTML5 canvas is a relatively low-level drawing API. It leaves a lot of stuff for you to do on your own that will drastically increase performance. See this article about implementing dirty rectangles in your game, and also about using multiple canvases (which helps A LOT and leads to the concept of having “layers”).

Let’s not forget about WebGL, the JavaScript implementation of OpenGL. WebGL has been performing pretty well so far, and will be the lowest level you can get as far as graphic APIs go in JavaScript. We also should remember WebGL is actually a 2D drawing API (that’s also capable of doing 3D of course with a bit of Linear Algebra) so consider it as a second choice for when deciding on a 2D rendering solution for your HTML5/JavaScript game!

“JavaScript has broken variable scoping, or none at all!”

So what’s the deal with JavaScript’s scoping? If you take this snippet for example:

Well that was weird. The next question is “Does JavaScript even have variable scoping?”. I’m not going to lie, the code snippet above suggests “no”, JavaScript does not having variable scoping as you would see it in Java or C, which have something commonly known as “block scope”. But as we established a few misconceptions ago, JavaScript isn’t anything like C or Java and just because you know those programming languages doesn’t necessarily man you know much about JavaScript.

JavaScript doesn’t have block scope which is commonly seen in programming languages that have C-like syntax. JavaScript has something called “function scope” rather than block scope.

To fully understand, let’s see this code snippet here:

Does it make a bit more sense now? There is no block scope in JavaScript, but there is function scope. This simply means that variables declared in functions using the “var” statement can only be accessed within that function. Variables declared in blocks of code like an if statement are added to the global namespace. That’s why we were able to log “string” when it was declared within the if statement block.

Knowing this about JavaScript’s variable scoping, you can create private data that cannot be modified by another’s code by encapsulating the data in a function, and many other interesting code patterns. See the popular Module Pattern.

Final Thought

I use JavaScript because it’s a very expressive programming language and I like its dynamic nature. It feels very loose and free and It’s the language I know best.

Like any other programming language, JavaScript has flaws and its initial poisition as “that little language that thinks it can beat Java in the fight for interactive web” leaves many programmers skeptical that JavaScript can be used today to write good software. And it’s different from what many are used to programming in, so naturally people will be hesitiant to write software in it. What I think is the bigger issue is how JavaScript basically lies to the programmer. The language dressed in a C-style syntax, but as you write programs in the language and undress it, you’ll find semantics derived from Scheme and Self.