cc @lukechurch

@cbazza ¿Puede explicar por qué quiere esto? ¿Quizás mostrar un ejemplo de cómo se vería en comparación con hoy?

Bien, entonces el ejemplo de "widgets básicos" en ' https://flutter.io/widgets-intro/#basic -widgets' se vería así:

import 'package:flutter/material.dart';

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

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

  final Widget title;

  <strong i="7">@override</strong>
  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 {
  <strong i="8">@override</strong>
  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/>}
  />);
}

¿Qué tal esta sintaxis?:

import 'package:flutter/material.dart';

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

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

  final Widget title;

  <strong i="6">@override</strong>
  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 {
  <strong i="7">@override</strong>
  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, un poco de mejora pero no tan bueno...
Estas son las cosas que se logran mediante el uso de XML:
(1) No más cosas de 'niño' y 'niños'
(2) fácil de manipular para herramientas de terceros (analizar, analizar y regenerar)
(3) observe que el cambio entre marcado y programación se detecta fácilmente. Me refiero a que dentro de XML tienes '{}' para delimitar el código y en el código tienes ' También separe todas las cosas de 'estilo' de la estructura principal.
Sé que esto es básicamente respaldar completamente el camino de React, pero de todos modos estás a mitad de camino;)

cc @kasperl

(1) No más cosas de 'niño' y 'niños'

Realmente no entiendo por qué eso es deseable. "niño" y "niños" no son especiales. Considere ListTile por ejemplo. ¿Cómo harías eso? ¿Por qué "icono" en IconButton, o "inicio" en MaterialApp, algo para lo que desea dar un nombre, pero no "niño" en Expandido? Los tres son solo argumentos arbitrarios que toman objetos Widget. No hay nada mágico en "niño" versus "hogar".

(2) fácil de manipular para herramientas de terceros (analizar, analizar y regenerar)

Puede analizar, analizar y regenerar código Dart. Pero estoy de acuerdo en que deberíamos hacerlo más fácil. Con suerte, en los próximos años, el equipo de Dart proporcionará mejores API para esto.

(3) observe que el cambio entre marcado y programación se detecta fácilmente.

¿Por qué es eso deseable? Quiero decir, ¿por qué nada de esto contaría como "programación"? Son solo expresiones.

Me refiero a que dentro de XML tienes '{}' para delimitar el código y en el código tienes '

Realmente no entiendo la distinción.

También separe todas las cosas de 'estilo' de la estructura principal.

Puede hacer esto hoy en Flutter si realmente lo desea, solo coloque el estilo en una variable como lo hizo en el caso de XML.

Realmente no entiendo por qué eso es deseable. "niño" y "niños" no son especiales. Considere ListTile por ejemplo. ¿Cómo harías eso? ¿Por qué "icono" en IconButton, o "inicio" en MaterialApp, algo para lo que desea dar un nombre, pero no "niño" en Expandido? Los tres son solo argumentos arbitrarios que toman objetos Widget. No hay nada mágico en "niño" versus "hogar".

Menos repetitivo, no es necesario decirlo porque se hereda en la estructura.

¿Por qué es eso deseable? Quiero decir, ¿por qué nada de esto contaría como "programación"? Son solo expresiones.

Está relacionado con (2) porque hace que la vida de los fabricantes de herramientas, especialmente los constructores de GUI, sea mucho más fácil, ya que no necesitan analizar completamente Dart; pero también facilita la lectura del código.

Realmente no entiendo la distinción.

El formato de XML es muy simple, así que cuando vea '{}' sabrá que está calculando una expresión en dart. Lo mismo para lo contrario, al leer código dart y ves ') sabe que se está creando una jerarquía de objetos a partir del marcado XML.

También en el procesador XML final, evitaría pasar objetos a los atributos de los padres y, en su lugar, crearía etiquetas secundarias como se muestra a continuación:

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},
             />}
          />

Menos repetitivo, no es necesario decirlo porque se hereda en la estructura.

Pero, ¿por qué solo para algunas de las propiedades? ¿Y cómo maneja los casos en los que hay dos espacios secundarios, como ListItem? La sintaxis XML-ish simplemente no parece manejar esto muy bien.

Además, no estoy realmente seguro de que sea menos repetitivo.

Comparar:

   <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),
        ],
      ),
    )

No está del todo claro para mí que la sintaxis XML-ish sea más limpia o menos repetitiva. Hay mucha más puntuación y cierta duplicación de contenido (por ejemplo, en las etiquetas de cierre). Y tuvo que agregar algunos nombres, así que seguro, pierde "niño", pero gana "nombre" en Icon.

También con XML, ¿cómo deja en claro que Row puede tomar cero, uno o más de un hijo, mientras que Center tiene que tener exactamente un hijo? ¿Qué pasaría si alguien hiciera esto?:

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

Está relacionado con (2) porque hace que la vida de los fabricantes de herramientas, especialmente los constructores de GUI, sea mucho más fácil, ya que no necesitan analizar completamente Dart;

Sin embargo, tampoco necesitarían analizar completamente Dart si tuviéramos una API de análisis de Dart, ¿verdad? Quiero decir, analizarías lo que quieres analizar y dejarías el resto. Además, no estoy seguro de que sea realmente más fácil de analizar, ya que en realidad no es XML; vea abajo.

pero también facilita la lectura del código.

No estoy del todo convencido de que la versión XMLy aquí sea más fácil de leer. Una vez que haya leído algunas funciones de compilación, se acostumbrará rápidamente a la sintaxis del constructor anidado.

El formato de XML es muy simple, así que cuando vea '{}' sabrá que está calculando una expresión en dart.

Sin embargo, en realidad no es XML, ¿verdad? Es una variante de XML. ¿Existen reglas de análisis bien definidas para ello? Por ejemplo, ¿es esto válido?

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

¿Cómo sabe que el primer "}" no es el final de la expresión del atributo, sin analizar Dart?

Lo mismo para lo contrario, al leer código dart y ves ') sabe que se está creando una jerarquía de objetos a partir del marcado XML.

Lo sabes hoy cuando también ves la palabra clave new , ¿verdad? O, de hecho, en la propuesta de marcado nuevo menos anterior cuando ve cualquier palabra en mayúscula. ¿Es esto realmente un beneficio de XML, o está más familiarizado con XML que con Dart?

También en el procesador XML final, evitaría pasar objetos a los atributos de los padres y, en su lugar, crearía etiquetas secundarias como se muestra a continuación:

Realmente no entiendo lo que estás proponiendo aquí. Por lo que puedo decir, no es un XML bien formado. ¿Puede explicar exactamente cuál es la sintaxis que propone y cómo funciona? Por ejemplo, el constructor "Texto" parece haber desaparecido; ¿Cómo sabe el procesador que

Mira, estás mezclando todo lo que digo y esta conversación no va a ninguna parte. En términos legales, está "intimidando al testigo".

Si está realmente interesado en saber por qué JSX está de moda, simplemente busque en Google el "tutorial de reacción" y observe que durante los últimos 2 años todos los artículos sobre React usan JSX. La forma original de crear jerarquías de componentes en React (que es equivalente a la forma actual en Flutter) nunca se vuelve a mencionar porque JSX se convirtió en el método preferido (mejor práctica).

https://facebook.github.io/react/tutorial/tutorial.html
https://facebook.github.io/react-native/docs/flatlist.html

Otra cosa interesante es que Typescript también ha adoptado JSX:
https://www.typescriptlang.org/docs/handbook/jsx.html

No entendiste que el análisis XML (con algún código adicional para omitir '{}' correctamente) es mucho más simple que analizar completamente un lenguaje de programación como Dart. Eso es un hecho. Está asumiendo que los creadores de herramientas usarán Dart en su desarrollo, no es el caso, lo más probable es que Intellij esté usando Kotlin y Java en sus IDE compatibles con Dart (son un caso especial porque se especializan en el análisis de lenguaje; todos los demás tendrán dificultades para analizar Dart de otro idioma).

Lo que me gusta de poner XML dentro de otro lenguaje es que proporciona una separación cognitiva entre los dos porque XML es muy distinto de los lenguajes de programación. Simplemente desplazándose por el archivo fuente, puede ver fácilmente qué es el código y qué es el marcado declarativo. No se puede lograr eso con el código dart que pretende ser un marcado.

Deje de criticar las cosas que no están completamente especificadas. Todas sus dudas han sido respondidas, solo aprenda más sobre cómo se manejó eso en JSX. Simplemente no tengo tiempo para esto aquí.

Mis disculpas si sueno a la defensiva o agresivo. Este es un tema que ha surgido varias veces, pero nunca antes había tenido a alguien dispuesto a discutir el caso, así que encontré esta conversación muy útil para enseñarme cuál era el razonamiento detrás de la solicitud. Por favor, no tome mi tono argumentativo como desdeñoso, estoy muy interesado en su aporte aquí.

Por favor, no sienta que tiene que responder. Estoy comentando aquí para que haya transparencia con respecto a los problemas que tendríamos que resolver antes de poder tomar una decisión o diseñar de una forma u otra. Esto es básicamente un diálogo socrático. Su participación es bienvenida pero ciertamente no debe sentir que es su responsabilidad defender su propuesta.

No tengo ninguna duda de que JSX está "caliente". En React, la sintaxis que no es JSX es mucho peor que la sintaxis alternativa propuesta en este número (la que se parece a nuestro código actual pero sin las palabras clave "nuevo" y "const"). Lo que estoy tratando de entender es si las mismas razones por las que JSX está "caliente" en React se aplican a Flutter.

Con respecto a TypeScript haciendo JSX, en 2012 participé en los esfuerzos para especificar E4H , e incluso antes de eso, estaba E4X . Ambos esfuerzos murieron. Por lo tanto, es importante para mí que entendamos qué es exactamente lo que le gusta a la gente de JSX frente a otras sintaxis.

Analizar XML no es fácil, analizar tipo-de-XML-pero-con-llaves-de alguna manera tampoco es fácil. Analizar una especie de XML pero con llaves de alguna manera que está incrustado en otro idioma es aún menos fácil. Sin embargo, lo fácil que es implementarlo probablemente no sea un gran problema porque se implementará una o dos veces y luego se reutilizará la biblioteca que lo hace. (He estado muy involucrado en escribir las especificaciones para analizar HTML y he estado involucrado en un trabajo similar para XML, y he implementado un analizador para Dart, así que tengo una idea bastante clara de lo difícil que es analizar los lenguajes de marcado frente a los lenguajes de programación en realidad es.)

Lo que me gusta de poner XML dentro de otro lenguaje es que proporciona una separación cognitiva entre los dos porque XML es muy distinto de los lenguajes de programación. Simplemente desplazándose por el archivo fuente, puede ver fácilmente qué es el código y qué es el marcado declarativo. No se puede lograr eso con el código dart que pretende ser un marcado.

Pero, ¿por qué es beneficioso poder hacer eso?

Es bastante obvio cuando se desplaza por las aplicaciones de Flutter donde se encuentran las funciones de compilación (son las expresiones anidadas gigantes). ¿Qué tiene el "marcado declarativo" que es importante separar del "código"?

Deje de criticar las cosas que no están completamente especificadas. Todas sus dudas han sido respondidas, solo aprenda más sobre cómo se manejó eso en JSX. Simplemente no tengo tiempo para esto aquí.

Por lo que puedo decir, JSX no maneja las cosas que estaba preguntando. Por ejemplo, React no tiene el concepto de espacios para niños. Lo más parecido que pude encontrar es algo que hacen volviendo a JS y luego a JSX dentro de eso, por lo que debería poder analizar tanto el lenguaje de programación como el lenguaje de marcado.

Lo que estoy tratando de entender es si las mismas razones por las que JSX está "caliente" en React se aplican a Flutter.

Sí, exactamente lo mismo se aplica aquí. La forma actual te parece bien porque es la única opción que tienes. Dale a la gente una segunda opción y sucederá lo mismo.

Si E4X murió o no es irrelevante porque nada vive para siempre. He usado mucho ActionScript con E4X y pensé que Adobe hizo un excelente trabajo allí. En cierto modo, Flutter es solo una versión más nueva de Adobe Flash con aplicaciones Flex.

(He estado muy involucrado en escribir las especificaciones para analizar HTML y he estado involucrado en un trabajo similar para XML, y he implementado un analizador para Dart, así que tengo una idea bastante clara de lo difícil que es analizar los lenguajes de marcado frente a los lenguajes de programación en realidad es.)

Genial para que sepas que analizar un lenguaje de marcado es trivial en comparación con analizar un lenguaje de programación imperativo.

Pero, ¿por qué es beneficioso poder hacer eso?

La legibilidad y la simplicidad del código, lo que a su vez genera muchos otros beneficios.

Es bastante obvio cuando se desplaza por las aplicaciones de Flutter donde se encuentran las funciones de compilación (son las expresiones anidadas gigantes). ¿Qué tiene el "marcado declarativo" que es importante separar del "código"?

En sus expresiones anidadas gigantes, ¿puede ver fácilmente la estructura? ¿Puede esta estructura ser fácilmente manipulada por otras herramientas como los constructores de GUI de manera intercambiable? Quiero decir, como Adobe Flex Builder solía hacer, arrastrar y soltar widgets, conectarlos en la interfaz de usuario y luego cambiar a la vista de código y simplemente editar lo que quieras y luego volver al modo gui y continuar manipulando los widgets. No puede hacer eso fácilmente cuando el programador ingresa a sus "expresiones anidadas gigantes" y escribe cualquier código de dardo válido que no sigue la estructura que espera el editor de GUI. Con una estructura XML fija eso no es un problema.

Por lo que puedo decir, JSX no maneja las cosas que estaba preguntando. Por ejemplo, React no tiene el concepto de tragamonedas para niños.

Lo maneja muy bien, simplemente no sabes cómo hacerlo. Entonces, en el futuro, simplemente ponga el ejemplo en cuestión aquí y le proporcionaré lo que creo que debería ser la versión JSX.

  new ListTile(
    title: new Text('CineArts at the Empire',
        style: new TextStyle(fontWeight: FontWeight.w500, fontSize: 20.0)),
    subtitle: new Text('85 W Portal Ave'),
    leading: new Icon(
      Icons.theaters,
      color: Colors.blue[500],
    ),
  ),

  <ListTile>
    <title> 
      <Text style={{fontWeight: FontWeight.w500, fontSize: 20.0}}>
         CineArts at the Empire
      </Text>
    </title>
    <subtitle>
      <Text>85 W Portal Ave</Text>
    </subtitle>
    <leading>
      <Icon data={Icons.theaters} color={Colors.blue[500]}/>
    </leading>
  </ListTile>,

Parece más largo que la versión de dardos, pero podría haber colocado todo en el mismo número de líneas. La cosa es que un IDE/Editor puede proporcionar '+' y '-' para expandir y colapsar estos nodos XML de todos modos.

Haz que Flutter parezca familiar para los desarrolladores de React y tendrás la oportunidad de atraer a un montón de nuevos usuarios a Flutter.

Si E4X murió o no es irrelevante porque nada vive para siempre.

Si murió no es el problema, es por qué murió. ¿Murió porque no brindó la solución que la gente quería? ¿Murió debido a problemas de implementación? ¿Murió por problemas de patentes? ¿Era demasiado pronto? ¿Demasiado tarde? Creo que es importante aprender lecciones de experiencias pasadas. ¿Por qué fallaron E4X y E4H donde JSX tuvo éxito?

Lo que encuentro interesante es que las personas que son nuevas en Flutter a menudo piden dos cosas: un lenguaje de marcado y GIF animados. Luego, tres meses después, todavía piden GIF animados, pero no un lenguaje de marcas. Puede ser que esto se deba a que el lenguaje de marcado no es realmente necesario una vez que estás acostumbrado a escribir métodos de compilación en Dart. Podría ser que todavía quieran un lenguaje de marcado pero han solucionado la omisión y, por lo tanto, no piensen en preguntar más. Vale la pena averiguar cuál, porque de lo contrario corremos el riesgo de gastar esfuerzo en algo que es la elección equivocada (en cualquier dirección).

En sus expresiones anidadas gigantes, ¿puede ver fácilmente la estructura?

Sí, al menos con la misma facilidad que con XML. Personalmente, encuentro que XML es muy detallado y ofusca la estructura. Pero creo que esto se trata más de lo que estás acostumbrado.

(También estamos experimentando con IDE que colocan comentarios virtuales de "etiqueta de cierre" para que pueda ver la estructura sin tener que escribirla).

Genial para que sepas que analizar un lenguaje de marcado es trivial en comparación con analizar un lenguaje de programación imperativo.

Mi experiencia es que declarativo vs imperativo no es la distinción que importa cuando se trata de determinar qué tan fácil es analizar un idioma. (Por ejemplo, HTML es "declarativo", pero puede estar entre los lenguajes más complicados de analizar con los que he tratado).

La legibilidad y la simplicidad del código, lo que a su vez genera muchos otros beneficios.

Si este es el beneficio principal, entonces es algo que podemos probar. Podríamos tomar una mezcla de ingenieros que están acostumbrados a escribir HTML, React, código de iOS, código de Android, Flutter, aplicaciones de línea de comandos, etc., y presentarles a cada uno de ellos varias sintaxis y pedirles que describan lo que piensan que es el la interfaz de usuario resultante se vería así. Entonces podemos medir qué sintaxis obtiene los mejores resultados. @InMatrix , ¿es esto algo que podríamos ver después de que termine el trabajo de animación, tal vez?

¿Puede esta estructura ser fácilmente manipulada por otras herramientas como los constructores de GUI de manera intercambiable?

Sí, al menos en principio. Debería ser relativamente sencillo convertir mecánicamente las expresiones de Dart a XML o JSON o cualquier otro lenguaje estructurado que se pueda usar. Es solo cuestión de convertir la sintaxis, la información real es la misma. Personalmente, no lo convertiría a una sintaxis diferente si estuviera creando un editor de GUI, simplemente lo analizaría en una estructura de datos en la memoria directamente desde Dart.

No puede hacer eso fácilmente cuando el programador ingresa a sus "expresiones anidadas gigantes" y escribe cualquier código de dardo válido que no sigue la estructura que espera el editor de GUI. Con una estructura XML fija eso no es un problema.

La cuestión es que puede poner exactamente el mismo "cualquier código dart válido" en la estructura XML como en la expresión Dart. Son literalmente mecánicamente intercambiables. Así que realmente no veo cómo el uso de XML ayuda con esto en particular. Por ejemplo, ¿cómo convertiría esto en XML?:

new ListView.builder(
  padding: new EdgeInsets.all(8.0),
  itemExtent: 20.0,
  itemBuilder: (BuildContext context, int index) {
    return new Text('entry $index');
  },
)

Lo maneja muy bien, simplemente no sabes cómo hacerlo.

Me refiero específicamente a JSX. Estoy de acuerdo en que su sintaxis propuesta sería una forma perfectamente válida de abordar el problema.

Trabajé en Flex SDK de Adobe, que combinaba marcado XML y ActionScript, durante los dos últimos años que existió el producto en Adobe. Entiendo el atractivo del marcado para definir UI, sin embargo, también puedo recordar algunos inconvenientes:

• Las imágenes de la aplicación Flex se pueden definir en términos de marcado y código. Tal como lo recuerdo, el código tendía a dominar en las grandes aplicaciones del mundo real. La legibilidad no es necesariamente un beneficio para las aplicaciones definidas como híbridos complejos de marcado y código.
• El IDE "Flex Builder" tenía que admitir aplicaciones definidas por marcado y código. Esto hizo que el IDE fuera difícil de construir y mantener. Los desarrolladores tendían a verlo como una herramienta de ActionScript.
• Evolucionar y mantener el "compilador" XML fue una carga importante que mantuvo ocupado a un equipo de ingenieros a tiempo completo. Mantener el compilador y el conjunto de herramientas en sintonía ralentizó la evolución del SDK general.

Han pasado años y ya no puedo recordar todos los detalles. Sin embargo, mi impresión general es que definir interfaces de usuario con una combinación de marcado y código es, en el mejor de los casos, una mezcla.

Si murió no es el problema, es por qué murió. ¿Murió porque no brindó la solución que la gente quería? ¿Murió debido a problemas de implementación? ¿Murió por problemas de patentes? ¿Era demasiado pronto? ¿Demasiado tarde? Creo que es importante aprender lecciones de experiencias pasadas. ¿Por qué fallaron E4X y E4H donde JSX tuvo éxito?

Murió porque E4X solo se implementó en ActionScript, que solo se usó dentro de Adobe Flash/Flex y Adobe eliminó el proyecto. En cambio, Adobe cambió de dirección hacia estándares abiertos donde no hay un único proveedor de origen con posibilidad de bloqueo e implosión del ecosistema.

Lo que encuentro interesante es que las personas que son nuevas en Flutter a menudo piden dos cosas: un lenguaje de marcado y GIF animados. Luego, tres meses después, todavía piden GIF animados, pero no un lenguaje de marcado. Puede ser que esto se deba a que el lenguaje de marcado no es realmente necesario una vez que estás acostumbrado a escribir métodos de compilación en Dart. Podría ser que todavía quieran un lenguaje de marcado pero han solucionado la omisión y, por lo tanto, no piensen en preguntar más. Vale la pena averiguar cuál, porque de lo contrario corremos el riesgo de gastar esfuerzo en algo que es la elección equivocada (en cualquier dirección).

Bueno, si te pido 2 cosas y no haces ninguna en 3 meses y hay una alternativa a la primera, también te pediría solo lo que es totalmente imposible dada tu capacidad de respuesta y rendimiento de entrega anterior.

(También estamos experimentando con IDE que colocan comentarios virtuales de "etiqueta de cierre" para que pueda ver la estructura sin tener que escribirla).

Algo gracioso, pero es como si poner la etiqueta de cierre XML que mencionaste antes fuera demasiado detallada.

Si este es el beneficio principal, entonces es algo que podemos probar. Podríamos tomar una mezcla de ingenieros que están acostumbrados a escribir HTML, React, código de iOS, código de Android, Flutter, aplicaciones de línea de comandos, etc., y presentarles a cada uno de ellos varias sintaxis y pedirles que describan lo que piensan que es el la interfaz de usuario resultante se vería así. Entonces podemos medir qué sintaxis obtiene los mejores resultados. @InMatrix , ¿es esto algo que podríamos ver después de que termine el trabajo de animación, tal vez?

Seguro que puedes hacer eso, adelante, estoy seguro de que descubrirás que "Una vez que haces React (con JSX), simplemente no regresas". Encuesta a los desarrolladores experimentados de React y pregúntales si creen que JSX es malo y si nunca debería haberse hecho. Muestra tu camino y pregúntales si quieren reemplazar JSX con lo que tienes. Antes de hacer eso, cierre las puertas y asegure el lugar porque estos desarrolladores simplemente agarrarán sus cosas y correrán hacia la salida más cercana.

La cuestión es que puede poner exactamente el mismo "cualquier código dart válido" en la estructura XML como en la expresión Dart.

Claro, pero para los constructores de GUI, eso es solo un bloque de bytes que no es necesario tocar y se puede omitir fácilmente. Haciendo que la intercambiabilidad de diseño/código sea prácticamente posible en lugar de en principio.

new ListView.builder(
  padding: new EdgeInsets.all(8.0),
  itemExtent: 20.0,
  itemBuilder: (BuildContext context, int index) {
    return new Text('entry $index');
  },
)

let style = {
  padding: new EdgeInsets.all(8.0),
  itemExtent: 20.0
};

<ListView.builder style={style}>
  {(context, index) => <Text> entry {index} </Text>}
</ListView.builder>

Utilicé Adobe Flex Builder extensivamente...

Los desarrolladores tendían a verlo como una herramienta de ActionScript.

Sí, pero a menudo cambié de la vista de diseño a la vista de código y viceversa.
Al iniciar una pantalla, iría a la vista de diseño y usaría arrastrar/soltar para diseñar widgets y generar la primera pantalla estática. Luego agregaría código y algunos datos estáticos para completar la pantalla para poder mostrarle a la gente algo en ejecución que parecía material listo para producción. La productividad fue increíble. A medida que avanzaba el desarrollo, conecté el front-end con el back-end y la cantidad de código ActionScript creció y sí, dominó el código en general, pero incluso cerca del momento del lanzamiento, a menudo usaba la vista de diseño para ajustar la interfaz de usuario sin tener que profundizar en código.

Sin embargo, mi impresión general es que definir interfaces de usuario con una combinación de marcado y código es, en el mejor de los casos, una mezcla.

No en el mundo de hoy. Los lenguajes imperativos han evolucionado en la filosofía de Python y son excelentes para el desarrollo. Las técnicas declarativas con marcado incrustado (XML) se generalizaron con la llegada de React; y JSON se convirtió en el formato de datos basado en texto preferido.

E4X solo se implementó en ActionScript

E4X era un estándar ECMA. Mozilla lo envió por un tiempo, pero luego lo eliminó (un movimiento muy inusual para un proveedor de navegador). Otros proveedores de navegadores nunca quisieron implementarlo. (Sin embargo, implementaron otras características nuevas de ECMA). Con E4H, los proveedores de navegadores nunca estuvieron interesados ​​en implementarlo (aunque, de nuevo, implementaron muchas otras cosas que ayudé a inventar).

Bueno, si te pido 2 cosas y no haces ninguna en 3 meses y hay una alternativa a la primera, también te pediría solo lo que es totalmente imposible dada tu capacidad de respuesta y rendimiento de entrega anterior.

Esa es una teoría posible. Sin embargo, la gente tiende a pedir muchas otras cosas además, y muchas de las cosas que piden se implementan, y también hay soluciones para los GIF animados, por lo que no estoy seguro de que esto explique completamente la situación.

Algo gracioso, pero es como si poner la etiqueta de cierre XML que mencionaste antes fuera demasiado detallada.

Por supuesto. Esta es una característica opcional del IDE, y una que no tiene que escribir en el código, lo que hace una gran diferencia en cuanto a si la verbosidad es un problema.

... ListView ...

¿Cómo manejaría este marcado un editor de GUI? Realmente no entiendo cómo visualizar la interfaz de usuario para esto.

Este puede ser un argumento en contra de esta solicitud, y/o tal vez una idea para tener en cuenta si desea marcar. Tengo la fuerte sensación de que agregar marcado crea algunos desafíos con GWT. Odiaría ver pasar otra API.

He visto un par de otros marcos pasar por esta transición con respecto a la construcción de la interfaz de usuario. El marcado como este funciona muy bien para las herramientas, hasta ahora es celestial para los desarrolladores de IDE. Es más fácil separar las responsabilidades de quién hace qué. Aunque creo que se puede hacer mejor.

GWT comenzó de esta manera, creando interfaces de usuario con Java. Luego apareció UiBinder, donde podía crear la interfaz de usuario en marcado xml, con una especificación. Luego, la herramienta, Eclipse Plugin, pudo generar interfaces de usuario en marcado xml. Android también lo está haciendo, no hay necesidad de insistir en el punto. Entonces, lo que vi sucedió, el marcado funciona muy bien para los desarrolladores de UI IDE. Pero en realidad, el marcado es una gran inversión en tiempo y herramientas de complejidad adicional para hacer la transición a un programa real. Y las herramientas siempre son las últimas en llegar. Entonces, mientras tanto, mientras todo eso se manifiesta en la realidad, hay dos mundos. Dos formas interesantes de hacer todo. Uno en el idioma predeterminado y otro en marcado. Así que apoyo a GWT hoy. Cuando escribo documentación, tengo que escribirla dos veces, una para Java y otra para UiBinder XML Markup. Entonces, la verdadera pregunta, si desea seguir el camino del marcado, creo que debe hacerse la pregunta, ¡es la complejidad adicional que vale la pena el viaje!

Creo que JSX tiene como objetivo resolver otros problemas en los que desea combinar lo que está haciendo con HTML y javascript. Realmente no parece que la complejidad adicional de la especificación de marcado se adapte a las necesidades de escribir la interfaz de usuario con marcado. Especialmente cuando realmente no tiene un lenguaje de marcado de documentos como destino. Al menos no para el usuario cotidiano.

En una nota positiva. Me gusta trabajar en herramientas. Así que puedo ver que un lenguaje de marcado es bastante útil. Es mucho más fácil escribir y modificar AST cuando usa marcado.

Pero, de nuevo, si tienes suficientes mentes en el trabajo, realmente no importa lo que hagas. Al final del día, si el desarrollador puede escribir su aplicación más rápido con su API, obtendrá tracción. Pero a qué costo para el equipo de ingeniería.

Creo que la verdadera pregunta es cómo se puede construir la interfaz de usuario más rápido. Creo que las herramientas podrían escribir el dardo, omitir cualquier marcado de intermediario. Y mi objetivo no es realmente decir que no valga la pena, ¡sino contar los costos en todos los frentes si se toma el camino!

E4X era un estándar ECMA. Mozilla lo envió por un tiempo, pero luego lo eliminó (un movimiento muy inusual para un proveedor de navegador). Otros proveedores de navegadores nunca quisieron implementarlo.

Diría que solo Adobe defendió completamente E4X y tuvo un buen seguimiento entre los desarrolladores. Los proveedores de navegadores agregan y eliminan cosas de sus navegadores todo el tiempo; ¿Google no eliminó la compatibilidad con MathML?

Esa es una teoría posible. Sin embargo, la gente tiende a pedir muchas otras cosas además, y muchas de las cosas que piden se implementan, y también hay soluciones para los GIF animados, por lo que no estoy seguro de que esto explique completamente la situación.

Esto es lo que pasa con React y JSX. realmente no aprecias completamente lo que React trae a la mesa hasta que desarrollas con él por un tiempo, luego se vuelve noche y día contra todos los demás marcos.

¿Cómo manejaría este marcado un editor de GUI? Realmente no entiendo cómo visualizar la interfaz de usuario para esto.

let style = {
  padding: new EdgeInsets.all(8.0),
  itemExtent: 20.0
};

<ListView.builder style={style}>
  {(context, index) => <Text> entry {index} </Text>}
</ListView.builder>

Yo representaría el \como un rectángulo y si es hijo/hijos donde hay otros widgets, pondría rectángulos para eso dentro.
Dado que el niño en este caso es una función, simplemente puede poner un rectángulo que diga 'no editable/código' para decirles a los usuarios que este widget se creó a partir del código o, en este caso, deducir fácilmente que la función es un envoltorio poco profundo para elwidget y simplemente presente eso; Me refiero a un rectángulo que dice que la función es un envoltorio de función poco profundo y dentro de él el rectángulo del widget de elemento de lista (\en este caso).

Pero en realidad, el marcado es una gran inversión en tiempo y herramientas de complejidad adicional para hacer la transición a un programa real.

Todo lo que pido es agregar estas extensiones simples en el compilador Dart para que, si los desarrolladores lo desean, puedan escribir usando esta estructura XML. La forma antigua continuaría funcionando y la cantidad de trabajo que implica hacer esto no es enorme en absoluto. De hecho, puede ver cuántas líneas de código necesita el compilador babel.js para hacer JSX y estoy hablando de cientos y no de miles de líneas (lo acabo de comprobar).

Y las herramientas siempre son las últimas en llegar. Entonces, mientras tanto, mientras todo eso se manifiesta en la realidad, hay dos mundos. Dos formas interesantes de hacer todo. Uno en el idioma predeterminado y otro en marcado

Claro, pero React ha sido así y eso no es un problema en absoluto.

Cuando escribo documentación, tengo que escribirla dos veces, una para Java y otra para UiBinder XML Markup.

No en React porque el marcado vive dentro del código.

¡Vale la pena el viaje por la complejidad añadida!

Absolutamente, es como el argumento de si debe capacitar a sus desarrolladores con las últimas técnicas y arriesgarse a que abandonen su empresa. El mayor riesgo es mantenerlos sin entrenamiento. Por lo tanto, debe adoptar las últimas técnicas que existen o correr el riesgo de quedarse atrás.

React está liderando el viaje con las últimas técnicas para desarrollar UI/UX. Tiene una tremenda tracción con los desarrolladores. Tu mayor riesgo es no alcanzar la barra de React.

Creo que JSX tiene como objetivo resolver otros problemas en los que desea combinar lo que está haciendo con HTML y JavaScript.

JSX no es solo para HTML, React Native genera vistas (como Flutter Widgets) a partir del marcado XML.

Creo que la verdadera pregunta es cómo se puede construir la interfaz de usuario más rápido.

Más bien, cómo se puede construir mejor la UI/UX. Mejor significado: más rápido, de mayor calidad (código y UI/UX), interacción fluida entre diseñador y desarrollador, etc.

Por cierto, muy buen trabajo realizado con las herramientas de desarrollo; 'doctor aleteo' fue increíble !!!
Ahora estoy cocinando con gas y puedo ser peligrosamente creativo;)

Solo quería responder a la pregunta sobre la legibilidad planteada aquí, aunque entiendo que la legibilidad es solo uno de los muchos factores que debemos considerar.

La legibilidad y la simplicidad del código, lo que a su vez genera muchos otros beneficios.

Si este es el beneficio principal, entonces es algo que podemos probar. Podríamos tomar una mezcla de ingenieros que están acostumbrados a escribir HTML, React, código de iOS, código de Android, Flutter, aplicaciones de línea de comandos, etc., y presentarles a cada uno de ellos varias sintaxis y pedirles que describan lo que piensan que es el la interfaz de usuario resultante se vería así. Entonces podemos medir qué sintaxis obtiene los mejores resultados. @InMatrix , ¿es esto algo que podríamos ver después de que termine el trabajo de animación, tal vez?

Sin duda, hay formas de estudiar empíricamente la legibilidad del código, y podemos tener una discusión más seria cuando llegue el momento de la planificación del cuarto trimestre. Para que este estudio sea útil, debemos definir qué tipos de tareas de lectura son importantes para los desarrolladores en el contexto de la programación de Flutter. Además de leer un método de compilación completo e imaginar cuál podría ser la interfaz de usuario resultante, la legibilidad también afecta tareas más pequeñas, como identificar el método de compilación en un archivo dart, unir llaves, leer comentarios en línea, etc.

Para respaldar algunas de esas tareas de alcance más limitado, primero podemos experimentar con las mejoras de la interfaz de usuario en el editor, lo que suele ser más económico que introducir y mantener un lenguaje de marcado. La función de etiqueta de cierre en el código VS es una de esas mejoras de la interfaz de usuario, y debemos entender qué tan bien resuelve el problema de coincidencia de llaves que se propone abordar. Hay muchas otras opciones en este espacio que aún no hemos probado. Por ejemplo, se puede usar una fuente o color de fondo diferente para mostrar el método de compilación para ayudar al desarrollador a separarlo mentalmente del resto de su código.

Otra cosa que me parece importante es cómo podemos alentar a las personas a no escribir un método de construcción gigante y aprovechar la naturaleza de composición del marco. Si el método de construcción es más alto que la altura de su pantalla, será difícil de leer independientemente de si es Dart o XML.

Otra cosa que me parece importante es cómo podemos alentar a las personas a no escribir un método de construcción gigante y aprovechar la naturaleza de composición del marco. Si el método de construcción es más alto que la altura de su pantalla, será difícil de leer independientemente de si es Dart o XML.

No es solo el método de construcción. El método de construcción llama a todos los demás métodos para construir el árbol de widgets. Es muy común en React usar métodos más pequeños para construir partes de subárboles y luego llamarlos al árbol más grande.

También en WebStorm con JSX, cada nodo XML tiene +/- que se puede usar para expandir/contraer el nodo y los elementos secundarios para facilitar la lectura de estructuras más grandes que la altura de la pantalla.

Una cosa que encontramos en Flutter es que los métodos de compilación grandes no son excelentes para el rendimiento, y tratamos de alentar a las personas a dividir sus métodos de compilación en widgets reutilizables más pequeños. En particular, en Flutter tener un método de compilación que se construye a partir de los resultados de otros métodos es algo así como un antipatrón que preferimos desalentar en lugar de facilitar. (Esto es algo así como una realización reciente, por lo que muchos de nuestros ejemplos y widgets aún no lo hacen bien).

tratamos de alentar a las personas a dividir sus métodos de compilación en widgets reutilizables más pequeños.

¿Realmente se convierte en un widget reutilizable o simplemente en un envoltorio/widget compuesto? Quiero decir que para ser reutilizable, debe tener al menos 2 instancias de uso.

AppBar en https://flutter.io/catalog/samples/basic-app-bar/ es tan único que realmente no se puede llamar un componente reutilizable; es un componente contenedor/compuesto y, en estos casos, ¿por qué no usar un método local para crear esa parte de la interfaz de usuario? Supongo que si hiciera más cosas, tendría sentido colocarlo en un contenedor/componente compuesto.

Una cosa que hemos encontrado en Flutter es que los métodos de compilación grandes no son excelentes para el rendimiento.

Como mencionó el rendimiento, hacer que el bucle de animación controle el método de compilación causará problemas de rendimiento para una animación fluida. No desea que su método de compilación se llame 60 veces por segundo o más, especialmente teniendo en cuenta que el método de compilación es un código de usuario (por ejemplo, podría tener un ciclo súper largo que dura una eternidad y haría que las animaciones se salten). Siendo un principiante de Flutter, tal vez me equivoqué.

La barra de aplicaciones en https://flutter.io/catalog/samples/basic-app-bar/ es tan única que realmente no puedes llamarla un componente reutilizable

También es relativamente pequeño, así que está bien.

Con respecto al rendimiento, esto está algo fuera de tema para este problema, así que presente un nuevo problema si desea discutirlo (o envíe un correo electrónico a flutter-dev o publíquelo en el desbordamiento de pila, lo que prefiera).

https://github.com/Kotlin/anko/wiki/Anko-Layouts

Es una locura ver que este problema se entierre. En mi opinión, será un éxito o un fracaso para Flutter implementar una sintaxis similar a JSX para componer widgets.

Simplemente no entiendo el público objetivo, muchos desarrolladores de iOS y Android se están moviendo para reaccionar de forma nativa, parece ser la oportunidad perfecta para cosechar participación de mercado.

Animo a las personas involucradas a darle una oportunidad a React Native y ver de qué estamos hablando.

No extraño JSX ni un poco en Flutter. Esto solo inflaría el marco y las herramientas para obtener algunas pequeñas ganancias aquí y allá.

@birkir Estoy 100% contigo en este tema. La falta de JSX, que encaja perfectamente con Flutter, hace que Flutter se vea viejo y oxidado, se siente como tecnología de la década de 1990. En realidad, parece que todo el mundo, de una forma u otra, está adoptando JSX; el último es el popular framework Vue.js.

+1

@zoechi ¿Cuál es su experiencia previa con JSX? ¿Realmente lo usó o simplemente lo miró? Creo que están subestimando a JSX al decir que dará pequeñas ganancias aquí y allá. Si no tienes ningún usuario, no tienes un producto.

@birkir Veo mucho entusiasmo por JSX aquí, pero nadie parece molestarse en explicar qué ganaría exactamente Flutter al tener un DSL de este tipo, excepto quizás una mejor legibilidad, que es principalmente subjetiva.

Más funciones generalmente solo acaparan un marco en lugar de mejorarlo.
Implementarlos también consume una gran cantidad de recursos que faltan en otras áreas donde las características que faltan en realidad impiden que las personas implementen ciertas aplicaciones.

Entonces, si está entusiasmado con que Flutter obtenga algo como JSX, debe invertir su tiempo y energía en escribir argumentos convincentes.
Simplemente agregar algo porque otros también lo tienen, es probablemente el argumento más débil que existe.

También hay planes para mejorar Dart para que la escritura del código de la interfaz de usuario de Flutter sea menos detallada, lo que debilita aún más el caso de JSX.

Entonces, ¿cuáles son sus argumentos convincentes?

En realidad !!! "Nadie parece molestarse en explicar qué ganaría exactamente Flutter... bla, bla, bla".
¿No has leído este hilo completo? ¿Tu capacidad de atención es mayor que tu conocimiento de JSX?

Ustedes están sufriendo del síndrome NIH (no inventado aquí). "Los buenos artistas copian, los grandes artistas roban", los artistas mediocres, pues, se comportan como tú.

Solo el hecho de que admitir JSX es relativamente simple y ayudará enormemente a atraer nuevos clientes (desarrolladores móviles de React Native) a la plataforma, lo convierte en una obviedad que ustedes no ven. No se adapta bien a la plataforma.

¿Podemos mantener un tono constructivo al debatir?

Agregar funciones porque otros las tienen es un argumento débil. Bueno.
¿Por qué flutter tiene recarga en caliente? De donde vino eso? Jesús tío.

¿Cómo fallamos en proporcionar un argumento sólido para ustedes? La tracción del proyecto y la atracción de desarrolladores es nuestra razón número uno.

Razón número dos, legibilidad :

https://github.com/flutter/flutter/blob/master/examples/flutter_gallery/lib/demo/cupertino/cupertino_buttons_demo.dart vs https://gist.github.com/birkir/e921158239c324ab95bb0b174383a562

Razón número tres, GUI Builders . Citaré la primera línea del LÉAME.

Un nuevo SDK de aplicaciones móviles para ayudar a los desarrolladores y diseñadores a crear aplicaciones móviles modernas para iOS y Android.

Odiaría ver a Flutter caer en la misma madriguera que Polymer antes de que llegue a la versión beta.

Tracción de proyectos y atracción de desarrolladores

La relación aún no está clara.

Razón número dos, legibilidad:

Hacer que el código Dart sea más legible me parece un mejor objetivo

Razón número tres, GUI Builders. Citaré la primera línea del LÉAME.

Por lo que recuerdo, ya se mencionó anteriormente que no hay ninguna razón por la que el uso del código Dart lo impida.

Tus contraargumentos realmente no pueden descartar la idea, ¿o sí?

1. La relación es bastante clara. ¿A menos que no sea un objetivo que el proyecto sea popular?
2. ¡Estupendo! ¿Estará cerca de la legibilidad de JSX? ¿Cuál es la propuesta actual para tal cosa?
3. Se dijo que se podía hacer . Adaptar el soporte de JSX para los constructores de GUI actualmente disponibles será mucho más simple.

También hay planes para mejorar Dart para que la escritura del código de la interfaz de usuario de Flutter sea menos detallada.

Es bueno ver el reconocimiento de que la forma actual podría usar algunas mejoras.
Proporcione detalles sobre dicha propuesta. Su mejor apuesta es interactuar con la comunidad de React Native para recibir comentarios.

Varias solicitudes de características del lenguaje Dart podrían hacer que el código sea más corto/legible:

• new y const opcionales para Dart 2
• Meta-problema para la discusión de la propuesta para permitir argumentos con nombre en todas partes : esto podría permitir que el widget con el argumento child omita el argumento con nombre.
  
  
  
  • Número variable de argumentos : esto podría permitir que los widgets con el argumento children (como Fila y Columna) omitan este argumento con nombre y su declaración de lista.
  
  

Con esos cambios, el código podría verse así:

  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: Text('Cupertino Buttons')),
      body: Column(
        Padding(padding: EdgeInsets.all(16.0),
          Text(
            'iOS themed buttons are flat. They can have borders or backgrounds but '
            'only when necessary.'
          ),
        ),
        Expanded(
          Column(mainAxisAlignment: MainAxisAlignment.center,
            Text(_pressedCount > 0
                   ? 'Button pressed $_pressedCount time${_pressedCount == 1 ? "" : "s"}'
                   : ' '),
            Padding(padding: EdgeInsets.all(12.0)),
            Align(alignment: Alignment(0.0, -0.2),
              Row(mainAxisSize: MainAxisSize.min,
                CupertinoButton(onPressed: () { setState(() { _pressedCount += 1; }); },
                  Text('Cupertino Button'),
                ),
                CupertinoButton(onPressed: null,
                  Text('Disabled'),
                ),
              ),
            ),
            Padding(padding: EdgeInsets.all(12.0)),
            CupertinoButton(
              color: CupertinoColors.activeBlue,
              onPressed: () { setState(() { _pressedCount += 1; }); },
              Text('With Background'),
            ),
            Padding(padding: EdgeInsets.all(12.0)),
            CupertinoButton(
              color: CupertinoColors.activeBlue,
              onPressed: null,
              Text('Disabled'),
            )
          ),
        ),
      )
    );
  }

Además, dependiendo de su IDE, puede tener opcionalmente comentarios sintéticos al final del paréntesis y podría ver algo como esto en su IDE:

  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: Text('Cupertino Buttons')),
      body: Column(
        Padding(padding: EdgeInsets.all(16.0),
          Text(
            'iOS themed buttons are flat. They can have borders or backgrounds but '
            'only when necessary.'
          ),
        ),
        Expanded(
          Column(mainAxisAlignment: MainAxisAlignment.center,
            Text(_pressedCount > 0
                   ? 'Button pressed $_pressedCount time${_pressedCount == 1 ? "" : "s"}'
                   : ' '), // Text
            Padding(padding: EdgeInsets.all(12.0)),
            Align(alignment: Alignment(0.0, -0.2),
              Row(mainAxisSize: MainAxisSize.min,
                CupertinoButton(onPressed: () { setState(() { _pressedCount += 1; }); },
                  Text('Cupertino Button'),
                ), // CupertinoButton
                CupertinoButton(onPressed: null,
                  Text('Disabled'),
                ), // CupertinoButton
              ), // Row
            ), // Align
            Padding(padding: EdgeInsets.all(12.0)),
            CupertinoButton(
              color: CupertinoColors.activeBlue,
              onPressed: () { setState(() { _pressedCount += 1; }); },
              Text('With Background'),
            ), // CupertinoButton
            Padding(padding: EdgeInsets.all(12.0)),
            CupertinoButton(
              color: CupertinoColors.activeBlue,
              onPressed: null,
              Text('Disabled'),
            ), // CupertinoButton
          ), // Column
        ), // Expanded
      ), // Column
    ); // Scafold
  }

Esta conversación se está calentando. Me gustaría animar a todos a leer nuestro código de conducta:
https://flutter.io/design-principles/#conflict -resolución
Voy a cerrar esta conversación por unos días mientras todos consideran cómo pueden contribuir de manera respetuosa y productiva.

Todos sabemos que la sintaxis para construir la interfaz de usuario es una parte muy importante de la experiencia de desarrollo móvil. Por ahora, la sintaxis es un poco detallada, tengo que new algo solo con el fin de agregar un margen: margin: new EdgeInsets.symmetric(horizontal: 4.0) , creo que puede haber una manera más fácil.

¿Sería posible construir un DSL como lo que hizo el equipo de Kotlin para los desarrolladores de Android? Se llama Anko , un DSL para construir la interfaz de usuario de Android:

verticalLayout {
  padding = dip(30)
  editText {
    hint = "Name"
    textSize = 24f
  }
  button("Login") {
    textSize = 26f
  }
}

Una sintaxis concisa ayuda a mantener el código legible y mantenible, también puede hacer que el trabajo de construcción sea agradable, sí importa. Por favor, el equipo de Flutter estime seriamente antes de tomar una decisión. A todos nos encanta ver que Flutter tenga un mayor éxito en los próximos años.

Por favor, no introduzcas una sintaxis similar a XML en Flutter.

Programé en Android Java durante más de un año, luego comencé a buscar un conjunto de herramientas multiplataforma para probar.
Empecé con React Native y luego probé React. Realmente no me gustó la sintaxis de JSX porque no es del todo javascript ni del todo html, así que es otra cosa que aprender.
Cuando probé Flutter, me resultó mucho más fácil comenzar (probablemente debido principalmente a mi experiencia en Java).

Creo que algunas de las razones por las que no me gustaría ver una sintaxis XML agregada a flutter:

1. Otra cosa para aprender: podría dedicarse a aprender Futuros en su lugar; P
2. Cambio de contexto: está cambiando de contexto entre XML y código, lo que es solo una carga cognitiva innecesaria.
3. Ha habido días en los que he programado en Java por la mañana y en Python por la tarde. Con React, es posible que deba comprender Javascript, Babel, JSX, HTML, CSS y más en una base de código.
4. La razón por la que XML no es necesario en Flutter es porque dart tiene argumentos con nombre que reemplazan bastante bien los atributos XML.
5. Dart tiene el genial dartfmt que sangra el código muy bien sin esfuerzo.

Comparando con Android

1. Tienes que aprender la forma programática de todos modos, ¿por qué agregar otra forma de hacer las cosas?
2. El diseño XML en Android es más rápido para mostrar los cambios en el dispositivo, pero la ejecución en Flutter es prácticamente instantánea de todos modos, por lo que agregar XML no proporcionaría esa ventaja.
3. La combinación programática de Android XML + agrega complejidad, como inflar fragmentos XML e inyectar en el árbol XML mediante programación.
4. La ejecución instantánea es tan rápida en Flutter que no necesita el modelo XML para ayudar a visualizar cómo aparecerá, solo puede presionar una tecla y ver el cambio de inmediato.
5. Los errores de los problemas de diseño programáticos son diferentes de los problemas de diseño en XML, por lo que hay dos conjuntos de cosas que debe comprender.

Iría un paso más allá y eliminaría pubspec.yaml y lo reemplazaría con pubspec.dart y tendría la configuración en código dart.

Si los desarrolladores se quejan de la dificultad de diseñar las páginas visualmente, una idea sería crear un diseñador de diseño que le permita configurar sus temas y diseñar páginas visualmente arrastrando y soltando. Luego, generaría código de Flutter que no está destinado a ser editado nunca, sino que crea clases que se pueden usar para componer su aplicación.

No necesitaría ser una edición bidireccional (XML/diseño) como Android XML, pero simplemente guarde su diseño para más tarde. Si necesita cambiarlo, puede regenerar el código y (con suerte) simplemente cambiar algunos argumentos.

Sé que esta conversación es vieja y sí, se estaba poniendo bastante caliente, pero me gustaría dejar caer algunas líneas sobre lo que considero que está sucediendo aquí.

Flutter es NUEVO. Es una forma completamente NUEVA de hacer las cosas. Sí, tomó prestado del paradigma de reacción. Pero no significa que deba seguir sus mismos pasos. No creo que el objetivo del equipo de Flutter sea atraer a desarrolladores de React Native para que vengan a Flutter, es solo crear algo nuevo en lo que los desarrolladores puedan encontrar interés. Google lo usa internamente antes de compartirlo con el mundo y han sido productivos con eso. Comparto los comentarios con @Hixie de que no es diferente de JSX para construir la interfaz de usuario. Sí, es un poco más detallado a dardo puro derecho. Pero en realidad hace que la depuración de su código sea mucho más fácil.

La razón por la que estoy en contra de un lenguaje de marcado o JSX o cualquier cosa que se asiente sobre una tecnología es que requiere mucho más trabajo de la plataforma. Puede ser feliz componiendo lenguaje de marcado para una interfaz de usuario, pero tendrá tantos desarrolladores trabajando en la plataforma llorando y tirándose de los pelos para que funcione para usted. Otro punto de vista es que JSX funcionó para una comunidad de Javascript, donde, como siempre, su objetivo principal es facilitar las cosas al desarrollador y no preocuparse por las compensaciones. No me malinterpreten React (JSX) para web fue una combinación perfecta porque HTML es marcado de todos modos. Pero para React Native, mire todo el código en el repositorio que tuvieron que hacer para que funcionara. Agregar JSX a flutter requeriría toneladas de trabajo y 2 cosas en las que pensar al agregar nuevas funciones. Y nuevamente, solo para poder eliminar el parámetro secundario y las palabras clave const y new?. Prefiero saber lo que realmente está sucediendo en el código y tener control sobre lo que está sucediendo que tener una sintaxis mágica que todo lo que hace es agregar gastos generales.

Bueno, esa es mi opinión. No quiero comenzar una nueva discusión gigantesca. Solo por mencionar el hecho de que JSX es increíble para una comunidad de React/Javascript porque funcionó para ellos, pero para Dart/Flutter me parece un poco exagerado agregar JSX solo para atraer a los desarrolladores de React Native.

Wow, podría haber escrito una entrada de blog xD

@Rockvole ,

Otra cosa para aprender: podría dedicarse a aprender Futuros en su lugar; P

Lo que hay que aprender hace que la monstruosidad de construcción de objetos recursivos actual sea más simple y familiar para los desarrolladores de React Native todos los días, por lo que supongo que la gente preferirá aprender eso.

Cambio de contexto: está cambiando de contexto entre XML y código, lo que es solo una carga cognitiva innecesaria.

No es un problema, no hay cambio de contexto, es solo parte del entorno que hace que la programación UI/UX sea más limpia.

Luego generaría código Flutter que no está destinado a ser editado nunca

¿Por qué no? No es muy útil entonces.

@franzsilva

No creo que el objetivo del equipo de Flutter sea atraer desarrolladores de React Native para que vengan a Flutter.

En realidad !!! React Native domina y dado que la cantidad total de desarrolladores móviles que utilizan herramientas multiplataforma es limitada, ¿realmente crees que Flutter puede convertirse en un éxito sin atraer a la gente de React Native?

Sí, es un poco más detallado a dardo puro derecho. Pero en realidad hace que la depuración de su código sea mucho más fácil.

Esa no es una afirmación correcta. La depuración del código JSX, que es solo código javascript, no es más fácil ni más difícil, es lo mismo.

La razón por la que estoy en contra de un lenguaje de marcado o JSX o cualquier cosa que se asiente sobre una tecnología es que requiere mucho más trabajo de la plataforma.

¿A quién le importa cuánto trabajo se colocó en la plataforma? Los desarrolladores solo quieren las últimas técnicas que mejoren la legibilidad del código y la productividad. Ningún desarrollador quiere usar técnicas antiguas y obsoletas cuando las cosas más nuevas ofrecen una mejor alternativa.

Prefiero saber lo que realmente está sucediendo en el código y tener control sobre lo que está sucediendo que tener una sintaxis mágica que todo lo que hace es agregar gastos generales.

Esto no tiene sentido, sé exactamente lo que sucede con JSX, es una pequeña capa que se transforma casi uno a uno pero brinda muchos beneficios. Sobrecarga de tiempo de compilación insignificante si me preguntas.

Solo por mencionar el hecho de que JSX es increíble para una comunidad de React/Javascript porque funcionó para ellos, pero para Dart/Flutter me parece un poco exagerado agregar JSX solo para atraer a los desarrolladores de React Native.

JSX también debería funcionar muy bien para Dart/Flutter. No es una exageración de ninguna manera. ¿Hay alguna buena razón por la que JSX no funcione para Dart/Flutter? Si tuviera que codificarlo y publicarlo, ¿por qué no sería una buena opción para el desarrollo de Dart/Flutter?

Tomemos el ejemplo concreto de @xinthink :

Por ahora, la sintaxis es un poco detallada, tengo que new algo solo con el fin de agregar un margen: margin: new EdgeInsets.symmetric(horizontal: 4.0) , creo que puede haber una manera más fácil.

Si desea agregar un margen a la izquierda y a la derecha, ¿cómo le gustaría expresarlo? Específicamente, tomemos un ejemplo simple y veamos cómo se vería en varias sintaxis.

  // Flutter as written today
  return new Container(
    margin: new EdgeInsets.symmetric(horizontal: 4.0),
    decoration: new ShapeDecoration(shape: new CircleBorder(), color: Colors.blue[100]),
    child: new AnimatedCrossFade(
      duration: const Duration(seconds: 3),
      firstChild: const FlutterLogo(style: FlutterLogoStyle.horizontal, size: 100.0),
      secondChild: const FlutterLogo(style: FlutterLogoStyle.stacked, size: 100.0),
      crossFadeState: _showHorizontal ? CrossFadeState.showFirst : CrossFadeState.showSecond,
    ),
  );

  // Flutter as written later this year once we remove "new" and "const" keywords
  return Container(
    margin: EdgeInsets.symmetric(horizontal: 4.0),
    decoration: ShapeDecoration(shape: CircleBorder(), color: Colors.blue[100]),
    child: AnimatedCrossFade(
      duration: Duration(seconds: 3),
      firstChild: FlutterLogo(style: FlutterLogoStyle.horizontal, size: 100.0),
      secondChild: FlutterLogo(style: FlutterLogoStyle.stacked, size: 100.0),
      crossFadeState: _showHorizontal ? CrossFadeState.showFirst : CrossFadeState.showSecond,
    ),
  );

¿Cómo recomendaría que expresemos esta semántica _exacta_?

  // Remove "new" and "const", infer the class for enum values, allow int literals for doubles
  return Container(
    margin: EdgeInsets.symmetric(horizontal: 4),
    decoration: ShapeDecoration(shape: CircleBorder(), color: Colors.blue[100]),
    child: AnimatedCrossFade(
      duration: Duration(seconds: 3),
      firstChild: FlutterLogo(style: horizontal, size: 100),
      secondChild: FlutterLogo(style: stacked, size: 100),
      crossFadeState: _showHorizontal ? showFirst : showSecond,
    ),
  );

Babel.js tiene este pequeño y elegante sitio web, donde puedes escribir JSX y lo convierte a Javascript simple:
https://babeljs.io/repl/# ?babili=false&evaluate=true&lineWrap=false&presets=es2015%2Creact%2Cstage-0&code=function%20hello()%20%7B%0A%20%20return%20%3Cdiv%3EHello% 20mundo!%3C%2Fdiv%3E%3B%0A%7D

Haré uno equivalente para DSX a Dart. Solo una prueba de concepto, a ver cuanto tiempo me tomo...

Aquí está el último ejemplo de @Hixie en "DSX", utilizando la guía de estilo de Airbnb y suponiendo que todos los elementos secundarios pueden asignarse automáticamente a propiedades child .

return (
  <Container
    margin={EdgeInsets.symmetric(horizontal: 4)}
    decoration={ShapeDecoration(shape: CircleBorder(), color: Colors.blue[100])}
  >
    <AnimatedCrossFade
        duration={Duration(seconds: 3)}
        crossFadeState={_showHorizontal ? showFirst : showSecond}
    >
      <FlutterLogo style={horizontal} size={100} />
      <FlutterLogo style={stacked} size={100} />
    </AnimatedCrossFade>
  </Container>
);

Si la intención es mejorar la legibilidad, creo que Future Dart gana con creces.

Debe consultar la documentación para saber qué se puede convertir en etiquetas (presumiblemente solo Widget s), o cuántos elementos secundarios se requieren/permiten.

Si su objetivo es generar HTML desde JavaScript, JSX tiene mucho sentido como término medio. Porque cuando quieres etiquetas al final del día, React.createElement('div', null, 'foo') es mucho peor que <div>foo</div> .

Si su objetivo es generar un árbol de objetos Dart desde... Dart, y un árbol bien formateado de constructores de Dart es perfectamente (posiblemente más) legible, no veo el punto de desviarse a través de XML. Y no me faltan esos XML que vienen de Android.

Es lo que permite el uso de XML... Mira, han pasado 5 meses con solo hablar, ahora estoy haciendo algo al respecto, así que dame algo de tiempo (tengo un trabajo de tiempo completo y solo puedo dedicar unas 4 horas los fines de semana).

Acabo de encontrar este hilo, interesante en ambos lados. Como desarrollador de React interesado en Flutter, hay un par de otros argumentos que no he visto mencionados (aunque solo leí brevemente todos los comentarios).

1. La declaración de la etiqueta de cierre aumenta la comprensión de los niños frente a las propiedades. Desafortunadamente, la interfaz de usuario puede estar profundamente anidada, y tener una etiqueta clara frente a una desconocida ayuda a aclarar y analizar a los niños. También me permite mover el código entre los componentes y ver de manera muy declarativa cuándo algo está fuera de lugar (una etiqueta de cierre antes de, por ejemplo). Esto es más complicado con múltiples ) anidados.

2. Mi reacción visceral inicial al ver múltiples componentes anidados dentro de los constructores me recuerda al "infierno de devolución de llamada" . Fue una era muy dolorosa de JS que está empezando a mejorar, volver a ella se siente un poco como un paso atrás.

3. Relacionado con el n. ° 2, el hecho desafortunado es que tenemos que convencer a las personas para que cambien (o al menos lo prueben). Muchas personas usan React/React Native y aún más usan HTML/JS. La creación de un tutorial/guía simple y en su mayoría sintácticamente familiar que aborde específicamente algunos de los puntos débiles de React podría ser extremadamente convincente para aquellos que están un poco fatigados.

Una de las principales razones por las que React se hizo popular en la comunidad de desarrolladores web fue el soporte de JSX.

Es realmente decepcionante ver "votos negativos" en una solicitud de función tan agradable. Mejora la legibilidad y acelera la adopción.

Creo que esta es una gran diferencia entre Open JavaScript y Dart. JavaScript es verdaderamente de código abierto, mientras que una solicitud en Dart entra en una conversación como esta y, en última instancia, te desmotivas con los votos negativos.

¡Haz más espacio para nuevas ideas!

@jayjun ¡ Eso se ve increíble! ¿Puedo probarlo en alguna parte?

@sanketsahusoft No te preocupes, muy pronto podrás probar mi versión y es incluso mejor que la de @jayjun.

Actualización rápida: hace 2 fines de semana, la interfaz de usuario funcionó muy bien. El fin de semana pasado, el analizador funcionó completamente y la mitad del transpilador funcionó. Este próximo fin de semana espero rematarlo si evito la Superbowl ;)

Tengo la piel gruesa y la terquedad de mula, así que ni siquiera me doy cuenta de estos votos negativos, aunque gracias por señalarlos.

carlos

¿Ayudaría esto con el problema de perder el rastro de las etiquetas de cierre?
Idea: etiquetas de cierre generadas automáticamente

Aquí hay una sintaxis de marcado propuesta para el ejemplo de @Hixie :

<Container margin=<EdgeInsets.symmetric horizontal=4 />
           decoration=<ShapeDecoration shape=<CircleBorder> color={{ Colors.blue[100] }} />>
    <AnimatedCrossFade duration=<Duration seconds=3 />
                       crossFadeState={{ _showHorizontal ? showFirst : showSecond }}>
      <FlutterLogo style=horizontal size=100 />
      <FlutterLogo style=stacked size=100 />
    </AnimatedCrossFade>
</Container>

@abarth , lo interesante que hiciste fue agregar una tercera posibilidad de atributo que simplifica el aspecto de las expresiones cuando son otra etiqueta.
JSX tiene:
1 - <tag attrib=""/> o <tag attrib=''/>
2 - <tag attrib={}/>
Usted sugirió otro:
3 - <tag attrib=<anotherTag.../>/>
con JSX tienes que escribirlo como:
<tag attrib={<anotherTag.../>}/>

@cbazza Sí, el tercer caso es bastante común en Flutter, por lo que tiene sentido omitir el anidamiento adicional { .

@abarth ¡ Ah, pero estoy haciendo que la mayoría de esas cosas sean innecesarias al usar estilos similares a css! El transpiler expande estos estilos similares a css en llamadas de Flutter apropiadas. Ahora la estructura de etiquetado es mucho más limpia y los estilos se pueden importar fácilmente desde herramientas de diseño como InVision, Figma, Atomic, etc.

@cbazza Genial, uso muchos widgets con cierres como FutureBuilder . Espero que su transpiler pueda generar algo como,

return new FutureBuilder(
  future: Firestore.instance
      .collection('stuff')
      .document(id)
      .get(),
  builder: (context, snapshot) {
    if (!snapshot.hasData) {
      switch (snapshot.connectionState) {
        case ConnectionState.waiting:
          return const Text('Loading...');
        default:
          return new Text('${id} not found');
      }
    }

    return new Text(snapshot.data['name']);
  },
);

@jayjun , sí, eso no es un problema. El transpiler es un procesador XML simple y cuando se trata de analizar expresiones (todo lo que está dentro de {}), simplemente se convierte en un blob de texto, por lo que lo escribe palabra por palabra.

@xinpensar

¿Sería posible construir un DSL como lo que hizo el equipo de Kotlin para los desarrolladores de Android?

Parece que a mucha gente le gustaría usar Kotlin con Flutter. Honestamente, no entiendo, ¿por qué los desarrolladores decidieron reinventar las ruedas en Dart?

En mi humilde opinión, Flutter no necesita JSX. Flutter debería haber elegido Kotlin en lugar de Dart. Kotlin nos permite escribir una lógica de interfaz de usuario compleja con una hermosa sintaxis lista para usar, tiene una gran comunidad, herramientas listas para producción, probado en batalla en el desarrollo de Android...

Solo digo.

Kotlin es bueno, soy un fan, pero no se ejecuta en iOS... en realidad lo hace, pero aún no se ha lanzado (etapa de prelanzamiento en este momento).
Para el desarrollo de UI/UX sigo prefiriendo JSX en lugar de Anko DSL. Me gusta el hecho de que puedo separar visualmente el marcado declarativo del código imperativo y poder mezclar y combinar componentes con bastante facilidad.

Dart, Kotlin y Swift tienen similitudes:
https://sethladd.github.io/swift-es-como-kotlin-y-un-poco-como-dart/

Me gusta eso :

1. Dart es más familiar si vienes de Java.
2. Puede tomar sus habilidades de Dart y usarlas para crear páginas web, lo cual es valioso al crear aplicaciones, puede crear funciones en la web (y mostrarlas en un WebView) donde tenga más sentido (tal vez páginas de administración rápida o listados de productos que necesita estar indexado en Google).
3. Dart se creó desde el principio para compilar en javascript, lo que supongo que no es fácil de agregar a un idioma más adelante.

Estas son básicamente las razones por las que elegí Dart en lugar de Kotlin/Swift/React.

_Aunque la decisión de admitir Dart y Swift en el nuevo sistema operativo Fuchsia de Google me resulta confusa._

No estoy seguro de que Dart sea más familiar si vienes de Java. Vengo de Java y no tengo problemas con Kotlin o Swift; básicamente, la declaración de tipo está invertida, nada realmente nuevo, ya que se usó en Pascal y ActionScript.

Sí, puede crear páginas web con Dart, pero no veo una gran aceptación con eso. El único otro lenguaje que funciona bien en la web es TypeScript, ya que se integra bien con los 3 marcos web más populares.

Eche un vistazo a las diferentes sintaxis disponibles para React on the Web:
https://github.com/Workiva/over_react#fluent-style-component-consumption
¡Ambas versiones de Dart no tienen ninguna posibilidad contra JSX!

TypeScript fue diseñado para compilar en Javascript y es mejor que Dart para eso. También es compatible con JSX.
Dart está siendo exprimido por todos lados. Swift tiene impulso, por lo que es aconsejable apoyarlo en Fuchsia OS junto con su bebé.

¿Cuánto tiempo hasta el prototipo? ¡Me encantaría usarlo!

Usé React por un tiempo y JSX multiplicó por diez mi productividad. Este no es un tema controvertido: otros equipos decidieron, correctamente, que esto sería mejor, entonces, ¿por qué no Flutter? (Retórica: leí el hilo... (facepalm))

Estoy trabajando en ello este fin de semana, pero sigo aumentando el alcance con nuevas ideas, así que espero poder sacar algo este fin de semana.

Algunas de las cosas interesantes con las que estoy experimentando:
1) usar el espacio de nombres xml en las etiquetas secundarias para que se inserten con el argumento Dart correcto en el padre.
2) operador de difusión para organizar mejor las propiedades similares al estilo para que puedan definirse/agruparse fuera de xml en un mapa y luego incorporarse y distribuirse en una etiqueta como las cosas típicas de React.
3) propiedad styleCSS que genera estilos flutter a partir de CSS.

(1) y (2) son genéricos, por lo que funcionan para todo el código Dart Flutter.
(3) está especializado por Flutter Widget (Contenedor, Texto, etc.) y solo estoy haciendo esos 2 por ahora.

@ yuriy-manifold solo porque algo funcionó para JS no significa que sea una buena idea para Dart.
Si hubiera leído las discusiones anteriores, vería que, de hecho, es controvertido.
No veo por qué 2 idiomas sería mejor que uno.

solo porque algo funcionó para JS no significa que sea una buena idea para Dart.

JSX es una idea increíble para el desarrollo de UI/UX en un marco reactivo, independientemente del idioma. Si tuviera más tiempo libre, sacaría LSX, que es JSX para Logo;)

No veo por qué 2 idiomas sería mejor que uno.

Puedes programar iOS con Objective-C y Swift (2 idiomas)
Puedes programar Android con Java y Kotlin (2 idiomas)
...

Todavía tengo que ver un argumento a favor de JSX.
Las discusiones anteriores solo contienen argumentos como "es mejor", "aumenta la productividad" o similar, pero no hay argumentos de por qué o cómo sería realmente mejor que el código Dart puro, especialmente considerando los cambios de lenguaje planificados que reducirían la diferencia entre JSX-like y
código Dart puro aún más.

@cbazza

Puedes programar iOS con Objective-C y Swift (2 idiomas)
Puedes programar Android con Java y Kotlin (2 idiomas)

¿Cómo se relaciona eso con la discusión de JSX? ¿Cómo se puede considerar eso una ventaja?
Puede usar Swift en iOS porque es el sucesor de Objectiv-C.
Puede usar Kotlin en Android porque se considera una mejora ingeniosa para Java.
Parece que usted argumenta que JSX debería reemplazar a Dart. Eso no tiene mucho sentido para mí.

@zoechi

¿Cómo se relaciona eso con la discusión de JSX? ¿Cómo se puede considerar eso una ventaja?
Puede usar Swift en iOS porque es el sucesor de Objectiv-C.
Puede usar Kotlin en Android porque se considera una mejora ingeniosa para Java.
Parece que usted argumenta que JSX debería reemplazar a Dart. Eso no tiene mucho sentido para mí.

En realidad lo dijiste (JSX es una mejora ingeniosa con respecto a la forma actual) pero llegaste a la conclusión equivocada (JSX para reemplazar a Dart).

@cbazza eso es más de lo mismo

¿Cuál es la ventaja real sobre Dart simple?

"JSX es una mejora ingeniosa" simplemente no es convincente de ninguna manera y no es un argumento.
Es solo una opinión personal sin (nuevamente) ningún argumento que la respalde,
similar con otros argumentos pro-JSX anteriores.

No puede esperar que nadie considere sus sugerencias si no está dispuesto a proporcionar buenos argumentos.

Agregar algo como JSX a Dart genera mucho trabajo y complejidad en las herramientas de Flutter y el IDE. Debe proporcionar argumentos adecuados para que otros incluso consideren mirarlo.

@zoechi suena como un disco rayado que pide "buenos" argumentos, se dieron muchos antes, pero simplemente no los entendiste; lo cual está bien, 'a cada uno lo suyo'.

Agregar algo como JSX a Dart genera mucho trabajo y complejidad en las herramientas de Flutter y el IDE. Debe proporcionar argumentos adecuados para que otros incluso consideren mirarlo.

No realmente, mi trabajo está casi listo y me tomó muy poco tiempo considerando que solo trabajé en él los fines de semana.

Nuevamente, DSX es solo una mejora ingeniosa que las personas pueden elegir usar o no, porque no cambia la forma actual, solo brinda una alternativa con la que otros (desarrolladores de React) se familiarizarán instantáneamente.

@cbazza

se dio mucho

realmente no. Solo afirmaciones generales que pueden ser ciertas o no.
No se proporcionaron detalles adicionales que permitieran a otros verificar.

No realmente, mi trabajo está casi listo.

Estupendo. Entonces no hay necesidad de que el equipo de Flutter haga nada y el problema se puede cerrar ;p
¿Esto incluye compatibilidad con autocompletado y verificaciones de sintaxis en todos los IDE compatibles con Flutter?

Estupendo. Entonces no hay necesidad de que el equipo de Flutter haga nada y el problema se puede cerrar ;p

;)

¿Esto incluye compatibilidad con autocompletado y verificaciones de sintaxis en todos los IDE compatibles con Flutter?

La mayoría de los IDE ya son compatibles con XML y JSX, por lo que no sería difícil para ellos agregar mis adiciones menores.

Me pregunto si la sintaxis JSX podría ser más apreciada en angular Dart. Parece que es más una situación a la que estás acostumbrado en lugar de "mejor". La sintaxis JSX probablemente se sienta más natural para los desarrolladores web.

Sé que la programación se siente incómoda para mí, incluso usando diferentes colores de resaltado de código durante un día.

https://blog.dantup.com/2014/08/has-arruinado-html/

Sí, las personas de Angular se sentirán muy cómodas con JSX, pero también lo estarán los desarrolladores de React Native y esto es para el desarrollo móvil. Ciertamente, los desarrolladores actuales de Flutter no tomarán JSX, pero esta segunda alternativa atraerá a nuevos desarrolladores a Flutter y eso es seguro.

El artículo anterior se equivocó tanto, React sin JSX es básicamente inexistente y todos los marcos web reactivos permiten mezclar marcado y programación en su DSL.

Ha llegado el momento...
Es un gran placer anunciar el transpilador DSX en línea.
https://chispa-heroku-dsx.herokuapp.com/index.html

Buen trabajo con el transpiler cbazza
Una cosa que diría que es más fácil de seguir con JSX son las etiquetas de cierre. La idea que mencioné antes:
Idea: etiquetas de cierre generadas automáticamente

En su primer ejemplo, le daría un código de aleteo de (eliminó el nuevo opcional en el futuro Dart):

Material(
  child: Column(
    children: <Widget>[
      MyAppBar(
        title: Text(
          'Example title',
          style: Theme.of(context).primaryTextTheme.title,
        )-Text,
      )-MyAppBar,
      Expanded(
        child: Center(
          child: Text(
            'Hello, world!',
          )-Text,
        )-Center,
      )-Expanded,
    ],
  )-Column,
)-Material;

@cbazza Agradezco su trabajo para la comunidad y las personas que quieren crear interfaces de usuario de esa manera, pero realmente espero nunca verme obligado a usar algo así en Flutter :-(((

Como recién llegado a Flutter pero bastante familiarizado con React, me llamaron la atención algunas cosas:

• El modelo de gestión estatal es más o menos el mismo
• El árbol de representación virtual de widgets/componentes es prácticamente el mismo
• Conociendo el estado y el modelo de componentes, básicamente me siento listo para escribir una aplicación ahora, excepto algunas especificaciones de Dart y las API de la plataforma, pero...
• El lenguaje de estilo es un escollo. Me refiero a https://flutter.io/web-analogs/ pero no es fácil averiguar qué importaciones se requieren para que las cosas funcionen (¿EdgeInset? ¿Color?) o cuándo debo usar primitivas en lugar de instancias de clase.
• El analizador CSS del convertidor DSX de @cbazza es realmente útil para descubrir equivalentes de diseño en el modelo Flutter.

Con respecto a JSX:

• No creo que sea necesario inventar una nueva sintaxis JSX para admitir patrones de Flutter. Algunas de las dudas de sintaxis en este hilo podrían resolverse utilizando algunos de los patrones de React más nuevos, como componentes de orden superior (funciones que construyen clases de componentes) y accesorios de representación (componentes que toman funciones como argumentos; las funciones devuelven elementos). Por ejemplo, el nombre "ranuras para niños" podría traducirse en algo como esto en JSX:

<Item
  right={() => new Text("Right")} {/* a named slot */}
  left={() => new Text("Left")}> {/* another named slot */}
  <ChildOne /> {/* generic children prop with 2 children */}
  <ChildTwo>
    <NestedChild />
  </ChildTwo>
</Item>

• El mejor argumento contra JSX que vi fue que Dart ha nombrado argumentos.
• ¿Por qué es importante que un elemento sepa si tiene varios hijos o un solo hijo? Tal vez una construcción de "fragmento" podría eliminar la ambigüedad de esa API.

Sigo pensando, como recién llegado a Flutter con algo de experiencia con Angular, React, etc., que la forma normal de Dart, y más en Dart 2.0, es mejor que este DSX. Simplemente tiene más sentido que algunos parámetros XML y CSS-ish. 🤷‍♂️

@cbazza, su segundo ejemplo de demostración tiene 466 caracteres en comparación con los 391 de dart (ambos sin espacios). A mí me parece visualmente hinchado. Tendría que aprender su semántica, que no tengo que hacer con el código normal de Dart. Y no tengo idea de cómo usar paradigmas de programación de propósito general con él (if, forEach, etc.).

Si pudiera elegir, me quedaría con el modelo actual.

Todos están dando su propia opinión subjetiva al comparar ambas sintaxis, pero tenemos que estar de acuerdo en un hecho: es una característica muy controvertida. Hay amor y odio, pero la mayoría de las opiniones divergen sobre la utilidad de JSX sobre Dart simple.

En cualquier caso, creo que es totalmente irrazonable pedirle al equipo de Flutter que se comprometa a admitir esta función antes del lanzamiento de la versión 1.0. Si bien la forma actual de crear una interfaz de usuario puede no parecer excelente para todos, funciona (y funciona muy bien en algunas opiniones).

Si la gente realmente quiere una sintaxis similar a JSX ahora, un esfuerzo impulsado por la comunidad parece ser el camino a seguir. Y ayudaría a presentar el caso (o no) cuando el equipo de Flutter lo considere en el lanzamiento posterior a 1.0.

Personalmente, estoy totalmente de acuerdo con el siguiente argumento: no es porque JSX funcione para React (donde ya está creando la interfaz de usuario usando un lenguaje de marcado) que funciona automáticamente para Flutter.

@tehfailsafe

La buena noticia es que incluso si esto fue adoptado por el equipo de Flutter (que probablemente no se base en este hilo), nadie se vería FORZADO a usarlo. Es una OPCIÓN. No entiendo por qué es tan emocional que a algunas personas les guste escribir código con una sintaxis que no les gusta...

No me importa lo que les guste o no les guste a otras personas. Pero me importan las características que me ayudan a progresar con mi aplicación. Los recursos son limitados y preferiría tener un reproductor de video/transmisión adecuado, vistas nativas para niños y algún formato de gráficos vectoriales.

Por ejemplo, ahora mismo en React y React Native puedes escribir toda tu aplicación sin JSX, es solo una opción. Así es como se ve React sin JSX:
[...]
Es mucho más desordenado que la versión JSX y casi nadie lo usa. Probablemente es por eso que algunos de nosotros que venimos de React apreciaríamos la posibilidad de evitar tener que hacerlo de este estilo nuevamente.

Eso es porque la web no fue diseñada para un sistema como ese. Si tiene un lenguaje de marcado estático como HTML y desea "dinamizarlo", debe inventar un sistema que deba funcionar sobre eso. Con lo que terminará es una construcción restringida por la plataforma subyacente.
(ver: https://gbracha.blogspot.de/2014/09/a-domain-of-shadows.html)

Flutter, por otro lado, no tiene lenguaje de marcado. Todavía tengo que ver una razón para invertir recursos en algo que sea menos dinámico y menos expresivo.

Me gustaría saber si las personas que no están de acuerdo han usado React con y sin JSX. Animo a todos a probarlo, así esta discusión sería menos teórica. Después de la curva de aprendizaje superficial inicial, se vuelve muy natural (y no se trata solo de la cantidad de caracteres, porque las etiquetas de cierre le permiten leerlo más fácilmente). No es diferente de aprender cualquier otra cosa nueva, como Flutter, que a la larga aumenta la productividad. Y estoy de acuerdo en que no es para todos, por lo que sería opcional.
Creo que es importante tener en cuenta que tenemos en mente los mejores intereses de los demás, lo que facilita la creación de cosas. Creo que este transpiler ayudaría y sería más fácil de adoptar si tuviera apoyo oficial.

Además, gracias @cbazza :)

@yuriy-manifold

No creo que nadie aquí dude de que JSX React es una mejora con respecto al clásico React. Pero como dije, esa solución se creó debido a problemas relacionados con las propiedades de la plataforma subyacente. Flutter no tiene estas propiedades.

La pregunta no es '¿JSX es útil para React?' la pregunta es '¿algo como JSX es útil para Flutter?'.

Creo que la respuesta es no.

Hay algunas otras cosas a considerar:

• Separar la especificación de diseño del código de la aplicación puede hacer que el código esté más preparado para el futuro; por ejemplo, esta propuesta de sintaxis de Dart 2 no afectaría a los métodos build si se transformaran de acuerdo con un pragma actualizable en código Dart desde un formato agnóstico como JSX.
• Definir el diseño como marcado hace posible separar el motor de renderizado del motor de widgets (con estado/virtualizado) al estilo de la relación de React con ReactDOM y React Native, lo que podría facilitar la transferencia de widgets a nuevas plataformas.
• Definir el formato de marcado facilita la transferencia de diseños existentes a Flutter, por ejemplo, desde Sketch u otras herramientas de diseño.

Buen trabajo con el transpiler cbazza

@Rockvole , gracias.

Agradezco su trabajo para la comunidad y las personas que quieren crear interfaces de usuario de esa manera, pero realmente espero nunca verme obligado a usar algo así en Flutter :-(((

@zoechi , gracias. Sí, es solo otra opción para las personas que aman JSX. Si eso no es lo tuyo, sigue haciendo lo que estás haciendo, ahí no cambia nada.

No creo que sea necesario inventar una nueva sintaxis JSX para admitir patrones de Flutter.

@alexkrolick , sí, puede usar accesorios de representación para los parámetros nombrados, pero no hay nada que pueda hacer con los parámetros posicionales. La clave era que no quería codificar nada en el transpiler para que funcionara para todo.

Sigo pensando, como recién llegado a Flutter con algo de experiencia con Angular, React, etc., que la forma normal de Dart, y más en Dart 2.0, es mejor que este DSX. Simplemente tiene más sentido que algunos parámetros XML y CSS-ish.

@tenhobi , gran uso que luego, obviamente, DSX no es para todos.

Si pudiera elegir, me quedaría con el modelo actual.

@b-strauss, esto no es un reemplazo, es una opción para las personas a las que les gusta JSX.

Hay amor y odio, pero la mayoría de las opiniones divergen sobre la utilidad de JSX sobre Dart simple.

@lukaspili , DSX es para personas nativas de React que aman JSX, si no ve sus beneficios, no lo use. No es DSX versus simple Dart. Es DSX vs. JSX, cuanto más cerca estén los 2, mejor.

La buena noticia es que incluso si esto fue adoptado por el equipo de Flutter (que probablemente no se base en este hilo), nadie se vería FORZADO a usarlo. Es una OPCIÓN. No entiendo por qué es tan emocional que a algunas personas les guste escribir código con una sintaxis que no les gusta...

@tehfailsafe , gracias por escuchar!!! Has dado en el clavo por qué tanta resistencia a algo que hará que la gente de React Native esté realmente feliz.

No me importa lo que les guste o no les guste a otras personas. Pero me importan las características que me ayudan a progresar con mi aplicación. Los recursos son limitados y preferiría tener un reproductor de video/transmisión adecuado, vistas nativas para niños y algún formato de gráficos vectoriales.

@b-strauss, una vez que los fanáticos de React Native se cambien a Flutter, habrá toneladas de personas para ayudar en estas otras cosas necesarias. La prioridad 1 es robar la participación mental de React Native y hacer que sea lo más simple posible para que las personas de React Native se trasladen.

Flutter, por otro lado, no tiene lenguaje de marcado. Todavía tengo que ver una razón para invertir recursos en algo que sea menos dinámico y menos expresivo.

@b-strauss, ¿Cómo es DSX 'menos dinámico' y 'menos expresivo' que el simple Dart? DSX es Dart, ¿no probaste el transpilador?

@yuriy-manifold, gracias.

La pregunta no es '¿JSX es útil para React?' la pregunta es '¿algo como JSX es útil para Flutter?'.

@b-strauss, por supuesto que lo es. no es útil para los desarrolladores actuales de Flutter, pero es muy útil para los diseñadores que pueden generar CSS desde sus herramientas, es muy útil para las personas con experiencia en la plataforma React Native.

@alexkrolick , muy buenas observaciones.

@cbazza

esto no es un reemplazo, es una opción para las personas a las que les gusta JSX.

Lo entiendo... No me afectaría de esa manera, pero como dije antes, faltan funciones en este momento que necesito para crear una aplicación flutter.

Una vez que los fanáticos de React Native se cambien a Flutter, habrá toneladas de personas para ayudar en estas otras cosas necesarias. La prioridad 1 es robar la participación mental de React Native y hacer que sea lo más simple posible para que las personas de React Native se trasladen.

Entonces, ¿propone que el equipo de flutter suspenda las funciones por algo que es cuestionable y puede o no atraer a una fracción de un subconjunto específico de desarrolladores web?

¿Cómo es DSX 'menos dinámico' y 'menos expresivo' que Dart simple? DSX es Dart, ¿no probaste el transpilador?

Cada DSL es, por definición, menos expresivo que una GPL. Con DSX, ¿cómo escondo condicionalmente un widget? ¿Cómo itero sobre una colección y mapeo cada elemento a un widget? ¿Cómo uso un interruptor? Ahora debe inventar la sintaxis y la semántica de las construcciones que ya tiene en su GPL. Entonces, ¿por qué inventar el DSL en primer lugar?

por supuesto que lo es. no es útil para los desarrolladores actuales de Flutter, pero es muy útil para los diseñadores que pueden generar CSS desde sus herramientas, es muy útil para las personas con experiencia en la plataforma React Native.

Esa no era la pregunta... ¿Qué problemas resolvería un DSL que no puedes resolver ahora? Sigues diciendo que es mejor, ¿por qué es mejor? No tengo dudas de que DSX atraería a algunas personas de JSX. Sé que a la gente no le gustan las cosas que son diferentes. Y la familiaridad parece ser el único argumento. Entonces, ¿por qué no usar CSS?
¿Por qué no usar JavaScript? Más personas saben cómo usarlos que Dart.

Si diseña su sistema en base a alguna otra cosa con el único propósito de ser familiar, en realidad no está innovando.

@b-strauss para ser claros, JSX compila llamadas a funciones (en llamadas React a createElement(ComponentClass) , en Dart deberían ser constructores).

<A property="a" />
new A(property: a)

<A property="a">
  <B />
  <C />
</A>
new A(property: a, children: <Widget>[new B(), new C()])

Las únicas construcciones son las transformaciones entre los nombres de los elementos+atributos y las llamadas de función+argumentos, y las expresiones escapadas ( {...} ).

• Con DSX, ¿cómo escondo condicionalmente un widget?

(JS)
  { condition && <A /> }
  { condition ? <A /> : <B /> }

• ¿Cómo itero sobre una colección y mapeo cada elemento a un widget?

(JS)
  { ['a', 'b'].map(i => <A property={i} />) }

• ¿Cómo uso un interruptor?
  Por lo que sé, en Dart como en JS, no puede usar un interruptor en línea ya que no es una expresión. Si está fuera del árbol de widgets, puede usar un interruptor normalmente.

Entonces, ¿propone que el equipo de flutter suspenda las funciones por algo que es cuestionable y puede o no atraer a una fracción de un subconjunto específico de desarrolladores web?

@b-strauss, React Native no es desarrollo web, es desarrollo móvil multiplataforma que es el principal competidor de Flutter; y sí, JSX es como una fuente de luz, atraerá a muchos desarrolladores de React Native. Pedí esta función en agosto de 2017, demasiadas palabras y poca acción.

Cada DSL es, por definición, menos expresivo que una GPL. Con DSX, ¿cómo escondo condicionalmente un widget? ¿Cómo itero sobre una colección y mapeo cada elemento a un widget? ¿Cómo uso un interruptor? Ahora debe inventar la sintaxis y la semántica de las construcciones que ya tiene en su GPL. Entonces, ¿por qué inventar el DSL en primer lugar?

Estás completamente equivocado. La buena noticia es que yo también me equivoqué una vez. La mayoría de los DSL (pero no todos) intentan recrear construcciones de programación en el marcado (y eso no es muy poderoso), JSX trae el marcado a la programación (aprovechando al máximo el lenguaje host). La diferencia es transformacional. La respuesta a todas sus preguntas es básicamente usar la forma en que lo hace en Dart porque es Dart. Todo lo que está entre '{}' es código Dart con la excepción del operador de propagación. Son todas expresiones de dardos, pero también puede usar funciones anónimas que devuelven una expresión. Como ves en el transpiler una etiqueta (\) es solo una novedad en un widget (texto nuevo()).

¿Qué problemas resolvería un DSL que usted no puede resolver en este momento?

¿Por qué usar Dart cuando puedes usar ceros y unos? ¿No es eso todo lo que se necesita para resolver cualquier problema de computación?

Sigues diciendo que es mejor, ¿por qué es mejor?

Di mis razones antes y no las repetiré aquí. La gente de JSX estará de acuerdo conmigo pero 'cada uno por su cuenta'.

No tengo dudas de que DSX atraería a algunas personas de JSX. Sé que a la gente no le gustan las cosas que son diferentes. Y la familiaridad parece ser el único argumento. Entonces, ¿por qué no usar CSS?
¿Por qué no usar JavaScript? Más personas saben cómo usarlos que Dart.

Sí, usar CSS tiene sentido para facilitar el flujo de trabajo del diseñador-desarrollador. DSX lo admite. La ventaja de Dart sobre Javascript es la velocidad de ejecución (rendimiento).

Si diseña su sistema en base a alguna otra cosa con el único propósito de ser familiar, en realidad no está innovando.

Estás tan lleno de prejuicios erróneos que lo más probable es que te impidan alcanzar tu máximo potencial. Abre tu mente, prueba cosas diferentes.

@alexkrolick , gracias por los detalles.

@cbazza

Estás tan lleno de prejuicios erróneos que lo más probable es que te impidan alcanzar tu máximo potencial. Abre tu mente, prueba cosas diferentes.

Me daré de baja de este problema ahora. Por favor, no vuelvas a mencionarme aquí ni en ningún otro lugar, gracias.

@b-strauss

Lo siento chico, no quise herir tus sentimientos... Solo estaba tratando de guiarte suavemente mientras trataba de manejar mis propias frustraciones. Todos somos humanos después de todo.

@cbazza ¿Puedes enviarme un correo electrónico, por favor? [email protected]

Ya hice esta propuesta en el hilo anterior, pero sigo pensando que es un punto importante.

En mi humilde opinión, eliminar la necesidad de usar new/const ya ayudó mucho. Tengo verdaderas dificultades en la forma en que el formato de dardo da formato a los árboles. en mi humilde opinión, no enfatiza lo suficiente la estructura de árbol en comparación con:

    return Scaffold(
      appBar: AppBar(title: Text("WeatherDemo")),
      resizeToAvoidBottomPadding: false,
      body: 
        Column(children: <Widget>
        [
          Padding(
            padding: const EdgeInsets.all(16.0),
            child: 
            TextField(
                    key: AppKeys.textField,
                    autocorrect: false,
                    controller: _controller,
                    decoration: InputDecoration(hintText: "Filter cities",),
                    style:  TextStyle(fontSize: 20.0,),
                    onChanged: ModelProvider.of(context).textChangedCommand,
                    ),
          ),

Estoy de acuerdo con el propósito de simplificar el aleteo que no quiere usar una sintaxis similar a JSX, y también apoyo el concepto de división en múltiples widgets, pero ahora siento que la era MVC está de vuelta en jquery. Tal escenario en el que había un widget simple, con relleno, borde y diseño central para más tarde, muchos símbolos "} " afectan seriamente la legibilidad. Sin embargo, es un widget integral, no quiero dividirlo, útil ¿solución? Aunque mi inglés es pobre, me esfuerzo por expresar mis pensamientos.

Señor, ayúdanos a todos.

Ok, esto no va a ninguna parte. No parece que nadie vaya a cambiar de bando en el corto plazo. Definitivamente necesitamos llegar a algún tipo de compromiso aquí. Por supuesto, "pro-DSX" frente a "anti-DSX" en realidad no tiene un compromiso ni remotamente satisfactorio, lo cual es una realidad frustrante. ¿Podríamos posiblemente replantear nuestras posiciones para que pudieran ser más compatibles?

@naiveaiguy "ellos" pueden tener su DSX.
Si el equipo de Flutter no lo implementa, puede ser una iniciativa de código abierto.
Eso no significa que el enfoque puro de Dart como ahora ya no funcionará.
Ambos mundos pueden coexistir.

Estoy muy de acuerdo con @zoechi en que pueden coexistir... eso es todo y pensé que esto se había resuelto en el hilo anterior.

@lrhn

Por favor, todos, sean civilizados y constructivos. Estamos discutiendo el estilo aquí, algo muy subjetivo, por lo que no importa cuánto le guste a cada uno su propia preferencia, es poco probable que sea inherentemente superior a la de los demás. Haga una lista de las ventajas y desventajas que ve con las sintaxis existentes y propuestas, pero recuerde que no todos lo ven de la misma manera, y eso está perfectamente bien.

Bravo, eso es absolutamente todo.

En React puedes hacerlo de 4 maneras (¡¡¡y acabo de enterarme de las otras 2 formas hoy !!!)

(1) Puedes usar JSX (que es lo que me gusta)
https://reactjs.org/docs/introducing-jsx.html

(2) Puedes usar la forma original (que es similar a Flutter)
https://reactjs.org/docs/react-sin-jsx.html

Al final del enlace de arriba incluso mencionan 2 proyectos comunitarios prometedores

(3) Sintaxis de hiperíndice para el marcado de React.js
https://github.com/mlmorg/react-hyperscript

(4) Sintaxis concisa para hiperíndice.
https://github.com/ohanhi/hyperscript-helpers

Tener alternativas es algo bueno, ya quedaron atrás los días en los que podías conseguir un Ford del color que quisieras, siempre que fuera negro :)

@naiveaiguy, ¿por qué es un problema para usted si existe el enfoque actual y DSX?
(eso es lo que deduzco de sus votos negativos)

@naiveaiguy "ellos" pueden tener su DSX.
Si el equipo de Flutter no lo implementa, puede ser una iniciativa de código abierto.
Eso no significa que el enfoque puro de Dart como ahora ya no funcionará.
Ambos mundos pueden coexistir.

Estoy totalmente de acuerdo con esto. Aunque creo que debería ser una solución enchufable en lugar de una solución lista para usar. Tener un estándar que funcione pero poder personalizar la experiencia con cosas adicionales es un gran paradigma. De esa manera, el equipo de Flutter puede mantener su enfoque en (lo que creo que son) problemas más relevantes, la comunidad puede experimentar con diferentes herramientas/soluciones y luego podemos tener una discusión con más datos y experiencia con DSX o cualquier otra alternativa a la actual. meta.

Tener alternativas es algo bueno, ya pasaron los días en los que podías conseguir un Ford en cualquier color que quisieras.
me gusta siempre y cuando sea negro :)

Eso es cierto. Sin embargo, creo que todos podemos estar de acuerdo en que no queremos que Dart/Flutter se convierta en otro ecosistema JS/Web Frontend. Flutter aún no ha salido de la versión beta y ya queremos que tenga 2 estándares para algo un poco subjetivo.

En React puedes hacerlo de 4 maneras (¡¡¡y acabo de enterarme de las otras 2 formas hoy !!!)

La mayoría están impulsados ​​por la comunidad, aunque React se refiere a ellos. Bien a mitad de camino. Ahora, solo 2 de ellos son oficialmente compatibles: el React.createElement y el modo JSX, que es un envoltorio sobre el otro. El valor de JSX es notorio en ese contexto, pero no está tan claro aquí. Con esto en mente, ¿podemos llegar a la mitad teniendo solo un estándar oficial y los documentos que hacen referencia a DSX siempre que sea relevante?

Creo que el equipo de Flutter debería centrarse en las características que faltan y que realmente impiden que los desarrolladores creen aplicaciones. No puedo recomendar Flutter a mis gerentes si ni siquiera podemos agregar compatibilidad con Maps y desarrollar funciones de cámara lleva 2 semanas.

Tenga en cuenta que no voy a cerrar la puerta a DSX para siempre. Tal vez se convierta en la solución para la construcción de la interfaz de usuario, pero necesitamos que la comunidad experimente con ella para tomar esa decisión.

@zoechi Personalmente, no creo que las dos ideas puedan coexistir en el estado actual de Flutter; realmente no deberíamos alentar una división de esta naturaleza tan pronto, pero en este punto parece el único compromiso.

@naiveaiguy

Personalmente, no creo que las dos ideas puedan coexistir en el estado actual de Flutter; realmente no deberíamos alentar una división de esta naturaleza tan pronto.

¿Podría ser más específico en cuanto a por qué no pueden coexistir? (dado el hecho de que DSX es solo azúcar sintáctico; o como dice @emalamela "solo un envoltorio de la forma actual").

Además, ¿por qué es demasiado pronto para proporcionar una sintaxis diferente para exactamente lo mismo? Básicamente, estoy preguntando por qué es necesario retrasar esto, ¿qué sería diferente en el futuro que aún no existe en este momento?

@emalamela

Sin embargo, creo que todos podemos estar de acuerdo en que no queremos que Dart/Flutter se convierta en otro ecosistema JS/Web Frontend.

Personalmente, prefiero no poner límites a lo que la gente puede hacer con Dart/Flutter. Deje que el mercado/la comunidad decida. Básicamente, si lo que se crea no agrega valor, la gente no lo usará y morirá. Si se vuelve popular es porque la comunidad lo encontró útil y lo valoró. No es necesario elegir ganadores y perdedores en este momento.

Lo único que me impide probar Flutter es el hecho de que optaron por no usar JSX.
En mi humilde opinión, JSX es la mejor opción para expresar la jerarquía de componentes

Escuché sobre Flutter, quería probarlo, e inmediatamente dejé de considerarlo en el momento en que vi la sintaxis, lo cual es una pena porque es probable que esta sea una gran pieza de tecnología. para construir productos.

He estado haciendo desarrollo de React/React Native durante los últimos 2,5 años, sacrificar el aprovechamiento de la productividad que ofrece la sintaxis JSX cuando se trata de describir la interfaz de usuario es mucho pedir. Consideraría seriamente pasar el tiempo para aprender todo sobre Flutter y estudiar si vale la pena cambiar cuando dicha función sea compatible de forma inmediata.

Ni siquiera puedo imaginar la cantidad de adoptantes/usuarios/desarrolladores potenciales que Flutter está perdiendo debido a esto, que volveremos a visitar en los próximos meses.

Ni siquiera puedo imaginar la cantidad de adoptantes/usuarios/desarrolladores potenciales que Flutter está perdiendo debido a esto, que volveremos a visitar en los próximos meses.

Sí, 44 Mio lo encontró lo suficientemente importante como para votar a favor: D

Sí, 44 lo encontró lo suficientemente importante como para votar a favor: D

Sin embargo, cuando se ordena por 'voto a favor', esta solicitud de función aparece en el séptimo lugar en la lista de 3131 tickets abiertos.

https://github.com/flutter/flutter/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

@cbazza No quiero argumentar en contra de la función, pero los comentarios como "si no haces x, horriblemente sucederá" son simplemente ridículos.

He estado haciendo desarrollo de React/React Native durante los últimos 2,5 años, sacrificar el aprovechamiento de la productividad que ofrece la sintaxis JSX cuando se trata de describir la interfaz de usuario es mucho pedir. Consideraría seriamente pasar el tiempo para aprender todo sobre Flutter y estudiar si vale la pena cambiar cuando dicha función sea compatible de forma inmediata.

@sonaye

Ya que mencionó la productividad, ¿puede proporcionar un ejemplo que muestre claramente la pérdida de productividad al usar Flutter's Pattern en lugar de JSX? El ejemplo debe construirse con la base de conocer suficiente JS y Dart para poder codificar dicho ejemplo. Creo que si no tenemos eso en cuenta, también estamos comparando lenguajes de programación, que no es la misma discusión.

Sin embargo, cuando se ordena por 'voto a favor', esta solicitud de función aparece en el séptimo lugar en la lista de 3131 tickets abiertos.

@cbazza

También es el más votado negativamente. Es bastante controvertido.

@emalamela ,

También es el más votado negativamente. Es bastante controvertido.

Dado que esta solicitud de función es una alternativa a la forma actual y no cambia la forma actual, no debería haber ninguna controversia en absoluto; si no le gusta JSX/DSX, continúe programando como lo hace hoy.

La llamada controversia solo existe porque el equipo de Flutter necesita trabajar para permitir que la comunidad haga DSX correctamente. Si las herramientas de Flutter (compilador, analizador, compatibilidad con ide, etc.) admitieran el preprocesamiento con mapas de origen, DSX se habría realizado hace mucho tiempo, y lo más probable es que también se hubieran producido otras innovaciones/ideas de lenguaje de desarrolladores externos.

new Card(
  child: Column(
    crossAxisAlignment: CrossAxisAlignment.start,
    children: <Widget>[
      AspectRatio(
        aspectRatio: 18 / 11,
        child: Image.asset('assets/diamond.png'),
      ),
      new Padding(
        padding: EdgeInsets.fromLTRB(16, 12, 16, 8),
        child: Column(
          crossAxisAlignment: CrossAxisAlignment.start,
          children: <Widget>[
            Text('Title'),
            SizedBox(height: 8),
            Text('Secondary Text'),
          ],
        ),
      ),
    ],
  ),
)

se convierte en:

<Card>
  <Column crossAxisAlignment={CrossAxisAlignment.start}>
    <AspectRatio aspectRatio={18 / 11}>
      <Image src={asset('assets/diamond.png')} />
    </AspectRatio>

    <Padding padding={EdgeInsets.fromLTRB(16, 12, 16, 8)}>
      <Column crossAxisAlignment={CrossAxisAlignment.start}>
        <Text>Title</Text>
        <SizedBox height={8} />
        <Text>Secondary Text</Text>
      </Column>
    </Padding>
  </Column>
</Card>

@emalamela El argumento a favor y en contra de JSX se ha agotado en la discusión, hay mucho material que puede consultar. Solo comparto mi opinión personal.

Primero, la legibilidad del código. Inmediatamente puedo obtener una idea clara y nítida sobre la estructura de la interfaz de usuario en JSX (toma unos segundos), el modal mental es muy visual. En segundo lugar, la usabilidad. Yo diría que JSX se puede usar incluso sin conocer JS/Dart ni nada sobre la API subyacente. Esto es muy adecuado para alguien que recién está aprendiendo programación, o para alguien que es parte de mi equipo, los diseñadores ahora pueden codificar la interfaz de usuario.

La descripción de la aplicación es completamente declarativa (no solo expresiva), cuando trabajas en un proyecto grande con cientos de componentes, esta forma de describir la interfaz de usuario hace una gran diferencia (tienes que probarla para realmente apreciarla). No me gustó JSX cuando lo vi por primera vez, una vez que lo usé me sentí bien, así es como quiero describir la interfaz de usuario de ahora en adelante, fue un claro avance en la forma en que enfoco la creación de interfaces.

No se trata de escribir menos líneas de código, no se trata de tener un "azúcar de sintaxis", se trata de construir herramientas para humanos. También estoy en contra del argumento de que todos deberían usar JSX, esto es ridículo. Usas la herramienta que te permite hacer tu trabajo más rápido con menos confusión, en el caso de muchos (incluyéndome a mí), sería JSX (o DSX en el caso de Flutter), eso es todo.

Vengo de React, y es la primera vez que pruebo Flutter. Es realmente extraño que el equipo de flutter no tenga sintaxis JSX, ¡lo digo en serio! ¡En el mundo de JS, JSX es extremadamente frecuente en todas las alternativas de React hoy en día! JSX es súper amigable para los desarrolladores. Implemente esto lo antes posible, para que pueda ayudar a hacer crecer la comunidad.

Puede darse cuenta de que JSX (o DSX en este caso) es un gran problema con solo mirar la cantidad de comentarios en este número.

JSX es algo que no sabes que amas hasta que lo pruebas. Es extraño al principio tener marcado en tu código, pero luego se vuelve increíble.

Parece innecesario para los chicos que ya saben flutter/dart, lo entiendo. Pero para alguien que nunca tocó el dardo (como yo), JSX es mucho más fácil para comenzar y ese es el punto. Si quieren que venga más gente y empiecen a construir cosas mucho más asombrosas, las herramientas deben ser más sencillas.

Y, como @eseidelGoogle (https://youtu.be/h7HOt3Jb1Ts?t=2m41s) le dijo al otro tipo: "Flutter es una forma de escribir en iOS y Android en una sola base de código. Intentamos que sea rápido y fácil [. ..] Flutter habla todo el camino hasta el hardware [...] Tenemos un enfoque muy estratificado, por lo que puede tomar tanto o tan poco como desee. [...] Tenemos una gran inversión en herramientas ."

Implemente JSX, bastante por favor.

Soy fanático de Dart y también un gran usuario de reaccionar. Siempre encuentro a Dart más breve y más fácil de mantener que JSX. Entonces, creo que JSX/DSX podría y tal vez debería implementarse de manera comunitaria.

@rajaraodv El hecho de que Flutter se promueva como un marco de estilo reactivo no significa que sea solo un sabor de ReactJS.
De la mayoría de los comentarios, tengo la impresión de que a la gente le cuesta aceptar que algo nuevo no es lo mismo que lo que ya conocen.

Podría intentar trabajar con Flutter por un tiempo tal como es actualmente y luego proporcionar los argumentos adecuados de por qué cree que JSX/DSX sería mejor que Dart simple de una manera objetiva en lugar de solo "por preferencia personal" o "porque es mejor" .

@zoechi , te estás perdiendo algo: flutter se inspiró en React, según el documento de Flutter.
Tal vez sea solo mi problema. Realmente siento que tengo dificultades para leer el código de la interfaz de usuario, incluso si está en la sintaxis de Dart 2.

flutter se inspiró en React Native

No veo cómo dice eso "todo es igual, excepto que el idioma se llama Flutter en lugar de JS".

Realmente siento que tengo dificultades para leer el código de la interfaz de usuario

¿Y afirma que la única solución imaginable para eso es DSX?

¿Has considerado que Flutter no es ni siquiera 1.0 y que el soporte IDE puede mejorar con el tiempo?

Solo se tomaron los primeros pequeños pasos recientemente para obtener una mejor compatibilidad con Flutter IDE en el editor de código, como arreglos rápidos ("wrap xxx") y etiquetas de cierre.

Hay posibilidades ilimitadas para mejorar la experiencia del desarrollador y la mayoría en esta discusión es como
"Flutter aún no es perfecto y, por lo tanto, necesitamos DSX"
generalmente sin argumentos concretos sobre cómo o por qué DSX resolvería o mejoraría eso.

@zoechi ,

Podría intentar trabajar con Flutter por un tiempo tal como es actualmente y luego proporcionar los argumentos adecuados de por qué cree que JSX/DSX sería mejor que Dart simple de una manera objetiva en lugar de solo "por preferencia personal" o "porque es mejor" .

Una vez más, Plain Dart o DSX es simplemente una cuestión de estilo, no tiene sentido discutir cuál es mejor. Es solo una preferencia personal y las personas tienen sus razones para elegir uno u otro.

Lo que sucedió en React World es que una vez que vas con JSX, simplemente no regresas. Como otros han dicho anteriormente, te enganchas a JSX después de usarlo por un tiempo. JSX ha sido adoptado por otros fuera de React's World (Typescript, Vue) y encaja perfectamente con Flutter.

¿Y afirma que la única solución imaginable para eso es DSX?

Lo que la comunidad necesita son capacidades genéricas de preprocesamiento con compatibilidad con mapas de origen integradas en las herramientas de Dart (compilador, analizador, IDE, etc.) para que la comunidad pueda desarrollar DSX o cualquier otra cosa mejor e integrarse completamente en Flutter (depurador, completa, etc.).

Hay posibilidades ilimitadas para mejorar la experiencia del desarrollador y la mayoría en esta discusión es como
"Flutter aún no es perfecto y, por lo tanto, necesitamos DSX"
generalmente sin argumentos concretos sobre cómo o por qué DSX resolvería o mejoraría eso.

Claro, la cosa es que este ticket no se trata de una cosa genérica de 'mejorar la experiencia del desarrollador'. Es muy específico y se trata de obtener soporte JSX en Flutter. La comunidad quiere DSX como una alternativa a la forma simple de Dart.

No me veo usando esto (pero estoy dispuesto a intentarlo). No creo que esto sea una bala de plata, pero hay tanto entusiasmo que vale la pena hacerlo.

Creo que Google debería eliminar los obstáculos del idioma para permitir que la comunidad construya lo que quiera.

No conozco ningún obstáculo que impida que alguien fuera de los equipos Flutter/Dart de Google escriba algo similar a JSX para Dart/Flutter. Me encantaría ver errores en esos si alguien lo está intentando. (También es posible que los haya perdido en los comentarios anteriores, ya que admito no haber leído cada palabra de este error tan largo). :)

¡Gracias! ¡Qué alegría ver tanto entusiasmo!

@eseidelGoogle ,

¿Cómo podrían Intellij y/o VS Code (con Dart-Code) establecer puntos de interrupción y recorrer el código de un archivo .dsx? (Quiero decir que esto no es un archivo .dart). ¿Qué hay de la funcionalidad de autocompletar desde el archivo .dsx (como con un archivo .dart)?

Ha invertido mucho en las herramientas, pero las herramientas no admiten el preprocesamiento (con mapas de origen) de un nuevo lenguaje (como DSX) que se transfiere a Dart/Flutter sin problemas.

Hay un transpilador disponible, pero no hay una manera fácil de integrarlo por completo:
https://chispa-heroku-dsx.herokuapp.com/index.html

PD ¡Este boleto es solo la mitad de los comentarios!
https://github.com/flutter/flutter/issues/15922

@cbazza , ¿hay un repositorio con ese compilador en alguna parte? Sería genial compartir el código e involucrar a la comunidad en hackearlo, incluso si no es perfecto.

@jonahwilliams , no, el código transpiler DSX no se ha publicado porque es demasiado pronto para eso.
Simplemente puede usar 2 archivos equivalentes escritos a mano (.dsx y .dart) para probar capacidades de preprocesamiento como puntos de interrupción, pasos, autocompletar, etc.

Una vez que las herramientas admitan el preprocesamiento con algún tipo de mapas de origen, puedo agregar eso al transpiler y desbloquearlo. Esto también permitiría a otros experimentar los deseos de sus corazones.

No trabajo en Flutter, pero parece poco razonable exigir ciertas herramientas para beneficiar a otros, y luego negarme a publicar cualquier código fuente inicial o ejemplos de con qué quieres que se integren las herramientas.

Por lo que vale, no conozco ningún lenguaje o kit de herramientas que proporcione ganchos de preprocesamiento de ningún tipo, probablemente porque simplemente no es fácil, hay muchos casos de esquina y suposiciones en torno al lenguaje y la sintaxis.

Si generó mapas de origen (https://pub.dartlang.org/packages/source_maps), imagino que obtener al menos algún soporte básico en un IDE es bastante trivial, independientemente de Dart/Flutter. Pero, de nuevo, todo esto son conjeturas sin saber qué hace su herramienta y cómo espera que funcione.

@matanlurey , admitir el procesamiento previo a través de mapas de origen es un mecanismo genérico que no depende de ningún transpilador específico. Es una funcionalidad que está destinada a admitir cualquier lenguaje futuro imaginable. El navegador/depurador Chrome lo admite bastante bien y puedo depurar cualquier idioma que se transfiera a JS.

Para las pruebas, puede crear cualquier tipo simple de transpilador para mostrar cómo usar los mapas de origen. Por ejemplo, escriba un transpiler trivial que genere código Dart/Flutter con una línea en blanco entre cada línea del archivo original. (.d2 => .dart, .d2 es un archivo Dart/Flutter, el archivo .dart contendrá una línea en blanco entre cada línea del archivo original).

Sí, puedo trabajar en generar un mapa fuente para un archivo de prueba.

Actualmente, Flutter es reacio a tratar de complacer a NativeScript, ReactNative, Android, Web y otros desarrolladores que están acostumbrados a diseños XML similares. Tienen cosas más importantes que hacer, así que separémonos y vayamos a dormir.

Deseaba que Amy, defensora de la sintaxis JSX, pasara algunos días realmente trabajando con Flutter antes de continuar lamentándose. Vengo de un sistema basado en Xaml, pero me acostumbré rápidamente. Solo pruébalo de verdad.

@escamoteur
Oye, escamoteur. ¿Crees que no he pasado mucho tiempo aprendiendo aleteo?
En flutter.io/tutorials/layout/, al final de la sección "Packing widgets", el código que dio el tutorial no funciona.
Mencioné el problema en el bloque de problemas de aleteo, pero nadie quiere preocuparse por esto.

• Código de dardo: main.dart
  https://raw.githubusercontent.com/flutter/website/master/_includes/code/layout/pavlova/main.dart

• Pubspec: pubspec.yaml
  https://raw.githubusercontent.com/flutter/website/master/_includes/code/layout/pavlova/pubspec.yaml

• https://flutter.io/tutorials/layout/

@JonathanSum , ¿hay alguna conexión entre su comentario y el tema de este problema?

@zoechi
escamoteur dijo que espera que el defensor de la sintaxis JSX solo pase algunos días trabajando realmente con Flutter antes de continuar lamentándose.
Este comentario muestra que realmente hemos pasado muchos días trabajando con Flutter, y la solicitud de JSX es realmente nuestro sentimiento de corazón.

Group Dart: "La sintaxis de Dart es mucho mejor y JSX/DSX simplemente no es bueno"
Grupo JSX/DSX: "La sintaxis de JSX/DSX es mucho mejor y Dart simplemente no es bueno"

¿No puedo ser la única persona que vea esto? Ambos lados hacen puntos válidos a favor y en contra de su posición. Creo que lo que se pierde aquí es que @cbazza no solo tuvo críticas SINO QUE TAMBIÉN HIZO ALGO AL RESPECTO. Tratando de cerrar la brecha entre los desarrolladores web/react/react-native y flutter para beneficiar a Flutter.

Y mis 2 centavos... Como desarrollador de pila completa, tengo experiencia con una amplia gama de lenguajes y enfoques... JSX es una de mis formas favoritas de escribir código y espero que haya una sintaxis alternativa a Darts... Y no digo que la sintaxis actual sea mala, es solo que prefiero el estilo JSX.

Tengo que estar en desacuerdo con esta cita del Grupo JSX/DSX

Dart simplemente no es bueno

Dart es un lenguaje muy bueno y robusto, nadie menosprecia el lenguaje. La discusión no se trata de Dart, sino de una capa sintética encima que la mayoría de los desarrolladores de UI ya usan hoy, y estamos proponiendo que Flutter incorpore algo así.

• Android tiene diseños XML.
• iOS tiene Storyboard XIB (XML)
• GTK+ tiene XML para Pango, etc.
• Qt tiene QML (como YAML)
• Xamarin tiene XAML

La mayoría de estos marcos y lenguajes tienen lenguajes de marcado de interfaz de usuario que separan la vista de la lógica del controlador. Luego, React viene con un enfoque diferente (que estamos proponiendo aquí) y creo que tenemos que estar de acuerdo en que RN está volando en este momento en términos de crecimiento de usuarios y popularidad, y puedo estar equivocado, pero principalmente debido a JSX.

...

¿Es realmente una propuesta tan loca que tenemos que recibir este tipo de comentarios del equipo/usuarios de Flutter?

@birkir y todos ellos traen una serie de problemas que Flutter no tiene \o/
No hay necesidad de otro idioma.
También puedes separar la vista en Flutter, incluso con el mismo idioma.

@birkir este hilo es 100% sobre Dart y sintaxis.

La discusión no se trata de Dart, sino de una capa sintética encima que la mayoría de los desarrolladores de UI ya usan hoy, y estamos proponiendo que Flutter incorpore algo así.

Entonces, no se trata de Dart... pero ¿Flutter necesita usar algo además de Dart para los diseños? ¿Parece que dices que Dart no es lo suficientemente bueno y al mismo tiempo afirmas que esto no tiene nada que ver con Dart?

No creo que importe en este punto, el equipo de Flutter ha visto estos comentarios (sobre la solicitud de un enfoque JSX/DSX) y quieren continuar por su camino original. Creo que podría manejarse mejor, pero no parece que se opongan a que la comunidad cree soluciones.

Estoy feliz de que haya otra opción multiplataforma... ¿Será Apple el próximo en ofrecer algo? ¿Y tal vez vean lo que a muchos de nosotros nos gusta de react/react-native? IDK si tienen algo cocinando.

el equipo de Flutter ha visto estos comentarios (sobre la solicitud de un enfoque JSX/DSX) y ellos

Este error aún está abierto porque no hemos descubierto qué queremos hacer aquí. Estamos ansiosos por ver los experimentos (p. ej., los de cbazza) para ver cómo los usa la gente. Estamos planeando, en algún momento, proporcionar un gancho en el sistema de compilación para herramientas de generación de código como esta, aunque no es algo que probablemente hagamos en un futuro cercano. A largo plazo, esperamos usar lo que aprendemos aquí para influir en el desarrollo de Dart como lenguaje. Esto podría significar agregar algo como E4X/H4X/JSX/DSX a Dart. O tal vez aprendamos que nadie realmente termina usándolo, así que no haremos nada. O tal vez todos necesiten algo diferente, por lo que la respuesta son ganchos de generación de códigos y paquetes personalizados como los de cbazza. Todavía no lo sabemos.

@jstansbe : Apple cree que multiplataforma significa iPhone, iPad y Mac OS. Es más probable que agreguen torretas en la parte superior del jardín amurallado que construyan algo entre plataformas :)

Creo que si fuera posible sangrar y formatear el widget de otra manera, sería más similar a jsx y amigable para los usuarios que tienen experiencia con xml y html (casi todos los desarrolladores de Android) ... verifique este código en codelab

return new Container(
    margin: const EdgeInsets.symmetric(horizontal: 8.0),
    child: new Row(
      children: <Widget>[
        new Flexible(
          child: new TextField(
            controller: _textController,
            onSubmitted: _handleSubmitted,
            decoration: new InputDecoration.collapsed(
              hintText: "Send a message"),
          ),
        ),
        new Container(                                                 //new
          margin: new EdgeInsets.symmetric(horizontal: 4.0),           //new
          child: new IconButton(                                       //new
            icon: new Icon(Icons.send),                                //new
            onPressed: () => _handleSubmitted(_textController.text)),  //new
        ),                                                             //new
      ],
    ),
  );

revisa este código dart to jsx

<Container margin="">
   <Row>
       <Flexible>
            <TextField   controller=""
                                onSubmitted=""
                                decoration="">
                 <OtherWidget></OtherWidget>

            </TextField>
        </Flexible>
   </Row>
</Container>

y compara con este otro formato mas htmlish

  return Container(margin: const EdgeInsets.symmetric(horizontal: 8.0), child:
            Row(children: <Widget>[
                Flexible(child:
                    TextField(controller: _textController,
                              onSubmitted: _handleSubmit,
                              decoration: new InputDecoration.collapsed(hintText: "manda un mensaje"),),
                    ),
                Container(margin: const EdgeInsets.symmetric(horizontal: 4.0),child:
                     IconButton(icon: Icon(Icons.send),
                               onPressed: ()=>_handleSubmit(_textController.text),),)
              ],
            )
    );

esto es un poco más similar y ahora solo necesita ver de izquierda a derecha para notar los diferentes widgets similares a html/xml/jsx

los atributos del elemento (widget) tienen más sangría que los nuevos widgets, por lo que esto hace más claro que se puede entender y verificar el código

sería genial si pudiera tener una sangría automática para este formato en los diferentes idus, ahora mismo lo hago a mano....

Después de leer todos los comentarios aquí y discutir en privado con mis amigos (desarrolladores nativos de aplicaciones móviles, chicos de java/kotlin/objective-c/swift), mi observación:

La gente está pidiendo dos cosas,

• __Mejor legibilidad y escritura más fácil__. El anidamiento profundo mezclado con algunos ruidos de sintaxis (paréntesis, punto y coma, new , child , children ) es molesto en la forma actual de codificación.
• __Separe el estilo/diseño del código__. La separación visual es buena para la lectura (diferenciar el estilo del código imperativo de un vistazo) y una separación real es buena para las herramientas (por ejemplo, IDE con el editor de diseño).

También hay principalmente dos grupos con opiniones diferentes,

• Mejorar la sintaxis actual sin introducir otra complejidad para solucionar el problema.
  Ya ha habido algunas mejoras en esta dirección. Por ejemplo, new , const opcionales en Dart 2.0 y la función propuesta virtual "closing tag" comments .
• Introducción de lenguajes de marcado adicionales (como JSX o XML) para resolver el problema.

No se puede concluir fácilmente cuál es mejor en la actualidad. Así que deje que la comunidad haga sus experimentos primero y tome la decisión final (aceptar o rechazar) más tarde.

Los comentarios de etiqueta de cierre virtual de @hooluupog ya funcionan en IntelliJ, AS, VSCode desde hace un tiempo

@Hixie

Este error aún está abierto porque no hemos descubierto qué queremos hacer aquí. Estamos ansiosos por ver los experimentos (p. ej., los de cbazza) para ver cómo los usa la gente.

Las personas no pueden usar mis experimentos porque no se pueden integrar sin problemas en este momento en Flutter; por lo que sigue siendo un experimento externo/en línea donde las personas solo pueden ver el potencial.

Estamos planeando, en algún momento, proporcionar un gancho en el sistema de compilación para herramientas de generación de código como esta, aunque no es algo que probablemente hagamos en un futuro cercano. A largo plazo, esperamos usar lo que aprendemos aquí para influir en el desarrollo de Dart como lenguaje.

¿Puede ser más específico en cuanto a cuándo podemos esperar algún movimiento en los cambios del sistema de compilación para admitir el preprocesamiento? ¿Estamos hablando de un mes, un trimestre, seis meses, un año, 2 años, una década, un jubileo, etc.

Esto podría significar agregar algo como E4X/H4X/JSX/DSX a Dart.

Lea los párrafos superiores de las especificaciones de JSX para ver que no es necesario cambiar el lenguaje de Dart, ya que JSX/DSX no tiene semántica y no está diseñado para ser implementado por motores ni incorporado en lenguajes. Está destinado a ser utilizado en un preprocesador (transpiler). DSX podría usarse con Flutter & on Web para hacer que React-Dart sea exactamente igual a React.js pero con el lenguaje Dart.

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

O tal vez aprendamos que nadie realmente termina usándolo, así que no haremos nada.

¿Cómo pueden las personas usar algo que no está disponible para que lo usen en primer lugar y luego concluir que no es necesario hacer nada porque las personas no lo están usando? Esto me recuerda mucho a la personificación de Sean Spicer de Melissa McCarthy en SNL sobre la 'prohibición de viajar'... 'uso circular de la palabra' :)

https://www.youtube.com/watch?v=1Dvo6EHEJQE&t=48s

O tal vez todos necesiten algo diferente, por lo que la respuesta son ganchos de generación de códigos y paquetes personalizados como los de cbazza. Todavía no lo sabemos.

Las capacidades de preprocesamiento son muy necesarias para permitir la experimentación. Sin ella nada avanza y no aprenderás nada nuevo.

La gente no puede usar mis experimentos.

Creo que subestimas lo dispuesta que está la gente a probar cosas, incluso cuando no están completamente pulidas. Por ejemplo, alguien podría escribir fácilmente un script de shell que envuelva flutter run para realizar el preprocesamiento primero y luego llamar a flutter run . Yo mismo tengo un script que envuelve la recarga en caliente para hacer algo similar (primero ejecuto el analizador, luego, solo si pasa, envío la señal de recarga en caliente al script flutter ).

¿Puede ser más específico en cuanto a cuándo podemos esperar algún movimiento en los cambios del sistema de compilación?

No realmente (consulte, por ejemplo, https://en.wikipedia.org/wiki/Forward- looking_statement para saber por qué podría ser difícil hacer tales declaraciones), pero probablemente no en las próximas semanas.

no hay necesidad de cambiar el idioma de Dart

Eso es bastante posible, de hecho. Solo digo que en base a estos experimentos, podemos llegar a cualquier cantidad de conclusiones, desde "no hacer nada" hasta "agregar nuevas características radicales a la sintaxis del lenguaje" y cualquier cosa intermedia. El punto es que aún no hemos tomado ninguna decisión y estamos muy abiertos a aprender lo que se debe hacer en función de todas estas discusiones y experimentos.

¿Agregar JSX a la cartera de pedidos y dejar que compita, al estilo gladiador, con los más de un millón de otros requisitos urgentes?

React está escrito para la web y, por lo tanto, necesita una solución simple para escribir HTML. JSX no se volvió popular porque es la mejor solución para escribir interfaces de usuario, sino porque es la mejor solución para escribir HTML.

Flutter no tiene esa restricción, por lo que no deberíamos conformarnos con una solución mediocre y detallada por las razones equivocadas.

Si queremos reducir la verbosidad, prefiero inspirarme, por ejemplo, en Anko (https://github.com/Kotlin/anko/wiki/Anko-Layouts). Allí puede definir nuevas variables locales en cualquier lugar y usar bucles for normales para construir dinámicamente la lista de elementos secundarios, lo que puede hacer que el código sea más fácil de seguir. Además, LayoutBuilder se volvería más fácil a la vista ya que cada nivel de anidamiento ya es una función lambda de todos modos (no es necesario pasar un constructor lambda adicional). De todos modos, esto es solo como inspiración y no creo que Flutter deba copiar eso 1:1.

React está escrito para la web y, por lo tanto, necesita una solución simple para escribir HTML. JSX no se volvió popular porque es la mejor solución para escribir interfaces de usuario, sino porque es la mejor solución para escribir HTML.

React Native no es desarrollo web ni utiliza HTML. Pregunte a los desarrolladores experimentados de React (o lea completamente este y el otro hilo de JSX) y verá que muchos desarrolladores de React consideran que JSX es la mejor manera de escribir interfaces de usuario.

Allí puede definir nuevas variables locales en cualquier lugar y usar bucles for normales para construir dinámicamente la lista de elementos secundarios, lo que puede hacer que el código sea más fácil de seguir.

Esta declaración demuestra claramente que no conoce JSX. JSX (como en DSX) utiliza todas las construcciones de programación (for-loops, etc.) del lenguaje de alojamiento (Javascript/Dart).

Este ticket solo está interesado en la funcionalidad similar a JSX, para otros enfoques (como Anko), cree su propio ticket para discutirlo allí.

React Native no es desarrollo web ni utiliza HTML. Pregunte a los desarrolladores experimentados de React (o lea completamente este y el otro hilo de JSX) y verá que muchos desarrolladores de React consideran que JSX es la mejor manera de escribir interfaces de usuario.

React salió mucho antes que React Native. El diseño original de JSX se basa en renderizar HTML, no en interfaces de usuario nativas. Nadie ha podido mostrar un solo argumento convincente de lo que JSX hace mejor. Por comparación

new Scaffold(
  appBar: new AppBar(
    title: new Text(widget.title),
  ),
  body: new Column(
    child: ...,
  ),
)

a

<Scaffold
    appBar={<AppBar title={<Text>{widget.title}</Text>} />}
  >
  <Column>
    ...
  </Column>
</Scaffold>

no ha hecho una comparación actualizada y simplemente está poniendo más cosas en una sola línea. Debes compararlo con:

Scaffold(
  appBar: AppBar(title: Text(widget.title)),
  body: Column(
    child: ...,
  ),
)

Observe cómo desaparecen todas las etiquetas feas {<{<>} />} y </...> cierre.

Esta declaración demuestra claramente que no conoce JSX. JSX (como en DSX) utiliza todas las construcciones de programación (for-loops, etc.) del lenguaje de alojamiento (Javascript/Dart).

No, no puede usar sentencias if o bucles for (o switch o cualquier otra sentencia) dentro de JSX:

function render(data) {
  return (
    <div>
      // This is impossible
      let total = 0;
      for (let item of data.list) {
        total += item.value;
        <div>{ total }</div>
        <div>{ item.name }</div>
      }
    </div>
  )
}

Solo se permiten expresiones. Por lo tanto, debe usar operadores condicionales ( c ? x : y , lo que hace que else if sea ​​muy feo) y Array.map etc. (que también pueden ser muy feos) o mueva partes de su código al parte superior de la función de representación o en una función de ayuda independiente. Es lo mismo con Flutter, por supuesto. Anko no tiene esta limitación y hace que escribir (algunos) códigos de interfaz de usuario sea más natural.

Creo que en una discusión sobre la introducción de JSX es bastante válido y necesario preguntar si esa es realmente la mejor solución o si podemos encontrar algo mejor. De lo contrario, desperdiciaremos recursos en las tareas equivocadas.

React salió mucho antes que React Native. El diseño original de JSX se basa en renderizar HTML, no en interfaces de usuario nativas.

El diseño original de JSX se trata de una forma familiar de crear/manipular estructuras de árbol que aparecen especialmente cuando se trabaja en la interfaz de usuario; piense en las jerarquías de componentes (https://facebook.github.io/jsx/) que aparecen en el desarrollo web, el desarrollo nativo, cualquier desarrollo de interfaz de usuario, etc.

Nadie ha podido mostrar un solo argumento convincente de lo que JSX hace mejor.

Ese es el punto, no estamos buscando reemplazar la forma actual, estamos buscando agregar una forma alternativa que sea familiar para los desarrolladores de React.

Su propuesta de Anko sería familiar para los desarrolladores de Android Kotlin, así que proponga una especificación que funcione con la jerarquía actual de Flutter en un ticket separado. Una vez que vea (o pruebe una versión en línea de su especificación), podré ver si puede generar/interoperar con la jerarquía actual de widgets de Flutter.

No, no puede usar sentencias if o bucles for (o switch o cualquier otra sentencia) dentro de JSX:

No es que te recomiende hacer esto, pero es posible: crea una función anónima y llámala.

function render(data) {
  return (
    <div>
      { ()=>{
        // This is *not* impossible
        let divs=[];
        let total = 0;
        for (let item of data.list) {
          total += item.value;
          divs.push(<div>{ total }</div>);
          divs.push(<div>{ item.name }</div>);
        }
        return divs;
      }() }
    </div>
  )
}

Creo que en una discusión sobre la introducción de JSX es bastante válido y necesario preguntar si esa es realmente la mejor solución.

No existe la mejor solución, se trata de tener opciones, tener la opción de usar algo familiar que se asigne directamente a los widgets de Flutter y no agregue gastos generales.

Por cierto, intente lo siguiente en mi transpilador en línea en:
https://chispa-heroku-dsx.herokuapp.com/index.html

@<Scaffold>
  <appBar:AppBar>
     <title:Text [widget.title]/>
  </appBar:AppBar>
  <Column>
    {kids}
  </Column>
</Scaffold>@

y obtienes:

--------new Scaffold(
--------  appBar: new AppBar(
--------    title: new Text(
--------      widget.title,
--------    ),
--------  ),
--------  child: new Column(
--------    child: kids,
--------  ),
--------);

DSX es similar a JSX pero para Dart & Flutter, por lo que tiene características propias que se describen en el enlace anterior.

cuando veo esto, recibo flashbacks de los diseños xml de Android. No creo que sea una buena idea implementar esto. Ahora que ni siquiera tiene que escribir new y const incluso se ve mejor.

@charafau ¿Puede compartir un ejemplo/img/enlace de "diseños xml de Android" al que se refiere?

No, @wkornewald. Si "JSX no se hizo popular porque es la mejor solución para escribir interfaces de usuario, sino porque es la mejor solución para escribir HTML", ¿por qué React todavía usa JSX para crear una aplicación móvil y una aplicación de escritorio? Incluso su aplicación de escritorio Github, la aplicación móvil multiplataforma de Walmart, la aplicación Tesla y Skype también están creadas por RN.

React no coloca un bucle for en la etiqueta JSX porque el concepto de React se trata del componente. La parte superior es la lógica y la parte inferior es el JSX, y siempre es así. Todo está separado en muchos componentes y conectado entre sí en un gran componente.

De hecho, la mayoría de las personas aquí que están en contra de JSX solo pueden suponer que JSX es algún tipo de HTML, XML o una solución menos detallada.

@JonathanSum

la mayoría de las personas aquí que contra JSX solo pueden adivinar que JSX es algún tipo de HTML

Creo que es más bien porque no había otros argumentos a favor de JSX/DSX además de las preferencias personales. Eso está bien, por supuesto, como ya se mencionó anteriormente, pero no insinúe que las personas están en contra de JSX porque no lo entienden, cuando no hay una lista de buenos argumentos fácticos que muestren dónde JSX es mejor que Dart simple.

Creo que es más bien porque no había otros argumentos a favor de JSX/DSX además de las preferencias personales.

En realidad, no, muchos se dieron antes, solo lea completamente ambos hilos. Mencioné estas 2 cosas antes:
(1) No más cosas de 'niño' y 'niños'
(2) fácil de manipular para herramientas de terceros (analizar, analizar y regenerar)

Con (2) puede mejorar el marcado para hacer cosas que no son posibles solo con Dart; por ejemplo, el operador de propagación de DSX o la generación de muchos parámetros de función a partir de un conjunto más pequeño.

Otros han brindado muchos puntos buenos, pero no lo estoy investigando para ti;)

(1) como se mencionó, tales cosas también se pueden cambiar/mejorar en Dart y ya hubo discusiones. Esto simplemente no sucederá antes del lanzamiento de Dart 2.
Asumir que DSX permite todo tipo de funciones nuevas y Dart no, no es un argumento justo en mi opinión.
(2) Estoy bastante seguro de que esto también se puede hacer con Dart y, por supuesto, ya hay un analizador para Dart.

Otros han brindado muchos puntos buenos, pero no lo estoy investigando para ti;)

No hay necesidad de desenterrarlos para mí , pero esto surge con frecuencia y es posible que pueda convencer a otros de que realmente tiene argumentos válidos.
Seguí la discusión y no puedo recordar buenos argumentos fácticos y eso podría ser lo mismo para otros. Si los resume, puede simplemente publicar un enlace al siguiente que cuestione eso.

Como se discutió antes, puedo aceptar la preferencia personal como un argumento válido, pero si también afirma tener muchos argumentos fácticos, entonces creo que es válido pedir que se los señalen.

Sigues pidiendo 'argumentos válidos' y cuando te los dan los descartas como 'el futuro Dart tendrá esto' o 'este no es un argumento válido'.

El hecho es que, en este momento, Dart/Flutter tiene niños/niños ruidosos en todas partes cuando se crea un widget y XML/DSX no. En este momento, es un argumento muy válido para usar DSX para eliminar este ruido de niños/niños. ¿Puede aceptar eso como un argumento válido? (Solo porque dices que Dart tendrá eso en el futuro, no invalida el argumento).

También es un hecho que analizar XML es mucho más simple que analizar el lenguaje Dart completo y todos los lenguajes tienen un analizador XML, mientras que solo Dart tiene un analizador de lenguaje Dart completo y completo. ¿Puedes ver que este también es un argumento válido?

Hay muchos argumentos válidos, simplemente no son válidos para ti y es por eso que dejé de discutir sobre eso. Si las personas están interesadas en lo que se dijo, solo lea los 2 hilos en JSX por completo. No tengo ningún interés en convencerte de que uses DSX, estás contento con Dart, que así sea; No soy.

Argumentos para una sintaxis DSX opcional:

1) Incorpore y atraiga a más desarrolladores provenientes de React (web y nativo)
2) Mejor experiencia de portar componentes de React Native a widgets de Flutter
3) Impulsa la consistencia de las propiedades secundarias/secundarias en los widgets
4) Legibilidad del código (argumento de opinión)
5) Ver la pelusa lógica separada de la pelusa del dardo
6) Abre un mundo para las herramientas de creación de UI
7) Abre el ecosistema para los preprocesadores

DSX +1

DSX +1

Me hubiera encantado escribir un montón de pros y contras, pero al haber leído todos estos comentarios, siento que voy a repetir todo una y otra vez.
Deje de ser tan ingenuo e ignorante, nadie dice que se verá FORZADO a escribir interfaces de usuario usando DSX, es simplemente una opción (mejor alternativa).
Hay una razón por la que puedes escribir JS de 101203103 formas diferentes.

Bueno, siempre existe la opción de escribir un complemento de analizador que analice DSX y los convierta en llamadas regulares a funciones de Dart, para que el compilador no tenga que hacer ningún trabajo adicional.

La verdadera pregunta es si los complementos del analizador se aplican dentro del contexto del compilador.

Si me preguntas, DSX solo debería estar habilitado, idealmente a través de algún tipo de complemento. Creo que es extremadamente innecesario agregarlo al lenguaje en sí, ya que los usuarios web y del lado del servidor de Dart tienen que adaptarse a los cambios, no solo los usuarios de Flutter. La gran mayoría del código escrito en Dart no necesita ni remotamente ninguna sintaxis XML, por lo que imponerla a todo el mundo es una mala decisión.

TLDR; si desea tanto DSX, escriba un complemento de analizador y llévelo a Dart usted mismo. Internet te amará, obtendrás miles de estrellas de Github y te sentirás como si fuera React. ganar-ganar

PD Incluso te competiré para que lo hagas

Bueno, siempre existe la opción de escribir un complemento de analizador que analice DSX y los convierta en llamadas regulares a funciones de Dart, para que el compilador no tenga que hacer ningún trabajo adicional.

Actualmente, no hay forma en el lenguaje de dardos de implementar esto sin ningún truco (piense en las condiciones de carrera, las importaciones recursivas y esas cosas). Esto debe integrarse en un nivel en el que todo funcione como se espera, recarga en caliente, análisis estático, etc.

Si me preguntas, DSX solo debería estar habilitado, idealmente a través de algún tipo de complemento. Creo que es extremadamente innecesario agregarlo al lenguaje en sí, ya que los usuarios web y del lado del servidor de Dart tienen que adaptarse a los cambios, no solo los usuarios de Flutter. La gran mayoría del código escrito en Dart no necesita ni remotamente ninguna sintaxis XML, por lo que imponerla a todo el mundo es una mala decisión.

Si lees el hilo, esa ha sido la idea desde el primer día. Solo queremos el apoyo de flutter/dart para hacer un transpiler.

TLDR; si desea tanto DSX, escriba un complemento de analizador y llévelo a Dart usted mismo. Internet te amará, obtendrás miles de estrellas de Github y te sentirás como si fuera React. ganar-ganar

Lea el hilo, esto ya lo ha hecho @cbazza (el complemento del analizador no funcionará)

https://github.com/flutter/flutter/issues/11609#issuecomment-388484681

PD Incluso te competiré para que lo hagas

¡Estupendo! Incluso sería interesante ver una teoría de cómo funcionaría esto.

SGTM. Supongo que todos estamos esperando algún tipo de soporte de preprocesamiento, entonces.

Prefiero la sintaxis del constructor que pasar parámetros a través del constructor.

<strong i="6">@override</strong>
Widget build(BuildContext context) {
    return container()
      .height(56.0)
      .padding(8.0)
      .decoration(BoxDecoration(color: Colors.blue[500]))
      .child(text("Hello world!")
                   .style(...)
                  .build());
}

como en https://fblitho.com/

Text.create(context)
    .text("Hello World")
    .textSizeDip(50)
    .build();

DSX +1

Entiendo los argumentos a favor de JSX, pero creo que hay tantas personas (incluido yo mismo) que odian la idea de introducir XML en un lenguaje de programación. Simplemente se siente mal (pero entiendo totalmente que otros no se sientan de la misma manera).

Dado que es casi imposible quitar funciones una vez implementadas, sugeriría el principio de precaución. Veamos cómo se desarrollan algunas de las características de sintaxis más nuevas de Dart 2 antes de comprometernos con un cambio sustancial en la forma en que se crean las aplicaciones de Flutter.

@wstrange
Puedo entenderte. Solía ​​estar en contra de JSX y mezclar js con xml/html... luego lo probé. Después de pasar unos meses con reaccionar, me enamoré de JSX. Dos ventajas asesinas son:

1. sin sintaxis y utilidades nuevas
2. no más paso de variables, funciones, etc.

@wstrange ,

Dado que es casi imposible eliminar funciones una vez implementadas,

Eso no es un hecho, ¿quién hubiera pensado que Google eliminaría MathML de Chrome?

Veamos cómo se desarrollan algunas de las características de sintaxis más nuevas de Dart 2 antes de comprometernos con un cambio sustancial en la forma en que se crean las aplicaciones de Flutter.

No es un cambio en la forma en que se crean las aplicaciones de Flutter, es solo una forma alternativa que no cambia la forma actual y, lo que es más importante, es simplemente una sintaxis diferente a la biblioteca de clases. Un transpiler simple hace el mapeo sin necesidad de información de las clases de Flutter, por lo que funciona bien para el código de cualquier persona, así como para Flutter ahora y en el futuro.

@Bessonov ,

Sí, no conoce React hasta que pasa unos meses trabajando con él y luego se da cuenta de lo fenomenal que es una biblioteca para manejar jerarquías de componentes.

@cbazza Podría decir exactamente lo mismo sobre Flutter. Dedique algunas semanas a usarlo y no se perderá JSX.

La reacción nos lo dice todo.

Como ahora, +1 casi el doble -1

@escamoteur ,
Sí, es una declaración muy justa, pero he pasado mucho tiempo con Flutter y ciertamente puedo ver el valor que DSX le agregaría. Como @leedstyh ha notado, los fanáticos de DSX lideran la carrera por casi 2 a 1, lo cual es bastante sorprendente considerando que las personas en este foro son personas de Flutter.

Tengo una pregunta:

Cuando usamos la sintaxis DSX, asumimos implícitamente que el niño o los niños anidados son del tipo Widget. ¿Qué pasa si queremos indicar explícitamente que queremos que los niños/niños anidados sean un subtipo específico de Widget?

por ejemplo, cuando quiero que los elementos secundarios de mi widget personalizado solo acepten una lista de Contenedor, puedo anotar los elementos secundarios con List<Container> y el IDE generará un error tan pronto como coloque algo diferente de Contenedor. Como sé, no hay forma de hacer cumplir el tipo seguro como este cuando se usa dsx. Tal vez podamos tener algún error cuando la aplicación se compila, pero creo que el error aparece cuando estoy escribiendo sigue siendo una mejor experiencia.

Creo que deberíamos darles a todos algo de tiempo para probar y familiarizarse con la forma flutter de declarar la interfaz de usuario, al menos después del lanzamiento de v1. Entonces podríamos echar un mejor vistazo a esta característica.

@sandangel ,

Muy buena captura!!! Te lanzo mi sombrero virtual. Mi prototipo inicial ha tenido algunos agujeros desde el principio de los que era consciente y solo esperaba que la gente los encontrara y se presentara. Solo esperaba que la gente estuviera interesada en discutir la tecnología en lugar de pelear por ella.

La solución que tengo para esto es proporcionar el tipo de matriz como otro parámetro en el espacio de nombres. A medida que el espacio de nombres se hace más grande, podemos establecer que la forma abreviada de 'hijos' sea '*'.

En el Ejemplo 2 en https://spark-heroku-dsx.herokuapp.com/index.html , si las acciones fueran una matriz de 'Contenedor' en lugar del 'Widget' predeterminado, se vería como las siguientes alternativas:

        <actions:children:Container>
            <IconButton 
                icon={new Icon(Icons.search)}
                tooltip='Search'
                onPress={null}
            />
        </actions:children:Container>

        <actions:*:Container>
            <IconButton 
                icon={new Icon(Icons.search)}
                tooltip='Search'
                onPress={null}
            />
        </actions:*:Container>

hola @cbazza , gracias por tu respuesta.

Me pregunto acerca de su solución. ¿Estamos haciendo un mal uso del espacio de nombres xml como se describe en Espacios de nombres w3shool-XML ?

Como establece que el espacio de nombres se usa principalmente para resolver el conflicto de nombres en el documento XML.

Entonces, cuando alguien lea el XML anterior, podría pensar que está declarando una etiqueta de Contenedor bajo el espacio de nombres 'hijos' del espacio de nombres 'acciones', no que está imponiendo que todos los niños anidados deben ser un Contenedor. Me confunde cuando leo por primera vez la sintaxis de su propuesta sin leer la explicación anterior.

¿Podríamos tener algo mejor?

DSX no es XML, es similar a XML, por lo que no necesita seguir la semántica XML, algo así como el lenguaje de plantilla Angular;) De todos modos, siempre estoy abierto a mejores alternativas o sugerencias y me encantaría tener una discusión aquí.

Viniendo de React-native, primero apoyé la implementación similar a JSX, y no me gustaban los objetos anidados, ¡pero estoy empezando a disfrutar de OOP y veo todo como un objeto!

Para las personas que vienen de React-native, ¡recomiendo encarecidamente este complemento! https://marketplace.visualstudio.com/items?itemName=CoenraadS.bracket-pair-colorizer

@clarktank
¿Puede ampliar su experiencia con react-native (JSX), Flutter (OOP) y su viaje de uno a otro?

@cbazza Creo que la sintaxis de la plantilla angular sigue la semántica xml y, como sé, no existe un caso de uso de conflicto entre la sintaxis angular y el documento xml.

En mecanografiado, tenemos soporte para componente genérico .
Así que creo que podríamos tener algo como esto:

<children<Container>>
  <Container/>
</children>

Pero nuevamente, el componente genérico se usa para verificar el tipo de entrada de la propiedad. No sé si la sintaxis anterior tiene un significado semántico correcto en este caso de uso.

Realmente siento que el equipo de Flutter ha creado la API actual específicamente para la nueva forma de declarar la interfaz de usuario que supusieron que es mejor que JSX y cualquier esfuerzo que intentemos vincular la sintaxis de JSX a la API actual solo hace que parezca poco natural/incómodo de usar.

La reacción nos lo dice todo.

Como ahora, +1 casi el doble de -1

Esto no significa nada.

Excepto aquellos que están viendo todos los problemas de Flutter el doble del que llega a este problema porque ya están acostumbrados a JSX (y lo están buscando explícitamente). Así que esto significa más bien que _las personas que quieren una experiencia similar a JSX duplican a las personas que miran todos los temas que han votado -1_. (En mi humilde opinión, una parte de las personas que votan +1 ni siquiera han probado el aleteo)

@sandangel ,

Creo que la sintaxis de la plantilla angular sigue la semántica xml y, como sé, no existe un caso de uso de conflicto entre la sintaxis angular y el documento xml.

Claro, pero JSX no usa el espacio de nombres, por lo que no es una característica XML de interés.

<children<Container>>
  <Container/>
</children>

Dado que separaste los 'niños' fuera de acción en su propia etiqueta, me recuerda un poco a la nueva etiqueta Fragment de React. Es un equilibrio entre verbosidad y concisión, eso es seguro.

Realmente siento que el equipo de Flutter ha creado la API actual específicamente para la nueva forma de declarar la interfaz de usuario que supusieron que es mejor que JSX y cualquier esfuerzo que intentemos vincular la sintaxis de JSX a la API actual solo hace que parezca poco natural/incómodo de usar.

No hay nada nuevo en la forma en que Flutter declara la interfaz de usuario en el código. Quizás usar DSX no sea natural/incómodo para usted, pero para los desarrolladores de JSX no lo es. JSX/DSX es perfecto para Flutter, se ajusta como un guante y si no te gustan los guantes, ve con las manos desnudas;)

@a14n ,

Esto no significa nada.

seguro que sí !!! puede discutir con 'sentimiento', 'pensamiento', 'sospechoso', 'en mi humilde opinión', 'opinión', pero estos son datos, un punto de datos concreto. Si los datos son inútiles, no deben recopilarse. Supongo que los datos son inútiles porque no pintan tu imagen.

@cbazza Me refiero a que cuando estamos tratando de responder la pregunta que tengo arriba sobre la aplicación del subtipo de widget para niños/niños, creo que el código Dart está haciendo un mejor trabajo que JSX.

DSX no es XML, es similar a XML, por lo que no necesita seguir la semántica XML

Claro, pero JSX no usa el espacio de nombres, por lo que no es una característica XML de interés.

No estoy seguro, pero he leído algunos de sus comentarios anteriores y creo que ha mencionado el nodo JSX/XML indistintamente. De todos modos, personalmente creo que usar el espacio de nombres como solución no es lo ideal.

solo compara

<actions:children:Container>

</actions:children:Container>

y

actions: <Container>[]

sintaxis.

@sandangel ,

Sí, la sintaxis de etiquetado es más detallada para este caso y es por eso que mencioné que la forma abreviada para niños es '*'. De todos modos, este caso es la excepción y no la regla. La mayoría de las veces ni siquiera necesita especificar 'hijos', y mucho menos 'Contenedor'; pero la funcionalidad debe estar allí para cubrir todos los casos de uso posibles.

@a14n votar es votar, seguro que significa.

Respeto tu sentimiento, tal vez sea cierto. Pero incluso con una proporción inversa (1 a 2), eso todavía significa una base de usuarios del 33%. ¿Puedes decir que el 33% es una pequeña parte?

personas que quieren una experiencia similar a JSX

Sí, algunas personas están mirando. Esto también significa que _la falta de JSX es una de las razones por las que las personas no eligen flutter_.

Flutter apunta a más desarrolladores, no solo a los que leen todos los números.

@jstansbe
Soy un programador autodidacta y, como la mayoría de los autodidactas, comencé con Javascript.
Luego comencé a aprender React y React-Native. Creo que en los últimos años, especialmente después de ES6, se agregó el estilo OOP a Javascript.

Entonces, la gente como yo no está acostumbrada al estilo de programación OOP. Aunque React native Component son clases como Widgets en Flutter.

JSX esconde la imagen pura de programación orientada a objetos. Básicamente, oculta lo que sucede debajo del capó. Nota: React fue diseñado para desarrolladores web, y los desarrolladores web están acostumbrados a la sintaxis html. Es por eso que JSX es tan popular entre los desarrolladores web.

Personalmente, creo que OOP puro tiene más sentido para grandes proyectos.

@clarktank ,

Cuando se habla de lenguajes informáticos, debe tener en cuenta:
(1) Sintaxis - los caracteres y palabras que componen el lenguaje
(2) Semántica - el significado de esos caracteres y palabras

Por ejemplo, las llamadas a funciones en muchos idiomas tienen el siguiente aspecto (es decir, tienen la siguiente sintaxis):

a = someFunction(param1, param2)

Imagine ahora que otro idioma decide usar corchetes en lugar de corchetes para llamadas a funciones; se vería como lo siguiente:

a = someFunction[param1, param2]

Lo que pasa aquí es que la sintaxis es diferente pero la semántica es la misma. Quiero decir que ambos están básicamente haciendo llamadas a funciones pero con una sintaxis diferente.

JSX esconde la imagen pura de programación orientada a objetos. Básicamente, oculta lo que sucede debajo del capó.

No es cierto del todo. JSX/DSX es solo una sintaxis diferente a exactamente lo mismo (la semántica es la misma). En el caso de JSX, las etiquetas XML solo crean componentes React (al igual que puede hacerlo en Pure Javascript). En el caso de DSX, las etiquetas XML solo crean Flutter Widgets (al igual que puede hacerlo en Pure Dart). La sintaxis es diferente, pero genera exactamente lo mismo, por lo que es idéntico bajo el capó.

Nota: React fue diseñado para desarrolladores web, y los desarrolladores web están acostumbrados a la sintaxis html. Es por eso que JSX es tan popular entre los desarrolladores web.

JSX es popular porque es una excelente manera de administrar jerarquías de árboles de componentes, ya sea para web, dispositivos móviles o cualquier desarrollo de interfaz de usuario. Observe en el código a continuación que no sabe si el componente desplegable es para web o móvil, por ejemplo.

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

// Using JSX to express UI components.
var dropdown =
  <Dropdown>
    A dropdown list
    <Menu>
      <MenuItem>Do Something</MenuItem>
      <MenuItem>Do Something Fun!</MenuItem>
      <MenuItem>Do Something Else</MenuItem>
    </Menu>
  </Dropdown>;

render(dropdown);

Personalmente, creo que OOP puro tiene más sentido para grandes proyectos.

¿Como es eso? (considerando que usar JSX/DSX o Pure Javascript/Dart genera exactamente lo mismo debajo del capó).

@cbazza

Usé react-native durante casi un año y no tenía idea de que los elementos JSX son objetos que se están instanciando, hasta que comencé con Flutter/Dart. Desde mi perspectiva, oculta la imagen OOP, aunque, como dijiste, ¡semánticamente hace lo mismo debajo del capó!

En aplicaciones grandes, JSX también podría volverse tan feo como objetos muy anidados. Entonces, sintácticamente, preferiría mantener la coherencia que introducir otro estilo que podría ser tan confuso.

@clarktank ,

En aplicaciones grandes, JSX también podría volverse tan feo como objetos muy anidados. Entonces, sintácticamente, preferiría mantener la coherencia que introducir otro estilo que podría ser tan confuso.

Para mí, tener un aspecto diferente al resto del código es en realidad un beneficio.

(Me disculpo de antemano por el muro de texto).

Como alguien que no ha usado React-Native o Flutter el tiempo suficiente para considerarme una fuente definitiva, ya sea que Dart sin formato o JSX/DSX sea "mejor", este tema ha sido bastante fascinante de leer. Sin embargo, hay un par de cosas en las que me gustaría poner mi $ 0.02.

Para empezar, estoy de acuerdo con varias personas sobre la naturaleza de lo que JSX es en realidad y cómo beneficia a los desarrolladores. En primer lugar, JSX se diseñó como una forma de "HTML dinámico" que se podía integrar en el código Javascript existente. Es indispensable para las plataformas web basadas en JS como React, ya que permite a los desarrolladores web interactuar de manera limpia y eficiente con el DOM sin tener que luchar con la horrible forma nativa (o la forma jQuery solo un poco mejor). Además, por su propia naturaleza, JSX fomenta el desarrollo de una interfaz de usuario que se puede desvincular fácilmente de los datos subyacentes, lo que promueve una estructura de proyecto bien organizada. En ese entorno, JSX es una herramienta para permitir una mayor productividad, y creo que sería prácticamente imposible discutir eso.

La forma en que ese párrafo se relaciona con React-Native es que, a pesar de que es una plataforma de desarrollo móvil, desciende directamente de React. Como tal, casi toda la sintaxis y los paradigmas todavía se crearon originalmente con el desarrollo web en mente. Eso es por diseño: todo el truco de RN es que puede "crear aplicaciones móviles multiplataforma usando React", por lo que se supone que se siente como un desarrollo web cuando lo usa. Las aplicaciones RN también están predominantemente escritas en Javascript, por lo que la inclusión de JSX es natural. JSX ayuda al desarrollo de RN por casi las mismas razones por las que ayuda en el desarrollo web. (Realmente creo que esta es una gran razón por la que, al menos en RN, el enfoque JSX se usa con mucha más frecuencia que el enfoque nativo. RN en sí mismo simplemente _se siente_ como una plataforma web, por lo que el enfoque más natural de la web inevitablemente llegar a ser predominante.)

Flutter, por otro lado, no tiene tal filosofía de diseño. Está destinado a ser una solución multiplataforma puramente nativa, y aunque afirma que se inspiró en React-Native, se parece mucho más a una aplicación nativa de escritorio o móvil que a una aplicación web. También se ejecuta con Dart y no con Javascript, que desde el punto de vista de integrar algo como JSX es una consideración importante. Por un lado, mientras que las funciones JS DOM pueden ser terriblemente detalladas (tanto por el diseño de la función como por el lenguaje JS en sí), Dart como lenguaje facilita mucho más el código declarativo de interfaz de usuario limpio, mientras que Flutter en su mayor parte hace un buen trabajo de mantener los constructores de IU concisos. Por otro lado ( como señaló @sandangel ), Dart es un lenguaje de tipo estático, por lo que la naturaleza de JSX está diseñado para un lenguaje de tipo dinámico como JS se encontrará con inconvenientes en los casos en que, por ejemplo, un constructor de interfaz de usuario requiere un Widget de un tipo específico, la única solución a la que solo se suma a la verbosidad. Personalmente, se siente como una solución que, con el tiempo, inevitablemente dará como resultado un DSL que se ha inflado y es difícil de mantener, ya que tiene que dar cuenta de un número creciente de casos de uso inherentes a un sistema que no estaba destinado a ser. usado para.

Como tal, realmente no veo cómo JSX/DSX beneficiaría la productividad de desarrollo de Flutter más allá de ser una cuestión de preferencia personal. Ambas sintaxis en general son aproximadamente equivalentes en verbosidad, y cuando una pierde verbosidad en instancias específicas, lo compensa con claridad (las etiquetas XML de cierre, por ejemplo). En gran medida se reduce a si alguien llega a Flutter desde un entorno orientado a la web (React/RN, Angular, etc.) o desde un entorno nativo (Java/Kotlin/Swift, WPF/UWP, etc.) que determinará qué enfoque que preferirían. Incluso solo en este hilo, hay muchas historias de usuarios que dicen que al principio eran extremadamente escépticos con respecto a JSX, pero después de usarlo durante unos meses cambiaron su opinión a "no se puede prescindir". (Aunque la parte cínica de mí quiere señalar que lo mismo podría pasarles a ellos con el enfoque nativo de Dart si le dieran una oportunidad).

Habiendo dicho todo eso, realmente no puedo verme de acuerdo en que DSX debería recibir soporte oficial del equipo de Flutter como una alternativa a los constructores de UI nativos. Si bien está perfectamente bien como una solución de terceros (y todos los apoyos para @cbazza por implementarla realmente), en realidad no encaja con la naturaleza central de Flutter como una plataforma no basada en tecnología web. Como tal, más poder para cualquiera que quiera usar DSX en sus propios proyectos, pero estoy de acuerdo con la mentalidad de que hay muchas otras cosas más importantes en las que el equipo de Flutter podría y debería dedicar su tiempo.

Ahora, dicho esto, aunque no estoy de acuerdo con que DSX sea oficialmente compatible, sí creo que debería haber un formato de interfaz de usuario oficial de _algún_ tipo. Como señaló @birkir , casi todas las principales plataformas nativas de interfaz de usuario, ya sea de escritorio o móvil, tienen un formato de interfaz de usuario además del enfoque directo basado en código (y la mayoría de ellos se procesan previamente en el enfoque basado en código de todos modos). Tener archivos de interfaz de usuario separados de los archivos lógicos siempre ha sido la forma recomendada de adoptar el patrón MVVM (que, por cierto, es algo que siempre me ha molestado en JSX). Lo que diría, por lo tanto, es que Flutter tiene algo similar: en lugar de un formato DSL de interfaz de usuario en línea, debería tener un formato de interfaz de usuario separado que esté destinado a ir a su propio archivo lejos del código Dart.

Como parte de esta línea de pensamiento, en realidad trabajé un poco el pasado fin de semana en ese sentido. Si se me permitiera hablar por un momento, desarrollé un proyecto que he denominado "FLUI", que es mi intento de mostrar cómo sería ese formato . En lugar de usar un DSL existente (o una versión modificada), desarrollé uno completamente nuevo que se inspira en YAML y he hecho todo lo posible para mantenerme cerca de la "sensación" del diseño del enfoque del constructor de Flutter. De acuerdo, es una implementación _muy_ temprana, por lo que realmente no espero que no tenga una gran cantidad de problemas, pero he incluido el código fuente para el script del procesador (escrito en C#/.NET Standard) para que la gente pueda jugar con ella si quieren. :)

Como usuario de React/RN y Flutter, no estoy de acuerdo con la idea de "DSX".

DSX no aportaría nada . JSX se usa en reaccionar porque la sintaxis de JS es horrible. Pero en el caso de Flutter, la creación de widgets es muy fácil.

El clásico:

Widget build(BuildContext context) {
  return Center(
    child: Text("foo"),
  );
}

ya está lista para usar legible, fácil de escribir, compatible con tipos/genéricos y sin ninguna duplicación innecesaria.

La única queja que podría tener con la sintaxis actual es "Es difícil saber dónde está el paréntesis de cierre de un widget".

Pero, de nuevo, el complemento dart de los IDE compatibles oficialmente resuelve este problema. Entonces, cuando abramos el código anterior en, por ejemplo, vscode, veremos

Widget build(BuildContext context) {
  return Center(
    child: Text("foo"),
  ); // Center
}

En cuanto a "Es difícil diferenciar el código casual del código de la interfaz de usuario", las reglas de reacción también se aplican a flutter:

Los widgets deben ser tontos o inteligentes. El widget inteligente no tiene lógica de interfaz de usuario. Los widgets tontos no tienen más que lógica de interfaz de usuario.

Si sigue este patrón, nunca debe caer en una situación en la que no pueda diferenciar la interfaz de usuario del resto.
Esto es aún más cierto cuando se sigue algo como el patrón BLoC; que imponen en gran medida la separación de negocios y UI.

JSX se usa en reaccionar porque la sintaxis JS es horrible

Declaración muy obstinada y simplemente no es cierto.

render() {
  return React.createElement(Container, { padding: EdgeInsets.all(20.0) },
    React.createElement(Text, { style: { color: Colors.black } },
      'foo'
    )
  );
}

Widget build(BuildContext context) {
  return Container(
    padding: EdgeInsets.all(20.0),
    child: Text(
      'foo',
      style: TextStyle(color: Colors.black)
    ),
  );
}

render() {
  return (
    <Container padding={EdgeInsets.all(20.0)}>
      <Text style={{ color: Colors.black }}>foo</Text>
    </Container>
  );
}

Widget build(BuildContext context) {
  return (
    <Container padding={EdgeInsets.all(20.0)}>
      <Text style={TextStyle(color: Colors.black)}>{'foo'}</Text>
    </Container>
  );
}

Declaración muy obstinada y simplemente no es cierto.

Hay muchos caracteres innecesarios en la sintaxis de reacción predeterminada.
Comparemos la repetición de palabras y el recuento de caracteres para cada sintaxis (excluyendo la definición de función, la sangría y el 'retorno')

Reaccionar sin JSX:

• 133 caracteres, incluidos 3 paréntesis, 3 corchetes, 3 : , 4 , y 11 espacios
• React.createElement escrito dos veces

JSX:

• 104 caracteres, con 2 paréntesis, 3 corchetes, 1 : , 4 <> y 5 espacios
• Container y Text escritos dos veces

Dardo:

• 99 caracteres, con 2 paréntesis, 4 : , 3 , y 4 espacios
• Sin repetición

En términos de caracteres, el ganador obvio aquí es la sintaxis de dardos.

Ahora también tenemos que tener en cuenta otras características específicas de los dardos.

Dart escribe un solo hijo frente a varios hijos, tiene const constructores y permite genéricos e incluso parámetros posicionados. JSX no admite ninguno de estos.

Algunos ejemplos que se convertirían mal a JSX:

No siempre children :

Scaffold(
  appBar: AppBar(),
  body: Container(),
)

OR

SingleChildScrollView(
  child: Container(
    height: 100.0,
  ),
)

const constructor en el propio widget

const Padding(
  padding: const EdgeInsets.all(4.0),
)

genéricos

NotificationListener<ScrollNotification>(
  onNotification: (foo) {

  },
  child: child,
)

accesorios posicionados:

Text("foo")

constructor con nombre

Positioned.fill(
  child: Container(),
);

constructores (Dart no admite el tipo de unión, por lo que children no puede ser un widget y una función a la vez)

Builder(
  builder: (context) => Container(),
)

@rrousselGit

Como se mencionó varias veces antes, DSX es simplemente un
sintaxis y es un superconjunto de Dart, por lo que todo lo que puede hacer con
Dart, puedes hacerlo dentro de DSX. También puedes mezclar y combinar ambos
sintaxis como mejor le parezca. Obviamente ni siquiera te molestaste en comprobar
cuáles son algunas de las características de DSX que se realizaron para admitir
Dardo:
https://chispa-heroku-dsx.herokuapp.com/index.html

-1---------------------------------------
En dardo:

Scaffold(
  appBar: AppBar(),
  body: Container(),
)

OR

SingleChildScrollView(
  child: Container(
    height: 100.0,
  ),
)

En DSX:

<Scaffold
  appBar={<AppBar/>}
  body={<Container/>}
/>

OR

<SingleChildScrollView>
  <Container
    height={100.0}
  />
</SingleChildScrollView>

-2---------------------------------------
En dardo:

const Padding(
  padding: const EdgeInsets.all(4.0),
)

En DSX:

const Padding(
  padding: const EdgeInsets.all(4.0),
)

-3---------------------------------------
En dardo:

NotificationListener<ScrollNotification>(
  onNotification: (foo) {

  },
  child: child,
)

En DSX:

<NotificationListener<ScrollNotification>
  onNotification={(foo) {

  }}
  child={child}
/>

-4---------------------------------------
En dardo:

Text("foo")

En DSX:

<Text ["foo"]/>

-5---------------------------------------
En dardo:

Positioned.fill(
  child: Container(),
);

En DSX:

<Positioned.fill>
  <Container/>
</Positioned.fill>

-6---------------------------------------
En dardo:

Builder(
  builder: (context) => Container(),
)

En DSX:

<Builder
  builder={(context) => <Container/>}
/>

Pero entonces el argumento de tener una conversión más fácil de reaccionar a aleteo no es válido. Como JSX es radicalmente diferente de su prototipo:

<MyAppBar>
    <title:Text [] style={Theme.of(context).primaryTextTheme.title}>
        Example title
    </title:Text>
</MyAppBar>

Y ninguno de sus ejemplos aquí o de su enlace realmente simplifica el código o mejora la legibilidad

Por mucho que me relacione con su sensación de extrañar JSX (obtuve lo mismo al iniciar flutter), después de un poco de experiencia, la sintaxis nativa se siente bastante bien en realidad

Como nota al margen, hay una solución mucho mejor para su separación de preocupaciones. Ese es un archivo de plantilla.
Podría tener un archivo xml/yaml al lado de su widget. Y luego use las increíbles herramientas de generación de código que proporciona dart.

Prefiero preferir un:

// main.dart
import 'package:flutter/material.dart';

part 'main.g.dart';

class MyState extends StatefulWidget {
  <strong i="14">@override</strong>
  _MyStateState createState() => _MyStateState();
}

class _MyStateState extends State<MyState> {
  <strong i="15">@override</strong>
  Widget build(BuildContext context) {
    return $myStateStateTemplate(theme: Theme.of(context));
  }
}

combinado con un

// main.xml
<strong i="19">@theme</strong> ThemeData

<Container  color={@theme.cardColor} />

que luego, usando un generador de código personalizado, genera el siguiente archivo dart:

part of 'main.dart';

Widget $myStateStateTemplate({ThemeData theme}) {
  return Container(
    color: theme.cardColor,
  );
}

El resultado final es incluso mejor que un "DSX" para la separación de la interfaz de usuario y la lógica. También es mejor para los posibles generadores de IU. Y es mucho más fácil de implementar usando built .

Como JSX es radicalmente diferente de su prototipo:

En realidad !!! Lo único radical en estas discusiones ha sido la reacción de los detractores.

Como se indica en el título de este ticket, DSX es similar a JSX, no es idéntico a JSX o de lo contrario se habría llamado JSX; y las adiciones son menores y brindan opciones a los desarrolladores.

Podrías escribirlo como:

<MyAppBar>
    <title:Text [] style={Theme.of(context).primaryTextTheme.title}>
        Example title
    </title:Text>
</MyAppBar>

or

<MyAppBar>
    <title:Text ['Example title'] style={Theme.of(context).primaryTextTheme.title}/>
</MyAppBar>

or

<MyAppBar
    title={<Text [] style={Theme.of(context).primaryTextTheme.title}>
        Example title
    <Text>}
/>

or

<MyAppBar
    title={<Text ['Example title'] style={Theme.of(context).primaryTextTheme.title}/>}
/>

Hummmm, pareces estar confundiendo 'separación de preocupaciones' con 'separación de tecnología'. Estas cosas son muy diferentes; usted separa el código dart y el código de marcado en diferentes archivos, es simplemente 'separación de tecnología' y no proporciona ninguno de los beneficios de la 'separación de preocupaciones'. Una preocupación aquí sería un componente/widget que encapsule código reutilizable limpiamente, no importa que dentro de ese componente/widget esté usando diferentes tecnologías.

Además, la separación de tecnologías como usted recomienda es muy inferior a JSX/DSX, que utiliza el lenguaje host para todas sus construcciones imperativas (para bucles, llamadas a funciones, declaraciones if, etc.).

Después de mucho código y ejemplos publicados aquí ( especialmente ), llego a la conclusión de que JSX agrega mucho más valor a JS en contraste con DSX y Dart. Pero una característica es muy importante desde mi punto de vista: las etiquetas de cierre. Me gusta:

<SingleChildScrollView>
  <Container
    height={100.0}
  />
</SingleChildScrollView>

reduce MUCHA complejidad cognitiva en estructuras profundas como aquí en contraste con:

SingleChildScrollView(
  child: Container(
    height: 100.0,
  ),
)

Pero bueno, si lo usas así:

<Scaffold
  appBar={<AppBar/>}
  body={<Container/>}
/>

hay una pequeña ganancia.

Como se indica en el título de este ticket, DSX es similar a JSX, no es idéntico a JSX.

Te perdiste mi "Pero entonces el argumento de tener una conversión más fácil de reaccionar a aleteo no es válido".

La mitad de los argumentos a favor de DSX es "JSX es popular en reacción, también necesitamos esto aquí". Pero estás proponiendo algo diferente (y más complejo) de JSX.
La otra mitad se trata de separar la interfaz de usuario del código; lo que también puede hacer un archivo de plantilla.

Además, la separación de tecnologías como usted recomienda es muy inferior a JSX/DSX, que utiliza el lenguaje host para todas sus construcciones imperativas (para bucles, llamadas a funciones, declaraciones if, etc.).

No es verdad. Podrías hacer if y otras cosas dentro de tu archivo de plantilla. Mire cshtml o plantillas angulares.

La cuestión es que un archivo de plantilla, siempre que ya tenga un analizador para él, podría implementarse para flutter en menos de una semana en pleno funcionamiento.
Ya sea yaml, xml, cshtml o html con directivas.

Mientras que un DSX requeriría mucho trabajo.

@Bessonov Recientemente agregaron comentarios virtuales en IDE compatibles para simular la etiqueta de cierre.

Así que en tu vscode verás lo siguiente:

SingleChildScrollView(
  child: Container(
    height: 100.0,
  ), // Container
) // SingleChildScrollView

Los beneficios de cerrar las etiquetas. Sin tener que escribirlos

@rrousselGit

Recientemente agregaron comentarios virtuales en IDE compatibles para simular la etiqueta de cierre.

Sí, lo he visto en el comentario citado. Pero no es lo mismo. Esto introduce un cambio de alineación y perturba el flujo de lectura. Y esto no me ayuda en otros IDE y procesadores de texto.

La cosa es un archivo de plantilla.

En mi humilde opinión, las plantillas sufren de síndrome NIH. No digo que el enfoque de mezclar PHP y HTML sea la forma correcta de hacerlo. Pero reaccionar muestra con JSX cómo se puede hacer mejor.

@rrousselGit

Te perdiste mi "Pero entonces el argumento de tener una conversión más fácil de reaccionar a aleteo no es válido".

No, no me perdí el comentario en absoluto, simplemente no tiene sentido que me digas que las personas que vienen de JSX encontrarán que DSX es demasiado complejo.

La mitad de los argumentos a favor de DSX...

Hay muchas razones para elegir DSX, pero con las alternativas, las personas elegirán lo que prefieran por cualquier razón que tengan.

No es verdad. Podría hacer if y cosas dentro de su archivo de plantilla. Mire cshtml o plantillas angulares.

La cuestión es que un archivo de plantilla, siempre que ya tenga un analizador para él, podría implementarse para flutter en menos de una semana en pleno funcionamiento.
Ya sea yaml, xml, cshtml o html con directivas.

Mientras que un DSX requeriría mucho trabajo.

Totalmente opuesto, DSX solo implementa 2 transformaciones xml y obtiene todo lo demás de forma gratuita desde el lenguaje de alojamiento. Imagine el esfuerzo de tratar de volver a implementar el poder de Dart dentro de su nuevo lenguaje de plantillas. No gracias, me quedo con Dart.

No, no me perdí el comentario en absoluto, simplemente no tiene sentido que me digas que las personas que vienen de JSX encontrarán que DSX es demasiado complejo.

Lo mismo se aplica a la implementación actual de dart.

De todos modos, no creo que podamos convencernos aquí. Así que solo enumeraré algunas razones más de por qué no me gusta JSX en flutter y luego "esperar y ver".

1. La creación de widgets es diferente a React

En reaccionar, es la biblioteca que maneja la creación de componentes. JSX está bien porque dice "No te preocupes por cómo funcionan las cosas. Hacemos las cosas por ti".

En flutter ese no es el caso. Instanciamos manualmente un nuevo widget cada llamada de compilación. Esto es realmente importante de entender, y JSX lo haría menos claro.

Y, en la continuación de esa lógica:

2. La gente puede pensar que <Foo /> hace algo especial que new Foo() no

<Foo /> en un método se siente especial. Parece que hace algo extraño incorporado en el marco. Lo cual es cierto en reaccionar, donde los componentes se envuelven en un React.Element .
Esto se traduce en reaccionar en <Foo /> != new Foo() y no tener acceso directo a Foo .

Esto no se aplica en flutter y puede causar confusión.

También :

<Foo>
  <Bar />
</Foo>

En reacción, si Foo nunca usa su hijo, entonces nunca se crea una instancia Bar . Y se crea una instancia Foo después de que regresa el método render .
Mientras que en aleteo esto es lo contrario. Tanto Bar como Foo se crean inmediatamente

Esto conduciría potencialmente a que los desarrolladores de React creen código flutter no optimizado.

3. En general, Dart/flutter no es JS/react

Si agregamos JSX en dart, ya puedo ver los problemas sobre la unión de tipos o poder hacer
return foo && <Component /> o la próxima representación asíncrona en reaccionar.
Justificado con un "ya tenemos JSX, ¡así que también podemos tener eso!"

Preferiría una sintaxis propietaria o ninguna sintaxis, por el bien de no tener que implementar la última función JSX/react en dart

4. JSX hace que algunos detalles de los dardos no estén claros

Un pequeño ejemplo, Scaffold requiere para appbar un PrefferedSizeWidget .
Si creamos Scaffold usando JSX, la gente esperaría que pueda reemplazar cualquier JSX dado por otro. lo cual no es cierto

Quiero decir, deja muy poco claro por qué podemos hacer

<Scaffold
  appbar={<AppBar />}
/>

pero no

<Scaffold
  appbar={<Container />}
/>

@rrousselGit

De todos modos, no creo que podamos convencernos aquí. Así que solo enumeraré algunas razones más de por qué no me gusta JSX en flutter y luego "esperar y ver".

No estoy de acuerdo con mucho de lo que dijiste, pero agradezco tu esfuerzo ya que te estás tomando el tiempo para pensar profundamente en el tema.

1. La creación de widgets es diferente de React

Para mí no importa porque esto es solo un detalle de implementación, conceptualmente una vez que ves algo de XML, en React es un Componente, en Flutter es un Widget.

1. Los pueblos pueden pensar hace algo especial que el nuevo Foo() no hace

Creo que la gente aprenderá bastante rápido que Dart/DSX no es Javascript/JSX.

1. En general, Dart/flutter no es JS/react

Sí, finalmente estamos de acuerdo en algo, pero a pesar de que son diferentes, el hilo común es que son marcos de interfaz de usuario declarativos y creo que las estructuras de árbol declarativas se manejan bien con JSX/DSX. Te mantiene en la forma de pensar de la programación declarativa.

Si agregamos JSX en dart, ya puedo ver los problemas relacionados con la unión de tipos o poder hacer return foo && <Component /> o la próxima representación asíncrona en reaccionar.
Justificado con un "ya tenemos JSX, ¡así que también podemos tener eso!"

No estamos agregando JSX en Dart, estamos agregando DSX, es diferente pero tiene similitudes con JSX y la familiaridad es algo enorme.

Preferiría una sintaxis propietaria o ninguna sintaxis, por el bien de no tener que implementar la última función JSX/react en dart.

Entonces, con ese razonamiento, ¿por qué estás usando Dart? se parece bastante a Java y, sin embargo, es diferente a Java; Al diablo con eso, desechemos todas estas palabras clave y conceptos de Java y propongamos algo vagamente similar a Erland que solo puedes programar con una mano mientras haces un movimiento de yoga pretzel en la cima del Monte Everest;)

1. JSX hace que algunos detalles de dardos no estén claros

No realmente, si conecta Widgets incomparables, el compilador de Dart escupirá mensajes de error como si lo hiciera en Dart simple. No puedo enfatizar lo suficiente que DSX es simplemente azúcar sintáctica delgada, no hay magia, solo una sintaxis diferente a la misma cosa.

@cbazza Pasé horas leyendo sus publicaciones y realmente aprecio su esfuerzo en este tema. Pero creo que es (más o menos) fácil terminar la discusión. ¿Recuerdas que flux era la solución de administración estatal oficial para reaccionar, pero ahora todos usan redux? ¿Y cuántas bibliotecas de navegación hay para react-native? Simplemente haga un repositorio DSX y deje que los desarrolladores de reacción participen.

@rrousselGit

Nunca antes había visto la sintaxis part / part of en Dart, y tengo problemas para encontrar documentación al respecto. ¿Es algo que Dart/Flutter admita oficialmente? Me encantaría usar algo así en FLUI.

@cbazza

Sigues dando vueltas en círculos con la justificación DSX. DSX no es JSX. DSX es similar a JSX. DSX está destinado a ser una sintaxis familiar para los desarrolladores de React. DSX es simplemente azúcar sintáctico para Dart. La gente aprenderá que DSX no es JSX. (Y así.)

Si bien entiendo el punto que está tratando de hacer con todas esas explicaciones, creo que el hecho de que tenga que seguir haciéndolas revela un problema importante con respecto a la naturaleza de DSX en general, y es un punto que rrouselGit también mencionó. Aunque sigas diciendo que DSX no es JSX, las personas que lo encuentren pensarán que lo es, y eso es un problema. JSX, y las personas que lo usan, provienen de un ecosistema que es tan conceptualmente diferente en niveles fundamentales de Dart/Flutter. Como tal, desarrollar una función de "familiaridad" no es necesariamente algo bueno. Una de las razones más evidentes de esto es, como se señaló, que la gente intentará algo como esto:

Widget build(BuildContext context) {
    return isDialogVisible && <Widget>...</Widget>;
}

Debido a que provienen de Javascript/JSX, esperan que esa sintaxis funcione en DSX. Cuando no es así, se convierte en un punto de disonancia cognitiva que en realidad puede _dañar_ su interés no solo en DSX sino en Flutter en general. La familiaridad es beneficiosa cuando se usa como un medio para ayudar a las personas a aprender algo nuevo, pero eso puede ser un arma de doble filo: cuando el 90 % de las características son las mismas, el 10 % restante puede servir para frustrar y molestar.

Otro problema con DSX es que no es probable que sea una característica perfectamente integrada en el corto plazo, independientemente de si es un complemento de terceros o si Flutter lo adopta oficialmente. Como usted mismo ha dicho, para que realmente funcione con el proceso de implementación y depuración de Flutter, necesita soporte oficial no solo del equipo de Flutter sino también del equipo de Dart. De lo contrario, sin soporte de preprocesamiento y herramientas, la única forma en que DSX funcionaría es con herramientas de conversión manual externas, que es solo otro paso (potencialmente largo) que los desarrolladores tendrán que seguir.

Mientras escribía esto, se me ocurrió otra cosa. Ha habido varias personas pro-JSX en este hilo que han elogiado a JSX, diciendo que el enfoque de "separación de preocupaciones" para el diseño de la interfaz de usuario es realmente la única forma en que considerarán desarrollar interfaces de usuario nuevamente. Si ese es el caso, ¿por qué React es el único marco con presencia en el mercado que lo usa? Tanto los frameworks de aplicaciones móviles nativas como multiplataforma se han quedado con sus guiones gráficos, sus archivos XML, sus archivos XAML y otros DST de definición de interfaz de usuario. Incluso otros marcos JS populares como Angular y el prometedor Vue todavía tienen el enfoque de "separación de tecnologías". Los desarrolladores de React hablan como si JSX fuera el camino hacia el futuro, pero todavía no lo he visto aparecer en ningún otro lugar que no sea React en un marco que haya tenido una tracción real.

@andrewackerman

part / part of es una característica de dardo existente. De alguna manera une dos archivos en uno. Normalmente se utiliza para la generación de código.

Hay algunos escenarios de casos reales que utilizan dicha técnica. Como json_serializable que genera un método toJSON y una fábrica de fromJSON para las clases en función de sus propiedades.

part / part of realmente no hacen nada por sí solos. La parte interesante es cuando lo combinas con algo como source_gen .

@sunnylqm

No creo que poner el código en un repositorio resuelva mi problema porque el problema actual se trata de integrar correctamente DSX con las herramientas de Flutter para brindar una excelente experiencia de desarrollador con depurador, autocompletar, etc. trabajando en el archivo .dsx.

Decirle a los usuarios que pueden usar DSX pero que no pueden usar el depurador o disfrutar de la función de autocompletar no es un comienzo para mí. Si alguien quiere ayudar, lo que necesito es encontrar una manera de agregar soporte completo de preprocesamiento (con mapa de origen) a Dart Tools y VS Code Dart plug in. Una vez que las herramientas admitan ese DSX o cualquier otro lenguaje de transpilación (cualquier idioma que es un superconjunto de Dart pero compila todo hasta Dart) simplemente funcionaría.

@andrewackerman

No necesito justificar nada, estoy muy seguro de que DSX será un éxito y hay casi 100 personas interesadas solo en este boleto.

De lo contrario, sin soporte de preprocesamiento y herramientas, la única forma en que DSX funcionaría es con herramientas de conversión manual externas, que es solo otro paso (potencialmente largo) que los desarrolladores tendrán que seguir.

El transpilador DSX es deslumbrantemente rápido y puede transformar archivos .dsx en archivos .dart más rápido de lo que puede parpadear, por lo que la velocidad no es un problema; solo trato de obtener la paridad de características para que sea una obviedad para las personas usar DSX.

Si ese es el caso, ¿por qué React es el único marco con presencia en el mercado que lo usa? Tanto los frameworks de aplicaciones móviles nativas como multiplataforma se han quedado con sus guiones gráficos, sus archivos XML, sus archivos XAML y otros DST de definición de interfaz de usuario.

Simplemente haga una línea de tiempo y verá la evolución del desarrollo de la interfaz de usuario. El desarrollo de Android e iOS a través de sus formas actuales comenzó hace más de 10 años, por lo que utiliza técnicas de 10 años (técnicas totalmente imperativas). Las técnicas de desarrollo de UI reactivas (declarativas) comenzaron a aparecer para la web hace aproximadamente 8 años. React apareció hace 5 años y fue el primer marco Reactivo en combinar tecnologías a la perfección con JSX. Vue es ahora el marco Reactivo más reciente que admite las técnicas más antiguas de "separación de tecnologías", pero también es compatible con JSX. En dispositivos móviles, Flutter es lo último y utiliza técnicas de marco reactivo como React y podría aprovechar DSX al igual que Vue aprovecha JSX. Vue está matando a Angular porque brinda opciones a los desarrolladores y no es demasiado obstinado.

El problema con los archivos de plantilla separados es que las construcciones de programación imperativas allí (si, bucle for, etc.) son muy débiles en comparación con lo que está disponible en el lenguaje de programación utilizado para la lógica comercial. Para mí, combinar los 2 en la forma en que lo hace JSX es claramente el futuro.

Los desarrolladores de React hablan como si JSX fuera el camino del futuro,

Está !!!

pero todavía tengo que verlo aparecer en otro lugar que no sea en React en un marco que haya tenido una tracción real.

Vue usa JSX

@cbazza

No necesito justificar nada, estoy muy seguro de que DSX será un éxito y hay casi 100 personas interesadas solo en este boleto.

No estoy diciendo que _debes_ justificar nada. Antes, cuando insistías en que el equipo de Flutter recogiera esta propuesta y la implementara ellos mismos, sí, habría dicho que tenías bastante que justificar. Ahora que está tratando de hacerlo usted mismo, puede hacer lo que quiera por cualquier justificación que crea que es suficiente y más poder para usted. Simplemente estoy indicando las razones por las que veo que podría no ser tan fácil o tan popular como parece pensar que será, y estoy poniendo la pelota en su cancha para desafiarlos.

El transpilador DSX es deslumbrantemente rápido y puede transformar archivos .dsx en archivos .dart más rápido de lo que puede parpadear, por lo que la velocidad no es un problema; solo trato de obtener la paridad de características para que sea una obviedad para las personas usar DSX.

Supongo que, en este punto, lo ha probado hasta ahora en UI y aplicaciones que son triviales en tamaño. ¿Qué pasa con los no triviales? ¿Qué pasa con los que caen dentro de los casos extremos? Además, el tiempo real que toma el proceso no es la única parte relevante, solo el hecho de que el desarrollador tiene que pasar por otra lista de verificación de acciones manuales antes de que puedan construir es suficiente para desanimar a muchas personas.

Además, todavía tiene que publicar el código fuente del proyecto, por lo que nadie ha podido pasar por su proceso, verificar dos veces sus hallazgos y sugerir mejoras. En este punto, todo lo que cualquiera puede hacer es confiar en su palabra de que es conveniente y eficaz.

Vue usa JSX

He estado usando Vue durante casi un año, y en ese tiempo he revisado una buena cantidad de repositorios de proyectos de código abierto para ver cómo se hacen las diferentes cosas. Si bien no me considero un maestro de Vue de ninguna manera, lo que diré es que en ninguno de ellos he visto JSX realmente utilizado: la gente parece preferir enormemente el enfoque .vue (plantilla -script-styling) sobre el enfoque render+JSX. Ni siquiera sabía que Vue era compatible con JSX (al menos a través de un complemento de Babel) hasta que después de su respuesta investigué un poco en la documentación de Vue y descubrí un pequeño fragmento de información en la sección de función de procesamiento .

Pero esto es irrelevante para mi punto general. Vue sigue siendo un marco de Javascript. Flutter seguramente no lo es. Como tal, hay muchas razones que hacen que JSX sea lo más nuevo y mejor en un entorno centrado en Javascript que no se traducirá a Dart+Flutter, muchas de las cuales ya se han cubierto en este hilo.

Está !!!

Hasta que lo vea popularizarse en un entorno de desarrollo que no sea Javascript, discreparé respetuosamente.

Vue usa JSX

Vue especifica tiene una amplia variedad de usos. JSX está simplemente "allí". Pero no es la sintaxis dominante.
Podrías conectar JSX a Angular si quisieras. Aunque nadie lo hace

Los desarrolladores de React hablan como si JSX fuera el camino del futuro,
Está !!!

Un gran candidato para el futuro son los componentes web. Y se usan directamente en html de manera similar a lo que encontraría en Angular o la forma más común de Vue

@andrewackerman

el solo hecho de que el desarrollador tenga que pasar por otra lista de verificación de acciones manuales antes de poder construir es suficiente para desanimar a muchas personas.

¿Quién dijo algo sobre acciones manuales? ¿No dejé en claro que estoy tratando de obtener una integración IDE completa y sin problemas (la mejor experiencia de usuario posible para los desarrolladores)?

Además, todavía tiene que publicar el código fuente del proyecto, por lo que nadie ha podido pasar por su proceso, verificar dos veces sus hallazgos y sugerir mejoras.

¿Qué tiene eso que ver con las personas que usan DSX? He usado JSX durante más de 2 años y no podría importarme menos su código fuente. ¿Es necesario mirar el código fuente del compilador de Dart para poder programar en Dart?

lo que diré es que en ninguno de ellos he visto JSX realmente utilizado: la gente parece preferir enormemente el enfoque .vue (estilo de script de plantilla) sobre el enfoque render + JSX.

JSX es una nueva incorporación, por lo que llevará tiempo difundirlo, pero el punto importante es que Vue acepta otros enfoques sin obligar a los desarrolladores a usar "la forma correcta y única" en que se deben hacer las cosas en Vue.

Vue sigue siendo un marco de Javascript. Flutter seguramente no lo es.

Bien, así que en lugar de JSX usas DSX con Flutter.

@rrousselGit

Un gran candidato para el futuro son los componentes web.

Los componentes web son zoobies, muertos pero que aún caminan; están tan extendidos como los canguros en Canadá. Podría seguir durante días, pero para evitar divagar...
https://dmitriid.com/blog/2017/03/la-promesa-rota-de-los-componentes-web/

@cbazza

¿Quién dijo algo sobre acciones manuales? ¿No dejé en claro que estoy tratando de obtener una integración IDE completa y sin problemas (la mejor experiencia de usuario posible para los desarrolladores)?

También dijo que necesitaba soporte de preprocesamiento del equipo de Flutter/Dart para poder hacerlo. ¿Estoy equivocado en eso?

¿Qué tiene eso que ver con las personas que usan DSX? He usado JSX durante más de 2 años y no podría importarme menos su código fuente.

JSX fue desarrollado por Facebook para React, se sometió a un riguroso proceso de propuesta/diseño/implementación/iteración y luego se lanzó al mundo años antes de que lo tuvieras en tus manos. Ha sido rigurosamente probado y probado una y otra vez en entornos del mundo real. Es una tecnología madura. No hay razón para exigir ver una hoja de especificaciones para algo así.

DSX, por otro lado, está siendo desarrollado hoy por usted y un puñado de personas. Ha hablado con elocuencia sobre lo que puede y podrá hacer, pero todo lo que hemos _visto_ en realidad es un pequeño puñado de fragmentos de código creados específicamente y su palabra de que fueron generados por el transpilador. Las personas que incluso quieren probarlo y sugerir posibles cambios o mejoras no pueden hacerlo, por lo que no tienen motivos para apoyar sus esfuerzos más allá de "¡Yay JSX!".

No te estoy acusando de mentir ni nada, solo digo que JSX se ha ganado un nivel de fe que DSX no tiene, entonces, ¿cómo vas a llamar la atención si no dejas que la gente juegue con eso?

JSX es una nueva incorporación, por lo que llevará tiempo difundirlo, pero el punto importante es que Vue acepta otros enfoques sin obligar a los desarrolladores a usar "la forma correcta y única" en que se deben hacer las cosas en Vue.

JSX ha estado en Vue durante casi 2 años. Y a diferencia de Vue, JSX es una tecnología preexistente que no necesita presentación, especialmente para las personas familiarizadas con React. Si JSX iba a conquistar el mundo de Vue.js, no puedo evitar sentir que ya lo habría hecho. (Especialmente si es una indicación de que tantas personas están clamando por JSX en Flutter como usted afirma).

Bien, así que en lugar de JSX usas DSX con Flutter.

JSX y DSX son el mismo concepto sintáctico. El problema es que, donde JSX se creó en un lenguaje dinámico de tipo débil como JavaScript, DSX se está construyendo en un lenguaje estático de tipo fuerte como Dart. Eso significa que hay muchos problemas que DSX tendrá que tener en cuenta que JSX no tuvo que hacerlo si va a ser algo más que una implementación de nicho "JSX para Flutter", y se necesitarán algunas modificaciones _ingeniosas_ para que DSX realmente funcione. sin hacerlo demasiado hinchado para justificar la afirmación de que es visualmente más conciso.

Y para abordar la refutación "DSX es solo Dart, si DSX no puede hacer algo, solo use Dart", entonces mi contrarrefutación sería si tengo que seguir recurriendo a Dart cada vez que me encuentro con un escenario que DSX no hace. t handle, entonces, ¿por qué no debería usar Dart todo el tiempo?

Y para abordar la refutación de esa lectura "puede hacerlo si lo desea, DSX es solo una opción", entonces realmente se está vendiendo corto. Incluso si realmente solo va a ser "una opción", todavía necesita traer algo a la mesa que convenza a las personas para que lo usen. Usted mismo dijo que DSX no es JSX, por lo que las personas que solo quieren JSX no obtendrán lo que quieren. Eso significa que debe haber algunas razones tangibles más allá del "atractivo similar a JSX" para que la gente quiera usarlo.

Si solo está creando una herramienta que usted mismo quiere usar, entonces todo esto es discutible y puede volverse loco. Pero si en realidad está construyendo algo que pretende que otras personas usen, entonces necesita ponerlo en una forma sólida por la que cree que deberían hacerlo.

Los componentes web son zoobies, muertos pero que aún caminan; están tan extendidos como los canguros en Canadá. Podría seguir durante días, pero para evitar divagar...

Un poco fuera de tema, pero me gustaría señalar que los componentes web realmente son una mirada prometedora hacia el futuro, incluso si el soporte para ellos se agrega más lentamente que tar. Piénselo de esta manera: React hace lo que hace porque esencialmente implementa la idea de los componentes web solo en Javascript. Imagínese cuánto mejor sería si esas funciones fueran compatibles con el navegador y se beneficiaran del rendimiento sin espacio aislado y no tuvieran que operar a través de la manipulación DOM. (De acuerdo, podrían pasar otros 20 años antes de que lo descubramos, pero aún así...)

@andrewackerman

Lo siento amigo, no tengo tiempo para discutir interminablemente y repetir lo que dije antes una y otra vez; De todos modos, no terminaremos de acuerdo, así que la mejor de las suertes con su FLUI.

Ha hablado con elocuencia sobre lo que puede y podrá hacer, pero todo lo que hemos visto en realidad es un pequeño puñado de fragmentos de código especialmente diseñados y su palabra de que fueron generados por el transpiler.

El transpilador DSX en línea ha estado activo desde febrero de 2018 y cualquiera puede usarlo, por lo que no es necesario que confíe en mi palabra. Presiona 'Compilar' y compila lo que está escrito en el panel izquierdo y coloca los resultados en el panel derecho. Abra el depurador y verá el AST escrito.
https://chispa-heroku-dsx.herokuapp.com/index.html

El problema es que, donde JSX se creó en un lenguaje dinámico de tipo débil como JavaScript, DSX se está construyendo en un lenguaje estático de tipo fuerte como Dart.

No hace ninguna diferencia importante, como el concepto OOP (Programación Orientada a Objetos) y la sintaxis para 'clases'. Es casi idéntico en Javascript sin tipos o en Dart escrito; Lo mismo puede decirse de la declaración 'if', 'for', etc.

todavía necesita traer algo a la mesa que convenza a la gente para que lo use.

Aparentemente ya lo hace para 100 personas en este boleto; y eso es 100 veces más grande que solo yo usándolo; suficientemente bueno para mi.

@cbazza

Lo siento amigo, no tengo tiempo para discutir interminablemente y repetir lo que dije antes una y otra vez; De todos modos, no terminaremos de acuerdo, así que la mejor de las suertes con su FLUI.

No estoy discutiendo contigo solo por discutir o por algún sesgo anti-JSX profundamente arraigado. Estoy tratando de que respondas preguntas que necesitan ser respondidas. Está desarrollando una herramienta que presumiblemente tiene la intención de que otras personas usen, pero aún no ha ofrecido una razón convincente de por qué deberían usarla más allá de los vagos y subjetivos beneficios de "familiaridad" y "porque es mejor". Lo primero, como dije antes, no es necesariamente algo bueno, y lo segundo es hasta ahora un reclamo hecho sin ningún respaldo tangible.

Si desea que su herramienta sea un éxito, debe grabar en piedra lo que está haciendo y por qué lo está haciendo, y debe hacerlo de una manera que pueda transmitirse fácilmente a otros. Eso no quiere decir que no pueda crear un producto hasta que le guste a _todos_, pero los objetivos claros y concisos son cruciales para dar forma al diseño y la implementación. De lo contrario, terminará con una utilidad sin dirección que, en el mejor de los casos, será un producto de nicho y tendrá mucha suerte si termina en código de producción de cualquier escala.

El transpilador DSX en línea ha estado activo desde febrero de 2018 y cualquiera puede usarlo, por lo que no es necesario que confíe en mi palabra. Presiona 'Compilar' y compila lo que está escrito en el panel izquierdo y coloca los resultados en el panel derecho. Abra el depurador y verá el AST escrito.

Ni siquiera vi que ese enlace era un ejemplo de trabajo. Nunca antes había usado herokuapp y solo parecía una esencia o algo así, así que eso depende de mí. :PAGS

(Aunque señalaré que jugar con un sandbox en línea no es lo mismo que probar el transpiler en un entorno más práctico).

No hace ninguna diferencia importante, como el concepto OOP (Programación Orientada a Objetos) y la sintaxis para 'clases'. Es casi idéntico en Javascript sin tipos o en Dart escrito; Lo mismo puede decirse de la declaración 'if', 'for', etc.

Ya tuvo que lidiar con una de esas diferencias en la tipificación fuerte de niños . ¿Qué pasa con la tipificación fuerte de atributos? ¿Qué pasa con los widgets en diferentes bibliotecas con el mismo nombre? ¿Qué sucede si alguien crea un widget con más de un argumento posicional sin nombre? ¿Qué sucede si importamos dos bibliotecas que tienen widgets con el mismo nombre? ¿Qué sucede en algún escenario en el que no he pensado que aparece para mostrar aún más la diferencia inherente entre sistemas como Javascript y Dart? Debo decir que ser tan frívolo en este punto de discusión hace que me preocupe la longevidad de DSX en un entorno del mundo real.

Aparentemente ya lo hace para 100 personas en este boleto; y eso es 100 veces más grande que solo yo usándolo; suficientemente bueno para mi.

Nuevamente, son 100 personas las que votaron a favor del problema sobre la base de "Considere la sintaxis similar a JSX dentro del código dart". Votaron a favor porque quieren _JSX_, y como ha estado tan interesado en señalar, DSX no es JSX. Entonces, ¿por qué más querrían usar DSX? ¿Porque la declaración de interfaz de usuario similar a XML en línea es "el futuro"? De nuevo, simplemente no lo veo.

Ya hemos cubierto JSX en Vue que no recibe ninguna tracción, pero también están las dos alternativas de React mencionadas en el artículo de componentes web que vinculó: Inferno y Preact. Por lo que puedo decir, ninguno de los dos ha logrado hacer ningún tipo de ola en el mundo del desarrollo de aplicaciones web basadas en JS, a pesar de que también admiten de forma nativa la sintaxis similar a JSX. Realmente creo que las personas deben analizar detenidamente _exactamente por qué_ a las personas les gusta JSX en React, porque, según todas las cuentas, no parece ser debido a JSX en sí. Si se puede responder a _esa_ pregunta, entonces podemos avanzar hacia las innovaciones "futuras" en lugar de simplemente convertir esa característica de esa biblioteca que nos gustaba en cualquier otro lugar que personalmente pensamos que debería estar.

Me entristece pensar en la cantidad de energía que se invirtió solo en esta discusión y en lo que podría haberse hecho bien para mejorar el marco actual.

@andrewackerman

El problema es que, donde JSX se creó en un lenguaje dinámico de tipo débil como JavaScript, DSX se está construyendo en un lenguaje estático de tipo fuerte como Dart.

Lo siento, pero esto no es un problema. Además, esto no tiene ningún sentido en absoluto. Además de eso, usamos JSX con TypeScript.

@escamoteur absolutamente!

@escamoteur Estoy contigo en esto. _Los 100._

@Bessonov

Lo siento, pero esto no es un problema. Además, esto no tiene ningún sentido en absoluto. Además de eso, usamos JSX con TypeScript.

React no fue diseñado para TypeScript. Fue diseñado para Javascript. Todas las definiciones de widgets, atributos, propiedades y todo lo demás se diseñó para usarse en el entorno dinámico de JavaScript, por lo que la seguridad de tipos de TypeScript no introduce ningún factor nuevo con respecto a la forma en que JSX interactúa con React. Este es otro ejemplo más de cómo se diseñó JSX para una configuración completamente diferente a la de Flutter.

@andrewackerman
¿Por qué crees que importa? JSX es una forma de describir la interfaz. Es agnóstico del lenguaje por sí mismo. Mira aquí . No es JavaScript. Pero bueno, ¿por qué no se puede hacer con JSX? (Además, no hay implementación de esto (todavía))

Y... ya sabes... flow también viene de fb:

Flow es un verificador de tipos estático para JavaScript.

Por favor, deja de vender argumentos a favor y en contra de extensiones que nunca has usado. Uso JSX todos los días y estoy contento con él ATM, aunque era muy escéptico al respecto. Puedo imaginar que JSX evoluciona en otros patrones, como lo fue con AngularJS.

¿Y tal vez este tema ayude a encontrar un mejor patrón para Dart? DSX es solo una propuesta. Mire el ejemplo de patrón de constructor anterior u otros ajustes de lenguaje presentados aquí. Y, bueno, ¿quizás tu flui es una mejor manera? No sé. Pero averigüémoslo y ayudémonos unos a otros a mejorar sus sugerencias en lugar de discutir sobre cosas malas en la propuesta de otra persona.

Me gustaría proponer cerrar este tema y abrir un nuevo tema general con una conversación limitada. Todas las propuestas para mejorar la forma, cómo se puede usar flutter, discutir en temas propios objetivamente con amor y sin odio.

Sí, la cantidad de odio aquí es épica, solo considera esto:
Hay 3587 entradas abiertas, si las ordenas por "me gusta" obtienes
1 (este) con 57 "pulgares abajo"
3586 (otras entradas) con 1 o menos "me gusta"

@Bessonov

¿Por qué crees que importa? JSX es una forma de describir la interfaz. Es agnóstico del lenguaje por sí mismo. Mira aquí. No es JavaScript. Pero bueno, ¿por qué no se puede hacer con JSX? (Además, no hay implementación de esto (todavía))

Es una forma de describir la interfaz de usuario _en Javascript_ (de ahí la parte "JS" del nombre). Y no, dado que es un DSL en línea, no es independiente del idioma. E incluso si lo fuera, eso todavía no lo convierte en la "mejor opción", ya que hay muchos DSL verdaderamente independientes del idioma que serían lamentablemente inadecuados para las declaraciones de la interfaz de usuario.

Y... ya sabes... flow también viene de fb:

Flow es como TypeScript: un sistema de verificación de tipo estático para Javascript. No es una herramienta React, ni React fue diseñado para usarse con ella. React es ante todo una biblioteca de Javascript, y JSX fue diseñado para usarse con React. Las herramientas y utilidades secundarias que se introduzcan en el desarrollo de React son, en última instancia, irrelevantes para la interoperabilidad de React+JSX.

Por favor, deja de vender argumentos a favor y en contra de extensiones que nunca has usado. Uso JSX todos los días y estoy contento con él ATM, aunque era muy escéptico al respecto. Puedo imaginar que JSX evoluciona en otros patrones, como lo fue con AngularJS.

He usado JSX, y aunque tengo opiniones personales al respecto, deliberadamente he dejado esas opiniones fuera de esta discusión. De hecho, si hubiera leído mis comentarios anteriores, sabría que había elogiado a JSX por revolucionar el desarrollo de la interfaz de usuario en React. Aparte de algunos comentarios levemente tangenciales que hice sobre la penetración de mercado de JSX en su conjunto, mis argumentos han sido específicamente sobre JSX _en Flutter_. Y sobre ese tema, no existe una base práctica para determinar la eficacia de DSX, por lo que todo lo que podemos hacer es examinar cómo se ha implementado JSX en otros lugares, y ese examen no es un buen augurio.

A menos, por supuesto, que también haya estado usando DSX todos los días y pueda informarnos sobre las ventajas prácticas de usar DSX en Flutter.

¿Y tal vez este tema ayude a encontrar un mejor patrón para Dart? DSX es solo una propuesta. Mire el ejemplo de patrón de constructor anterior u otros ajustes de lenguaje presentados aquí. Y, bueno, ¿quizás tu flui es una mejor manera? No sé. Pero averigüémoslo y ayudémonos unos a otros a mejorar sus sugerencias en lugar de discutir sobre cosas malas en la propuesta de otra persona.

_Eso es lo que estoy haciendo._ DSX se propone como una solución de interfaz de usuario para personas familiarizadas con JSX. Hay elementos de diseño clave en JSX que estaban destinados a usarse en un entorno completamente diferente de Dart y Flutter. _Es necesario abordar esas diferencias para que DSX tenga éxito._ No estoy siendo un _odiador_. Estoy tratando de promover una discusión constructiva y hacer las preguntas importantes. Sin embargo, todas las respuestas que he estado recibiendo equivalen a una tautología subjetiva ("JSX es bueno porque es el futuro, y es el futuro porque es bueno"), gestos desdeñosos de puntos de diseño cruciales ("DSX no necesita tener en cuenta por las diferencias entre JS y Dart porque no hay ninguna"), o simplemente hostil ("Obviamente no te gusta JSX, así que deja de hablar de DSX").

No haces un producto exitoso únicamente con elogios sin adulterar. También debe hacer frente a las críticas y dar cuenta de ellas. Las personas que aparecen y dicen "Dios mío, sí, por favor, haz DSX", aunque son alentadoras, no son útiles. Ha habido varias personas a lo largo de este hilo que han planteado críticas perfectamente válidas de DSX, tanto con su diseño inicial como con el concepto en su conjunto. Y en su mayor parte, muchas de estas críticas aún no se han abordado directamente, y la actitud general es desdeñosa.

Mi único temor es que todo este amor incondicional por JSX impida que las personas vean DSX de manera objetiva. Entiendo por qué ustedes quieren algo como JSX en Flutter, y puedo relacionarme: mi opinión de que Flutter necesita un DSL de interfaz de usuario dedicado es lo que me llevó a crear flui. Pero si las únicas personas a las que se les permite hablar sobre DSX son las personas que solo tienen cosas buenas que decir al respecto, entonces fallará.

¿Podemos volver a centrar la discusión sobre este tema?
De hecho, no veo ninguna razón para mantener este tema abierto.

El equipo de Dart declaró que tienen otras prioridades. Y el lado profesional de JSX se ofreció como voluntario para hacer su propia implementación de DSX

Tal vez deberíamos tener algunos repositorios de código abierto que propongan diferentes soluciones (incluso que apenas funcionen). Como DSX, o plantillas.
Y luego considere redirigir desde el archivo Léame o awesome_flutter de Flutter a estos repositorios. Y si hay algo que bloquea la implementación de DSX, cree otro problema con los detalles.

Entonces deja que la comunidad haga su trabajo.

Déjalo abierto como está porque la gente seguirá abriendo nuevos tickets preguntando por JSX (como ya ha pasado dos veces antes).

Déjalo abierto como está porque la gente seguirá abriendo nuevos tickets preguntando por JSX (como ya ha pasado dos veces antes).

La diferencia aquí es que ahora podríamos responder con lo siguiente:

"No planeamos implementar esto en dart/flutter por ahora. Pero puede echar un vistazo a las alternativas de la comunidad [aquí] y [allí] o leer [este número]".

y cierre el problema como duplicado.

Un lugar para comentarios y votos y es aquí. La solicitud de funcionalidad similar a JSX no desaparece y el ticket se abre porque necesita compatibilidad con las herramientas de Flutter (compilador y VS Code IDE) y actualicé la solicitud del ticket con esta información (primer comentario). Si una gran cantidad de personas comienza a pedir esto, le dará al equipo de Flutter un incentivo para invertir recursos en ello.

Parece que la mayor parte de la controversia aquí no se trata de JSX en este momento, sino de DSX. Sugeriría dividir la discusión de DSX en su propio hilo y dejar este genérico para JSX.

Al final, DSX es solo una forma de acercarnos a JSX, por lo que no deberíamos mezclar estas dos discusiones en un solo hilo de todos modos.

Gran no para esto, realmente creo que 1 idioma solo es una gran ganancia, la sintaxis jsx vendrá con más cosas como la separación de xml de js, etc. No es bueno.

esa es mi opinión.

Ese es el problema de Github más largo y sin sentido que he visto.

@cbazza Buen trabajo 👍
DSX + 1

@BarryYan , gracias

Evite este tipo de comentarios, ya sea "+1" o "Gracias".
Esto envía un correo electrónico a todos los suscriptores sin nada interesante.

Evite este tipo de comentarios, ya sea "+1" o "Gracias".
Esto envía un correo electrónico a todos los suscriptores sin nada interesante.

Nada interesante para ti !!!
Evite decirle a la gente lo que pueden decir o hacer y concéntrese solo en lo que puede decir o hacer.

@cbazza

Amigo, es la etiqueta básica. Cualquier mensaje nuevo en este hilo envía correos electrónicos a todos los que están suscritos, por lo que es de mala educación publicar un comentario que no contribuye a la discusión porque molesta a las personas sin motivo alguno. Las reacciones básicas como "+1" y "Gracias" se pueden transmitir con una simple reacción de pulgar hacia arriba, así que solo haz eso.

Dicho esto, si este hilo realmente se ha convertido en una discusión sobre si alguien debe o no publicar un mensaje "+1", es una gran señal de alerta de que toda discusión constructiva ha muerto oficialmente, y realmente debería cerrarse (quizás permanentemente esta vez).

@andrewackerman ,

Lo entiendo, pero mientras estás en eso, quizás también deberías considerar la etiqueta básica mientras explotas este hilo con tus novelas (escritura larga y ficticia).

Deje de difundir FUD (miedo, incertidumbre y duda) con su andanada de preguntas sin sentido (ya sabe, arroje tanta basura en la pared y vea si algo se pega) y demandas.

Después de todos sus escritos, no ha agregado ningún valor a DSX, por lo que no tengo interés en tener una discusión con usted sobre este tema. Sin embargo, su motivo es obvio: promueva FLUI mientras explota DSX.

Dime algo, ¿tienes respuestas a tus propias preguntas cuando se aplican a FLUI? Hablemos un poco de FLUI, ¿de acuerdo?

@cbazza

Lo entiendo, pero mientras estás en eso, quizás también deberías considerar la etiqueta básica mientras explotas este hilo con tus novelas (escritura larga y ficticia).

El hecho de que te refieras a mis respuestas de que invertí mucho tiempo y esfuerzo en ser tan bien pensadas e imparciales como pude como "escritura larga y ficticia" ilustra mucho sobre tu personaje y cómo te estás acercando. esta discusión Estoy tratando de promover la discusión sobre problemas muy reales relacionados con cualquier implementación de JSX en Flutter, mientras criticas a cualquiera con cualquier forma de opinión contraria. ¿Quién de nosotros es el mayor infractor de la etiqueta básica?

Deje de difundir FUD (miedo, incertidumbre y duda) con su andanada de preguntas sin sentido (ya sabe, arroje tanta basura en la pared y vea si algo se pega) y demandas.

Lo único que estoy "exigiendo" es que aborde los numerosos problemas planteados por muchas personas con respecto a DSX con más que un gesto de mano o una abierta hostilidad. Para alguien que propone un cambio/adición significativo al conjunto de características de Flutter, creo que no es una expectativa irrazonable.

Después de todos sus escritos, no ha agregado ningún valor a DSX, por lo que no tengo interés en tener una discusión con usted sobre este tema. Sin embargo, su motivo es obvio: promueva FLUI mientras explota DSX.

Le pido a usted que defienda su posición. Ha dicho repetidamente que JSX/DSX es el mejor/futuro, pero aún tiene que explicar cómo o por qué. Varias personas han expresado preocupaciones válidas sobre DSX, pero en lugar de abordarlas, usted las rechaza escondiéndose detrás del contraargumento "si no le gusta, no lo use". Mi "motivo" es lograr que responda las preguntas que deben formularse con respecto a _cualquier_ proyecto técnico, siendo primero y principal por qué las personas deberían usarlo en lugar de las alternativas. (Y como he explicado antes, la familiaridad no es razón suficiente).

En lo que respecta a FLUI, todo lo que estoy haciendo es proponer una solución alternativa al problema general (sintaxis declarativa de la interfaz de usuario para Flutter) al tiempo que solicito que las personas hagan lo mismo que yo estoy haciendo con DSX: ofrecer críticas sinceras y constructivas. No estoy diciendo que FLUI sea objetivamente mejor que DSX: estoy proponiendo una alternativa formada a partir de un enfoque diferente para el desarrollo de la interfaz de usuario y pidiendo a las personas que se formen sus propias opiniones.

(También me gustaría señalar que, aparte de mi mención inicial en la que proponía un posible enfoque alternativo para la representación de GUI, las únicas veces que he hablado sobre FLUI es cuando lo mencionaste. Entonces, ¿cómo funciona? ¿Tiene sentido que mi motivo ulterior sea promoverlo cuando hablas de eso más que yo?)

Dime algo, ¿tienes respuestas a tus propias preguntas cuando se aplican a FLUI? Hablemos un poco de FLUI, ¿de acuerdo?

FLUI no es DSX: no tiene que responder a _todas_ las preguntas que le planteé sobre DSX porque muchas de ellas son específicas del diseño de DSX. Sin embargo, eso no quiere decir que no tenga su propio conjunto de preguntas que deben responderse, y no, no tengo todas esas respuestas. Es por eso que valoro la discusión crítica: FLUI/DSX no van a hacer frente a la corte de la opinión pública a menos que puedan sobrevivir siendo rastrillados a través de las brasas un par de veces. Sin embargo, este no es el lugar apropiado para discutir FLUI. Si desea analizar FLUI en detalle, el proyecto tiene su propio panel de problemas , así que siéntase libre de publicarlo allí.

En lugar de responder a las críticas, has estado a la defensiva y evasivo, tanto que eres directamente responsable de las dos ocasiones separadas (casi tres) en las que este hilo tuvo que cerrarse temporalmente debido a que las cosas se calentaron demasiado. Así que voy a romper con la "etiqueta" y decir esto una vez: deja de lado tu ego, deja de interpretar las críticas como ataques personales y responde las preguntas importantes. O eso, o hacer las paces con DSX nunca despegando.

andrewackerman Buen trabajo 👍
+ 1

@andrewackerman

Buen trabajo

Amigo, ¿recibiste un cumplido de @jstansbe que transmite mucha más información que un pulgar hacia arriba y un pulgar hacia abajo en el cumplido?

Obviamente no tomaste en serio mi sugerencia sobre la extensión, pero no saques conclusiones sobre mi carácter porque no me conoces en absoluto.

El hecho de que se refiera a mis respuestas que dediqué mucho tiempo y esfuerzo para que fueran lo más bien pensadas e imparciales posible.

Que agradezco y leo todos tus 'escritos largos', contestando todo: ni modo, pero cuando contesto bien no entiendes mi respuesta y concluyes que estoy siendo despectivo.

Es obvio para mí que no tienes mucha experiencia con JSX, realmente no entiendes cómo funciona. Entonces, en lugar de duplicar la inversión, solo aprovéchalo y te lo explicaré con más detalle. Por ejemplo, JSX y DSX solo realizan las siguientes 2 transformaciones (mencionadas varias veces antes):

(1)
<A property="a" />
    becomes
new A(property: a)

(2)
<A property="a">
  <B />
  <C />
</A>
    becomes
new A(property: a, children: <Widget>[new B(), new C()])

Todo lo demás es manejado por el idioma host, por ejemplo: ¿cómo maneja la importación de componentes con el mismo nombre? respuesta: idioma anfitrión. No estoy siendo desdeñoso, es la forma en que está diseñado y la fuente de su fuerza. Verá si separa el marcado y la programación en archivos separados, comienza a duplicar la programación dentro del marcado con construcciones simples para 'si', etc. Termina creando un lenguaje de programación declarativo dentro del marcado que nunca puede ser tan poderoso como el lenguaje de programación principal. Entonces, al llevar el marcado al lenguaje de programación, tiene lo mejor de ambos mundos y ese es el poder de JSX/DSX.

Observe arriba en (2) que la transformación está codificada de forma rígida <Widget> y ese no es siempre el caso, por lo que ahora puede especificarlo si es necesario, como se discutió anteriormente. Mire las transformaciones y ahora todos los símbolos provienen de la fuente o se pueden especificar para que no haya errores mágicos importantes en el futuro.

mientras criticas a cualquiera con cualquier forma de opinión contraria.

Eso no es cierto, puedes tener una opinión contraria pero no puedes afirmar algo cierto cuando puedo probar lo contrario.

Para alguien que propone un cambio/adición significativo al conjunto de características de Flutter, creo que no es una expectativa irrazonable.

Pero esa es la cuestión, quería que el equipo de Flutter implementara DSX, pero luego lo hice, así que lo que necesitan implementar son cosas genéricas que no dependen de DSX y DSX no es el único beneficiario. El motor js del navegador admite mapas de origen que permitieron un ecosistema de nuevos idiomas en el navegador que se transfirió a js; permitió la creación de Dart !!! y varios otros (Coffeescript, Typescript, Reason, etc). Dart podría hacer lo mismo ahora y beneficiarse del ecosistema que ayuda a subir, todos los barcos suben.

Te estoy pidiendo que defiendas tu posición.

Ya lo he hecho muchas veces y la conclusión es que Plain Dart o DSX se reduce a la preferencia del usuario; y lo importante es brindar opciones en lugar de obligar a las personas de una manera.

en primer lugar, es por qué la gente debería usarlo sobre las alternativas.

Usaría DSX porque lo prefiero, como espacios o tabulaciones, escriba la definición antes o después del nombre de la variable. No tiene sentido luchar por ello, solo acepta que las personas tienen preferencias diferentes; hay más de 1 editor de programación por ahí, ¿verdad?

la familiaridad no es razón suficiente

Solo su opinión, ¿por qué usamos declaraciones "if" en casi todos los idiomas, declaración 'for', 'clase' y ahora 'asyn / await'?

Sin embargo, este no es el lugar apropiado para discutir FLUI. Si desea hablar sobre FLUI en detalle, el proyecto tiene su propio panel de problemas, así que no dude en publicarlo allí.

Muy bien, ahora te ganaste mi respeto.

usted es directamente responsable de las dos ocasiones separadas (que se acercan a las tres) en las que este hilo tuvo que cerrarse temporalmente debido a que las cosas se calentaron demasiado.

La cosa es que incluso si se cierra de nuevo, no impedirá que las personas soliciten capacidades similares a JSX.

Deja de lado tu ego, deja de interpretar las críticas como ataques personales y responde las preguntas importantes.

No tengo ego, pero tengo mal genio, por lo que no hay duda cuando alguien me enoja (se nota de inmediato). No es para ofenderte pero tus preguntas no eran importantes.

O eso, o hacer las paces con DSX nunca despegando.

No eres el medidor que se usa para medir el éxito y no sabes lo que estoy haciendo.

Amigo, ¿recibiste un cumplido de @jstansbe que transmite mucha más información que un pulgar hacia arriba y un pulgar hacia abajo en el cumplido?

Aparentemente no te diste cuenta del sarcasmo inherente a su comentario. (Literalmente hizo todo lo que le dije que no hiciera). Si bien es un trolleo divertido que puedo apreciar, no es apropiado aquí. Y si, por casualidad, estaba siendo sincero, entonces me disculpo por mi sarcasmo, pero mi punto sigue en pie: ese tipo de comentario _todavía_ no es apropiado aquí.

Es obvio para mí que no tienes mucha experiencia con JSX...

¿Mi descargo de responsabilidad en mi primer comentario en este hilo quizás te avisó?

...realmente no entiendes cómo funciona.

¿Me comparas sin tener mucha experiencia con JSX y sin saber cómo funciona? Si bien nunca he trabajado en ningún proyecto serio de React, he hecho mi parte justa de retoques. Entiendo perfectamente bien cómo _funciona_.

Todo lo demás es manejado por el idioma host, por ejemplo: ¿cómo maneja la importación de componentes con el mismo nombre? respuesta: idioma anfitrión.

Y eso tiene sentido en el caso de que el lenguaje de marcado y el lenguaje anfitrión sean distintos. Con JSX, el lenguaje de marcado está diseñado como una _extensión_ del lenguaje host. Como tal, JSX fue diseñado como una extensión de JS, y es por eso que funciona tan bien como lo hace. DSX es una implementación de JSX para Dart.

¿No ves el problema ahí? Un lenguaje de marcado diseñado como una extensión de un lenguaje que se transforma en un lenguaje fundamentalmente diferente. Es _inevitable_ que haya un montón de problemas, casos extremos y consideraciones.

Verá si separa el marcado y la programación en archivos separados, comienza a duplicar la programación dentro del marcado con construcciones simples para 'si', etc. Termina creando un lenguaje de programación declarativo dentro del marcado que nunca puede ser tan poderoso como el lenguaje de programación principal.

Primero, la idea detrás de separar el marcado y la programación es que, si lo está haciendo correctamente, hay una separación clara entre los dos que resulta en _no_ duplicación.

En segundo lugar, si está haciendo algo mucho más complejo que if s y for s en su código de interfaz de usuario (que son construcciones que se pueden manejar fácilmente en muchas soluciones de marcado), entonces diría que es una señal de que hay algo mal en tu diseño de todos modos. De acuerdo con los principios de diseño de MVC/MVVM, si está incorporando una lógica compleja en sus construcciones de interfaz de usuario, eso es una señal potencial de código maloliente y debería considerar seriamente un rediseño de todos modos.

(Eso no quiere decir que no pueda escribir una interfaz de usuario declarativa al estilo de MVVM usando JSX, pero es algo que genera problemas por poca ganancia objetiva. ¿Por qué usar algo en lo que puede escribir código que cumpla con los estándares cuando puede usar algo que hace que sea difícil escribir código que _no_?)

Eso no es cierto, puedes tener una opinión contraria pero no puedes afirmar algo cierto cuando puedo probar lo contrario.

No has "probado" nada. Ha dado un montón de afirmaciones subjetivas que aún no se han respaldado con ninguna lógica de respaldo. (Aunque para su crédito, esta última publicación es una gran mejora).

Pero esa es la cuestión, quería que el equipo de Flutter implementara DSX, pero luego lo hice, así que lo que necesitan implementar son cosas genéricas que no dependen de DSX y DSX no es el único beneficiario.

Todavía les estás pidiendo que hagan cosas no triviales, por lo que la responsabilidad recae en ti para convencerlos a ellos y al resto de nosotros de por qué deberían hacerlo y por qué es tan importante que deban dejar otras cosas en su lista de tareas pendientes.

El motor js del navegador admite mapas de origen que permitieron un ecosistema de nuevos idiomas en el navegador que se transfirió a js; permitió la creación de Dart !!!

Está en la naturaleza de JS en sí mismo que tal cosa es fácilmente factible (en términos relativos), tanto que Dart está lejos de ser el único lenguaje que tiene un transpiler para JS. Como he señalado muchas veces, Dart no es JS. Es estático y fuertemente tipado, lo que significa que muchas cosas que serían fáciles de hacer en JS son enormemente complejas en Dart.

Usaría DSX porque lo prefiero, como espacios o tabulaciones, escriba la definición antes o después del nombre de la variable. No tiene sentido luchar por ello, solo acepta que las personas tienen preferencias diferentes; hay más de 1 editor de programación por ahí, ¿verdad?

Según esa lógica, debería crear una solución de interfaz de usuario en la que defina construcciones utilizando braille codificado en hexadecimal. Quiero decir, si todo lo que realmente importa es la preferencia personal, todo lo que necesito decir para defender su existencia es que "algunas personas lo prefieren", ¿no?

Está desarrollando una herramienta que tiene la intención de que otras personas usen, por lo que necesita un razonamiento más allá de "a algunas personas les puede gustar" para ser convincente. Si no puede ponerlo en palabras _por qué_ deberían usarlo sobre otra cosa, entonces ¿qué le hace creer que lo harán? ¿Y qué hay para incentivarlo a _garantizar_ que lo harán al diseñar el conjunto de funciones de DSX?

Solo su opinión, ¿por qué usamos declaraciones "if" en casi todos los idiomas, declaración 'for', 'clase' y ahora 'async / await'?

Primero, esas palabras clave (aparte de async/await ) se convirtieron en un léxico de programación común debido a la inmensa popularidad de lenguajes como C y BASIC a lo largo de varias décadas. Como mencioné antes, JSX está lejos de demostrar su longevidad: ha existido durante 5 años y aún no se ha visto ningún uso significativo fuera de React a pesar de que la opción está disponible.

En segundo lugar, hay una gran diferencia entre familiaridad y convención. if , while , for , struct , class , enum , try/catch/finally , async/await ... todas esas son excelentes maneras de representar verbalmente un concepto. Hay razones para defender el uso de esas palabras clave más allá de que solo son aquello con lo que la gente está familiarizada: tienen sentido conceptual. (Por supuesto, eso no significa que sean constantes. Algunos idiomas hacen if ... then . Algunos hacen if ... elif mientras que otros hacen if ... else if y otros hacen if...endif . Algunos hacen foreach , otros hacen from . Y así sucesivamente.)

Mientras tanto, el argumento para usar JSX porque es "familiar" no encaja en la misma categoría. JSX es una forma de representar la interfaz de usuario declarativa, pero no es la única ni la más popular. Además, fue diseñado para usarse en un tipo de entorno, por lo que usarlo en otro entorno puede convertir la familiaridad en algo malo: la familiaridad los lleva a esperar que funcione más o menos exactamente de la misma manera que funciona en otros lugares, por lo que si entonces eso lleva a una desconexión mental que es algo que quieres _evitar_.

La cosa es que incluso si se cierra de nuevo, no impedirá que las personas soliciten capacidades similares a JSX.

Lo solicitan de todos modos, y el problema se redirige aquí de todos modos. No veo cómo el hilo que se cierra cambiaría eso.

No eres el medidor que se usa para medir el éxito y no sabes lo que estoy haciendo.

Lee cualquier libro sobre diseño de productos. El capítulo uno siempre se trata de crear una declaración, un manifiesto, un eslogan, cualquier cosa tangible y expresable en un lenguaje sencillo que describa qué es el producto y por qué la gente debería preocuparse por él. Hay una razón por la que la forma más común de consejo que se da a los empresarios aficionados es hacer un "discurso de ascensor", algo que comunique de forma clara y concisa el producto y el sorteo en 30 segundos o menos. Si no puede decir de manera sucinta por qué la gente debería usar su producto, es una señal de que está sufriendo una crisis de identidad. Si la persona que diseña el producto no puede responder adecuadamente a las críticas, eso da la impresión de falta de fe en su propio producto. Ambas cosas son grandes señales de alerta para los inversores.

En esta situación, el producto es DSX y los inversores son desarrolladores que están considerando usarlo. Las únicas personas que te respaldan son personas que aparentemente alentarían incondicionalmente cualquier cosa con "JSX" en la descripción. Todas las demás personas en este hilo que he visto cuestionar lo que estás haciendo se han ido aparentemente sin estar convencidas después de tu respuesta.

Actualmente se encuentra en una tasa de conversión del 0 % o cerca de ella, y _es_ de donde vengo cuando digo que aún tiene que responder adecuadamente a las críticas. Tal vez no le importe, pero si tiene la intención seria de que DSX sea un complemento de marcado de declaración de interfaz de usuario utilizable y utilizado en proyectos del mundo real, es posible que desee comenzar.

Pero, de nuevo, tal vez seas una excepción.

Ok, esta conversación ha ido mucho más allá de los tipos de discusiones que consideramos aceptables en la comunidad de Flutter, por lo que cerraré este hilo y cerraré el error. Considere leer https://flutter.io/design-principles/#conflict -solution para obtener más detalles sobre cómo nos comportamos aquí.

El siguiente paso, si alguien quiere contribuir con código para abordar este problema, sería idear un diseño sobre cómo hacer la integración del sistema de compilación, de modo que podamos hacer que la generación de código funcione con Gradle, Xcode, la recarga en caliente y la integración con las aplicaciones existentes. Si alguien está interesado en trabajar en esto, no dude en comunicarse conmigo. De lo contrario, espero que esto sea algo en lo que trabajaremos a principios del próximo año. Una vez que tengamos un mecanismo para hacerlo, las soluciones como DSX serán fáciles de integrar en el ecosistema de Flutter. Incluso podemos encontrar soluciones que deberían estar integradas por defecto. Mientras tanto, también estamos trabajando en mejoras a la sintaxis de Dart para ver si podemos hacer que las expresiones de la interfaz de usuario sean aún más fáciles de escribir.

Me gustaría pedirles a las personas que no abran nuevos errores sobre este tema a menos que haya algo muy constructivo y nuevo que valga la pena mencionar.