Times are a'changing :)
"Official" thread here (for now ha ha):
Nice conversation here, jump on in and let your voices be heard. :)
LOL @ Anonymous ... this is starting to remind me of the epic "YES!" "NO!" debate/rant/post fest that happened with bringing back Silverlight in Edge:
The bottom line here is that there are two camps that MSFT has (unfortunately) created: web application developers and native application developers. Conceptually, they are one and the same (and ideally they should be!), but because of confusing/questionable strategy/direction we have now ended up with these two conflicting camps, with completely incompatible approaches and neither likes the ways of the other. Sounds like someone was inspired by our political system here in the US. :D
There's been good feedback like yours Michael. Thank you for sharing and hopefully MSFT will consider this with its new project system. To start with, I am not sure how you don't think Xaml is not tool friendly while JSON is. With Xaml you only require two artifacts:
1) Class definition (.cs file)
2) Data file (.xaml file)
Whereas with the JSON approach, you require 3:
1) Class definition (.cs file)
2) Data file (.json file)
3) JSON Schema (yet another .json file)
Then you need some way of linking up that 3rd schema file. JSON is supposed to be terse and standardized, but you end up having to define an arbitrary, unusual "$schema" attribute to point to its schema. With Xaml this is baked in to the root element and xmlns attribute and the tooling catches on to it without any sort of configuration.
Don't get me wrong, I see, understand (I hope! :D ), and appreciate the value of JSON: for describing objects in a compact, human-readable manner that's intended to transfer across service boundaries. The fact that the standard doesn't support comments reflects this intent. Any extended use of this travels into dangerous territory as now you are violating/bending a "standard" that might further be used (read: copy/paste) down the line that ends up breaking in interoperable scenarios.
At the end of the day, we have two developer scenarios: creating objects that are meant for transfer (lightweight/compact/terse: JSON is great for this), and defining applications that create those objects (significant/verbose: XAML is great for this). Of course, there are developers that prefer to keep the same format throughout their solutions to minimize context-switching and maximize efficiency, so this should be considered, too.
As a business owner, I would prefer to have one language (C#) and one data format (Xaml) all the way through my solutions. That way, I not only have to worry about working with just these formats in any of my solutions (less time in context-switching) but I also benefit in seeking the resources from the marketplace necessary to manage/maintain them by was of a simpler more defined/exact skillset. Incidentally, this is another reason why I think it's so important for a consolidated, ubiquitous .NET client application model, as well:
"We also need to make it easy to work with projects across these application models. In order to do this we are working to merge the capabilities of .xproj/project.json and .csproj project systems into a single project system based on MSBuild."
Sounds promising! And the right thing to do. :)
Here's an article that sums up the discussion so far, discussing the tweet below, how Visual Studio is not actually following the .json specification, and screenshots/example of how Xaml is a viable object-definition language -- especially for things like project structure definitions:
Thank you john.ludlow.uk. Your support is much appreciated. :) Glad I am not alone here.
FWIW, something to consider here. This seems to be speaking directly to project.json:
1 voteMike-EEE shared this idea ·
Correct, shimmy. All of the "Big Four" are accounted for, with the exception of the Web.
I would also like to share my appreciation for your comment along with Lukas and Alberto's comment. And by appreciation I mean 100% agreement and shared vision. :)
I also have to say I am a bit disappointed in //build and Evolve in that no cross-platform UWP was announced. Xamarin.Forms is a good stab, but has a lot of problems. I guess for the time being the best answer is Perspex, which is very much under development (and does not support web):
Pretty awesome... wonder if this can now be used to integrate WebAssembly somehow?
FWIW, this vote is mentioned in the following article: Azure, Xamarin, and ... a Ubiquitous .NET?
Indeed, Eder! Very VERY happy about that -- to say the least! Cannot thank everyone enough, including the Visual Studio team -- assuming someone didn't hit the wrong button over there or something, ha ha!
FWIW, here is a post I made about this very update here: http://blog.developers.win/2016/02/for-your-review-we-are-under-review/
Totally more than I ever expected when I started this vote 4 months ago and I am forever humbled and honored by all that has transpired since then. FWIW, at *best* I was expecting to reach 1,000 votes after one year, let alone two months. Getting 2,000+ votes after 4 months has just rocked my world! And of course I was expecting like 4 or 5 *YEARS* to get *any* sort of recognition/acknowledgement from MSFT, so that has been wonderful as well.
Granted, it's still just a simple update (without any explanation, no less) but to me that's like getting attention from the hottie in the room ha ha. Like I mentioned in other threads, I feel that question marks are starting to turn into exclamation marks and MSFT really is starting to feel like they are starting to move in the right direction again. :)
Whoaaaa... thank you @Philippe Monteil for taking the time to elucidate this very new and emerging concept and technology. Outstanding, even! I do indeed think you have identified the preferred pathway here. I have known about WASM for a while now, but now that I have a better understanding of it I will be using it in my messaging going forward.
Let's call it... WASM.NET! :D
This pretty much sums me up right about now:
OK I will now take deep breaths and count to 10. :P
Please educate us, good sir. :)
LOL @Marc Roussel! When a UserVoice thread becomes a product's tech support. ;) Marc, that looks like C# to me, albeit terribly formatted. Are you concerned about the [Ready] attribute?
In any case, I am very appreciative of Bridge.NET supporting this cause and for sharing their project here and for the dialogue that has transpired here. @Philippe Monteil, that link is fantastic. Thank you. Easily the best article I have seen on WebAssembly to date.
The important and key part is to nicely integrate it with all the new stuff that MSFT/Xamarin are doing so that we are all one, big, synchronous, happy .NET family again. :) :) :)
Once we have this solved it is going to be a golden -- nay, DIAMOND! -- era in Microsoft and .NET history, I dare do say!
Exactly Scott... this definitely bodes well for our cause here. However, if only iOS and Droid are accounted for, and not browser-hosted scenarios, then NodeJS will still have a competitive, cost-effective advantage. It would be great to see the new Xamarin integration yield a new client application model that is based on a stronger Xaml offering (like WPF, NOT like UWP) and can compile/transpile for the big four: iOS/Droid/Windows and Web. :)
How NodeJS is Dominating .NET in 3 Easy Charts:
SO CONFUSING!!! ;)
A solid example of an asynchronous "gotcha": https://ayende.com/blog/173057/production-postmorterm-houston-we-have-a-problem
Yeah... it still burns. Silverlight was really WPF that ran in a browser. It got killed because it really wasn't truly interoperabie/cross-platform. I think the dynamic now has changed in the marketplace we find ourselves in. We now have four platforms that have started to settle, and comprise ~3.5B devices: iOS (~1B devices), Droid (~1.5B), Windows (~1B with 270M announced yesterday being Windows 10), and the web, which is HTML5 these days and runs on all of the 3.5B devices in some form or another.
Xamarin takes care of the native (non-web) scenarios, but the web continues to be a question mark. If WebAssembly turns out to be the answer then we really have a something to build towards.
Cool... thanks for the context and information, @Sten2005. I fully hear/feel you on the abandoned worry. I'm a hardened (bitter?) Silverlight developer (from version 1-5), so I know all about that pain. What I see in .NET is that it is the most mature (and popular?) MSFT tech to date. My thought is that if MSFT were to push for one grand version of a platform that enabled every possible scenario -- not unlike what NodeJS currently enjoys -- and sticks with it offering full and committed support, then it would pretty much solve every known problem in its ecosphere.
Then, using this (cross-)platform infrastructure, it could put any sort of technology it wishes on it, the most obvious being .NET and VB6.
Big, impossible thinking, I know. LOL. But it would be cool to see. The goal being that you can start to invest with a MSFT technology and be assured that those investments will carry into the future without fear of abandonment and/or irrelevance.
LOL @ "Xamarin dead end!" Funny. I am curious if someone can speak to why VB6 is preferred over VB.NET?
If .NET was made so that you could build applications to run in a browser through the use of WebAssembly (more here: http://moduscreate.com/webassembly-explained/ ), would this also be an acceptable solution? I thought VB.NET was a better/next version of VB6?
In my view, this is something an entire MSFT division should have been dedicated to doing, rather than some kid with lofty ambitions and a lot of spare time on his hands. It definitely should be a strategy and focus of MSFT going forward, and should expand into all areas of its technology IP portfolio, even VB6 if possible. :)
(And yes, it should have DEFINITELY happened with Silverlight: http://dotnetfuture.wufoo.com/forms/m1azjhyi1ozawho/ )