Home | Rules and Guide | Sign In/Create Account | Write a Post | Reddit | | #ludumdare on irc.afternet.org (Info)

Ludum Dare 29 — April 25th-28th Weekend [9 PM EST] — Theme: ??? (Slaughter!)
  • Ludum Dare 29 Compo Begins: in 9 days, 14 hours, 49 minutes, 7 seconds
  • Ludum Dare 29 Jam Begins: in 9 days, 14 hours, 49 minutes, 8 seconds
  • [ MiniLD 50 | Warmup Weekend April 19th-20th | Real World Gatherings | Ludum Deals | Wallpaper ]


    Faith in JavaScript has been restored

    Posted by
    August 6th, 2012 6:28 pm

    This post, other than being an I am IN post, actually describes my journey around JavaScript: why I left it and how I finally came back to it. If JavaScript concerns you, you would find here a few things that I hope I knew half a year ago. Also please excuse my inability to summarize.

    When I first started learning Javascript and Html5, I was trying to find an alternative to flash to make online games. At first, I have been pleased of how simple it was. You didn’t need a complex IDE, you didn’t need any compilers and libraries to get graphics. All you needed was an average text-editor (in my case gedit) and a browser (I chose Chrome for its developer’s tools). In fact, I have made a few unfinished but kind of playable “games”, one of them for the 34th miniLD.

    As I became better and better at the language (learning how closures work and stuff), I started seeing more and more of these “issues” in the language, as well as in the <canvas> object, some of them couldn’t be worked around. (There are quite a few of them and I chose to spare them for you as the paragraph was becoming big enough. If you’re curious ask in the comments.) Then, here is the issue that made me loose faith in JavaScript: the nature of JavaScript arrays. You see, in JavaScript arrays are just objects that have a special length property. And when you do myArray[5] it is exactly the same as myArray["5"] since it is supposed to internally do myArray[(5).toString] . So JavaScript arrays aren’t real arrays (C-like arrays), and aren’t even number-associative arrays , but are string-associative arrays. And to crown it all, these not real arrays can’t even be directly inherited.

    At this point I decided that maybe I should leave web scripting for a “real” language. For a few months I drifted from C++ to D, to Java and Processing and back to C++. If I would have settled down for a language, I would have probably became good at it, but it is such a difficult choice to make and there is always some feature that a language has and others don’t.

    And then, recently, I have found out that most JavaScript implementations actually treat arrays as real arrays until there is a need to really treat them differently. I was amused knowing how browser providers silently try to close the performance gaps left out by the standardization in which they have themselves took part. On a side note, I heard Mozilla is adding type inference in their next JavaScript implementation to speed it up. Cruel irony.

    Things started to get really bright for me when I discovered that JavaScript has a pretty new feature called Typed Arrays. Typed arrays permit to manipulate raw binary data by creating an array of bits and then accessing them as 8bit, 16bit, 32bit; signed, unsigned; ints or floats. I have then thought that it would be really good to use this kind of array to boost performance in a tile-based game where each tile corresponds to a number. So today’s JavaScript maybe isn’t so bad.

    And the future of JavaScript is even brighter, and must be, talking about the amount of people that use it. The JavaScript 2.0 draft that would make JavaScript strongly-typed but dynamic if the developer chooses, submitted by Netscape in 2006, sounded very exciting. Sadly, ECMA didn’t make it into ECMAscript 4, and to not confuse people they directly jumped to making ECMAscript 5, the language that we use today, with just a few small changes. Most of the features of the proposed JavaScript 2.0 were yet incorporated into ActionScript making flash developers pretty glad. But the ECMAscript team continued working on the proposal and they actually came up with an agreement: EcmaScript-Harmony wich will become the EcmaScript 6 (a quick list of it’s features that you can google may be found here). This will add classes, but just to simplify the prototyping based inheritance. Then they say that maybe, just maybe, they would make javascript strongly typed in a further release but not just yet. Anyways, the future looks good, but isn’t here yet.

    So to conclude, I would probably use HTML5 and JavaScript in the 24th Ludum Dare, unless I find some epic language/game engine at the last minute (if I for example start playing around with Flex). And in the mean time, I would be creating a library to simplify the use of typed arrays for 2d tile based games. I will make a system that automatically transforms a two-dimensional JavaScript array into an object that keeps the data as a typed array internally and gives you methods for easily accessing the tiles.(  var map= new binaryArray([[1,1,1],[1,0,23],[1,1,1]]);   map.setTile(1,2,25);   //set tile at (1,2) to 25  ). I hope that this would boost performance. I would keep track of my efforts on this blog and anyone of you would be able to use the library once it’s done.

    And to pursue the tradition:

    • Platform:HTML5
    • Language:JavaScript
    • Graphics:Gimp,Blender 3d, InkScape
    • Audio and Music: Audacity, LMMS, Bfxr

    Good luck to all of you and have a good time.

    I would also be searching for some screen recording program.

    One Response to “Faith in JavaScript has been restored”

    1. Puzzlem00n says:

      Haha. “Inability to summarize.” I’m in the same boat as you there. Try to keep things short, never can.

      Good luck in your pursuit of game devving, my friend. And check out the tools page for that screen recording stuff:

      http://www.ludumdare.com/compo/tools/

    Leave a Reply

    You must be logged in to post a comment.


    All posts, images, and comments are owned by their creators.

    [cache: storing page]