locked
Any advantage of developing in HTML/JS rather than C# RRS feed

  • General discussion

  • Hi,

    I'm returning to the IT world after a 5 year hiatus. I want to develop a Metro app that will interact with a web based system (i.e. the user will have the ability to create content on the website, which then get loaded into the app).

    Initially I want to create it for Win8, but I will probably also want to port the app side of things to Android/IOS platforms.

    I've done C# and HTML/JS in the past, though admittedly need to re-learn a lot of things.

    I want to know whether the HTML/JS approach would give me any advantage when porting over to Android / IOS? Or is there any other reason I would choose this method over C#?




    Wednesday, June 6, 2012 9:06 PM

All replies

  • The different language options are offered with the thought of "use what you know" because we've endeavored to provide parity between them. It really depends on what you feel most comfortable working in and/or relearning. In either case you'll need to learn necessary aspects of the Windows Runtime API (WinRT); for XAML you'll get to use all the APIs in Windows.UI.Xaml, for HTML you also use much of what's called the Windows Library for JavaScript (WinJS), which is where the HTML-based controls are implemented.

    Where portability is concerned, a Metro style app writing in HTML/JS is going to be fairly platform-specific to Win8, though you can architect the app to abstract away a number of platform specifics. You could port app logic code in JS, of course, but with the HTML/CSS, you're going to be using lots of Win8-specific controls which won't port at all.

    Since C#/XAML apps can access web services as well as HTML/JS apps, that's not too much of a differentiator except for HTML/JS being more inherently oriented around consuming XML and JSON. There are APIs in WinRT for this that C# apps use, but there is something of a translation between the loosely-typed XML/JSON world and the strongly-typed C# world. Others on this forum might have some experience in that.

    If you have the opportunity, I'd suggest you spend a few hours with some of the Quickstart topics on http://dev.windows.com in both languages, and see which one feels most natural and comfortable.

    Thursday, June 7, 2012 4:11 AM
  • Kraig - that was a great answer, thanks. In terms of comfort I'm happy with either approach (or rather I'm equally uncomfortable with either approach as I need to relearn things!).

    I will opt for C# though. Cheers.

    Thursday, June 7, 2012 11:21 AM
  • An other reason to pick JavaScript / HTML5 for you Metro app could be visualisation options. Lots of libraries are available for graphics in HTML5/JS, but not in Portable Class libraries (yet). Example showing a bargraph could be pretty hard in non-JS Metro because you have to create the element by yourself.
    • Edited by Precan7000 Friday, June 8, 2012 2:26 PM
    Friday, June 8, 2012 2:26 PM
  • Thought I'd bring in an important thing against HTML5/WinJS applications...they're not fun to build. Too high of a learning curve, even for seasoned HTML developers. Fragments take getting used to, the stack trace on finding bugs is aweful, figuring out how to pass variables and keep vairables in scope are mind-numbing.

    I'm hoping all of our future Windows 8 Metro builds are in Xaml/C#.
    Friday, June 8, 2012 5:35 PM
  • I once got bleeding eyes from looking at XAML. Since then I prefer clean HTML/CSS3 any time. 

    Fragments are easy to understand, just like C-includes. The stack trace and debugger is just fine. What do you mean by "how to pass variables"? Its no different than in C#.

    I have to agree though, that the current version of VC2012 is too buggy do do any reasonable javascript/coffeescript development.

    Saturday, June 9, 2012 5:34 PM
  • Look at the example snippet below. Now, the point of having HTML5/CSS as a building block for Windows 8 applications, is to bring on web developers to help build more apps. Do we really think that when web devs look at stuff like the below, it will make them enthusiastic about developing Windows 8 apps? Just look at some of the issues since the RC came out...especially things like selectNodes being removed and everyone running around trying to figure out what the Hell things like querySelectorAll are.

    Yes, there is always a learning curve...but this curve was way too steep for myself and other coworkers, who had deadlines to meet.

    Monday, June 11, 2012 2:02 PM
  • querySelector[All] should be familiar to any decent jQuery developer. I am not aware that selectNodes has been deprecated but never used it myself and still could develop a complex HTML app.

    I think depending on the background of the developer one might choose her tool to develop metro apps. HTML5/CSS just feels more natural to me, and XAML is overly verbose. I am working on a simple to use framework like RubyOnRails to make developing WinJS metro apps even faster and more configuration than code driven. Good luck with your project though.

    Do you plan to write a post-mortem on your developing experience? Is the VS IDE also as unstable in C# as we are experincing here with the JS/C++ part of it?

    Monday, June 11, 2012 2:19 PM
  • I can't post-mortem anything....we build stuff for Microsoft internal, so nothing we do is public(SharePoint, WP7, Windows 8)

    Even posting for help on these forums I can't say too much. Screenshots, I need to be careful on what is posted... =)

    Monday, June 11, 2012 5:29 PM
  • Just so it's clear on this thread: selectNodes wasn't removed...the whole object type used for the responseXML coming back from WinJS.xhr changed from XML DOM to HTML DOM. See http://social.msdn.microsoft.com/Forums/en-US/winappswithhtml5/thread/2141429b-b7d3-46ef-a46b-5919e41d454f.
    Tuesday, June 12, 2012 5:35 PM
  • Well the issue Kraig, is that in the document "Migrating your Windows 8 Consumer Preview app to Windows 8 Release Preview" from Microsoft, there are no changes on the responseXML in there, nor is there anything about WinJS.xhr. We were completely sideswiped on this one.

    I do find it odd that responseXML brings back HTML, I would have figured a better architecture would be to leave responseXML the same, and make a responseHTML. It's not much of a responseXML if it brings back HTML :)
    Wednesday, June 13, 2012 12:06 AM