The vocal portions of the Web that care about such things seem to have already made up their minds about Dart, the new web programming language from Google. My opinion of it has been flipping between intrigue and tedium.

Maybe you don’t even know what I’m talking about so here’s the gist of it: last week at the GOTO conference Google unveiled, to moderate hype, their new programming language called Dart. The official aim of Dart is to help developers with writing “structured web applications” – which sounds like a euphemism for “[eventually] replace JavaScript” — to some at least. I’m going to explore that loaded sentence (or go to tl;dr).

Origins of Dart at Google

Google and the Web are inseparable. To many, the Web would pretty much cease to be useful without Google Search and Gmail. Google pioneered, or at least popularised, the foundations of modern web application development, namely AJAX. When Google Maps was released it was a breath of fresh air in its product niche and an astounding achievement in programming and UX. The thing to note here is the J in AJAX, which stands for JavaScript. Having wedded itself to the Web, Google has had to wrestle with this piece of technology since the beginning of its forays into anything more complicated that a search box and a list of results.

I doubt a Google spokesperson has ever come out to say it, but it’s clear that Google staff are no fans of JavaScript. Six years ago, they got sick of figuring out the look and feel of things and started work on GWT. A few years later they got fed up of the performance of JavaScript runtimes and wrote the source-to-source Closure Compiler/Optimiser for JavaScript and started work on their own V8 JavaScript Engine which powers Google Chrome (and notably also NodeJS). All in all, a business expense of at least tens of millions of dollars, not to mention the headaches and opportunity cost. Of course, Google has to go all this effort because of the scale of their JavaScript codebase, which makes any criticism from small- to medium-sized development teams utterly moot when they say “we’ve never had a problem with normal JavaScript” — yes, of course you haven’t, because you’re not juggling a web application product line which includes Gmail and Google Docs.

This leaked email from Googler and ECMAScript committee member Mark Miller emerged last year. It provides an insight into Google’s view of JavaScript as a bottleneck in their efforts to build products that compete with native applications. It’s a long read but the gist of is that Google can either wait for JavaScript to evolve slowly, and/or take action and write its own better JavaScript, codenamed “Dash” in the email. The main goals of the new language are listed as performance, developer usability (including familiarity) and improved tooling (a.k.a. clearer code structuring and packaging), which no-one will deny are lacking in JavaScript.

So they did just that. Sort of.

Dear Google, Public Relations != Developer Relations

<rant>

Google suffers from NIH Syndrome: it does not take from the outside world, preferring to build its tools from scratch, and anything it produces it does so mainly for consumption by the thousands of people it employs (this manifests itself in things like their approach to Platform development, too). Don’t let the odd open-sourced project fool you.

In the case of Dart (not the first Google-made langauge) they may have hyped up its announcement, but they clearly have no intention of letting programmers — the only people who care — actually experiment with the new language yet. When you go to Dart’s code repository, there is little effort made to make it simple for you build and use anything. Maybe Dart is just not ready for too much public airing, but that means they should have left its unveiling until it was. Google is not providing a pre-built compiler or VM binary for Dart, and their build instructions are just about tedious enough that I’d rather not waste my time. If git clone and make install are good enough for many a large project, why am I being instructed to install and use a Google-specific tool to merely fetch code?! No thanks.

</rant>

What’s Dart Like?

Apart from syntax and code samples that run in the browser, there isn’t much to go on. I quite like this article that says Dart is to JavaScript what C# is to C++: basically cleaning up some of the mess. Here’s a summary of what I think are the main features to give you a feel.

Key Language Features

Purely class-based

The class and interface concepts from Java are brought into Dart, almost exactly, with multiple inheritance being achieved through implementing several interfaces. The “purity” here refers to the idea of everything-has-a-class (or everything-is-an-object), which is lacking in both Java and JavaScript, and can only be a good thing. This applies to functions, of course, which makes closures possible in the same way as JavaScript. Compared to JavaScript’s prototype-based model of OOP this class-based approach makes writing Dart code less crufty, more familiar to the average programmer, and will make tooling and dealing with hierarchy of the code simpler or at least easier to adapt from existing tools.

I suspect this model improves the run-time performance of Dart code compared to JavaScript, too, since JavaScript’s prototypal inheritance and functions-as-objects idiom are expensive (objects are cloned or recreated instead of referenced or re-used), at least without a good JIT compiler (but don’t hold me to that).

Optional typing

This is one of the more baffling features for me. You could write Dart code without any consideration for variable types, but you could also annotate your variables with types, like String or any class you’ve defined. The baffling nature of this is that the annotation is just that, an annotation: it makes no difference to how your code works, other than the compiler giving you a warning if you’ve misused the variable (e.g. tried to assign a number to a String variable). The code will still compile and run.

The justification for this feature is that it provides “documentation” and aids debugging and static build tools during development. I’m not convinced by this half-feature. Perhaps the makers didn’t want to put off web developers with scary strong typing or the goal of making Dart compilable to JavaScript was an obstacle. The official advice is “use types where they make sense”. To me, that advice doesn’t make sense.

Structure and isolation

One of the big practical difference between JavaScript and Dart is that when embedded in HTML, each script tag containing Dart code is isolated and can not access other scripts directly, i.e. there is no per-page global namespace. Also, Dart code isn’t simply run when it is encountered but a main() function needs to be included as the entry point into each piece of code. In theory, the designers intend each portion of code, or isolate, to be able to run in its own thread, but such multi-threading support is non-existent in browsers.

This is where the “structured” nature of Dart is most obvious and I personally like it compared to JavaScript, but those used to the way JavaScript behaves will resist it.

In the language specification, there is some detail about the concurrency model of Dart, which involves these isolates behaving like actors which perform local computation and then communicate via message-passing. I didn’t spend much time trying to understand these, but this (rather negative) write-up has an explanation.

Why you won’t use Dart

Firstly, there is obviously no practical implementation for developing or deploying Dart code, so don’t waste your time on it yet. Even the Google Chrome team aren’t 100% on whether and when they will implement a Dart runtime, let alone other browser vendors.

Secondly, although all concepts used in Dart should be familiar, it is still a paradigm shift for web developers and you can get by just fine with JavaScript. This extends to the way Dart handles DOM events which is something many developers take some time to completely absorb even in JavaScript with all the online documentation available, let alone with Dart’s event model.

Thirdly, if you really don’t want to write in JavaScript, and you don’t have Google’s NIH Syndrome, you already have access to many well-established alternatives. I have written a non-trivial amount of code in CoffeeScript, which is a pleasure to use, and look forward to playing more with ClojureScript, which is elegant but still immature. Of course, JavaScript isn’t just “assembly language for the Web” which can be ignored and you still need to fully understand its intricacies before trying to work around it.

tl;dr

This chap on StackOverflow got it right, in my opinion: Learn JavaScript, use CoffeeScript, check out Dart.

Overall it was an excellent conference with a great group of attendees. The numerous inter-session conversations I had with fellow attendees were as enlightening as the sessions themselves.

Here are my thoughts about the sessions that I attended.

Monday 13th June

HTML5 Boot Camp

This session by Laurie Young and Ismael Celis was one of several focussing on the hot topics of the moment, HTML5 and JavaScript. After a brief introduction to HTML5 and what it provides we got cracking with the exercises.

Working in small groups we were asked to implement a web page that allowed the user to drag an image from the file system into it. The next task was to upgrade it to get the image(s) to persist when the user refreshes the page using local storage. Finally we were asked to use a web socket to send the image to a pre built server which would then distribute it to everyone else viewing the same web page.

There was a reasonably large range of JavaScript experience within the session, however I think most people managed to complete the exercises. It provided a great introduction to several of the most universally helpful HTML5 JavaScript APIs.

Improving Trust in Teams

Rachel Davies’ session looked at how to improve trust in teams.

Split into groups of four we were encouraged to discuss our various experiences of both low and high trust scenarios. Perhaps unsurprisingly most of the scenarios that were highlighted involved low trust. Once each of us had relayed our own trust stories within our groups we were invited to share the most interesting ones with the wider audience.

Afterwards we resumed working in our groups to draw force field charts that highlight things that we believed help to improve trust and those things that hinder it. We drew these up on a flip charts and again shared our thoughts with everyone attending the session.

Finally we looked at one of the forces behind improving trust and what we might do to nurture it.

It was an enjoyable session that has really made me start to realise that there are perhaps more facets to trust than I had previously considered.

At the Extremities of Extreme

This catchily titled session by Julian Fitzell and Jason Ayers was a fascinating introduction to the theory behind wolf pack programming. This technique takes the familiar pair programming, but turns it up a notch, taking collaboration to a new extreme.

I can barely do the concept justice here, but my simple interpretation is that with adequate tool support developers can collaborate without having to be sat around the same PC if they work on precisely the same instance of the code. The tools would allow a developer to see which functions/methods the other people working on the code base were looking at or editing. This allows pair programming to be followed where appropriate, but the navigator can slip off to do some driving if they think of something that will help to remove a block that they have observed that the driver is about to encounter. They also advocated judicial use of spikes to hunt out the quickest solution to a problem.

They had run an actual wolf pack programming session on Sunday which I am now disappointed that I missed.

At the moment the example sessions they have been running use Smalltalk, however my thoughts are about how we might trial these techniques for JavaScript development.

Invited Rant

John Nolan entertained the conference audience with a rant against the term “software engineering”, specifically that:

Software engineering does not and should not exist

He reaffirmed Kent Beck’s statement that:

Software is software

He conceded that:

Software is like engineering

But saying it is engineering is wrong. Instead he introduced us to a different metaphor:

Software is cooking

The examples he provided were very compelling, although even John conceded that he wouldn’t be changing his business card to read Software Chef just yet.

Tuesday 14th June

Unfortunately I missed most of Tuesday’s event as I was preparing for my presentation the following day, which leads me to…

Wednesday 15th June

Web Apps That Shine

I co-presented this HTML5 focussed session with my colleague Adam Iley. The specific context for it was the features of HTML5 that allow up to build web apps.

We introduced the offline support that is provided by HTML5, including local storage and the application cache. Afterwards the attendees paired off and worked at upgrading a n0tr, simple note taking website, to work offline.

The second section highlighted the tighter integration we can now get between a web app and the device it is running on. On mobile devices access to geolocation, and the device orientation is available, whilst on the desktop we can implement drag and drop both within the web app as well as to and from other applications, including dropping files into the page. Again we asked the pairs to upgrade the n0tr app to use some of these techniques.

We concluded by talking about portability and other concerns for building and releasing web apps. The presentation is available online as are the exercises that we ran.

Invited Rant

Jason Gorman’s rant was titled Slow and Dirty.

It was a thought provoking view on our responsibilities as developers with plenty of statistics to help back up his points. When starting on a new project the features come in thick and fast, however over time productivity starts to plateau. On the 8th major release of a major product (no names mentioned) the cost to write or change a line of code was 20 times as much as it had been initially.

Making our software maintainable is our responsibility, and is not something that we should abandon in our quest to keep adding new features to keep our customers happy. We need to be prepared to pace ourselves for a marathon, not a sprint.

Finally, beware the statistical aberrations that seem to have flouted all of this advice and are major successes nevertheless. Just because your great aunt smoked 60 cigarettes a day and lived to be 103 doesn’t mean that to give yourself the best chance to survive to 103 means that you should smoke 60 a day.

Specification By Example: By Example

The final session I attended was run by Lasse Koskela. Lasse asked us to split up into groups of three, then handed out an index card to each group that specified a requirement for a particular software system. Within our groups we needed to capture the specification by writing or drawing out the various examples we could think of.

My group was asked to produce the specification for an email verification system. We sketched out the interaction between the server and the user, defining 5 different scenarios that we could think of, one of which covered a hacker.

Two members of each group were asked to switch over with people from other groups. The remaining person on each group was asked to explain the examples they had drawn up to the new members, and we were asked what improvements could be made.

Finally everyone changed groups again, moving onto a requirement that none of us had worked on before. We are asked to review what had already been done, then start afresh and come up with our own examples.

Overall the session went very well and it was interesting to see how much would be achieved in a very short period of time by sketching out the examples with tight collaboration between all the members of the group. There was a warning flag though that the lifespan of the examples that we created was limited as there was contextual information that was only available to those who were involved in the conversations surrounding the creation of the examples – a little more structure might be necessary if these are to persist over a long period of time. Nevertheless this was a technique that I’ll be trying out at some point soon.

It seems like a slightly crazy mix of backwards compatibility and some quite cool new ideas that are meant to be suitable for keyboard/mouse based systems as well as touch based. What is interesting though is the mention that the new style tiles and apps are built on a new platform using HTML5 and JavaScript. It seems unclear what the future of Silverlight is, but what is clear is that Microsoft is definitely embracing the HTML5 world.

This can only be good for HTML5 development and tools.

Embarking on developing a web application can be bewildering: there’s no shortage of JavaScript toolkits of all different shapes and sizes but there’s no guiding light.  Microsoft and Adobe, by contrast, offer a much greater degree of comfort with their methodologies, libraries and tool support – but only if you are willing to restrict your application to running on their respective platforms.

There are some great JavaScript tools out there, however, and this article attempts to navigate through the maze of toolkits to assist making technology choices when building a web application.

User Experience is Paramount

The GUI is the most prominent part of the application, and is usually the most expensive to develop.  An important part of the UX rests on your choice of widgets and how customisable they are.  You should choose widgets that will give you the best possible starting point; if you can’t find what you want, you will have to consider composing your own.

Most widget toolkits are general purpose, but more sophisticated widgets are emerging.  ExtJS, jQuery and Dojo provide widgets ranging from grids to email suites.  Caplin specifically targets widgets for financial sector clients that are oriented to financial domain specific objects and delivering real-time prices to the screen.

Widgets are typically customised using templates, configuration and programatically.  Templating is by far the quickest approach, and this has been well proven with Silverlight’s XAML.  HTML also works very well as a view templating language, and HTML5’s data attributes can be used to further this approach.  Caplin has developed some easy-to-use frameworks that use HTML/CSS templating to build new widgets quickly.

UX does not stop at widget selection though: how they interact is also crucial.  User workflow across all the widgets in the application needs to be implemented with due respect to the overall application structure.

Structural Patterns

Most GUIs conform to some kind of structural pattern.   Passive View, Presenter First and Presentation Model (aka MVVM) are all good design approaches.  There’s little merit in debating which precise pattern is “best” – if it were that simple then Martin Fowler would have told us the answer by now.  The most important thing is that you should be able to build your widgets with the appropriate degree of composability, isolation and testability.

All MVC-derivatives leverage the observer pattern, and it’s crucial to choose an implementation to support the right level of decoupling (such as pub/sub).  For example, a web application typically comprises a layout manager which houses its widgets and manages screen real estate, and you will need to consider how your component-level widgets will communicate with application-level code.

You may decide to use additional utilities to implement structural patterns in your application, but you need to proceed with caution.

Toolkit Selection

JavaScript toolkits come in two categories: widgets and utilities.  Utilities such as prototype.js and backbone.js can serve as the basis for building your own widgets, but that starting point doesn’t suit everyone.

The lack of JavaScript standards means that, invariably, widget toolkits come with their own JavaScript extensions that are both integral to the widgets themselves and also feature in the API.  Combining widgets from more than one toolkit requires special care, and each toolkit brings its own idiosyncratic syntax.  For example, jQuery has its own $() selector syntax, and underscore.js which (as suggested by its name) entirely revolves around the ‘_’ symbol.  This can be quite distracting when trying to standardise development across an enterprise.

For each toolkit you adopt, ensure that the benefits outweigh the incremental burden that you are taking on, and ensure that you are happy to embrace its idioms and syntax.

At Caplin we’ve made enthusiastic use of toolkits such as ExtJS, jQuery and Emprise charting, but have found it necessary to build our own frameworks for layout management, real-time grids and templating/data-binding.  The last one of these has proved so useful that we are planning to open source this in the near future.

Fiddler Customize Rules option

static function OnBeforeResponse(oSession: Session)
{
	oSession.oResponse.headers.Add("Access-Control-Allow-Origin", "*");
}

static function OnBeforeResponse(oSession: Session)
{
	if (oSession.HostNameIs("www.leggetter.co.uk"))
	{
		oSession.oResponse.headers.Add("Access-Control-Allow-Origin", "*");
	}
}

HTTP/1.1 200 OK
Connection: close
Date: Fri, 19 Mar 2010 11:04:51 GMT
Server: Microsoft-IIS/6.0
Content-Type: text/html; charset=utf-8
Expires: Fri, 19 Mar 2010 11:03:51 GMT
Cache-Control: no-cache
Pragma: no-cache
Access-Control-Allow-Origin: *

Rumour on the street has it that, finally, the investment banks are going to start abandoning IE6. Barclays are allegedly going to do an enterprise-wide rollout of IE8 in Q2 of this year (put back from Q3 last year). Even more surprising (and impressive) is a rumour that Standard Bank of South Africa are going to ditch Microsoft browsers completely and move to Chrome for their corporate standard!

The evolution of software practices ebbs and flows over time, and it seems that Hungarian notation is currently out of favour. This is especially apparent with some of the new developers that have joined the team here at Caplin. One of the first questions they ask is often about the naming convention that we use.

Hungarian Notation is useful in JavaScript

I believe that an untyped language like JavaScript benefits greatly from Hungarian notation, allowing the intended type of a variable to be determined from its name. If I am debugging some code that is going wrong I can quickly check that the data associated with that variable is of the expected type. Also if I am writing new code I know which methods I can invoke on the variable.

The scoping within JavaScript is strange too. If a developer forgets to add a var declaration for a particular local variable within a function then the variable is added to the global scope, with the potential of nasty unforeseen side effects.

Caplin’s JavaScript Naming Convention

At Caplin, we have two components that are added to the start of the names of our JavaScript variables: one represents the type, and the other represents the scope.

Type Prefix

• b – a Boolean variable. We only expect it to have a value true or false. For example bIsVisible.
• e – a DOM element. Provided its not null we expect to be able to access childNodes and so on. For example eGridBody.
• f – a function pointer. Typically this will be invoked at some stage in the future. For example fCallback.
• m – a map. For example mPropertyNamesToValues.
• n – number, either a integer or a float. For example nColumnIndex.
• o – an object. We don’t try to differentiate between all the different object types we have defined within our code with dozens of different prefixes, this would get too complicated to remember. Typically we use JsDoc to identify the types, if the scope of a variable is not small enough to see its type. For example oObservable.
• p – an array. This should really use an a prefix, however this is a throw back to the original Hungarian notation from my C++ days where an array was just a pointer. For example pQueue.
• s – a string. Provided its not null we expect to be able to invoke methods like match(). For example sUsername.
• v – a variant, where various different types might be allowed. A typical example of where this might be used is a generic debugging method that is happy to take any type of argument and output it to a log. For example vValueToLog.

Scope Prefix

• m_ – private member variable. Although there are techniques to hide member variables there are performance costs associated with them. The m_ prefix is a gentle reminder that only the class the member variable is defined in should be accessing it. In fact, when the code is obfuscated these private members may also be obfuscated since they aren’t part of of the public interface of the class. For example this.m_sSubject.
• g_ – global variable. These are used sparingly. If a variable has a value to assigned to it within a method but does not have a g_ prefix then beware, this is probably a mistake and we now have an unexpected side effect. For example g_bIsDevelopment.
• All other variables, such as local variables or function arguments, have no scope prefix.

Horses for Courses

To be honest, although I use Hungarian notation throughout all of my JavaScript code, I avoid it altogether when coding in other languages such as Java. The reason for this is simply that Java is a typed language, and I don’t feel that this adds any benefit, however Joel Spolsky makes a great case for using it, even in the case of a typed language, in his blog Making Wrong Code Look Wrong.

One of the main reasons we were keen to adopt JsUnit five years ago was its similarity to JUnit 3. Back then our developers had been using JUnit for a few years, and familiarity of the JsUnit API meant that we could immediately start writing tests. Unfortunately the old adage “familiarity breeds contempt” reared its ugly head, and we discovered that our main issue with JsUnit were the occasional, very subtle, differences between it and JUnit. The logic for a test that works in JUnit might not work in JsUnit.

An example of this is highlighted by the test that would be written for the example JobQueue class defined below. Its purpose is to queue JavaScript functions for invocation at some point in the future. The addJob() method employs the fast-fail philosophy to throw an exception if the fJobToExecuteLater argument is null or undefined, rather than fail later on when an attempt is made to execute it.

function JobQueue()
{
   this.m_pQueue = [];
}

JobQueue.prototype.addJob = function(fJobToExecuteLater)
{
   if (fJobToExecuteLater == null) // this is true if it is undefined
   {
      throw new Error("JobQueue.addJob: Job cannot be null or undefined");
   }
   this.m_pQueue.push(fJobToExecuteLater);
};

// other methods...

The JsUnit test written to verify the behaviour would look something like:

var g_oJobQueue = null;

function setUp()
{
   g_oJobQueue= new JobQueue();
}

function testAddJobThrowsExceptionIfJobToExecuteLaterIsNull()
{
   try
   {
      g_oJobQueue.addJob(null);
      fail("Unexpected success invoking addJob() with null job");
   }
   catch (e)
   {
      // expected exception
   }
}

Casting a casual (JUnit 3) glance over this test, everything looks to be in order. The test checks that an exception is thrown if the addJob() method is passed a null argument and remembers to invoke fail() if the exception isn’t thrown. This latter point is important since if it is omitted then the test will pass regardless of whether an exception is thrown or not.

The equivalent test in Java would work without any problems, however in JavaScript there is a hidden bug within this test logic. Within JUnit the fail() method throws a subclass of Error, which won’t be caught by a catch block expecting an Exception. Unfortunately JavaScript has no such distinctions between errors and exceptions, and the call to fail() throws an exception which will be caught within the catch block.

Solutions to the Exception expection issue

There are two approaches that we have taken to resolving this issue.

1. We extended the JsUnit API to add a new assertion method, assertFails(), that encapsulates the logic necessary to ensure that an exception is thrown, and fail if it hasn’t. It takes three arguments:

i. A comment to output if the test fails
ii. A reference to the function to invoke which is expected to throw an exception, if this doesn’t throw an exception then the assertion fails
iii. The exception that is expected to be thrown (optional, if omitted the assertion just ensures that an exception is thrown)

Using the addJob() test can be rewritten to use assertFails():

function testAddJobThrowsExceptionIfJobToExecuteLaterIsNull()
{
   assertFails("Unexpected success invoking addJob() with null job",
                   function() {
                      g_oJobQueue.addJob(null);
                   });
}

2. We verify that the exception that is thrown is the one that we expect. This particular approach has been met with trepidation from some of our developers who are concerned that verification of exceptions will lead to fragile test code, prone to break if someone changes the text within an exception (presumably to make it more helpful). There are certainly pros and cons to this, however in my experience it is rare that changes are made to the descriptions passed into the exceptions thrown by our code, and the overhead of these verifications is negligible.

The original test code can be rewritten to assert that the exception is the expected one:

function testAddJobThrowsExceptionIfJobToExecuteLaterIsNull()
{
   try
   {
      g_oJobQueue.addJob(null);
      fail("Unexpected success invoking addJob() with null job");
   }
   catch (e)
   {
      var oExpectedException =
               new Error("JobQueue.addJob: Job cannot be null or undefined");
      assertEquals(oExpectedException.toString(), e.toString());
   }
}

Alternatively assertFails() can be used as such:

function testAddJobThrowsExceptionIfJobToExecuteLaterIsNull()
{
   assertFails("Unexpected success invoking addJob() with null job",
                   function() {
                      g_oJobQueue.addJob(null);
                   },
                   new Error("JobQueue.addJob: Job cannot be null or undefined"));
}

Conclusion

This article is not intended to be a criticism of JsUnit. The issue highlighted here is simply due to a difference between the JavaScript and Java languages with respect to their exception handling which led to some tests being marked as successful when they shouldn’t. Over the last five years I have found that JsUnit has been reliable unit testing framework and, combined with Mock4JS and a TDD philosophy, it can form the solid foundations from which enterprise level JavaScript APIs and applications can be built.

Since we made our decision to use JsUnit we have never really looked back. So far it has managed to do everything that we have needed from it. However if you are looking into unit testing your JavaScript, then this list of JavaScript unit testing frameworks should be a good starting point to uncover one that is suitable for you. Just remember, it doesn’t matter which framework you choose, you need to be aware of the subtle nuisances of JavaScript, compared to any other languages you might be familiar with, to avoid the sort of trap that we fell into.