Once you have become familiar with WinJS app development basics, the next thing to do is run and debug your app, test it out, and see what the new IDE and tools can do. Debugging is a great way to manually verify the flow of your app, and when writing WinJS code, debugging sessions require the Windows Simulator (and of course, the built-in VS debugging tools).
Introducing the Windows Simulator
The Windows Simulator ships as part of Visual Studio 2012 on Windows 8. The Windows Simulator is a remote desktop session into your local machine, for the purpose of debugging apps and testing hardware features. Some features might not be available on your host development machine, such as an accelerometer, Geolocation, or touch screen, and debugging with the simulator allows you to test them anyway.
Being an RDP session is what makes it a simulator rather than an emulator. Additionally, changing operating system settings, or running code that modifies the OS in the simulator also modifies your host OS. Only one instance of the Simulator is allowed to run at a time, and multiple instances of Visual Studio and/or Blend for Visual Studio share the only instance of the Windows Simulator. This also means that you cannot run the Simulator inside the Simulator.
Because Windows 8 Metro style apps run in immersive mode (full screen) or snapped view, it is difficult to debug them without a simulator, although multiple monitors can help make full screen debugging easier. Controlling suspend and resume events in the Simulator is far easier than when running in immersive mode.
The simulator lives at C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Simulator\Microsoft.Windows.Simulator.exe; however, it is part of Visual Studio so you can access it from the standard toolbar.
The customary F5/Ctrl + F5 keyboard shortcuts map to whatever option (i.e., Simulator, Local, or Remote) you choose. Alternatively, you can access these same settings from the Debug->App Properties menu option.
The Simulator allows you to test hardware specific features by the many options on the toolbar located on its right side.
The Simulator’s toolbar, magnified with descriptions:
There are many hardware specific features such as location, rotation, or touch, that are not available on many of today’s laptops/desktops, but you still need to ensure they work. The simulator is the best way to do so, short of owning one of every device known to earth (this also makes the Simulator cheaper). Of course, before deploying your app to the Window Store, be sure to test your app on as many physical devices as possible.
The DOM Explorer
Most of the popular web browsers contain debugging tools usually accessible via the F12 key. Web developers are accustomed to these tools for debugging, inspecting, and changing code during runtime. Since Metro style apps are HTML5/JS apps, it is necessary to have comparable debugging tools available from within the Visual Studio IDE, and the DOM Explorer is one such tool.
The DOM Explorer allows you to inspect and modify the runtime DOM of your app. To open the DOM Explorer you must enter a debugging session then choose Debug->Windows->DOM Explorer
During a debugging session, the DOM Explorer shows the runtime DOM in the left side pane, and the options for the selected DOM node(s) on the right: Style, Trace Styles, Layout, Attributes, and Events. The Layout tab is great for defining the CSS Box Model, while Style & Trace Styles tabs are for DOM inspection
Trace & Style tabs list styles for the selected node(s) in order of specificity. This means the styles listed toward the bottom of the window are the most specific. Changes you make in the DOM Explorer are reflected immediately in the Simulator; however, keep in mind these are runtime changes that will not affect source code. This article on CSS inspection contains complete details about each DOM explorer tab.
Other Visual Studio 2012 Debugging Windows
 Don’t be lazy. Keep Strict Mode enabled, it keeps you away from a lot of trouble.