I know, as a XAML developer, you are probably confident that you own the better way for writing stunning interfaces, with a productive timing, a consistent toolset and a powerful language like C# that is a sweet juice. I'm also pretty sure that HTML people is completely confortable on its side and do not feel the need of moving to another language. Unfortunately, landing on the real world, these strong reasons are not so strong for all the people, and often you are forced to rely on something you'd not use under normal conditions, as an example because your customer has some constraints that prevent you from use your consolidated XAML or HTML5 knowledge but wants the other.
It's the main reason that convinced me to improve my knowledge in the HTML way to the Windows Store apps - also if I'm totally productive with the XAML side - together with personal will of being aware of all the technologies in my scope. During this exploration I've always kept my XAML knowledge as a guide to understand how the HTML apps works and I found that, under the hoods, the things are not so different and I think that someone may go on the same path backward from HTML to XAML, reading this series.
Building the project
The very first step when you have to create a new Windows Store app - I mean when you are ready to start writing code - is to create a project. In this series I'll use two projects, as you expect one for HTML and the other for XAML code, trying to make things equal in both of them. So, first of all, you have to find a template in Visual Studio that is the most similar to a project in XAML. Since I usually skip complex and ready-made templates, I've started from the "Blank App" in XAML and I after a bunch of tests I found that the most similar on the HTML side is the "Navigation App". 
In XAML as for HTML you can create apps that are not navigable but from the templates on the XAML side this is not completely evident. The minimal app in HTML is really minimal and do not include a navigation frame. In XAML you always get a frame and eventually you have to remove it.
On the side you see the comparison between the two projects in the solution and to me it is pretty clear that there are a number of common points into them, together with few differences. The "App.xaml" file in XAML becomes the "default.html" in the HTML app. These are the entry points of the application and they does the same thing in different ways. Since the frame is injected in code from C#, the HTML application has it specified in the markup. This is the sole difference given that all the initialization code does exactly the same in both the model and, at the end, the application navigates to its start page. Going deep into the code, the very important difference is not on the structure but in the implementation. As XAML developer you know there is a Frame control ready, but in HTML, the counterpart named PageControlNavigator, is coded directly into the template. It is a WinJS control referenced by the default.html page and you can find it into the js/navigator.js file. Into the page is it referenced using a <script> tag and then used into the markup as a <div> element. The following code shows the different approach of the two languages:
1: // frame injection in XAML apps.
2:
3: if (rootFrame == null)
4: {
5: // Create a Frame to act as the navigation context and navigate to the first page
6: rootFrame = new Frame();
7:
8: // ... does other things related to initialization ...
9:
10: // Place the frame in the current Window
11: Window.Current.Content = rootFrame;
12: }
1: <!-- frame injection in HTML apps -->
2: <body>
3: <div id="contenthost"
4: data-win-control="Application.PageControlNavigator"
5: data-win-options="{home: '/pages/home/home.html'}"></div>
6: </body>
The two attributes that are uncommon for html, specify the type of the control to apply to the element (data-win-control) and the initial values of some properties expressed as json (data-win-options). I'll be back on this argument when I'll talk about the WinJs controls in a next article. For now you have only to notice that the runtime creates an instance or the PageControlNavigator class and assign to it the values in the json. Both the frameworks then start the navigation by code:
1: // start navigation in XAML
2:
3: if (!rootFrame.Navigate(typeof(MainPage), args.Arguments))
4: {
5: throw new Exception("Failed to create initial page");
6: }
1: // start navigation in HTML
2:
3: args.setPromise(WinJS.UI.processAll().then(function () {
4: if (nav.location) {
5: nav.history.current.initialPlaceholder = true;
6: return nav.navigate(nav.location, nav.state);
7: } else {
8: return nav.navigate(Application.navigator.home);
9: }
10: }
This javascript code simply says: "after the initialization has completed, navigate to the home specified in markup". You may expect that specifying the "home" property to an url directly causes the navigation but it is not true in HTML. You usually need to call the WinJS.UI.processAll() method to have attributes processed. From this point of view it is clear that coding javascript and HTML is much more verbose than XAML and C#.
Going forward in the exploration you see a "pages" folder in the HTML application. Inside this folder you put all the files related to each page. Since every page has up to three files they are grouped inside another folder that has the name of the page. I really like the organization in the HTML projects because it is very similar to the one I use in XAML. The default xaml template instead puts the MainPage.xaml in the root folder an this force me to delete and create again the page in the right place.
Each page in html is made of three specific files. The html markup defines the structure and references the other two. The CSS contains the look and feel and finally the JS file contains the logic. At the proof of facts this distinction is only for separation purposes because nothing prevents to include both javascript and css in the html markup but I love how the template propose a clean and well organized structure. In XAML this is not so clear. We can for sure relay on a very effective and powerful separation using XAML for structure, Resource dictionaries for styles and CS for logic but most of the times people is not so clever in this separation and ends to put all the things together. Unfortunately the XAML templates do not try to teach the good way as the HTML does.
Working with Style(s)
Speaking about style sheets, both XAML and HTML give a number of predefined styles to use in the application. In HTML they are provided as two separated CSS files, ui-light.css for light theme and ui-dark.css for dark apps, and they are part of the WinJS library. To switch from the light to dark theme you have to change the reference in your pages, in the head section, or in the default.html that propagates its value to all the pages like it does the App.xaml.
1: <!-- WinJS references -->
2: <link href="http://Microsoft.WinJS.1.0/css/ui-light.css" rel="stylesheet" />
3: <!--<link href="http://Microsoft.WinJS.1.0/css/ui-dark.css" rel="stylesheet" />-->
This is different from the XAML way because it implicitly defines the Styles in the WinRT runtime and you only have to define the theme once in the App.xaml. Switching between the Light and Dark theme means that the runtime defines different values fo the styles but they have always the same name that is often related to the control, the scope or the meaning.
1: <Application
2: x:Class="Elite.Html4Xaml.XamlApp.App"
3: xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
4: xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
5: xmlns:local="using:Elite.Html4Xaml.XamlApp"
6: RequestedTheme="Light">
7:
8: </Application>
Inside the stylesheets, WinJS defines a number of classess prefixed by win-*, These apply to the controls as well as the xaml runtime defines a number of brushes and styles. Both automatically applies the styles wherever it is possible and let you override the default aspect in your own stylesheet (xaml or css) or in the page itself. In this example I show how to define a green appbar html. It requires a minimum effort and apply automatically to all the pages:
1: .win-appbar {
2: background-color: green;
3: }
In xaml the things are little different. You have to apply the named style to the AppBar manually since it is a brush and then redefine the brush. This makes thing slightly complex but definitley flexible as in html. Here is and example:
1: <SolidColorBrush x:Key="AppBarBackgroundThemeBrush" Color="Green" />
2:
3: <Style TargetType="AppBar">
4: <Setter Property="Background" Value="{StaticResource AppBarBackgroundThemeBrush}" />
5: </Style>
In the example the brush is redefined as green and then, with a global style it is automatically applied to all the app bars. Then you can customize app bars in the page for specific reasons with another style.
So different, so similar
As you have seen in the examples the common points between the html and xaml templates are many. This might not be a surprise since the base platform is the same. This first impression watching the project structure is sometimes confirmed in a number of aspect and this enforces the choice of the technology that better fit your own knowledge when the choice is up to you. However, if the marker forces you to move to the other side you have not to be fear because with a little effort it is possible to work in both the languages. The sole point of friction is the switch between C# and Javascript. Coming from Javascript you need to completely learn a totally new and different language. Coming from C# you have to accept some big miss like types and a real object orientation. In the next article I'll go deep on the layout of the page and viewstate management to discover some other unexpected common points.