Mike-EEE

My feedback

  1. 10,178 votes
    Vote
    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      You have left! (?) (thinking…)
      under review  ·  469 comments  ·  Visual Studio IDE » .NET  ·  Flag idea as inappropriate…  ·  Admin →
      Mike-EEE commented  · 

      Ah but it does @shimmy ... read #3 above, which is further explained here:
      http://blog.developers.win/2015/10/ubiquitous-qualities/#consistent-user-experience

      :)

      Mike-EEE commented  · 

      @birbilis I am not sure if you were asking me specifically, but in my world *any* non-.NET language is the threat here, not just JavaScript. That is the power and elegance of .NET, with its initial vision that of supporting numerous languages and (in theory) being able to add more in the future to continue staying relevant and competitive. In doing so, companies and individuals are able to leverage previous and existing investments and continue forward onto new projects with these same investments to reduce costs incurred otherwise by developing or incorporating in an all new, incompatible language altogether.

      That's how it is supposed to work, at least. And, actually, does work exactly as envisioned everywhere except for this little problem of the UI tier. :P

      Mike-EEE commented  · 

      Wow @Marc... that IS a good video. All until the end when it talks about async, though. What a stain on our language:
      https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/9126493-improve-asynchronous-programming-model

      Adding a System.IAsyncDisposable -- not to be confused with IDisposableAsync ;) -- is a perfect example. It is basically creating two different sets of APIs throughout our entire framework. The async zombie virus spreads! DON'T FORGET TO DOUBLE TAP!!!

      Mike-EEE commented  · 

      Hehe... @Marc thanks Brogrammer... I appreciate that! You got me as I was fixing a major edit/flaw in the previous post, DOH. Do know that I have been pawing at this problem for many years now, and I have not been able to articulate it as well until very recently, I would say in the past year or so. IMO the Silverlight 6 vote didn't survive because it wasn't a very business-oriented case, IMO:
      https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3556619-silverlight-6

      This vote is that EXACT same vote but with a more business-oriented objective and angle. In the end, MSFT is a business (I always use its stock ticker in place of its name for this very reason), and so it is most effective to frame complaints and issues is as a BUSINESS problem and highlight where VALUE is taken and where it can be restored.

      Mike-EEE commented  · 

      +1 to Marc's sentiment, but do I have to actually state that at this point? LOL... @Marc I think it's better to state that this as a business problem rather than comparing technologies. When you introduce JavaScript (or ANY language that isn't .NET/IL-compatible), then you have simply doubled the amount of code required to build your solution. Smart businesses will realize (and already have) that they can dump .NET altogether and simply use JavaScript as it can be used everywhere while also enjoying the ability to share code between all known boundaries (as you suggest with .NET). This is an INCREDIBLE amount of cost savings as not only you can easily leverage existing development but bugs fixed in one area are automatically fixed in another and vice versa. With JavaScript paired with .NET you are constantly chasing bugs in both frameworks -- not to mention constantly learning quirks in both frameworks -- leading to a lot of time and money lost due to such endeavors.

      Mike-EEE commented  · 

      @Collin, what do you base the statement that Xamarin has this covered and works quite well? It is the second most dreaded framework in stackoverflow's most recent poll:
      https://insights.stackoverflow.com/survey/2018/#technology-most-loved-dreaded-and-wanted-frameworks-libraries-and-tools

      I also pair this with the comments of this thread, over 450 of them to date, LOL. Xamarin.Forms is not very praised that I have seen.

      Additionally you seem to be missing the point about JavaScript, as Blazor is meant to replace all the expensive, friction-prone script that you use in a typical web-hosted application and use .NET instead, thereby reducing the total cost of development for a .NET solution.

      Also, in regards to desktop/mobile designs. The vision/ask/idea here is to provide a more WPF-esque model where you can easily apply a theme and it would match up with the platform that is serving as the host. Given such a paradigm, you could imagine using it to apply a theme to run on an iOS host that provides the Droid UX and vice versa. The point being that great UX is great UX and is not meant to be bound by, well, boundaries. :) Also consider that what you consider as an "iOS" experience and a "Droid" experience is approaching a decade in age and could use a refresh. Also ALSO consider that no one really complains about how web UX operates and it is growing more sophisticated (native-like) by the year.

      Mike-EEE commented  · 

      @Oliver I am OK with Blazor. In fact it's really awesome that MSFT is stepping out and trying new things here. At the end of the day however they are WASM-centric and are not really designed for iOS/Droid/Windows. Additionally Razor has its own parser/engine and is not very Xaml-ish as you know.

      My beef with WASM is that there is a huge download associated with it. If there is a way to streamline this there won't be much of a problem but I am pretty sure it's going to be a struggle for the first couple years for sure.

      As such, I am still very much in favor of Ooui's approach and using a simple, lightweight HTML+CSS presentation tier. The trick here, however, is to adapt it so that you can easily Xamlfy it and make it more .NET-ish.

      Mike-EEE commented  · 

      HEY EVERYBODY... GUESS WHAT NOW HAS TWO+ YEARS IN SERVICE AND OVER TEN THOUSAND VOTES TO ITS NAME???

      Mike-EEE commented  · 

      > I guess we do care about Microsoft.

      LOL... yeah, I agree. More like I care about my soon-to-be-approaching 20-year investment into their technology. ;)

      I can't find much fault in what you have to say. WebAssembly is certainly a viable route any tech can take so I see what you say there. I am just not impressed with what I have seen out of XF to really jump in. In addition to their bigger fundamental problems, the way they approach problems and write APIs (e.g. ALL THE STATIC METHODS) leaves much to be desired.

      As such, I think the primary concern in XF and UWP is that neither of these technologies *inspire* developers. WPF and especially Silverlight were LOADED with really great, creative approaches that made developers think differently in how they created their solutions. What's more about Silverlight, is that it was 100% fully comprehensive. It wasn't "just" at the UI tier... it had RIA Services and a ton of supporting cast around the entire vision. In addition to vision, it had purpose, and this fed into developers' minds as they were not only implementing core solutions, but extending and making their own.

      None of that exists in UWP or XF IMO. Now, I will say that I am getting that same creative energy from .NET Core's camp. To me, that is where the talent is at these days but NO UI... this is why I say dump UWP and have .NET Core absorb its mission.

      THEN we can have another HOLISTIC shot at creating a UI-oriented solution. Right now, the UI space is so rickety and pieced together. Hodge podge. There simply is no inspiration in that, and the poor adoption reflects this.

      Mike-EEE commented  · 

      BTW @Olumide I super appreciate your line of thinking in providing potential solutions. Please do not think that I do not find them valuable with my line of questioning. If you want to join the discussion there on that Disqus thread it is a better way of posting comments and I can upvote them, too. :)

      Mike-EEE commented  · 

      @Olumide. Have you tried Xamarin.Forms? It's not very well liked or broadly used, mostly because it's very difficult to use and has fundamental architectural/design issues (not to mention INCREDIBLY buggy -- but this is getting better). For one, if you have a custom renderer for a control, you must make that renderer for each platform you wish to support. So if you also include web as you are suggesting, you could end up creating four custom renderers for each control. Hardly viable.

      When you say XF is closer to the web, we should ensure that you mean that it LOOKS closer to the web. XF has NO plans to become web-based technology, save for WebAssembly when it reaches RTM (but when? this is still a risk).

      Also, have you actually tried to make a UWP application vs. a WPF application? Have you encountered an error in UWP? And then tried to find out more context around that exception on StackOverflow? If you haven't, give that a whirl before suggesting that UWP should be promoted in any capacity. There is also the HUGE issue with the Xaml model which I can't even begin to get into it here.

      At the end of the day, the best thing that could possibly happen is the .NET/Core group to assimilate the UWP group, hopefully gutting all its management in the course of doing so.

      BTW I am wrecking shop on this very topic here, if you are up for some good reading/discussion:
      https://mspoweruser.com/microsoft-fixed-fluent-designs-most-stifling-limitation-at-build/#comment-3897863413

      Mike-EEE commented  · 

      I appreciate that you appreciate, @Olumide. :D Thank you for that.

      Unfortunately, if you are not aware, the Xaml Standard is dead. UWP group simply does not play well with others, or at all for that matter. UWP has hijacked Xaml and for whatever reason someone continues to allow their questionable management maintain power despite the fact that they are the primary reason Windows has lost its relevance during the past 5 years. More "discussion" here: https://github.com/Microsoft/xaml-standard/issues/230

      (I denote "discussion" because all of "management" has abstained from any communication with the members they have been delegated to serve. Perfect example of UWP at "work.")

      I especially like the "new" XamlDirect "feature", which is basically a wrapper around System.Activator... a nifty class that has been around since v1.0.

      Also, I respect and understand what you have to say about the web. It *IS* the common denominator. Taken in the context of a few more years, however, it will be even closer to native technologies than what it is today.

      ALSO consider (in my opinion) that "amazing" applications really do not need that much technology to be amazing. I am more of a minimalist in my style, however. I think less is more. If you are looking for super graphics intensive power and/or a game, you are 100% correct. However, for about 95% of LOB's out there (Windows Forms, even), the web currently has you covered.

      The issue of course is that it is a total pain to work with, especially when .NET is involved, and that is what we are aiming to fix here.

      Mike-EEE commented  · 

      Olumide: Xamarin does not run on the web, nor do they have plans to. The result of which is that you end up having to create TWO application codebases whereas with a JavaScript-based solution you only need one. This means twice the development, maintenance, and cost. More here:
      http://blog.developers.win/2016/11/why-an-html5-compliant-net-is-important/

      Mike-EEE commented  · 

      Suddenly we're only 300 votes away from 10,000... did something happen or something? An event or something? ;)

      Mike-EEE commented  · 

      FWIW we're discussing the dumpster fire of Xaml Standard and //build 2018 here (skipping to an interesting post, if I do say so myself):
      https://github.com/Microsoft/xaml-standard/issues/230#issuecomment-387292869

      Mike-EEE commented  · 

      Worth an investigation: http://platform.uno/

      Mike-EEE commented  · 

      Lots of mention of "ubiquitous" in //build currently, but meaning all the wrong things. ;)

      https://developer.microsoft.com/en-us/events/build

      Mike-EEE commented  · 
      Mike-EEE commented  · 

      @Marc 100% agree... there was actually a discussion around this lately on Xamarin's forums. Well it actually started on Twitter and had to do with Xaml Standard, but was never on Xaml Standard's repo... GO FIGURE. Anyways, there is actually a movement to make code more UI-ish, and I'll just skip to the good part where I put in my $.02. ;)
      https://forums.xamarin.com/discussion/comment/328392/#Comment_328392

      People seem to forget that while it's cool to build neat tech (and that certainly is part of it), the core/root/fundamental challenge is the business driver. You can build the most amazing tech in the world, but if it costs 3-5x as much to use it as something less fancy with less talented resources, that's where the business goes. Just ask JavaScript.

      Mike-EEE commented  · 

      LOL @Marc ... negative but funny AF. ;)

      Also, @Anonymous 100% agree. Don't forget this issue has been "under review" for over 2 full years now. Without any remark whatsoever from admins. Pretty impressive. I still think someone got drunk one day and accidentally hit the wrong button. Either that or they are no longer working for MSFT. Maybe both. :P

      Mike-EEE commented  · 

      FWIW, this idea has now surpassed 9,000 votes, and is by far the most popular idea here on Visual Studio's feedback forum. FWIWx2: There's a survey going on with the .NET group on what they should do next. Feel free to chime in and give them a pointer back here. ;)

      https://blogs.msdn.microsoft.com/dotnet/2018/04/20/help-us-plan-the-future-of-net/

      Mike-EEE commented  · 

      @Антон, the problem with Bridge.net is that it does not support .NET Standard 2.0 or PCLs, so you ultimately end up with 2 separate codebases that results in twice the total cost of ownership to develop and maintain. Right now the only viable choices or approaches for a ubiquitous .NET are Blazor (as you mentioned) and Ooui:
      https://github.com/praeclarum/Ooui

      Mike-EEE commented  · 

      For those who have voiced their displeasure with Xamarin Forms, there's a nice thread on their very own repo with developers talking about its shortsighted issues and other well-deserved criticisms. It is also talking about ubiquitous technology in general. Nice read, IMO... that's why I am sharing it! ;)
      https://github.com/xamarin/Xamarin.Forms/issues/1789

      Mike-EEE commented  · 

      @Oliver ... i have had problems before with certain words triggering a block. No warning/indication/nothing. This was on Visual Studio's blog and not .NET's, however. Try doing a simple post and seeing if it works, with a message saying that you are having trouble as described.

      Mike-EEE commented  · 

      FWIW/FYI nice conversation going on in the comments of this post if you want to contribute/complain somehow. ;)

      https://blogs.msdn.microsoft.com/dotnet/2018/03/23/calling-all-desktop-developers-how-should-ui-development-be-improved

      Mike-EEE commented  · 

      Hah, well "better" is relative, and of course every application is different and tailored towards its intended market. Certainly native hosting environments offer "better" :) integration with device components and hardware accessibility. But also consider that HTML5 is slowly gaining more and more access to these features as well.

      > Webapps are a cross-platform technology, that make it easy to reach many platforms, albeit with a low-quality solution.

      Consider that the only difference between a "webapp" and a "nativeapp" is the hosting environment. That's it. You can technically run an HTML5 "webapp" in a nativeapp via Cordova and a suite of other technologies. A "webapp" is simply an application that is hosted in a web browser host process. It is not a website, although those have historically existed, and are probably contributing to your conflation with the two notions (and that of "low-quality"). If you have not taken a look at WordPress's editor lately, try checking it out and see if you continue to have the same notion of a "webapp" being of low-quality. From what I have seen, it is just about as good as any WPF application I have seen, and then some, especially when you consider it can be rendered on any modern browser (and therefore device).

      > But if we can reach those platforms natively, why would we want a webapp?

      Or conversely, if you have one application that runs within a hosted web browser context (i.e. everywhere), why would you want nativeapps? :)

      Along such lines, consider the sheer amount of resources required to get .NET to run and emulate a Droid/iOS environment. Or even UWP. You will spend a day in Visual Studio installing all the required (100s of GBs!) software to simply launch an emulator (or UWP scene) from your installation, assuming you do not run into obscure platform-based hiccups. Whereas with web, a simple visit to a URL is all it takes, no special installs required, outside of the web browser you run it on (preinstalled on all devices these days) and the web server that serves the content, of course.

      And, of course, this runs through the whole "web" experience. Users don't need to go to a store or perform any installation or permissions checks to run a web application. They simply visit a url/location and it "just works" without having any proprietary magic or store voodoo. In fact, if you have a web application and force the user to further install a "native" app, you risk losing that user altogether as you already have them right there. In your web application. :)

      The web is simply much more lightweight and as it incorporates more and more native-esque features and functionality, it will become the defacto platform to develop and deliver upon as such. That's not to say that it will replace native applications (although it might), but it should certainly be considered as a peer platform to the current 3 platforms that we find ourselves with in the current landscape.

      Mike-EEE commented  · 

      Hehe nice try @cs mr, but a web solution is still required to stay competitive to JavaScript, which can access both web and native scenarios effortlessly, making it a more attractive and cheaper solution stack:
      http://blog.developers.win/2016/11/why-an-html5-compliant-net-is-important/

      Mike-EEE commented  · 

      Sorry brogrammer... if there is one thing in all of MSFT that is worse than UWP it is IE. You're on your own there, I'm afraid. ;)

      Mike-EEE commented  · 

      Heh heh Aaron, yeah ... about that UWP. Installing that bloated SDK on your machine via Visual Studio takes about a day. Same for Xamarin's Droid experience. I got mass respect for Xamarin for the magic they have pulled off to get .NET working on Droid, but there's a LOT involved in getting it to work on a developer machine. UWP, OTOH, seems like they have put every second of every "employee" in their organization to destroy the MSFT brand. When they actually get around to doing any work, that is. ;)

      Now, compare this with working in a web page. You don't have to install any grueling SDK packs or muck with any emulators. It "just works" and is incredibly lightweight. This is why I am so sprung around the WebSocket Bridge approach as demonstrated by Ooui that I mentioned earlier. The same lightweight code that is used to work in a webpage can also be used in a native environment. You could do 99% of your development by viewing it in a webpage (no WebAssembly required!) and spend the remaining 1% deploying it to native hosts to make sure it works there. In theory. ;) Very promising stuff.

      Mike-EEE commented  · 

      Yeah, I gotta say I am very drawn to Ooui's approach over Blazor's ATM:
      https://github.com/praeclarum/Ooui/issues/74#issuecomment-362813308

      As I mention there, it doesn't support data-binding (yet ;)), and other issues, but consider that this works in all four platforms: iOS, Droid, Windows, *and* web. Additionally, with the web scenario, you aren't faced with the prospect of massive downloads (or a proprietary technology that requires codified agreement between Google, MSFT, and Apple, blahhh). The websocket magic sends all the information back and forth between client and server.

      Even better, this allows us to sidestep Xamarin.Forms and UWP altogether. ;) ;) ;)

      Mike-EEE commented  · 
      Mike-EEE commented  · 

      For those of you all into Telerik: https://www.telerik.com/platform-next-level

      Boh.

      Mike-EEE commented  · 

      Hey good to hear @Oliver. Many others have said the same. We should start pestering Telerik at some point. :)

      @Anonymous, I am sure we are going to see more projects like that. However the problem remains that you now have at least 2 different code bases (or view bases) that you have to develop and maintain. The goal here is to have ONE code (or view) base that used and from there (via theming, etc) have it adapt to the hosting environment/platform.

      Mike-EEE commented  · 

      Well you say no problem, but how many concurrent users have you actually had to prove this? Several hundred might work, but thousands? Hundreds of thousands? Millions? Also, when you reference ASP.NET are you talking the old or the new re-written ASP.NET Core? The performance comparison between the two are staggering.

      If you have found some way to legitimately cater the server load/scale problem then more power to you, otherwise, I reserve judgement until I see this ****** in the wild working as described under cloud scale/load. :)

      Mike-EEE commented  · 

      Ah yes, there have been some attempts at what you are describing. There are two problems with this, however:
      1) Scale. Since you are placing the work in the server, this places the processing within the server and struggles with scaling out the solution.
      2) Sharing code. Are you able to say that the same code that works in your scenario is the exact same code that works on iOS, Droid, and Windows platforms? This is what Avalonia and Noesis offer, as they allow you to use the same code and each of the platforms are merely relegated as rendering hosts.

      If you are able to address these two aspects, then I wish you the best of luck!

      BTW, for those watching at home, this issue has now reached 8,000 votes.

      Mike-EEE commented  · 

      @Yoram what we're looking for at this point is a .NET runtime/environment that will execute within a browser-hosted context, either via JS or WebAssembly. At this point, it should be .NET Standard 2.0 compatible, wherein you are able to share code cleanly and effortlessly between server and client (whether it be iOS, Droid, Windows, and/or web page).

      FWIW, the closest solutions to this idea are Noesis and Avalonia:
      https://www.noesisengine.com/
      https://github.com/AvaloniaUI/Avalonia

      They do not work in a webpage yet however, so if you got something that is better than that, and works within a web context (in addition to iOS, Droid, and of course Windows) and is .NET Standard 2.0 compatible, then I will be the first to see your demo which is no doubt hosted on a webpage somewhere, right??? :) :) :) :)

      Mike-EEE commented  · 

      Indeed, Tom_W, anything out of the UWP group (currently) does not work within the context of a web browser host.

      Mike-EEE commented  · 

      LOL 1998 called and wants its code back, Yoram. ;) It's 2017 and open source is where it's at. MSFT isn't going to adopt anything that doesn't have mass following/branding/awareness. Put it on GitHub, buddy!

      Mike-EEE commented  · 

      You're not alone in your disdain for Xamarin, Oliver. Well, Xamarin.Forms, that is. You can read the storied history of this issue to see that XF is very much disliked, whereas -- in alignment with your input -- Avalonia and Noesis is prized.

      As for WebAssembly, the pendulum swings back to the web these days. That is probably why all 3 big shots in MSFT, GOOG, and AAPL support the WebAssembly initiative in their respective browsers. I know, hard to believe, but it's there, available, and the specification is moving forward. Even FireFox is in on the gig!

      Mike-EEE commented  · 

      Wow, some nice WebAssembly demos coming out already: https://www.funkykarts.rocks/demo.html

      Mike-EEE commented  · 

      Interesting little project here:

      https://github.com/lrz/mono-wasm

      Get a few more dozen of these out there and we'll no doubt land on what we're looking for here.

      Mike-EEE commented  · 

      Wow... thanks for the suggestion and consideration, Jay. Although, I am not sure how effective that will be, or if they will even let me in, even with the KickStarter. :)

      For the most part, this idea is on its way to fruition. If WebAssembly takes off and becomes "official" then we have a good chance of having what we're looking to accomplish here. You can see from the Blazer demo below that it is already starting to take root and inspire. So, let's hope (and pray lol) that this continues. Once that is complete, then it just a matter of a team like Avalonia and/or Noesis (the real UWP) to build a great conceptual model on top of this and we're back in business. :)

      Mike-EEE commented  · 

      @Charles, thanks for sharing. Literally worth noting that this "huge challenge" is met by NodeJS/JavaScript just fine, along with being able to reach all the other listed platforms (and more).

      The literal worth is in reference to the cost involved with developing and maintaining two incompatible codebases (JS/.NET) with a .NET solution, vs. only one with JS.

      Mike-EEE commented  · 

      https://github.com/SteveSanderson/Blazor

      HTML5-based, but encouraging to see the adoption/embracing of WebAssembly.

      Mike-EEE commented  · 
      Mike-EEE commented  · 

      Nice little add here:
      http://jasonette.com/

      Gotta say, that jump to TypeScript/JS is looking more tempting day by day, especially when we will have to start over with .NET Core, in any case.

      Oh, and no petitions/explaining required. ;) ;) ;)
      Nice to see when others "just get it." ;) ;) ;)

      Mike-EEE commented  · 

      WOOOOOOOOOOW... NativeScript already looking a little like Xaml already. It uses the ~ for image paths and everything:

      Example:
      https://docs.nativescript.org/ui/action-bar

      Mike-EEE commented  · 

      Machine learning to generate code from UI:
      https://github.com/tonybeltramelli/pix2code

      It will be really funny once we use the robots to resurrect Silverlight 6. ;)

      Mike-EEE commented  · 

      I am not sure what is more impressive @birbilis: the fact that someone uses this thread for an unrelated technical support issue, or the fact that you actually entertain it, LOL!

      But I guess it's good to see *someone* get *some* value out of this thing... for once. ;)

      Mike-EEE commented  · 

      Thanks David... upvoted.

      Mike-EEE commented  · 

      Why look at that... 7,000 votes and going strong. This is actually the #2 top open issue here in Visual Studio's UserVoice.

      Still remarkable that this was put "Under Review" without a single word mentioned by the administrators here for over 15 months now.

      Mike-EEE commented  · 

      @Anonymous: indeed, sharing local project code via the use of File Links is one way of sharing code. However, what happens when that file references an assembly that only exists in the server tier/runtime or the client tier/runtime? You will get compile errors when one of those projects compile.

      To be more precise, CSHTML5/JSIL does not support Portable Class Libraries (PCLs) or their equivalent in .NET Standard 2.0 (have not researched this enough to speak intelligently on this yet!).

      Mike-EEE commented  · 

      > Marc - why not wait for these guys to complete their work. http://www.cshtml5.com/links/roadmap.aspx

      @Anonymous, the pain point with CSHTML5 and JSIL on which it is based is that you cannot share code between server and client tiers (thereby saving development time and cost). You could do this with Silverlight and you can do this now with a JS-based solution.

      Mike-EEE commented  · 

      So I completely refreshed my local and development environment last week, completely reinstalling any and everything I owned and upgrading it to the latest and greatest, including Windows Creator Update and VS2017. This also means that I haven't gotten around to wiring up the vote counter, but I am not exactly rushing to do it. I think everyone here gets the idea. ;)

      In any case, I am checking out an ambitious Plan B in case WebAssembly doesn't pan out: client-side virtualization. It is only valid for always-on/connected scenarios, but you essentially pipe your application through a remote desktop. So you could develop in it anything if you wanted, even WPF.

      Azure actually had something like this called RemoteApp, but it was domain-joined only. They they pawned it off to Citrix. I have an open question in their forum which you can follow (or chime in with interest) here:

      https://discussions.citrix.com/topic/386823-feature-request-xenapp-powered-public-websites/

      Mike-EEE commented  · 

      Truly is frightening how pervasive and common the thinking is to "just use JS." It has infected the typical developer as much as it has MSFT, the source of such inflicted thinking. Look no further than the scourge of TypeScript, which not only reinforces this cost-intensive thinking, but confuses market space that we are fighting so hard to save.

      At some point, everyone will understand: two codebases are more expensive than one.

      Mike-EEE commented  · 

      Yeah, not too surprising. "Xamarin" is pretty broad though... is it "Xamarin" or "Xamarin.Forms"? Interesting that it is also 48.7% "Loved" vs. its 51.3% "Dreaded."

      Mike-EEE commented  · 

      Coooool... thanks for the info, George!

      I just upgraded to the Creator Update, which has a new Paint (Paint3D), which is tied to this:
      https://www.remix3d.com

      Bonus points/kudos to anyone who can id the tech involved to make that happen. My guess is WebGL.

      Kind of cool. 3D in a web page... once again. Like Silverlight. Seven years ago. ;)

      Mike-EEE commented  · 

      FWIW, looks like there are bindings for Qt here: https://github.com/ddobrev/QtSharp

      My money is still on Noesis at this point, however. It is based on Xaml and better Xaml than UWP "Xaml." :P

      ---

      Weekly Friday morning check-in: 31 votes were cast for this idea last week, bringing the total to 45,940 combined votes across 10 similar ideas asking for a ubiquitous .NET. Please feel free to like and/or retweet to show your support to the "Big Three" here:
      https://twitter.com/DevelopersWin/status/855414653526167552

      Thank you all who have shown and continue to show your support!

      Mike-EEE commented  · 

      Anyone have any experience/knowledge about Qt? I just found out about it:
      http://qt.io

      I've got an open thread with questions if you want to join along/participate:
      https://forum.qt.io/topic/78274/net-support

      Mike-EEE commented  · 

      @Anonymous, correct the best solution in that regard is http://www.noesisengine.com/

      I've heard Mono/WebAssembly could be as soon as a few months, but I am skeptical. I was also told that this is more for games than for "applications" which is a good starting point (see: Noesis) for my purposes. The concern is that the Mono framework will be a 3-4MB download.

      Which is not as bad as it would have been 5-6 years ago. Doing a quick check, the CSHTML5 control demo is already 2.3MB.

      In any case, if anyone wants more information and wants to further elevate awareness to this, please send a mail to dotnet@microsoft.com and reference this issue. Really from .NET's perspective "no one is talking about WebAssembly" because no one from .NET is reading Visual Studio's UserVoice.

      Not even anyone from Visual Studio is reading Visual Studio's UserVoice. ;)

      Mike-EEE commented  · 

      Weekly Friday morning check-in: 39 votes were cast for this idea last week, bringing the total to 45,897 combined votes across 10 similar ideas asking for a ubiquitous .NET. Please feel free to like and/or retweet to show your support to the "Big Three" here:
      https://twitter.com/DevelopersWin/status/852854044855066624

      Thank you all who have shown and continue to show your support!

      Mike-EEE commented  · 

      @Anonee.... In other words: "Rather than spend time innovating and getting Xamarin to work on the web, we decided to take the easy shortcut and saddle .NET developers with another incompatible codebase for their solutions."

      Truly infuriating. ;)

      Feel free to upvote/add your voice here:
      https://github.com/Microsoft/reactxp/issues/28

      Mike-EEE commented  · 

      MSFT builds a React framework, known as ReactXP. I do not see any .NET integration points, however. Perhaps that is the goal of WebSharp?

      This still does not solve the "web page" problem of being able to build an app in this technology and push it out as a web page that is accessible by URL (that I can see):

      https://microsoft.github.io/reactxp/

      Mike-EEE commented  · 

      @birbilis, Sounds like I should take a look at what Electron is, first. ;) And yeah, the whole DOM/W3C makes me weary. I guess if they are exposing the host like they do with iOS and Droid, then that makes sense. I just don't want to be building an app where it renders a certain way for iOS/Droid/Windows and then for the "web" it has to be in an HTML5 page, because, well it's the web, duh. ;)

      That sounds pretty ridiculous until you consider that is exactly the quagmire we find ourselves in now as .NET developers.

      --

      Weekly Friday morning check-in: 40 votes were cast for this idea last week, bringing the total to 45,832 combined votes across 10 similar ideas asking for a ubiquitous .NET. Please feel free to like and/or retweet to show your support to the "Big Three" here:
      https://twitter.com/DevelopersWin/status/850309304406167552

      Thank you all who have shown and continue to show your support!

      Mike-EEE commented  · 

      Indeed, @birbilis, there is a lot to process. It still looks as if it can host in a web page? It does look more geared towards desktop development, which doesn't make sense as it is hosted in a browser? In any case, I plan on checking it out when I get the chance. I have been in contact with Mr. Pouncey there and he says that this should compile PCLs. If that is the case, and it can be hosted in the browser process, that would essentially check off all the necessary boxes to take this to the next step.

      ---

      Weekly Friday morning check-in: 50 votes were cast for this idea last week, bringing the total to 45,777 combined votes across 10 similar ideas asking for a ubiquitous .NET. Please feel free to like and/or retweet to show your support to the "Big Three" here:
      https://twitter.com/DevelopersWin/status/847776712226197504

      Thank you all who have shown and continue to show your support!

      Mike-EEE commented  · 

      Something to be aware of, not sure what it means just yet. Looks like a Mono runtime in a webpage via JS? Someone pointed it out to me and thought I would share.

      https://github.com/xamarin/WebSharp

      Mike-EEE commented  · 

      Weekly Friday morning check-in: 40 votes were cast for this idea last week, bringing the total to 45,718 combined votes across 10 similar ideas asking for a ubiquitous .NET. Please feel free to like and/or retweet to show your support to the "Big Three" here:
      https://twitter.com/DevelopersWin/status/845239306671308800

      Thank you all who have shown and continue to show your support!

      Mike-EEE commented  · 

      Boy it got quiet in here all of the sudden. ;)

      ---

      Weekly Friday morning check-in: 54 votes were cast for this idea last week, bringing the total to 45,654 combined votes across 10 similar ideas asking for a ubiquitous .NET. Please feel free to like and/or retweet to show your support to the "Big Three" here:
      https://twitter.com/DevelopersWin/status/842717393357099009

      Thank you all who have shown and continue to show your support!

      Mike-EEE commented  · 

      Just saw this blog article. Looks like JetBrains developed a ubiquitous application development language for Java/JavaScript. They are looking to compile to iOS as well:
      https://blog.jetbrains.com/kotlin/2017/03/kotlin-1-1

      So, pretty much everything out there is ubiquitous these days with the exception of .NET.

      Probably should have posted this idea on JetBrains forum instead. ;)

      Mike-EEE commented  · 

      > we will see if the idea of having (the very good IMHO) .Net core for the server backend and having nothing at all for the client side (except creating and maintaining a complete separate JS tree for the clients) will work out. I personally doubt it.

      Indeed, if it ends in this scenario, we will see developers and organizations managing and maintaining two incompatible code bases in two incompatible languages, thereby doubling the effort and money required to do so vs. a JavaScript-only solution:
      http://blog.developers.win/2016/11/why-an-html5-compliant-net-is-important/

      Therefore they (or at least the fiscally intelligent ones) will end up switching to Node/JS-based solutions as it will be a cheaper development path:
      https://blogs.msdn.microsoft.com/azuredev/2016/03/02/azure-xamarin-and-a-ubiquitous-net/

      Fortunately, Mono (a flavor of .NET) has been verified as being ported over to WebAssembly, which would make .NET available in the browser. I also have heard an unverified report that it something will be available for developers to use within 2-3 months, which would be excellent and much sooner than anything that I have anticipated. So, there's hope. :)

      Mike-EEE commented  · 

      Good question, Anonee! I've learned to take a "I'll believe when I see it" approach to MSFT mobile. ;) I saw a report somewhere that they are expecting 0% market share (!) by 2021 I believe. I would say that Surface Phone is their only chance! FWIW, I still own an HTC M8 Windows Phone 8.1 heh heh.

      Now on with our Friday morning show...

      ---

      Weekly Friday morning check-in: 169 votes were cast for this idea last week, bringing the total to 45,567 combined votes across 10 similar ideas asking for a ubiquitous .NET. Please feel free to like and/or retweet to show your support to the "Big Three" here:
      https://twitter.com/DevelopersWin/status/840175220493291525

      Thank you all who have shown and continue to show your support!

      Mike-EEE commented  · 

      @Anonee, patience. :)

      I share your angst about the amount of time that this idea has been Under Review. In fact there is part of me that still says it was done by mistake. But make no mistake MSFT is investing into .NET. They wouldn't have acquired Xamarin otherwise. And it is that same Xamarin team that is porting .NET (Mono) to WebAssembly that would essentially actualize and complete this idea, so do not go rushing over to JavaScript unless you truly find it a better paradigm.

      FWIW, some kid genius back in 2011 made a transpiled .NET JS framework that already renders .NET in WebGL: http://jsil.org Now, how awesome would it have been to hear Steven Sinofsky jump up and down on stage at Mix'11 about THAT rather than trying to impress SL developers with blinking sprites in an HTML5 page?

      (Also FWIW, the reason why this isn't a viable option at present is that it doesn't support PCLs, so you still end up with multiple codebases)

      In any case, MSFT is running a business, and JS has indeed become ubiquitous alongside .NET. You can run JS everywhere, and it would not be very pragmatic for MSFT to ignore the market that has been created around this.

      Fortunately, with the advent of WASM and its Mono port, .NET will attain market reach parity with JS. And even technically speaking, other technology stacks such as Java should be along for the ride, too. As a result, we *should* (as this is all conjecture and based on my limited understanding) and will be able to select the technology stack that makes the most sense (and cents) to us, rather than the one (or ones) that can reach the greatest market. It's going to be a little longer yet, but it appears to be on its way. Stay tuned.

      Mike-EEE commented  · 

      @Anonymous, technically once .NET Standard is available, both Noesis and Avalonia will be able to utilize .NET (and EF) Core and deploy to supported platforms via Mono. As for vendor controls, I am actually discussing this with the Noesis team if you would like to follow along here:
      http://www.noesisengine.com/forums/viewtopic.php?f=3&t=1011&p=5803#p5803

      Now onto our regular Friday morning scheduling:

      Weekly Friday morning check-in: 59 votes were cast for this idea last week, bringing the total to 45,364 combined votes across 10 similar ideas asking for a ubiquitous .NET. Please feel free to like and/or retweet to show your support to the "Big Three" here:
      https://twitter.com/DevelopersWin/status/837636698376929280

      Thank you all who have shown and continue to show your support!

      Mike-EEE commented  · 

      @Anonymous (and really, open an account here, LOL), I would say that both Avalonia and Noesis is greater than SL3.0. Avalonia has a lot of heart but it hasn't reached critical mass yet. It is still in alpha. TBH it is an extreme challenge to pull off a feat such as this in a closed-source capacity.

      I would say that Noesis is more like what UWP *should* be. It does lack markup extensions, but they just verified that they are on the way: https://twitter.com/noesisengine/status/837226399727378432

      If I were to start a project today I would definitely go with Noesis above any other option since it is now free for indie developers, has a team that cares about Xaml, listens to its customers, and doesn't take five years to implement features *ahem*UWP*ahem*.

      That is not to discredit Avalonia, but like I said they are in alpha currently vs. a 2.0 product. Again, the Avalonia team has a lot of heart and I will definitely be keeping track of their efforts.

      And yes, once you get vendors making controls for you, then you have arrived, indeed. :)

      Mike-EEE commented  · 

      Indeed @birbilis. Ammy, so hot right now. :) Exciting times ahead!

      Mike-EEE commented  · 

      Noesis 2.0 was announced today and is now free for indie development:
      https://twitter.com/noesisengine/status/836880385120301056

      Mike-EEE commented  · 

      @Anonee that is what .NET Standard 2.0 is meant to address (should be announced/released @ this year's //build):

      https://www.infoq.com/news/2016/11/dotnet-standard-20-goals

      Mike-EEE commented  · 

      Far too sensible of an idea, Anonymous... it will never work. ;) But no, if you want to amass a coordinated community effort, why not focus all firepower on Avalonia?

      https://github.com/AvaloniaUI/Avalonia

      Just think: Avalonia uses Mono, and Mono is being ported to WebAssembly. It also already runs/supports the same platforms that Mono does as well. So when Mono finally supports WebAssembly, so will Avalonia (in theory).

      COOL RIGHT??? I just connected those dots. Surprised it took me that long. Avalonia is basically the free/open-source/community counterpart to Noesis.

      Also, "YES" to all of your understandings below. :)

      Mike-EEE commented  · 

      @Philippe I am with you 100% on everything but Xaml referring to UI engines. It is often conflated with UI -- and understandably so as it started out embedded in WPF -- but Xaml by itself evolved into its own assembly and is used for more than UI (Windows Workflow). Feel free to join the discussion here if you haven't already to port System.Xaml to .NET Core:
      https://github.com/dotnet/corefx/issues/5766

      And yeah, Xamarin Forms was a gallant attempt, but it should be shelved ASAP. When I said "combine" w/ UWP I was specifically referring to XF's Xaml system, which is better than UWP's but not as good as WPF's of course. In an ideal world we would want WPF's client model wholesale and replace both XF and UWP, for sure. :)

      Mike-EEE commented  · 

      Correct @Anonymous. The Mono support is simply the ability to run .NET in a WASM host. There is no API that would be used to provide a client UI/GUI within that host at present. Currently there are two known MSFT models that could (and should) be combined (taking the best out of each offering): Xamarin.Forms and UWP.

      Unfortunately (or fortunately, depending on your perspective), WASM exposes a fatal flaw in Xamarin.Forms design. Namely, if you build custom controls, you are required to build a renderer for every platform that is supported by Xamarin.Forms. So if XF adds WASM, that means every control vendor must go through every control and release a new renderer for WASM.

      Very much a pain.

      Obviously, a model such as WPF/Avalonia is preferred where you have one model and your controls are skinned/themed according to the host it is rendering in.

      As for Moonlight, that might be a possibility. It's last known supported featureset is/was SL3, which if you know anything about was nothing compared to SL5. I would rather see a new effort altogether that is community driven like .NETCore/GitHub initiative. Like I said earlier the earliest we'll see anything is 2018.

      Mike-EEE commented  · 

      @Anonymous, that is sort of the request here. There are all sorts of "here and there" endeavors, especially on the JS/HTML5 front with CSHTML5 and Bridge.NET that do "some" of the things we're looking for here, but not all. Noesis is another example. It's got a lot going for it, but it doesn't offer the 3D component. Additionally, it also suffers from the same problem of UWP and doesn't support Markup Extensions ATM. Which to me you might as well say you support XML, not Xaml. :P

      In any case, we're looking for a comprehensive, authoritative vision and offering from MSFT that says "this is the platform." Once you have that, you'll get vendors such as ComponentOne jumping onboard and contributing their goods.

      We're close. All the pieces are there now that Mono is being ported to WebAssembly. My feeling is that //build2017 is going to be all about .NET Standard 2.0 (the terrain), and then //build2018 will be this new platform (the highways). Then it will all about finding the right API (the cars) to best utilize it.

      BTW, EF Core already works on Xamarin in some capacity: https://xamarinhelp.com/entity-framework-core-xamarin-forms/

      Mike-EEE commented  · 

      Indeed, @birbilis. Xaml is simply a (powerful) serialization/data format that allows you to expressively describe .NET objects while leveraging key features that vastly improve the developer (read: tooling) experience when compared with other data formats. You can describe anything in it, whether it is UI, your application domain model, or as you point out, 3D objects. If it's a .NET object, you can describe it in Xaml.

      Anyways, on with our regular Friday morning programming here. :)

      ---

      Weekly Friday morning check-in: 90 votes were cast for this idea last week, bringing the total to 45,280 combined votes across 10 similar ideas asking for a ubiquitous .NET. Please feel free to like and/or retweet to show your support to the "Big Three" here:
      https://twitter.com/DevelopersWin/status/835098020643471360

      Thank you all who have shown and continue to show your support!

      Mike-EEE commented  · 

      Right Philippe, it doesn't support any 3D, but is a cross-platform vector-based .NET rendering solution, which is still impressive in its own right. You might already know this, but just in case, you can pair Noesis with Unity3D to achieve what you are looking for today. In fact Unity currently runs in the web browser via Flash control, so there's that. I am sure they too will be supporting WebAssembly in the next year or so.

      Unity also now support .NET4.5, which is pretty impressive. The only drawback with Unity is that it is a commercial product like Noesis, but more notably does suffer from very un-.NET design in its integration. For instance you are required to create classes that have convention-based methods. So if you misspell a method name it doesn't work. Additionally you get no intellisense around this sort of design (and impacts discoverability).

      You can find an example of this here (look for the "Start" and "Update" methods):
      https://forum.unity3d.com/threads/step-by-step-tutorial-for-c-net-dll-and-unity3d-pro-only.99427/

      Mike-EEE commented  · 

      @Anony, 100% agree. UWP is a tragic, terrible joke. The lack of adoption is proof of its disaster. The group in charge of it continues to be old skool, terribly managed, and still Windows-centric. It is still mired in closed-source thinking and very few parts of it are on GitHub. The only good use for it is a rendering host for another API such as Avalonia, as you suggest.

      Another good candidate, is Noesis. They are top on my list currently. The owners are very engaging and they care about Xaml, unlike the UWP group:
      http://www.noesisengine.com/

      The downside is that they are commerical/licensed/paid. However, considering options it might be worth the investment.

      Mike-EEE commented  · 

      Oh heyyyyyyy look at that. One year ago today someone got drunk @ MSFT and accidentally hit the "Under Review" button for this issue. ;) ;) ;)

      @Anonee, forget all those links (although they are very nice, yes), the only one that matters is the one below where Mr. de Icaza confirms that Mono is currently being ported to WASM. Incidentally, this should give provide a tremendous sense of relief to MSFT management as now they can focus their valuable resources on getting .NET working on toasters. Or whatever else they currently feel is more important than a ~3.5 billion device install market. Gotta "brag" about "something" for next year's Connect(); after all.

      @Anonymous: that has nothing to do with this issue. ;) It's actually the antithesis of this concept. But thank you for sharing. :)

      Mike-EEE commented  · 

      Still blazing along here. We are now over 6k votes and going strong!

      --

      Weekly Friday morning check-in: 136 votes were cast for this idea last week, bringing the total to 45,171 combined votes across 10 similar ideas asking for a ubiquitous .NET. Please feel free to like and/or retweet to show your support to the "Big Three" here:
      https://twitter.com/DevelopersWin/status/832565033859178496

      Thank you all who have shown and continue to show your support!

      Mike-EEE commented  · 

      Digging the conversation here @Anonee, @Anonymous (with a profile picture, LOL), and @Marc. Finding myself nodding. :) Very encouraged about the future here.

      Mike-EEE commented  · 

      This idea has passed 6,000 votes, wh00t! Also, Mr. de Icaza just confirmed that changes are already currently underway for Mono to support WebAssembly:

      http://forums.dotnetfoundation.org/t/wasm-asm-js-plans-projects/1947/4

      Mike-EEE commented  · 

      45k total votes... next stop, 50k. :) We're also a little less than two weeks away from this vote being "Under Review" for an entire year. Whatever that means. :)

      ---

      Weekly check-in: 48 votes were cast for this idea last week, bringing the total to 45,022 combined votes for a ubiquitous .NET across 10 similar votes. Please feel free to like and/or retweet to show your support to the "Big Three" here:
      https://twitter.com/DevelopersWin/status/830037774816382976

      Thank you all who have shown and continue to show your support!

      Mike-EEE commented  · 

      55 more votes and we'll be at a cool 45k collective votes for this idea. Additionally, this idea in particular is looking to ***** 6k on its own soon.

      ---

      Weekly check-in: 85 votes were cast for this idea last week, bringing the total to 44,945 combined votes across 10 similar ideas asking for a ubiquitous .NET. Please feel free to like and/or retweet to show your support to the "Big Three" here:
      https://twitter.com/DevelopersWin/status/827492561497518080

      Thank you all who have shown and continue to show your support!

      Mike-EEE commented  · 

      Slowly inching towards 45k with the total vote here...

      39 votes were cast for this idea last week, bringing the total to 44,830 combined votes across 10 similar ideas asking for a ubiquitous .NET. Please feel free to like and/or retweet to show your support to the "Big Three" here:
      https://twitter.com/DevelopersWin/status/824961553459986432

      Thank you all who have shown and continue to show your support!

      Mike-EEE commented  · 

      FWIW, we're one month away from having this vote being Under Review. It is also in the #2 spot for top ideas on this forum.

      ---

      42 votes were cast for this idea last week, bringing the total to 44,772 combined votes across 10 similar ideas asking for a ubiquitous .NET. Please feel free to like and/or retweet to show your support to the "Big Three" here:
      https://twitter.com/DevelopersWin/status/822420454489157633

      Thank you all who have shown and continue to show your support!

      Mike-EEE commented  · 

      Back to business here. ;)

      46 votes were cast for this idea last week, bringing the total to 44,727 combined votes across 10 similar ideas asking for a ubiquitous .NET. Please feel free to like and/or retweet to show your support to the "Big Three" here:
      https://twitter.com/DevelopersWin/status/819877485542338561

      Thank you all who have shown and continue to show your support!

      Mike-EEE commented  · 

      +1 to Marc. Reflects very poorly on UserVoice and/or MSFT (who should be moderating) to allow such posts to persist, or even publish to begin with. Does anyone there even care anymore? ;)

      Mike-EEE commented  · 

      36 votes were cast for this idea last week, bringing the total to 44,675 combined votes across 10 similar ideas asking for a ubiquitous .NET. Please feel free to like and/or retweet to show your support to the "Big Three" here:
      https://twitter.com/DevelopersWin/status/817356558757675008

      Thank you all who have shown and continue to show your support!

      Mike-EEE commented  · 

      Happy Holidays and Happy New Year to all out there -- especially to all those who have supported this idea. ;)

      26 votes were cast for this idea last week, bringing the total to 44,634 combined votes across 10 similar ideas asking for a ubiquitous .NET. Please feel free to like and/or retweet to show your support to the "Big Three" here:
      https://twitter.com/DevelopersWin/status/814819575955161089

      Thank you all who have shown and continue to show your support!

      Mike-EEE commented  · 

      52 votes were cast for this idea last week, bringing the total to 44,596 combined votes across 10 similar ideas asking for a ubiquitous .NET. Please feel free to like and/or retweet to show your support to the "Big Three" here:
      https://twitter.com/DevelopersWin/status/812270296476614656

      Thank you all who have shown and continue to show your support!

      Mike-EEE commented  · 

      40 votes were cast for this idea last week, bringing the total to 44,528 combined votes across 10 similar ideas asking for a ubiquitous .NET. Please feel free to like and/or retweet to show your support to the "Big Three" here:
      https://twitter.com/DevelopersWin/status/809733206186594304

      Thank you all who have shown and continue to show your support!

      Mike-EEE commented  · 

      31 votes were cast for this idea last week, bringing the total to 44,459 combined votes across 10 similar ideas asking for a ubiquitous .NET. Please feel free to like and/or retweet to show your support to the "Big Three" here:
      https://twitter.com/DevelopersWin/status/807216642002472964

      Thank you all who have shown and continue to show your support!

      Mike-EEE commented  · 

      Indeed Marc, it may be impossible to drop all server codes *now* but that is the direction we're heading. I am in agreement with your passionate hate towards JavaScript, of which it is unadulterated. :P

      FWIW, I dropped HTML/JS/Perl back in 2001 to pick up Visual Studio and learn .NET. I dropped JS with the intent of never having to deal with its ugly face again. However, since it does work in more places than .NET now, it by essence more valuable and is why companies are gravitating towards it.

      I have seen this with my own clients and there is chatter along the web. The best example (and corresponding diaglogue) can be found here, if you can wade through the discussion:
      http://forums.dotnetfoundation.org/t/cross-platform-wpf/421

      Mike-EEE commented  · 

      I agree Marc, it doesn't make sense, but if you excuse the pun, it makes cents. :p

      Companies are tired of hiring two types of developers for two different code bases in JavaScript *and* .NET, as it is expensive not only in time but money. Since JavaScript works in the client browser process and .NET does not, they are dropping .NET altogether and going strictly with JavaScript everywhere. This not only means a simpler development paradigm, but means yielding nearly half the TCO (total cost of ownership) of their projects while putting the savings back into their pockets.

      ---

      Now, onto our regular scheduled programming... :)

      ---

      53 votes were cast for this idea last week, bringing the total to 44,414 combined votes across 10 similar ideas asking for a ubiquitous .NET. Please feel free to like and/or retweet to show your support to the "Big Three" here:
      https://twitter.com/DevelopersWin/status/804662238510534656

      Mike-EEE commented  · 

      92 votes were cast for this idea last week, bringing the total to 44,357 combined votes for a ubiquitous .NET across 10 similar votes. Please feel free to like and/or retweet to show your support to the "Big Three" here:
      https://twitter.com/DevelopersWin/status/802147307953209345

      Thank you all who have shown and continue to show your support!

      Mike-EEE commented  · 

      72 votes were cast for this idea last week, bringing the total to 44,256 combined votes for a ubiquitous .NET across 10 similar votes. Please feel free to like and/or retweet to show your support to the "Big Three" here:
      https://twitter.com/DevelopersWin/status/799618538818457600

      Thank you all who have shown and continue to show your support!

      Mike-EEE commented  · 

      82 votes were cast for this idea last week, bringing the total to 44,172 combined votes for a ubiquitous .NET across 10 similar votes. Please feel free to like and/or retweet to show your support to the "Big Three" here:
      https://twitter.com/DevelopersWin/status/797091992949891072

      Thank you all who have shown and continue to show your support!

      Mike-EEE commented  · 

      89 votes were cast for this idea last week, bringing the total to 44,086 combined votes for a ubiquitous .NET across 10 similar votes. Please feel free to like and/or retweet to show your support to the "Big Three" here:
      https://twitter.com/DevelopersWin/status/794553664815828994

      Thank you all who have shown and continue to show your support!

      Mike-EEE commented  · 

      Excellent article, anonymous! Thank you for sharing.

      Mike-EEE commented  · 

      Glad to hear you "get it" Marc. :) I added on this topic (from a business perspective) with a recent post here:
      http://blog.developers.win/2016/11/why-an-html5-compliant-net-is-important/

      Mike-EEE commented  · 

      Couple of links to note:

      Telerik has created a NativeScript that allows you to code in TypeScript/JavaScript native applications. This essentially makes JavaScript the only language you need to know to create ubiquitous applications, meaning you no longer need to know objective-c, java, or even .NET. :P
      http://searchcloudapplications.techtarget.com/podcast/NativeScript-framework-eases-cross-platform-app-development-woes

      Also, Avalonia seems to be picking up steam. Maybe the answer here is to put official, authoritative support (and resources) from MSFT behind this project, which would include implementing 3D and WebAssembly support? By doing so, you will have effectively created a truly ubiquitous .NET client application development model:
      https://github.com/AvaloniaUI/Avalonia

      Mike-EEE commented  · 

      99 votes were cast for this idea last week, bringing the total to 43,986 combined votes for a ubiquitous .NET across 10 similar votes. Please feel free to like and/or retweet to show your support to the "Big Three" here:
      https://twitter.com/DevelopersWin/status/791975480954089473

      Thank you all who have shown and continue to show your support!

      Mike-EEE commented  · 

      125 votes were cast for this idea last week, bringing the total to 43,876 combined votes for a ubiquitous .NET across 10 similar votes. Please feel free to like and/or retweet to show your support to the "Big Three" here:
      https://twitter.com/DevelopersWin/status/789464549518872576

      Thank you all who have shown and continue to show your support!

      Mike-EEE commented  · 

      Hey, would you look at that? This idea is over 5,000 votes as of today. I am personally humbled and amazed to see the success it has received over the past year. Thank you to all who have shown and continue to show their support!

      Mike-EEE commented  · 

      60 votes were cast for this idea last week, bringing the total to 43,728 combined votes for a ubiquitous .NET across 10 similar votes. Please feel free to like and/or retweet to show your support to the "Big Three" here:
      https://twitter.com/DevelopersWin/status/786909745110196224

      Thank you all who have shown and continue to show your support!

      Mike-EEE commented  · 

      181 votes were cast for this idea last week, bringing the total to 43,661 combined votes for a ubiquitous .NET across 10 similar votes. Please feel free to like and/or retweet to show your support to the "Big Three" here:
      https://twitter.com/DevelopersWin/status/784488818820775937

      Thank you all who have shown and continue to show your support!

      Mike-EEE commented  · 

      205 (!) votes were cast for this idea last week, bringing the total to 43,457 combined votes for a ubiquitous .NET across 10 similar votes. Please feel free to like and/or retweet to show your support to the "Big 3" here:
      https://twitter.com/DevelopersWin/status/781850028142919682

      Thank you all who have shown and continue to show your support!

      Mike-EEE commented  · 

      70 votes were cast for this idea last week, bringing the total to 43,248 combined votes for a ubiquitous .NET across 10 similar votes. Please feel free to like and/or retweet to show your support to the "Big 3" here:
      https://twitter.com/DevelopersWin/status/779298435291877376

      Mike-EEE commented  · 

      73 votes were cast for this idea last week, bringing the total to 43,164 combined votes for a ubiquitous .NET across 10 similar votes (wpdev adjusted their voting system last week so the totals are lower than last). Please feel free to like and/or retweet to show your support:
      https://twitter.com/DevelopersWin/status/776770240646643712

      Mike-EEE commented  · 

      64 votes were cast for this idea last week, bringing the total to 44,374 combined votes for a ubiquitous .NET across 10 similar votes. Please feel free to like and/or retweet to show your support:
      https://twitter.com/DevelopersWin/status/774243669557870592

      Mike-EEE commented  · 

      React Native for Web, doing exactly what MSFT should be doing for .NET. :P
      https://www.smashingmagazine.com/2016/08/a-glimpse-into-the-future-with-react-native-for-web/

      Mike-EEE commented  · 

      Over 4,000 votes as of today! Thank you so much to everyone that has supported this.

      @Anonymous I was like you and was getting concerned that I haven't heard anything in a while in WebAssembly, so I contacted my Google contact who has been working with this. This is very much in play, and the Git repo is pretty active:
      https://github.com/WebAssembly/

      MSFT Edge has already declared support for it so in SOME fashion we should ultimately see SOMETHING... SOMEWHERE. LOL. Of course the end result remains the key here.

      It does appear the IL efforts in the Git repo have waned. That doesn't mean that MSFT isn't working on their own efforts. The fact that this vote is Under Review, along with Miguel's Reddit comments below make me cautiously optimistic here.

      MSFT makes announcements every November (connect(); ) and Mayish (//build). So I am looking forward this November for the first signs of anything, if anything. :P

      Mike-EEE commented  · 

      @Gavin, yeah the original ask can be seen as a little ambitious, but we're actually very close to the heart and soul of what this is after. iOS, Droid, and Windows 10 (really the only Windows to consider) are covered now after the Xamarin acquisition. The only platform that needs the MSFT luv is WebAssembly (which pretty much every comment except yours has been asking for. ;)).

      Making sure that it can account for future platforms would be nice, too. Since there are now 3 with Miguel de Icaza saying that WebAssembly should be "simple" to add, this appears to be accounted for:
      https://www.reddit.com/r/programmerchat/comments/4dxpcp/i_am_miguel_de_icaza_i_started_xamarin_mono_gnome/d1v9xyd

      Finally, if you truly feel that MSFT doesn't have "infinite development potential"... maybe you're in the wrong crowd? Perhaps go learn Java or JavaScript, instead? ;) ;) ;)

    • 127 votes
      Vote
      Sign in
      Check!
      (thinking…)
      Reset
      or sign in with
      • facebook
      • google
        Password icon
        Signed in as (Sign out)
        You have left! (?) (thinking…)
        26 comments  ·  Visual Studio IDE » Languages - C#  ·  Flag idea as inappropriate…  ·  Admin →
        Mike-EEE commented  · 

        OMG NOW THERE IS AN IAsyncDisposable -- not to be confused with IDisposableAsync that follows all the suggested conventions established to date ;) -- THAT IS JUST LIKE IDisposable BUT WITH ASYNC Y'ALL... zombie much?

        https://youtu.be/QZ0rWLaMZeI?t=1h2m40s

        Mike-EEE commented  · 

        Oh TAP, how you continue to suck out a week's worth of time from my soul, every time I touch you:
        https://github.com/dotnet/docs/issues/4973

        Mike-EEE commented  · 

        WE CAN DO BETTER!!! I KNOW WE CAN!!! :) :) :)

        "From these results, we see that there is a real and significant overhead to using tasks. In situations with very low cost operations and extreme throughput requirements, it makes sense to avoid tasks."

        https://www.danielcrabtree.com/blog/248/maximizing-throughput-the-overhead-of-1-million-tasks

        Mike-EEE commented  · 
        Mike-EEE commented  · 

        And above all... it's SLOW! How slow, you ask? THIS SLOW:
        https://twitter.com/AntaoAlmada/status/836239173413564421

        :o

        Mike-EEE commented  · 

        Another solid article demonstrating some more gotchas. You know what, instead of waiting for this issue to be addressed, just follow this blog in the meantime. :P

        http://blog.i3arnon.com/2017/02/21/task-wrapper/

        Mike-EEE commented  · 

        @Mani, as I have stated below, the infestation concept is not local to this idea. Here is an article on MSDN that acknowledges this very quality:
        https://msdn.microsoft.com/en-us/magazine/jj991977.aspx

        Search for zombie or turles. There is definitely a "spread" or "infection" of the code that follows integration of this API. While you are correct to state that the compiler requires these words, the *idea* again (this being an idea/suggestion site) is to improve this API so that these words are not needed, thereby returning cleaner code/design to our solutions.

        Additionally, the guidance you provide for calling ".Wait()" while intuitive is actually one of the gotchas for using this API:
        http://blog.stephencleary.com/2012/07/dont-block-on-async-code.html

        Mike-EEE commented  · 

        Some more pitfalls and explaining away of TaskAPI here:
        http://blog.stephencleary.com/2016/12/eliding-async-await.html

        Mike-EEE commented  · 

        Async gotchas are now making their way into MSFT code, making a clinic on how not to write async code. The horror:
        https://twitter.com/Nick_Craver/status/799304014001270784

        Mike-EEE commented  · 

        API's getting bit by the void async oddity:
        http://brianlagunas.com/prism-delegatecommand-fromasynchandler-is-obsolete/

        Yes, we can do better. :) :) :)

        Mike-EEE commented  · 

        I appreciate your zeal to preserve the status quo (or rather, unnovation) here, but I think it's safe to say that if users are comparing your API to a zombie infestation, that there is room for improvement. :P This is not my term, either. This is a well-used term you can see in both blogs and StackOverflow, which of course is quite apt.

        With that said, you're thinking with current restrictions and designs, while the point of the idea is to improve upon them with further innovation, perhaps (and most likely) with new language keywords and syntactic sugar.

        I agree this a non-trivial ask, and will involve many IQ cycles that unfortunately are outside of my scope and experience here. All I (and others know) is that I/we had pretty, consistent code, interfaces, and design before TPL, and now with post-TPL they are gone, with a whole lot of zombie horde to double-tap in its wake.

        https://www.youtube.com/watch?v=JmA2WYyw-_A

        :P

        Mike-EEE commented  · 

        @Joseph, You bet I'm complaining. :) Complaining with hopes of improving, as per the title of the vote.

        I'm afraid you're going to have to work a little more to convince me how being infested with zombies is *ideal*. Sounds like were once a human coder and have been bitten and overrun by the horde. :P

        If you mean in the current scope of capability, that is one thing, but that is not the ask here. The ask is to remove the zombie infestation altogether, along with the inordinate esoteric requirements to work with the current API, of which I am sure you are painfully familiar with, or at least were at some point.

        We can do better, I KNOW WE CAN!!! :)

        Mike-EEE commented  · 

        This looks like a vote/issue that will address some of the notorious TPL friction. Please upvote it here:
        https://github.com/dotnet/corefx/issues/8931

        Mike-EEE commented  · 

        Cool, thanks for the share, Qwertie. It's got my votes. :) To be sure, this vote is asking for improving TPL as a whole, in any way necessary/possible. If that involves stack switching (or really, ANYTHING to defeat the zombies and esoteric usage friction), then so be it. :)

        Mike-EEE supported this idea  · 
        Mike-EEE commented  · 
      • 6,009 votes
        Vote
        Sign in
        Check!
        (thinking…)
        Reset
        or sign in with
        • facebook
        • google
          Password icon
          Signed in as (Sign out)
          You have left! (?) (thinking…)
          75 comments  ·  Visual Studio IDE » .NET  ·  Flag idea as inappropriate…  ·  Admin →
          Mike-EEE commented  · 

          Wow thanks for the share @horeaper. Sharing further. :)

        • 1,185 votes
          Vote
          Sign in
          Check!
          (thinking…)
          Reset
          or sign in with
          • facebook
          • google
            Password icon
            Signed in as (Sign out)
            You have left! (?) (thinking…)
            25 comments  ·  Visual Studio IDE » Windows Forms  ·  Flag idea as inappropriate…  ·  Admin →
            Mike-EEE commented  · 
          • 2,004 votes
            Vote
            Sign in
            Check!
            (thinking…)
            Reset
            or sign in with
            • facebook
            • google
              Password icon
              Signed in as (Sign out)
              You have left! (?) (thinking…)
              227 comments  ·  Visual Studio IDE » Languages - Visual Basic  ·  Flag idea as inappropriate…  ·  Admin →
              Mike-EEE commented  · 

              @Mark does that support web/HTML5? Does not seem obvious if so...

              Mike-EEE commented  · 

              LOL... bwahaha... OMG my troll-lord is clearly dusty... rusty, even. :)

              We're all part of the same community here, regardless of the language we find ourselves in or makes us passionate. VB/VB6 is as much of MSFT culture as .NET. Let's please reserve the name-calling for the web hacks and JavaScript kiddies where it belongs, K? :) :) :)

              Mike-EEE commented  · 

              I am beginning to understand why you are so familiar with what being a moron is all about.

              You pasted: "TRANSFER YOU CODE TO ALL PLATFORMS ... !!!"

              To which I said "care to show us how to do this with web browser?" As the web browser is the BIGGEST platform of them all.

              To which you said "NET will NEVER run in a browser" and let's not forget your instant classic "it's a server side technology"

              As I have demonstrated, both of these statements are patently false, in addition to espousing the originating (false) belief that you can transfer code to ALL platforms, as you simply cannot do this for a web browser-hosted application -- the biggest platform of all (topping in at around 3.5 BILLION devices and workstation).

              > The only client side instance of .NET that ever existed in the context of a web app is Silverlight, and it's deprecated

              Again, not true, in addition to JSIL there is:
              http://cshtml5.com

              Which is built on JSIL with a dedicated team and company in France working on it full time.

              Additionally, there is:
              http://bridge.net
              http://duoco.de

              Both are transpilers that effectively do the same thing as JSIL, but in a more HTML5 DOM-oriented way.

              Finally, I suggest you look up the word "moron" before you continue this discussion, just so you have a better grasp on at least one of the concepts you are trying to talk about.

              Also, the word "irony."

              Mike-EEE commented  · 

              LOL @HMan you clearly do not know how .NET works. JSIL converts IL instruction into JavaScript, the bytecode of the browser. What is the difference between that and how Xamarin translates IL to work on iOS and Droid? is Xamarin not .NET either?

              Seriously dude. Spend more time reading a book rather than trying to troll on a user forum, LOL.

              "None of these address the web. In the context of web applications, .NET is a server side technology. JavaScript is a client side technology."

              But you just said that .NET is a server-side technology. Here let me paste again what you said. "it's a server side technology". You DID say that, right? Let me paste it again to make sure "it's a server side technology". Yep, looks like you.

              But it DOES clearly run in client-side scenarios as seen on iOS, Droid, and Windows clients. So... which is it? Certainly you're not a moron who doesn't know the difference between server-side and client-side? Please enlighten us here.

              "List to me what other languages run in a web browser" ... the only one you need is JavaScript, which is 100% ubiquitous and works everywhere -- even where .NET can't, in all modern browsers as a host. I just demonstrated a working proof concept framework that takes .NET code and transpiles it into JavaScript, EXACTLY the same way that Xamarin compiles .NET code into the target platforms of iOS and Droid. And it does so in a 100% standards-compliant cross-platform way.

              The only hitch is that it has been a side project of some wizkid out of CA for the past 5 years, rather than a full-blown endeavor of an entire MSFT division as it should have been once Silverlight strategy shifted. :(

              Mike-EEE commented  · 

              LOL dude... I don't even know where to start.

              "it's a server side technology"... then how do you explain WPF, iOS, Droid, Windows Forms, Xamarin.Forms, Silverlight...?

              You copy/pasted a declaration that you can use .NET on "any" platform, when in fact you cannot run .NET in a web browser, the biggest platform there is.

              ".NET will NEVER run in a browser"

              Cover your eyes then: http://jsil.org

              ;) ;) ;)

              Before you go about calling people morons, you should probably take some time to study the space you're so sure about.

              Mike-EEE commented  · 

              @HMan, .NET isn't just a server framework, it is an application framework that can run in any hosted environment, which at present includes:
              - Server
              - iOS
              - Droid
              - Windows

              You will notice that one of those scenarios isn't listed, and that is the browser. An "ASP.NET website" is .NET on the server, but what gets rendered in the browser is HTML/JS, which is completely incompatible with .NET, the result of which is having to maintain two incompatible codebases: one in .NET on the server, and one in JavaScript on the client. This means twice the amount of work (bugs), and resources (cost) in doing so.

              You call people morons but seem to think this is a good and acceptable idea. Hm. :)

              So, simply saying to use .NET for VB6 (or this idea) doesn't apply just yet, as .NET doesn't run within the browser host.

              Mike-EEE commented  · 

              LOL Zagor: "TRANSFER YOU CODE TO ALL PLATFORMS ... !!!!"

              Care to show us how to make .NET work in a web browser, the biggest platform of all? ;) ;) ;)

            • 6 votes
              Sign in
              Check!
              (thinking…)
              Reset
              or sign in with
              • facebook
              • google
                Password icon
                Signed in as (Sign out)

                We’ll send you updates on this idea

                0 comments  ·  Visual Studio Team Services » CI (Build)  ·  Flag idea as inappropriate…  ·  Admin →
                Mike-EEE shared this idea  · 
              • 35 votes
                Vote
                Sign in
                Check!
                (thinking…)
                Reset
                or sign in with
                • facebook
                • google
                  Password icon
                  Signed in as (Sign out)
                  You have left! (?) (thinking…)
                  3 comments  ·  Visual Studio IDE » UWP / WPF / XAML Tools  ·  Flag idea as inappropriate…  ·  Admin →
                  Mike-EEE commented  · 

                  Man na, the point being that a formatted data language is more tool-friendly and therefore more cost-effective for developing applications and solutions that utilize them. TFS Xaml is not "Xaml" but a consumer (and producer) of it. Xaml is the format/language that makes it work. You cannot build a (cost effective) solution around imperative code, but you can easily around a formatted language.

                  Also, this is not a discussion/idea around supporting one format over the other. Personally I believe MSFT should innovate this space and make an underlying data format/language much like how IL works in .NET. From this format you can load and save all other formats, particularly the one that works best with tooling and environments found in a given organization and the developers that they employ.

                  Randy Jackson feels me: https://www.youtube.com/watch?v=nT7500qDa7E

                  Mike-EEE shared this idea  · 
                • 63 votes
                  Sign in
                  Check!
                  (thinking…)
                  Reset
                  or sign in with
                  • facebook
                  • google
                    Password icon
                    Signed in as (Sign out)

                    We’ll send you updates on this idea

                    Mike-EEE commented  · 

                    Wow... started nearly two years ago. Still not done?

                    Mike-EEE supported this idea  · 
                  • 5 votes
                    Sign in
                    Check!
                    (thinking…)
                    Reset
                    or sign in with
                    • facebook
                    • google
                      Password icon
                      Signed in as (Sign out)

                      We’ll send you updates on this idea

                      1 comment  ·  Visual Studio Team Services » CI (Build)  ·  Flag idea as inappropriate…  ·  Admin →
                      Mike-EEE commented  · 
                      Mike-EEE supported this idea  · 
                    • 16 votes
                      Sign in
                      Check!
                      (thinking…)
                      Reset
                      or sign in with
                      • facebook
                      • google
                        Password icon
                        Signed in as (Sign out)

                        We’ll send you updates on this idea

                        2 comments  ·  Visual Studio Team Services » CI (Build)  ·  Flag idea as inappropriate…  ·  Admin →
                        Mike-EEE shared this idea  · 
                      • 1 vote
                        Sign in
                        Check!
                        (thinking…)
                        Reset
                        or sign in with
                        • facebook
                        • google
                          Password icon
                          Signed in as (Sign out)

                          We’ll send you updates on this idea

                          Mike-EEE commented  · 

                          Additionally, the big plus symbol in the backlog view is not lightweight and fast, like the board's. It opens up a new dialog box and you have to put in a bunch of information. Each of these views should have the same experience! And make them configurable so that if you want light-weight task-list TODO, you get THAT, and if you want a big dialog box, you get THAT. Sometimes I am going in TODO style and then others I am going in with more detail. Quick n' dirty vs. styled and composed. Both views should be able to cater to both with a click of a button or keyboard press.

                          Mike-EEE shared this idea  · 
                        • 156 votes
                          Vote
                          Sign in
                          Check!
                          (thinking…)
                          Reset
                          or sign in with
                          • facebook
                          • google
                            Password icon
                            Signed in as (Sign out)
                            You have left! (?) (thinking…)
                            5 comments  ·  Visual Studio IDE » Languages - Other  ·  Flag idea as inappropriate…  ·  Admin →
                            Mike-EEE commented  · 

                            @KP correct. Well, it would *support* them as they do now. That is simply a matter of creating the symbols and ensure they align with the view that the developer has applied to their code. :)

                          • 36 votes
                            Vote
                            Sign in
                            Check!
                            (thinking…)
                            Reset
                            or sign in with
                            • facebook
                            • google
                              Password icon
                              Signed in as (Sign out)
                              You have left! (?) (thinking…)
                              5 comments  ·  Visual Studio IDE » Cloud  ·  Flag idea as inappropriate…  ·  Admin →
                              Mike-EEE commented  · 

                              Thanks for your feedback and response @pcchan. I am open to ANY improvement over the current system, as what is in place now makes it seem like you don't really care or have much pride/concern to what your users must endure to communicate with you and/or each other.

                              I'm even OK with using LiveFyre as the new docs has (unfortunately) switched over to, even though it is a property that was recently acquired by Adobe... you know, your historically bitter rival. :P

                              Anything but what is in place now, please. :) :) :)

                              Mike-EEE commented  · 

                              Ahhhhhh... docs.microsoft.com moved away from Disqus!
                              Example: https://docs.microsoft.com/teamblog/stackoverflow-documentation-for-microsoft-developers/

                              Oh well. Again anything is better than Wordpress. :P

                              Mike-EEE commented  · 

                              Good points, @tsahi. Thank you for your feedback and perspective. I believe Disqus does offer custom solutions that might be able to cater to these issues. That is, I have seen sites that offer Disqus, but it is customized specifically to that site (e.g., site-specific authentication and not using Facebook/Disqus's auth).

                              On the flip side, you cannot see the activity from other Disqus sites in your own, which is also pretty valuable metrics, too. :)

                              So, choose your poison. Of course, Disqus is not the only option. There is LiveFyre which was recently acquired by Adobe, but I do not consider it as advanced (or pervasive/popular) as Disqus. To get a good idea of how popular Disqus is with the .NET crowd especially, check out the blog posts that are shared weekly by the "This Week in .NET" series and note how many of them utilize it.

                              All I know (and it sounds like we are in agreement on this at least) what is in place now is an absolute embarrassment and must change... someway, somehow. :P

                              Mike-EEE supported this idea  · 
                            • 121 votes
                              Vote
                              Sign in
                              Check!
                              (thinking…)
                              Reset
                              or sign in with
                              • facebook
                              • google
                                Password icon
                                Signed in as (Sign out)
                                You have left! (?) (thinking…)
                                9 comments  ·  Visual Studio IDE » Languages - C#  ·  Flag idea as inappropriate…  ·  Admin →
                                Mike-EEE supported this idea  · 

                              Feedback and Knowledge Base