Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon

20. October 2012

A month ago I started looking for a Mac based alternative to the excellent Windows Live Writer and thought I may have found one in the form of MarsEdit. It came with a 30 day trial and my final verdict was a bit mixed.  It was a very pleasant writing experience, if that makes any sense.  It was like when you write with a quality pen, the actual experience itself is just better.  On the other hand, some things were a bit unwieldy too.  The picture formatting tools are primitive to nonexistent, it's hard to format source code ( something of key importance to me ), it didn't do site preview all that well ( although frankly, neither did Live Writer, at least with my site ) and it didn't support tags.  None of those is a deal breaker, but all of them make the experience slightly worse than Live Writer, to the point when I needed to do code related blogs, I rebooted in to Windows to use Live Writer.  It's a great little product, but the limitations make me a bit hesitant to pull the trigger.  If it had good source code pasting options and better image formatting, I would have purchased already.

 

At the end of the day, I was resigning myself to having to work in Windows only, which is certainly unfortunate.  There are a couple open source cross-platform options, but they all seem pretty much terrible.  There are a couple other commercial options such as Blogo and Ecto, but let's just say their online presence just doesn't fill me with a ton of optimism. So I figured it was either MarsEdit ( which I may still buy ) or reboot to use Windows Live Writer ( not a great option ).  Then I discovered Adobe Contribute, which apparently started life as Macromedia Contribute.

First things first, Contribute is expensive compared to the other two products.  MarsEdit is 40$ ( plus they charge for updates ), Windows Live Writer is free, which is hard to compete with.  Adobe Contribute on the other hand is 100$.  That said, I have no qualms about paying for software, it's what I do for a living after all, and I spend so much time in my blog editor, that I will gladly pay that price if the experience is an improvement.  Now, I just need to decide if Contribute is an improvement!  Fortunately, like MarsEdit, it comes with a 30 day trial.

 

One immediately appealing feature of Contribute is that it is available cross-platform.  I need to confirm that if I buy a seat I can use it under either operating system ( I am not buying it twice! ), but if I can, have a familiar editing environment on either platform is a big plus to me.  The rest of this post is a bit of a playground for testing Contibute out.  First of all, Contribute certainly has more imaging options than MarsEdit.  Actually it may have more options than Windows Live Writer!  At the same time though, I've run in to a couple of limitations.  For some reason, and this is a shame as it is a feature I use all the time, but I can't copy and paste images for some reason.  I pulled the above image in to Preview and resized it, did a select all and... nothing.  The entire Edit->Paste menu in Contribute just stayed disabled.  Need to see if this is a bug or not. 

That said, I didn't actually have to pull the image in to Preview in the first place, you can actually in place resize and crop images in Contribute.  You can also rotate, sharpen, adjust contrast and brightness, or send it to an external program for editing.  Unlike MarsEdit, you can also apply image padding, borders and edge colours, although unlike Live Writer, you cannot set padding on a side by side basis.  In the end, I would say the image handling is better than MarsEdit, and on par with Live Writer, if I can get paste working that is.

I am running in to some other problems in addition to the inability to paste images, I can't choose categories.  According to my blog settings it is allowed, but the Categories menu is disabled, and refreshing categories results in the Window:

Which by the way, not being able to copy paste the above was really disruptive, requiring me to capture it, convert it to png, import it.  Blah. On an unrelated note, why the heck does grab save things to tiff format?  Tiff? Is this 1992?

One other thing I have noticed is, I cannot drop directly to the HTML level.  I may be missing how to do it, but I don't see any menu option for editing as HTML or sending to an external editor.  This feature is handy when you run in to limitations of the blogging software and is something that MarsEdit does quite well, while Live Writer does it, but can be a bit destructive at times.  Contribute doesn't seem to do it at all.  There is however the ability to enter an HTML snippet, which should accomplish the same thing, at least most of the time.  As mentioned above, Categories are supported ( as the are in MarsEdit and Live Writer ), but do not work with my blog.  Tags are also supported, unlike MarsEdit, but it doesn't have the ability to download a list of tags to choose from.  Considering my blog treats HTML and Html as different tags, this missing feature is well, missed.

Contribute does seem to support pretty good table formatting...

  A B
1 DataData
2 DataData
 
Merged cells work!
 
So does per cell formatting

I have to say, table support is exceptional.  I never could get merged cells to work in Live Writer.  Tables are still a damned handy feature, so it's nice to see how well they work.  I never really tested table functionality in MarsEdit... oops.

 

Now what about code... does it preserve formating... a straight paste from XCode:

bool demo::drawScene(Node* node)

{

// If the node visited contains a model, draw it

Model* model = node->getModel();

if (model)

{

model->draw();

}

return true;

}

 

UGH, not be default anyways. There certainly doesn't appear to be an option for pasting as RTF either. Let's try pasting from Sublime Text Exported HTML:

-- create text to display on screen in 72point font
local helloText = display.newText("Hello World!",0,0,native.systemFont,72)
-- center to screen
helloText.x = display.contentWidth/2
helloText.y = display.contentHeight/2

Ick...

 

Now the same HTML as a snippet:

Strike that... didn't work.

 

 

Ok, that's enough for me.  For 100$ price tag, Contribute doesn't work for me.  Hell, for a 40$ price tag, it doesn't work for me.  One last test to see if this publishing even works...

 

Anyone know any other options I should look in to for Mac based blogging?  As of right now, it's seeming like MarsEdit or bust.

19. October 2012

 

Sony, actually… and file this under the category of longest most unwieldy names ever, Sony Computer Entertainment Worldwide Studios Europe External Development Studio (yeah… really) in collaboration with Creative England and Birmingham Science Park have put together a contestimage called PlayStation Pioneers, with a grand prize of £25,000.  That’s about 40K in real money! Smile

 

So, how then do you go about winning this money?  Well, here are the details:

  • The opportunity is open to UK-based developers only
  • The goal is to take a concept/prototype and develop a playable ‘vertical slice’ suitable for consumer trial/user testing in summer 2013.
  • The deadline for submissions is 31st October 2012
  • Five finalists will then be selected to exhibit at this year’s LAUNCH conference taking place at Birmingham Science Park on 13th and 14th November 2012 and present their concepts to a panel.
  • £25,000 will be awarded to the winning entry
  • XDev will have the first right of refusal in regard to publishing the final game.
  • The winner will be announced by the panel at LAUNCH on 14th November 2012.

 

What isn’t explicitly listed in those requirements, your project will be for PlayStation Mobile.

 

That deadline is fast approaching (less than 2 weeks!).  Keep in mind though, you are submitting a *concept* by October 31st, not a complete game. 

 

The other line of note you should be aware of was:

XDev will have the first right of refusal in regard to publishing the final game

In other words, if they like you game, they get first crack at being the publisher.  Given that most indie developers would love to have a publisher, this shouldn’t be a huge deal, but is certainly something you should be aware of.

 

 

If you have never heard of it before, PlayStation Mobile is cross platform game development system based around Mono.  It is C# based, built over OpenGL ES and able to target the PlayStation Vita, as well as select Android mobile devices ( most Sony Android devices, plus select devices from HTC, Asus and a few other manufacturers ).  This site has a series of tutorials you can used to get started.

 

You can read the original announcement thread right here.

 

If you are interested in proceeding, be sure to read this guide (PDF link).  It gives more details of what is involved.  From that document, here is what is recommended in your proposal:

1. Concept summary (ideally one page).
2. A walkthrough/storyboard detailing the proposed ‘vertical slice’ playable.
3. Artwork/Visualisation that is representative of proposed final quality.
4. Design briefs (prototypes where possible) explaining key features.
5. A summary schedule and risk assessment re delivery of the ‘vertical slice’ playable to be delivered for full
consumer trial/user testing in summer 2013.
6. A commercial/financial business model, illustrating market potential for the concept on PS Mobile certified
platforms; (PS Vita, Xperia, Sony Tablet S etc.)
7. Details of relevant prior experience.

 

The PDF however has no more legal issues regarding publishing or IP ownership.

News ,

17. October 2012

 

A level is made up of sprites and sprites come from somewhere.  In our editor, we are going to allow the user to “upload” multiple image files containing sprite sheets.  However, are server is not required and that is going to require a bit of work.  Also, we are going to need some form of UI where users can upload the spritesheet, without cluttering our main UI too much, so we will implement it as a modal dialog box.

 

Well, let’s get to it.  First lets create a data type for holding our sprite sheet collection.  For now, a spritesheet is simply an image, the dimensions of each sprite and a name.  In your models folder create a new file named spriteSheet.js

spriteSheet.js

 

YUI.add('spriteSheet',function(Y){
    Y.SpriteSheet = Y.Base.create('spriteSheet', Y.Model, [],{
            count:function(){
                return this.get('spritesheets').length;
            },
            add:function(name,width,height,img){
                this.get('spritesheets').push({name:name,width:width,height:height,img:img});
            }
        },{
            ATTRS:{
                spritesheets: {
                    value: []
                }
            }
        }
    );
}, '0.0.1', { requires: ['model']});

Nothing really special.  Our spritesheets attribute is just an empty array for now.  We also included a pair of methods, add, for adding a new spritesheet and count for getting the current count of spritesheets already declared.  Everything else here should already be familiar at this point.

 

Now we want to create a dialog that will be displayed when the user wants to add a spritesheet.  As a bit of a spoiler, here is what we are going to create:

image

This isn’t a View and it isn’t a model, so we create a new folder called classess and create the long-winded file named AddSpriteSheetDialog.js

AddSpriteSheetDialog.js

YUI.add('addSpriteSheetDialog', function(Y){

    Y.AddSpriteSheetDialog = new Y.Base();
    var spriteSheets = null;
    Y.AddSpriteSheetDialog.show = function(ss,onComplete){
        spriteSheets = ss;
        var panel = new Y.Panel({
            width:500,
            height:300,
            centered:true,
            visible:true,
            modal:true,
            headerContent:'Select the image file containing your sprite sheet',
            bodyContent:Y.Node.create(
                "<DIV>\
                <input type=file id=spritesheet /> \
                <br /> <div id=imgName style='padding-top:25px;padding-bottom:25px'> \
                Click above to select a file to download</div>\
                <br />Sheet name:<input type=Text id=name size=30 value=''> \
                <br />Sprite Width:<input type=Text id=width size=4 value=32> \
                Sprite Height:<input type=Text id=height size=4 value=32> \
                <br /><input type=button id=done value=done />\
                </DIV>\
                "
            ),
            render:true
        });

        var fileUpload = Y.one("#spritesheet");
        fileUpload.on("change", Y.AddSpriteSheetDialog._fileUploaded);

        var buttonDone = Y.one("#done");
        buttonDone.on("click", function(){
            panel.hide();
            onComplete();
        })
        panel.show();

    };

    Y.AddSpriteSheetDialog._fileUploaded = function(e){
        if(!e.target._node.files[0].type.match(/image.*/)){
            alert("NOT AN IMAGE!");
            return;
        }
        var selectedFile = e.target._node.files[0];
        var fileReader = new FileReader();

        var that=this;
        fileReader.onload = (function(file){
            return function(e){
                if(e.target.readyState == 2)
                {
                    var imgData = e.target.result;
                    var img = new Image();
                    img.onload = function(){
                        Y.one('#imgName').set('innerHTML',selectedFile.name + " selected");
                        var name = Y.one('#name').get('value');
                        var width = Y.one('#width').get('value');
                        var height = Y.one('#height').get('value');
                        spriteSheets.add(name,width,height,img);
                    }
                    img.src = imgData;
                }
            };

        })(selectedFile);
        fileReader.readAsDataURL(selectedFile);

    };


},'0.0.1', {requires:['node','spriteSheet','panel']});

The editorView owns the spritesheet collection, and passes it in to the show() method of AddSpriteSheetDialog.  We also pass in a callback function that will be called when we are done.

We start off creating the panel which is a Y.Panel.  Most of the properties should be pretty straight forward, headerContent is the title and bodyContent is either the ID of the object to render the panel in, or in our case, we actually create a new node with our dialog HTML.  We then wire up a change handler on our file upload button, this will fire when a file is uploaded and call the _fileUploaded function.  We then wire up the Done button’s on click handler to hide the panel then call the callback function that was passed in.  Finally we display the panel.

 

When the user clicks the Choose File button, _fileUploaded is called.  First thing we check to make sure it is an image that is uploaded and error out if it isn’t.  We then want to read the selected file, which we do with the FileReader api.  Word of warning, this isn’t completely supported in every browser… frankly though, I don’t care about supporting IE in a project like this, cross browser support takes all of the fun out of web app development! Smile

 

Next is well… JavaScript at it’s most confusing. We are registering an onload event that will be fired once the file has been loaded, which in turn fires off an anonymous method.  It checks the readystate of the file to make sure it is ready and if so, our “uploaded” file will be in e.target.result.  We then create an Image object, then register yet another onload handler, this one for when the image has completed loading.  Once the user has uploaded the file, its finished loading and populated in our newly create Image, we then get the width, height name and our newly populated image and at it to the screenSheets object we passed in during show().  Yes, this is a bit screwy of an interface, in that you need to populate the text fields before uploading the interview.  I will ultimately clean that up ( and add edit ability ), but it would needlessly complicate the code for now.  Finally, no that our fileReader.onload() event is done, we actually read the file now with readAsDataUrl() the file that was chosen, which fires off the whole onload event handler in the first place.   Welcome to asynchronous JavaScript programming!  Don’t worry, if this is new to you, thinking async will come naturally soon enough…

 

So, that is how you can create a modal dialog to edit app data.  Now we wire it up and deal with a bit of a gotcha.

 

The gotcha first…  the Panel dialog requires a parent HTML element in the DOM to have a YUI skin CSS class declared.  At the bottom on the render function in editor.View.js add the following code:

Y.one('body').setStyle("margin",0);
Y.one('body').setStyle("overflow","hidden");
// The below needs to be added as some controls, such as our add sprite dialog, require a parent container
// to have the YUI skin defined already
Y.one('body').setAttribute("class","yui3-skin-sam");
return this;

This adds the yui3-skin-sam class to the page’s body, which brings in all the styling for the Panel ( and other YUI widgets ).

 

While we are in editor.View.js, we wire up a menu handler for when the user clicks the add spritesheet button ( we will add in a second ).  That handler is basically the same as the menu:fileExit handler we created earlier.  Right below that handler in the initializer function, add the following:

 

var that = this;
Y.Global.on('menu:fileAddSpriteSheet',function(e){
    var dialog = Y.AddSpriteSheetDialog.show(that.spriteSheets,function(){
        var sheet = that.spriteSheets.get("spritesheets")[0];
        console.log(sheet);
    });
});

There is the that=this hack again, there are alternatives ( you can pass the context in to the Y.Global.on event handler ), but this is a fair bit easier at the end of the day, as we would lose this again when the callback is called.  Otherwise, when the menu:fileAddSpriteSheet event is received, we simply call AddSpriteSheetDialog.show(), passing in our spritesheet and the function that is called when the panel is complete.  For now we simply log the spritesheet out to the console to prove something changed.

We also need to add the SpriteSheet to our editor.View.js, like so:

 

 Y.EditorView = Y.Base.create('editorView', Y.View, [], {
        spriteSheets:new Y.SpriteSheet(),
        initializer:function(){

 

Now we need to add the menu item.  First add it to the template mainMenu.Template,like so:

<ul>
    <li class="yui3-menuitem" id="menuFileAddSpriteSheet">
        <a class="yui3-menuitem-content" href="#">Add SpriteSheet</a>
    </li>
    <li class="yui3-menuitem" id="menuFileExit">
        <a class="yui3-menuitem-content" href="#">Exit</a>
    </li>
</ul

And we wire it up in the mainMenu.View.js, add the bottom of render() add the following code:

var menuFileAddSpriteSheet = container.one('#menuFileAddSpriteSheet');
            menuFileAddSpriteSheet.on("click", function(e){
                Y.Global.fire('menu:fileAddSpriteSheet', {msg:null});
            });

Oh, and our newly added script AddSpriteSheetDialog.js is added to index.html to guarantee it gets loaded and evaluated.

 

And done.  We now added a dialog for adding sprite sheet images, and can store the image results locally without requiring any server interaction at all.

 

Here is the end result, select File->Add Spritesheet to bring up the newly created dialog:

 


You can download the entire updated source code here.

One step closer to a full web based game editor, one very tiny step. Smile

Programming, General , , ,

16. October 2012

 

I recently read this ( very good ) blog post documenting the process of developing and publishing the game Pumped BMX and was struck by one thing.  I really really liked the font he used on his site, it was clean but not gimmicky.

 

It turns out the font is Open Sans, created by Google.  I have decided to adopt it on GameFromScratch.com.  With the recent increase of page width I also decided to increase the font size from 12 to 14pt.

 

Here are before and after results:

image

 

What do you think?  Like it better the new way, or prefer the old font?  All told they are both fairly similar fonts, so it’s not a very massive change.

Totally Off Topic

14. October 2012

 

I don’t think there are many people out there that would argue that JavaScript isn’t an important language.  It certainly is, and with the recent death of Flash and Silverlight in the browser and the hype behind HTML5, to say nothing of Node, it is actually getting more popular

 

I also don’t think there are many people out there that would argue that JavaScript is a heavily broken language too.  As systems written in JavaScript become larger and more complex, the language flaws become more and more pronounced.  Just as C++ ultimately came about from C’s (arguable by some) inability to deal with complexity, a number of companies and groups are looking at possible successors to JavaScript.  Generally all of these languages are backward compatible with JavaScript in some form.  Let’s take a look at the contenders for the short term future of JavaScript.

 

 

ECMAScript 6 AKA Harmony AKA ES.next

 

When talking about the future of JavaScript, the most logical place to start is … well, the future of JavaScript, the next version.  The spec is a work in progress and you can read it here, the most recent revision as of writing (September 27th, 2012).  It would seem obvious that the next version of JavaScript would be ECMAScript 6, but don’t bet the farm just yet.  After all, ECMAScript 6 is effectively a scaled back version of ECMAScript 4, while ECMAScript 5 (the JavaScript version in common usage today), is essentially a fork of ECMAScript 3.  Firefox and Chrome already support bits of ECMAScript 6, so it’s future is quite bright, but by no means are things certain.  Plus there is no way of knowing how long until ECMAScript 6 is supported enough to actually make it useful.  For an idea of where ECMAScript support in various browsers is, check out this handy table.

 

This has opened the door to a number of alternatives, many are languages that compile down to JavaScript making them useful today. Others (like Dart) compile down to JavaScript as a fallback, but perform better in their native environment.

 

 

The 900lb gorillas.

 

Two of the companies are very interested in the future of JavaScript are Google and Microsoft.  Each has created a language they hope will be the future of JavaScript, Dart and TypeScript respectively.

 

This interview between Anders Hejlsberg ( Microsoft, creator of Delphi, C# and now TypeScript ) and Lars Bak ( Google, creator of V8 JavaScript engine and Dart ) is very good summary.  It allows each developer to describe their opinions of the existing problems with JavaScript ( on which they largely agree ) and describe the strengths of each of their companies offerings.

 

Anders Heljsberg & Lars Bak on TypeScript/Dart and the problems with JavaScript today

 

 

Google Dart

 

http://code.google.com/p/dart/ or http://www.dartlang.org/

image

 

In Their Words:

Why Dart?

At Google we've written our share of web apps, and we've tried in many ways to make improvements to that development process, short of introducing a new language. Now we think it's time to take that leap. We designed Dart to be easy to write development tools for, well-suited to modern app development, and capable of high-performance implementations.

 

Dynamic or Static Typed?

Dynamic

 

Key language features

Compiles down to JavaScript, or to the Dart VM ( which is currently only available in Chrome ).  Code running in the Dart VM will perform better.

Language is basically JavaScript with prototypes removed and classes added.  They’ve added lexical closures, sane this management, optional static types, named parameters, cleaner event and DOM programming and more.

The language also comes with an IDE, the Dart Editor, which is a mash-up of Eclipse, Chromium and the DartVM.  For those like me that prefer WebStorm/IntelliJ over Eclipse, they also have a plugin available.  There used to be a cloud based editor, but it appears to have been retired.

 

My 2 cents

Dart technically solves most of the problems with JavaScript and is compatible with existing JavaScript.  That said, I checked out Dart shortly after it was released, then again 6 months later and as usual, Google’s developer support stunk.  They just don’t put the extra effort in to making the experience easy on developers ( at the time, the Windows build didn’t work, you need to compile everything yourself, etc… this lack of polish is just as common with other Google developer tools such as GWT, NativeClient even Android), but the package seems to be improved quite a bit.  Just a warning though, if you aren’t experienced with Google developer support, be prepared for a ton of frustrations if you run in to any problems.

Probably the biggest flaw with Dart is going to be the lack of adoption.  Dart compiles to JavaScript as a fall back, but the VM is obviously the preferred platform.  Google announced their intention of submitting Dart to a standards body, but do you see Microsoft or Mozilla adopting Dart?  Yeah, me neither.  That said, Chrome is getting a pretty big install base.

My biggest problems are the above mentioned Google support, and their tendency to kill off projects at the drop of a hat lately. 

 

 

Microsoft TypeScript

 

http://www.typescriptlang.org/

 

image

In Their Words:

Why TypeScript?

TypeScript is a language for application-scale JavaScript development. TypeScript is a typed superset of JavaScript that compiles to plain JavaScript. Any browser. Any host. Any OS. Open Source.

Dynamic or Static Typed?

Static

 

Key language features

TypeScript is compiled down to JavaScript.

Language allows you to add static types to JavaScript, allowing you to catch type errors during the compilation process ( although the compilation will still generate a JS file ).  Allows you to mix and match TypeScript and JavaScript in existing files.  Adds new constructs to the language such as classes, interfaces and modules.

IDE support is available in the form of a Visual Studio 2012 plugin, as well as plugins for Sublime Text, Vi and Emacs.  They also have Node support out of the box and you can download TypeScript using NPM.

 

My 2 cents

I will admit, I am a bit of a Anders fanboy, so that has gotten me excited about this language.  Language design is all about pragmatic choices, and Anders just seems to pick the right compromises.

At the end of the day, TypeScript is less of a gamble than Dart, and this has it’s advantages and disadvantages.  As Lars said in that video above, TypeScript is “the safe bet” and that is a pretty apt description.  It is a layer on top of JavaScript and nothing more, in many ways it is quite similar to CoffeeScript.  In the end though, TypeScript is probably the one that will best integrate with existing Javascript and given the massive variety of existing code, that is probably a pretty big advantage.  At the end of the day though, TypeScript is ends up being JavaScript, so don’t expect any performance improvements.

The tooling support is shockingly not Microsoft.  Would you have ever expected Vi and Emacs support from day 1?  What about Node support?  There is a noted lack of documentation at this point, which is shocking for a Microsoft product.  They do however have a nifty Playground/Tutorial environment that allows you to type TypeScript and see the generated JavaScript.  Sadly for now, comments and whitespaces are mangled as part of the process, although this is a temporary flaw.

 

 

CoffeeScript

http://coffeescript.org/

 

In Their Words:

CoffeeScript is a little language that compiles into JavaScript. Underneath all those awkward braces and semicolons, JavaScript has alwaysimage had a gorgeous object model at its heart. CoffeeScript is an attempt to expose the good parts of JavaScript in a simple way.

The golden rule of CoffeeScript is: "It's just JavaScript". The code compiles one-to-one into the equivalent JS, and there is no interpretation at runtime

 

Dynamic or Static Typed?

Dynamic

 

Key Language Features

Coffeescript is a whitespace ( as opposed to curly brace ) based language that compiles down to JavaScript.  It is certainly the elder statements of the group and has been around for a number of years.

Coffeescript provides a number of features to JavaScript including a class system, lexical scoping, splats (…) for variable arguments, array slicing and more.  Additionally it provides a layer of syntactical sugar over some of the JavaScript warts such as is instead of === or unless as the inverse of if.

Coffeescript also offers impressive tooling support.  Like TypeScript, it is available as a Node utility, making installation via NPM trivial.  Most IDEs support Coffeescript ( IntelliJ, Eclipse, WebStorm, Netbeans, Sublime Text, etc ) out of the box.

 

My 2 cents

I only gave CoffeeScript the smallest of evaluations and that was a few years back.  You see, I have an irrational hatred of whitespace based languages.  What I found most irksome ( and TypeScript fixed this ), is that it’s a language on-top of JavaScript, not within Javascript.  So you had to program things the Coffeescript way, then compile it to JavaScript.  Coffeescript felt like a completely different language than JavaScript, while neither Dart nor TypeScript gave me that impression.  Mostly though, I never got over my hatred of whitespace based languages.

All that said, CoffeeScript solved many of the problems that Dart and TypeScript are setting out to solve, and it solved them years ago.  It’s by far the most mature and as a result had the most time to iron out the kinks.

 

 

Other Options

 

Dart, TypeScript and CoffeeScript are by no means the only options when it comes to more programmer friendly JavaScript programming languages, but they are the three that are closest to JavaScript itself.  The following are a selection of other languages that will compile to JavaScript.

 

 

GWT – Google Web Toolkit

 

https://developers.google.com/web-toolkit/

Google Web Toolkit (GWT) is a development toolkit for building and optimizing complex browser-based applications. GWT is used by many products atimage Google, including Google AdWords and Orkut. It's open source, completely free, and used by thousands of developers around the world.

Basically GTW is a Java –> JavaScript compiler.  That is over generalizing, but basically you write your code using a subset of libraries in the Java language, and it is compiled down to JavaScript.  Or a bit of mix and match, with Java running on the server and JavaScript on the client.  The programmer never really works in JavaScript when working with GWT.

 

As is pretty typical with Google projects, IDE support is mostly Eclipse based.  There are a few published books available for GWT.  GWT has been around for quite a while and integrates nicely with Google App Engine.  That said, if you aren’t a Java developer, GWT really isn’t for you.

 

 

 

Haxe

 

http://haxe.org/

Haxe is a powerful modern language with many compelling features. It is aimed at giving developers a tool to create websites & applications using aimage single unified programming language. Whether you use Haxe for its cross-platform features, or focus on a single platform, there are many reasons to adopt it.

Haxe is a language that allows you to compile down to JavaScript, Flash, NekoVM, PHP, C++, C# and Java.  It provides a standard language and library that compiles down to the mentioned languages, while filling in the missing pieces of each language, such as packages and typing for JavaScript, reflection for C++, etc.  The Haxe language itself is derived from ActionScript 3, which itself is a ECMAScript language. Haxe has pretty good IDE support. Haxe also has a few published books which is always handy.

 

I’ve not yet used Haxe, mostly because I have no prior ActionScript experience and because I never really had the time to look into it further. That said, HaxeNME, which is a gaming library targeting web, mobile and desktop certainly has piqued my interests.

 

 

 

Other other options…

 

This doesn’t even come close to listing all of the languages that compile to JavaScript, for a more complete list see this.  This does however cover the major players, at least as I see them.  If you think I made a major omission or mistake in this list, please let me know!

 

JavaScript is becoming more important and JavaScript programs are becoming more complex.  The language does have a number of flaws, but fortunately there are a number of options to help you cope, at least until ECMAScript 6 arrives.

General, Programming ,

Month List

Popular Comments