Developing Apps for Windows 8 - My Experiences and Opinions

Disclaimer: The views expressed in this post are my own and do not reflect any opinions of my employer. The app was written using publicly available resources as an Independent developer. 

A few posts ago, I had written about the TrialTool app for Windows 8. TrialTool is a web based application that illustrates the capabilities of various Javascript APIs. It is like an API playground that lets you view, modify and run examples and this version of TrialTool specifically illustrates the various Windows 8 APIs.

1. Background
The app was developed on Windows 8 Developer Preview with Visual Studio 11 Express. The entire application was written using HTML5, CSS and Javascripht. The tool does not exhaustively cover all APIs yet, but the APIs used are a good representative of the programming model in Windows 8.

2. Development Environment
My primary IDE is Eclipse or Cloud9 and this was actually the first time I have used Visual Studio exclusively for an end to end project.
The application starts from choosing a pre-defined project type or a simple blank JS template in Visual Studio. The templates do a good job of creating the skeleton and filling in the boiler plate code. As with any skeletons, it may be hard to navigate the multiple files created as a part of the template for a newbie. Once you know your way around the files and the parts to edit, the templates are good. Unfortunately, looks like Visual Studio is the only option for now as I was not able to find any command line utilities that I could use with Eclipse or Notepad++ to build, package or deploy the project.

3. Writing Code
Starting with a blank project is similar to writing a web page from scratch. Using a template however starts us off with the Metro Style UI. TrialTool used the grid layout template that starts with an "index" page that displays a list of items. Each item can be clicked to take us to a "details" page.
The Javascript files created by the template recommend using strict mode.

3.1 Single Page application
The app created is inherently an equivalent of one-page website. Navigation from the "index" page to a "details" page results in the details being loaded as a DOM fragment. Loading and unloading events give us control over the content to be displayed on each action. The WinJS module defines events that let us access the activate or DOM fragment load events for navigation in addition to events for layout changes (portrait to landscape mode for tablets, re-size, etc. )
I noticed that the by default, files of type HTML, CSS and JS had a directory each. I would prefer to group files by modules instead of file type; file types are distinguished by their extension anyway.

3.2 CSS Grids
The use of ms-grid to define the metro UI is great. Grid layout for CSS are still in work in progress. Tiles are an prime to the Metro UI and the implementation of ms-grid makes building tiles in Metro UI is a lot easier.
Vendor prefix would be removed in the final version I guess.

3.3 Data Binding
The Templates also have support for data binding. With the data-win-* attributes in a the HTML tags, render views can be defined. These render views can define specific controls (like ListView) and options for these controls. JSON data can be loaded via AJAX and use these "itemRenderers".
The concepts here are very similar to frameworks like Backbone. However, some features like automatically changing the view when data changes, etc needs to explicitly coded unlike backbone. A way to point a itemRenderer to a URL would be even better.
Another feature that I would like to have is the ability to declare formats in the item renderers. Currently, the data from the model can be converted, but that seems to be manual. A data-win-option on individual elements to specify the format would be good.

3.4 Promises
All asynchronous operations (like AJAX, File reading, etc) seem to return promises. This is definitely better for an interactive event driven application. The "async" keywork in C#
is the equivalent.
The documentation for the promised could have been better. Looks like the documentation is written for C# and force fitted to Javascript. For example, in an operation like FilePicker, the return value is a promise. However, to see the actual arguments passed to the promise.then() method, you have to navigate to the "GetResults" method.

4. Windows 8 APIs
The main reason I would write a Windows 8 app (apart from store distribution) would be to use the Windows 8 APIs; otherwise, the app may as well be a web site viewed in the Metro IE.
Working with native Windows 8 APIs in Javascript is no different manipulating DOM using native DOM methods. Popping up a Windows 8 Toast is no different from invoking the native window.alert. Working with native File APIs, or cryptography is also very easy and straight forward.
The documentation on the Windows Runtime APIs is exhaustive but I would would have been more comfortable if they were grouped better and the first list the over high level categories (like Storage) and then you could drill down to understand a specific API (Bulk Access or File properties). This would help since a lot of APIs have common concepts before we look at specific APIs. This was probably why I wrote TrialTool in the first place.
The other issue I found was an example of APIs that require features not present in the Javascript language. For example, reading the contents of a file returns an InputStream that does not seem to show any Javascript API. It is not very clear that DataReader can in fact be used to read the data.
I wish that the APIs converge to become similar to the HTML5 File/Blob APIs.

5. Debugging
Debugging with Visual Studio is so good that you would not really miss Firebug or Web Developer toolbar. From basic features like support for logging to break points or inspecting the HTML source, the debugger is very powerful. I would recommend a dual monitor setup for for a better experience.
One feature that I found missing was a way to profile (like Speed Tracer) the Javascript app for performance issues. Adding to the wishlist would be a way to remotely debug an application (like Opera dragonfly but that is a feature I would like in IE too). Remote debugging may prove useful specially in case of tablets.
The usual annoyance of printing [object] with console.log still exists. It would be even better if we are able to integrate console.log with Windows application or system logs during a production deployment.

6. Packaging and Deployment
Though Visual Studio has a Store menu, looks like the Store is currently not available. The only option available today would be to create a local app. Packaging the app creates an appx file, a bat file and certificate file. Executing the bat file with Admin privileges install the application.

7. Conclusion
For the Web Developers, the option of using HTML/CSS/JS for writing native windows 8 applications is definitely compelling. Existing web development knowledge can be put to use here, but to leverage the full power of the operating system, it is best to familiarize with the APIs that Windows8 provides.
Overall, a great approach in bringing web development to native applications - hope writing Android or iOS apps were this simple for a Web Developer.