Coffeehouse Thread

20 posts

DISCUSSION: .NET vs. C++ vs. JS, who's in the best position for Metro ?

Back to Forum: Coffeehouse
  • User profile image
    felix9

    Lets say, here are 3 developers, each has been very familiar to one of the 3, now who is in the best position to write Metro-style apps/games for Win 8 ?

    C++ dev:

    1, need to learn a new 'language extension', and use a bunch of weird types in Platform:: namespace. not good.
    2, need to lean a new UI markup language and a whole stack of quite complex UI API. not good.
    3, can leverage DirectX and a lot of super powerful and performant libraries. good.
    4, need to compile for 3 architectures and upload them all to store (I guess). not so good.
    5, pure native performance. good.

    .NET dev:

    1, very natual language projection to WinRT, almost nothing to learn here. good.
    2, already familiar to XAML and the Avalon stack and used them for years. good.
    3, no XNA (yet). not so good.
    4, compile once and target all architectures. good.
    5, performance on ARM is unknown.

    JS dev:

    1, no new language or markup to learn, just a library. good.
    2, the idea of writing platform specific app may boggles mind. not so good.

    any more thoughts ?

    P.S. actually the one in the best position maybe the one with experiences in more than 1 world, right ?

  • User profile image
    Charles

    As Tony Goodhew says: Discard the tyranny of OR and embrace the happiness of AND.
    C

  • User profile image
    PerfectPhase

    Agreed, they all win in different areas. The developers in the best position will be the ones that know when to chose what, which may will be different for different teams.

  • User profile image
    contextfree`

    How about writing core logic in C# or C++ components and UI in HTML/JS?

  • User profile image
    Charles

    @contextfree`: That's the idea.

    C

  • User profile image
    DeathBy​VisualStudio

    @felix9:

    IMO, C++ is the winner because windiv is winning. It was quite clear from build that there is still a great division between windiv an devdiv. WinRT (COM with a little sugar) and Metro is what Microsoft is betting the farm on. They are both products of windiv and they seem to be running the show right now. C++ or Javascript...anything windiv controls is golden. Their architecture diagram says it all.

    Also IMO you will see more and more of .NET APIs being swallowed up by WinRT until .NET is relegated to apps akin to vb6 apps today.

     

     

     

     

     

     

  • User profile image
    evildictait​or

    ,DeathBy​VisualStudio wrote

    @felix9:

    IMO, C++ is the winner because windiv is winning. It was quite clear from build that there is still a great division between windiv an devdiv. WinRT (COM with a little sugar) and Metro is what Microsoft is betting the farm on. They are both products of windiv and they seem to be running the show right now. C++ or Javascript...anything windiv controls is golden. Their architecture diagram says it all.

    Also IMO you will see more and more of .NET APIs being swallowed up by WinRT until .NET is relegated to apps akin to vb6 apps today.

    Wow you have your angry hat on today. .NET apps won't be going in the bin anytime soon (there's code in ntdll.dll to specifically speed them up in Win8, and MS wouldn't have done that if they didn't like .NET), and you seem to have got confused about the distinction between the Windows team and the rest of Microsoft. The only thing that the Windows team have final say over is the kernel (and there's some pretty hefty restrictions on what they can do there too) - everything else is done collaboratively with the rest of Microsoft. Stuff like the Ribbon and WinRT and the rest of it came from outside of the Windows team, and the Windows team just gave it go-faster stripes.

  • User profile image
    felix9

    some more issues:

    What about the database accessing layer ?

    Local:

    C++: Jet
    .NET: ADO.NET is NOT there, so ???
    JS: IndexedDB

    Remote:

    C++: ???
    .NET & JS: WCF Data Services + OData, WCF Ria Services

    What about the web-services/Cloud accessing layer ?

  • User profile image
    TomboRombo

    @DeathByVisualStudio:Maybe you and I know C/C++ but there are new libraries and new syntax in what Microsoft is pushing.  COM died because a bunch of sloppy programmers made bad applications that were crashing,  leaking memory etc.   The problem is bad apps make Microsoft Windows look bad.   What is really needed is someone to come up with a better C that is like C# but compiles to native code.   I have done C/C++ for 20 years and I find C# alot cleaner, more powerful and easier to train junior programmers/engineers.   So why go backwards.   If someone at Microsoft had some guts,  maybe Anders,  we just need a brand new native language (not managed).   Basically I want C# that compiles like C++.     The VB6 guys are struggling with VB.net and will have their heads blow when they see the next version of C++.   So I agree with some comments above about using best tool for job.

  • User profile image
    fanbaby

    @TomboRombo: The answer to your prayers (please look at it more deeply then: oh, it's got declarations reversed, forget it)

    EDIT: That look might take a day or two.

  • User profile image
    Diestl

    @TomboRombo:

     

    The latest C++ standard  C++0x can look as good as C#.

  • User profile image
    KDawg

    ,DeathBy​VisualStudio wrote

    @felix9:

    IMO, C++ is the winner because windiv is winning. It was quite clear from build that there is still a great division between windiv an devdiv. WinRT (COM with a little sugar) and Metro is what Microsoft is betting the farm on. They are both products of windiv and they seem to be running the show right now. C++ or Javascript...anything windiv controls is golden. Their architecture diagram says it all.

    Also IMO you will see more and more of .NET APIs being swallowed up by WinRT until .NET is relegated to apps akin to vb6 apps today.

    Actually WinDiv and DevDiv split the pot.  Windows came in and basically won the battle that you can't use the CLR for doing systems development.  They effectively rewrote the BCL as native code.  But DevDiv won the API story.  All the APIs look like DevDiv APIs, not WinDiv APIs (including Xaml as the markup for C++ apps even).  In one of the sessions the WinRT guy even said that the Windows API design review process is modeled from the DevDiv one. 

    I personally like the split.  I want the improved perf from more native code in the stack, but I did hate the Windows APIs, while the .NET APIs have been great.  And we still keep C#.  With that said, I'm not a super fan of Xaml.  I mean I like it, but if I could somehow bind HTML/CSS to C#, I'd happily use that too.

  • User profile image
    androidi

    @DeathByVisualStudio:

    Maybe a sentimental winner but I need to look no further than Explorer search (since Vista) & libraries (7) performance to know that C++, Native and COM can be made untolerably slow. I think C++ is best left to experts*. I just found there's IL instruction that allows zero-overhead native calls. C# already has unsafe { } and such. I think this area of C# could use improvements to reduce need for C++/CLI wrappers.

    I really like that the language allows to clearly scope where the unsafe or non-verifiable stuff is and that safe is the default.

    * What this means is really splitting hairs. My thinking here is that unless you know to restrict yourself to subset of C++ and specific well designed libraries then the risks/difficulties are bigger than in C#, you can't exactly just do a search for say unsafe blocks of code and understanding code of others is much more challenging when other devs can be using wholly different approach as allowed by the language. Thus if you aren't already expert in C++ then writing C++ is just imho high risk vs reward proposition over writing C#. (and I hear rewards for experts are big so by all means. But should it be the "default/preferred" language? No. C# & interop should be made faster either all over, or atleast in the unsafe blocks.

  • User profile image
    DeathBy​VisualStudio

    ,evildictait​or wrote

    *snip*

    Wow you have your angry hat on today. .NET apps won't be going in the bin anytime soon (there's code in ntdll.dll to specifically speed them up in Win8, and MS wouldn't have done that if they didn't like .NET), and you seem to have got confused about the distinction between the Windows team and the rest of Microsoft. The only thing that the Windows team have final say over is the kernel (and there's some pretty hefty restrictions on what they can do there too) - everything else is done collaboratively with the rest of Microsoft. Stuff like the Ribbon and WinRT and the rest of it came from outside of the Windows team, and the Windows team just gave it go-faster stripes.

    It's not anger. It's disgust. This whole WinRT thing is politics. Windiv didn't have the time to move everything over to WinRT so they still depend on .NET. You have to ask yourself "why did the HTML5/JS story come out first?", "why is there so much talk about native?" IMO it's pretty simple; windiv is going for a power grab. They need to bring over the SL/WPF/.NET devs to WinRT so what do they do? They try and make it easy to port your XAML over by keeping the controls syntax as similar as possible. They've done the same with other WinRT APIs and made them easier to use over their .NET counterparts in some cases. Like as been inferred before windiv thinks the whole Silverlight thing was a mistake and they are trying to reign it back in. This is politics pure and simple. Just like the republicans use the economy as the smoke screen for their power grab, windiv uses the losses to Apple and Android as their justification for their power grab.

    I truly like where they are going with WinRT/Metro. By playing the bundling game (phone-like experience w/desktop) I beleive they have a shot. I also believe they could have performed the same re-inventing of Windows using Silverlight and .NET as the basis rather than putting a wrapper around COM, calling it WinRT, and porting XAML to it. The same eco-system of contracts and capabilities that are in the WinRT/Metro stack could have been added to SL/.NET (or at least a special runtime mode of SL) rather than re-inventing the wheel.

  • User profile image
    androidi

    WinRT/Metro edit:err... I mean some comments on the touch. I'm not sure what is the name for the touch feature.

    From the keynotes I observed that touch+drag operations did appear to have noticeable latency. If I ever get a touch device my criteria are quality of the panel, touch responsiveness and behaviour. Those are fundamentals of a touch interface. If those are right, I think the platform is on a good track. If those are bad, then we'll just see a bunch of marketing and apps which try to hide the issues. With sufficient momentum that can be enough to propel the platform into a success but I'm not going to be too excited about touch until I see things working better. And I suspect what I saw in the keynote didn't have to do with C++/JS/.NET  but some layer in the system that interprets the touch data.

  • User profile image
    AndyC

    ,androidi wrote

    WinRT/Metro:

    But from the keynotes I did observe that touch+drag operations did appear to have noticeable latency.

    Probably because the machines in use were either older machines or prototypes, it was mentioned repeatedly that they're working with device manufacturers to improve any latency issues because they are infintely more problematic when dealing with a touch device than they are with mouse/keyboard combos. I'm also pretty sure there will be lots more works done on this specifically before release.

  • User profile image
    DeathBy​VisualStudio

    ,AndyC wrote

    *snip*

    Probably because the machines in use were either older machines or prototypes, it was mentioned repeatedly that they're working with device manufacturers to improve any latency issues because they are infintely more problematic when dealing with a touch device than they are with mouse/keyboard combos. I'm also pretty sure there will be lots more works done on this specifically before release.

    But that was part of Sinofsky's point in the keynote: with 450 million Windows 8 capable machines out there we have a lot of customers for Metro apps. if it doesn't perform well on those older machines that notion of Sinofsy's is a falicy. They said the same thing about startup time and power management with Windows 7 and there weren't any huge strides forward there either. They boast of all of the power usage improvements they made in the Big Picture sessions but the tablet they handed out gets 3 to 4 hours battery life at best being miserly with turining off all radios and using power saver mode exclusively. You can say "well that's because you were doing x, y, or z" but in the end it's no match for the iPad nor Android tablets. You could also argue "that's not a fair comparison; wait until the ARM slates arrive and then compare." To which I counter with "and throw out your app capatibility with it; your options on ARM will be limited to media, social, internet, and fart apps for some time." Microsoft is creating a nice big ditch for themselves and us developers to try and crawl out of with Windows 8. Their only upside here is that PCs will continue to sell and have Windows installed on them. The WinRT/Metro side of Windows 8 is a long shot at best.

    If we all believed in unicorns and fairies the world would be a better place.
    Last modified
  • User profile image
    TomboRombo

    @DeathByVisualStudio:"To which I counter with "and throw out your app capatibility with it; your options on ARM will be limited to media, social, internet, and fart apps for some time."

    I agree with that statement completely.  Also, that power management killing my wireless connection is very annoying.  

    Also, they wasted so much on getting C++ to work with WINRT to make metro apps that they did not even implement the C++ new standard yet.   Who in the right mind would do a metro app in C++?   I use C++ in many places but I won't use it in that case. 

    I was somewhat disappointed at Build by their story with some of the Metro stuff.   I think this story will/should change but Microsoft is big and about alot of technologies which are very good.   I think Azure, Windows 7, boot time,  App Store, DirectX, C# /.NET is all good.

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.