Hacker News new | ask | show | jobs
by randomf1fan 3232 days ago
Question for you - I have created a few (okay, two) UWP apps, but the limited success of the store has made me look to using Xamarin. Only thing is, Xamarin's XAML is sufficiently different from UWP's XAML that I got disoriented and gave up.

If I want to target cross platform apps (including Linux and Mac), should I wait for Xamarin Forms 3 or will UWP eventually expand to cover Mac & Linux?

I'm only a hobby programmer so I don't want to waste hours learning something that will be a dead end.

Any insight you might have would be very useful! thanks

3 comments

Microsoft is working out a XAML standard to cover that case.

If you check BUILD 2017 sessions, there were a couple of talks about it.

Yeah, I did watch those, but haven't kept up with the latest news - not sure if they have announced any progress.
Will the new XAML version (the first one in 10+ years!) finally solve the problems of excessively verbose syntax, excessive XML namespace imports, excessive binding syntax options, and excessive-needing-to-search-stackoverflow-to-do-the-simple-things? :)

Any news on allowing JSON or another syntax as an alternative to XML-based XAML?

JSON is no where near expressive enough to replace XAML, it would look a lot worse than what we have right now.

The XML-like syntax of XAML isn't the problem, it separates object properties from child content well due to it's nature - the bigger issue is how difficult binding syntax is to grok by anyone who hasn't been working with it for quite some time.

> it separates object properties from child content well due to it's nature

This is only the case for trivial properties - there is also the expanded form of properties and that's where it muddies XAML very quickly.

For example, in a WPF project of mine I have a DataGrid with a Templated column parenting an ItemsControl with HyperLink children (it displays a list of Phone numbers for each Customer row).

This is my current XAML - I understand this is the minimum I need to achieve that effect: https://pastebin.com/cRjT2PG5

It could be simplified drastically in two ways, for example:

* Eliminate `<ItemsPanelTemplate>` and `<DataTemplate>` elements, they're implicit in 90% of cases and yet add another element and indent level without conveying significant information. They could be expressed as attributes of the `<ItemsControl.ItemsPanel>` and `<ItemsContorl.ItemTemplate>` property elements.

* Allow C# expressions and the composition of child-binding to be used in property bindings, not just `String.Format` strings. In my example I have to populate `<Hyperlink.Tooltip>` with a full `<TextBlock>` and `<MultiBinding>` element - why can't I just do `<HyperLink ToolTip="{Binding Kind} {Binding Number}">`? That alone would 10 lines of my 42 line example.

Another issue with XAML is that the creators of XAML failed to learn from HTML+CSS: while it succeeds at separating programming code from view-level concerns, it fails at separating presentation from content - it's like we're back in HTML3/4 days when <table> and <font> were all around and it was nearly impossible to tweak and standardise a UI. XAML does have <Style> and <Setter> elements but they're more used for setting Template properties - the end result is a horrid mess.

> * Eliminate `<ItemsPanelTemplate>` and `<DataTemplate>` elements, they're implicit in 90% of cases and yet add another element and indent level without conveying significant information. They could be expressed as attributes of the `<ItemsControl.ItemsPanel>` and `<ItemsContorl.ItemTemplate>` property elements.

XAML ultimately compiles to an object tree, if you're putting more than a reference, string, int, etc. into a property you need to construct it as a child element - if you want you are free to define the DataTemplate elsewhere in your XAML or in a resource dictionary and use the binding syntax.

> * Allow C# expressions and the composition of child-binding to be used in property bindings, not just `String.Format` strings. In my example I have to populate `<Hyperlink.Tooltip>` with a full `<TextBlock>` and `<MultiBinding>` element - why can't I just do `<HyperLink ToolTip="{Binding Kind} {Binding Number}">`? That alone would 10 lines of my 42 line example.

Use a converter? I know they're cumbersome to write, but that's what they exist for.

> Another issue with XAML is that the creators of XAML failed to learn from HTML+CSS: while it succeeds at separating programming code from view-level concerns, it fails at separating presentation from content - it's like we're back in HTML3/4 days when <table> and <font> were all around and it was nearly impossible to tweak and standardise a UI. XAML does have <Style> and <Setter> elements but they're more used for setting Template properties - the end result is a horrid mess.

Again, resource dictionaries, bind reusable styles to your elements. Syntax again sucks, `<TextBlock Style="{StaticResource AwesomeTextBlock}"/>`, and there IS the nagging issue that the styles are decided by the UI - but it's not too much worse than CSS classes.

Don't take any of this to mean your concerns aren't valid, but it's really not AS bad as you make it out to be. There's always room for improvement though!

I fail to see anything good about JSON.

Many of us do enjoy XML based tooling.

I don't mean the current verbose JSON standard (e.g. string keys, no comments) but something derived from it - because XML's capabilities are a subset of what JS/JSON is capable of, and because the same syntax for complex properties can be used for trivial properties it simplifies the syntax, for example:

<Foo Trivial="trivial"> <Foo.Complex> <Bar Bound="{Binding qux}" /> </Foo.Complex> </Foo>

Could be represented in strict JSON as:

{ "Type": "Foo", "Trivial": "trivial", "Complex": { "Type": "Bar", "Bound": { "Type": "Binding", "Path": "qux" } } }

A more succint JSON-derivative would allow for the "Type" property to be specified anonymously, object keys as identifiers, not strings, allow comments, and use object constructors directly instead of object literals:

{ Foo, Trivial: "trivial", Complex: { Bar, Bound: new Binding( "qux" ) }

}

> because XML's capabilities are a subset of what JS/JSON is capable of,

It is the other way around, JSON is a subset of XML features.

XML is a very expressive language/file format.

If you widen JSON to be strictly pure JavaScript object and value literals (e.g. allow comments, non-string keys, use of constructor calls, etc) then JSON is more expressive because each child of a JSON object itself is a JSON object - whereas an XML element has two distinct types of children: child-elements and child-attributes, and the expressiveness of attributes is considerably limited compared to child-elements. Granted, JSON provides no inherent way to denote an attribute compared to a child element, but remember that XML restricts you to a single complex child element collection, whereas with JSON you can have multiple properties containing children (unless you want to argue that named element children could correspond with named complex properties in JSON - then it's just a matter of syntax).
IF UWP will expand to do that it's not in any announced roadmap (and if it's being discussed internally I'm not privy to such things :) ) whereas Xamarin is doing it now(ish). You are right, the XAML is a bit different, the syntax is the same, but we use different class structures.
Thank you, I didn't know this wasn't actually announced.
Oh heck, don't waste your time waiting for MS. Qt works cross platform Windows, OSX and Linux right now.

It even does iOS and Android without any recajiggering. You can just compile your desktop app straight to your cell phone if you want.

It's amazing.

> It even does iOS and Android without any recajiggering

Not really, it is a pain to use versus Xamarin.

All you get is QML and the freedom to implement all your bindings to Android and iOS APIs.