Consider JSX-like as React Native

[JonathanSum]

For code that builds a UI has to be readable. I understand that Dart is kind of like a simple version of Java, but it is not really a programming language for building a UI. For example, it doesn't have a closing tag. As a result, It is very hard to build a picture in mind with this unreadable code.

Moreover, Flutter was inspired by React. How can Flutter doesn't have JSX but has this kind of unreadable code? I am very scared that Flutter is going to die very soon as the early days of AnglurJs.

I understand people who work in Google are smart, but we also have some people who are not really smart choose React instead of Dart, and this is one of the reasons why Dart was dead in the past.

[cbazza]

This has been asked for a long time:
#11609
Functional prototype developed:
https://spark-heroku-dsx.herokuapp.com/index.html
That shows the alternative and some benefits...

[cbazza]

This has been asked for a long time:
#11609
Functional prototype developed:
https://spark-heroku-dsx.herokuapp.com/index.html
That shows the alternative and some benefits...

[escamoteur]

I cannot agree. Especially using a IDE like Dart Code you get virtual closing tags which makes readin way easier. With Dart2 where you can omit new it will even get better.

Also I find it discourages you to build too big Widget trees without deconstruct it into smaller easier to maintain widget classes.

[escamoteur]

I cannot agree. Especially using a IDE like Dart Code you get virtual closing tags which makes readin way easier. With Dart2 where you can omit new it will even get better.

Also I find it discourages you to build too big Widget trees without deconstruct it into smaller easier to maintain widget classes.

[JonathanSum]

I use Android Studio. I don't even see a virtual closing tag. Even though we have a virtual closing tag, it is more complicated than HTML that everyone hates. Dart is just a programming language. People in Google don't understand the importance of simplification.

[JonathanSum]

I use Android Studio. I don't even see a virtual closing tag. Even though we have a virtual closing tag, it is more complicated than HTML that everyone hates. Dart is just a programming language. People in Google don't understand the importance of simplification.

[JonathanSum]

[JonathanSum]

[carl2013]

I don't think I would like a JSX-like syntax either but yeah, I use IntelliJ and something needs to be done with the tooling so that the UI code is easier to understand.

[carl2013]

I don't think I would like a JSX-like syntax either but yeah, I use IntelliJ and something needs to be done with the tooling so that the UI code is easier to understand.

[cbazza]

Also I find it discourages you to build too big Widget trees without deconstruct it into smaller easier to maintain widget classes.

I don't see how this is any different than with JSX... as the tree gets larger you can break into smaller sub-trees with both.

I don't think I would like a JSX-like syntax either but yeah, I use IntelliJ and something needs to be done with the tooling so that the UI code is easier to understand.

and it should be easy to read on all platforms and not only Intellij; I mean it should be easy to read on Bitbucket when reviewing code; and it should also be valid when using any editor; I mean with these 'comment annotations' what happens if someone using 'vi' types a different comment in there?

[cbazza]

Also I find it discourages you to build too big Widget trees without deconstruct it into smaller easier to maintain widget classes.

I don't see how this is any different than with JSX... as the tree gets larger you can break into smaller sub-trees with both.

I don't think I would like a JSX-like syntax either but yeah, I use IntelliJ and something needs to be done with the tooling so that the UI code is easier to understand.

and it should be easy to read on all platforms and not only Intellij; I mean it should be easy to read on Bitbucket when reviewing code; and it should also be valid when using any editor; I mean with these 'comment annotations' what happens if someone using 'vi' types a different comment in there?

[zoechi]

This is a dup of the locked down #11609
@sethladd ?

[zoechi]

This is a dup of the locked down #11609
@sethladd ?

[sethladd]

Apologies, you should be seeing the "virtual closing tags" in IntelliJ and Android Studio.

cc @devoncarew to verify which version turned that on, or if the user needs to opt-in ?

We thank you for your comments re: JSX-like syntax. We believe there is opportunity across the language, our tools, and plugins to make editing UI code easier.

This does dupe #11609 but I'd like for @devoncarew or @mit-mit to add a note about how to turn on "virtual closing tags", if possible.

Thanks!

[sethladd]

Apologies, you should be seeing the "virtual closing tags" in IntelliJ and Android Studio.

cc @devoncarew to verify which version turned that on, or if the user needs to opt-in ?

We thank you for your comments re: JSX-like syntax. We believe there is opportunity across the language, our tools, and plugins to make editing UI code easier.

This does dupe #11609 but I'd like for @devoncarew or @mit-mit to add a note about how to turn on "virtual closing tags", if possible.

Thanks!

[devoncarew]

@JonathanSum, the closing labels aren't available in Android Studio 3.0 unfortunately. You'll need at least IntelliJ 2017.3 or Android Studio 3.1. Android Studio 3.1 is currently in the release candidate stage, and we plan to release a flutter plugin with support for it tomorrow.

Irrespective of the conversation around a JSX like syntax, we do want to work towards making it easier to write UI code in Dart, in both IntelliJ / Android Studio and in VS Code. That's initially the closing label work, but also the recent Flutter Outline view. That shows the structure of your build() method in an outline view, and allows you to navigate the widgets and more easily see their parent / child relationships. That's currently available in IntelliJ - we do expect to be able to bring it to VS Code as well.

[devoncarew]

@JonathanSum, the closing labels aren't available in Android Studio 3.0 unfortunately. You'll need at least IntelliJ 2017.3 or Android Studio 3.1. Android Studio 3.1 is currently in the release candidate stage, and we plan to release a flutter plugin with support for it tomorrow.

Irrespective of the conversation around a JSX like syntax, we do want to work towards making it easier to write UI code in Dart, in both IntelliJ / Android Studio and in VS Code. That's initially the closing label work, but also the recent Flutter Outline view. That shows the structure of your build() method in an outline view, and allows you to navigate the widgets and more easily see their parent / child relationships. That's currently available in IntelliJ - we do expect to be able to bring it to VS Code as well.

[NathanaelA]

@zoechi - This might be a dup; but the other thread got heated, and locked. So their is no way to contribute to that conversation. I don't think you should close this thread as a dup just because you don't like people asking for a feature. This should probably be the new thread for responses for new people coming and requesting JSX support (or similar functionality).

---

@sethladd - Please do not lock this thread; I do think having community discuss pro's and con's on alternative layout methods is useful. I would have participated in #11609 had it not been locked.

---

I come from a NativeScript background. I have to say this is one area where I do feel NativeScript is considerably easier to use than Flutter. I can get a fairly complex screens working in less than 5 minutes and easily iterate the design quickly. Then add the code that runs the screen.

In NativeScript we actually have the following files:

• screen.js / screen.ts (.ts is transpiled into .js if you prefer typescript). This is the main logic for the screen that you are displaying.
• screen.css (or screen.android.css and/or screen.ios.css) which is a much more limited version of CSS but supports things like height, width, color, background, etc. Most the time a single css file is only needed, but occasionally if you are doing something weird you might separate your css for android and ios. It has full support for Classes, Elements, and id's So I can do TextArea.Login #Password and it actually will limit itself to just that specfic element chain.
• screen.xml (Again or screen.android.xml and/or screen.ios.xml) - This is the screen layout. You CAN code the layout in JS if you want (basically like flutter); but the XML is so so much easier. Example:

<Page onLoad="loadme">
    <ActionBar title="Blah"><NavigationButton click="back" title="Back"/></ActionBar>
    <StackLayout>
      <Label text="Hi" id="Hi" style="color: red"/>
     <Label text="{{name}}" class="name"></Label>
     <Button text="Click Me" tap="clicker"/>
    </StackLayout></Page>

The interesting thing is that ActionBar is a specific page only component (i.e. it is specific to only Page); so basically what happens is the XML parser See's page; creates a new Page Element; then creates a ActionBar component which it then runs a builderChild function on the Page component; the page component overrides the default builderChild and looks to see if the child is a ActionBar; if it is; then it internally assigns it to the proper variable; otherwise the rest is passed through parent/super which then assigns it to the "child" or "children" components automatically. The build system is incredibly versatile in that each component can use either the parent's builderchild function or override it to do extra items like support <Label>Hi</Label> and assign that to the Text value automatically. This makes layout incredibly easy to get up and running without any code.

Because most editors have good XML editing capability it is automatically colorized and with the proper xsd definition intellij (& vscode) does automatic checking and limited context support.

Now technically everything is actually a JavaScript component; so you can do all this manually (like what Flutter does); but I find the easy of laying out a screen is trivial in NativeScript. And you don't need the JS or CSS when you first start; then you can add the CSS (typically you don't hard code in the layout the css based properties; but you can if you want).

The nice thing about this; is it allows Web developers to jump right in with very little (if any) retraining. In fact; because of its flexible renderer and being JS based -- NativeScript actually support Angular and Vue -- so that you can actually share close to 95% of the code base between web, and your mobile app if you use Angular or Vue. Since it uses Native OS components like react native (not a webview like cordova); it really is a decent cross-platform system (that is imho better than React Native) . However, I can see where there are some strengths that Flutter has that makes it a good complimentary tool for some mobile development as their are some apps that NativeScript is worse at and some it is still the much better for and based on the responses to my issues from Ian; will stay the considerably better tool for in those areas.

[NathanaelA]

@zoechi - This might be a dup; but the other thread got heated, and locked. So their is no way to contribute to that conversation. I don't think you should close this thread as a dup just because you don't like people asking for a feature. This should probably be the new thread for responses for new people coming and requesting JSX support (or similar functionality).

---

@sethladd - Please do not lock this thread; I do think having community discuss pro's and con's on alternative layout methods is useful. I would have participated in #11609 had it not been locked.

---

I come from a NativeScript background. I have to say this is one area where I do feel NativeScript is considerably easier to use than Flutter. I can get a fairly complex screens working in less than 5 minutes and easily iterate the design quickly. Then add the code that runs the screen.

In NativeScript we actually have the following files:

• screen.js / screen.ts (.ts is transpiled into .js if you prefer typescript). This is the main logic for the screen that you are displaying.
• screen.css (or screen.android.css and/or screen.ios.css) which is a much more limited version of CSS but supports things like height, width, color, background, etc. Most the time a single css file is only needed, but occasionally if you are doing something weird you might separate your css for android and ios. It has full support for Classes, Elements, and id's So I can do TextArea.Login #Password and it actually will limit itself to just that specfic element chain.
• screen.xml (Again or screen.android.xml and/or screen.ios.xml) - This is the screen layout. You CAN code the layout in JS if you want (basically like flutter); but the XML is so so much easier. Example:

<Page onLoad="loadme">
    <ActionBar title="Blah"><NavigationButton click="back" title="Back"/></ActionBar>
    <StackLayout>
      <Label text="Hi" id="Hi" style="color: red"/>
     <Label text="{{name}}" class="name"></Label>
     <Button text="Click Me" tap="clicker"/>
    </StackLayout></Page>

The interesting thing is that ActionBar is a specific page only component (i.e. it is specific to only Page); so basically what happens is the XML parser See's page; creates a new Page Element; then creates a ActionBar component which it then runs a builderChild function on the Page component; the page component overrides the default builderChild and looks to see if the child is a ActionBar; if it is; then it internally assigns it to the proper variable; otherwise the rest is passed through parent/super which then assigns it to the "child" or "children" components automatically. The build system is incredibly versatile in that each component can use either the parent's builderchild function or override it to do extra items like support <Label>Hi</Label> and assign that to the Text value automatically. This makes layout incredibly easy to get up and running without any code.

Because most editors have good XML editing capability it is automatically colorized and with the proper xsd definition intellij (& vscode) does automatic checking and limited context support.

Now technically everything is actually a JavaScript component; so you can do all this manually (like what Flutter does); but I find the easy of laying out a screen is trivial in NativeScript. And you don't need the JS or CSS when you first start; then you can add the CSS (typically you don't hard code in the layout the css based properties; but you can if you want).

The nice thing about this; is it allows Web developers to jump right in with very little (if any) retraining. In fact; because of its flexible renderer and being JS based -- NativeScript actually support Angular and Vue -- so that you can actually share close to 95% of the code base between web, and your mobile app if you use Angular or Vue. Since it uses Native OS components like react native (not a webview like cordova); it really is a decent cross-platform system (that is imho better than React Native) . However, I can see where there are some strengths that Flutter has that makes it a good complimentary tool for some mobile development as their are some apps that NativeScript is worse at and some it is still the much better for and based on the responses to my issues from Ian; will stay the considerably better tool for in those areas.

[cbazza]

Better to open that locked thread and copy these comments there so we have a history of full discussions.

[cbazza]

Better to open that locked thread and copy these comments there so we have a history of full discussions.

[zoechi]

@JonathanSum it's not about whether anyone wants or doesn't wants the feature,
it's whether this is the place to have a heated discussion about it. I guess reddit or similar are better places.

[zoechi]

@JonathanSum it's not about whether anyone wants or doesn't wants the feature,
it's whether this is the place to have a heated discussion about it. I guess reddit or similar are better places.

[NathanaelA]

@cbazza - I don't disagree; but you have to be very careful in the future to not insinuate things about people. That just inflames the discussion, no matter how idiotic you believe they are being.

@zoechi - Actually I believe any discussion about a new feature should be here. History should be maintained so that when John Doe comes a month from now and searches about XYZ feature he can 👍 an existing feature and/or contribute to it.

[NathanaelA]

@cbazza - I don't disagree; but you have to be very careful in the future to not insinuate things about people. That just inflames the discussion, no matter how idiotic you believe they are being.

@zoechi - Actually I believe any discussion about a new feature should be here. History should be maintained so that when John Doe comes a month from now and searches about XYZ feature he can 👍 an existing feature and/or contribute to it.

[cbazza]

I don't think that thread is really locked for this long because of my comments. If what I said was so bad how come I can comment on everything else, like for example this thread?

The thread is locked because the Flutter team has no interest in doing this and just want people to stop talking about it.

[cbazza]

I don't think that thread is really locked for this long because of my comments. If what I said was so bad how come I can comment on everything else, like for example this thread?

The thread is locked because the Flutter team has no interest in doing this and just want people to stop talking about it.

[sethladd]

Let's please keep the discussion in this issue focused on use cases and examples for a JSX-like feature.

[sethladd]

Let's please keep the discussion in this issue focused on use cases and examples for a JSX-like feature.

[escamoteur]

Actually if NativeScript is that good, why bother with Flutter at all instead of trying to make Flutter NativeScript like.
I'm coming from an XML based Platform (Xamarin Forms) and thought in the beginning it might be more difficult to design in code but that's not the case.
In the contrary it makes is very easy to break down your design in separate classes which are easy to maintain.

[escamoteur]

Actually if NativeScript is that good, why bother with Flutter at all instead of trying to make Flutter NativeScript like.
I'm coming from an XML based Platform (Xamarin Forms) and thought in the beginning it might be more difficult to design in code but that's not the case.
In the contrary it makes is very easy to break down your design in separate classes which are easy to maintain.

[cbazza]

JSX is designing in code !!!

@sethladd

Let's please keep the discussion in this issue focused on use cases and examples for a JSX-like feature.

OK, Let's talk about my DSX design which can be viewed here:
https://spark-heroku-dsx.herokuapp.com/index.html

It provides a direct mapping to the current way widgets are built and yet provides a JSX like flavour that is very lightweight and familiar to React developers. Is there anything missing in this design? Can this design generate all possible widgets in the wild?

[cbazza]

JSX is designing in code !!!

@sethladd

Let's please keep the discussion in this issue focused on use cases and examples for a JSX-like feature.

OK, Let's talk about my DSX design which can be viewed here:
https://spark-heroku-dsx.herokuapp.com/index.html

It provides a direct mapping to the current way widgets are built and yet provides a JSX like flavour that is very lightweight and familiar to React developers. Is there anything missing in this design? Can this design generate all possible widgets in the wild?

[mrmcq2u]

Rule of thumb, if you feel one exclamation mark isnt enough you should probably step away from the keyboard and take a break.

[mrmcq2u]

Rule of thumb, if you feel one exclamation mark isnt enough you should probably step away from the keyboard and take a break.

[SirComputer1]

I'm a newcomer to Flutter, having only some experience with Android and Java, and I must say I find what Flutter offers far better than what is being proposed here. I tend to find that XML is ugly and unwieldy. It's so much more beautiful to have a singular closing character, rather than a sea of that makes my code 5x longer, a hatred of mine when editing Android XML, and just virtual closing tags which the vast majority of IDEs which people use support. This is incredibly useful when designing longer structures. The neat nesting XML provides just doesn't outweigh the rest of the disadvantages, in my opinion, especially when 'child:/children:' do almost as good of a job. Dart is incredibly clean, and it is a reason I like it so much. I would be incredibly disappointed if this was to be ruined.

I know that React does it like this, but last time I checked, this place says Flutter. Just because React does it doesn't mean we have to - you're not the only ones jumping ship to here! I very much agree with all the points @escamoteur made. I'm not seeing the point in adding yet another language that people need to handle when using Flutter. We're already using Dart to program most of it, we don't need a load of other things to master! Consistency and simplicity must be valued.

[SirComputer1]

I'm a newcomer to Flutter, having only some experience with Android and Java, and I must say I find what Flutter offers far better than what is being proposed here. I tend to find that XML is ugly and unwieldy. It's so much more beautiful to have a singular closing character, rather than a sea of that makes my code 5x longer, a hatred of mine when editing Android XML, and just virtual closing tags which the vast majority of IDEs which people use support. This is incredibly useful when designing longer structures. The neat nesting XML provides just doesn't outweigh the rest of the disadvantages, in my opinion, especially when 'child:/children:' do almost as good of a job. Dart is incredibly clean, and it is a reason I like it so much. I would be incredibly disappointed if this was to be ruined.

I know that React does it like this, but last time I checked, this place says Flutter. Just because React does it doesn't mean we have to - you're not the only ones jumping ship to here! I very much agree with all the points @escamoteur made. I'm not seeing the point in adding yet another language that people need to handle when using Flutter. We're already using Dart to program most of it, we don't need a load of other things to master! Consistency and simplicity must be valued.

[lukaspili]

Some remarks from your DSX vs generated Dart snippets:

1. Subjective: I don't see any great readability gains. Verbosity is similar - if not a tad longer. Dart IDE plugin provides auto closing tags, which mirrors declarative markup closing tags. If JSX is design in code, then I don't see how widgets in Dart is not.

2. Multiple properties in <vars>

@<vars>
var textStyle = {
    "textDirection": "TextDirection.ltr",
    "textAlign": "TextAlign.center",
    "overflow": "TextOverflow.ellipsis",
    "style": "new TextStyle(fontWeight: FontWeight.bold)"
};
</vars>@

Being able to define global styles mixing several properties is a nice idea.
However when I'm looking back at my modest flutter experience, I don't see where I would use these.

For Text it seems most of what I need to reuse is defined in TextStyle, rather than a mix of several properties. Maybe you can find another example than Text where that's not the case.

Looking at TextStyle, I find the current immutable + copy() to be great for reusing and composing in Dart:

class Style {
  static const TextStyle avenirNextMedium =
      const TextStyle(
         fontFamily: 'Avenir Next', 
         fontWeight: FontWeight.w500,
      );

  static TextStyle title =
      avenirNextMedium.copyWith(
        color: ColorKit.blue, 
        fontSize: 45.0,
      );
}

new Text(
  'Hello',
  style: Style.title,
),

new Text(
  'Hello2',
  style: Style.title.copyWith(
    color: ColorKit.red,
  ),
),

For reusable Container sharing a same style, I think that creating a custom stateless widget works better than an external defined <vars>. Most of the time, I want also a padding, an ink, a gesture listener or a shadow.

For any of those cases, I would need to compose Container with another widget: Material, Padding, Center etc. So if I have to create a custom reusable "container" widget anyway, I don't see much gain to have an external <vars> style that would just define the properties of a single widget in my reusable widgets hierarchy.

I don't see Flutter's "everything is a widget" work well with "multiple properties" styles.

3. Not highlighted in your current DSX examples: How would you code an interface with dynamic widgets? Meaning: how to show or not show some widgets depending on a condition.

When doing design in Dart it's easy and convenient to add or not a particular widget into children.
It's also very convenient to dynamically wrap a widget with another. It makes the build() function fluent and easy to understand.

    var children = <Widget>[];
    if(a) {
      children.add(wa);
    }
    
    var wb = Text();
    if(b) {
      wb = Padding(child: wb);
    }
    
    children.add(wb);

[lukaspili]

Some remarks from your DSX vs generated Dart snippets:

1. Subjective: I don't see any great readability gains. Verbosity is similar - if not a tad longer. Dart IDE plugin provides auto closing tags, which mirrors declarative markup closing tags. If JSX is design in code, then I don't see how widgets in Dart is not.

2. Multiple properties in <vars>

@<vars>
var textStyle = {
    "textDirection": "TextDirection.ltr",
    "textAlign": "TextAlign.center",
    "overflow": "TextOverflow.ellipsis",
    "style": "new TextStyle(fontWeight: FontWeight.bold)"
};
</vars>@

Being able to define global styles mixing several properties is a nice idea.
However when I'm looking back at my modest flutter experience, I don't see where I would use these.

For Text it seems most of what I need to reuse is defined in TextStyle, rather than a mix of several properties. Maybe you can find another example than Text where that's not the case.

Looking at TextStyle, I find the current immutable + copy() to be great for reusing and composing in Dart:

class Style {
  static const TextStyle avenirNextMedium =
      const TextStyle(
         fontFamily: 'Avenir Next', 
         fontWeight: FontWeight.w500,
      );

  static TextStyle title =
      avenirNextMedium.copyWith(
        color: ColorKit.blue, 
        fontSize: 45.0,
      );
}

new Text(
  'Hello',
  style: Style.title,
),

new Text(
  'Hello2',
  style: Style.title.copyWith(
    color: ColorKit.red,
  ),
),

For reusable Container sharing a same style, I think that creating a custom stateless widget works better than an external defined <vars>. Most of the time, I want also a padding, an ink, a gesture listener or a shadow.

For any of those cases, I would need to compose Container with another widget: Material, Padding, Center etc. So if I have to create a custom reusable "container" widget anyway, I don't see much gain to have an external <vars> style that would just define the properties of a single widget in my reusable widgets hierarchy.

I don't see Flutter's "everything is a widget" work well with "multiple properties" styles.

3. Not highlighted in your current DSX examples: How would you code an interface with dynamic widgets? Meaning: how to show or not show some widgets depending on a condition.

When doing design in Dart it's easy and convenient to add or not a particular widget into children.
It's also very convenient to dynamically wrap a widget with another. It makes the build() function fluent and easy to understand.

    var children = <Widget>[];
    if(a) {
      children.add(wa);
    }
    
    var wb = Text();
    if(b) {
      wb = Padding(child: wb);
    }
    
    children.add(wb);

[cbazza]

@SirComputer1 the DSX proposal is an addition, the current way doesn't change so if you don't like it, don't use it, continue as you are today.

The <var> thing was only done for the demo because I didn't want to parse full Dart. The final solution would not include <var> but would use any dart variable. Also the '@' was only done for the demo to make parsing easy. Final solution would not include it.

Don't forget that anything else on the file is your normal Dart code, so you can use that for everything else.

    var children = <Widget>[];
    if(a) {
      children.add(wa);
    }
    
    // You can mix and match both
    var wb = <Text/>;
    if(b) {
      wb = Padding(child: wb);
    }

    // or
    var wb = Text();
    if(b) {
      wb = <Padding> {wb} </Padding>;
    }
    
    children.add(wb);

    children.add(
      <Center>
          {sayHello == true ?
             <Text ['Hello, world!']/>
          :
             <Text ['Good bye']/>
          }
      </Center>
    );

Let's stop comparing DSX with the current way, one is not competing with the other. Some people will prefer JSX and this thread is for them. What I want to know is how can I improve DSX to handle things that it won't work for.

[cbazza]

@SirComputer1 the DSX proposal is an addition, the current way doesn't change so if you don't like it, don't use it, continue as you are today.

The <var> thing was only done for the demo because I didn't want to parse full Dart. The final solution would not include <var> but would use any dart variable. Also the '@' was only done for the demo to make parsing easy. Final solution would not include it.

Don't forget that anything else on the file is your normal Dart code, so you can use that for everything else.

    var children = <Widget>[];
    if(a) {
      children.add(wa);
    }
    
    // You can mix and match both
    var wb = <Text/>;
    if(b) {
      wb = Padding(child: wb);
    }

    // or
    var wb = Text();
    if(b) {
      wb = <Padding> {wb} </Padding>;
    }
    
    children.add(wb);

    children.add(
      <Center>
          {sayHello == true ?
             <Text ['Hello, world!']/>
          :
             <Text ['Good bye']/>
          }
      </Center>
    );

Let's stop comparing DSX with the current way, one is not competing with the other. Some people will prefer JSX and this thread is for them. What I want to know is how can I improve DSX to handle things that it won't work for.

[NathanaelA]

@escamoteur - I don't tend to use a hammer as a screw driver. I evaluate the different technologies and use the proper one for the proper use case. That doesn't mean their isn't things can could be changed for the better in each of the platforms. 😀

For example; third party plugins integration. NativeScript is truly king over every single other cross platform. Nothing else even remotely comes close to NativeScript; and third party integration. I have a client asking about using https://github.com/vipulasri/Timeline-View . Flutter virtually impossible; NativeScript give me a couple hours and it will work just like any other NS control probably even with fully working data binding. On the flip side flutter has some serious strengths where NS flags...

Use the proper tool for the job. 😀

---

I do tend to like the XML based screen layout; but I do understand why people don't. Adding the ability for XML based building does NOT mean eliminating the existing method; it is just complementary; choice. For those of you who didn't bother reading, I can do the same chain of calls in NS that we do in flutter; but using xml is a lot less typings and easier to me to read. Everybody has their preferences...

I have actually thought about adding a XML based renderer to Flutter as a POC; but I haven't had the spare time. I just wanted to contribute to the conversation and say I would like to see this move forward; but I actually do not expect the core team to work on it. I think NS XML format could be done as community projects where those of us who care (i.e. probably me 😀) would be willing to do the work on them. However, my biggest concern @sethladd -- is if I spend a lot of time on a patch; will it be rejected because someone on the core team absolutely opposes this ability. That is what I would like to nail down first before I spend any time on this...

[NathanaelA]

@escamoteur - I don't tend to use a hammer as a screw driver. I evaluate the different technologies and use the proper one for the proper use case. That doesn't mean their isn't things can could be changed for the better in each of the platforms. 😀

For example; third party plugins integration. NativeScript is truly king over every single other cross platform. Nothing else even remotely comes close to NativeScript; and third party integration. I have a client asking about using https://github.com/vipulasri/Timeline-View . Flutter virtually impossible; NativeScript give me a couple hours and it will work just like any other NS control probably even with fully working data binding. On the flip side flutter has some serious strengths where NS flags...

Use the proper tool for the job. 😀

---

I do tend to like the XML based screen layout; but I do understand why people don't. Adding the ability for XML based building does NOT mean eliminating the existing method; it is just complementary; choice. For those of you who didn't bother reading, I can do the same chain of calls in NS that we do in flutter; but using xml is a lot less typings and easier to me to read. Everybody has their preferences...

I have actually thought about adding a XML based renderer to Flutter as a POC; but I haven't had the spare time. I just wanted to contribute to the conversation and say I would like to see this move forward; but I actually do not expect the core team to work on it. I think NS XML format could be done as community projects where those of us who care (i.e. probably me 😀) would be willing to do the work on them. However, my biggest concern @sethladd -- is if I spend a lot of time on a patch; will it be rejected because someone on the core team absolutely opposes this ability. That is what I would like to nail down first before I spend any time on this...

[cbazza]

@NathanaelA Fantastic perspective !!!!!!! and look I used lots of exclaimation marks ;-) You literally nailed it on the head.

Yes, I can do DSX but I need a way to integrate it in the current Flutter build system so I need commitment from the current Flutter team before I move forward. IDE integration is virtually trivial on VS Code but not so much with Intellij (unless Google has access to Intellij JSX support).

[cbazza]

@NathanaelA Fantastic perspective !!!!!!! and look I used lots of exclaimation marks ;-) You literally nailed it on the head.

Yes, I can do DSX but I need a way to integrate it in the current Flutter build system so I need commitment from the current Flutter team before I move forward. IDE integration is virtually trivial on VS Code but not so much with Intellij (unless Google has access to Intellij JSX support).

[JonathanSum]

@zoech, No! I think this is an issue. I remember developing an android app with native Java and XML. We still use XML for UI language part. I think using Dart for logic and UI is kind of odd, and this problem is kind of obvious. furthermore, I just hope Google is going to add the UI idea of React into the flutter. The UI part of React is very powerful and concise.

[JonathanSum]

@zoech, No! I think this is an issue. I remember developing an android app with native Java and XML. We still use XML for UI language part. I think using Dart for logic and UI is kind of odd, and this problem is kind of obvious. furthermore, I just hope Google is going to add the UI idea of React into the flutter. The UI part of React is very powerful and concise.

[zoechi]

@JonathanSum I have seen many comments about this.
For me it still looks like something people want because they are reluctant to change their habits, not because it's a benefit for the platform.

[zoechi]

@JonathanSum I have seen many comments about this.
For me it still looks like something people want because they are reluctant to change their habits, not because it's a benefit for the platform.

[yuu2lee4]

Some people like jsx, Some people dont. Why dont support the two ways to implement UI. You can write jsx-like syntax,and it will finally be comeplied to flutter native syntax,why not support?

[yuu2lee4]

Some people like jsx, Some people dont. Why dont support the two ways to implement UI. You can write jsx-like syntax,and it will finally be comeplied to flutter native syntax,why not support?

[zoechi]

@yuu2lee4 #11609 (comment)

[zoechi]

@yuu2lee4 #11609 (comment)

[cbazza]

@zoechi

For me it still looks like something people want because they are reluctant to change their habits

This is a fair observation but wouldn't it be better for Flutter to be an enabler and remove as much friction as possible for people (outside Google) to adopt Flutter? This gate-keeping behavior is not winning hearts and minds of developers.

@yuu2lee4

Some people like jsx, Some people dont. Why dont support the two ways to implement UI. You can write jsx-like syntax,and it will finally be comeplied to flutter native syntax,why not support?

Excellent question. Given that I am doing all work on DSX, which is just like JSX, and @Hixie personally sent me email excited about the progress, I don't see why not support it, I don't see why not extend a hand and say 'What can I do to help you? What is blocking you to do this?'

[cbazza]

@zoechi

For me it still looks like something people want because they are reluctant to change their habits

This is a fair observation but wouldn't it be better for Flutter to be an enabler and remove as much friction as possible for people (outside Google) to adopt Flutter? This gate-keeping behavior is not winning hearts and minds of developers.

@yuu2lee4

Some people like jsx, Some people dont. Why dont support the two ways to implement UI. You can write jsx-like syntax,and it will finally be comeplied to flutter native syntax,why not support?

Excellent question. Given that I am doing all work on DSX, which is just like JSX, and @Hixie personally sent me email excited about the progress, I don't see why not support it, I don't see why not extend a hand and say 'What can I do to help you? What is blocking you to do this?'

[ghost]

@cbazza

Name calling? I didn't imply that these people were negative, only that they were different. I do like this thread but accusing me of arguing in bad faith is a bit ironic.

[ghost]

@cbazza

Name calling? I didn't imply that these people were negative, only that they were different. I do like this thread but accusing me of arguing in bad faith is a bit ironic.

[lrhn]

The word "fanboy" is generally considered a derogative, and was taken so in this context as well. I recommend avoiding words like that in discussions here.

Please everybody, be civil and constructive. We are discussing style here, something very subjective, so no matter how much everyone likes their own preference, it is unlikely to be inherently superior to everybody else's. Do list the advantages and disadvantages that you see with existing and proposed syntaxes, but remember that not everybody sees it the same way, and that's perfectly fine.

[lrhn]

The word "fanboy" is generally considered a derogative, and was taken so in this context as well. I recommend avoiding words like that in discussions here.

Please everybody, be civil and constructive. We are discussing style here, something very subjective, so no matter how much everyone likes their own preference, it is unlikely to be inherently superior to everybody else's. Do list the advantages and disadvantages that you see with existing and proposed syntaxes, but remember that not everybody sees it the same way, and that's perfectly fine.

[cbazza]

@hartmannj

Just some minor clarifications...

However, like mentioned before, Facebook had a reason to use JSX due to how JavaScript is written (e.g. no named constructor parameters) which is not the case with Dart.

Actually since ES2015/ES6, JS has had named parameters; you can just use 'de-structuring' for it :)
Here is an example:

// function declaration
function findUsersByRole ({
  role,
  withContactInfo, 
  includeInactive
}) {
  if (role === 'admin' && withContactInfo) {
  ...
  }
...
}


// usage
findUsersByRole({
  role: 'admin', 
  withContactInfo: true, 
  includeInactive: true
})

https://medium.freecodecamp.org/elegant-patterns-in-modern-javascript-roro-be01e7669cbd

Also the added Dart type-safety is nice indeed!

You get the same type-safety with DSX, which is indeed nice.

[cbazza]

@hartmannj

Just some minor clarifications...

However, like mentioned before, Facebook had a reason to use JSX due to how JavaScript is written (e.g. no named constructor parameters) which is not the case with Dart.

Actually since ES2015/ES6, JS has had named parameters; you can just use 'de-structuring' for it :)
Here is an example:

// function declaration
function findUsersByRole ({
  role,
  withContactInfo, 
  includeInactive
}) {
  if (role === 'admin' && withContactInfo) {
  ...
  }
...
}


// usage
findUsersByRole({
  role: 'admin', 
  withContactInfo: true, 
  includeInactive: true
})

https://medium.freecodecamp.org/elegant-patterns-in-modern-javascript-roro-be01e7669cbd

Also the added Dart type-safety is nice indeed!

You get the same type-safety with DSX, which is indeed nice.

[Hixie]

Since this is a duplicate of the earlier-reported #11609, I'm going to close this one in favour of that one.

[Hixie]

Since this is a duplicate of the earlier-reported #11609, I'm going to close this one in favour of that one.

[tonypee]

i really dont understand how people can vote against this- something which is so second nature to the way declarative code is written in the internet era..

<like><this /></like>

please be flexible enough to give flutter the chance to fly!

[tonypee]

i really dont understand how people can vote against this- something which is so second nature to the way declarative code is written in the internet era..

<like><this /></like>

please be flexible enough to give flutter the chance to fly!

[touseefbsb]

sadly this looks hopeless, every technology used markup to create UI in the past and even now and all of that developer experience is now being wasted by flutter.

[touseefbsb]

sadly this looks hopeless, every technology used markup to create UI in the past and even now and all of that developer experience is now being wasted by flutter.

[touseefbsb]

we dont need to do it like react native or html, just use simple xml

[touseefbsb]

we dont need to do it like react native or html, just use simple xml

[tonypee]

and maybeeee... xml embedded in dart! ;P

…

On Tue, 28 Aug 2018 at 21:29, Touseef ***@***.***> wrote: we dont need to do it like react native or html, just use simple *xml* — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#15922 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC8aNdVb_NV8c8JH4t36OS1OOvX6kY58ks5uVSmjgaJpZM4S6HPa> .

-- Tony Polinelli

[tonypee]

and maybeeee... xml embedded in dart! ;P

…

On Tue, 28 Aug 2018 at 21:29, Touseef ***@***.***> wrote: we dont need to do it like react native or html, just use simple *xml* — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#15922 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC8aNdVb_NV8c8JH4t36OS1OOvX6kY58ks5uVSmjgaJpZM4S6HPa> .

-- Tony Polinelli

[cbazza]

To me JSX-like functionality is the future and it will become a standard construct for declarative frameworks like React, Vue & Flutter.

[cbazza]

To me JSX-like functionality is the future and it will become a standard construct for declarative frameworks like React, Vue & Flutter.

[touseefbsb]

we dont need to embed xml in dart if we can just have 2 separate files for UI and logic then we can easily follow mvvm, mvc or any other desired pattren.

[touseefbsb]

we dont need to embed xml in dart if we can just have 2 separate files for UI and logic then we can easily follow mvvm, mvc or any other desired pattren.

[rrousselGit]

I've said it in the other thread but:

If you really want JSX, a good starter is using code generation. Go with a .html or .xml file and generate widgets from these.

Obviously, this is not a full-fledged JSX, but it's a start. Enough to see how the community will react to it.
If that syntax gain traction, maybe Flutter team will reconsider the topic.

Otherwise, I think it's just a loss of time. We can clearly see from here that it is a heavily debated topic.

[rrousselGit]

I've said it in the other thread but:

If you really want JSX, a good starter is using code generation. Go with a .html or .xml file and generate widgets from these.

Obviously, this is not a full-fledged JSX, but it's a start. Enough to see how the community will react to it.
If that syntax gain traction, maybe Flutter team will reconsider the topic.

Otherwise, I think it's just a loss of time. We can clearly see from here that it is a heavily debated topic.

[leossmith]

If flutter introduces and xml / jsx / call it what you want way of creating the UI I would start using it for production level apps in a heart beat!

[leossmith]

If flutter introduces and xml / jsx / call it what you want way of creating the UI I would start using it for production level apps in a heart beat!

[touseefbsb]

I agree @leossmith tht is the only thing being a hurdle for production level apps.

[touseefbsb]

I agree @leossmith tht is the only thing being a hurdle for production level apps.

[StokeMasterJack]

I personally would prefer to not add JSX or an external markup language. I prefer to keep everything in a single type-checked language. I feel a better approach is to continue improving the Dart language for the purpose of coding deeply nested declarative UI trees. They have already added some nice features in this area:

• Making the new and const keywords optional helps.
• Virtual closing tags in the IDE
• dartfmt helps also

[StokeMasterJack]

I personally would prefer to not add JSX or an external markup language. I prefer to keep everything in a single type-checked language. I feel a better approach is to continue improving the Dart language for the purpose of coding deeply nested declarative UI trees. They have already added some nice features in this area:

• Making the new and const keywords optional helps.
• Virtual closing tags in the IDE
• dartfmt helps also

[cbazza]

I prefer to keep everything in a single type-checked language

That's exactly what DSX/JSX does, the language is Dart for DSX, Javascript for JSX !!!

I feel a better approach is to continue improving the Dart language for the purpose of coding deeply nested declarative UI trees.

DSX is an improvement to the Dart language to better support deeply nested declarative trees. Just like JSX is for Javascript.

https://facebook.github.io/jsx/

The purpose of this specification is to define a concise and familiar syntax for defining tree structures with attributes.

[cbazza]

I prefer to keep everything in a single type-checked language

That's exactly what DSX/JSX does, the language is Dart for DSX, Javascript for JSX !!!

I feel a better approach is to continue improving the Dart language for the purpose of coding deeply nested declarative UI trees.

DSX is an improvement to the Dart language to better support deeply nested declarative trees. Just like JSX is for Javascript.

https://facebook.github.io/jsx/

The purpose of this specification is to define a concise and familiar syntax for defining tree structures with attributes.

[StokeMasterJack]

@cbazza You raise a good point. JSX is just and improvement to JavaScript.

So first let's clearly separate two things:

1. External DSL for defining UI. I am 100% against this. I have always believed this creates more problems than it solves. I wrote a blog post arguing this point. It got 58K views and surprisingly, almost no dissenting opinions: 80% of my coding is doing this (or why templates are dead)
2. Language improvements. To make it easier to construct and visualize deeply nested UI tree structures. On this we both agree there is room for improvement.

But we differ slightly on the approach. There are two reasons JSX makes more sense for React:

1. Data structure: On the web, JSX matches exactly the thing being generated (HTML DOM nodes). In flutter, we are generating Widget instances.
2. Familiarity: People are used to looking at html code. But the DSX proposal deviates from JSX/XML just enough to invalidate this point.

Below are the two things (I believe) that make XML good (and readable) for constructing UI trees. The question is, can these be achieved without introducing XML into the language:

1. XML has End tags. This is possible with or without an xml-ish syntax. Visual basic had it in the 90s (think End If). And other languages have it. The IDE does provide "virtual end tags" but this is kind of sketchy. I would prefer language support.
2. XML has special treatment of children. Attributes are distinct from children. But I would argue that this is a double edged sword. There are some cases where Dart is actually more clear and expressive than XML in this respect. For example, container widgets with differing child content models:

MyWidgetA(children: [ w1, w2 ])
MyWidgetB(child: w1)
MyWidgetC(top: w1, bottom: w2)

Dave Proposal for end tag problem

ButtonsView(
        onDeal: onDeal,
        onHit: onHit,
        onStay: onStay,
)ButtonsView

This would be easy to read by humans. And a parser would just replace the )ButtonsView with ). Also, the IDE could provide better checking and assistance with this scheme. I would make it required any time the open and close parens are not on the same line.

Dave Proposal for the nested children problem

Some languages (like kotlin) allow special treatment for args of type lambda. They allow you to put the lambda argument outside the parens. See Passing a lambda to the last parameter.

I propose something similar for Dart, but as arg of type List, not for lambdas. I propose special syntax for passing a arg of type list that is named "children":

//instead of this:
Foo(a: 1, b:10,c:44, children:[...])

//we do this:
Foo(a: 1, b:10,c:44)[

]

For a Constructors/functions that take a single child or 2 children (like top and bottom) leave it as it, no change.

> > I prefer to keep everything in a single type-checked language
> 
> That's exactly what DSX/JSX does, the language is Dart for DSX, Javascript for JSX !!!
> 
> > I feel a better approach is to continue improving the Dart language for the purpose of coding deeply nested declarative UI trees.
> 
> DSX is an improvement to the Dart language to better support deeply nested declarative trees. Just like JSX is for Javascript.
> 
> https://facebook.github.io/jsx/
> 
> > The purpose of this specification is to define a concise and familiar syntax for defining tree structures with attributes.

[StokeMasterJack]

@cbazza You raise a good point. JSX is just and improvement to JavaScript.

So first let's clearly separate two things:

1. External DSL for defining UI. I am 100% against this. I have always believed this creates more problems than it solves. I wrote a blog post arguing this point. It got 58K views and surprisingly, almost no dissenting opinions: 80% of my coding is doing this (or why templates are dead)
2. Language improvements. To make it easier to construct and visualize deeply nested UI tree structures. On this we both agree there is room for improvement.

But we differ slightly on the approach. There are two reasons JSX makes more sense for React:

1. Data structure: On the web, JSX matches exactly the thing being generated (HTML DOM nodes). In flutter, we are generating Widget instances.
2. Familiarity: People are used to looking at html code. But the DSX proposal deviates from JSX/XML just enough to invalidate this point.

Below are the two things (I believe) that make XML good (and readable) for constructing UI trees. The question is, can these be achieved without introducing XML into the language:

1. XML has End tags. This is possible with or without an xml-ish syntax. Visual basic had it in the 90s (think End If). And other languages have it. The IDE does provide "virtual end tags" but this is kind of sketchy. I would prefer language support.
2. XML has special treatment of children. Attributes are distinct from children. But I would argue that this is a double edged sword. There are some cases where Dart is actually more clear and expressive than XML in this respect. For example, container widgets with differing child content models:

MyWidgetA(children: [ w1, w2 ])
MyWidgetB(child: w1)
MyWidgetC(top: w1, bottom: w2)

Dave Proposal for end tag problem

ButtonsView(
        onDeal: onDeal,
        onHit: onHit,
        onStay: onStay,
)ButtonsView

This would be easy to read by humans. And a parser would just replace the )ButtonsView with ). Also, the IDE could provide better checking and assistance with this scheme. I would make it required any time the open and close parens are not on the same line.

Dave Proposal for the nested children problem

Some languages (like kotlin) allow special treatment for args of type lambda. They allow you to put the lambda argument outside the parens. See Passing a lambda to the last parameter.

I propose something similar for Dart, but as arg of type List, not for lambdas. I propose special syntax for passing a arg of type list that is named "children":

//instead of this:
Foo(a: 1, b:10,c:44, children:[...])

//we do this:
Foo(a: 1, b:10,c:44)[

]

For a Constructors/functions that take a single child or 2 children (like top and bottom) leave it as it, no change.

> > I prefer to keep everything in a single type-checked language
> 
> That's exactly what DSX/JSX does, the language is Dart for DSX, Javascript for JSX !!!
> 
> > I feel a better approach is to continue improving the Dart language for the purpose of coding deeply nested declarative UI trees.
> 
> DSX is an improvement to the Dart language to better support deeply nested declarative trees. Just like JSX is for Javascript.
> 
> https://facebook.github.io/jsx/
> 
> > The purpose of this specification is to define a concise and familiar syntax for defining tree structures with attributes.

[Rockvole]

@StokeMasterJack - your proposal for the end tag problem sounds the same as my proposal some time ago.
Idea: Auto generated closing tags

I think flutter needs something like this. I struggle with inserting new widgets inside a deep nest most days. I would use a JSX-like syntax just to get the end tag notation.

[Rockvole]

@StokeMasterJack - your proposal for the end tag problem sounds the same as my proposal some time ago.
Idea: Auto generated closing tags

I think flutter needs something like this. I struggle with inserting new widgets inside a deep nest most days. I would use a JSX-like syntax just to get the end tag notation.

[rrousselGit]

I don't want to have to write closing tags. It's a pain in JSX/html/xml. Especially when I want to refactor.
I think the virtual closing tags is pretty neat. It seems like a good compromise between both worlds.

If we really need some improvements here I think we can continue exploring on the IDE side. For example, vscode provides the following panel:

(Pretty sure Android Studio has the same)

Instead of stopping at the focused method, we could add constructors nesting too.
So that when hovering a specific class we'd get the following UI:

lib > main.dart > Foo > build > Container > Center > Text 

---

If it's about separating visually widgets from other kind of content, the IDE can do it too again.

We can have a different syntax hightlighting for widgets. Instead of the usual color used for classes, we can have a specific color for widget subclass

---

If it's about editability, then Flutter already provides all the tooling you need.

There are quite a few refactoring options, including:

• Wrap into new widget
• Remove widget
• Swap widget with child
• Swap widget with parent

With these in mind, you don't have to deal with parenthesis anymore.

---

In all honesty, I spent hours on a daily basis playing around Flutter for months. And I haven't felt any lack in readability or any disconfort in writing nested widgets.
While in comparison, I've used React for just as much and there are some stuff that frustrate me.

[rrousselGit]

I don't want to have to write closing tags. It's a pain in JSX/html/xml. Especially when I want to refactor.
I think the virtual closing tags is pretty neat. It seems like a good compromise between both worlds.

If we really need some improvements here I think we can continue exploring on the IDE side. For example, vscode provides the following panel:

(Pretty sure Android Studio has the same)

Instead of stopping at the focused method, we could add constructors nesting too.
So that when hovering a specific class we'd get the following UI:

lib > main.dart > Foo > build > Container > Center > Text 

---

If it's about separating visually widgets from other kind of content, the IDE can do it too again.

We can have a different syntax hightlighting for widgets. Instead of the usual color used for classes, we can have a specific color for widget subclass

---

If it's about editability, then Flutter already provides all the tooling you need.

There are quite a few refactoring options, including:

• Wrap into new widget
• Remove widget
• Swap widget with child
• Swap widget with parent

With these in mind, you don't have to deal with parenthesis anymore.

---

In all honesty, I spent hours on a daily basis playing around Flutter for months. And I haven't felt any lack in readability or any disconfort in writing nested widgets.
While in comparison, I've used React for just as much and there are some stuff that frustrate me.

[Rockvole]

@rrousselGit - those refactoring options you have sound useful. I don't see them on Android Studio 3.2.
I thought Android Studio would provide the best features for Flutter development.

[Rockvole]

@rrousselGit - those refactoring options you have sound useful. I don't see them on Android Studio 3.2.
I thought Android Studio would provide the best features for Flutter development.

[pulyaevskiy]

@Rockvole

Here is a screenshot from Android Studio:

Activated as a quick-fix Option+Enter (macOS).
I use these all the time, super helpful.

On the topic: it seems that Flutter team is exploring options for "UI as code" and we might get more improvements on this front sooner or later. Though ideas of @StokeMasterJack sound interesting.

[pulyaevskiy]

@Rockvole

Here is a screenshot from Android Studio:

Activated as a quick-fix Option+Enter (macOS).
I use these all the time, super helpful.

On the topic: it seems that Flutter team is exploring options for "UI as code" and we might get more improvements on this front sooner or later. Though ideas of @StokeMasterJack sound interesting.

[StokeMasterJack]

@Rockvole Great minds think alike!

[StokeMasterJack]

@Rockvole Great minds think alike!

[cbazza]

@StokeMasterJack

Nice reply !!!

There are two reasons JSX makes more sense for React:

1. Data structure: On the web, JSX matches exactly the thing being generated (HTML DOM nodes). In flutter, we are generating Widget instances.

The power of JSX is not on generating HTML/DOM nodes, it is in managing component hierarchies; React Native doesn't have HTML/DOM nodes right?

2. Familiarity: People are used to looking at html code. But the DSX proposal deviates from JSX/XML just enough to invalidate this point.

Just like above, it is not about HTML code, it is about a syntax that becomes clearly separate from the imperative constructs of the host language and screams declarative markup for building tree hierarchies.

I am not a fan of your proposal or Kotlin's because it looks like a hack done to avoid doing a proper design. Instead of designing a DSL that looks distinct, now I have to look at the code and try to figure out what it does; The syntax looks ambiguous. There are benefits for separating imperative and declarative constructs; 3rd party tools can easily locate XML markup inside code for example.

@Rockvole

I would use a JSX-like syntax just to get the end tag notation

Good to know ;)

@rrousselGit

I don't want to have to write closing tags.

You don't have to; WebStorm for example auto generates the closing tag and it even renames the open or closing tags as you edit the other. Really great editor functionality that others should follow (looking at you 'VS Code').

In all honesty, I spent hours on a daily basis playing around Flutter for months. And I haven't felt any lack in readability or any disconfort in writing nested widgets

I hope you can appreciate that your experience does not reflect everybody else's experience. With the tooling, writing is not as painful as reading the code. Go to github to read other people's code and you will notice that reading is a pain, the code is too verbose and long with nested structures. It looks like when promise-chains were used before async/await showed a better way. Also it feels like declarative techniques are less important than imperative ones; I mean why isn't there declarative vector graphics constructs? instead I have to use imperative calls to Skia for vector graphics drawing for example.

[cbazza]

@StokeMasterJack

Nice reply !!!

There are two reasons JSX makes more sense for React:

1. Data structure: On the web, JSX matches exactly the thing being generated (HTML DOM nodes). In flutter, we are generating Widget instances.

The power of JSX is not on generating HTML/DOM nodes, it is in managing component hierarchies; React Native doesn't have HTML/DOM nodes right?

2. Familiarity: People are used to looking at html code. But the DSX proposal deviates from JSX/XML just enough to invalidate this point.

Just like above, it is not about HTML code, it is about a syntax that becomes clearly separate from the imperative constructs of the host language and screams declarative markup for building tree hierarchies.

I am not a fan of your proposal or Kotlin's because it looks like a hack done to avoid doing a proper design. Instead of designing a DSL that looks distinct, now I have to look at the code and try to figure out what it does; The syntax looks ambiguous. There are benefits for separating imperative and declarative constructs; 3rd party tools can easily locate XML markup inside code for example.

@Rockvole

I would use a JSX-like syntax just to get the end tag notation

Good to know ;)

@rrousselGit

I don't want to have to write closing tags.

You don't have to; WebStorm for example auto generates the closing tag and it even renames the open or closing tags as you edit the other. Really great editor functionality that others should follow (looking at you 'VS Code').

In all honesty, I spent hours on a daily basis playing around Flutter for months. And I haven't felt any lack in readability or any disconfort in writing nested widgets

I hope you can appreciate that your experience does not reflect everybody else's experience. With the tooling, writing is not as painful as reading the code. Go to github to read other people's code and you will notice that reading is a pain, the code is too verbose and long with nested structures. It looks like when promise-chains were used before async/await showed a better way. Also it feels like declarative techniques are less important than imperative ones; I mean why isn't there declarative vector graphics constructs? instead I have to use imperative calls to Skia for vector graphics drawing for example.

[rrousselGit]

You don't have to; WebStorm for example auto generates

Vscode does that too. But that it still not perfect. Especially in the refactoring step when moving things around.
I think virtual tags provides a much smoother experience here.

I hope you can appreciate that your experience does not reflect everybody else's experience

For sure ! I just wanted to point out it may be more of an inexperience with the tooling then an actual lack 😄

Go to github to read other people's code and you will notice that reading is a pain, [...]

I don't quite see how your arguments here are related to the topic.
The problem you listed comes from bad practices, not bad syntax. It's not Flutter's fault if peoples want to make a 500 long widget tree.

[rrousselGit]

You don't have to; WebStorm for example auto generates

Vscode does that too. But that it still not perfect. Especially in the refactoring step when moving things around.
I think virtual tags provides a much smoother experience here.

I hope you can appreciate that your experience does not reflect everybody else's experience

For sure ! I just wanted to point out it may be more of an inexperience with the tooling then an actual lack 😄

Go to github to read other people's code and you will notice that reading is a pain, [...]

I don't quite see how your arguments here are related to the topic.
The problem you listed comes from bad practices, not bad syntax. It's not Flutter's fault if peoples want to make a 500 long widget tree.

[Rockvole]

@pulyaevskiy - thanks for the useful tip, on Linux the quick fix is Alt-Enter. Not a very easy feature to discover, I scoured the top menu options but it seems to be nowhere except by magical keypress :)

[Rockvole]

@pulyaevskiy - thanks for the useful tip, on Linux the quick fix is Alt-Enter. Not a very easy feature to discover, I scoured the top menu options but it seems to be nowhere except by magical keypress :)

[cbazza]

I think virtual tags provides a much smoother experience here.

Do these virtual tags show up on source file in github for example?

I don't quite see how your arguments here are related to the topic.

Basically the language could provide constructs to make things less verbose as I mentioned in the promises vs. async/await example. In Flutter Widget constructors are enormous and a lot of times they take a lot of parameters; with DSX you can use the spread operator for example to compress a 10 line constructor into a 1 line constructor and hence you can still have the complete tree hierarchy visible with less noise around it. This makes reading the code easier and allows clean separation of style from tree structure for example. I am not saying this can't be done by re-structuring your Dart code but it can be done without much effort or re-structuring things around. You don't need to fit to the limitations of the language, the language fits to you.

The problem you listed comes from bad practices, not bad syntax.

Before async/await, best practices were to use promises instead of crazy event callbacks everywhere. Using promises causes readability problems that were addressed by async/await. It is basically the same thing just syntactic sugar but async/await is clearer when reading someone else's code.

[cbazza]

I think virtual tags provides a much smoother experience here.

Do these virtual tags show up on source file in github for example?

I don't quite see how your arguments here are related to the topic.

Basically the language could provide constructs to make things less verbose as I mentioned in the promises vs. async/await example. In Flutter Widget constructors are enormous and a lot of times they take a lot of parameters; with DSX you can use the spread operator for example to compress a 10 line constructor into a 1 line constructor and hence you can still have the complete tree hierarchy visible with less noise around it. This makes reading the code easier and allows clean separation of style from tree structure for example. I am not saying this can't be done by re-structuring your Dart code but it can be done without much effort or re-structuring things around. You don't need to fit to the limitations of the language, the language fits to you.

The problem you listed comes from bad practices, not bad syntax.

Before async/await, best practices were to use promises instead of crazy event callbacks everywhere. Using promises causes readability problems that were addressed by async/await. It is basically the same thing just syntactic sugar but async/await is clearer when reading someone else's code.