Things to improve on Windows 8 JavaScript app development

Since October 2013 my team is working on a JavaScript app for Windows 8. There are good things, and there are bad things. I was asked to give feedback about the bad parts. So here it goes:

Tests

There’s no easy way to run unit tests. We started with node.js, mocking the Windows/WinJS libraries. Later we discovered that a new project inside the same solution can share code. We have a “product-unit-tests” project that imports code from the main project, and executes tests. Using this approach we do not mock Windows libraries, but it has problems. You need to set the unit-test project as default and Run the project, or start it from the command line, which takes around 10 seconds. The node.js entire suite, with double the amount of unit tests, runs in 2.5 seconds.

Making the unit test project work with Jenkins required extra effort, while running tests with node.js was easier due to the already available plugins and parsers.

There’s absolutely no way to automate the app, like Selenium does for browsers. We end up writing a tool named Rainbow Driver that understands the jsonwireprotocol and augmented with specific Windows 8 tasks, such as snap and picker management.

MSDN Samples

The documentation for classes, methods and properties for Windows 8 JavaScript apps is fantastic. But something that ties up these individual pieces of knowledge is hard to find. We used to run the samples available on MSDN but reading its source code to understand what’s happening is painful because the samples are made to be run as an app, with particular setups and information display. Take for example the following code, the sample for programmatically invoking the settings flyout:

//// THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF 
//// ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO 
//// THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A 
//// PARTICULAR PURPOSE. 
//// 
//// Copyright (c) Microsoft Corporation. All rights reserved 
 
(function () { 
    "use strict"; 
    var page = WinJS.UI.Pages.define("/html/5-ProgrammaticInvocation.html", { 
        ready: function (element, options) { 
            document.getElementById("scenario5Add").addEventListener("click", scenario5AddSettingsFlyout, false); 
            document.getElementById("scenario5Show").addEventListener("click", scenario5ShowSettingsFlyout, false); 
 
            // clear out the current on settings handler to ensure scenarios are atomic 
            WinJS.Application.onsettings = null; 
 
            // Display invocation instructions in the SDK sample output region 
            WinJS.log && WinJS.log("To show the settings charm, invoke the charm bar by swiping your finger on the right edge of the screen or bringing your mouse to the lower-right corner of the screen, then select Settings. Or you can just press Windows logo + i. To dismiss the settings charm, tap in the application, swipe a screen edge, right click, invoke another charm or application.", "sample", "status"); 
        } 
    }); 
 
    function scenario5AddSettingsFlyout() { 
        WinJS.Application.onsettings = function (e) { 
            e.detail.applicationcommands = { "defaults": { title: "Defaults", href: "/html/5-SettingsFlyout-Settings.html" } }; 
            WinJS.UI.SettingsFlyout.populateSettings(e); 
        }; 
        // Make sure the following is called after the DOM has initialized. Typically this would be part of app initialization 
        WinJS.Application.start(); 
 
        // Display a status message in the SDK sample output region 
        WinJS.log && WinJS.log("Defaults settings flyout added from 5-SettingsFlyout-Settings.html", "samples", "status"); 
    } 
 
    function scenario5ShowSettingsFlyout() { 
        WinJS.UI.SettingsFlyout.showSettings("defaults", "/html/5-SettingsFlyout-Settings.html"); 
 
        // Display a status message in the SDK sample output region 
        WinJS.log && WinJS.log("Defaults settings flyout showing", "samples", "status"); 
    } 
})(); 

41 lines, but only 5 of them are related to what we are trying to learn.

Slow Visual Studio feedback loop

The time it takes to build/deploy/open an application and check the effect of a code change is longer than the team is used to. And it’s getting worse. We have multiple projects, BeforeBuild targets, translations, etc… Daily operations on the environment do not feel as snappy as we are used to.