Author's note: this was originally intended to be one in a series, but what with WinJS being terrible, I decided to abandon the platform. Honestly, avoid it if you can. Since this was written, I've decided to avoid using libraries I can't do pull requests on as much as possible.
For the past couple of months, I've been working on/off on a Windows 8 app called Cargo. It's a client for the Pocket service for "read later" bookmarking, similar to Instapaper or Readability.
But, hey, it seems to be working well enough. And while I would never write an HTML5/JS app for a traditional desktop platform, with Microsoft's Metro interface (or "New Design Interface," or "Windows 8 Interface," or whatever they're calling it these days - even MSDN is inconsistent!), it's actually a viable option. They provide a ton of good APIs for integrating with devices, including various views with great touch support.
This series of blog posts are the result of my exploration into creating a WinJS app. Rather than simply go over the various aspects of WinJS, I'll show how to use them to create an MVC structure, similar to an app created using a framework like Backbone.js.
(an aside: there are many people who forego WinJS as much as possible, instead preferring to use libraries like Backbone, Angular, or Knockout. This is not necessarily a bad idea - I've heard Knockout integrates particularly well - but I'll focus purely on the WinJS APIs here.)
Throughout this series, I'm going to have a lot of major issues with WinJS. It's a frustrating library - there's a lot of great ideas there, and some are implemented well, but many are just half-baked. The worst is that the library isn't open source, unlike just about every other JS library you'll ever use, so there's no way to just submit a pull request to fix it!
<script>block at the top of your entry page(s)
Thankfully, there's only one situation where WinJS actually requires you to use their Namespaces - defining template converters - and it works well enough there, regardless of whether you've used them elsewhere in the app.
RequireJS is simple to implement:
default.jsfile Visual Studio generates for you when you create a new WinJS project as an entry point
default.jsfile in your entry point page, after RequireJS itself
default.js, call "main" modules depending on the activation state. For example, if an app is being opened, you would run a "main" module; if it's being restored from suspension; you would run a "restore" module; and if it's being called from a share target, you could run a "share" module.
You should probably read up on the RequireJS API before reading further in this tutorial, but it's not necessary. Keep it around for reference, though!
First, add a RequireJS config file to your project:
This file just sets the root of your RequireJS modules to
/js, which makes your paths easier to write, but you can add all sorts of rules (such as shims) to this file if needed.
index.html file. Rather than have a giant stack of
<script> tags, just include
require.js (with your
data-main attribute being set to your config file) and
Finally, update your
default.js. This file is used as an entry point for your app, and essentially will run different modules based on your app's initial state. For example, this file will run different modules based on if it's being launched the first time, restored from suspension, being used as a share target, or being suspended:
Once you have RequireJS set up, dependency management and creating modular applications is a breeze. Want to create a new model class? Just create
/js/app/models/SomeModel.js that returns a
SomeModel prototype, include it in your dependencies, and create it with
new SomeModel(). Of course, we'll get to creating models (and an MVC architecture) in the future.
All of these modules will simply take the form:
Ultimately, you end up writing code similar to the module pattern WinJS encourages, but with the bonus of dependency management and loading JS files only when needed.
Next, I'll cover some of the basics WinJS includes, including Classes, Mixins, and Promises. These will be the basis that we build an MVC structure on in future sections. Look for that post next week-ish.