Flutter: Consider JSX-like syntax inside dart code

cc @lukechurch

@cbazza Can you elaborate on why you want this? Maybe show an example of what it would look like compared to today?

Ok, so the "Basic widgets" example on 'https://flutter.io/widgets-intro/#basic-widgets' would look like the following:

import 'package:flutter/material.dart';

class MyAppBar extends StatelessWidget {
  MyAppBar({this.title});

  // Fields in a Widget subclass are always marked "final".

  final Widget title;

  @override
  Widget build(BuildContext context) {
    let style = {
        height: 56.0, // in logical pixels
        padding: const EdgeInsets.symmetric(horizontal: 8.0),
        decoration: <BoxDecoration color={Colors.blue[500]}/>,
    };

    return <Container style={style}>
      <Row>
        <IconButton
            icon={<Icon name={Icons.menu}/>}
            tooltip='Navigation menu'
            onPressed={null}
        />
        <Expanded>
           {title}
    </Expanded>  
        <IconButton
            icon={<Icon name={Icons.search}/>}
            tooltip='Search'
            onPressed={null}
        />
      </Row>
    </Container>;
  }
}

class MyScaffold extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    // Material is a conceptual piece of paper on which the UI appears.
    return <Material>
      <Column>
          <MyAppBar
             title={<Text 
               text='Example title'
               style={Theme.of(context).primaryTextTheme.title},
             />}
          />
          <Expanded>
            <Center>
              <Text text='Hello, world!'/>
            </Center>
          </Expanded>
      </Column>
    </Material>;
  }
}

void main() {
  runApp(<MaterialApp
    title='My app'
    home={<MyScaffold/>}
  />);
}

How about this syntax?:

import 'package:flutter/material.dart';

class MyAppBar extends StatelessWidget {
  MyAppBar({this.title});

  // Fields in a Widget subclass are always marked "final".

  final Widget title;

  @override
  Widget build(BuildContext context) {
    return Container(
      height: 56.0, // in logical pixels
      padding: EdgeInsets.symmetric(horizontal: 8.0),
      decoration: BoxDecoration(color: Colors.blue[500]),
      child: Row(
        children: <Widget>[
          IconButton(
            icon: Icon(Icons.menu),
            tooltip: 'Navigation menu',
            onPressed: null,
          ),
          Expanded(
            child: title,
          ),
          IconButton(
            icon: Icon(Icons.search),
            tooltip: 'Search',
            onPressed: null,
          ),
        ],
      ),
    );
  }
}

class MyScaffold extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    // Material is a conceptual piece of paper on which the UI appears.
    return Material(
      child: Column(
        children: <Widget>[
          MyAppBar(
            title: Text(
              'Example title',
              style: Theme.of(context).primaryTextTheme.title,
            ),
          ),
          Expanded(
            child: Center(
              child: Text('Hello, world!'),
            ),
          ),
        ],
      ),
    );
  }
}

void main() {
  runApp(MaterialApp(
    title: 'My app',
    home: MyScaffold(),
  ));
}

Huumm, a little improvement but not so good...
Here are the things that gets accomplished by using XML:
(1) No more 'child' & 'children' stuff
(2) easy for 3rd party tools to manipulate (parse, analyse and regenerate)
(3) notice that the switching between markup and programming is easily detected. I mean inside XML you have '{}' to delimit code and in code you have ' Also separate all the 'style' things from the main structure.
I know this is basically fully endorsing React's way but you are half way there anyways ;)

cc @kasperl

(1) No more 'child' & 'children' stuff

I don't really understand why that's desireable. "child" and "children" aren't special. Consider ListTile for example. How would you do that one? Why are "icon" in IconButton, or "home" in MaterialApp, something you want to give a name for, but not "child" in Expanded? All three are just arbitrary arguments that happen to take Widget objects. There's nothing magical about "child" vs "home".

(2) easy for 3rd party tools to manipulate (parse, analyse and regenerate)

You can parse, analyze, and regenerate Dart code. But I agree we should make that easier. Hopefully in the coming years the Dart team will provide better APIs for this.

(3) notice that the switching between markup and programming is easily detected.

Why is that desireable? I mean, why would any of this count as "programming"? It's all just expressions.

I mean inside XML you have '{}' to delimit code and in code you have '

I don't really understand the distinction.

Also separate all the 'style' things from the main structure.

You can do this today in Flutter if you really want to, just put the style in a variable like you did in the XML case.

I don't really understand why that's desireable. "child" and "children" aren't special. Consider ListTile for example. How would you do that one? Why are "icon" in IconButton, or "home" in MaterialApp, something you want to give a name for, but not "child" in Expanded? All three are just arbitrary arguments that happen to take Widget objects. There's nothing magical about "child" vs "home".

Less boilerplate, you don't need to say it because it is inherited in the structure.

Why is that desireable? I mean, why would any of this count as "programming"? It's all just expressions.

It's related to (2) because it makes life of toolmakers, specially GUI builders, much easier since they don't need to fully parse Dart; but it also makes reading the code easier.

I don't really understand the distinction.

The format of XML is very simple so when you see '{}' you know it is calculating an expression in dart. Same for the opposite, when reading dart code and you see ') you know that an object hierarchy is being created from XML markup.

Also in the final XML processor I would avoid passing objects to attributes of parents and instead create child tags as below:

this...
          <MyAppBar>
             <Title style={Theme.of(context).primaryTextTheme.title}>  
                 Example title
             </Title>
          </MyAppBar>

instead of this...
          <MyAppBar
             title={<Text 
               text='Example title'
               style={Theme.of(context).primaryTextTheme.title},
             />}
          />

Less boilerplate, you don't need to say it because it is inherited in the structure.

But why only for some of the properties? And how do you handle cases where there's two child slots, like ListItem? XML-ish syntax just doesn't seem to handle this very well.

Also I'm not really sure it's less boilerplate.

Compare:

   <Container style={style}>
      <Row>
        <IconButton
            icon={<Icon name={Icons.menu}/>}
            tooltip='Navigation menu'
            onPressed={null}
        />
        <Expanded> {title} </Expanded>  
      </Row>
    </Container>

   Container(style: style,
      child: Row(
        children: [
          IconButton(
            icon: Icon(Icons.menu),
            tooltip: 'Navigation menu',
            onPressed: null,
          ),
          Expanded(child: title),
        ],
      ),
    )

It's not at all clear to me that the XML-ish syntax is cleaner or less boilerplatey. There's lots more punctuation, and some duplication of content (e.g. in the close tags). And you had to add some names, so sure, you lose "child", but you gain "name" on Icon.

Also with XML how do you make it clear that Row can take zero, one, or more than one child, while Center has to have exactly one child? What would happen if someone did this?:

   <Center> <Test/> <Test/> </Center>

It's related to (2) because it makes life of toolmakers, specially GUI builders, much easier since they don't need to fully parse Dart;

They wouldn't need to fully parse Dart if we had a Dart parsing API either, though, right? I mean, you'd parse what you want to parse and leave the rest. Also I'm not sure it's actually easier to parse, since it's not actually XML; see below.

but it also makes reading the code easier.

I'm not at all convinced that the XMLy version here is easier to read. Once you've read a few build functions, you quickly get used to the nested constructor syntax.

The format of XML is very simple so when you see '{}' you know it is calculating an expression in dart.

It's not actually XML, though, right? It's some variant of XML. Are there well-defined parsing rules for it? For example, is this valid?

  <Test name={describe("}")}>

How does it know that the first "}" isn't the end of the attribute expression, without parsing Dart?

Same for the opposite, when reading dart code and you see ') you know that an object hierarchy is being created from XML markup.

You know this today when you see the new keyword too, right? Or indeed in the new-less markup proposal above when you see any capitalised word. Is this really a benefit of XML, or are you more familiar with XML than Dart?

Also in the final XML processor I would avoid passing objects to attributes of parents and instead create child tags as below:

I really don't understand what you're proposing here. It's not well-formed XML at all as far as I can tell. Can you elaborate on exactly what the syntax you are proposing is and how it works? For example, the "Text" constructor seems to have disappeared; how does the processor know that