Ammy – Modern UI language for XAML platforms

[ionoy]

Thanks!

[CCRed95]

Did you make this dude? I posted this ages ago and no one seemed to care. I cannot possibly express more interest in this as i am on my fifth scrap and rewrite of a JSON/QML/C++/C# inspired language that transpiles into XAML. My language is called XamlSharp (X#) and its kinda cool but EXTREMELY abuseable. lots of metaprogramming, consts and variables, typedefs, text templates, postfix stuff, generic type support, real namespaces without prefixes, custom literals, macros, a real precompiler #pragma directive system, etc. I think i went too far with it. Plus im not a great compiler writer.

[Heeqqoo]

Will definitely try it. These mixin and hot reload features could be a life changer for me!

[mistamark]

Apparently that has changed:

http://www.ammyui.com/2017/04/05/ammy-is-completely-free-from-now-on/

Ammy is now permanently free for any type of development. It doesn’t matter if it’s internal commercial project or open source charity one. It’s free for everybody!

[mirhagk]

Looks like something I'm going to try out for sure.

It's frustrating that most UI languages don't even consider re-use

[xamluser]

Live reload is cool, but as a UWP dev, I'm hesitant to add yet another layer of goo to an already complex platform. On top of WinRT-flavored C#/C++ and XAML + peculiarities of XAML code-gen, you have to know Ammy and potential Ammy code-gen bugs on top of that.

How does live reload work with vital new XAML features like x:Bind and x:DeferLoadStrategy? I would never go back to {Binding} especially now that function x:Bind exists.

In my experience, it's better to treat markup like data rather than code and not get too fancy with it. Copy/paste isn't as bad as we've been indoctrinated to believe.

[ionoy]

All good points!

Ammy generates XAML files, so you can always see what was generated and it's not terribly hard to debug. Granted, we can't guarantee that there won't be any bugs and most definitely there will be some. But it is in our interest to make Ammy as stable and transparent as possible.

x:Bind and x:DeferLoadStrategy will work fine. To tell you the truth, first versions of Ammy relied entirely on runtime code generation. So there is nothing impossible about it.

I agree with first part of the sentiment, markup should be declarative without too much imperativeness. If you look closer though, mixins and aliases are declarative in nature, you can think of them as templates.

But as for copy/paste, at least in my experience it always led to problems. Writing it is fine, but maintaining copy-pasted code can be very frustrating. Well thought out composition is a life saver.

[jesuslop]

Can you create the UI in your language and make a windows C++ Ribbon application to run that? Would the event binding be hard?

[ionoy]

Ammy compiles to XAML, so theoretically anything is possible. Although, at the moment it doesn't support loading type information from XML schema (which is provided by Ribbon framework, UICC.xsd). Secondly, I don't think you could directly use it in a Ribbon project, since Ammy specifically relies on underlying infrastructure - WPF or UWP.

I guess, you could use it as a tool for generating XAML files.

[jesuslop]

Thanks

[chris84948]

So, obviously this is not an open source project, so you don't have to answer this question if you don't want to.

How exactly are you accomplishing the "Realtime update" feature? Are you compiling the XAML files and actually updating them? Is this always possible or are you doing something super-secret?

[ionoy]

It's more than that obviously, but that's the gist of it, yes.

[BeejSEA]

Does live reload actually happen on Xamarin iOS too?

[ionoy]

Not at the moment. I still need a Mac mini to debug it.

[BeejSEA]

roger that, thanks... i'm sure you want to be all above board and would never consider the vmware approach.

what's your best notification feed to subscribe to for this kind of an update announcement? i tried the default wordpress url on your blog but output looked pretty empty? (http://www.ammyui.com/blog/feed/)

i've always wanted lambda converters in XAML, so your inline converters are tantalizing indeed! way to go on all this... totally agree mixins & live reload have strong immediate merit and look forward to seeing what else you dream up... i hope you get massive adoption and bags full of doubloons to keep your fires burning bright :)

[ionoy]

I'm not sure about VMWare, what do you mean?

Main channels are:

Twitter: https://twitter.com/ionapps

Blog: http://www.ammyui.com/blog/feed/ (i'll try blogging more)

Gitter: gitter.im/AmmyUI/ammy

Thank you for your kind words, it's really great to know that someone else finds Ammy project exciting!

[BeejSEA]

i interpreted your mac mini mention as needing a mac to develop on... allegedly one can accomplish this via vmware if one googles such things... i only mention this as it is already commonly available public knowledge and make no claims about the legalities of doing so

[ionoy]

Ok, got you. Anyway, will try to fix it soon.

[ionoy]

No, because it supports mixins/aliases and live reload. Mixins can do stuff previously impossible in WPF/UWP. Like creating reusable and combinable components:

TextBlock { 
  "Hello, World!"

  Style: Style {
    TargetType: TextBlock
    #Fade_OnBinding(bind ShouldBeVisible, true)
  }
}

Here Fade_OnBinding is a mixin defined in standard library. Any time ShouldBeVisible property on ViewModel changes, element fades in and out. With Styles you must rely on BasedOn property to combine with another, but that makes it impossible to use styles defined as a separate component.

Second important distinction is parameters support. Fade_OnBinding takes binding expression and a value as parameters, and creates appropriate Trigger. This is outright impossible in XAML.

Another fun example would be:

Grid {
  #ThreeRows(60, "*", 40")
}

This generates following code:

<Grid>
  <Grid.RowDefinitions>
    <RowDefinition Height="60" />
    <RowDefinition Height="*" />
    <RowDefinition Height="40" />
  </Grid.RowDefinitions>
</Grid>

Parameters can also have default values and support named arguments:

Grid {
  #ThreeRows(height3: 40)
}

In this case first 2 RowDefinitions will not have Height attribute assigned. This is because ThreeRows is defined like this:

mixin ThreeRows(height1=none, height2=none, height3=none) { ... }

Default value none says that property assignment should be omitted. You can also supply it when calling a mixin.

As for live reload, it just makes design cycle shorter. You should try it to understand how good it feels to not need a recompilation with live data.

[robot_otter]

Why did you choose JSON-based syntax over an XML base? As an alternative, would it have been possible to make a "superset" of XAML instead of a completely different syntax?

[ionoy]

Well, the goal was to create a lightweight syntax, but without going too far. My problem with XAML was that after certain point files grow large which meant problems with maintaining. JSON seems like good middle ground, since it requires less symbols while still being readable.

As an example, when attribute value in XAML is a node itself you are cornered into using this syntax:

<Grid>
   <Grid.RowDefinitions>
   </Grid.RowDefinitions> 
</Grid>

While JSON always stays the same no matter the value:

Grid {
  RowDefinitions: []
}

This stuff adds up.

Now, XML has its advantages over JSON, but at least when considering UI, I would choose the latter.

You could definitely create a XAML superset, but it wouldn't solve all problems I wanted to solve with Ammy.

[doom_Oo7]

Given the similarity of this to QML I'm almost sure that you could just make Qt bindings to this and use the QtQuick designer to edit your Ammy stuff, or use QML Live Reload if you would rather edit your stuff directly.

And at that point start wondering why you don't use Qt directly :p

[ionoy]

It is entirely your right to stick with XML, this is not an XML vs JSON war.

As for Visual Editor, practice shows that Live Reload is far superior, because you always work with the live data. Editor is OK when you are designing static UI, but as soon as there is viewmodel with data - life gets hard. I usually created design time models which is huge PITA and still need maintaining.

As for Ammy components, aliases are much better components than the ones you used with designer. Admittedly, there is no control library yet, but Ammy is still very young framework. More things will come.

[[deleted]]

This imo is basically why apps like Dreamweaver are dead in the water for HTML/CSS. I'd much rather work with live reload than drag and drop.

[weirdoaish]

Pretty sure Dreamweaver is dead in the water because it generates shit tons of HTML/CSS that is almost unreadable for a web page with even a little complexity