January 2014

Volume 29 Number 1

Editor's Note : WinJS Takes the Next Step

Michael Desmond | January 2014

We recently surveyed MSDN Magazine readers and found that, with the exception of C#, more companies report working with JavaScript than any other programming language—more than Java, more than C/C++, more than Visual Basic. So it should come as no surprise that this month’s issue focuses on JavaScript development for Windows Runtime.

In his lead feature, “Build More Efficient Windows Store Apps Using JavaScript: Error Handling,” Eric Schmidt dives into some fundamental concepts of the Windows Library for JavaScript (WinJS), including promises, asynchronous debugging, and error handling. As Schmidt notes in an interview, the tooling and capabilities of WinJS differ from JavaScript in that the environment is tailored for full-fledged app development, rather than for Web sites. And these differences are important to understand when ensuring that flaws in code and logic are properly handled.

Many of the techniques Schmidt explores in this month’s feature are present in the initial version of Windows 8 and WinJS, but Schmidt says many developers are unclear on how the techniques work and relate to each other. He wrote this month’s article with the idea of explaining “how the entire package of error-handling works together from a top-down, holistic perspective.”

For instance, Schmidt describes the JavaScript window.onerror event as “the catchall for error handling” for Web apps. Windows Store apps built using WinJS, however, leverage both window.onerror and the WinJS.Application.onerror event handler, which catches additional events like platform-specific errors and promises that error out. Schmidt also urges developers to consider moving to Visual Studio 2013, which delivers key tooling improvements, including the ability to track down errors within chains of asynchronous calls—an important capability given that WinJS apps frequently chain promises to each other.

“When one of those promises errors out, you either need to have an onError parameter for each promise in the chain, or you need to track down the error starting from the last promise in the chain,” explains Schmidt, who says both approaches are time consuming. “The Tasks pane, which has been extended to encompass JavaScript code in Visual Studio 2013, really helps developers track down those errors in their code,” he notes.

The latest version of WinJS and its attendant tooling deliver what Schmidt describes as “ready to go” templates and controls that help streamline development. The updates also deliver significant performance improvements and streamlined WinJS app development.

“We provided new tools in Visual Studio 2013 for measuring HTML UI responsiveness, JavaScript memory usage, JavaScript function timing and asynchronous debugging,” Schmidt says. “In the platform, we improved the performance of some of our existing controls—for example, ListView—with APIs like the Dispose pattern and the Scheduler, as well as provided new controls that are better suited for specific tasks—for example, the Repeater control.”

Speaking of performance improvements, next month Schmidt will publish a follow-on article focused specifically on performance issues. What advice does he have for developers struggling to ensure that their WinJS applications are performant?

“The No. 1 thing I’d recommend is to really use the platform. Any retained-mode system—whether it’s HTML or XAML or PDF or you name it—has certain sets of capabilities that are natively implemented and highly optimized within it. In as much as your app code and script calls into and leverages those capabilities, the better performance you’ll get,” Schmidt says. He adds that the latest version of WinJS pushes more of the features lower down into the implementation, where they can be optimized for best performance.

Are you working with WinJS? If so, I’d love to hear about your experience. E-mail me at mmeditor@microsoft.com.

Michael Desmond is the Editor-in-Chief of MSDN Magazine