For some, the Windows Library for JavaScript, or WinJS, seems to take on an aura of mystique, as if it’s something really special or privileged, or something that is absolutely required by a Windows Store App.

The truth is that WinJS is actually just a JavaScript library, like other libraries you might employ. It does have one unique privilege in that it’s obtained automatically via the Windows Store when a dependent app is installed, and is also serviced through the Store.

But otherwise, it’s just a bunch of JavaScript code that makes writing a Windows Store app in JavaScript a whole lot easier, but isn’t absolutely required. For example, WinJS contains the HTML/CSS/JS implementation of those standard Windows 8 controls that aren’t already covered by HTML5. These include AppBar, DatePicker, FlipView, Flyout, ListView, Rating, SemanticZoom, TimePicker, ToggleSwitch, Tooltip, and ViewBox. You can roll your own versions of these if you want, but I’d think you’d want to spend time on those things that make your app really special.

Similarly, WinJS contains an animations library with the Windows 8 personality built right it…all this is implemented on CSS animations and transitions, so you can do it all manually, but what’s the point?

WinJS contains a bunch of utilities that simplify certain tasks in JavaScript–and many of these are pure JS and have nothing to do, really, with Windows itself. For example, WinJS.Namespace.define and WinJS.Class.define provide some built-in ways to deal with module and class patterns, which I find convenient. WinJS.Binding does the same for data binding, and WinJS.Navigation and WinJS.UI.Pages (along with WinJS.UI.Fragments) does the same for implementing a page navigation (that is, DOM-replacement) mechanism so you maintain the script context within an app.

Then there’s the WinJS.Application object that simplifies your interactions with the core Windows structures provided through WinRT–basically giving you an easier way to keep track of the details. All of this is stuff you can again write yourself, but the WinJS team decided that you’d probably like to have something written for you!

Consider something like promises as well. A promise is basically an object that has .then and .done methods on it. Even if you didn’t use WinJS, you’d get promise objects back from async WinRT APIs thanks to the JavaScript language projection. What the code in WinJS.Promises does, then, is give you a set of utilities for doing more with these basic promises, like joining them or creating new ones from scratch. Again, all stuff you might end up writing on your own, just like the wrapper for XmlHttpRequests in WinJS.xhr that makes that async JS API look like a promise such that it can be easily integrated in with other async code using WinRT.

The short of it is that WinJS is a library full of all kinds of stuff for which people inside Microsoft figured a standard implementation would be really, really helpful.

Now along these lines, questions about the nature of WinJS sometimes arise in the context of whether it’s possible to write a Windows Store app using HTML, CSS, and JavaScript and have that app run within other browsers or other frameworks that also use these standards.

You can certainly write code that can be used in both an app and a site, and they can use common services, but an app written in HTML, CSS, and JavaScript has specific structures that are distinctly different from the structure of a web site/web app.

In particular, an app ties into various platform features such as the WinRT API, many parts of WinJS, and the fact that it’s running inside the WWAHost process instead of a browser. Apps are also generally written in an AJAX style (a single HTML page wherein parts of the DOM are swapped in and out) rather than using <a> navigation (which is again why WinJS provides many utilities here).

So again if you modularize your app code to separate pure app logic that can run in a browser (and doesn’t have any Windows-specific dependencies) from that which is platform-specific, then you can achieve some amount of code-sharing. But those apps won’t just run in a browser. They aren’t web apps: they are Windows Store apps that just so happen to be written with the same technologies as web apps.

Is it possible to use WinJS code in a web app, then? Originally, WinJS wasn’t licensed for this purpose, but as of April 2014, WinJS is an open source project so that you can use it anywhere. See http://try.buildwinjs.com/. It’s important to note that WinJS will take advantage of WinRT APIs when they’re available, but it was written to adapt when WinRT isn’t there.

In short, WinJS is a very useful library with many different controls and other capabilities, and now that it’s open source it’s really helpful for creating a Windows-like experience in apps and on the web.


2 Comments

  1. Mark Sampson
    Posted January 30, 2013 at 2:08 pm | Permalink

    There’s also this as an option for WinJS developers: http://www.bluesky.io. Its a complete rewrite of WinJS for the web. It’s in beta as of now (1/30/13), but otherwise pretty full featured.

  2. Posted January 30, 2013 at 5:00 pm | Permalink

    Thanks for sharing–very cool to see third-party work like this going on…