Common sense on Windows 8, Silverlight and .NET

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.

31 thoughts on “Common sense on Windows 8, Silverlight and .NET”

  1. @Garry/Sean ADO.Net? You must be kidding. Yes, for a two-tiered application, ADO.NET is important, but SL is not about two-tiered apps, it is about three-tiered apps, where SL in the browser talks to a middle-tiered back-end. You don’t do that over ADO.Net. You don’t even think about it. It would be absurd. Your web server can talk ADO, but the SL app running inside the browser talks to the web server, and ONLY the web server. It can use JSON (great support), SOAP or REST or whatever you want. Seriously. Your argument is just silly.

    If you want to create WPF apps that use ADO.Net you don’t use SL, it isn’t the right tool for the job. Lamenting lack of ADO.Net support in SL is like lamenting that support in JavaScript.

    Again, you can continue using ADO.Net in WPF applications, which is similar to building standard two-tiered LOB apps, but having ADO.Net support in the browser would be, for one, a security nightmare.

  2. @Doug – excellent point. Using ADO.Net in ANY client app, even a desktop one, is a clue that the developer in question is ready to put out to pasture. Even native desktop apps should adhere to good practices of separation of concerns. ADO in a client app is a Bad Idea(tm).

    Me, my self, my client apps have been using SOAP for a while, but moving to REST and JSON these days. Both are very well supported in .NET. Just separating into a business intelligence server and a “dumb-ish” client using REST/JSON gives me future flexibility that would be unavailable had I been dumb enough (yes, it is dumb) to have the client interact with the data tier directly (ADO).

    Way back when we were doing Delphi apps on the client, they were all talking to a middle layer, also written in Delphi, for all of the business intelligence. Lately we have been asked to move said middle layer over to a Java-based platform for scalability reasons. The Java stuff scales up better than our home-grown middle layer. Guess what, we can accomplish this, piece by piece, function by function, with ZERO changes to our client apps. I would love to see someone making such a transition with a two-tiered solution with ADO functionality in the client app.

  3. @Doug,

    Do you know how to seperate your concerns? Doesn’t support ADO? Are you serious? Do you really believe your client app should be using ADO? Oof, I hope your customers aren’t reading this. Wow.

    Errr… so for every database accessing application, you only use a webservice/service tier, which communicates over a network (or local loop) and serializes data back/forth over xml or json? That’s your idea of _solid software_ ? Well, for some applications, that’s indeed great. However, for others, desktop apps which access ‘a’ database, it doesn’t have to be, as cross-aggregate root data manipulation is perhaps more efficiently done in a 3-tier application on the desktop, instead of an application accessing a service. after all, the whole SOAP story that everything is a service has shown there are severe downsides to that approach as well.

    ‘separation of concerns’ isn’t about ‘let’s make for each concern in my application a different _application_. Because that’s the story you try to sell.

    I agree that a UI tier shouldn’t execute queries. I disagree with the statement that the UI tier has to be a separate application altogether and has to communicate with a service to do data manipulation, as I don’t see why that’s ‘better’.

  4. Thanks @Frans.
    To @Doug/@Terje: You seem to have read a few books and built a couple of small sample projects. You can not possibly believe that multiple separate services is the ideal architecture for every LOB application? Does anyone remember MS MTS? What a load of rubbish for use in multi-tiered LOB systems. Unscalable, unreliable, impossible to maintain piece of junk.

    A well designed application implements logical layers, separating concerns to help coding, testing and maintenance. Only someone inexperienced would place each tier on separate servers in every case without consideration of a few basic requirements:

    1. Performance – your multiple servers will seriously degrade performance.
    2. Extensibility – how can your multi-tiered servers cope with the addition of new fields and entities to the schema and application GUI?
    3. Maintenance – if deployment is too complex to maintain, your app will be switched off.

    To answer your ADO.Net point explicitly, the data layer talks to the database via ADO The GUI talks to the data layer. If the data layer is on the same machine as the GUI, you can utilise the SQL/Oracle server to its maximum performance and flexibility. Thats the best performant app for Windows 8. Silverlight lacking ADO.Net means you cannot pass high performant data sets from your middle tier servers to the client, instead you have to re-invent the wheel (again). Why? Because the inexperienced script-kiddies at MS who designed SL/WPF, have never written commercial LOB apps for windows.

  5. WinForms? Managed wrapper on top of Legacy win32, descendant of even more legacy win16? Heh, try to zoom winforms checkbox on HD display for LOB apps used by almost blind hard-working seniors… Yes, chane DPi… ugly as hell… win32 UI is dead. LightSwitch, howgh!

  6. Perhaps this is what is going on. I again restate that one thing Microsoft always has been about is choice for the developers, I don’t think that is going to change.

    If they were to pull this off… It will be as leapfrogging as the 2008 PDC. If they actually manage this they will almost have added the last brick for the new platform we have seen being built the last years, and being started with windows azure (or actually Hyper-V).

    MS seem to be building for the future instead of the next quarter hot product syndrome. Perhaps it will pay off.

Comments are closed.