microsoft / xaml-standard

XAML Standard : a set of principles that drive XAML dialect alignment
Other
805 stars 50 forks source link

Is this repo dead? #230

Closed GeraudFabien closed 5 years ago

GeraudFabien commented 6 years ago

All in the title. Since May 2017 no real news. .... What MS thinks about it? What the community thinks? What "other implementation guys" like Avalon thinks?

Mike-E-angelo commented 6 years ago

Cool... thank you for that context, @dotMorten.

niels9001 commented 6 years ago

https://youtu.be/tkiPcCHGngY?t=17m51s Interesting answer - UWP going cross platform in the future?

dotMorten commented 6 years ago

Microsoft is spending resources on porting Edge

No, they are not. First of all that would be against Apple policies. They are using the same rendering engine Apple's browser are. Think of it as Edge chrome around Safari. This is more about being able to integrate better with Windows (share bookmarks, continue-on-PC, the Microsoft Graph/Timeline etc).

Meanwhile, a real cross platform XAML solution, the number one request put to Microsoft, and their response, "sorry, can you repeat that."

So you're saying that the team doing this, is the reason they can't do the other thing? Because Microsoft is this teeny tiny company that only has that one single resource? Don't be ridiculous. These are completely different teams with a completely different set of resources.

This has probably been requested by a total of 3 developers

Nice one. Let's make up some more completely irrelevant facts. That's helpful. I know a lot of users (not developers!) who enjoy the integration with the Microsoft Graph / Timeline, and it's only just starting.

Note to self: I really need to stop feeding these silly trolls

dotMorten commented 6 years ago

The UWP toolkit still doesn't have a DataGrid

You need to pay more attention. That was added and announced during Build (it was even used in the Tuesday keynote).

Hopefully someday, someone there at Microsoft will start actually listening to their desktop developers.

Did you miss all the announcements at Build? Like the .NET Core App Local under WPF ? The XAML language alignments coming to XF3.1? XAML Islands? All of these features are coming due to frequent developer demand. Also please consider that things don't just happen because something has a lot of votes. Naturally return of investment, feasibility, breaking existing customers, telemetry etc all play into this.

I'm not trolling, I'm shaming

Potato Potahto. Call it whatever you want, but this "shaming" stuff doesn't help (how would you react to somone yelling and "shaming" at you?), Please be more constructive instead. I can almost guarantee you most people have muted this thread, because it's gone completely off the rails.

LazyGepid commented 6 years ago

I'm with jackbond on this one. Microsoft either needs to say that they will offer a cross platform solution or not. The worst thing they can do is leave people in the dark. It creates animosity.

dotMorten commented 6 years ago

Microsoft either needs to say that they will offer a cross platform solution or not.

??!? They do

LazyGepid commented 6 years ago
A **comprehensive** cross platform solution. Better?
niels9001 commented 6 years ago

.NET is so amazing.. you can build bots infused with AI, you can build apps for Xbox, heck even HoloLens. You can create awesome back-ends for your web apps. It covers it all, except... The actual web app. And guess what the whole world is using?

I get that it's hard.. but with React/Angular everywhere, Microsoft needs to have an answer. Or come up straight, and tell us they are not going to invest in it and that they would recommend X because it works so great with their product Y.

It would be good to have some sort of sign from them that they are actually working on this and to ship it. Even at Build I asked MS people, and I got comments like "yeah, WebAssembly is really cool" or "Oh yeah, that's a good point'.

Again, I really get that this is tough (don't overpromise!) but we need more than just a quote in an interview.

Mike-E-angelo commented 6 years ago

Also please consider that things don't just happen because something has a lot of votes.

Clearly. πŸ˜‰ Keep in mind @dotMorten these votes are what MSFT directs and prescribes to us to do to help steer the direction and effort put into their new features. Clearly they are saying this to distract us as they really have no desire to listen the developers they claim to serve.

Like the .NET Core App Local under WPF ?

Did you take time to read the nearly 300 comments under that "announcement"? Many questions on why this is considered a big deal and many MORE questions asking why there isn't a legitimate .NET client story. There seems to be a serious disconnect between MSFT thinking what their customers want and what their developers are actually asking for.

XAML Islands?

Where is the value? You are regressing the Xaml model of WPF with a far less capable (and liked) one. Why would I want to replace the V8 in my Mustang with a ... battery, or something? πŸ˜‰

The XAML language alignments coming to XF3.1?

OK, decent announcement? Not earth-shattering and something worthy of a conference announcement, IMO. Xaml Standard is more of a conference announcement, and we see where that got us. Speaking of which, how do you have any faith that these language alignments will actually stick considering the "success" of this repo's announcement from last year?

??!? They do

Doesn't work in a web page. πŸ˜„

Mike-E-angelo commented 6 years ago

we need more than just a quote in an interview

Right @niels9001 and also do not forget the issue of trust we're now battling here, as this repo was a huge deal last year but has since turned into a... well, lie.

danielkornev commented 6 years ago

Microsoft simply uses an existing built-in web view in the corresponding mobile OS, not an Edge rendering engine (to the best of my knowledge). It uses Edge brand as a way to capture more of the typical user’s activities for its Microsoft Graph, to connect them with her/his Windows PC. That’s about it.

In other words, IMHO, Edge on iOS/Android has nothing to do with cross-platform XAML solution we beg it for.

Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows 10

From: Jack Bond notifications@github.com Sent: Monday, May 21, 2018 8:48:35 PM To: Microsoft/xaml-standard Cc: Daniel Kornev; Manual Subject: Re: [Microsoft/xaml-standard] Is this repo dead? (#230)

https://www.onmsft.com/news/microsoft-edge-beta-updated-on-ios-with-new-hub-design-developer-options-menu-and-more

Let me get this straight. Microsoft is spending resources on porting Edge, a rendering engine, and one of the worst browsers ever written, to another platform. This has probably been requested by a total of 3 developers scattered randomly throughout the universe. Meanwhile, a real cross platform XAML solution, the number one request put to Microsoft, and their response, "sorry, can you repeat that."

It really is incomprehensible.

β€” You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/xaml-standard/issues/230#issuecomment-390729999, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AFBSq52yah3aDlUphnM5hqFoAuqxDpBmks5t0v3zgaJpZM4SCk2M.

tpetrina commented 6 years ago

Maybe if we really wanted cross platform XAML, we would see a couple of those in the wild. Oh look, there is Avalonia with just 4k stars while Flutter has 24k. React Native has 64k. Sure, big companies are behind those two. But Ionic has 34k stars on GitHub and is not product from Google/Facebook/etc.

So, this tells me that the demand from Windows developers, of which there are plenty, simply isn't there. Don't conflate your demands for what the whole community demands.

Mike-E-angelo commented 6 years ago

Good points, @tpetrina ... I would say that at this point we as Windows developers are battling attrition along with the typical MSFT confusion and misdirection that has been pervasive since the turn of the decade. In fact, I would even say a good amount of those 24k/64k in those GitHub repos that you referenced are former MSFT/Windows-based developers that have given up on the incompetent, dysfunctional management strategy and approaches that we are dealing with now.

So, we that are left are either the stupid ones, the loyal ones, or the stupidly loyal ones. Take your pick. πŸ˜†

Also, when you say that there are "plenty" of Windows developers, I am interested in the source of your metrics. From my perspective, UWP/Windows did not even make a mention on StackOverflow's 2018 Survey.

Additionally, the Windows division is not exactly the most transparent, communative, and open source there out there, if you have not noticed. πŸ˜‰ The only significant open source effort that we have seen from them is the Windows Community Toolkit and, as you can see, it has less than half of the participation of Avalonia that you mentioned.

I am certainly welcome and am open to additional information that challenges and corrects my understanding here, of course.

tpetrina commented 6 years ago

When I say Windows I mean Win32/WPF, not UWP. So...millions of people writing/maintaing WinForms and WPF apps.

This topic is sad for me because I became a freelancer to do WP7 development only to see it fade into obscurity. And even if former windows developers starred such repositories only shows that people want Microsoft to do everything and they will just follow along. No innovation, even in the "cheap" way of liking a repository.

Had Avalonia gotten 100k stars, that would be a great signal. Why would Microsoft "lead" the development of this new XAML platform when people can't even be bothered enough to like the effort? It is obvious that it can be seen as spending, not investing.

danielkornev commented 6 years ago

To me, the biggest problem is a lack of backwards compatibility.

Can you move from WPF to Silverlight without a significant effort? No.

Same for WPF to WinRT XAML (Win8.x)? No.

Same for Silverlight to WinRT XAML? No.

WPF to UWP XAML? No.

Silverlight to UWP XAML? No.

I'm not even mentioning Xamarin Forms, and not mentioning Avalonia.

For some strange reason each new tech rethinks XAML again and again, effectively making investments in the hese tech meaningless.

At the same time, HTML has this backwards compatibility that Microsoft was for so long so proud of in case of Windows.

Of course it's hard to return trust to XAML-based platforms after all of these missteps. The reason all of that had happened is simple - no long term planning for XAML, and a desire to innovate without taking care of backwards compatibility. You can break it when you are a monopoly and everyone has to write for your platform. Windows is no longer a monopoly. It's position in tablets and phones is simply not there, and never was since 2007 and 2010.

As a former Microsoft employee, I'm really sad to see this picture.

XAML Standard was a great idea towards fixing the problem above, yet it is not a complete solution without at least WPF.

But investing in WPF is against the current goal of expanding UWP.

The funny thing is, Microsoft made a Longhorn mistake when it seemed to learn everything else from Longhorn port-mortem. Microsoft launched UWP (and WinRT XAML prior to it) without backporting it to the previous platforms. It was the original approach for WPF in Longhorn, and now we can see that WPF backporting was a good idea.

Get Outlook for Androidhttps://aka.ms/ghei36


From: Toni Petrina notifications@github.com Sent: Tuesday, May 22, 2018 11:02:11 AM To: Microsoft/xaml-standard Cc: Daniel Kornev; Manual Subject: Re: [Microsoft/xaml-standard] Is this repo dead? (#230)

When I say Windows I mean Win32/WPF, not UWP. So...millions of people writing/maintaing WinForms and WPF apps.

This topic is sad for me because I became a freelancer to do WP7 development only to see it fade into obscurity. And even if former windows developers starred such repositories only shows that people want Microsoft to do everything and they will just follow along. No innovation, even in the "cheap" way of liking a repository.

Had Avalonia gotten 100k stars, that would be a great signal. Why would Microsoft "lead" the development of this new XAML platform when people can't even be bothered enough to like the effort? It is obvious that it can be seen as spending, not investing.

β€” You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/xaml-standard/issues/230#issuecomment-390899384, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AFBSq0w4jFzIxjoa6-53M4851Em4FFRNks5t08YDgaJpZM4SCk2M.

tpetrina commented 6 years ago

Most people ported their apps to Angular anyway, there is no going back. Angular/React/other.js even offer a way of moving towards mobile while WPF doesn't push you to UWP or Xamarin or Web. So why bother...

And XAML...is it really that good? No one really liked it other than developers which up to that point ( around 2006) had to manually write width, height, left and top in WinForms so component model was fresh and offered an easy way of writing layouts. Plus bindings which were easier than what we had in WinForms.

But, years go by and even Angular dropped direct bindings in favour of unidirectional flow. Observables were a big thing coming to ES6/7 but it was dropped when everyone moved to Reactish way of writing your code. So two-way binding is no longer hot.

So what advantage does XAML have over HTML? Markup extensions? Which don't exist in Silverlight/WP/WinRT/UWP? Overly verbose binding which forced the UWP team to invent x:Bind? Inability to do cascade or conditional styling?

What does XAML offer you in 2018 and coming years?

danielkornev commented 6 years ago

XAML in WPF provides a rich and simple way to build a product using components. It is designed for apps, not content. You describe interface, not a web page.

Visual Editor gives you a simple way to see what you design, and you can either use it to design interface, or use XAML markup and see changes live. Unlike React/Redux way (which is brilliant in a way of how state is used), you can have one place to see your markup, and see its visual representation. I worked with React/Redux and with NReact (React for WPF/UWP) and I remember how painful it was to realize that I don't understand how my UI is built without running the whole thing. Individual components in React and the way you chain them might be awesome for very simple user interfaces, and those with super cool visual imagination, but for the rest of us who do complex things, thinking in React way slows down the whole work too much to make this approach reallt useful.

This is in no way a comprehensive explanation of the key differences, but enough to start a conversation.

Get Outlook for Androidhttps://aka.ms/ghei36


From: Toni Petrina notifications@github.com Sent: Tuesday, May 22, 2018 12:31:12 PM To: Microsoft/xaml-standard Cc: Daniel Kornev; Manual Subject: Re: [Microsoft/xaml-standard] Is this repo dead? (#230)

Most people ported their apps to Angular anyway, there is no going back. Angular/React/other.js even offer a way of moving towards mobile while WPF doesn't push you to UWP or Xamarin or Web. So why bother...

And XAML...is it really that good? No one really liked it other than developers which up to that point ( around 2006) had to manually write width, height, left and top in WinForms so component model was fresh and offered an easy way of writing layouts. Plus bindings which were easier than what we had in WinForms.

But, years go by and even Angular dropped direct bindings in favour of unidirectional flow. Observables were a big thing coming to ES6/7 but it was dropped when everyone moved to Reactish way of writing your code. So two-way binding is no longer hot.

So what advantage does XAML have over HTML? Markup extensions? Which don't exist in Silverlight/WP/WinRT/UWP? Overly verbose binding which forced the UWP team to invent x:Bind? Inability to do cascade or conditional styling?

What does XAML offer you in 2018 and coming years?

β€” You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/xaml-standard/issues/230#issuecomment-390925801, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AFBSqyMXJS1G67y6vvBWbXopbe2Wy9U6ks5t09rggaJpZM4SCk2M.

tpetrina commented 6 years ago

@danielkornev Then I guess you haven't been using Storybook or React Styleguidist which offers unprecedented ability to view your components in isolation and in different states. Previously I had different xml files initialising my viewmodels just to be able to design XAML component when a particular data is present.

And I am designing apps with React, not web pages. Even if there is no preview in React editor itself, dev tools for HTML/React offer ability to tweak styles in runtime and offer hot reload. I had to manually hard code the first page of my XAML apps to point to the one I am currently designing only to see how border thickness or image size affects my layout. Because if your icon is only shown in third list item on a particular state (item is sold) then it is near to impossible to preview that component other than in runtime.

Like I asked, what benefit you get from XAML that other frameworks don't already have? And React has in store lots of new, exciting features, what is the upcoming feature in XAML that we all want to get?

Mike-E-angelo commented 6 years ago

Well when you say framework, @tpetrina, none of the frameworks you have presented work with .NET. Well, they do, but not in a viable, cost-effective manner. πŸ˜‰ You essentially result in building two different codebases in two incompatible languages -- each with their defects and risks -- which is a very expensive proposition.

Like I asked, what benefit you get from XAML that other frameworks don't already have? And React has in store lots of new, exciting features, what is the upcoming feature in XAML that we all want to get?

These are excellent and salient questions. You make a great point of highlighting the fact that we are comparing features that are available now versus features that were available in 2006 (or 2009). I will try to answer from my perspective based on what Xaml was, and how we can potentially regain what it was aiming to achieve.

From my view, the vision of Xaml was to provide an interpreted language-agnostic data format that was easily consumed and modified by visual designer tooling, ala Blend and Visual Studio. Doing so not only reduced the costs in the development of applications, but also in the process workflow between designer and developer.

In the friction that you describe above, both Visual Studio and Blend by way of design-time components and markup extensions should have assisted in displaying your elements and scenes in way that resembled a runtime state before even having to launch an application. Now, that is in theory. Whether it actually arrived there, is another matter. πŸŽ‰

Keep in mind that Xaml is based on XML. It really could be JSON or YAML (and should be -- for those formats and more). At the end of the day, it is an expressive data dialect for serializing and describing a POCO graph and enabling it for powerful designer/tooling use. Keep also in mind (getting back to being interpreted language-agnostic) that .NET's primary pillar of power (🎢) was that it could host a multitude of languages, not just C#. That means by using the same interpreted language-agnostic data format, an F# developer could also use and consume the exact same file for their application, as well could a VB.NET developer, and an X.NET developer (where the language is not yet introduced and supported by .NET).

Now, this was the vision. I am not saying that is the reality. Far from it, unfortunately. WPF and Silverlight was closest to reaching this ideal. I and others have made attempts to encourage the UWP team to make their Xaml Model more like these other popular ones, but as you can see, the sheer amount of time to grasp the simplest of concepts has proven to be quite the challenge and test of patience.

So to sum up and reiterate, from my view Xaml's intended value was/is to reduce the costs of .NET application development, both in tooling and process. I concede this is more of pawing at the potential of the past rather than what we actually have now in the present. As you point out, a lot has happened in over a decade's worth of time. Even still, Xaml has had a remarkable run considering its time wasting on the altar by UWP's hand -- for whatever reason.

TonyHenrique commented 6 years ago

I simply would not use Angular in my projects. When writing Web apps, VueJS (+Axios web api client) is the way to go in my opinion.

I hope that XAML + Elmish + platform.uno + F# + Fable + Observable/Reactive replace all this soon. From the Web to the Native, a seamless solution.

LazyGepid commented 6 years ago

Not to mention that everything is supposed to be free and open source these days. Why would anyone - including Microsoft I guess - want to put in that kind of effort for free?

Mike-E-angelo commented 6 years ago

@LazyGepid for the same reason that MSFT is doing .NET Core for free:

The goal/idea is to create a fully comprehensive developer ecosystem solution that results in much cheaper application development, deployment, and overall application lifecycle TCO than what would be attained otherwise with a competing technology. The cheaper the development costs with higher yield of quality, the more developers will flock to it -- or should flock to it, at least. πŸ˜‰

Mike-E-angelo commented 6 years ago

You're selling yourself short, @jackbond ... the Windows Store is so desperate for developers to put apps into their existing, failing store that they are only taking 5% cut now.

Another "major announcement" from //build. πŸ˜‰

But you are spot on about Azure. It is where all the value is these days, which, BTW is the reason why ScottGu should be CEO (some additional Silveright memories here, too).

tpetrina commented 6 years ago

XAML brings nothing to the table for non-Windows developers when considering the current alternatives. And by the time it would roll out, all other platforms would be so far ahead with toolings in place and with an established ecosystem. In which XAML based framework has to play nice.

In the meanwhile, all existing platforms have immediate benefit from Azure.

birbilis commented 6 years ago

since it was mentioned above, didn't Silverlight 5 add custom markup extensions (at some level at least)? https://www.wintellect.com/using-custom-markup-extensions-in-silverlight-5/

danielkornev commented 6 years ago

So, we shall think of XAML as dead thing?

Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows 10


From: Toni Petrina notifications@github.com Sent: Tuesday, May 22, 2018 9:43:41 PM To: Microsoft/xaml-standard Cc: Daniel Kornev; Mention Subject: Re: [Microsoft/xaml-standard] Is this repo dead? (#230)

XAML brings nothing to the table for non-Windows developers when considering the current alternatives. And by the time it would roll out, all other platforms would be so far ahead with toolings in place and with an established ecosystem. In which XAML based framework has to play nice.

In the meanwhile, all existing platforms have immediate benefit from Azure.

β€” You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/xaml-standard/issues/230#issuecomment-391098733, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AFBSq07txHNlM9OtoLEfbDY-XG-RZY-Yks5t1FxdgaJpZM4SCk2M.

Mike-E-angelo commented 6 years ago

since it was mentioned above, didn't Silverlight 5 add custom markup extensions (at some level at least)?

It did, @birbilis. Silverlight 5 was truly an epic release... until it was killed shortly thereafter. πŸ˜‰ Despite that, I really consider Silverlight 5 one of MSFT's best products, ever. It's why I reference it in the wpdev vote, and why I am always comparing UWP to Silverlight, as Silverlight 5 had a very functional feature set that was much less than WPF's.

Mike-E-angelo commented 6 years ago

So, we shall think of XAML as dead thing?

Well from MSFT's perspective, that is obviously the case @danielkornev. It is possible that they can kick off an initiative to make something happen, but I do not think the political will (or competence) is there. To @tpetrina's point, one of the problems is that MSFT still suffers from stigma of forcing things down the market's throat. So, it would have to overcome this in addition to getting developers on board.

TBH I would think that this would be more successful if it was run by the community. But where would that start? Avalonia might be a good place. But I would like to see something that is more web-based.

Also, I am of the mindset that it is time for a fresh start altogether. As awesome as Xaml is, there's a lot of aspects that I would like to see changed. One is the format dependency that I alluded to earlier. Xaml should be able to be described in not just XML but JSON, YAML, and pretty much any format that is out there. This should be a matter of adding on a new format provider.

Then there are other things like how the market has evolved since 2006. And even .NET with .NET Core and the focus on performance. The one thing that UWP has right is its focus on performance (in all the wrong ways, of course). Xaml is a bit of a hog and could use to improve in this area.

But yeah, I'm a bit tempted to take the work that I've done with ExtendedXmlSerializer (which, btw, has markup extensions -- and only took a week to do πŸ˜†) and kind of, sort of do my own thing with it from scratch to see where it goes. πŸ˜‰

I would need help for sure, though. Especially with the visual designer aspect. I would really like to see a .NET equivalent of Weblfow based on the new vision. Big fan of that editor. πŸŽ‰

birbilis commented 6 years ago

btw, should check out this article from StackOverflow based on their analytics: https://stackoverflow.blog/2018/01/11/brutal-lifecycle-javascript-frameworks/

obviously being trendy is for the masses of students and other wanna-be devs, rest of us have to maintain and extend existing systems

e.g. I'm doing work on a Marionette/Backbone/Underscorejs/jQuery/DataTables/etc. + JavaEE + MyBatis one currently for a client - obviously they don't want to just scrap and rewrite their system just because Marionette/Backbone is not the top trend currently.

Plus when I make a new system a pick the best tech for the job and the fact for example that Silverlight had embedded and cross-platform video codecs from Microsoft, supported Smooth Streaming via the nice SMF framework (now with the cryptic name MMPPF), PivotViewer, DeepZoom, MEF (πŸ‘) etc. was the best choice at the time I created ClipFlair (http://clipflair.net). Plus it can still run even on WindowsXP that one can find at school labs (which was the main target of that research project) in less rich countries. And I'm still very happy with that choice since a big part of its codebase is sharing both XAML and nice and clean C# logic (not the average Javascript crap) via file linking in Silveright and WPF projects. And I wasn't happy with UWP when they decided to add using etc. and make my XAML not reusable. So I still hope for UWP to add backward compatibility features and love the Desktop Bridge progressing (hope they add easy wrapping of OOB [out of browser, yep Silverlight supported that too] XAPs in the future too). And wasn't happy with UWP forcing one to target only Windows 10. Would expect backporting it or making it portable (why not on OS-X too?) which would be even nicer. Nor was I happy with VS2017 dropping Silverlight project support (would be nice to see some extension add it via the Silverligh 5 SDK) forcing me to open my solutions that had WPF + Silverlight projects at VS2015.

birbilis commented 6 years ago

The Silverlight engine could also have been directly available in Edge, but they just included the Flash engine instead (those engines could have been downloadable extensions from the Store instead on demand / upon use of them in some page and user consent).

Btw, IE Tab on Chrome (http://www.ietab.net/) can run Silverlight, but Microsoft didn't think of adding an IE Tab in Edge, just hid it as much as they could in Win10 and put some menu option to open a page in IE11.

Even worse story of choices is the case with the WebBrowser ActiveX control that even Eclipse IDE uses. They use IE7 engine and one cannot change it unless they edit their webpages to add a special meta or edit the registry. Whereas it could just have a property to set the engine level that is wanted (cause if you have to modify your pages or change the registry to make it work you can't make some portable / non-installable application that shows modern web pages [cause one's own pages could link to external sites you have no access to that is]). And guess what Silverlight OOB (out of browser) mode was using for WebBrowser control (only available in OOB mode)? That same thing, forcing one to render hosted web content in IE7 engine with no way to change it without making a proxy or something to injecting meta in all pages navigated to. So bad choices in one thing spread into many others...

birbilis commented 6 years ago

And one last rant regarding the pain of making portable code+xaml:

When I was making my compatibility layer to ease reuse (via linking) of the same files in both my WPF and Silverlight projects, XmlnsDefinition was helpful but I think UWP had killed it (not sure if it came back later on at some point)

And what a pain was Silverlight's extensive usage of sealing: by not allowing me to subclass something to extend it (e.g. add some property/method that WPF had so that I can compile my code in both platforms) I had to resort to other ways that usually required changing the code. That code was either my libraries that I would write in Siverlight but wanted it to compile at WPF too or third party libraries that I had found in one or the other platform (or in both but with separate implementations) that I was making portable (diff/merging in reusable XAML+code files and enhancing the compatibility layer on the way by adding stuff to either Compatibility.Silverlight or Compatibility.WPF depending on which platform was missing something or had it differently, to avoid again changing much in the original code)

In fact even that Compatibility solution is using the same pattern of a single Source folder for all projects there (WPF/Silverlight/WP7/WP8)

tpetrina commented 6 years ago

@jackbond How do you code with such a broken logic? I say x is false and you then go and compare y and z? Is that exhaustive switch statement there?

@Mike-EEE If XAML is just a format and you can encode stuff in JSON, what then is the value of it? The component based system? Why not go for React's model which has clearly proven worth pursuing.

birbilis commented 6 years ago

@tpetrina the XML in the XAML could be though of yet another representation format for the XAML tree, e.g. see http://www.ammyui.com/

Mike-E-angelo commented 6 years ago

Format is simply one of the aspects to this, @tpetrina. I am certainly open to other models and approaches as well... especially before I actually start any work towards a new endeavor. πŸ˜‰ Do you have a resource from React that you find useful/valuable? I can definitely check it out and get familiar with it. πŸ‘

birbilis commented 6 years ago

@Mike-EEE see https://reactjs.org/ - more like operator overloading tricks to place markup inside your code. Why mix the two? To be able to statically compile your UI code and use the same tooling used for your programming language I guess. But then what happens when you want to have multiple programming languages? It just teases one to not separate concerns (UI tree and adaptive layout rules from UI logic). Guess with XamlDirect and some operator overloading you might be able to pull something similar in C#

Happypig375 commented 6 years ago

Well it would be faster if you use Xamarin Forms and run it on macOS and GTK# :wink:

tpetrina commented 6 years ago

@jackbond Try coding that in Angular/React...it is not as if that god awful Grid syntax can't be improved... @Mike-EEE Look up async rendering in React (upcoming feature) and suspense feature. Also, the greatest strength in vdom found in React is that I can actually change the UI for my child components on the fly. Think of it as macros or reflection before rendering.

You like binding? Look at this:

// Container is a component that has children component
// and one property: context
const Container = ({children, context}) =>
    React.Children.map(children, child => 
        // inject dependency here
        React.cloneElement(child, { context = context })
    )

// Now use it like this:
// Input will get context injected
<Container context={myViewModel}>
    <Input />
</Container>

You can rewrite UI, inject/replace properties, etc. Very simple model based on components and properties. Or you prefer reflection and xmlns:assembly=;namespace=; and {StaticResource ...}

tpetrina commented 6 years ago

@jackbond I have worked on almost all possible versions of XAML starting from WPF to UWP for billion dollar businesses like HP, DJI and others. It was the sole reason I left my job to become a freelancer. Hell, I even owned xaml.io domain and I loved XAML. Until it got annoying to write converters Items.Length > 0. So don't pretend you know me. Ask if you want to know, but don't presume.

And as for god awful syntax, it actually is. It is not that there is no bad alternative, sure that is. But it is not the best just because it is not the worst. Look at this following code: https://github.com/tpetrina/wp-helpers/blob/master/wp-helpers/UiHelpers/AttachedProperties/GridEx.cs Look at the date also if you think "I got no idea what XAML is". I fucking tried to write my own parser/MSBuild tasks and other shit to help my customers get better product. And I failed because XAML is not a platform. Unfortunately for me since I still love XAML. Why else would I write on this topic if I just can "move on"?

The reason you want XAML is because you are used to it. Well, I am also used to it and I extremely dislike not knowing how to write new .xaml file from memory. Do you know, by any chance? How to start file for user control? Or for dependency event?


<!-- what goes above??? -->
</UserControl```

And do you know the proper lifecycle of XAML controls per platform? Do you know how to get `xmlns:md=""` namespace correctly for debug data/instance? And how to make it work in WPF, which Blend libraries do you need? Do you know how much you need to write just to get your designer show you fake data? How long does it take you from figuring out you have invalid padding to actually commiting a fix into source control? And sure you like jumping from xaml to xaml.cs to viewmodel to model to data source file...that is sooo much fun...

Facts is what I have and opinions are built on them. XAML is old. What was invented in 2006 hasn't changed 12 years later...and for the worse. And no, XAML has as advanced layout system as you can get as long as you hide the fact that there is code involved in it. Sure, if you can code a carousel layout in XAML it means you are writing Measure/Arrange code. And you can do that in js as well so...there is that. And maybe HTML/CSS is slow, but while it took years for it to catch up with Grid/Flex layout, now it is Xamarin.Forms that is implementing Flexbox layout based on Yoga. And when will we get float layout in XAML? 

So yeah, what XAML has that React/Angular/Polymer folks are really jealous about...nothing is the answer since there has been little to no innovation in XAML world. FFS we still don't know how to layout WPF apps depending on the window/screen size!
birbilis commented 6 years ago

Btw, JFC/Swing had Layout Managers that you could plug in to a container, bit different concept than using specialized containers for the layout. Probably the specialized parent/container approach was more designer-friendly and got more traction at other UI frameworks

tpetrina commented 6 years ago
  1. I am not arguing that...I am arguing that JS+HTML is better than XAML. Why? Because every cool feature of XAML can be reimplemented on top of HTML/JS combo. It is not like is magic...it is just Measure/Arrange combo. I am also arguing that HTML has wider reach, bigger innovation base and brighter future. And I am also arguing that some things are easier in the former than the latter.

Two examples I provided are UserControls and ability to reshape UI using logic. Also, ability to not have to create converter for items.Length > 0.

  1. So...XAML is excellent because AutoLayout sucks? And you are arguing that "because writing particular thing in AutoLayout is hard therefore XAML brings this to iOS devs?" Because that is how logic works. I am arguing that bringing XAML on top of UI is not beneficial since Xamarin.Forms already does that and traction is not where we would love/want it to be. Had XAML been such an awesome technology, innovation would happen around it. Instead, we got https://componentkit.org which is React inspired technology.

And, as I said earlier, no one wants to write:

<UserControl xmlns="" xmlns:x="" x:Class="Namespace.Namespace.ClassName">
</UserControl>
public class Namespace.Namespace
{
  public class ClassName
  {
    public ClassName() => InitializeComponent();
  }
}

Btw, notice how I don't know how to fill out those namespaces, why should I? Shouldn't we start our XAML files with

<!XAML WPF>

And get all the benefits? Also, refactoring: move the user control to the external assembly...enjoy your world of pain.

Also, do you know how to write dependency properties from heart? Attached ones? Behaviors? If you know which NuGet to import? Do you know when x:Bind doesn't work, what is required to make it work? Can you write VisualStateManager/Animations without looking it up everytime?

And all of those things haven't changed in the past 12 years...

danielkornev commented 6 years ago

Notion of controls is native to XAML as a first class UI application framework.

Controls in HTML, and especially custom ones are an afterthought. Of course you can build anything from a web page, but just because you can build anything with stick and shit it doesn't mean you need to stick to these materials.

Get Outlook for Androidhttps://aka.ms/ghei36


From: Toni Petrina notifications@github.com Sent: Thursday, May 24, 2018 9:48:09 AM To: Microsoft/xaml-standard Cc: Daniel Kornev; Mention Subject: Re: [Microsoft/xaml-standard] Is this repo dead? (#230)

  1. I am not arguing that...I am arguing that JS+HTML is better than XAML. Why? Because every cool feature of XAML can be reimplemented on top of HTML/JS combo. It is not like is magic...it is just Measure/Arrange combo. I am also arguing that HTML has wider reach, bigger innovation base and brighter future. And I am also arguing that some things are easier in the former than the latter.

Two examples I provided are UserControls and ability to reshape UI using logic. Also, ability to not have to create converter for items.Length > 0.

  1. So...XAML is excellent because AutoLayout sucks? And you are arguing that "because writing particular thing in AutoLayout is hard therefore XAML brings this to iOS devs?" Because that is how logic works. I am arguing that bringing XAML on top of UI is not beneficial since Xamarin.Forms already does that and traction is not where we would love/want it to be. Had XAML been such an awesome technology, innovation would happen around it. Instead, we got https://componentkit.org which is React inspired technology.

And, as I said earlier, no one wants to write:

public class Namespace.Namespace { public class ClassName { public ClassName() => InitializeComponent(); } }```

Btw, notice how I don't know how to fill out those namespaces, why should I? Shouldn't we start our XAML files with


<!XAML WPF>

And get all the benefits?
Also, refactoring: move the user control to the external assembly...enjoy your world of pain.

Also, do you know how to write dependency properties from heart? Attached ones? Behaviors? If you know which NuGet to import? Do you know when x:Bind doesn't work, what is required to make it work? Can you write VisualStateManager/Animations without looking it up everytime?

And all of those things haven't changed in the past 12 years...

β€”
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<https://github.com/Microsoft/xaml-standard/issues/230#issuecomment-391607568>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AFBSq65dIQE3r-E2wfNCyUwqE_rGH2nWks5t1lepgaJpZM4SCk2M>.
tpetrina commented 6 years ago

:/ Calling other platforms "shit" won't make XAML better. It is 2018, we have the following dialects: WPF, UWP, Xamarin.Forms and Avalonia. The former two actually have a prototype to run in WebAssembly and are using HTML. What does it mean to run XAML on the Web or on iOS? Does it mean:

  1. Wrap existing controls like Xamarin.Forms does?
  2. Render everything in custom drawing layer like Flutter?

We have non-compatible dialects (missing features, clr-namespace: vs using:), different approaches (wrap/extend vs. redraw). What is the focus of XAML Standard?

  1. Ensuring all XAML files are portable?
  2. Same features (markup extensions, data triggers)?
  3. Same controls (StackLayout vs StackPanel, TextBox vs Edit vs Input)

How do we approach building cross platform version of XAML? Are we aware of what the problems are and are we unified in our approach to solving it? Because it is not clear and it is not trivial. Most issues on this forum deal with the control names/availability, are we even aligned around the simple thing like control lifecycle?

What do we get by saying "HTML sux" or "AutoLayout sux"? How does that make XAML better, cross platform?

tpetrina commented 6 years ago

Julia Liuson: https://www.theregister.co.uk/2018/05/10/microsoft_will_revive_windows_desktop_development_says_programming_chief/

Is there any chance of .NET Core getting a cross-platform GUI framework?

"That is a fascinating topic. If I go to a bunch of .NET guys and say, 'how many of you want to have the WPF running on iOS and Android?' you will have a lot of people raise their hands. But then the real question is that, let's say we could even make the XAML run, but XAML designed for desktop? It's very dense. Is that the right design? And experience? For your phone? I don't think so.

"We want to ask developers, what is your pain point? Give us examples of what you are trying to do. Then we'll have a better answer. Right now, we've heard a bit of noise. That's why we haven't done anything. We have to do more customer research."

See guys? Noise. Just wanting XAML everywhere is not good enough. And Microsoft doesn't want us running battleship grey datagrid based apps cross platform...

GeraudFabien commented 6 years ago

running battleship grey datagrid based apps

I don't want this anywhere. And that is not what XAML is about. Xaml can be personnalise with the user param. I want that for my cross plateform. Xaml can add complex animation easly. I want that for my cross plateform. ...

XAML is the best to design app. But designer know HTML. XAML designer are costly. More think about WASM. I want my app work in browser. XAML never going to work well in browser (I talk about Search Engine Optimisation).

My understanding of the build: microsoft sayed they don't know whether they port UWP cross plateform, they port xamarin.form on windows. Or the make the two converge by using a standart between the two.

Many year ago (before buying xamarin) some MS employee sayed that .Net core will not have desktop solution made by us until at least 2020. Many month ago some sayed that .Net core is for web and Mono is for desktop and when ASP.Net core will be correct they will focuse on desktop.

amartens181 commented 6 years ago

HTML Without CSS is useless. HTML without JS is useless. HTML with CSS and JS make a powerful UI. Want that element over there? we finally have a grid. It is not as performant as XAML but it's much easier to write and can be styled far better (also, live editing βœ”).

insinfo commented 6 years ago

In my opinion, I firmly believe that XAML was one of the most incredible things ever developed in the area of ​​graphic interface design.

Some key points for my statement are:

The second place where XAML shines is that it really takes advantage of the bindings. For example:

<Button IsEnabled = "{Binding IsBusy}">

In your vision model, you can go about your business and define IsBusy as true or false, and as it changes, the enabled state of the button automatically switches back and forth.

So, as a more complex example:

<ListBox ItemsSource = {Binding Options}>
Β <ListBox.ItemsTemplate>
Β Β <CheckBox Checked = "{Binding IsChecked}" Contents = "{Binding Name}" />
Β </ListBox.ItemsTemplate>
</ ListBox>

In this example, we are linking to a list (Options) and creating an item in a list box for each item. The cool thing here is that as we add or remove items to the list, the user interface automatically syncs with the status of our list. When we click the check box for each item, the underlying objects are updated automatically to match the user interface. With powerful tools like this, I've eliminated user interfaces in a fraction of the time it would take to bind all events in a WinForms application.

In general, all this means that you can write your user interface in a declarative format and this is a huge gain in productivity.

I think the biggest problem with XAML is that Microsoft isolated XAML on Windows and did not let or encourage XAML to flourish on other platforms, in addition to abandoning WPF which was the flagship demonstration of the XAML's social relevance this abandonment of the echo XAML system and in this terrible isolation, not to mention the lack of marketing, have made XAML be forgotten or even not known by most of the developers.

The shortcomings found in HTML (which was designed to be static, and which was meant to be a representation of a formal document similar to Word DOC) + HTML monopoly, JS, CSS + WEB growth have made developers create solutions , to my mind they seem to plug holes, a real fix to fix.

I currently work on developing large WEB projects with VueJS, Angular, and other solutions, as I do not have a XAML + C # solution available for WEB. For me Javascript + (HTML, CSS), React, Angular, VueJS among others are true slap hole, I do not want to underestimate(I don't want to say that these are rubbish) these as unfortunately there is no other option at the moment.

I still have faith and hope in XAML

tpetrina commented 6 years ago

@jackbond

Agree to disagree.

Well, the hard truth is that HTML/JS/CSS combo is both more popular and brings innovation to the table.

Silly argument. A developer with an easily bindable DataGrid is light years ahead in productivity.

DataGrid is not XAML, it is a control found in WPF/Silverlight. It is not in UWP/WP/XF/Avalonia. And it is not as if there are no datagrid implementations on the web including binding. Also, binding is no longer hot...

Created that converter once a decade ago, that's seriously a complaint? Gets copy/pasted at the beginning of a project into static resources. Oh what, you don't know how to do that?

I don't want to. And it is not that easy. First of all, you need to match namespace. Than you need to do the following:

<UserControl.Resources>
  <converters:MyCoolNamedConverter x:Key="MyCoolNamedConverter"
  xmlns:converters="My.Cool.Namespace" />
</UserControl.Resources>

  <!-- further down -->

<Control Value="{Binding MySourceValue, Converter={StaticResource MyCoolNamedConverter}}" />

Putting them in global namespace is annoying and non-performant. And it is verbose. And what when you want to do configurable converter like BooleanToObjectConverter or MyEnumToBorderColorConverter? Just because I know how it is done doesn't mean I like :D Because that logic leads you to justify anything and you will never innovate since..."you know how to do it now"

Laughable / pathetic attempt to twist my words. Try this sequence. Autolayout sucks and autolayout is the best MacOs/iOS developers have got. XAML is better, therefore it "brings something to the table for non-Windows developers."

So does React Native...You don't see them dreaming about XAML, right?

Right Click... New Page... Boom. Visual Studio did that for you. But let's go with your logic... Ahahahahaaha, you know about snippets right?

Well, I am not using VS all the time, I am using VS Code or Sublime or Atom...or Notepad ++.

Shouldn't I just be able to start HTML files with HTML?

It is <!DOCTYPE html> and you are done.

Experienced developers experience no such pain. Oh, and you're complaining about moving a user control to a separate assembly, when HTML doesn't even offer user controls?

Why are you constantly comparing pure HTML? This is dishonest because I was never arguing HTML is better than XAML. I am arguing that new frameworks like React brought new features and new innovation to the table while using a simpler model.

Also, without Resharper you don't have auto complete for your controls. React is younger framework and autoimport components works already in VS...It's been 12 years for WPF...

Also, look at innovation in that space. How much did it take to move from web to mobile? Look at Flux/Redux/unidirectional data flow. Look at GraphQL. Look at dev tools support for these frameworks. Look at hot module reload which always works. Look at Storybooks or style guides for components, wouldn't you want something like that for XAML based apps? And XAML offers an easy way to style all buttons in your app, but have this exception over here? Is there a built in way to style/layout XAML app depending on the window/screen size?

That is what I am saying when I say that XAML offers nothing: there are new players on the field with features and XAML is playing catch up...and poorly at that. No previewer, hot reload, easy to use inspect/tinker mode.

Nope, but I know how to copy paste. You've got every css/html/jquery/libraryofthemonth memorized? No platform is perfect, and perhaps there would be ways to address some of your nits (although some of them are just laughable.)

No one is talking about perfection. We are talking about productivity, quality and future innovation. XAML as it stands does not allow for productivity when you compare it to React. Quality is subjective. Future innovation is not on the side of XAML.

Instead of nitpickingly attacking my arguments and I am on your side since I do want XAML to succeed, maybe you should invest some effort in identifying the areas XAML needs help with.

Like I said earlier, talking smack about competition won't bring XAML anywhere.

danielkornev commented 6 years ago

What would be some good areas for XAML to innovate? W/o breaking backwards compatibility which is precisely what several XAML-based frameworks did over the last decade, ofc.

Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows 10


From: Toni Petrina notifications@github.com Sent: Friday, May 25, 2018 7:41:03 AM To: Microsoft/xaml-standard Cc: Daniel Kornev; Mention Subject: Re: [Microsoft/xaml-standard] Is this repo dead? (#230)

@jackbondhttps://github.com/jackbond

Agree to disagree.

Well, the hard truth is that HTML/JS/CSS combo is both more popular and brings innovation to the table.

Silly argument. A developer with an easily bindable DataGrid is light years ahead in productivity.

DataGrid is not XAML, it is a control found in WPF/Silverlight. It is not in UWP/WP/XF/Avalonia. And it is not as if there are no datagrid implementations on the web including binding. Also, binding is no longer hot...

Created that converter once a decade ago, that's seriously a complaint? Gets copy/pasted at the beginning of a project into static resources. Oh what, you don't know how to do that?

I don't want to. And it is not that easy. First of all, you need to match namespace. Than you need to do the following:

Putting them in global namespace is annoying and non-performant. And it is verbose. And what when you want to do configurable converter like BooleanToObjectConverter or MyEnumToBorderColorConverter? Just because I know how it is done doesn't mean I like :D Because that logic leads you to justify anything and you will never innovate since..."you know how to do it now" Laughable / pathetic attempt to twist my words. Try this sequence. Autolayout sucks and autolayout is the best MacOs/iOS developers have got. XAML is better, therefore it "brings something to the table for non-Windows developers." So does React Native...You don't see them dreaming about XAML, right? Right Click... New Page... Boom. Visual Studio did that for you. But let's go with your logic... Ahahahahaaha, you know about snippets right? Well, I am not using VS all the time, I am using VS Code or Sublime or Atom...or Notepad ++. Shouldn't I just be able to start HTML files with HTML? It is and you are done. Experienced developers experience no such pain. Oh, and you're complaining about moving a user control to a separate assembly, when HTML doesn't even offer user controls? Why are you constantly comparing pure HTML? This is dishonest because I was never arguing HTML is better than XAML. I am arguing that new frameworks like React brought new features and new innovation to the table while using a simpler model. Also, without Resharper you don't have auto complete for your controls. React is younger framework and autoimport components works already in VS...It's been 12 years for WPF... Also, look at innovation in that space. How much did it take to move from web to mobile? Look at Flux/Redux/unidirectional data flow. Look at GraphQL. Look at dev tools support for these frameworks. Look at hot module reload which always works. Look at Storybooks or style guides for components, wouldn't you want something like that for XAML based apps? And XAML offers an easy way to style all buttons in your app, but have this exception over here? Is there a built in way to style/layout XAML app depending on the window/screen size? That is what I am saying when I say that XAML offers nothing: there are new players on the field with features and XAML is playing catch up...and poorly at that. No previewer, hot reload, easy to use inspect/tinker mode. Nope, but I know how to copy paste. You've got every css/html/jquery/libraryofthemonth memorized? No platform is perfect, and perhaps there would be ways to address some of your nits (although some of them are just laughable.) No one is talking about perfection. We are talking about productivity, quality and future innovation. XAML as it stands does not allow for productivity when you compare it to React. Quality is subjective. Future innovation is not on the side of XAML. Instead of nitpickingly attacking my arguments and I am on your side since I do want XAML to succeed, maybe you should invest some effort in identifying the areas XAML needs help with. Like I said earlier, talking smack about competition won't bring XAML anywhere. β€” You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
tpetrina commented 6 years ago
  1. Unify feature set across dialects.
  2. Support for adaptive layouts.
  3. Open source it.

That is a good start.

danielkornev commented 6 years ago

Agree.

Get Outlook for Androidhttps://aka.ms/ghei36


From: Toni Petrina notifications@github.com Sent: Friday, May 25, 2018 2:34:39 PM To: Microsoft/xaml-standard Cc: Daniel Kornev; Mention Subject: Re: [Microsoft/xaml-standard] Is this repo dead? (#230)

  1. Unify feature set across dialects.
  2. Support for adaptive layouts.
  3. Open source it.

That is a good start.

β€” You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/xaml-standard/issues/230#issuecomment-392025281, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AFBSqyknwYdw2Y6dOS4NiWM_kIMgga7Aks5t1-xPgaJpZM4SCk2M.