W8 Store App: Writing UI in HTML and CSS, and usin

We've started to research the possibility of creating the LOB W8 Store apps pushed to Surfaces through our/customers' domain store. We've got a portfolio of working WinForms and WPF apps written in .Net, and are thinking of migrating some of them to Surface because of the customers' preferences. Now I've got a dilemma: I've made a research about development technologies in Windows 8, and from what I have read and tried it seems the best way to utilize the W8 Store development techs is to use this combination:

HTML, CSS, JQuery and JS for UI development (View), and
C# and proper .Net for the Model/Domain part of the solution.

The fact is (or IMHO), that XAML is heavily bloated compared to lightweight HTML/CSS/JQuery when creating triggers, effects, animations and UI, we don't have that much developers' time creating the UIs. On the other hand, JS is (IMHO, again) unusable for Domain/Model application because the code would have to be rewritten (no time for that) and, despite the language and type-checks introduced in JS, I think the language is hardly usable for our Domain/Model requirements and learning curves.

From what I was thinking, is there a possibility of writing the UI part in HTML/CSS/JQuery/JS and Domain/Model parts in .Net/C#? So that we'd have a bunch of HTMLs, JS and, let's say ViewModels to bind to, and a domain DLL written in C#? I mean to use it similarly to creating a solution in C++.Net and adding a couple of C# and VB.Net projects/dll references to it and referencing the classes in it?

I read that the only way how to achieve this (since the JS app is native AFAIK), is to use the Interops and COMs, and, I'm afraid that this would not be possible with our software.

Thank you guys.

A Windows Runtime Component should enable what you want here and provide a seamless integration with the JS front end (read: no messy interop/COM for you to worry about). The Windows Runtime component you write in C# can use any of the .NET functionality allowed for the Windows Store (so you're not losing any capability there); however, what you expose from the Windows Runtime Component can only use Windows Runtime types for parameters and return values, which you probably expected anyway.

Check out the Walkthrough on the Dev Center and Creating Windows Runtime Components in C# and Visual Basic for more details.