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.

VN:F [1.9.18_1163]
Rate this post
Rating: 8.5/10 (26 votes cast)
Common sense on Windows 8, Silverlight and .NET, 8.5 out of 10 based on 26 ratings

Related posts:

  1. A common-sense introduction to software factories
  2. Silverlight in Microsoft products – Silverlight the new Windows runtime, HTML 5 the new Silverlight?
  3. Windows 7 Service Pack 1 install failures common?
  4. Windows Phone 8 will run Windows 8, with Silverlight centre stage?
  5. Making sense of Microsoft’s Windows 8 strategy

31 comments to Common sense on Windows 8, Silverlight and .NET

  • soren

    There are leaked betas… and those betas indicate that there will probably be some sort of AOT compiler for .NET on the client side… and that native programmers will be using javascript to write their GUIs.

  • I agree with your assessment that we will likely see choice for the developer here. I think Silverlight might replace win32/winforms as the native UI api with HTML5 along side it.

    There is absolutely nothing wrong in support HTML5 apps “natively” in Windows, but just because you do that doesn’t mean you abandon what you already have.

    I have written it many times before, the .Net programming model experience is so much stronger than the HTML5/Javascript model and that would be the biggest turn off.

    But then again, if they could make the HTML5/Javascript programming experience as strong in Visual Studio as the .Net is, does the language matter that much, I guess not, but to get all the analysis tools and performance tools to work effectively on a fundamentally broken language such as javascript is not an easy feat.

    Then again, if customers have to give up their “right” to decide when to deploy an application (as it gets deployed when the provider choses to) your cycle of failure to correction is so much smaller that upfront effort can largely be reduced, perhaps it is a gain in the end.

  • Chui Tey

    All this makes me wonder whether we are seeing all this because the DOJ antitrust has expired, and MS is back leading the charge with deep integration of HTML into the OS?

  • @Chui: I find it kind of funny that Microsoft has to litteraly allow and promote all browser into their OS, while others, like ChromeOS gets a free pass. What will all the browser makers do if ChromeOS because the standard?

  • Can anyone please remind me why Silverlight is better than Winforms for builing native Windows 8 apps/applications? Whoever at Microsoft decided that all windows developers wanted to build cross platform apps, I hope he has retired. Apple iOS and Android have been hugely successful with native apps of late. Has Microsoft lost focus and forgotten that their most successful business application suite, Office 2003/2007/2010 is a native windows app and that its Apple Mac version of office is a different code base? Are MS intending to rewrite Office in HTML5/JS, or Silverlight, or WPF? Of course not: So please return winforms to 1st class citizen status for building native Windows 8 apps in VS2012.

  • pingpong

    .Net has been a massive failure in terms of consumer-facing client apps. It has it strongholds on the desktop LOB market, but Windows has been largely missing the explosive app growth in the consumer section – partially because of heavy emphasis on .Net on the desktop as preferred tech coming from the DevDiv. Essentially, the WinDiv sees no chance that .Net programmers can rejuvenate the platform, hence the shift into native (and by this I mean C/C++ for high perf) and HTML/JS (to tap into the designer potential).

    I expect at //build/ we’ll see the examples of well performing apps manipulating HTML DOM from native code + platform specific hooks accessible from JS in IE10 for NUIs.

  • >>Can anyone please remind me why Silverlight is better than Winforms for builing native Windows 8 apps/applications?

    Because it is. XAML makes layout, transitions, graphics, styling, etc so much better that native Windows Forms it is not even funny. I guess you have yet to use XAML in WPF or Siverlight or you wouldn’t be asking the question.

    BOb

  • Vic Klien

    @pingpong:
    I think you nailed it!

    Elaborating a little:
    Neither WinDiv nor DevDiv are likely to publicly voice such a direct message, even though it’s true. But getting all devs to understand and accept that reality would be good.

    Can you imagine either Sinofsky or ScottGu publicly saying the following? “SL/WPF/.NET are OK for LOB apps, but for consumer apps or in the OS UI their bulky memory footprint and slowish load times won’t fly. That’s why we haven’t used them in the OS UI or Office .”

    Which is not to say SL/WPF/.NET are crap or a bad choice. Most 3rd party devs on Windows are doing “LOB” type apps. SL/WPF/.NET make lots of sense there. It is these same 3rd party .NET devs who are freaking out (probably more than necessary), in the absence of a clear, honest story from MS.

    Vic

  • Vic Klien

    @PilotBob:
    Even though I’m a SL/WPF dev myself, I’d have to agree with Garry that its possible to build a pretty good LOB app in WinForms today.

    This gets to one of the other weaknesses of SL/WPF: They have a steep learning curve. Although LightSwitch may partly address this, its fair to say SL/WPF have not taken the broad MS dev market by storm. Not in the way that something like VB6 could.

    A well executed “embrace and extend” of HTML5/JS by MS could possibly get some of that back.

    Vic

  • Andrius Bentkus

    You know, I thought about this.
    If .NET dies, mono lives on, if .NET doesn’t die, mono lives on.

    If you really like .NET/CLR and C#, you will not up give so easily!

  • @Garry:

    My answer to that is data binding, which gives XAML its power and disconnects the developer and designer work flows in a very neat thin API between the two.

    It is the same disconnect that HTML/CSS gives, except it is much better and more powerful model in SL. You can tap the design power.

    This is why it would be bad to drop the SL model.

    But yes memory consumption is an issue and has been since the day someone invented Java and said allocations are cheap… Turns out nothing comes for free…

  • tim

    @pingpong good comment, a lot of truth in this I suspect.

    Tim

  • Crusty

    Anyone who can’t see the difference in what SL/WPF can deliver above and beyond WinForms hasn’t done anything significant with either technology.

  • Crusty, what rubbish. We have a million line .Net (winforms, web services, Asp.Net, SQL, reporting, business intelligence, cloud API…) commercially succesful cloud based LOB app suite with thousands of customers. My point is that when we have built components in Silverlight, they perform poorly and do not even support ADO.Net, the principal API For data driven LOB applications.

    PilotBOB, I do NOT want to write markup. I write windows based LOB applications focused on user requirements and usability. Silverlight offers me no benefit for windows applications. If writing markup is the only benefit of SL over winforms, then you and MS have failed to provide a reason, or technology stack, respectively to improve the winforms model.

  • Bill Woodruff

    “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 hypothesis would be that Microsoft is not a monolithic corporate ‘culture’ with a ‘single intention,’ but, rather, a collection of competing tribal entities (warring feudal city-states ?) which at any specific time may be projecting multiple public ‘faces.’

    “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.”

    This hypothesis might account for the lack of content about devtools in recent presentations about Win 8 by senior executives of MS, but that would not account for the lack of news about future changes in devtools from other sources. And note: as Pete O’Hanlon (of CodeProject fame) recently commented on his blog: at the present time many Microsoft MVP’s … historically important sources of information to developers … are under strong NDA’s with MS now.

    As an ‘outlier on the bell curve’ hypothesis: perhaps MS is busy hatching something(s) radically new, and it’s not clear yet, technically, if it’s going to ‘fly.’ Aside: I pray whatever embryonic technology initiatives may reach live-birth: may they utter their first screams not looking like Darth Vader’s own user interface (i.e., Blend).

    And last, but not least, one might question if a lot of the apparent controversy here is just ‘static,’ produced by the surplus number of technical talking-heads and twitter-freaks that daily produce a tidal wave of speculation, some of those ‘owned’ by Microsoft (Thurrot), and others only ‘leased’ on an ad hoc basis.

    ECMAScript (mis-named ‘JavaScript’), even extended by brilliant innovations, like jQuery by John Resig: Cinderella-gone-to-the-ball … or … dead-end ?

  • Paul M

    Dear clueless pundit,

    Script#…

    Midori

  • Bob M

    Come on people, Microsoft already has major issues trying to ween business users off of Windows XP. They even had to give a virtual copy of XP to Windows 7 business users. If they want to sell a new operating system to businesses and don’t forget it is the business users that keep Microsoft’s OS out front they have to support legacy applications.

    When friends ask what kind of computer to buy and they are going to do nothing but surf and use the web I tell them it does not make a difference. If you want to run business applications for the most part you need Microsoft Windows.

    There is no way Windows 8 will not support .NET not on the desktop version anyway. Business users will just keep using XP or Virtual XP. Unless Microsoft wants to have everyone run a virtual machine XP under HTML 5.

    IMHO

    Bob M.

  • Gary, thanks for mentioning ADO.net. When SL first was being announced an I noticed it’s absence I started immediately inquiring about it. The people I spoke to at MS were all very dismissive of its necessity. ADO.net had fallen out of fashion but unfortunately MS forgot that fashion is not what LOB developers care about, getting the job done is. Many had made significant investments in ADO.net based application layers and to omit this from Silverlight was a mistake.

    This is one of my top gripes with MS these days, they drop support (maybe not officially but in willingness to fix things) for things so quickly that by the time you roll out a big product it is now using completely out of fashion technology. Then you find a bug in MS technology and are basically told that you shouldn’t be doing it “that way” anymore and that the given technology is in maintenance mode so they won’t fix the issue you found.

    I hope this isn’t another case where this is going to happen, that WPF and SL will be supported but anyone using them in 3 years will be looked at crosseyed when they have an issue that needs to be addressed for continuing to use “that old technology.” I think that’s where a lot of the fear comes from in the world of LOB developers, we’ve seen this happen before.

    Sean

  • Mike

    silverlight is nice, but I hate this direction of cloud computing. I don’t want my browser to be my x windows, i do not want SaaS as my only way to use software. I want my privacy and security in my hands, not some anonymous admin.

  • JohnnyG

    @Garry
    (Sorry, Guys. I know this is off-topic). The truth, Garry, is that it’s not a matter of better/worse. It’s a matter of the type of user experience you want to deliver to your customer and the ease with which you can create that. WinForms is still an excellent choice for apps with a more traditional user experience. If you want to create a UI with a more modern experience using controls with a customized appearance and possibly some animation, SL & WPF are better options.

    Your comment: “I don’t want to write markup” is valid, but keep in mind that it’s as subjective as the comments that say SL is just better because it is. It’s a preference. The markup is a very powerful tool for laying out interfaces. I have found it to be quite intuitive. The more I used it, the more I liked it. Being able to re-style the controls is also a fantastic feature. That said, there have been many times that I wished for the simplicity of WinForms type controls because I didn’t want to have to restyle a control just to get the same feature that was already built into a WinForms control.

    The databinding is amazing. There are quite a few things that you can do with just a few lines of markup that you’d have to write whole class libraries to do in WinForms. So don’t be so quick to criticize the markup. The databinding makes it amazingly powerful. And then there’s animations. If you want them or need them, WPF/SL handle them very well. If not, you probably won’t miss them.

    So again, it comes down to the experience you want to deliver. SL/WPF provide incredible tools to easily create powerful applications with smoother, more modern UIs. If you don’t care about that, WinForms can easily deliver the more traditional no-nonsense apps. You can probably throw together a WinForms UI very quickly – so that’s a plus. However, depending on the app, many users will thank you for creating a more modern style UI. Most of mine have appreciated it immensely. As with all things, you have to gauge your audience.

  • JohnnyG

    @Bob M
    “There is no way Windows 8 will not support .NET not on the desktop version anyway. Business users will just keep using XP or Virtual XP. Unless Microsoft wants to have everyone run a virtual machine XP under HTML 5.”

    I tend to agree with you, Bob. I don’t think .NET is going away. I know that a lot of developers are worried that SL/WPF/.NET are going to take a back seat for development. I don’t think that’s the case for business apps. But I also think there’s a lot of truth to PingPong’s statement. They never really were ‘front seat’ tools for consumer apps – and that’s what MS is going after.

    MS needs to make some headway in the mobile/tablet market. While those devices are definitely making inroads in business, they were launched as consumer devices. That’s the market that’s growing. MS recognizes that, if they don’t start making real progress there and soon, they never will. That market could eventually supplant the business market that keeps them going. So the consumer market is where they need to focus.

    Now, let’s face it, fart apps may not get much work done, but that doesn’t stop them from selling like hotcakes on the app store. Most consumer apps can easily get by on HTML5/javascript. There’s a huge developer base that knows those tools and MS needs to get them making apps for their platform. They can either say “Learn .NET” or they can say “Use what you already know.” They are wisely saying the latter.

    If MS can attract those developers to the Windows platform in addition to the army of business developers that are already there, then they have a chance of making real progress with consumers. That’s what they need to do and they know that.

  • bobby

    1. XAML with its wonderfull things like databinding, theming, animation, templating,… results in far more elegant architecture then winforms

    2. why does a developer, who apparantly works on an LOB app of a million lines of code, want ado.net support IN silverlight? Have you ever heared of layering your application? Your silverlight is not supposed to access your database.

    3. on topic: people who think that .net is “dead” need to wake up and small the lunacy. http://lmgtfy.com/?q=jupiter+xaml

  • Doug

    @Gary, You are being myopic, ignorant and rude.

    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.

    @Everyone else,
    .NET isn’t going away.
    Assuming MS will push an anti-.NET environment in Win8 (and it won’t), Win 8 has to first be a success for enterprise to see the .NET fruit shrivel. I don’t see that happening. This OS revision is aimed entirely at consumers, and even there it will be a jagged pill. MS is simply trumpeting what it thinks the mobile world wants to hear and leaving out everything else.

  • agendaFX

    “and its Azure cloud is largely a .NET platform though there are are efforts to support other things like PHP and Java”

    It’s an altruistic lie that M$ will support something that could mess up with their strategy to dominate with their proprietaries. But hey it’s nice to claim support for something that ain’t there just for sake of bigger market share inside non tech savvy population.

  • Terje

    @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.

  • Terje

    @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.

  • @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’.

  • 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.

  • falken

    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!

  • 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.

    http://arstechnica.com/microsoft/news/2011/06/windows-8-for-software-developers-the-longhorn-dream-reborn.ars

    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.