Google+

Observations From Microsoft's Build Conference

Overview

Build was a bit of a different conference.... Initially, when it was announced at MIX it was called PDC (Microsoft's Professional Developers Conference). PDC generally has topics that cover the breadth of the Microsoft eco system from a developer's perspective; creating ASP.NET applications, C# , VB.NET , Entity Framework this and Entity Framework that. Build was NOT that, it was specifically dedicated to Microsoft's upcoming Windows 8 operating system, and especially to the new Metro UI introduced as part of the OS.

Windows 8 is, quite obviously, the next version of Microsoft's Windows platform. Microsoft is laser-focused on optimizing Windows for alternative form factors, especially the tablet. They have reduced the footprint of Windows by eliminating several core services that start up as part of the Operating system as well as the memory footprint. A demo played on an old netbook showed overall resource usage actually decreased when moving from Windows 7 to Windows 8, the first time that a new version of their operating system has had decreased baseline hardware requirements.

The biggest change though is the introduction of the Metro UI for Windows, which can be thought of as the tablet interface for Windows. It is a 'fast and fluid' touch-based interface, similar in some ways to Windows Phone 7, especially in the use of the Live Tiles, which are uber-icons that update with information. Take a look at the screen shot below to see what the new 'start screen' looks like, gone is the iconic start menu introduced in Windows 95, replaced with a 'Windows Phone on steroids' style home screen.

Win8screen1

The interface has been well received by folks at large. It's a pretty bold reworking of Windows, part of which involves the fact there are NO Windows, just one or two running applications on screen at a time. For developers, the good news with Windows 8 is that you can also get to the desktop and use all of the applications you already use on Windows 7.

To make all of this fluid, swipey goodness, Microsoft has introduced a new programming API called WinRT, which stands for Windows Runtime. WinRT is to Win32 what Silverlight or Windows Phone 7 are to the full .NET Framework, a smaller API surface optimized for their respective platforms. However, it is different in a couple of ways. First, it introduces new areas to the core Windows API, most of which are focused on using Windows for things like storage and search. Second, Microsoft is providing [or projecting] the WinRT APIs for direct use by C#, C++, VB.NET and JavaScript (and possibly F#), so instead of calling .NET framework libraries that in turn call Win32 APIs, the .NET code directly executes WinRT calls, similar to existing COM interop and P/Invoke technologies. The difference is that the projections include rich metadata so that the libraries appear as 'native' class libraries in each of their respective languages, avoiding a lot of the headaches of existing COM and P/Invoke interactions.

The diagram below outlines the various options for creating applications on Windows 8.

Win8screen2

The 'Desktop Apps' section of the diagram is the same types of applications that we currently know and love (or love to hate). These types of applications will continue to be supported and extended moving forward, but WILL NOT be able to interact directly with Metro apps, nor participate in the Windows 8 contracts that provide the rich 'web of applications' that are one of Windows 8's signature features. These applications will also not be able to be installed through the new Windows Store (think the App Store, but for Windows). Desktop applications will be linked through the store, but are not subject to the same certification and safety guarantees as Metro apps.

Similar to how C#, VB.NET, F#, and a host of other languages can create applications using the .NET Framework APIs, there are several options for creating WinRT applications. The options can be split into three different groups. The first group is C/C++ applications using either DirectX or XAML based UI technologies. DirectX is primarily used for game creation or complex imaging applications, and XAML based UIs are really Microsoft's replacement for their existing MFC framework. The second group is a Metro equivalent to WPF applications, written in either C# or VB.NET. The final group is the newly introduced/repurposed HTML/CSS/JavaScript stack, which allows the creation and packing of applications Windows 8 Metro applications using HTML/CSS as the UI layer, and JavaScript as the interface. An entire article could be written on what the HTML/JS layers represent and how they are different than 'web apps', but these types of applications are not executed 'in browser', they are fully fledged 'Metro' apps, using IE's JavaScript engine (Chakra) as the runtime interpreter. To be clear, there is NO fundamental difference in the end result for 'Metro' apps, regardless of what technology stack you choose to use, they really are just options that allow you to use your existing skillset to build Win8 Metro applications.

Quick Hits

Here are some quick bullet points for takeaway...

Microsoft got its C++ love back -There was quite a lot of time and energy from Microsoft put into the development tools for C++. One of the sessions even stated "C++ is back because performance matters". If you are looking to create uber-optimized WinRT apps on Windows 8, C++ may be the best option. If you are looking to get a date or see your family grow up, the .NET stack is still going to be the best way to create Line of Business applications (LOB). Also, WinRT applications run great with C#/VB/JS languages!

All Services All the Time -The data story for WinRT is going to be REST/JSON services. As of now, there is no way to run something like an Entity Framework model on the Metro UI. There are some rumors of SQL Lite support, but the hard push is for connected apps that require backend data sources that are NOT LOCAL to the machine (or even network) in question.

Metro UI on other processors -Microsoft is looking to have folks create many different devices and form factors using Windows 8. A lot of these will run on ARM processors, which are the low energy, middling performance chips that power things like iPads and mobile phones. For classic non-.NET desktop applications to run on these processors they will need to be recompiled. It is worth noting that there are LOTS of confusing statements about this, but as of now, that is the current understanding. Currently there is, at least, a subset of the .NET framework (the Windows Phone runtime) that runs on ARM, so it seems like good .NET framework support should be possible, even on ARM.

Visual Studio 2011 -Microsoft has a new version of Visual Studio 2011 that supports templates for many of the WinRT application types

Asynchronous data access -Microsoft has a new async/await keywords that are being introduced with the .NET Framework 4.5. These keywords allow a call to be made on a different thread. This becomes VITALLY important for performant applications because the thread that runs the UI has to wait for data to come back. Microsoft states that any call that takes longer than 50 (or 15, both have been mentioned) milliseconds should be asynchronous. Get used to coding a lot of async calls in the future! The good news is that the new keywords and compiler support mean that writing Metro (and .NET 4.5) applications will look a lot like standard synchronous code that 'just works'.

Promises -JavaScript programming on the WinRT stack is going to be implementing the idea of promises. This is the JavaScript version of async/await. Essentially, have JavaScript go get some data, promise data comes back and there is a then() function (or continuation) which will run after your data returns.

Windows Store -Microsoft is introducing a Windows Store for users to go and download applications and easily install them on their computer. This will be for WinRT applications only! Other .NET/Win32 applications may exist in the store, but they will link to external sites for purchase and install.

Conclusion So, what does it all mean? At the end of day, at least for now, not a whole lot! In all seriousness, Microsoft is probably a year away from releasing Windows 8 and clients will be at least 6 months to a year out from installing and asking for it. But, be sure to be ready when they start asking!

Having said that, Windows 8 represents a HUGE opportunity! According to Microsoft there are soon to be over 500 million copies of Windows in use. That is more than all the other mobile platforms combined. If there is one thing you want to do today to get ready for Windows 8, I would recommend this... Get your HTML 5/XAML skills up to speed and learn to love creating data services that can be consumed on mobile platforms.


 

HTML 5: A Little History

HTML 5 is being proposed as a magic potion for all that ails the world of developers. It slices, it dices, it chops and even calls your mom on her birthday when you forget. Let's jump on the bandwagon!

To understand HTML 5, first you'll need a bit of history... HTML is a standard, standards are created by standards bodies, and they can take a while. The HTML standard is created by the World Wide Web Consortium (W3C), with the last HTML standard being HTML 4, which was published in December of 1997. At that point, the W3C essentially said HTML is dead, long live HTML, but in the form of XHTML, a break from the previous version of HTML with HTML being recreated as strongly formed XML.

The introduction of XHTML had one problem though; XHTML "broke" the internet. It didn't literally break it in the sense that you couldn't get your White Sox scores from ESPN, but without massive rewrites, it would have. HTML has always been a "forgiving" standard. If I develop an HTML page and have an opening xml <P> tag but not a corresponding closing xml </P> tag, my page will (most likely) work. XHTML would have resulted in a fatal error. People have estimated that fully implementing the XHMTL specification would have resulted in 99% of HTML pages at the time not rendering properly.

So, our journey to the way back machine brings us to 2004, HTML 4 is the last W3C standard and their work has been focused on XHTML since 1997. During this time, XHTML has NOT taken off in the marketplace. People still want their White Sox scores from ESPN. As a result, browser developers, some web development companies, and some W3C members got together and proposed evolving HTML 4 with new features for modern browsers since a lot had changed in the years since the last standard (2004 -1997 = 73 Internet years). The W3C said they were not interested but the folks who proposed extending HTML WERE interested and went off and created the Web Hypertext Application Technology (WHAT) working group. So here is the state of the world: the people responsible for the HTML standard are not evolving the HTML standard any more, the folks who implement the HTML standard (the web browser creators, the app tool creators, etc.) want to evolve HTML.

So the WHAT group went on doing its thing. Their main goal was backward compatibility. They wanted to be able to evolve HTML without breaking the 10 years of web development that came before. One of the more interesting things they did was explicitly identifying HOW to parse HTML so that it would be compatible across all browsers. In some ways, that became a new standard that indicated how all browsers should work.

They also went on and introduced new features into HTML (without breaking HTML) including new form elements for things like dates. They thought, "Wouldn't it be swell if browsers natively supported video and audio so we could get rid of things like Flash for streaming video?", so they added it. They also thought, "Wouldn't it be awesome if you could animate things directly in the browser?", so they added a drawing canvas to HTML.

The industry responded positively to these new ideas and the WHAT group started gaining momentum. During this time the W3C was working on XHTML 2, which none of the browser vendors implemented. I'm not sure what you call a standard that nobody implements, but whatever you call it, it's pretty useless. It got to the point where in October of 2006, the W3C and the WHAT working group decided to join forces and evolve HTML and create HTML 5.

Today we are at a point where these two groups are working together to create the HTML 5 standard. The next question is WHEN will there be an HTML 5 standard? It's going to be a while, maybe as far out as 2022 or later. So is that a problem? The answer is, hopefully not.

Part of the reason for the long time is that the HTML 4 specification is very vague or even undefined on how things work. If you forget to include your closing paragraph tag, it was up to the browser vendor to figure it out. This leads to different implementations across vendors so things don't work as expected across all the browsers, something you are no doubt very familiar with. As a first step, sometime in 2012, a candidate recommendation for the HTML 5 standard will be released. At that point, the feature set, already very close to being final, will be official. A good part of the remaining 10 years will be spent on officially documenting how the standard should parse HTML.

Another, even more important thing, is that the HTML 5 team is working on test suites. The idea is that browser vendors will have to run their browsers against the test suite and not until they hit 100% in a test suite will they be considered to have passed. In a lot of ways, the test suite becomes the standard. In fact, not until two major browser vendors pass the test suite with 100%, will the standard be considered completed. This is part of the reason for the very long elapsed time.

The other player in this is how HTML 5 works other devices. HTML 5 is or will be supported by all major smart phone vendors as well as tablet vendors, e-readers and most likely a plethora of things not even imagined yet. In fact, some sites, such as the ubiquitous Facebook, are rumored to be developing HTML 5 applications rather than native applications for mobile or tablet vendors. Part of the reason for this is that some of the hardware vendors are requiring essentially a commission on any purchases within a native application. As a result, a lot of sites may be looking to bypass the App Store approach and create native HTML 5 so they don't need to worry about giving hardware vendors a percentage of their revenue.

HTML 5 is a lot of hope and promise. In the past I have called it Java-esque, in the promise of the write once, run everywhere. What is different this time? A couple of things, one is the test suite that browser vendors will need to pass. The other is that there really seems to be a good cross section of the industry that REALLY wants this to work. It's not often that Apple, Google, Microsoft and other big companies are working towards the same thing. Do they always agree? Of course not! Will it cause problems? It already is. However, the industry is working hard to make this a reality.

It will be interesting to see how it all plays out. Browsers like Google Chrome are working hard on supporting HTML 5 across many platforms. IE is working towards supporting HTML 5 on the Windows platform using hardware acceleration. You will see differences where HTML 5 rendered using IE which will run much faster and can do more, so that performance issues of other browsers may be a concern. Vice-versa you can have issues where IE is not rendering something the same way Chrome is.

It's a long article just discussing the history of HTML 5 with none of the introduction of what HTML 5 is. However, it's important to understand the history of how we got here, and why the industry thinks this will be important. Next time I'll actually discuss some of what's new in HTML 5!

Why Use it? HTML 5 is going to (soon) be the industry standard for web applications

I want to learn more! Interview with Ian Hickson discussing HTML 5 adoption rates

This blog post originally appeared at [Skyline Technologies] (http://www.skylinetechnologies.com/Insights/Skyline-Blog/June-2011/HTML-5-A-Little-History)


 

An Introduction to the Microsoft Razor View Engine

In past blog posts on MVC and WebMatrix. I've mentioned Razor. Today, I'm going to get a bit more in depth on Razor and what it can do.

ASP.NET MVC supports view engines. All web programming consists of providing developers a way to insert data dynamically into their HTML output. In ASP.NET Web forms, this was done using <%= =%> syntax to let the runtime know that code was coming. In previous versions of ASP.NET MVC, this same approach was used and was called the Web Forms view engine.

ASP.NET MVC, however, had the ability to use other view engines. Ever since the introduction of MVC, people have not liked using the Web Forms View engine. During that time, several other view engines became popular for MVC development including Spark, StringTemplate and NHAML.

With the release of ASP.NET MVC 3, Microsoft is now using the Razor view engine. You can still use the previous Web Forms view engine if you would like. The team at Microsoft outlined several design goals for Razor when they introduced it. The most important ones are that Razor be compact, expressive and fluid as well as easy to learn.

One of the main complaints with the Web Forms View engine is how verbose the syntax was. Razor explicitly address this by using the @ keyword to enable script escaping.

So what does this code look like? First, Razor files have the extension csHtml (C# Syntax) or vbHtml (VB syntax). Razor files then get processed by the runtime. If we have a variable defined message and have an HTML stream going, you can see the razor terseness in the following syntax:

<p>Message for the user @message</p>

In ASP.NET Web Forms, this same line would have been

<p> Message for the user <%= message %></p><

Similarly, for example, if we have a list of sports teams showing their name and what place they are in and we want to iterate through to display the standings the syntax is:

<h3>Teams</h3>
<ul>
@foreach (var t in teams) {
<li>@t.Place - @t.Name </li>
}
</ul>

On the screen this would print as follows:

<h3>Teams</h3>
    <ul>
        <li>1 - Green Bay Packers</li>
        <li>2 - Chicago Bears</li>
        <li>3 - Detroit Lions</li>
        <li>4 - Minnesota Vikings</li>
    </ul>

Similar syntax with Web Forms:

<h3>Teams</h3>
<ul>
    <% foreach (var t in teams) { %>
        <li><%= t.Place%> - <%=t.Name%> <li>
    <%}%>
</ul>

Razor also supports HTML Helpers, which are a way for users to create HTML snippets across their code. So in the example above, we could create an HTML Helper to create the football standings and use it multiple times in our view or across multiple views. The syntax is as such:

@helper TeamStandings(FootballTeam team) {
    <li>@team.Place - @team.Name </li>
}

We could then update the page to call the helper:

<h3>Teams</h3>
<ul>
    @foreach (var t in teams) {
        @TeamStandings(t)
    }
</ul>

You can see how less verbose the syntax is to use. It is also, in a lot of ways easier to use. You never need to remember if you should escape out using <% or <%= either. The Razor syntax also introduces new syntax for laying out pages, superseding the ASP.NET concept of master pages. In truth, the ideas are both the same, but the concept is now called LayoutPages. Instead of having ContentPlaceholder sprinkled throughout a master page, helper methods in the template are used to fill in specific content. For example, let's call this page _groovySiteLayout.cshtml:

<html>
<head>
    <title>Groovy Page</title>
</head>
<body>
    <div id="groovyMenu"><a href="/">Home</a></div>
    <div id="groovyPageBody">
        @RenderBody()
    </div>
</html>

Then, within the view, we create our site content which includes a setting for the layout page. When the layout page hits the @RenderBoy helper method it injects the view content into the layout page and sends back to the browser. So for a simple view:

{
    @LayoutPage = "_groovySiteLayout.cshtml";
}
<h1>Welcome to Groovy</h1>
<p>Hello world</p>

Would render the following HTML:

<html>
<head>
    <title>Groovy Page</title>
</head>
<body>
    <div id="groovyMenu"><a href="/">Home</a></div>
    <div id="groovyPageBody">
        <h1>Welcome to Groovy</h1>
        <p>Hello world</p>
    </div>
</html>

There is a lot more to the Razor view engine, this is just a quick introduction, I will be talking about it a lot more in the future.

Why Use it? Razor is a new Microsoft view engine that is lightweight and easy to use. It is currently part of WebMatrix and ASP.NET MVC. There are even indications it will be an integral part of a future version of ASP.NET WebForms.

I want to learn more! Microsoft Introduction - This post on Scott Guthrie's blog is an excellent introduction! • Microsoft ASP.NET MVC site - Check out the pluralsight videos on the page


 

John Ptacek I'm John Ptacek, a software developer for Skyline Technologies. This blog is my contains my content and opinionss, which are not those of my employer.

Currently, I am reading Norse Mythology by Neil Gaiman

@jptacekGitHubLinkedInStack OverflowGoogle+