This is What Microsoft Said About PWAs at Build 2018

Posted on May 12, 2018 by Paul Thurrott in Cloud, Dev, Windows 10 with 71 Comments

This is What Microsoft Said About PWAs at Build 2018

Microsoft didn’t promote Progressive Web Apps (PWAs) as heavily this week as Google did. But there is some great information to be had.

You can find a complete list of Build 2018 session videos that include Progressive Web Apps content on the Channel 9 website.

Looking this over, there is only a little new information once you get past the “here’s what PWAs are”-type sessions, like Designing for Everyone: Building great web experiences for any device, which is worth watching if you’re still not sure what PWAs are all about. There are a handful of sessions featuring the developers who created certain PWAs, like Starbucks, Twitter, and Cboard. And then there are a handful of Windows developer-specific sessions, like Building Progressive Web Apps for Windows devices.

I think the issue here is that Microsoft is still trying to communicate what PWAs are, exactly, to developers. Meanwhile, Google is already moving on to describing new features.

Microsoft’s developer base needs to get on board with this technology. According to Microsoft’s Aaron Gustafson, “mobile ate the desktop back in October 2016.” I would move the needle back almost a decade: As I’ve noted in the past, the iPhone was released in 2007, and it was the asteroid that killed the Windows dinosaur. And Windows 8, released in 2012, put the final nail in that coffin.

What he’s referring to, of course, is the point in time at which mobile web traffic overtook desktop web traffic. That’s a subset of the “mobile first, cloud first” trends that define the current generation of personal computing by my own measure. And to be clear, this is just the web. Actual usage on mobile devices—and engagement—is much higher than is the case on the PC desktop.

But his point is sound: When you compare web traffic across platforms, you see that mobile doesn’t beat desktop by a wide margin. And in some important sub-markets—like news and finance—desktop traffic actually remains on top. And desktop users tend to spend more time on websites than do mobile users. The engagement is actually higher for PWAs than for mobile apps, something each of the PWA developers noted above mentions in their respective sessions.

Put simply, when it comes to the web, the desktop matters. And that explains, in part, why Microsoft has embraced PWAs.

As for Windows developers specifically, Jeff Burtoft’s Building Progressive Web Apps for Windows devices is the key session. (I met Jeff in person briefly at Build and we tried to connect later, but failed. I’m hoping to speak to him again soon.)

Skipping past all the important but oft-repeated information about PWAs, Jeff’s session provides a few interesting details about the future of the platform on Windows 10.

Microsoft wants Windows to provide the best PWA experience of any OS platform. PWAs are natively supported in Android and Chrome OS today, and they will see some form of native support on macOS and iOS soon. But Microsoft wants Windows 10 to offer the best possible experience for running PWAs of any of these OS platforms. This is consistent with Microsoft’s goals for Windows apps, generally. Native apps on Windows should always be more powerful, more usable, and more feature-rich than the same or similar apps on other platforms. The progressive nature of PWAs makes this possible: Microsoft can extend the capabilities of PWAs with Windows-specific features.

Windows 10 provides PWA with support for a number of native features. Today in Windows 10 version 1803, developers can add native OS features like password integration, Share integration, notifications and Action Center integration, Start tile pinning, jump list support, Store reviews/feedback integration, Timeline support, and protocol handling. Yes, that last one means that an email PWA could be configured as your default email client in Windows 10.

PWAs can access native code on Windows 10. This one is very much developer-focused, so I’ll dumb it down a bit. One of the jabs against PWAs is that they’re not really “native” apps and thus won’t perform as well as apps that are written in languages like C# and C++. That’s mostly nonsense, actually, but Microsoft also PWAs on Windows 10 to call C# and C++ code (via a bundled WinRT object or portable class library) in order to improve performance where necessary or, more likely, in order to reuse software code you’ve already written. Burtoft calls this “PWA with a splash of native.” And this is how Microsoft built its PWA Teams app, by the way.

They’re not done. The initial release of PWA support in Windows 10 is just the start, Burtoft says. Additional PWA features are coming in future releases of Windows 10. Including, yes, the ability to install PWAs from the web using Microsoft Edge. (This is expected in Redstone 5.) Microsoft is also exploring something called Fluent Web, which will bring the Fluent Design System to PWAs.

Tagged with ,

Join the discussion!

BECOME A THURROTT MEMBER:

Don't have a login but want to join the conversation? Become a Thurrott Premium or Basic User to participate

Register
Comments (71)

71 responses to “This is What Microsoft Said About PWAs at Build 2018”

  1. Avatar

    rmac

    I'm amazed at how little coverage Blazor and WebAssembly got when these combined technologies should bring about a very significant game changer for MS devs. Daniel Roth talked about it end of his ASP.NET talk but I felt it was scant. Sounds a bit like the old MS guard: milk an ageing technology (UWP which is going nowhere) instead of getting this thing out now, so I'm quite gutted about the whole Build thing. I'm not really interested in AI, want to see what's happening on the UI stack and I found the whole show lack lustre and a re-hash of things a previous e.g. embedding UWP controls in WPF apps - weren't WPF controls embeddable in WinForms?

  2. Avatar

    Rob_Wade

    In other words, one of Microsoft's mantras is "PWAs are better on Windows". Hmm, sounds like the failed "better on Windows phone' mantra they tried. And bailed on. Or, rather, really never meant in the first place.

  3. Avatar

    SherlockHolmes

    Sorry Paul, but you are too optimistic what the future of PWA on Windows is. PWAs is just another way to keep the Microsoft Store alive. Why should anyone install PWA when either


    a) the App is only a wrapped website or

    b) the App does not have the full feature set that the normal Win32 App has


    And I dont buy the crap that a PWA or UWP is easier to Update. Nobody proved that to me in any way.

    • Avatar

      Daekar

      In reply to SherlockHolmes:

      Well, I am not sure about the developer experience, but I have almost completely switch to Store apps on my machines and the update process just happens. My tray isn't filled with helper programs, and uninstalling is effortless. I don't know if performance is the same or not since I have only gotten one high demand program (Tomb Raider) but that app ran great.

      • Avatar

        hrlngrv

        In reply to Daekar:

        . . . My tray isn't filled with helper programs, and uninstalling is effortless. . . .

        I use the portable versions of Firefox and Chrome, and there are no helper programs (or background services) and uninstalling only requires deleting their directories. As for updates, they check whether updates are available when they launch, let me know when there are, and let me update when it's convenient for me.

        • Avatar

          lvthunder

          In reply to hrlngrv:

          Some of us need more than just a web browser. I have update processes for Adobe, Autodesk, iTunes, Dropbox, and Java. Those are just the ones with update in there name. Actually there are two for Adobe. One for Acrobat and the other for the rest of the Creative Cloud Apps.

        • Avatar

          Daekar

          In reply to hrlngrv:

          Sounds like those are an excellent compliment to the Store apps since neither are available via the Store. Are there any functional differences between the installed versions and the portable versions?

          • Avatar

            hrlngrv

            In reply to Daekar:

            No significant differences for Firefox. It can even update itself.

            Portable Chrome can't update itself, but otherwise I haven't notices any limitations. Interestingly, web apps pinned to the desktop and opening in their own windows through Chrome do appear in Sets tabs. (Well, at least Google Maps, only one I've tried.)

    • Avatar

      lvthunder

      In reply to SherlockHolmes:

      Not every app needs the full feature set that a normal Win32 App has. With a PWA everyone is using the same version. That would make things easier to support.

  4. Avatar

    skane2600

    Adding features that are platform-specific is in direct opposition to the purported PWA characteristic of platform independence. Web apps aren't truly WORE, but they come a lot closer than anything that runs native code.


    I suspect that having separate native Windows, MacOs, iOS etc apps is a simpler development model than writing a single PWA that combines multiple platform-specific aspects into one big coupled mess.


    Of course for desktop OS's like Windows and MacOS, web apps are probably the best approach in most cases.

    • Avatar

      behindmyscreen

      In reply to skane2600:

      But that is up to the developer....and maybe, as Paul said, the developer wants to use existing native functions....allowing that isn't wrong.

    • Avatar

      hrlngrv

      In reply to skane2600:

      To be charitable, I figure platform-specific features would be dead code on other platforms. Presumably not hurting performance beyond using up disk storage and maybe a bit of RAM. Could PWAs handle platform specificity via something like optional modules loaded on demand?

      As for WORE, scripting languages may get there first.

      • Avatar

        skane2600

        In reply to hrlngrv:

        The whole point of cross-platform for the user is that they can use the software without regard to which platform they are using. Delivering different features for different platforms goes back at least 30 years. Nothing new.


        WORE will never be achieved regardless of the language used.

  5. Avatar

    justincrawford

    Microsoft needs to release their own client-side PWA framework that is tightly integrated with Visual Studio. I understand that you can build PWA's without tying yourself to a framework, but any serious application will be looking to Angular, React, Vue.js, Polymer, etc. All of which are fine, except none are supported and maintained by Microsoft. Ya, ya... you can use these frameworks with ASP .NET Core/MVC projects, however, none of the documentation talks about any of the quirks you run into using them in Visual Studio. Give us a MS supported client-side framework, with F1/MSDN documentation and examples. Project templates for React/Angular aren't enough.

  6. Avatar

    Kadren

    Well, Build 2018 was a letdown in general. This is especially silly, of course.

  7. Avatar

    Jules Wombat

    This is dumb.

    "capabilities of PWAs with Windows-specific features." We have all been down this road before, and this approach will be rejected by developers and users. We all want cross platform compatibility, with any PWA must run on Android and iOS first and foremost, Windows, MacOS, Linux desktops are secondary.

    Suggestions of Windows specific PWAs are dead duck walking.

  8. Avatar

    JustMe

    I do not have the optimism for PWAs that you do, Paul, largely because I simply dont get them. My desktop/laptop is not my phone. PWAs may work presented front and center with Android (and as you point out, soon on IOS), but those to OSs are mobile OSs, something which Windows 10 is not. If I am on my desktop or laptop, I'll use a browser, not an app. PWAs work on a phone because of the lack of real estate, and in general, the browser experience is less satisfying than on a regular PC. Where are we to get these PWAs, the Store? Color me cynical and skeptical, but I just dont see it.

  9. Avatar

    skane2600

    "Microsoft can extend the capabilities of PWAs with Windows-specific features."


    Perhaps they should name their implementation PWA++ to reflect the obvious parallels to J++.

  10. Avatar

    edboyhan

    What I'd really like to see from Microsoft is a PWA light email app that replaces the Windows 10 mail app, outlook.com, and OWA ( BTW those apps also do calendar and people). This PWA should include the best features of the 3 antecedent apps. This would remove some outlook name confusion, and reduce 3 lightweight mail apps to one. Oh, and of course this would eliminate all the UI inconsistencies. They could also use this PWA on Android and IOS (so five apps to one :grin).

    Is there any hope that Microsoft might do this?

  11. Avatar

    illuminated

    Amazingly negative comments. Bunch of sick people (or bots) here.

  12. Avatar

    kirtigupta

    Nice conversation you publish your blog its really informative post, I search this information many blog but I don’t understand this topic but you define this subject very well know. Love Marriage Problem Solution

    Love problem solution Intercast love marriage problems

  13. Avatar

    Stooks

    "Microsoft’s developer base needs to get on board with this technology".


    Hmm lets hope they do so better than Windows Phone, Windows RT and UWP..or even UWP wrapped Win32 apps.


    "Burtoft calls this “PWA with a splash of native.” And this is how Microsoft built its PWA Teams app, by the way.


    And they have already deviated from the true path of PWA's. Doing this "splash of native" ensures that Microsoft PWA apps will run better on Windows. Unless of course they do a splash of native on other OS's.


    Microsoft future is the cloud and subscriptions, which will make the truck loads of money. Everything else they do is in a free fall right now.

  14. Avatar

    behindmyscreen

    The number of Microsoft trolls is amazing.

  15. Avatar

    MutualCore

    As always MS misses the boat. While Google is putting PWA front & center, MS thinks cloud, cloud, cloud and MS Biz Server.

  16. Avatar

    Bats

    I just have one question.


    Uh....what exactly is new here?


    The way I am reading this, nothing is new. Seriously! About two years ago, Nadella and Microsoft were talking up a storm about AI. Today, ... nothing. Microsoft is talking about PWA, like they did with Augmented Reality. Today, pretty much used by everyone and none of them come from Microsoft. Therefore, all this PWA talk reminds me that old commercial (and Walter Mondale) with that saying, "Where's the Beef?"


    • Avatar

      roastedwookie

      In reply to Bats:

      They were barking about bots last year like crazy, and fanboys all over about how apps will die and bots, the future, will save the app store and revive windows mobile :)) That was the big thing that MS was counting on...now it's about PWA, that will somehow gain traction, but on other platforms as usual...Next year it will probably be about cloning a horse into a unicorn

    • Avatar

      MutualCore

      In reply to Bats:

      Every year MS plays the shell game. The previous year's BIG THING failed miserably and so they have to throw in the NEW THING. The NEW THING will fail in 2018 and then in 2019 they will have yet another NEW THING that will fail, on and on to the year 3000.

  17. Avatar

    cybersaurusrex

    I don't expect PWA's to have much impact on Windows. Meaning, they're unlikely to change the way people use Windows.

    • Avatar

      Maelstrom

      In reply to cybersaurusrex:

      Quite the contrary. On Windows, if when going to a website visited on a regular basis, users are being told via a pop-up notification that, with a simple click, it is possible to check stuff offline while on the go, receive notifications while also benefiting from a more app-like UI (i.e. without the browser one) and without having to launch the browser for that purpose again, then people will be enticed to use PWAs instead of the browser. That way, I bet many users will change their habit to get a more modern, mobile-like experience!


      There, I'm convinced that PWAs will have much more impact than say, both HTML5 and Responsive design. And let's not forget they both have become the norm these days… I'm expecting no less from PWAs on Windows.


      • Avatar

        skane2600

        In reply to Maelstrom:

        You mean people won't have to launch the browser they're already running?

        • Avatar

          rockycpa

          In reply to skane2600: We turned our firm qbixas.com wordpress site into a PWA. Pretty much a wrapper, but after it is installed you don't need the browser at all. On windows 10, I haven't found the mechanism yet to install it unless Microsoft does it through the store, however in Chrome on an Android device, it asks you if you want to install it. On the Iphone, you open it in Safari and click the share button and then click "add to home page". It doesn't feel like much but it actually installs it. If you look at the app vs in Safari, you can see the difference. This is still in the early stages. The iphone is currently allowed to download about 50 meg of your site and has other limitations.


          • Avatar

            Stooks

            In reply to rockycpa:

            So what advantage does this give you in your example? A dedicated icon on the iOS desktop for your site vs going to safari and then going to you site?


            You could already put a webpage on the iOS desktop, pin the page. Now if you made a native app for iOS.....

          • Avatar

            skane2600

            In reply to rockycpa:

            It seems you're missing the point. Just because a few sites implement PWAs doesn't mean that users won't have their browsers open to accommodate the vast majority of sites that don't use PWAs. So, at least on a PC, Mac, or Chromebook not having to open a browser really isn't a significant selling point.


            Now avoiding the browser on a smartphone is nice because browsing on smartphones suck. Native apps clearly make that possible and perhaps to some degree PWAs although how effective they work in general and whether they actually save development time over native apps remains to be seen.


            BTW, I'm not the one who voted you down. I very rarely mark someone's comment down just because they disagree with my post.

            • Avatar

              rockycpa

              In reply to skane2600: Hey the good thing about being an accountant is that expectations in this area should be low. :) I wasn't actually disagreeaing with you though. I do think on a mobile device there is an advantage to having an icon on the screen.
              In our own case, we upgraded our site for several reasons. #1 is I was that I was just curious about it. We used the developer tools/audit in Chrome to evaluate our site. We found that from google's standpoint, a PWA was a little about the app part and very much about having a faster, more legible and more secure site for low bandwidth smartphones. We spent 2 days optimizing images, text and other things to make our site more compatible with low bandwidth smartphones using the recommendations of the chrome audit tools. What we ended up with was a much faster and more secure site that is better across all browser types and devices. It also happened to be a PWA. I don't think anyone is going to actually care about having our site in an app. They will always come to it in a browser, but by going through the process, we have a much better site that google and bing will hopefully rank a little higher.
              I think that many apps in the app stores don't need to be apps, but most websites could be improved by going through the process. This probably helps all operating systems if they have higher quality sites and less true apps.


        • Avatar

          hrlngrv

          In reply to skane2600:

          Maybe people will be running dozens of PWAs at the same time rather than dozens of browser tabs or mix of browser tabs and locally running non-PWA applications.

          Would every PWA use a common service worker service, or would each PWA have its own full service worker foundation? I gotta wonder about the efficiency of PWAs.

          • Avatar

            skane2600

            In reply to hrlngrv:

            There are a lot of unanswered questions. It seem to me if there's one common service it has the potential to be bloated and if there are many smaller services, they could slow the system down.


            I also imagine that every service worker has to be platform-specific. If not, who is going to enforce a common interface across multiple platforms?


            Maybe people with more knowledge can answer those questions, I have to admit I'm not that motivated to go down that particular rabbit hole.

          • Avatar

            aThingOrTwo

            My opinion is Service Worker is too low level API for what most developers will want to achieve for offline. As such most developers use a higher level framework like workbox (realistically just workbox). Making developers manually write their own caching seems a curious choice to me given the two hard things in computer science.


            @hrlngrv

            > Would every PWA use a common service worker service, or would each PWA have its own full service worker foundation? I gotta wonder about the efficiency of PWAs.


            Service workers are sand-boxed by domain - so in practice each app will install its own service worker. They are terminated when not in use though.


            I cannot see PWAs being any more or any less efficient than the web in general. Likely there will be a wide spectrum of performance depending on implementation and design choices. If a development team is really sweating details and obsessing over their performance budgets, first meaningful paint (FMP), time to interactive (TTI) and push/render/precache/lazy-load (PRPL) strategies then things could theoretically be quite fast. They just better hope someone doesn't come along later and ruin everything by dumping and truckload of analytics on top.


            @skane2600

            > I also imagine that every service worker has to be platform-specific. If not, who is going to enforce a common interface across multiple platforms?


            It is a web standard - so these are defined by w3c working group like other standards:

            https://w3c.github.io/ServiceWorker/

            • Avatar

              hrlngrv

              In reply to aThingOrTwo:

              . . . [Service workers] are terminated when not in use . . .

              How would not in use be determined? No user interaction for a few minutes? Not the active window? Doing nothing other than waiting for user interaction?

              For example, when would a PWA stock price notification app be terminated if it was supposed to do nothing other than check particular stock prices maybe once a minute and only send a notification if the price moved outside of a given range?

              ADDED: I should be clear about my own biases: automatically terminating apps makes some sense on phones, maybe on consumption tablets, but not on PCs they way I use PCs.

              . . . I cannot see PWAs being any more or any less efficient than the web in general. . . .

              Aren't PWAs stored locally, one of the ways they can run offline? If so, they should be able to launch faster than web-based web apps.

            • Avatar

              skane2600

              In reply to aThingOrTwo:

              And every vendor follows w3c standard to the letter, right :)


              Remember also that efficiency of a particular application doesn't determine the overall consumption of CPU Bandwidth on the client. There will probably be other programs running on the client. Processing on the server from the client's point of view is free, but code running on the client isn't.

              • Avatar

                aThingOrTwo

                In reply to hrlngrv:


                How would not in use be determined? No user interaction for a few minutes? Not the active window? Doing nothing other than waiting for user interaction?


                Important point to understand is that Service Workers must run in a separate context to the main web page/application. As such they cannot access the window or handle user interaction (directly). They are event based, which means as soon as an "event" has been processed the Service Worker will be terminated. Examples of an "event" could be a request (from the application) or the arrival of a message (from a push subscription).


                For example, when would a PWA stock price notification app be terminated if it was supposed to do nothing other than check particular stock prices maybe once a minute and only send a notification if the price moved outside of a given range?


                That is a good example to pick. In this scenario the backend service which is providing the stock prices would need push out a message when the stock price has moved outside the range. This message would be handled by the browser (Edge/Chrome) which would delegate to appropriate Service Worker associated with the subscription. Only at this point the Service Worker code would be "woken up" to handle the message and as soon as it had finished processing it would be shut down again. Similar to push implementations on "native" mobile platforms, the client application itself does not handle the network access directly.


                Aren't PWAs stored locally, one of the ways they can run offline? If so, they should be able to launch faster than web-based web apps.


                They are not necessarily stored locally. They can choose to cache some resources locally, but which components and the extent of the offline functionality is the choice of the developer making the application. Moreover applications running in the browser can make use of the same APIs for caching and offline access. A PWA is a "web based-web app".


                In reply to skane2600:


                And every vendor follows w3c standard to the letter, right :)


                It is still not necessary to write a different service worker per vendor.


                Remember also that efficiency of a particular application doesn't determine the overall consumption of CPU Bandwidth on the client. There will probably be other programs running on the client. Processing on the server from the client's point of view is free, but code running on the client isn't.


                Apologies but I am struggling to understand this point. I was only referring to the client.

                • Avatar

                  skane2600

                  In reply to aThingOrTwo:

                  "I cannot see PWAs being any more or any less efficient than the web in general."


                  So, no, you were not only referring to the client. My point was that service workers use CPU bandwidth in a way that web apps don't even if the efficiency of a particular PWA running on it's own would be just as efficient as a web app.

      • Avatar

        cybersaurusrex

        In reply to Maelstrom:

        I think you're dreaming. That logic might work on a mobile OS like Android or iOS, but I just don't think it applies to Windows (a desktop OS). Most Windows users will shrug and think, "I wish that annoying pop-up would go away."

    • Avatar

      Tony Barrett

      In reply to cybersaurusrex:

      I agree. As the Windows app store has all but been abandoned, people are going to use Windows as they've always done - running browsers, writing letters, games and win32 apps. I just don't see this making much difference to Microsoft's ambitions, but at least they're doing something. I suspect they're 'all in' because of UWP's failure. If the proprietary UWP was a roaring success, MS probably wouldn't be interested in PWA.

      • Avatar

        cybersaurusrex

        In reply to ghostrider:

        Agree completely. Microsoft is desperate. Their next big idea is "Microsoft 365"... which is basically just Windows and Office "as a service"... which really means "our latest attempt to keep our customers locked in" even as we become increasingly irrelevant.

  18. Avatar

    Jules Wombat

    Developers won't be fooled by Microsoft old tricks, with suggestions of platform specific code in web apps. Been there before, got the T shirt. Dead Duck walking.

  19. Avatar

    hrlngrv

    I must be stupid, but I can't figure out how PWAs could perform faster than native apps, at least for well-written native apps for a local OS which doesn't undermine local app performance.

    • Avatar

      skane2600

      In reply to hrlngrv:

      Of course they can't and Service Workers consume CPU cycles just like anything else running locally. I suspect the "efficiencies" of PWA are really just moving the costs around.

      • Avatar

        Rob_Wade

        In reply to skane2600:


        Well, I think it will pretty much not matter by the time virtually all apps are PWA, so we won't have native app performance to compare against.


        • Avatar

          skane2600

          In reply to Rob_Wade:

          I think predicting that even 50% of apps will be PWAs in the next 5 years is very optimistic.

        • Avatar

          Stooks

          In reply to Rob_Wade:

          I think your wrong. Take iOS where there are millions upon million of native apps. If those native apps are replaced by PWA's that do not run as well there will be a huge back lash and people will not use the PWA apps.


          On Windows with the store it could work since a PWA app is better than no apps. I do not think it will take off for Microsoft. Google, sure since we are just getting better Google web apps with PWA's.


          Native > PWA > Web Apps > No apps.

          • Avatar

            skane2600

            In reply to Stooks:

            Keep in mind that on Windows it's millions of apps, They just don't happen to be UWP apps. Nobody cares but Microsoft.


            As far as PWA's being better than Web Apps is concerned, it's far to early to tell. The list of claimed attributes for PWA's remind me of the Agile Manifesto. Promised benefits that may or may not actually be achieved.

        • Avatar

          hrlngrv

          In reply to Rob_Wade:

          I'm not holding my breath waiting for the PWA version of Visual Studio or even the PWA version of Excel able to use VBA and add-ins.

          I'm actually a fan of some PWA-like software: Draw.io Desktop, StackEdit. I just don't believe it'd be practical for calculation-intensive or high data throughput software. IOW, forget stats, numerical (MatLab), and DBMS software as PWA candidates.

  20. Avatar

    obarthelemy

    It's hard to get real info about PWA.

    • how much code in PWAs is platform- and browser-specific
    • if I spent 60 days developping a Chrome+Android PWA for phones, how many more days to support tablets, desktops, Windows, Firefox, Edge...


    Most pro-PWA presentation don't touch those questions, or try to prented it's : "0% and 0 days". I don't buy it.

  21. Avatar

    roastedwookie

    "Microsoft wants Windows to provide the best PWA experience of any OS platform" :)))) yeah right, like that is ever gonna happen :))) MS is never gonna win over Google and Apple in this aspect. I always knew MS guys became freakin' delusional, but this statement of theirs, is laughable :)))

Leave a Reply