Person = function(fname, lname, age) {
...
    var getFirstName = function() {
    ...
    };
};

The second style is defining functions directly. So, the previous example becomes like this:

function Person(fname, lname, age) {
...
    function getFirstName() {
    ...
    };
};

Syntactically, I prefer the second style. It’s simpler and feels more natural. However, in my previous post about JavaScript classes, I used the first style for a reason. The reason is that even though you could use the second style for constructors and private methods, you cannot use it for privileged or public methods. You need to set privileged methods to “this” and public methods to protototype. So, the Person class from my previous post looks like this when I use the second style:

// Constructor
function Person(fname, lname, age) {

    // Private variables
    var _fname = fname;
    var _lname = lname;
    var _age = age;

    // Private method
    function getFirstName() {
        return _fname;
    };

    // Public variable
    this.fullName = fname + ' ' + lname;

    // Privileged method - exposes private variables and methods publicly.
    this.getFirstNameAndAge = function() {
        return getFirstName() + ", " + _age;
    };

    Person.numberOfPeople++;
};

// Public static variable
Person.numberOfPeople = 0;

// Public method
Person.prototype.getFullNameAndNumberOfPeople = function () {
    return this.fullName + " --> " + Person.numberOfPeople;
};

Notice how some functions are defined directly and some of them are defined as function variables. Even though this is not too bad, I prefer to stick with a single style, so I always go with the first style for consistency.

// Constructor
Person = function(fname, lname, age) {

    // Private variables
    var _fname = fname;
    var _lname = lname;
    var _age = age;

    // Private method
    var getFirstName = function() {
        return _fname;
    };

    // Public variable
    this.fullName = fname + ' ' + lname;

    // Privileged method - exposes private variables and methods publicly.
    this.getFirstNameAndAge = function() {
        return getFirstName() + ", " + _age;
    };

    Person.numberOfPeople++;
};

// Public static variable
Person.numberOfPeople = 0;

// Public method
Person.prototype.getFullNameAndNumberOfPeople = function () {
    return this.fullName + " --> " + Person.numberOfPeople;
};

And here’s the test output for the class:

var person = new Person('Mete', 'Atamel', 29);
var person2 = new Person('John', 'Smith', 50);
console.log(person._fname); // undefined
console.log(person.fullName); // Mete Atamel
console.log(person.getFirstNameAndAge()); // Mete, 29
console.log(Person.numberOfPeople); // 2
console.log(person.getFullNameAndNumberOfPeople()) // Mete Atamel --> 2

If you want to run the HTML/JavaScript chat sample, put Chat.html next to Chat.swf along with dataservices-client.js that’s under resources/client-sdk/javascript folder of DataServices installation.

If you want to run the sample yourself, here is the productRO.html file that I talked about in the video. Copy it where productRO.swf is along with dataservices-samples.js provided in resouces/client-sdks/javascript folder of DataServices installation.

Google recently announced Dart, a new programming language aimed for serious web apps. I can’t tell you how excited I am with this announcement.

If you’ve been following my posts recently, I had a series of posts on JavaScript (part1, part2, part3, part4, conclusion) where I concluded that JavaScript is not ready for serious development on the web. My main complaints were lack of true object oriented support, lack of visibility control, lack of type support, lack of tooling, and overall primitive nature of JavaScript language. If you look at Dart Technical Overview, Google is tackling the exact issues I outlined in my previous posts. There will be classes, optional types, libraries in Dart with extensive tooling.

This is quite exciting but not that exciting for me because ActionScript and the Flash ecosystem around it already provides all of these. I think the more exciting part of Dart (that ActionScript does not provide) is its flexibility. The type system in Dart is optional, so you can use it if you want strongly typed code (which will surely help with tooling) but you don’t have to and you can simply revert back to JavaScript style of everything being a var. Similarly, you can run Dart in its own VM that Chrome will surely provide and other browsers might follow but if some browser doesn’t support Dart VM, no worries, you will be able to compile Dart into JavaScript.

If Google can truly implement this kind of flexibility across browsers, I think Dart can be a serious contender to be the new language of the web. It’ll also be interesting how ActionScript will evolve as Dart materializes. Good times for web development for sure!

It’s certainly possible to create complex applications with JavaScript but the development and maintenance cost will definitely be higher than it would be for more strongly typed platforms like Java and Flash due to the looseness and primitive nature of the language, inconsistent runs across different browsers, and lack of mature/standard tooling around it.

Bad news: Most developers are stuck with JavaScript due to HTML5 madness. Good news: There are some great efforts, such as Google Closure Library, that recognize the shortcomings of JavaScript and provide tools to minimize the pain to a degree.

In the near term, I think we’ll see more tools and frameworks to address the shortcomings of JavaScript, so that’s not too bad of an issue but the inconsistencies among different browsers is a harder problem to solve because it involves browser vendors to cooperate and that doesn’t happen too often.

Whether you like Flash or not, one great value it provides is the consistent runtime across different browsers backed by a mature language like ActionScript 3. Consistency and maturity enabled serious development in Flash and sooner or later, JavaScript will have to provide the same level of consistency and maturity across different screens.

This could happen with more advanced tooling, or it could happen by transforming JavaScript into a more mature and extensive language and getting browser vendors stick with standards. One thing is certain though, it’s going to take time, and as it happens, I probably won’t help thinking “But Java/Flash had this 10 years ago!”

There are some established tools for Flash and Java development. For Java, there’s Eclipse & IntelliJ for IDEs, JUnit for testing, Ant/Maven for building, and JavaDoc for documentation. Similarly, for Flash, there’s Flash Builder/IntelliJ for IDEs, FlexUnit/MxUnit for testing, Ant/Maven/FlexMojos for building, and ASDoc for documentation. These tools might not be perfect but they work, they are maintained by a number of people, and there’s a community around them, so you don’t have to spend a lot of time and effort figuring out what to use for your project. There are established tools for the job.

In JavaScript, the tooling environment is messy to say the least. It’s ironic because the only way an inadequate language running inconsistently on different screens would be considered for serious development is if the tooling around the language was rock solid. I don’t think that’s the case in JavaScript.

There are some great initiatives from Google on this front with Closure Library and Closure Tools but my sense is that these tools are not perceived as standard as for example JUnit is perceived in the Java world at this point in time.

In my project, I couldn’t find a decent IDE to start with. I tried from Aptana to JSEclipse to IntelliJ JavaScript Editor and finally, I settled on IntelliJ which is somewhat decent but it’s far from Flash Builder in terms of debugging, code hinting and code templates.

For debugging, I mostly relied on browsers. I used the built-in debuggers in Chrome, Safari, Internet Explorer, and I used Firebug in Firefox. Chrome has by far the most responsive and useful debugger, so thanks to guys in the Chrome team for helping me debug a number of issues. Firebug was ok but a little slow and crashed a number of times. By far the worst debugger was Internet Explorer. The debugger had a difficult time just loading up and when the test hit a breakpoint, it would stop and refresh the whole page for 2-3 seconds. I don’t know if this is because I’m on Mac and I was running Windows 7 in VMWare but the debugger in IE was just awful. It’s great that all these browsers support some kind of debugging but I missed the consistency of Flash Builder every time I switched from one debugger to the next.

For testing, we were hoping to find something similar to JUnit in Java and FlexUnit in Flex, and after some research, we settled on Jasmine. The testing convention of Jasmine is somewhat different than JUnit but it met our needs for the most part and I do recommend it. I think Google’s Closure Library has a more JUnit like testing framework but by the time we found that, half of our tests were written in Jasmine, so we didn’t bother to switch at that point.

For JSDoc tool, there’s nothing standard for JavaScript mainly because the looseness of the language makes doc generation difficult. It looks like JSDoc-ToolKit is one of the main ones along with Yahoo’s YuiDoc but getting these tools recognize your coding style is a challenge. I think you’re better off if you stick with Google JavaScript Style Guide right from the beginning. This way you make sure JSDoc can generate docs for your JavaScript among many other benefits.

The conclusion here is that there’s some useful tooling around JavaScript but they are not mature yet and as a result no de facto standard tools have emerged. This means you need to spend some time researching into different tools and frameworks that you otherwise take granted in Java and Flash. Google’s Closure Library and Tools definitely have potential to be one of those de facto tools/frameworks and hopefully that will help to establish a solid environment for developers to build on.

Previously, I pointed out some major inadequacies of the language but as developers, we’re used to working with non-ideal languages in non-ideal platforms with ridiculous deadlines. We just get stuff done, so it shouldn’t be a big deal for a software craftsman that JavaScript lacks a few modern language artifacts, right? Besides, what about the simplicity of JavaScript? Isn’t there some value there?

I agree and that was the spirit I tried to keep up during my project. However, when you have a language that runs inconsistently on different screens, you lose the positive energy you try to uphold so hard.

In Flash or Java, you don’t really need to worry about the run-time too much because Flash Runtime and JVM provide mostly consistent environments for your applications to run in. Even though JavaScript is supposed to be based on standards, there are many inconsistencies among browsers.

To be fair, most of these inconsistencies are due to our big old friend Microsoft and their Internet Explorer but it’s still hard to ignore Internet Explorer, so you need to deal with these inconsistencies on your own.

During my time with Java and Flash, I ran into maybe 2 or 3 issues that are browser or operating system specific. In my 1 year of JavaScript development, I ran into at least 10, if not more, issues with browser inconsistencies.

For example, Array.indexOf is a function that is supported by bunch of browsers like Firefox, Chrome, etc. but not in Internet Explorer. You don’t know that until you run your application against Internet Explorer.

Another example is XML support. In most browsers, you have DOMParser but in Internet Explorer, you need to use the ActiveXObject.

Yet another example is XMLHttpRequest. Most modern browsers handle it one way but in Internet Explorer 6, you need to use the ActiveXObject again. Even the ones that handle it regular don’t do it consistently. For example, in Firefox, when you try to send a POST request where the first byte is zero, the POST body is dropped.

For byte array support, Firefox has a XMLHttpRequest#sendAsBinary method but it’s not a standard so others don’t have it. Internet Explorer has some byte array support but it’s VBScript and not a standard again.

In HTML5 space, I don’t have much experience other than WebSockets and that is a little messy itself with some browsers supporting hixie-76 version, some supporting hixie-76 in disabled mode, some not supporting at all, and some planing to support hybi-10 I’m sure there are more differences in other areas like CSS or UI stuff.

So how do you deal with these? Unfortunately, there’s no great solution. Frameworks like JQuery somewhat helps with these problems but again with my Java and Flash background, I expect the language to work consistently across different screens and I find it a little backwards that I need to depend on a framework to do the right thing.

Any time spent in cross browser issues is wasted time in my opinion and you’re going to waste time in cross-browser issues and that seems to be an accepted fact of life in the JavaScript land.

In our project, we didn’t want to depend on any external frameworks, so we created a central class to deal with cross browser issues and it helps that there’s one central abstracted place for all cross-browser issues but it’s far from ideal.

The main lesson here is that you really need to test your application against all browsers that you claim support for all the time because something might break in some browser at any time. You don’t have the luxury of assuming that “it should work” like you do in Java or Flash applications because you don’t have JVM or Flash Runtime to provide some kind of stability across different screens. In JavaScript land, you need to treat every browser as similar and yet different implementations and you need to keep reminding yourself that over and over again.

All of this is probably obvious to JavaScript developers but cross browser/operating system capability is something Java and Flash developers have been taking granted for some time now, so it feels like a step backwards having to think about these issues again. Thankfully, our friends at Google created tools such as Closure Compiler, Closure Linter around their Closure Library that helps with some of these issues and I hope it becomes some kind of standard or somehow seeks into the language itself, so everyone gets these benefits by the mere virtue of using the language.

The key is to have great and automated tests that you can easily run against different browsers but which one to use? That’s a whole different topic that I’ll cover in my next post.

I don’t care what anyone else says about how easy JavaScript is, how well it performs and so on because any gain one might get in one area is completely overshadowed by many fundamental features missing in JavaScript. Here are some very basic but fundamental features that you would expect from a modern language that JavaScript simply does not have.

No Visibility Control

There’s no notion of public, protected, private or constant/final variables in JavaScript. Everything is just a plain “var” or a “function” that everyone else sees and has access to and change. Ok, you can define vars in functions and that somewhat hides them but when a var is declared, I want to be able to say whether it’s public, protected or private. This helps in many ways that I don’t even think I need to explain and the lack of it turns me off as a serious developer. So, what do you do? You end up coming up with a set of rules on your own. In our project, we treated all upper case variables as constants, we treated variables that start with underscore as private etc. so you can deal with this problem on your own but it’s not ideal. I expect the language to enforce these rules because if a rule is not enforced, someone is certainly going to break it.

No True Object-Oriented Programming Model

In JavaScript, Object-Oriented programing simply means “Here’s an Object with a few key/value pairs and functions” and that’s it. There’s no way of defining a class like in Java or ActionScript, no way a subclass extending from a super class, no interfaces or abstract classes, not even function overloading for God’s sake! This is very frustrating because in 2011, you expect these from a serious language. Instead, you have bunch of frameworks or best-practices to mimic Object-Oriented programming. For example, in our project, we started using John Resig’s Inheritance Model which works OK but has a few bugs and quirks. We recently discovered Google’s Closure Library  that also has an inheritance model among other things. It’s good that there’s help out there but then again, language itself should provide these not random frameworks.

No Package/Namespace Support

Any serious project needs some way of organizing code, and in modern languages, this is done by using a file per class and then combining multiple files into packages. Unfortunately, JavaScript does not enforce a file per class rule and it has no notion of packages or namespaces. You are again left alone to deal with this on your own. For example, you can create “namespace objects” and attach functions/classes to it. For example:

var dev = {};
dev.echoservice = {};
dev.echoservice.Book = function()

You also need to manage dependencies, so if class A depends on class B, you need to make sure class B is listed earlier than class A in the JavaScript file. In our project, we used separate files for each JavaScript class, and then we used an Ant task to combine all JavaScript files into a single file with the right order. Recently, I discovered that Google’s Closure Library has some dependency support that looks useful but nothing in the language itself.

No Proper Hashtable/Map Support

In JavaScript, you can use Objects as Maps but the problem is keys can only be Strings. This works for simple applications but for many complex applications, you need Objects as keys. Fortunately, there are open source implementations like JSHashtable but the language itself leaves a lot to be desired for.

No Byte Array or DataInput/Output Support

Another major missing component in JavaScript is proper byte array support. There are many use cases where you simply want to send and receive a byte array. Unfortunately, there’s no native byte array support in JavaScript yet. Internet Explorer has a byte array implementation but it’s VBScript and not standard. People try to fake byte arrays by sending bytes as Strings and using String#charCodeAt and String#fromCharCode to interpret String as bytes but this is simply asking for trouble because many browsers mess with incoming/outgoing bytes. There are hacks (search for “charset=x-user-defined”) to deal with those or some browsers such as Firefox have non-standard ways of dealing with this (see Firefox’s XMLHttpRequest#sendAsBinary method) but nothing that feels non-hack.

As a related note, there are no DataInput/Output streams either, so even if you manage to send bytes as String, then you need to interpret those bytes on your own. For example, if you need to send/receive floats, you need to understand and implement IEEE-754 on your own instead of depending on the language. I did this and I can assure you that I lost good 2-3 days of my life during the process Be ready to pull some of your hair out as you’re dealing with byte arrays in JavaScript.

No Syntactic Sugar

After so many fundamental features missing from JavaScript, I wasn’t holding my breath for syntactic sugar and soon it was clear that there weren’t any.

In Java, you can get your IDE create getters/setters for your property automatically. In ActionScript, getters/setters are built into the language which is very nice. In JavaScript, without visibility control, there’s no support or need for getters/setters. This is not as big a deal as other problems but it’d be nice to have ActionScript like getter/setter support built into the language.

Another one is annotations. Annotating code with useful information is becoming standard nowadays and they are useful in many ways. Unfortunately, JavaScript has no support for annotations in any shape or form as far as I can tell.

I’m sure there are other things missing that I can’t remember right now but if you’re not convinced that JavaScript is an inadequate language for complex projects so far, then watch for my next post where I’ll talk about how browser inconsistencies makes things even worse…

First, some background. I’ve been a Java developer for almost 10 years and in the last 5 years, I’ve been doing ActionScript/Flash development. In my current role, I’m maintaining and improving BlazeDS and LiveCycle DataServices products which are Java (on the server) and ActionScript (on the client) based applications. In the past year or so, I’ve been periodically working on a JavaScript library, so, I have a good sense and experience of working with Java, ActionScript, and JavaScript.

As any serious developer, I’m used to Object-Oriented design, I expect a consistent and extensive SDK to work with, I expect decent IDEs to help me in coding and I am used to standard tools to help me in building, testing and documenting my code.

In Java, the platform independent Java language backed by JDK combined with Eclipse/IntelliJ IDE and tools like Ant/Maven, JavaDocs, FindBugs, and PMD help me to achieve maintainable, testable, bug-free, and well documented code.

In Flash, the platform independent ActionScript backed by Flash combined with with Flash Builder/IntelliJ, and familiar tools like Ant/Maven, ASDocs, and FlexPMD help me achieve the same level of productivity on the client side as well which is great.

Unfortunately, JavaScript is nowhere near to Java and Flash in terms of creating clean, maintainable, testable and consistent code. Don’t get me wrong, it’s certainly possible to write complex applications in JavaScript and I did so by implementing the full AMF binary encoding format in JavaScript. However, just because something is possible, it does not mean it’s optimal. During my JavaScript development, I felt like I went back in time and I was at school coding for a school project using an experimental language. It looks like I’m not alone feeling this way.

In my next post, I’ll try to justify my claims with my own experiences from my JavaScript project, so stay tuned.