For many reasons, I still love developing Windows 8 apps using HTML, CSS, and JavaScript. I have extensive C# experience and always want to be able to say "I'm a C# developer", but I'd like to add that "I'm a JavaScript developer" as well. Some months ago I was a little pained to make even a short term commitment to write more JavaScript than C#. It felt a little like when I was learning French and found myself hesitant to start trying to think in French as if I would lose my English. Of course, that won't happen, and we shouldn't be afraid even of immersing ourselves in other languages. In fact, I'm a big advocate of the polyglot theory of intentionally moving into other languages spaces to expand our own scope, our value, and our perspective.

Becomes a way of thinking

I'm sure most development languages become a "way of thinking," but I think JavaScript does even more so because it's so dynamic and so light.

It's the language of the web

Mashups are a breeze when you're ingesting HTML and JSON data into and app that's made with HTML and JavaScript. The WinJS.xhr() method can make web requests with a request type of "document" and then immediately act on the results just like it would any other in-app content. Blob images can be consumed and repurposed. JavaScript objects can be created instantly out of JSON data. Yada yada yada. It's very convenient.

CSS selection of elements is great

Selectors are one huge strengths of the HTML/CSS that take advantage of the fact that HTML markup goes all the way to the client as XML-like syntax. Even on the client (at run-time) CSS can select very specific portions of the UI in order to affect it with styles or layout. JavaScript can take advantage of selectors too (using document.querySelector and .querySelectorAll) and that allows our logic to act on very specific portions of the UI.

One with the masses

There are a LOT of people writing JavaScript. A StackOverflow search on the [javascript] tag returns 300k+ questions on the matter (actually [c#] returns almost 400k!). It's good to have camaraderie in writing code. It's good to have employers looking for your skillset. It's good to have others asking questions on StackOverflow that you can benefit from. It's good to be one with the masses.

Standards driven

JavaScript is broadly adopted and is broadly and inherently appealing because it's based on web standards. The ECMAScript standard that is JavaScript, along with CSS and HTML, are governed by the World Wide Web Consortium (W3C) and that makes developers feel good. It's very democratic and very social and has very high likelihood of moving forward and moving in good directions.

Don't reinvent the wheel

There are a lot of JavaScript libraries out there. A lot. If you want to track faces or get fancy with date calculation or recognize touch gestures or implement IoC or pub/sub or manage Entity Framework data or edit images or any of a plethora of other things, there's a JavaScript library waiting for you.

A full stack of script

When you write C#, you don't usually just write C#. We find the client/server model everywhere and you don't send server code to the client, but you can send script. Whether you're writing an ASP.NET app or a client app, these days it seems you're inevitably going to be interacting with some HTML or even some JSON somewhere… whether you're using REST web services or scraping HTML screens. Having JavaScript on both the server end and the client end just tends to make you smile.

I like exploring languages. I am a veteran of VB. Like I have said, I'm a huge fan of C#. I have huge respect for C++ (though I haven't knocked on that door since college). I am exploring Erlang. Nevertheless, today I am having a blast writing JavaScript, and if you're writing JavaScript, I don't think you'll be hurting for work anytime soon!

Happy coding!

Question: what is Microsoft's position on Flexbox and fallbacks for IE10 and legacy?

While I'm not the official voice of Microsoft and am not the smartest Softie in Redmond when it comes to the web standards, I'll attempt to answer this question anyway.

The official standard for the flexbox style in CSS is documented in exhaustive detail at W3C. The abstract of this implement is helpful stating that the flexbox is

"…a CSS box model optimized for user interface design. In the flex layout model, the children of a flex container can be laid out in any direction, and can "flex" their sizes, either growing to fill unused space or shrinking to avoid overflowing the parent. Both horizontal and vertical alignment of the children can be easily manipulated. Nesting of these boxes (horizontal inside vertical, or vertical inside horizontal) can be used to build layouts in two dimensions."

I think the official answer is that Microsoft doesn't have an official position on falling back from flexbox. The -ms-flexbox is an implementation by the Trident engine to the flexbox… end of story. You will, however, find some recommended strategies on the web, and the best I've run into so far is the use of inline-block for unsupporting browsers.

That said, I'm spending most of my time with Windows 8 apps these days am thus spared the pain (the ever building pain that has yet to reach a crescendo) of writing 12 lines of code to accommodate the various HTML/CSS engines. If I was doing web development for the masses, I think I would decide to avoid the use of flexboxes altogether to ease my pain. I'm not sure what's worse - an old, hacky solution or multiple solutions to maintain (one of which is still old and hacky).

If you throw down with a media query like this…

@media screen and (-ms-view-state: fullscreen-portrait) {
    p { color: purple; }
}

…then you’re going to get purple text in all of your paragraphs, right?

Well, what if you wanted to check to see if you were in fullscreen-portrait from your code so you could do something fancy. Of course, you get some help from Windows with that. If you’re using the navigation project template then you can implement an updateLayout method when you define a page and one of the parameters you’ll receive is viewState.

But you might not be in the updateLayout method and you might want to check some other media query property such as whether the screen is at least 600px wide.

That’s where you may benefit from accessing media queries programmatically.

To execute the media query above from could you can do this…

if (msMatchMedia("(-ms-view-state: fullscreen-portrait)").matches) {
    //do something if we're in portrait
}

This msMatchMedia method hangs off of the window object.

I know that there are usually properties in the DOM API that will allow you to discover these things about your environment, but if media queries are your thing and you can solve the issue that way, then there you go.