Category Archives: silverlight

.net, microsoft, professional, silverlight, software development

Windows Runtime must come to Windows Phone

1 Comment

I’ve been trying Windows Phone 7 in its latest “Mango” version over the last couple of days and mostly enjoying it. One thing I am not impressed by though is the range of apps available. Have a look at the Marketplace – Microsoft may claim 30,000 apps, but given how unexciting even the “top” selections are, you can imagine how bad the bottom ones must be. Microsoft I guess has been guilty of accepting almost anything to puff up the numbers.

What would fix this? Sell more phones, of course; but also improve the platform for developers. Windows Phone 7.x is not a bad platform: you get Silverlight, XNA, C# and Visual Studio.

By contrast though, the Windows Runtime (WinRT) shown at the BUILD conference earlier this month is a platform mobile developers can love. Here are what seem to me three great features:

  • Three first-class languages and programming platforms – C#/.NET, JavaScript and HTML 5, C++ and native code. All three are strategic platforms. I particularly like the native code option, as many mobile developers like native code and it is a weakness of Windows Phone 7.
  • Asynchrony built into the platform. This is a smart move: make every API call that might cause a delay an async-only call. On top of that, build easy async programming into the languages. The result should give apps a responsive user interface almost by default; developers will need to make an effort to freeze the UI.
  • Contracts which integrate apps with the operating system and with one another. There are five contracts: search, share, play to, settings, and app to app picking (for example, file selection).

Microsoft’s Windows chief Steven Sinofsky says Windows 8 is for tablets but not for phones. But he has to say that, because if Microsoft announced that the current Windows Phone 7.5 is a platform without a future, it would further dampen enthusiasm for the product.

Is there any reason why WinRT should not come to Windows Phone? A few:

  • Windows Phone is currently built on Windows CE, a cut-down version of Windows, whereas WinRT runs on top of the full Windows API.
  • The Metro-style UI is designed for tablets rather than phones.
  • Finally, the existence of Desktop Windows is presumed in the current Windows 8 design. If Microsoft has not had time to work out a Metro-style UI for something, you simply use the Desktop version.

All of these are good reasons why the arrival of WinRT on the phone will be delayed, but none are insuperable. Long-term, I find it inconceivable that Microsoft will persevere with a different programming platform for the phone and for tablets.

What are the implications for Windows Phone developers today? Well, WinRT and Metro borrow from the phone OS, so the porting effort should not be too bad, except in the case of XNA, a .NET wrapper for DirectX which WinRT does not support.

Of course this post is entirely speculative, and I have no insight into Microsoft’s plans beyond what is publicly stated, so there might be other compatibility options when and if the time comes.

And it is time that is Microsoft’s biggest enemy. Fumbling tablet computing has been a costly mistake, and the big question is whether anyone will care how good some future Windows Phone will be, if the ecosystem which Nokia likes to talk about is firmly established as Android vs Apple.

.net, microsoft, silverlight, software development

Reflections on Microsoft BUILD 2011

11 Comments

I’m just back from Microsoft’s BUILD conference at Anaheim in California, which lived up to the hype as a key moment of transition for the company. Some said it was the most significant PDC – yes, it was really the Professional Developers Conference renamed – since 2000, when .NET was introduced; some said the most significant ever.

image

“Significant” does not necessarily mean successful, and history will judge whether BUILD 2011 was a new dawn or the beginning of the end for Windows. Nevertheless, I have not heard so much cheering and whooping at a Microsoft conference for a while, and although I am no fan of cheering and whooping I recognise that there was genuine enthusiasm there for the new direction that was unveiled.

So what happened? First, let me mention the Windows Server 8 preview, which looks a solid upgrade to Server 2008 with a hugely improved Hyper-V virtualisation and lots of changes in storage, in IIS, networking, in data de-duplication, in modularisation (enabling seamless transition between Server Core and full Server) and in management, with the ascent of PowerShell scripting and recognition that logging onto a GUI on the server itself is poor practice.

The server team are not suffering the same angst as the client team in terms of direction, though the company has some tricky positioning to do with respect to Azure (platform) and Server 8 (infrastructure) cloud computing, and how much Microsoft hosts in its own datacentres and how much it leaves to partners.

What about Windows client? This is the interesting one, and you can almost hear the discussions among Microsoft execs that led them to create the Windows Runtime and Metro-style apps. There is the Apple iPad; there is cloud; there are smartphones; and Windows looks increasingly like a big, ponderous, legacy operating system with its dependence on keyboard and mouse (or stylus), security issues, and role as a fat client when the industry is moving slowly towards a cloud-plus-device model.

At the same time Windows and Office form a legacy that Microsoft cannot abandon, deeply embedded in the business world and the source of most of the company’s profits. The stage is set for slow decline, though if nothing else BUILD demonstrates that Microsoft is aware of this and making its move to escape that fate.

Its answer is a new platform based on the touch-friendly Metro UI derived from Windows Phone 7, and a new high-performance native code runtime, called Windows Runtime or WinRT. Forget Silverlight or WPF (Windows Presentation Foundation); this is a new platform in which .NET is optional, and which is friendly to all of C#, C/C++, and HTML5/JavaScript. That said, WinRT is a locked-down platform which puts safety and lock-in to Microsoft’s forthcoming Windows Store ahead of developer freedom, especially (and I am speculating a little) in the ARM configuration of which we heard little at BUILD.

BUILD attendees were given a high-end Samsung tablet with Windows 8 pre-installed, and in general the Metro-style UI was a delight, responsive and easy to use, and with some fun example apps, though many of the apps that will come as standard were missing and there was evidence of pre-beta roughness and instability in places.

The client strategy seems to me to look like this:

Windows desktop will trundle on, with a few improvements in areas like boot time, client Hyper-V, and the impressive Windows To Go that runs Windows from a bootable and bitlocker-encrypted USB stick leaving no footprint on the PC itself. Many Windows 8 users will spend all their time in the desktop, and I suspect Microsoft will be under pressure to allow users to stick with the old Start menu if they have no desire or need to see the new Metro-style side of Windows..

A new breed of Intel tablets and touch-screen notebooks will make great devices towards the high end of mobile computing. This is something I look forward to taking with me when I need to work on the road: Metro-style apps for when you are squashed in an aeroplane seat, browsing the web or checking a map, but full Windows only a tap away. These will be useful but slightly odd hybrids, and will tend to be expensive, especially as you will want a keyboard and stylus or trackpad for working in desktop Windows. They will not compete effectively with the iPad or Android tablets, being heavier, with shorter battery life, more expensive and less secure. They may compete well with Mac notebooks, depending on how much value Metro adds for business users mainly focused on desktop applications.

Windows on ARM, which will be mainly for Metro-style apps and priced to compete with other media tablets. This is where Microsoft is being vague, but we definitely heard at BUILD that only Metro-style apps will be available from the Windows Store for ARM, and even hints that there may be no way to install desktop apps. I suspect that Microsoft would like to get rid of desktop Windows on ARM, but that it will be too difficult to achieve that in the first iteration. One unknown factor is Office. It is obvious that Microsoft cannot rework full Office for Metro by this time next year; yet offering desktop Office will be uncomfortable and (knowing Microsoft) expensive on a lightweight, Metro-centric ARM device. Equally, not offering Office might be perceived as throwing away a key advantage of Windows.

Either way, Windows on ARM looks like Microsoft’s iPad competitor, safe, cloud-oriented, inexpensive, long battery life, and lots of fun and delightful apps, if developers rush to the platform in the way Microsoft hopes.

There are several risks for Microsoft here. OEM partners may cheapen the user experience with design flaws and low-quality add-ons. Developers may prove reluctant to invest in an unproven new platform. It may be hard to get the price down low enough, bearing in mind Apple’s advantage with enormous volume purchasing of components for iPad.

Still, one clever aspect of Microsoft’s strategy is that everyone with Windows 8 will have Metro, which means there will be a large installed base even if many of those users only really want desktop Windows.

I also wonder if this is an opportunity for Nokia, to use its hardware expertise to deliver excellent devices for Windows on ARM.

Finally, let me mention a few other BUILD highlights. Anders Hejlsberg spoke on C# and VB futures (though I note that there were few VB developers at BUILD) and I was impressed both by the new asynchronous programming support and the forthcoming compiler API which will enable some amazing new capabilities.

I also enjoyed Don Syme’s session on F#, where he focused on programming information rather than mere algorithms, and showed how the language can query internet data sources with IntelliSense and code hints in the IDE, inferred from schemas retrieved dynamically. You really need to watch his session to understand what this means.

In the end this was a great conference, with an abundance of innovation and though-provoking technology. In saying that, I do not mean to understate the challenges this huge company still faces.

.net, professional, silverlight, software development, windows

A few facts about Microsoft’s new Windows Runtime

25 Comments

I’ve just come out of Martyn Lovell’s talk on WinRT internals here at BUILD in Anaheim, California.

Make no mistake: Microsoft has re-invented the Windows API in WinRT. Just to recap, WinRT is the API for Metro-style applications, the touch-centric, app-centric API for tablets and, one presumes, eventually for Windows Phone (though Microsoft has yet to admit it).

WinRT is only useable from Metro applications. You cannot call WinRT from a Win32 application, nor vice versa*. I think it is reasonable to assume that a future version of Windows which runs only WinRT is a possibility; and that Windows 8 on ARM will look a bit like that even though Win32 will still be there, but mainly out of sight; but I am speculating.

Does that mean Win32 is now legacy? In a way, but such a huge legacy that for the moment we should think of Windows 8 as two platforms side by side.

There is no inter-app communication in WinRT other than by the pre-defined contracts built into the system (though Lovell noted that you could always use the file system and polling for a crude inter-process communication).

There is no way to install a shared dynamic library. Apps can only use the system libraries together with what you install with the app. Each app lives in its own context and is isolated. In other words, WinRT is not extensible, other than within your app’s code*.

If you figure out a way to bypass limitations of WinRT by calling other Windows APIs, your app might work but the submission process for the Windows Store will prohibit it.

Versioning is built into WinRT. This means that when Windows 9 comes along, you will be able to code just against the Windows 8 versions of the classes, for compatibility, and your IDE can support this by only exposing the Windows 8 version of the API.

The CLR exists in the Metro environment, for use by .NET applications, complete with JIT (Just in time) compilation. However only a subset of the .NET Framework libraries are included. Microsoft aimed to include only what was necessary for Metro. I am not sure yet what is included and what is not, beyond the obvious (no Windows Forms, for example) but will be investigating what is documented. The native WinRT APIs look similar to a COM callable wrapper from the .NET side. That said, you do not normally need to care about WinRT interfaces, even though these are there in WinRT. Normally you interact with WinRT classes, making it more natural for .NET than working with COM.

WinRT is full of asynchronous calls. Lovell told us that Microsoft had seen in the past that if both synchronous and asynchronous APIs are available for the same function, then developers often use the synchronous version even when they should not, making applications less responsive. The new await keyword in C# makes this easy to code.

WinRT makes use of the ILDasm metadata format which is also used by .NET. This means you get rich metadata for IntelliSense and debugging, but note that the actual runtime is not .NET; they just borrowed the same metadata format.

WinRT objects are reference counted like COM for memory management, with weak references to avoid circularity. You should not have to worry about this; you can code according to the conventions of your language.

There are three ways to write WinRT applications. One is C++, in which case you write directly to the “projection” of WinRT into your language. The second is .NET, in which case your code goes via the CLR. The third is HTML and JavaScript, in which case your code goes via the “Chakra” JavaScript engine also used by Internet Explorer 9 and higher. Lovell assured me that there is little difference in performance in most cases, though there could be advantages for C++ in certain niche scenarios. Of course we heard that story for .NET as well, but from what I have seen it is more plausible in WinRT.

There is no message loop in WinRT. There is no GDI in WinRT. All graphics are via DirectX. XNA, the .NET games framework, is not supported. It seems that you will need to use C++ for fancy DirectX coding, though this is not confirmed. Of course your XAML or Canvas code will be rendered by DirectX under the covers.

It is fascinating to see how Microsoft has borrowed XAML and ILDasm from .NET, but that WinRT is native and not .NET at its core. My take on this is that Microsoft intended to preserve the productivity of .NET, but without any performance compromise.

Despite the inclusion of .NET though, the fact that only a subset of the Framework is available, and that interop to the Windows API will not work*, means that most existing apps will need considerable work to be ported to Metro.

*Updates

A few clarifications.

It has been shown that you can call WinRT from Win32 (the favoured word for Win32 seems to be “desktop applications”) though I’m not sure how useful it is.

Concerning P/Invoke (Platform Invocation) to Win32 APIs, apparently this does work for a certain specified, small subset of the Windows API. It also works for your own native code DLL, with the proviso that if your native code DLL calls a disallowed Win32 API it will raise an error.

WinRT is partially extensible. A Framework Extension is a library which you can reference as a dependency in your app’s manifest. When the app is deployed it will download this dependency from the Windows Store. An example is the C Runtime Library. An extension library installs into its own directory, and can be used by multiple WinRT apps provided each one also references it in their manifests. However, the caveat is that only Microsoft can create these extensions: there is no way to create your own shared extension for general distribution, though an enterprise can deploy a shared extension internally.

.net, microsoft, mobile, open source, professional, silverlight, software development

PhoneGap comes to Windows Phone

Nitobi has announced PhoneGap for Windows Phone 7, nicely timed just before the Microsoft BUILD conference next week.

PhoneGap is a cross-platform mobile development tool that uses the HTML and JavaScript engine on the phone as its runtime, supplemented by extensions which give access to other device features:

After unpackaging the contents of the www folder, your www/index.html file is loaded into an embedded headless browser control. This is essentially the same paradigm as other platforms, except here it is an IE9 browser and not a webkit variant. IE9 is a much more standards-compliant browser than previous IEs, and implements commonly used html5 features like DOMContentLoaded events, addEventListener interfaces, and CSS3. Be sure to use to get the html5 implementation otherwise the browser may fallback to a compatibility mode, and your code will likely choke and die.

The version for Windows Phone 7, just released in preview, is extended to support features including the camera, accelerometer, contacts, and notifications. There is also support for plugins:

PhoneGap-WP7 maintains the plugability of other platforms via a command pattern, to allow developers to add functionality with minimal fuss, simply define your C# class in the WP7GapClassLib.PhoneGap.Commands namespace and derive your class from BaseCommand.

In general Windows Phone 7 is not well supported by cross-platform toolkits, so PhoneGap support is an interesting development. PhoneGap has a high profile currently, and is being integrated into a diverse range of tools ranging from Adobe Dreamweaver to Embarcadero RadPHP, as well as the standard PhoneGap tools based on Eclipse.

microsoft, silverlight, software development, visual studio

Windows Phone 7 apps, stats and future

2 Comments

Justin Angel, a former Microsoft employee who worked on Silverlight, has posted his analysis of the 24,505 apps he found in the Windows Phone 7 marketplace, exploiting a loophole that lets you get the download links. A few highlights:

  • 97% of the apps are not obfuscated, meaning that it is trivial (with easily available tools) to decompile the source.
  • 90% are Silverlight vs 10% XNA. This is not so much an indicator of the popularity of the two frameworks, but more an indicator of how many apps are graphic-rich games rather than some other kind of utility. Of course if you are making a very simple app, Silverlight is easier than XNA, so that may be a factor too.
  • 99% are C# vs 1% Visual Basic and a smattering of F#. A fascinating stat that makes me wonder what is the future of Visual Basic.

There are more interesting stats about libraries and components used, for which I refer you to the original post.

Does it matter? Well, Windows Phone 7 has not been a big success so far, though the reasons for that are not so much the quality of the OS or the ease of developing apps, but rather its low profile at retail and the fact that most operators and manufacturers don’t really need it: Apple and Android between them pretty much have the market.

That said, there are a few reasons why Windows Phone or some evolution of it may yet be significant. Nokia is betting on it, and while Nokia is undoubtedly in difficulties, this must work in Microsoft’s favour. Further, fear uncertainty and doubt surrounding Android patent and copyright issues may persuade some industry players to give Windows Phone another look.

Perhaps more significantly, when Microsoft unveils its developer strategy at the BUILD conference next week, it is likely that the application model in Windows Phone, or some evolution of it, will integrate with what is planned for Windows 8. NVIDIA is already talking about how Windows 8 will run Windows Phone apps.

For these reasons I believe there is at least a glimmer of hope for Microsoft in the mobile world; certainly the developer story to be officially told next week will be an interesting one.

adobe, flash, internet, mobile, silverlight, software development

Adobe says role of Flex and Flash has changed, makes play for mobile

5 Comments

Adobe’s Andrew Shorten has posted on the future of Flex, the developer-oriented tool for building applications for the Flash runtime.

This is one of the clearest statements I have seen from Adobe that recognises that the role of Flash on the web is diminishing:

There are countless examples where, in the past, Flex was (rightly) selected as the only way to deliver a great user experience. Today, many of those could be built using HTML5-related technologies and delivered via the browser, and at Adobe, we will provide tooling to help designers and developers create those experiences – Edge and Muse are two such examples.

Adobe is not giving up on Flash, of course, and states that it is still the best for certain categories of application:

We firmly believe that Flex is already the best technology for building complex, high fidelity enterprise applications such as business dashboards, line of business tools, real time trading applications and desktop replacement applications.

I would add both statements are written from the perspective of application developers. The role of Flash as a video and multimedia player is a separate issue. Flash is also important in that context. There is some overlap, in that if your application includes multimedia content then Flash is correspondingly more attractive.

As an aside, it is interesting to note that this repositioning of Flash makes it not so different from Microsoft’s Silverlight: a runtime for business applications.

Adobe is focusing on a new market for Flex in mobile. This overcomes the Apple iOS problem, since you can compile a Flex application to iOS native code. Adobe promises “additional mobile development capabilities” later this year and says:

In our next major release timeframe we expect that the need to build a fully-native application will be reserved for a small number of use cases.

I agree that cross-platform mobile development is a key area and one where there is no clear winner yet. It is a good opportunity for Adobe, though there is increasing competition from the products like Appcelerator Titanium and PhoneGap.

I also think that Embarcadero’s new RAD Studio XE2 will attract interest. This tool which will be released soon does native code compilation across Windows, Mac and Apple iOS, with Android promised, using the Delphi IDE and language.

.net, azure, development, microsoft, professional, silverlight, software development

Microsoft releases Visual Studio LightSwitch: a fascinating product with an uncertain future

8 Comments

Microsoft has released Visual Studio LightSwitch, a rapid application builder for data-centric applications.

image

LightSwitch builds Silverlight applications, which may seem strange bearing in mind that the future of Silverlight has been hotly debated since its lack of emphasis at the 2010 Professional Developers Conference. The explanation is either that Silverlight – or some close variant of Silverlight – has a more important future role than has yet been revealed; or that the developer division invented LightSwitch before Microsoft’s strategy shifted.

Either way, note that LightSwitch is a model-driven tool that is inherently well-suited to modification for different output types. If LightSwitch survives to version two, it would not surprise me to see other application targets appear. HTML 5 would make sense, as would Windows Phone.

So LightSwitch generates Silverlight applications, but they do not run on Windows Phone 7 which has Silverlight as its development platform? That is correct, and yes it does seem odd. I will give you the official line on this, which is that LightSwitch is not aimed primarily at developers, but is for business users who run Windows and who want a quick and easy way to build database applications. They will not care or even, supposedly, realise that they are building Silverlight apps.

I do not believe this is the whole story. It seems to me that either LightSwitch is a historical accident that will soon be quietly forgotten; or it is version one of a strategic product that will build multi-tier database applications, where the server is either Azure or on-premise, and the client any Windows device from phone to PC. Silverlight is ideal for this, with its modern presentation language (XAML), its sandboxed security, and its easy deployment. This last point is critical as we move into the app store era.

LightSwitch could be strategic then, or it could be a Microsoft muddle, since the official marketing line is unconvincing. I have spent considerable time with the beta and doubt that the supposed target market will get on with it well. Developers will also have a challenge, since the documentation is, apparently deliberately, incomplete when it comes to writing code. There is no complete reference, just lots of how-to examples that might or might not cover what you wish to achieve.

Nevertheless, there are flashes of brilliance in LightSwitch and I hope, perhaps vainly, that it does not get crushed under Microsoft’s HTML 5 steamroller. I set out some of its interesting features in a post nearly a year ago.

Put aside for a moment concerns about Silverlight and about Microsoft’s marketing strategy. The truth is that Microsoft is doing innovative work with database tools, not only in LightSwitch with its model-driven development but also in the SQL Server database projects and “Juneau” tools coming up for “Denali”, SQL Server 2011, which I covered briefly elsewhere. LightSwitch deserves a close look, even it is not clear yet why you would want actually to use it.

image

development, microsoft, mono, professional, silverlight, software, software development

C# vs C++ and .NET vs Mono vs Compact Framework performance tests

6 Comments

A detailed benchmark posted on codeproject investigates the performance of basic operations including string handling, hash tables, math generics, simple arithmetic, sorting, file scanning and (for C#) platform invoke of native code. These are the conclusions:

  • There is only a small performance penalty for C# on the desktop versus C++.
  • Mono is generally slower than Microsoft .NET but still acceptable, and all the benchmarks ran without modification.
  • The Compact Framework, an implementation of .NET for mobile devices, performs poorly.

My observations: this matches my own experiments. Why then do some .NET applications still perform badly? When Evernote switched its application from .NET to native code it got much better performance.

The main reason is a couple of issues that this kind of benchmark hides. One is the GUI layer, which involves a ton of platform invoke code under the covers. Another is the large size of .NET applications because of the runtime and library overhead; a lot more stuff gets loaded into memory.

One thing to like about Silverlight is that it is truly optimized for client programming and load time tends to be faster than for a desktop .NET application.

Note that for mobile these benchmarks suggest that C++ still has a big advantage. It would be interesting to see them applied to Silverlight apps on Windows Phone 7. As I understand it, the Silverlight .NET runtime in Windows Phone 7 shares code with the Compact Framework on Windows Mobile, so it is possible that the poor results for the Compact Framework would also apply to Silverlight on Windows Phone 7. Unfortunately developers do not have the option for C++ on Windows Phone 7.

.net, cloud computing, microsoft, silverlight, software development, visual studio

Common sense on Windows 8, Silverlight and .NET

31 Comments

I am wary about writing another post on this subject in the absence of any further news, but since there is a lot of speculation out there I thought it would be worth making a few further observations.

Will Windows 8 support Silverlight and/or some other variety of .NET in its new touch-centric mode? I will be astonished if it does not. Aside from other considerations, this is an essential unifying piece between the Windows Phone 7 developer platform and the Windows 8 developer platform, which from what we have seen have a similar user interface. For further evidence, try an internet search for “Jupiter” and “appx”.

Why isn’t Microsoft already shouting about this? A good question. Part of the answer is that Microsoft wants to get developers enthused about the forthcoming build conference in September, and is holding back information.

Another part of the answer is that Windows historically has kept .NET as a layer above the operating system, rather than as part of it. We saw this in Windows 7, where to take advantage of new features like jump lists or thumbnail toolbars, .NET developers had to use a supplementary Windows API Code Pack. The Windows team delivered only native code or COM APIs.

Admittedly, there are differences this time around. The Windows team is not just delivering native code APIs, but also an HTML and JavaScript API. This is a break with the past, hence the talk of a new platform.

When it comes to desktop applications, would not Silverlight or something .NET based be a better choice than HTML5? I can see both sides of this. On one side is all the effort Microsoft has invested in .NET and Silverlight over the past decade. As I’ve noted before, I see Silverlight as what client-side .NET should have been from the beginning, lightweight, secure, simple installation, but with support for C# and much of the .NET Framework which developers know so well.

On the other hand, I can see Microsoft wanting to tap into the wave of HTML5 development and to make it easy for web developers to build apps for Windows 8.

In the end, developers will most likely have the choice. That puts pressure on Microsoft’s developer division to provide strong tools for two different development models; but I think that is what we will get.

Is .NET itself under threat? As far as I am aware, Microsoft has no plan “B” in terms of web and application server technology, and its Azure cloud is largely a .NET platform though there are are efforts to support other things like PHP and Java. Further, this aspect of the Microsoft Platform is under Server and Tools which is 100% behind .NET as far as I can tell. We have also seen Silverlight crop up in the user interfaces for new server products like InTune and System Center. On the server then, there is no evidence for .NET doubts at Microsoft; and considering the trend towards cloud+device computing the server is now at the heart of most business application development.

That said, Microsoft has challenges in sustaining .NET momentum. It cannot afford to fail with Azure, yet other platforms such as Amazon EC2 have greater developer mindshare as cloud computing platforms. VMWare with its Java-based Spring framework is another key competitor. Microsoft was late to the server virtualisation party with Hyper-V. I also see declining market share for IIS versus Apache in Netcraft’s statistics, although these figures are distorted by millions of little-used domains that get shunted from one platform to another by major hosting providers.

Further, it seems to me that the fortunes of .NET on the server cannot be completely separated from what happens on the client. One of the attractions of .NET is the integration between client and server, with Visual Studio as the tool for both. Windows has lost momentum to Apple in mobile, in tablets, and in high-end laptops, making Windows-only clients less attractive. In that context, the decision of the Windows team to favour HTML5 over .NET is a blow, in that it seems to concede that the future client is cross-platform, though I expect there will be some sort of outcry when we see all the proprietary hooks Microsoft has implemented to get HTML5 apps integrated into Windows 8.

Therefore these really are difficult times for .NET. I do not count Microsoft out though; it still dominates business computing, and amongst consumers the Xbox may prove an important new platform as Tom Warren notes.

While I have reservations about Windows 8, it does demo nicely as a new touch-centric operating system and Microsoft surely has chances in the corporate world with new-style tablets that integrate with its system management tools and which run Microsoft Office.

Finally, the angst over the role of .NET in Windows 8 shows that many developers actually like the platform, including Visual Studio, the C# language, the .NET Framework, and XAML for building a rich user interface.

.net, apple, google, internet, javascript, microsoft, mobile, professional, silverlight, software development, visual studio, Web, windows

Considering Windows 8 as an HTML platform

4 Comments

Amongst all the fuss about whether Microsoft is deprecating Silverlight or even client-side .NET, it is easy to lose sight of the other angle on this. What are the implications of Microsoft embracing HTML and JavaScript as a new first-class Windows development platform? Here’s the quote again:

Today, we also talked a bit about how developers will build apps for the new system. Windows 8 apps use the power of HTML5, tapping into the native capabilities of Windows using standard JavaScript and HTML to deliver new kinds of experiences. These new Windows 8 apps are full-screen and touch-optimized, and they easily integrate with the capabilities of the new Windows user interface.

When Microsoft introduced IE9 with hardware-accelerated graphics, support for some key parts of HTML 5, and a new fast JavaScript engine, it was not only trying to recover ground in the browser wars. It also had in mind a new application runtime for Windows, for desktop as well as for web applications.

In order to achieve this, we can expect more hooks between the browser engine and the local operating system. There is potential security risk, but Microsoft of all companies will be sensitive to this and I would expect it to get the security right. The further implication is that some parts of a Windows HTML application will be Windows-specific. It is an “Embrace and extend” strategy, as I noted in this Register article back in September last year when former Silverlight product manager Scott Barnes broke the story of how the Windows team at Microsoft was favouring HTML and JavaScript above .NET.

The rationale for this is two-fold. First, I’m guessing that Microsoft thinks it will work better. Although .NET client apps are now commonplace, especially for custom business applications, problems like slow start-up and heavy memory requirements never really went away, though I would argue that in Silverlight they are almost eliminated.

Second, HTML and JavaScript is a universal programming platform. With the new model, any developer who can code a web page can also code a Windows app. Corporate VP Michael Angiulo said at Computex in Taipei:

Windows 8’s new application platform … is based on HTML 5, JavaScript and CSS, the most widely understood programming languages of all time. These languages form the backbone of the web, so that on day 1 when Windows 8 ships hundreds of millions of developers will already know how to build great apps for Windows 8.

These are both compelling arguments. Nevertheless, there are several reasons why making Windows an HTML platform might not be the instant hit that Microsoft will be hoping for. Here are a few:

  • Microsoft’s Visual Studio is .NET oriented. It does have a web design tool, Expression Web, which is OK but still falls short compared to Adobe Dreamweaver. Web designers tend to use Dreamweaver anyway, thanks to Mac compatibility and integration with other Adobe tools. Even Dreamweaver is not great as an application development tool, as opposed to a web design tool. Tooling is a problem, and it is fair to say that whatever goodies Microsoft comes up with in this area will likely be a step back compared to what it already has for C# or C++.
  • Standards are a mixed blessing if you are trying to sell an operating system. If Microsoft does such a good job of standards support that the same apps run with minor tweaks on an iPad and on Android, users may do just that. If Microsoft encumbers the standards with too many proprietary extensions, the universality of the platform is lost.
  • Windows plus HTML and JavaScript sounds a lot like Palm/HP WebOS, which has gained favourable reviews but has yet to take off in terms of sales. Otherwise, Palm would not have been taken over by HP.
  • The question of whether HTML and JavaScript will really take over app development is open. I certainly hear voices saying so. I interviewed Nitobi’s president André Charland, in charge of PhoneGap, and he makes a good case. On the other hand, App development today is still dominated by platform-specific development, Objective C for Apple iOS and Java on Dalvik, the Google Android virtual machine.
  • The standard in HTML/JavaScript app platforms is not Microsoft’s Internet Explorer, but WebKit, as used in iOS and in Google Android and Chrome. Microsoft did great work in standards support in IE9, but so far it has not stopped its browser share decline. Worldwide figures from StatCounter show Internet Explorer in continuing slow decline overall, and Chrome still growing and set to overtake Firefox in a year or so.

In other words, there is little evidence that embracing HTML and JavaScript as an app platform will ensure success for Windows 8.

That said, other factors count for more. Developers will go where their customers are, and if Microsoft turns out a version of Windows that wins substantial market share in the emerging tablet market as well as on traditional notebooks, the new platform will be a hit.

The risk though is that the market will continue to perceive Windows as an OS for desktop and laptop, and look to iOS or Android for mobile and touch devices. The dual personality of Windows 8 may count against it, if it means devices that are compromised by having to support both user interface models.