JavaScript alternative to XML for UX files

Feature Suggestions
1

Have you considered providing an alternative to the XML syntax of UX files? Something a bit more native and familiar to JavaScript developers — JavaScript — could be a good fit. Taking the example given in this video, as written in XML:

<App>
    <JavaScript>
        var text = "This is the text";

        function change() {
            text = "This is the new value";
            console.log(text);
        }

        module.exports = {
            text: text,
            change: change
        };    </JavaScript>

    <StackPanel Alignment="Center">
        <Text Value="{text}" />
        <Button Text="{Change value}" Clicked="{change}" />
    </StackPanel>
</App>

It might look something like this in JavaScript:

{
    script: function() {
        var text = "This is the text";

        module.exports = {
            text: text,
            change: function() {
                text = "This is the new value";
                console.log(text);
            }
        };
    },

    stackPanel: {
        alignment: "center",
        text: { value: "{text}" },
        button: {
            text: "Change value",
            clicked: "{change}"
        }
    }
}

It’s a bit weird with the intertwining of building an object graph reminiscing JSON and doing scripting, but having everything without angly brackets are nice, imho. It also makes it easier to support stuff like 0inline expressions (as requested here), since everything is just JavaScript anyway.

Having it be pure JavaScript also makes it more flexible, meaning it’s possible to envision something more terse, like this:

{
    script: function() {
        this.text = "This is the text";
    },

    stackPanel: {
        alignment: "center",
        text: "{text}",
        button: {
            text: "Change value",
            clicked: function() {
                this.text = "This is the new value";
                console.log(this.text);
            }
        }
    }
}

I understand the use of module.exports, but when you don’t do require anywhere, it doesn’t have to be a requirement, I think. Going in this direction makes it easier to think about things like ES6 exports and classes, meaning you can pretty much do exactly what Aurelia does and even adopt Template literals instead of the custom "{export}" syntax. Here’s the same example, Aurelia (or ES6) style:

export class App {
    text = 'This is the text';

    init() {
        return {
            stackPanel: {
                alignment: "center",
                text: ${this.text},
                button: {
                    text: "Change value",
                    clicked: this.change
                }
            }
        };
    }

    change() {
        this.text = "This is the new value";
        console.log(this.text);
    }
}

Entering into ES6 and ES7 land makes it possible to express the above in a million different ways, but I hope this gives an idea of what I’m thinking and how powerful this is going to become as ES6 and ES7 becomes more mainstream and incorporates features like async, Generators, etc.

Thoughts?

2

For some reason I’m doubting the fuse team will do this natively but perhaps when Fuse is out of beta someone in the community would make this possible somehow. Seems interesting though

3

Hi Asbjørn,

Thanks for the suggestions.

Our take on this is that “vanilla fuse” will remain XML.

However, it should be relatively straight forward to make community efforts that transpile between XML and other markups, such as your JS variant. A CLI tool that is capable of converting 1:1 in both directions would be cool. We are already doing something similar to support Angular 2.

However, the more flavors of Fuse exist, the more confusing will docs, forum threads, examples etc will become, so the value is not neccessarily a net positive.