I never actually built an application (nor a HelloWorld) in WinRT, and I’m very suspicious.
My question is if there are features in WPF/Silverlight that don’t exist in WinRT (excluding features that are implemented differently by design)?
And these aspects are most important to me and are the core of my question, and in result, decision to whether start using WinRT or wait for these to be implemented for it:
- Entity Framework?
- WCF RIA?
- MVVM support (Prism)???
- Various toolkits (Silverlight/WPF toolkit), that provide additional controls such as
DatePickeretc.?
It’s not clear to me whether WinRT fully targets .NET or how it works.
Also, is WinRT a client-only (like WPF) application or can be ran on a remote client while sitting on a server (like Silverlight)?
Another one: What about backwards compatibility, if I develop a WinRT app, will it ever be able to work on Win XP?
I anyway can’t understand why MVVM is not integrated inline and has seamless IDE support as MVC has. but that’s just a side note. I can’t use XAML without MVVM, any app that is a bit bigger than hello world is easier to do with MVVM.
Update after answer
As I commented on the answer, I do like the design of WinRT, but the question remains unsolved until I know about the specific technologies mentioned above (EF, WCF-RIA + Validation, MVVM, SDKs and Toolkits). And obviously, I’m not gonna start selling WinRT apps or digging into it until I have the above techs as a least.
Conclusion, as one who most of his work is LOB apps, after checking around a bit, HTML5+JS is far from being an alternative to SL. So for conclusion, I stick to SL and keep on recommending it to my customers. SL takes the least development time, and is bug free.
Javascript is a dirty error-prone language, no pattern and no nuttn, compared to C#.
Once EF+RIA+Prism+Toolkits are fully supported for WinRT, I will consider taking my LOB apps the metro way.
WinRT is basically a collection of COM objects that wrap a bunch of Win32 API’, exposed as CLI-compliant assemblies.
Microsoft modified their C++ compiler to consume and generate ECMA 335 (i.e. CLI) metadata rather than the more traditional and (largely) C++/COM-only MIDL or lib file formats. Microsoft also modified their “Chakra” Javascript engine to also consume and emit CLI metadata.
This means that when targeting WinRT, Javascript and C++ code, along with .NET languages, of course, can consume CLI-compliant (i.e. .NET) assemblies and can emit CLI-compatible (i.e. .NET) assemblies.
So, one can write WinRT code in C++, any .NET language (i.e. C#, VB.NET, F#, Iron*, etc) and in Javascript.
The WinRT API’s will be VERY familiar to you if you’ve ever written any .NET code. The Windows team actually sought the help & guidance of the .NET Framework design team when designing WinRT, so the same design guidelines that have guided the entire .NET framework team and most of the .NET community for the last 11 years have been applied to the WinRT API’s.
WinRT’s primary impact is that it replaces System.IO’s file, network, stream IO classes with similar API’s but which ONLY support async IO. This means that you will not be able to write apps that block threads while they wait for calls to the filesystem or external systems via the network to return unless you take explicit steps to do so.
This is a GOOD thing.
Luckily, the new async/await features of C# v5 & VB.NET v.next, along with specific support for C++ mean that you don’t have to go and fundamentally change how you write code in this new async world – typically you just need to add an “async” keyword to method signatures that call async API’s and then use the ‘await’ keyword prefixing each async API call.
I STRONGLY encourage you to watch Anders Hejlsberg’s session which should make this whole thing very clear. While you’re there, I also encourage you to watch several of the other //BUILD sessions, especially Harry Pierson’s talk on using WinRT with C# & VB.NET and Mads’ session on Async Made Simple in C# and VB.
I’d also recommend that you take a look at the improved Win8/WinRT platform architecture diagram that I blogged a few weeks back which should make things a little clearer.
As for .NET itself, as I articulate in my post above, .NET is not “going away”. While a few of the .NET API’s will be prohibited in WinRT apps (i.e. blocking IO API’s), most of the API’s you depend upon remain and are fully accessible.
Regarding Silverlight: Silverlight is a browser plug-in. It’s a modified-subset of WPF and offers some very powerful and attractive features. So much so, in fact, that the Silverlight XAML engine was moved into the core Windows team and is used for most of the Metro UI rendering in Windows8 – even by the OS itself!
The net result is that most of your Silverlight code will run just fine with barely any modification, other than just changing a few ‘using’ namespaces.
There are a ton of XAML-focussed sessions from BUILD available to watch here.
With regards backward compatibility, aim to:
Frankly, I don’t think it’s Microsoft’s job to write every framework for every scenario. There are several MVVP approaches/frameworks out there in the wild from various people with various pro’s and con’s. And if you don’t find one then create one and stick it up on GITHub and become famous 😉
Above all, though, there’s little stopping you from downloading and trying Win8 Consumer Preview & Dev11 Beta. Go get them and try them out – I think you’ll find them very refreshing 🙂
HTH.
You can find the WinRT API surface area enumerated here in some detail. The core WCF API’s are enumerated here.
Note, however, that Microsoft is strongly recommending against using network coomms to communicate between Metro apps and other metro apps or desktop apps/services on the same machine. Read this SO question & Kate Gregory’s answer – she links to a video where this scenario is discussed in detail.
If you want to communicate with off-box network services, then you have a wide variety of options including WCF, sockets, etc.
Regarding RIA: Microsoft are currently saying that if you want data, you’ll need to get it via a service rather than directly from a DB. There’s no ADO.NET for Metro and the recommendation is to surface data via OData, JSON, XML/HTTP, etc. Data as a service is very much a RIA scenario, so I expect RIA to be well supported for Metro apps. Here’s a BUILD session on this very subject which may shed more light.
Only you can tell whether or not your specific scenarios are supported in WinRT. I think your best bet would be to download the bits and start exploring.
This guidance includes updates to Prism/Kona and also includes EntLib6 & Unity3 (IoC). I encourage anyone interested in this space to study the published materials and reference apps – there is some great stuff in there 🙂