cc @lukechurch

@cbazza Você pode explicar por que você quer isso? Talvez mostrar um exemplo de como seria comparado a hoje?

Ok, então o exemplo "Widgets básicos" em ' https://flutter.io/widgets-intro/#basic -widgets' ficaria assim:

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/>}
  />);
}

Que tal essa sintaxe?:

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, uma pequena melhora, mas não tão boa...
Aqui estão as coisas que são realizadas usando XML:
(1) Chega de coisas de 'criança' e 'crianças'
(2) fácil para ferramentas de terceiros manipularem (analisar, analisar e regenerar)
(3) observe que a alternância entre marcação e programação é facilmente detectada. Quero dizer, dentro do XML você tem '{}' para delimitar o código e no código você tem ' Também separe todas as coisas de 'estilo' da estrutura principal.
Eu sei que isso é basicamente endossar totalmente o caminho do React, mas você está no meio do caminho de qualquer maneira;)

cc @kasperl

(1) Chega de coisas de 'criança' e 'crianças'

Eu realmente não entendo por que isso é desejável. "criança" e "crianças" não são especiais. Considere ListTile por exemplo. Como você faria isso? Por que "icon" em IconButton, ou "home" em MaterialApp, é algo para o qual você deseja dar um nome, mas não "filho" em Expanded? Todos os três são apenas argumentos arbitrários que usam objetos Widget. Não há nada mágico sobre "criança" versus "casa".

(2) fácil para ferramentas de terceiros manipularem (analisar, analisar e regenerar)

Você pode analisar, analisar e gerar novamente o código Dart. Mas concordo que deveríamos tornar isso mais fácil. Espero que nos próximos anos a equipe do Dart forneça APIs melhores para isso.

(3) observe que a alternância entre marcação e programação é facilmente detectada.

Por que isso é desejável? Quero dizer, por que isso contaria como "programação"? É tudo apenas expressões.

Quero dizer, dentro do XML você tem '{}' para delimitar o código e no código você tem '

Eu realmente não entendo a distinção.

Também separe todas as coisas de 'estilo' da estrutura principal.

Você pode fazer isso hoje no Flutter se realmente quiser, basta colocar o estilo em uma variável como você fez no caso do XML.

Eu realmente não entendo por que isso é desejável. "criança" e "crianças" não são especiais. Considere ListTile por exemplo. Como você faria isso? Por que "icon" em IconButton, ou "home" em MaterialApp, é algo para o qual você deseja dar um nome, mas não "filho" em Expanded? Todos os três são apenas argumentos arbitrários que usam objetos Widget. Não há nada mágico sobre "criança" versus "casa".

Menos clichê, você não precisa dizer isso porque é herdado na estrutura.

Por que isso é desejável? Quero dizer, por que isso contaria como "programação"? É tudo apenas expressões.

Está relacionado a (2) porque torna a vida dos fabricantes de ferramentas, especialmente os construtores de GUI, muito mais fácil, pois eles não precisam analisar completamente o Dart; mas também facilita a leitura do código.

Eu realmente não entendo a distinção.

O formato do XML é muito simples, então quando você vê '{}' você sabe que está calculando uma expressão em dart. O mesmo para o oposto, ao ler o código do dardo e você vê ') você sabe que uma hierarquia de objetos está sendo criada a partir da marcação XML.

Também no processador XML final, eu evitaria passar objetos para atributos de pais e, em vez disso, criaria tags filhas como abaixo:

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 clichê, você não precisa dizer isso porque é herdado na estrutura.

Mas por que apenas para algumas das propriedades? E como você lida com casos em que há dois slots filho, como ListItem? A sintaxe XML parece não lidar muito bem com isso.

Também não tenho certeza se é menos clichê.

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

Não está claro para mim se a sintaxe XML é mais limpa ou menos clichê. Há muito mais pontuação e alguma duplicação de conteúdo (por exemplo, nas tags de fechamento). E você teve que adicionar alguns nomes, então com certeza, você perde "filho", mas ganha "nome" no ícone.

Também com XML como você deixa claro que Row pode ter zero, um ou mais de um filho, enquanto o Center precisa ter exatamente um filho? O que aconteceria se alguém fizesse isso?:

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

Está relacionado a (2) porque torna a vida dos fabricantes de ferramentas, especialmente os construtores de GUI, muito mais fácil, pois eles não precisam analisar completamente o Dart;

Eles também não precisariam analisar completamente o Dart se tivéssemos uma API de análise do Dart, certo? Quero dizer, você analisaria o que deseja analisar e deixaria o resto. Também não tenho certeza se é realmente mais fácil de analisar, já que não é realmente XML; ver abaixo.

mas também facilita a leitura do código.

Não estou convencido de que a versão XMLy aqui seja mais fácil de ler. Depois de ler algumas funções de compilação, você se acostuma rapidamente com a sintaxe do construtor aninhado.

O formato do XML é muito simples, então quando você vê '{}' você sabe que está calculando uma expressão em dart.

Na verdade, não é XML, certo? É alguma variante do XML. Existem regras de análise bem definidas para isso? Por exemplo, isso é válido?

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

Como ele sabe que o primeiro "}" não é o final da expressão de atributo, sem analisar o Dart?

O mesmo para o oposto, ao ler o código do dardo e você vê ') você sabe que uma hierarquia de objetos está sendo criada a partir da marcação XML.

Você sabe disso hoje quando vê a palavra-chave new também, certo? Ou, de fato, na proposta de marcação sem novo acima, quando você vê qualquer palavra em maiúscula. Isso é realmente um benefício do XML ou você está mais familiarizado com XML do que com o Dart?

Também no processador XML final, eu evitaria passar objetos para atributos de pais e, em vez disso, criaria tags filhas como abaixo:

Eu realmente não entendo o que você está propondo aqui. Não é XML bem formado, tanto quanto posso dizer. Você pode explicar exatamente qual é a sintaxe que você está propondo e como ela funciona? Por exemplo, o construtor "Texto" parece ter desaparecido; como o processador sabe disso

Olha, você está misturando tudo o que eu digo e essa conversa não vai a lugar nenhum. Em termos legais, você está "Badicando a testemunha".

Se você está realmente interessado em saber por que o JSX é quente, apenas pesquise no Google por "tutorial de reação" e observe que nos últimos 2 anos todos os artigos sobre React usam JSX. A maneira original de criar hierarquias de componentes em React (que é equivalente à forma atual em Flutter) nunca mais é mencionada porque JSX se tornou o método preferido (melhor prática).

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

Outra coisa interessante é que o Typescript também adotou o JSX:
https://www.typescriptlang.org/docs/handbook/jsx.html

Você não conseguiu entender que a análise XML (com algum código extra para pular '{}' corretamente) é muito mais simples do que analisar completamente uma linguagem de programação como Dart. Isso é um fato. Você está assumindo que os construtores de ferramentas usarão o Dart em seu desenvolvimento, não o caso, o Intellij provavelmente está usando Kotlin e Java em seus IDEs que suportam o Dart (eles são um caso especial porque se especializam em análise de linguagem; todos os outros terão dificuldade para analisar o Dart de outro idioma).

O que eu gosto em colocar o XML dentro de outra linguagem é que ele fornece uma separação cognitiva entre os dois porque o XML é muito diferente das linguagens de programação. Apenas percorrendo o arquivo de origem, você pode ver facilmente o que é código e o que é marcação declarativa. Não é possível fazer isso com código de dardo fingindo ser marcação.

Pare de criticar coisas que não estão totalmente especificadas. Todas as suas dúvidas foram respondidas, basta saber mais sobre como isso foi tratado no JSX. Eu simplesmente não tenho tempo para isso aqui.

Minhas desculpas se pareço defensivo ou agressivo. Este é um tópico que surgiu várias vezes, mas eu nunca tive alguém disposto a realmente discutir o caso antes, então eu estava achando essa conversa muito útil para me ensinar qual era o raciocínio por trás do pedido. Por favor, não tome meu tom argumentativo como desdenhoso, estou muito interessado em sua opinião aqui.

Por favor, não se sinta obrigado a responder. Estou comentando aqui para que haja transparência em relação aos problemas que teríamos que resolver antes de podermos tomar uma decisão ou projetar de uma forma ou de outra. Este é basicamente apenas um diálogo socrático. Sua participação é bem-vinda, mas certamente você não deve sentir que é sua responsabilidade defender sua proposta.

Não tenho dúvidas de que o JSX é "quente". No React, a sintaxe não-JSX é muito pior do que a sintaxe alternativa proposta nesta edição (aquela que se parece com nosso código atual, mas sem as palavras-chave "new" e "const"). O que estou tentando entender é se as mesmas razões pelas quais o JSX é "quente" no React se aplicam ao Flutter.

Em relação ao TypeScript fazendo JSX, em 2012 estive envolvido nos esforços para especificar o E4H , e antes mesmo disso havia o E4X . Ambos os esforços morreram. Portanto, é importante para mim que entendamos exatamente o que as pessoas gostam sobre JSX versus outras sintaxes.

Analisar XML não é fácil, analisar tipo-de-XML-mas-com-chaves-de alguma forma também não é fácil. Analisar tipo-de-XML-mas-com-chaves-de alguma forma-que-está-embutido-em-outra-linguagem é ainda menos fácil. No entanto, a facilidade de implementação provavelmente não é grande coisa, porque será implementado uma ou duas vezes e, em seguida, a biblioteca que o fizer será reutilizada. (Eu estive muito envolvido em escrever as especificações para analisar HTML e estive envolvido em trabalho semelhante para XML, e implementei um analisador para Dart, então tenho uma boa ideia de como é difícil analisar linguagens de marcação versus linguagens de programação realmente é.)

O que eu gosto em colocar o XML dentro de outra linguagem é que ele fornece uma separação cognitiva entre os dois porque o XML é muito diferente das linguagens de programação. Apenas percorrendo o arquivo de origem, você pode ver facilmente o que é código e o que é marcação declarativa. Não é possível fazer isso com código de dardo fingindo ser marcação.

Mas por que é benéfico poder fazer isso?

É bastante óbvio ao percorrer os aplicativos Flutter onde estão as funções de compilação (elas são as expressões aninhadas gigantes). O que há na "marcação declarativa" que é importante separar do "código"?

Pare de criticar coisas que não estão totalmente especificadas. Todas as suas dúvidas foram respondidas, basta saber mais sobre como isso foi tratado no JSX. Eu simplesmente não tenho tempo para isso aqui.

Tanto quanto posso dizer, o JSX não lida com as coisas que eu estava perguntando. Por exemplo, o React não tem o conceito de slots filhos. A coisa mais próxima que pude encontrar é algo que eles fazem voltando para JS e depois para JSX dentro disso, então você precisa ser capaz de analisar a linguagem de programação e a linguagem de marcação.

O que estou tentando entender é se as mesmas razões pelas quais o JSX é "quente" no React se aplicam ao Flutter.

Sim, a mesma coisa se aplica aqui. A maneira atual parece boa para você porque essa é a única opção que você tem. Dê às pessoas uma segunda opção e o mesmo acontecerá.

Se E4X morreu ou não é irrelevante porque nada vive para sempre. Eu usei muito o ActionScript com o E4X e achei que a Adobe fez um excelente trabalho lá. De certa forma, o Flutter é apenas uma versão mais recente do Adobe Flash com aplicativos Flex.

(Eu estive muito envolvido em escrever as especificações para analisar HTML e estive envolvido em trabalho semelhante para XML, e implementei um analisador para Dart, então tenho uma boa ideia de como é difícil analisar linguagens de marcação versus linguagens de programação realmente é.)

Ótimo, então você sabe que analisar uma linguagem de marcação é trivial comparado a analisar uma linguagem de programação imperativa.

Mas por que é benéfico poder fazer isso?

A legibilidade e a simplicidade do código que, por sua vez, geram vários outros benefícios.

É bastante óbvio ao percorrer os aplicativos Flutter onde estão as funções de compilação (elas são as expressões aninhadas gigantes). O que há na "marcação declarativa" que é importante separar do "código"?

Em suas expressões aninhadas gigantes, você pode ver facilmente a estrutura? essa estrutura pode ser facilmente manipulada por outras ferramentas como construtores de GUI alternadamente? Quero dizer, como o Adobe Flex Builder costuma fazer, arrastar e soltar widgets, conectá-los à interface do usuário e depois alternar para a visualização de código e editar o que quiser e depois voltar para o modo gui e continuar a manipular os widgets. Você não pode fazer isso facilmente quando o programador entra em suas "expressões aninhadas gigantes" e escreve qualquer código de dardo válido que não siga a estrutura que o editor de GUI está esperando. Com uma estrutura XML fixa isso não é um problema.

Tanto quanto posso dizer, o JSX não lida com as coisas que eu estava perguntando. Por exemplo, o React não tem o conceito de slots filhos

Ele lida bem com isso, você só não sabe como fazê-lo. Então, daqui para frente, basta colocar o exemplo em questão aqui e eu fornecerei a você o que eu acho que a versão JSX deveria ser.

  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 mais longo do que a versão de dardo, mas eu poderia ter colocado tudo no mesmo número de linhas. O problema é que um IDE/Editor pode fornecer '+' e '-' para expandir e recolher esses nós XML de qualquer maneira.

Faça o Flutter parecer familiar para os desenvolvedores do React e você terá a chance de atrair um monte de novos usuários para o Flutter.

Se E4X morreu ou não é irrelevante porque nada vive para sempre.

Se morreu não é o problema, é por isso que morreu. Ele morreu porque não forneceu uma solução que as pessoas queriam? Ele morreu por causa de problemas de implementação? Ele morreu por causa de problemas de patente? Foi muito cedo? Muito tarde? Eu acho que é importante aprender lições de experiências passadas. Por que o E4X e o E4H falharam onde o JSX teve sucesso?

O que acho interessante é que as pessoas que são novas no Flutter costumam pedir duas coisas: uma linguagem de marcação e GIFs animados. Depois de três meses, eles ainda pedem GIFs animados, mas não uma linguagem de marcação. Pode ser que isso ocorra porque a linguagem de marcação não é realmente necessária quando você está acostumado a escrever métodos de compilação no Dart. Pode ser que eles ainda queiram uma linguagem de marcação, mas tenham contornado a omissão e, portanto, não pensem em perguntar mais. Vale a pena descobrir qual porque, caso contrário, corremos o risco de gastar esforço em algo que é a escolha errada (em qualquer direção).

Em suas expressões aninhadas gigantes, você pode ver facilmente a estrutura?

Sim, pelo menos tão facilmente quanto com XML. Pessoalmente, acho o XML muito detalhado e ofusca a estrutura. Mas acho que isso é mais sobre o que você está acostumado.

(Também estamos experimentando com IDEs que colocam comentários virtuais de "tag de fechamento" para que você possa ver a estrutura sem precisar escrevê-la.)

Ótimo, então você sabe que analisar uma linguagem de marcação é trivial comparado a analisar uma linguagem de programação imperativa.

Minha experiência é que declarativo versus imperativo não é a distinção que importa quando se trata de determinar quão fácil é analisar uma linguagem. (Por exemplo, HTML é "declarativo", mas pode estar entre as linguagens mais complicadas de analisar com as quais já lidei.)

A legibilidade e a simplicidade do código que, por sua vez, geram vários outros benefícios.

Se este é o principal benefício, então isso é algo que podemos testar. Poderíamos pegar uma mistura de engenheiros que estão acostumados a escrever HTML, React, código iOS, código Android, Flutter, aplicativos de linha de comando e assim por diante, e apresentá-los a cada um com várias sintaxes e pedir que descrevam o que eles acham que o UI resultante seria. Podemos então medir qual sintaxe obtém os melhores resultados. @InMatrix isso é algo que podemos analisar depois que o trabalho de animação terminar, talvez?

essa estrutura pode ser facilmente manipulada por outras ferramentas como construtores de GUI alternadamente?

Sim, pelo menos em princípio. Deve ser relativamente simples converter mecanicamente expressões Dart para XML ou JSON ou qualquer outra linguagem estruturada que se possa usar. É apenas uma questão de converter a sintaxe, a informação real é a mesma. Pessoalmente, eu não o converteria em uma sintaxe diferente se estivesse fazendo um editor de GUI, apenas o analisaria em uma estrutura de dados na memória diretamente do Dart.

Você não pode fazer isso facilmente quando o programador entra em suas "expressões aninhadas gigantes" e escreve qualquer código de dardo válido que não siga a estrutura que o editor de GUI está esperando. Com uma estrutura XML fixa isso não é um problema.

O problema é que você pode colocar exatamente o mesmo "qualquer código de dardo válido" na estrutura XML que na expressão Dart. Eles são literalmente mecanicamente intercambiáveis. Então, eu realmente não vejo como o uso de XML ajuda com isso particularmente. Por exemplo, como você transformaria isso em XML?:

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

Ele lida bem com isso, você só não sabe como fazê-lo.

Eu quis dizer especificamente JSX. Concordo que sua sintaxe proposta seria uma maneira perfeitamente válida de abordar o problema.

Trabalhei no Flex SDK da Adobe, que combinava marcação XML e ActionScript, nos últimos dois anos em que o produto existia na Adobe. Eu entendo o apelo da marcação para definir UIs, mas também me lembro de algumas desvantagens:

• Os visuais do aplicativo Flex podem ser definidos em termos de marcação e código. Pelo que me lembro, o código tendia a dominar em grandes aplicativos do mundo real. A legibilidade não é necessariamente um benefício para aplicativos definidos como híbridos complexos de marcação e código.
• O IDE "Flex Builder" precisava oferecer suporte a aplicativos definidos por marcação e código. Isso dificultou a construção e manutenção do IDE. Os desenvolvedores tendiam a vê-lo como uma ferramenta ActionScript.
• Evoluir e manter o "compilador" XML era um fardo significativo que mantinha uma equipe de engenheiros ocupada em tempo integral. Manter o compilador e o kit de ferramentas em sintonia retardou a evolução do SDK geral.

Já se passaram anos e não consigo mais me lembrar de todos os detalhes. No entanto, minha impressão geral é que definir UIs com uma combinação de marcação e código é, na melhor das hipóteses, um saco misto.

Se morreu não é o problema, é por isso que morreu. Ele morreu porque não forneceu uma solução que as pessoas queriam? Ele morreu por causa de problemas de implementação? Ele morreu por causa de problemas de patente? Foi muito cedo? Muito tarde? Eu acho que é importante aprender lições de experiências passadas. Por que o E4X e o E4H falharam onde o JSX teve sucesso?

Ele morreu porque o E4X foi implementado apenas no ActionScript, que foi usado apenas dentro do Adobe Flash/Flex e a Adobe matou o projeto. Em vez disso, a Adobe mudou de direção para padrões abertos, onde não há um único provedor de fonte com possibilidade de bloqueio e implosão do ecossistema.

O que eu acho interessante é que as pessoas que são novas no Flutter geralmente pedem duas coisas: uma linguagem de marcação e GIFs animados. Depois de três meses, eles ainda pedem GIFs animados, mas não uma linguagem de marcação. Pode ser que isso ocorra porque a linguagem de marcação não é realmente necessária quando você está acostumado a escrever métodos de compilação no Dart. Pode ser que eles ainda queiram uma linguagem de marcação, mas tenham contornado a omissão e, portanto, não pensem em perguntar mais. Vale a pena descobrir qual porque, caso contrário, corremos o risco de gastar esforço em algo que é a escolha errada (em qualquer direção).

Bem, se eu lhe pedisse 2 coisas e você não fizesse nenhuma em 3 meses e houvesse uma alternativa à primeira, eu também pediria apenas o que é totalmente impossível de fazer, dada sua capacidade de resposta e desempenho de entrega anterior.

(Também estamos experimentando com IDEs que colocam comentários virtuais de "tag de fechamento" para que você possa ver a estrutura sem precisar escrevê-la.)

Meio engraçado, mas é como colocar a tag de fechamento XML que você mencionou antes era muito detalhado.

Se este é o principal benefício, então isso é algo que podemos testar. Poderíamos pegar uma mistura de engenheiros que estão acostumados a escrever HTML, React, código iOS, código Android, Flutter, aplicativos de linha de comando e assim por diante, e apresentá-los a cada um com várias sintaxes e pedir que descrevam o que eles acham que o UI resultante seria. Podemos então medir qual sintaxe obtém os melhores resultados. @InMatrix isso é algo que podemos analisar depois que o trabalho de animação terminar, talvez?

Claro que você pode fazer isso vá em frente, tenho certeza que você descobrirá que "Depois de fazer React (com JSX), você simplesmente não volta mais". Pesquise desenvolvedores experientes em React e pergunte se eles acham que JSX é ruim e nunca deveria ter sido feito. Mostre seu caminho e pergunte se eles querem substituir o JSX pelo que você tem. Antes de fazer isso, feche as portas e tranque o lugar, porque esses desenvolvedores vão pegar suas coisas e correr para a saída mais próxima.

O problema é que você pode colocar exatamente o mesmo "qualquer código de dardo válido" na estrutura XML que na expressão Dart.

Claro, mas para os construtores de GUI, isso é apenas um bloco de bytes que não precisa ser tocado e pode ser facilmente ignorado. Tornando a intercambialidade de design/código praticamente possível em vez de em princípio.

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>

Eu usei o Adobe Flex Builder extensivamente...

Os desenvolvedores tendiam a vê-lo como uma ferramenta ActionScript.

Sim, mas muitas vezes mudei da visualização de design para a visualização de código e vice-versa.
Iniciando uma tela, eu iria para a visualização de design e usaria arrastar/soltar para layout de widgets e gerar a primeira tela estática. Então eu adicionaria código e alguns dados estáticos para preencher a tela para que eu pudesse mostrar às pessoas algo em execução que parecesse coisas prontas para produção. A produtividade foi incrível. À medida que o desenvolvimento progredia, conectei o front-end ao back-end e a quantidade de código ActionScript cresceu e sim, ele dominou o código geral, mas mesmo perto do tempo de lançamento, muitas vezes usei a visualização de design para ajustar a interface do usuário sem precisar pesquisar código.

No entanto, minha impressão geral é que definir UIs com uma combinação de marcação e código é, na melhor das hipóteses, um saco misto.

Não no mundo de hoje. As linguagens imperativas evoluíram na filosofia do Python e são ótimas para o desenvolvimento. Técnicas declarativas com marcação incorporada (XML) tornaram-se populares com o advento do React; e JSON tornou-se o formato de dados baseado em texto preferido.

E4X foi implementado apenas no ActionScript

E4X era um padrão ECMA. A Mozilla o enviou por um tempo, mas depois o removeu (uma jogada muito incomum para um fornecedor de navegadores). Outros fornecedores de navegadores nunca quiseram implementá-lo. (No entanto, eles implementaram outros novos recursos do ECMA.) Com o E4H, os fornecedores de navegadores nunca se interessaram em implementá-lo (embora, novamente, eles tenham implementado muitas outras coisas que ajudei a inventar).

Bem, se eu lhe pedisse 2 coisas e você não fizesse nenhuma em 3 meses e houvesse uma alternativa à primeira, eu também pediria apenas o que é totalmente impossível de fazer, dada sua capacidade de resposta e desempenho de entrega anterior.

Essa é uma teoria possível. As pessoas tendem a pedir muitas outras coisas além disso, e muitas das coisas que pedem são implementadas, e há soluções alternativas para GIFs animados também, então não tenho certeza se isso explica totalmente a situação.

Meio engraçado, mas é como colocar a tag de fechamento XML que você mencionou antes era muito detalhado.

De fato. Este é um recurso de IDE opcional e que você não precisa escrever no código, o que faz uma grande diferença se a verbosidade é um problema.

... ListView ...

Como um editor de GUI lidaria com essa marcação? Eu realmente não entendo como visualizar a interface do usuário para isso.

Isso pode ser um contra-argumento para essa solicitação e/ou talvez alguns insights a serem lembrados se você quiser marcação. Tenho fortes sentimentos de que adicionar marcação criando alguns desafios com o GWT eu odiaria ver outra API passar.

Eu vi alguns outros frameworks passarem por essa transição em relação à construção da interface do usuário. Marcação como essa funciona muito bem para ferramentas, na medida em que é celestial para os desenvolvedores de IDE. É mais fácil separar as responsabilidades de quem faz o quê. Embora eu ache que pode ser feito melhor.

O GWT começou assim, construindo interfaces de usuário com Java. Então veio o UiBinder, onde você poderia construir a interface do usuário em marcação xml, com uma especificação. Em seguida, o conjunto de ferramentas, Eclipse Plugin, foi capaz de gerar UI's em marcação xml. O Android também está fazendo isso, não há necessidade de detalhar o ponto. Então, o que eu vi acontecer, a marcação funciona muito bem para desenvolvedores de IDE de interface do usuário. Mas, na verdade, a marcação é um enorme investimento em tempo e ferramentas de complexidade adicional para fazer a transição para o programa real. E o ferramental é sempre o último a chegar. Então, enquanto isso, enquanto tudo isso se manifesta na realidade, existem dois mundos. Duas maneiras interessantes de fazer tudo. Um no idioma padrão e outro na marcação. Então eu apoio o GWT hoje. Quando escrevo documentação, tenho que escrevê-la duas vezes, uma para Java e outra para UiBinder XML Markup. Portanto, a verdadeira questão, se você quiser seguir o caminho da marcação, acho que a pergunta deve ser feita, é a complexidade adicional que vale a jornada!

JSX eu acho que visa resolver outros problemas onde você quer misturar o que está fazendo com HTML e javascript. Realmente não parece que a complexidade adicional da especificação de marcação atende às necessidades de escrever UI com marcação. Especialmente quando você realmente não tem uma linguagem de marcação de documento como destino. Pelo menos não para o usuário comum.

Em uma nota positiva. Gosto de trabalhar com ferramentas. Então eu posso ver uma linguagem de marcação sendo bastante útil. É muito mais fácil escrever e modificar AST ao usar marcação.

Mas, novamente, se você tem mente suficiente no trabalho, não importa o que você faz. No final do dia, se o desenvolvedor puder escrever seu aplicativo mais rapidamente com sua API, você terá tração. Mas a que custo para a equipe de engenharia.

Acho que a verdadeira questão é como a interface do usuário pode ser construída mais rapidamente. Acho que as ferramentas poderiam escrever o dardo, pular qualquer marcação de intermediário. E meu objetivo não é realmente dizer que não vale a pena, mas realmente contar o custo em todas as frentes se a estrada for tomada!

E4X era um padrão ECMA. A Mozilla o enviou por um tempo, mas depois o removeu (uma jogada muito incomum para um fornecedor de navegadores). Outros fornecedores de navegadores nunca quiseram implementá-lo.

Eu diria que apenas a Adobe defendeu totalmente o E4X e teve bons seguidores com os desenvolvedores. Os fornecedores de navegadores adicionam e removem coisas de seus navegadores o tempo todo; O Google não removeu o suporte ao MathML?

Essa é uma teoria possível. As pessoas tendem a pedir muitas outras coisas além disso, e muitas das coisas que pedem são implementadas, e há soluções alternativas para GIFs animados também, então não tenho certeza se isso explica totalmente a situação.

Aqui está a coisa sobre React e JSX. você realmente não aprecia totalmente o que o React traz para a mesa até desenvolver com ele por um tempo, então se torna noite e dia contra todos os outros frameworks.

Como um editor de GUI lidaria com essa marcação? Eu realmente não entendo como visualizar a interface do usuário para isso.

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

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

Eu representaria o \como um retângulo e se for filho/filhos onde outros widgets eu colocaria retângulos para isso dentro dele.
Como o filho neste caso é uma função, você pode simplesmente colocar um retângulo dizendo 'uneditable/code' para informar aos usuários que este widget é criado a partir do código ou, neste caso, deduzir facilmente que a função é um wrapper superficial para owidget e simplesmente apresente isso; Refiro-me a um retângulo que diz que a função é um wrapper de função superficial e dentro dele o retângulo de widget de item de lista (\nesse caso).

Mas, na verdade, a marcação é um enorme investimento em tempo e ferramentas de complexidade adicional para fazer a transição para o programa real.

Tudo o que estou pedindo é adicionar essas extensões simples no compilador Dart para que, se os desenvolvedores quiserem, possam escrever usando essa estrutura XML. A maneira antiga continuaria a funcionar e a quantidade de trabalho envolvida para fazer isso não é enorme. Você pode realmente ver quantas linhas de código são necessárias para o compilador babel.js fazer JSX e estou falando centenas e não milhares de linhas (acabei de verificar).

E o ferramental é sempre o último a chegar. Então, enquanto isso, enquanto tudo isso se manifesta na realidade, há dois mundos. Duas maneiras interessantes de fazer tudo. Um no idioma padrão e outro na marcação

Claro, mas o React tem sido assim e isso não é um problema.

Quando escrevo documentação, tenho que escrevê-la duas vezes, uma para Java e outra para UiBinder XML Markup.

Não em React porque a marcação vive dentro do código.

é a complexidade adicional que vale a viagem!

Absolutamente, é como o argumento de se você deve treinar seus desenvolvedores com as técnicas mais recentes e arriscar que eles deixem sua empresa. O maior risco é mantê-los por perto sem treinamento. Portanto, você deve adotar as técnicas mais recentes ou corre o risco de ficar para trás.

React está liderando a jornada com as mais recentes técnicas para desenvolver UI/UX. Tem uma tremenda tração com os desenvolvedores. Seu maior risco é não atender a barra do React.

JSX eu acho que visa resolver outros problemas em que você deseja misturar o que está fazendo com HTML e javascript

JSX não é apenas para HTML, o React Native gera Views (como Flutter Widgets) a partir da marcação XML.

Acho que a verdadeira questão é como a interface do usuário pode ser construída mais rapidamente.

Mais como como a UI/UX pode ser melhor construída. Melhor significado: mais rápido, de maior qualidade (código e UI/UX), interação suave entre designer e desenvolvedor, etc.

A propósito, muito bom trabalho feito nas ferramentas do desenvolvedor; 'flutter doctor' foi incrível !!!
Agora estou cozinhando com gás e posso ser perigosamente criativo ;)

Eu só queria responder à questão de legibilidade levantada aqui, embora eu entenda que legibilidade é apenas um dos muitos fatores que precisamos considerar.

A legibilidade e a simplicidade do código que, por sua vez, geram vários outros benefícios.

Se este é o principal benefício, então isso é algo que podemos testar. Poderíamos pegar uma mistura de engenheiros que estão acostumados a escrever HTML, React, código iOS, código Android, Flutter, aplicativos de linha de comando e assim por diante, e apresentá-los a cada um com várias sintaxes e pedir que descrevam o que eles acham que o UI resultante seria. Podemos então medir qual sintaxe obtém os melhores resultados. @InMatrix isso é algo que podemos analisar depois que o trabalho de animação terminar, talvez?

Certamente existem maneiras de estudar empiricamente a legibilidade do código, e podemos ter uma discussão mais séria quando chegar a hora do planejamento do quarto trimestre. Para tornar esse estudo útil, precisamos definir quais tipos de tarefas de leitura são importantes para os desenvolvedores no contexto da programação Flutter. Além de ler um método de compilação inteiro e imaginar o que a interface do usuário resultante pode ser, a legibilidade também afeta tarefas menores, como identificar o método de compilação em um arquivo dart, chaves correspondentes, ler comentários embutidos etc.

Para dar suporte a algumas dessas tarefas de escopo mais restrito, podemos experimentar primeiro os aprimoramentos da interface do usuário no editor, o que geralmente é mais barato do que introduzir e manter uma linguagem de marcação. O recurso de rótulo de fechamento no código VS é um desses aprimoramentos da interface do usuário, e devemos entender o quão bem ele resolve o problema de correspondência de chaves que se propõe a resolver. Existem muitas outras opções neste espaço que ainda não experimentamos. Por exemplo, uma fonte ou cor de fundo diferente pode ser usada para exibir o método de compilação para ajudar o desenvolvedor a separá-lo mentalmente do restante do código.

Outra coisa que me parece importante é como podemos encorajar as pessoas a não escreverem métodos de construção gigantes e tirar proveito da natureza de composição do framework. Se o método de construção for mais alto que a altura da tela, será difícil ler, independentemente de ser Dart ou XML.

Outra coisa que me parece importante é como podemos encorajar as pessoas a não escreverem métodos de construção gigantes e tirar proveito da natureza de composição do framework. Se o método de construção for mais alto que a altura da tela, será difícil ler, independentemente de ser Dart ou XML.

Não é apenas o método de construção. São todos os outros métodos que o método build chama para construir a árvore de widgets. Muito comum no React usar métodos menores para construir partes de sub-árvores e então chamá-las para a árvore maior.

Também no WebStorm com JSX, cada nó XML tem +/- que pode ser usado para expandir/recolher nó e filhos para facilitar a leitura de estruturas maiores que a altura da tela.

Uma coisa que descobrimos no Flutter é que grandes métodos de construção não são ótimos para desempenho, e tentamos encorajar as pessoas a dividir seus métodos de construção em widgets reutilizáveis ​​menores. Em particular, no Flutter, ter um método de compilação construído a partir dos resultados de outros métodos é um antipadrão que preferimos desencorajar em vez de facilitar. (Esta é uma percepção recente, então muitos de nossos exemplos e widgets ainda não fazem isso bem.)

tentamos encorajar as pessoas a dividir seus métodos de construção em widgets reutilizáveis ​​menores.

Ele realmente se torna um widget reutilizável ou simplesmente um widget wrapper/composto? Quero dizer, para ser reutilizável, você deve ter pelo menos 2 instâncias de uso.

O AppBar em https://flutter.io/catalog/samples/basic-app-bar/ é tão único que você não pode chamá-lo de componente reutilizável; é um componente wrapper/composto e, nesses casos, por que não usar apenas um método local para criar essa parte da interface do usuário? Eu acho que se ele fizesse mais coisas, faria sentido colocá-lo em um componente wrapper/composite.

Uma coisa que descobrimos no Flutter é que os métodos de compilação grande não são bons para o desempenho

Como você mencionou o desempenho, fazer com que o loop de animação conduza o método de compilação causará problemas de desempenho para uma animação suave. Você não quer que seu método de compilação seja chamado 60 vezes por segundo ou mais, especialmente considerando que o método de compilação é código do usuário (por exemplo, ele pode ter um loop super longo que leva uma eternidade e faria as animações pularem). Sendo um iniciante do Flutter, talvez eu tenha entendido errado.

O AppBar em https://flutter.io/catalog/samples/basic-app-bar/ é tão único que você não pode chamá-lo de componente reutilizável

Também é relativamente pequeno, então tudo bem.

Em relação ao desempenho, isso é um pouco fora do tópico para este problema, portanto, registre um novo problema se quiser discuti-lo (ou envie um e-mail para flutter-dev ou poste sobre estouro de pilha, o que você preferir).

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

É uma loucura ver essa questão sendo enterrada. Na minha opinião, será um sucesso ou um fracasso para o Flutter implementar uma sintaxe semelhante a JSX para compor widgets.

Eu simplesmente não entendo o público-alvo, muitos desenvolvedores de ios e android estão se movendo para reagir nativos, parece ser a oportunidade perfeita para colher participação de mercado.

Eu encorajo as pessoas envolvidas a dar uma olhada no react native e ver do que estamos falando.

Eu não sinto falta do JSX no Flutter. Isso só aumentaria a estrutura e as ferramentas para alguns pequenos ganhos aqui e ali.

@birkir estou 100% com você nesta questão. A falta de JSX, que é perfeito para o Flutter, faz o Flutter parecer velho e enferrujado, parece tecnologia dos anos 90. Na verdade, parece que todos, de uma forma ou de outra, estão adotando o JSX; o mais recente é o popular framework Vue.js.

+1

@zoechi Qual é a sua experiência anterior com o JSX, você realmente o usou ou apenas olhou para ele? Acho que vocês estão subestimando o JSX dizendo que vai dar pequenos ganhos aqui e ali. Se você não tem nenhum usuário, você não tem um produto.

@birkir Vejo muita empolgação com o JSX aqui, mas ninguém parece se incomodar em explicar o que exatamente o Flutter ganharia com esse DSL, exceto talvez uma melhor legibilidade, que é principalmente subjetiva.

Mais recursos geralmente apenas sobrecarregam uma estrutura em vez de melhorá-la.
Implementá-los também consome muitos recursos que estão faltando em outras áreas onde os recursos ausentes realmente impedem que as pessoas implementem determinados aplicativos.

Então, se você está empolgado com o Flutter recebendo algo como JSX, você deve investir seu tempo e energia escrevendo argumentos convincentes.
Apenas adicionar algo porque outros também o têm, é provavelmente o argumento mais fraco que existe.

Também há planos para melhorar o Dart para tornar a escrita do código Flutter UI menos detalhada, o que enfraquece ainda mais o caso do JSX.

Então, quais são seus argumentos convincentes?

Mesmo !!! "ninguém parece se preocupar em explicar o que exatamente Flutter ganharia... blá blá blá".
Você não leu este tópico completamente? Sua atenção é maior do que seu conhecimento de JSX?

Vocês estão sofrendo da síndrome do NIH (não inventado aqui). "Bons artistas copiam; grandes artistas roubam", artistas medíocres, bem, se comportam como você.

Apenas o fato de que o suporte ao JSX é relativamente simples, e ajudará tremendamente a atrair novos clientes (desenvolvedores móveis React Native) para a plataforma, torna-o um acéfalo que vocês não conseguem ver. Não negrito bem para a plataforma.

Podemos, por favor, manter um tom construtivo ao debater.

Adicionar recursos porque outros o têm é um argumento fraco. OK.
Por que o flutter tem recarga a quente? De onde veio isso? Jesus cara.

Como deixamos de fornecer argumentos sólidos para vocês? A tração do projeto e a atração de desenvolvedores é nossa razão número um.

Razão número dois, legibilidade :

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ão número três, Construtores de GUI . Vou citar a primeira linha do README.

Um novo SDK de aplicativo móvel para ajudar desenvolvedores e designers a criar aplicativos móveis modernos para iOS e Android.

Eu odiaria ver o Flutter caindo na mesma toca do Polymer antes mesmo de chegar ao beta.

Tração do projeto e atração de desenvolvedores

A relação ainda não está clara.

Razão número dois, legibilidade:

Tornar o código Dart mais legível parece um objetivo melhor para mim

Razão número três, Construtores de GUI. Vou citar a primeira linha do README.

Tanto quanto me lembro, já foi mencionado acima que não há razão para que o uso do código Dart impeça isso.

Seus contra-argumentos não podem realmente descartar a ideia, podem?

1. A relação é bem clara. A menos que não seja um objetivo para o projeto ser popular?
2. Excelente! Será próximo da legibilidade do JSX? Qual é a proposta atual para tal coisa?
3. Foi declarado que isso poderia ser feito . Adaptar o suporte JSX para construtores de GUI atualmente disponíveis será muito mais simples.

Também há planos para melhorar o Dart para tornar a escrita do código da interface do usuário do Flutter menos detalhada

É bom ver o reconhecimento de que a maneira atual pode usar algumas melhorias.
Por favor, forneça detalhes sobre tal proposta. Sua melhor aposta é interagir com a comunidade React Native para obter feedback.

Várias solicitações de recursos da linguagem Dart podem tornar o código mais curto/legível:

• Opcional new e const para Dart 2
• Meta-questão para discussão da proposta para permitir argumentos nomeados em todos os lugares - - isso poderia permitir que o widget com o argumento child pule o argumento nomeado.
  
  
  
  • Número variável de argumentos - isso pode permitir que widgets com argumento children (como Linha e Coluna) ignorem esse argumento nomeado e sua declaração de lista.
  
  

Com essas alterações, o código pode ficar assim:

  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'),
            )
          ),
        ),
      )
    );
  }

Além disso, dependendo do seu IDE, você pode opcionalmente ter comentários sintéticos no final dos parênteses e pode ver algo assim em seu 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
  }

Essa conversa está esquentando. Gostaria de encorajar a todos a lerem nosso código de conduta:
https://flutter.io/design-principles/#conflict -resolution
Vou encerrar esta conversa por alguns dias enquanto todos consideram como podem contribuir de forma respeitosa e produtiva.

Todos nós sabemos que a sintaxe para construir a interface do usuário é uma parte muito importante da experiência de desenvolvimento móvel. Por enquanto a sintaxe é um pouco detalhada, eu tenho que new algo apenas para adicionar uma margem: margin: new EdgeInsets.symmetric(horizontal: 4.0) , acho que pode haver uma maneira mais fácil.

Seria possível construir um DSL como o que a equipe Kotlin fez para desenvolvedores Android? Chama-se Anko , uma DSL para construir a interface do usuário do Android:

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

Uma sintaxe concisa ajuda a manter o código legível e sustentável, também pode tornar o trabalho de construção agradável, isso importa. Por favor, a equipe Flutter estime seriamente antes de tomar a decisão. Todos nós adoramos ver o Flutter fazer um sucesso maior nos próximos anos.

Por favor, não introduza a sintaxe do tipo XML no Flutter.

Programei no Android Java por mais de um ano, então comecei a procurar um conjunto de ferramentas multiplataforma para experimentar.
Comecei com React Native e depois tentei React. Eu realmente não gostei da sintaxe JSX porque não é bem javascript e não é bem html, então apenas outra coisa para aprender.
Quando experimentei o Flutter, achei muito mais fácil começar (provavelmente principalmente devido ao meu histórico de Java).

Eu acho que algumas das razões pelas quais eu não gostaria de ver uma sintaxe XML adicionada ao flutter :

1. Outra coisa a aprender - poderia ser gasto em aprender Futuros ;P
2. Troca de contexto - você está trocando de contexto entre XML e código, o que é apenas uma carga cognitiva desnecessária.
3. Houve dias em que programei em Java pela manhã e Python à tarde. Com React você pode precisar entender Javascript, Babel, JSX, HTML, CSS e muito mais em uma base de código.
4. A razão pela qual o XML não é necessário no Flutter é porque o dart tem argumentos nomeados que substituem os atributos XML muito bem.
5. Dart tem o dartfmt muito legal que recua o código muito bem sem esforço.

Comparando com o Android

1. Você tem que aprender a forma programática de qualquer maneira, por que adicionar outra maneira de fazer as coisas?
2. O layout XML no Android é mais rápido para exibir alterações no dispositivo, mas a execução no Flutter é praticamente instantânea de qualquer maneira, portanto, adicionar XML não forneceria essa vantagem.
3. A combinação Android XML + programática adiciona complexidade, como inflar snippets XML e injetar na árvore XML programaticamente.
4. A execução instantânea é tão rápida no Flutter que você não precisa do modelo XML para ajudar a visualizar como ele aparecerá, basta pressionar uma tecla e ver a alteração imediatamente.
5. Os erros de problemas de layout programático são diferentes dos problemas de layout em XML, portanto, há dois conjuntos de coisas que você precisa entender.

Eu daria um passo adiante e removeria pubspec.yaml e o substituiria por pubspec.dart e teria configuração no código dart.

Se os desenvolvedores estão reclamando da dificuldade de organizar as páginas visualmente - uma ideia seria criar um designer de layout que permita definir seus temas e criar páginas visualmente arrastando e soltando. Em seguida, ele geraria um código Flutter que não deve ser editado - mas cria classes que podem ser usadas para compor seu aplicativo.

Não precisaria ser uma edição bidirecional (XML/layout) como o XML do Android, mas você apenas salva seu layout para mais tarde. Se você precisar alterá-lo, poderá regenerar o código e (espero) apenas alterar alguns argumentos.

Eu sei que essa conversa é antiga e sim estava ficando bem quente, mas eu gostaria de deixar algumas linhas para o que eu considero que está acontecendo aqui.

Flutter é NOVO. É uma maneira completamente NOVA de fazer as coisas. Sim, ele tomou emprestado o paradigma de reação. Mas não significa que precisa seguir os mesmos passos. Eu não acho que o objetivo da equipe do flutter seja atrair desenvolvedores de react native para flutter, é apenas criar algo novo que os desenvolvedores possam se interessar. O Google o usa internamente antes de compartilhá-lo com o mundo e eles têm sido produtivos com isto. Compartilho os comentários com @Hixie que não é diferente do JSX para construir a interface do usuário. Sim, é um pouco mais detalhado para dart puro certo. Mas na verdade torna a depuração do seu código muito mais fácil.

A razão pela qual sou contra uma linguagem de marcação ou JSX ou qualquer coisa que fique em cima de uma tecnologia é que ela exige muito mais trabalho da plataforma. Você pode ficar feliz compondo a linguagem de marcação para uma interface do usuário, mas terá muitos desenvolvedores trabalhando na plataforma chorando e puxando os cabelos para fazê-la funcionar para você. Outro ponto de vista é que JSX funcionou para uma comunidade Javascript, onde como sempre seu principal objetivo é facilitar as coisas para o desenvolvedor e não se preocupar com as compensações. Não me interpretem mal React(JSX) para web foi um jogo feito no céu porque HTML é marcação de qualquer maneira. Mas para React Native, veja todo o código no repositório que eles tiveram que fazer para que funcionasse. Adicionar JSX ao flutter exigiria muito trabalho e 2 coisas para pensar ao adicionar novos recursos. E novamente apenas para poder remover o parâmetro filho e as palavras-chave const e new?. Eu prefiro saber o que realmente está acontecendo no código e ter controle sobre o que está acontecendo do que ter uma Sintaxe mágica que tudo o que está fazendo é adicionar sobrecarga.

Bem, essa é a minha opinião. Não quero começar uma nova discussão gigantesca. Apenas para mencionar o fato de que JSX é incrível para uma comunidade react/javascript porque funcionou para eles, mas para Dart/flutter eu acho um pouco exagerado adicionar JSX apenas para atrair desenvolvedores de React Native.

Uau, poderia ter escrito um post no blog xD

@Rockvole ,

Outra coisa a aprender - poderia ser gasto em aprender Futuros ;P

A coisa a aprender torna a monstruosidade atual de construção de objetos recursivos mais simples e familiar para os desenvolvedores React Native cotidianos, então meu palpite é que as pessoas vão preferir aprender isso.

Troca de contexto - você está trocando de contexto entre XML e código, o que é apenas uma carga cognitiva desnecessária.

Não é um problema, não há troca de contexto, é apenas parte do ambiente que torna a programação de UI/UX mais limpa.

Em seguida, ele geraria código Flutter que não se destina a ser editado

Por que não? Não muito útil então.

@franzsilva

Eu não acho que seja o objetivo da equipe do flutter atrair desenvolvedores de react native para vir para flutter

Mesmo !!! O React Native está dominando e, dado que o número total de desenvolvedores móveis usando ferramentas de plataforma cruzada é limitado, você realmente acha que o Flutter pode se tornar um sucesso sem atrair pessoas do React Native?

Sim, é um pouco mais detalhado para dart puro certo. Mas na verdade torna a depuração do seu código muito mais fácil.

Essa não é uma afirmação correta. Depurar código JSX, que é apenas código javascript, não é mais fácil ou mais difícil, é a mesma coisa.

A razão pela qual sou contra uma linguagem de marcação ou JSX ou qualquer coisa que fique em cima de uma tecnologia é que ela exige muito mais trabalho da plataforma.

Quem se importa com quanto trabalho foi colocado na plataforma? Os desenvolvedores querem apenas as técnicas mais recentes que melhoram a legibilidade e a produtividade do código. Nenhum desenvolvedor quer usar técnicas antigas e obsoletas quando coisas mais novas oferecem uma alternativa melhor.

Eu prefiro saber o que realmente está acontecendo no código e ter controle sobre o que está acontecendo do que ter uma Sintaxe mágica que tudo o que está fazendo é adicionar sobrecarga.

Isso não faz sentido, eu sei exatamente o que acontece com o JSX, é uma pequena camada que transforma quase um para um, mas oferece muitos benefícios. Sobrecarga de tempo de compilação insignificante, se você me perguntar.

Apenas para mencionar o fato de que JSX é incrível para uma comunidade react/javascript porque funcionou para eles, mas para Dart/flutter eu acho um pouco exagerado adicionar JSX apenas para atrair desenvolvedores de React Native.

JSX também deve funcionar muito bem para Dart/Flutter. Não é um exagero de forma alguma. Existe alguma boa razão pela qual o JSX não funcionaria para Dart/Flutter? Se eu codificasse e lançasse, por que não seria uma boa opção para o desenvolvimento do Dart/Flutter?

Vamos pegar o exemplo concreto de @xinthink :

Por enquanto a sintaxe é um pouco detalhada, eu tenho que new algo apenas para adicionar uma margem: margin: new EdgeInsets.symmetric(horizontal: 4.0) , acho que pode haver uma maneira mais fácil.

Se você quiser adicionar uma margem à esquerda e à direita, como você gostaria de expressar isso? Especificamente, vamos dar um exemplo simples e ver como ficaria em várias sintaxes.

  // 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,
    ),
  );

Como você recomendaria que expressássemos essa semântica _exata_?

  // 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 tem este pequeno site legal, onde você pode digitar JSX e convertê-lo em Javascript simples:
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

Vou fazer um equivalente para DSX to Dart. Apenas uma prova de conceito, vamos ver quanto tempo leva...

Aqui está o exemplo mais recente de @Hixie em ”DSX“, usando o guia de estilo do Airbnb e assumindo que todos os elementos filhos podem mapear automaticamente para propriedades 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>
);

Se a intenção é melhorar a legibilidade, acho que o futuro Dart vence em espadas.

Você precisa verificar a documentação para saber o que pode se transformar em tags (presumivelmente Widget s apenas), ou quantos elementos filho são obrigatórios/permitidos.

Se seu objetivo é produzir HTML a partir de JavaScript, JSX faz muito sentido como meio termo. Porque quando você quer tags no final do dia, React.createElement('div', null, 'foo') é muito pior do que <div>foo</div> .

Se o seu objetivo é produzir uma árvore de objetos Dart de... Dart, e uma árvore bem formatada de construtores Dart é perfeitamente (indiscutivelmente mais) legível, não vejo sentido em desviar pelo XML. E não estou perdendo esses XMLs vindos do Android.

É o que o uso de XML permite... Olha, já se passaram 5 meses com apenas conversa, agora estou fazendo algo sobre isso, então me dê algum tempo (eu tenho um emprego em tempo integral e só posso poupar cerca de 4 horas nos finais de semana).

Acabei de encontrar este tópico, interessante em ambos os lados. Como um desenvolvedor React interessado em Flutter, existem alguns outros argumentos que eu não vi mencionados (embora eu tenha apenas lido brevemente todos os comentários).

1. Fechar a declaração de marca aumenta a compreensão dos filhos versus propriedades. Infelizmente, a interface do usuário pode ser profundamente aninhada, e ter uma tag clear vs um unknown ) ajuda a esclarecer e analisar os filhos. Ele também me permite mover o código entre os componentes e ver de forma muito declarativa quando algo está fora do lugar (uma tag de fechamento antes de um, por exemplo.) Isso é mais complicado com vários ) aninhados.

2. Minha reação instintiva inicial ao ver vários componentes aninhados dentro de construtores me dá flashbacks do "inferno de retorno de chamada" . Foi uma era muito dolorosa do JS que está começando a melhorar, voltar parece um pouco como um retrocesso.

3. Relacionado ao nº 2, o fato lamentável é que temos que convencer as pessoas a mudar (ou pelo menos experimentar). Muitas pessoas estão usando React/React Native e ainda mais usando HTML/JS. Criar um tutorial/guia simples e sintaticamente familiar que tenha como alvo especificamente alguns dos pontos problemáticos do React pode ser extremamente atraente para aqueles que estão um pouco cansados.

Uma das principais razões pelas quais o React se tornou popular na comunidade de Desenvolvedores Web foi o suporte ao JSX.

É realmente decepcionante ver "votos negativos" em um pedido de recurso tão bom. Melhora a legibilidade e agiliza a adoção.

Eu acho que esta é uma grande diferença entre Open JavaScript e Dart. JavaScript é verdadeiramente open source, enquanto uma solicitação no Dart entra em uma conversa como essa e, finalmente, você fica desmotivado com votos negativos.

Abra mais espaço para novas ideias!

@jayjun Isso parece incrível! Posso tentar em algum lugar?

@sanketsahusoft Não se preocupe em breve você poderá experimentar minha versão e é ainda melhor que @jayjun.

Atualização rápida: 2 fins de semana atrás eu consegui a interface do usuário funcionando muito bem, no último fim de semana eu consegui o analisador totalmente funcionando e metade do transpilador funcionando. No próximo fim de semana espero terminá-lo se evitar o Superbowl ;)

Eu tenho pele grossa e teimosia como uma mula, então nem noto esses votos negativos, obrigado por apontá-los.

Carlos.

Isso ajudaria com a questão de perder o controle das tags de fechamento?
Ideia: tags de fechamento geradas automaticamente

Aqui está uma sintaxe de marcação proposta para o exemplo 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 , o interessante que você fez foi adicionar uma 3ª possibilidade de atributo que simplifica a aparência das expressões quando são outra tag.
JSX tem:
1 - <tag attrib=""/> ou <tag attrib=''/>
2 - <tag attrib={}/>
Você sugeriu outro:
3 - <tag attrib=<anotherTag.../>/>
com JSX você tem que escrevê-lo como:
<tag attrib={<anotherTag.../>}/>

@cbazza Sim, o terceiro caso é bastante comum no Flutter, então faz sentido pular o aninhamento extra de { .

@abarth Ah, mas estou tornando a maioria dessas coisas desnecessárias usando estilos semelhantes a CSS !!! O transpilador expande esses estilos semelhantes a CSS em chamadas Flutter apropriadas. Agora a estrutura de marcação está muito mais limpa e os estilos podem ser facilmente importados de ferramentas de designer como InVision, Figma, Atomic, etc.

@cbazza Legal, eu uso muitos widgets com closures como FutureBuilder . Espero que seu transpilador possa gerar 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 , Sim, isso não é um problema. O transpilador é um processador XML simples e, quando se trata de analisar expressões (tudo dentro de {}), ele se torna um blob de texto e o escreve na íntegra.

@xinthink

Seria possível construir um DSL como o que a equipe Kotlin fez para desenvolvedores Android?

Parece que muitas pessoas gostariam de usar Kotlin com Flutter. Honestamente, não entendo, por que os desenvolvedores decidiram reinventar as rodas no Dart?

Na minha humilde opinião, Flutter não precisa de JSX. Flutter deveria ter escolhido Kotlin em vez de Dart. Kotlin nos permite escrever lógica de interface do usuário complexa com bela sintaxe pronta para uso, tem uma comunidade enorme, ferramentas prontas para produção, testada em batalha no desenvolvimento Android...

Apenas dizendo.

Kotlin é legal, sou fã, mas não roda no iOS... na verdade roda, mas ainda não foi lançado (estágio de pré-lançamento agora).
Para desenvolvimento de UI/UX ainda prefiro JSX em vez de Anko DSL. Gosto do fato de poder separar visualmente a marcação declarativa do código imperativo e poder misturar e combinar componentes com bastante facilidade.

Dart, Kotlin e Swift têm semelhanças:
https://sethladd.github.io/swift-is-like-kotlin-and-kinda-like-dart/

Eu gosto disso :

1. Dart é mais familiar se você vem de Java.
2. Você pode usar suas habilidades no Dart para criar páginas da Web - o que é valioso ao criar aplicativos, você pode criar recursos na Web (e mostrá-los em um WebView) onde fizer mais sentido (talvez páginas de administração rápidas ou listagens de produtos que precisa ser indexado no google).
3. O Dart foi construído desde o início para compilar em javascript, o que suponho que não seja fácil adicionar a um idioma posteriormente.

Estas são basicamente as razões pelas quais eu escolhi Dart em vez de Kotlin / Swift / React.

_Embora a decisão de apoiar Dart e Swift no novo sistema operacional Fuchsia do Google seja confusa para mim._

Não tenho certeza se o Dart é mais familiar se você vier de Java. Eu vim de Java e não tenho problemas com Kotlin ou Swift; basicamente a declaração de tipo é invertida, nada realmente novo, pois foi usado em Pascal e ActionScript.

Sim, você pode criar páginas da web com o Dart, mas não vejo grande interesse nisso. A única outra linguagem que está indo bem na web é o TypeScript, pois se integra bem com os 3 principais frameworks da web mais populares.

Dê uma olhada nas diferentes sintaxes disponíveis para React na Web:
https://github.com/Workiva/over_react#fluent -style-component-consumption
Ambas as versões do Dart não têm chance contra JSX !!!

O TypeScript foi projetado para compilar em Javascript e é melhor que o Dart para isso. Ele também suporta JSX.
Dart está sendo espremido por todos os lados. Swift tem impulso, por isso é aconselhável apoiá-lo no Fuchsia OS junto com seu bebê.

Quanto tempo até o protótipo? Eu adoraria usá-lo!

Usei o React por um tempo e o JSX aumentou minha produtividade em dez vezes. Esta não é uma questão controversa: outras equipes decidiram, corretamente, que isso seria melhor, então por que não Flutter? (Retórica: eu li o tópico... (facepalm))

Estou trabalhando nisso neste fim de semana, mas continuo aumentando o escopo com novas ideias, então espero poder lançar algo neste fim de semana.

Algumas das coisas interessantes que estou experimentando:
1) usando o namespace xml nas tags filhas para que elas sejam inseridas com o argumento nomeado correto do Dart no pai.
2) operador spread para organizar melhor o estilo como propriedades para que possam ser definidas/agrupadas fora do xml em um mapa e então trazidas e espalhadas em uma tag como coisas típicas do React.
3) propriedade styleCSS que gera estilos de vibração a partir de CSS.

(1) e (2) são genéricos, portanto, funcionam para todos os códigos Dart Flutter.
(3) é especializado por Flutter Widget (Container, Text, etc) e estou fazendo apenas esses 2 por enquanto.

@yuriy-manifold só porque algo funcionou para o JS não significa que seja uma boa ideia para o Dart.
Se você tivesse lido as discussões acima, veria que, de fato, é controverso.
Não vejo por que 2 idiomas seria melhor do que um.

só porque algo funcionou para o JS não significa que seja uma boa ideia para o Dart.

JSX é uma ideia incrível para desenvolvimento de UI/UX em um framework reativo independente do idioma. Se eu tivesse mais tempo livre eu lançaria LSX que é JSX for Logo ;)

Não vejo por que 2 idiomas seria melhor do que um.

Você pode programar iOS com Objective-C e Swift (2 idiomas)
Você pode programar Android com Java e Kotlin (2 idiomas)
...

Eu ainda tenho que ver um argumento a favor do JSX.
As discussões acima contêm apenas argumentos como "é melhor", "aumenta a produtividade" ou similares, mas nenhum argumento por que ou como seria realmente melhor do que o código Dart puro, especialmente considerando as mudanças planejadas de linguagem que reduziriam a diferença entre o tipo JSX e
código Dart puro ainda mais.

@cbazza

Você pode programar iOS com Objective-C e Swift (2 idiomas)
Você pode programar Android com Java e Kotlin (2 idiomas)

Como isso está relacionado à discussão do JSX? Como isso pode ser considerado uma vantagem?
Você pode usar o Swift no iOS porque é o sucessor do Objectiv-C.
Você pode usar o Kotlin no Android porque é considerado uma melhoria inteligente para o Java.
Parece que você argumenta que o JSX deve substituir o Dart. Isso não faz muito sentido para mim.

@zoechi

Como isso está relacionado à discussão do JSX? Como isso pode ser considerado uma vantagem?
Você pode usar o Swift no iOS porque é o sucessor do Objectiv-C.
Você pode usar o Kotlin no Android porque é considerado uma melhoria inteligente para o Java.
Parece que você argumenta que o JSX deve substituir o Dart. Isso não faz muito sentido para mim.

Você realmente disse isso (JSX é uma melhoria inteligente em relação à maneira atual), mas chegou à conclusão errada (JSX para substituir o Dart).

@cbazza é mais do mesmo

qual é a vantagem real sobre o Dart simples?

"JSX é uma melhoria slick" não é convincente de forma alguma e não é um argumento.
É apenas uma opinião pessoal sem (novamente) qualquer argumento para apoiá-la,
semelhante com outros argumentos pró-JSX acima.

Você não pode esperar que alguém considere suas sugestões se você não estiver disposto a fornecer bons argumentos.

Adicionar algo como JSX ao Dart causa muito trabalho e complexidade nas ferramentas Flutter e no IDE. Você precisa fornecer argumentos adequados para que os outros considerem olhar para ele.

@zoechi soa como um disco quebrado pedindo 'bons' argumentos, muitos foram dados antes, mas você simplesmente não entendeu; o que é OK, 'cada um na sua'.

Adicionar algo como JSX ao Dart causa muito trabalho e complexidade nas ferramentas Flutter e no IDE. Você precisa fornecer argumentos adequados para que os outros considerem olhar para ele.

Na verdade não, meu trabalho está quase pronto e demorei muito pouco, considerando que só trabalhava nele nos finais de semana.

Novamente, o DSX é apenas uma melhoria que as pessoas podem escolher usar ou não, porque não muda a forma atual, apenas fornece uma alternativa com a qual outros (desenvolvedores do React) estarão instantaneamente familiarizados.

@cbazza

muitos foram dados

Na verdade não. Apenas afirmações gerais que podem ser verdadeiras ou não.
Nenhum detalhe adicional foi fornecido que permitiria que outros verificassem.

Na verdade não, meu trabalho está quase pronto

Excelente. Então não há necessidade da equipe do Flutter fazer nada e o problema pode ser encerrado ;p
Isso inclui suporte a autocompletar e verificações de sintaxe em todos os IDEs suportados pelo Flutter?

Excelente. Então não há necessidade da equipe do Flutter fazer nada e o problema pode ser encerrado ;p

;)

Isso inclui suporte a autocompletar e verificações de sintaxe em todos os IDEs suportados pelo Flutter?

A maioria dos IDEs já suporta XML e JSX, então não seria difícil para eles adicionar minhas pequenas adições.

Gostaria de saber se a sintaxe JSX pode ser mais apreciada em angular Dart? Parece que é mais uma situação do que você está acostumado, em vez de "melhor". A sintaxe JSX provavelmente parece mais natural para desenvolvedores web.

Eu sei que a programação parece estranha para mim, mesmo usando código diferente destacando cores por um dia.

https://blog.dantup.com/2014/08/you-have-ruined-html/

Sim, as pessoas do Angular ficarão muito confortáveis ​​com o JSX, mas também os desenvolvedores do React Native e isso é para desenvolvimento móvel. O JSX certamente não será usado pelos desenvolvedores atuais do Flutter, mas essa segunda alternativa atrairá novos desenvolvedores para o Flutter e isso é certo.

O artigo acima entendeu tão errado, React sem JSX é basicamente inexistente e todos os frameworks web reativos permitem a mistura de marcação e programação em seu DSL.

Chegou a hora...
É com grande prazer que anuncio o transpilador DSX online
https://spark-heroku-dsx.herokuapp.com/index.html

Bom trabalho com o transpiler cbazza
Uma coisa que eu diria que é mais fácil de seguir com o JSX são as tags de fechamento. A ideia que mencionei antes:
Ideia: tags de fechamento geradas automaticamente

Em seu primeiro exemplo, daria o código de vibração de (removido o opcional novo no 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 Eu aprecio seu trabalho para a comunidade e as pessoas que querem construir UIs dessa maneira, mas eu realmente espero nunca ser forçado a usar algo assim no Flutter :-(((

Como recém-chegado ao Flutter, mas bastante familiarizado com o React, algumas coisas se destacaram para mim:

• O modelo de gestão do estado é praticamente o mesmo
• A árvore de renderização virtual do widget/componente é praticamente a mesma
• Conhecendo o estado e o modelo de componentes, basicamente me sinto pronto para escrever um aplicativo agora, exceto algumas especificações do Dart e APIs de plataforma, mas...
• A linguagem de estilo é um obstáculo. Estou me referindo a https://flutter.io/web-analogs/ mas não é fácil descobrir quais importações são necessárias para fazer as coisas funcionarem (EdgeInset? Color?) ou quando devo usar primitivas em vez de instâncias de classe.
• O analisador CSS do conversor DSX do @cbazza é realmente útil para descobrir os equivalentes de layout no modelo Flutter.

Sobre JSX:

• Eu não acho que seja necessário inventar uma nova sintaxe JSX para suportar padrões Flutter. Alguns dos problemas de sintaxe neste thread podem ser resolvidos usando alguns dos padrões React mais recentes, como componentes de ordem superior (funções que constroem classes de componentes) e props de renderização (componentes que recebem funções como argumentos; as funções retornam elementos). Por exemplo, chamados "slots filhos" podem ser traduzidos para algo assim em 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>

• O melhor argumento contra o JSX que vi foi que o Dart nomeou argumentos.
• Por que é importante que um elemento saiba se tem vários filhos ou um filho? Talvez uma construção de "fragmento" possa desambiguar essa API.

Eu ainda acho, como recém-chegado ao Flutter com alguma experiência com Angular, React, etc., que o modo Dart regular, e mais no Dart 2.0, é melhor que este DSX. Faz mais sentido do que alguns parâmetros XML e CSS. 🤷‍♂️

@cbazza seu segundo exemplo de demonstração tem 466 caracteres em comparação com os 391 do dart (ambos sem espaços). Para mim, parece visualmente inchado. Eu teria que aprender sua semântica, o que não preciso com o código Dart normal. E não tenho ideia de como usar paradigmas de programação de propósito geral com ele (if, forEach, etc.).

Se eu pudesse escolher, ficaria com o modelo atual.

Todo mundo está apenas dando sua própria opinião subjetiva ao comparar as duas sintaxes, mas temos que concordar em um fato: é um recurso muito controverso. Há amor e ódio, mas a maioria das opiniões divergem sobre a utilidade do JSX sobre o Dart simples.

De qualquer forma, acho totalmente irracional pedir à equipe do Flutter que se comprometa a oferecer suporte a esse recurso antes do lançamento 1.0. Embora a maneira atual de construir a interface do usuário possa não parecer ótima para todos - funciona (e funciona muito bem em algumas opiniões).

Se as pessoas realmente querem uma sintaxe semelhante a JSX agora, um esforço conduzido pela comunidade parece ser o caminho a seguir. E isso ajudaria a fazer o caso (ou não) quando a equipe do Flutter o considerasse na versão pós-1.0.

Pessoalmente, concordo fortemente com o seguinte argumento: não é porque o JSX funciona para o React (onde você já está construindo a interface do usuário usando uma linguagem de marcação) que ele funciona automaticamente para o Flutter.

@tehfailsafe

A boa notícia é que mesmo que isso tenha sido adotado pela equipe do Flutter (o que provavelmente não é baseado neste tópico), ninguém seria forçado a usá-lo. É uma OPÇÃO. Não entendo por que é tão emocionalmente carregado que algumas pessoas podem gostar de escrever código com uma sintaxe que você não gosta ...

Eu não me importo com o que as outras pessoas gostam ou não gostam. Mas eu me importo com recursos que me ajudam a progredir com meu aplicativo. Os recursos são limitados, e eu preferiria ter um player de vídeo/stream adequado, visualizações filhas nativas e algum formato de gráficos vetoriais.

Por exemplo, agora em React e React Native você pode escrever toda a sua aplicação sem JSX, é apenas uma opção. Veja como é o React sem JSX:
[...]
É muito mais confuso do que a versão JSX, e quase ninguém o usa. É provavelmente por isso que alguns de nós que estão vindo do React apreciariam a possibilidade de evitar ter que fazer esse estilo novamente.

Isso porque a web não foi projetada para um sistema como esse. Se você tem uma linguagem de marcação estática como HTML e quer "dinamizá-la", você precisa inventar um sistema que precise trabalhar em cima disso. O que você terá é alguma construção que é restringida pela plataforma subjacente.
(ver: https://gbracha.blogspot.de/2014/09/a-domain-of-shadows.html)

Flutter, por outro lado, não tem linguagem de marcação. Ainda não vi uma razão para investir recursos em algo menos dinâmico e menos expressivo.

Gostaria de saber se as pessoas que discordam dele já usaram React com e sem JSX. Encorajo todos a experimentá-lo, para que esta discussão seja menos teórica. Após a curva inicial de aprendizado superficial, torna-se muito natural (e não é tudo sobre o número de caracteres, porque as tags de fechamento permitem que você leia com mais facilidade). Não é diferente de aprender qualquer outra coisa nova, como Flutter, que a longo prazo aumenta a produtividade. E concordo que não é para todos, por isso seria opcional.
Acho que é importante ter em mente que temos os melhores interesses uns dos outros em mente - tornando mais fácil construir coisas. Acho que esse transpilador ajudaria, e seria mais fácil de adotar se tivesse apoio oficial.

Além disso, obrigado @cbazza :)

@yuriy-manifold

Eu não acho que alguém aqui duvide que o JSX React seja uma melhoria em relação ao React clássico. Mas como eu disse, essa solução foi criada por causa de problemas relacionados às propriedades da plataforma subjacente. Flutter não tem essas propriedades.

A questão não é 'o JSX é útil para o React?' a pergunta é 'algo como JSX é útil para o Flutter?'.

Acho que a resposta é não.

Há algumas outras coisas a considerar:

• Separar a especificação de layout do código do aplicativo pode tornar o código mais à prova de futuro; por exemplo, esta proposta de sintaxe do Dart 2 não afetaria os métodos build se eles fossem transformados de acordo com um pragma atualizável em código Dart de um formato agnóstico como JSX.
• Definir o layout como marcação torna possível separar o mecanismo de renderização do mecanismo de widget (com estado/virtualizado) ala o relacionamento do React com ReactDOM e React Native, potencialmente facilitando a portabilidade de widgets para novas plataformas.
• Definir o formato de marcação facilita a portabilidade de layouts existentes para o Flutter, por exemplo, do Sketch ou de outras ferramentas de design

Bom trabalho com o transpiler cbazza

@Rockvole , obrigado.

Eu aprecio seu trabalho para a comunidade e as pessoas que querem construir UIs dessa maneira, mas eu realmente espero nunca ser forçado a usar algo assim no Flutter :-(((

@zoechi , obrigado. Sim, é apenas mais uma opção para as pessoas que amam JSX usarem. Se isso não é o seu jeito legal continue fazendo como está fazendo, nada muda aí.

Eu não acho que seja necessário inventar uma nova sintaxe JSX para suportar padrões Flutter.

@alexkrolick , sim, você pode usar props de renderização para os parâmetros nomeados, mas não há nada que você possa fazer sobre os parâmetros posicionais. A chave era que eu não queria codificar nada no transpilador para que funcionasse para tudo.

Eu ainda acho, como recém-chegado ao Flutter com alguma experiência com Angular, React, etc., que o modo Dart regular, e mais no Dart 2.0, é melhor que este DSX. Faz mais sentido do que alguns parâmetros XML e CSS.

@tenhobi , ótimo uso então, obviamente DSX não é para todos.

Se eu pudesse escolher, ficaria com o modelo atual.

@b-strauss, isso não é um substituto, é uma opção para pessoas que gostam de JSX.

Há amor e ódio, mas a maioria das opiniões divergem sobre a utilidade do JSX sobre o Dart simples.

@lukaspili , DSX é para pessoas React Native que amam JSX, se você não vê seus benefícios, não o use. Não é DSX versus Dart simples. É DSX vs. JSX, quanto mais próximos os 2 forem, melhor.

A boa notícia é que mesmo que isso tenha sido adotado pela equipe do Flutter (o que provavelmente não é baseado neste tópico), ninguém seria forçado a usá-lo. É uma OPÇÃO. Eu não entendo por que é tão emocionalmente carregado que algumas pessoas podem gostar de escrever código com uma sintaxe que você não gosta...

@tehfailsafe , obrigado por ouvir!!! Você acertou em cheio o porquê de tanta resistência a algo que vai deixar os React Native realmente felizes.

Eu não me importo com o que as outras pessoas gostam ou não gostam. Mas eu me importo com recursos que me ajudam a progredir com meu aplicativo. Os recursos são limitados, e eu preferiria ter um player de vídeo/stream adequado, visualizações filhas nativas e algum formato de gráficos vetoriais.

@b-strauss, Uma vez que os fãs do React Native se mudem para o Flutter, haverá toneladas de pessoas para ajudar nessas outras coisas necessárias. A prioridade 1 é roubar o compartilhamento de mente do React Native e torná-lo o mais simples possível para as pessoas do React Native se mudarem.

Flutter, por outro lado, não tem linguagem de marcação. Ainda não vi uma razão para investir recursos em algo menos dinâmico e menos expressivo.

@b-strauss, Como o DSX é 'menos dinâmico' e 'menos expressivo' do que o Dart simples? DSX é Dart, você não tentou o transpilador.

@yuriy-manifold, obrigado.

A questão não é 'o JSX é útil para o React?' a pergunta é 'algo como JSX é útil para o Flutter?'.

@b-strauss, claro que é. não é útil para desenvolvedores Flutter atuais, mas é muito útil para designers que podem produzir CSS de suas ferramentas, é muito útil para pessoas investidas na plataforma React Native.

@alexkrolick , observações muito boas.

@cbazza

isso não é um substituto, é uma opção para quem gosta de JSX.

Eu entendo... Isso não me afetaria dessa maneira, mas como eu disse antes, faltam recursos agora que eu preciso criar um aplicativo flutter.

Uma vez que os fãs do React Native se mudem para o Flutter, haverá toneladas de pessoas para ajudar nessas outras coisas necessárias. A prioridade 1 é roubar o compartilhamento de mente do React Native e torná-lo o mais simples possível para as pessoas do React Native se mudarem.

Então você propõe que a equipe do flutter coloque recursos em espera para algo que é questionável e pode ou não atrair uma fração de um subconjunto específico de desenvolvedores da web?

Como o DSX é 'menos dinâmico' e 'menos expressivo' do que o Dart simples? DSX é Dart, você não tentou o transpilador.

Toda DSL é, por definição, menos expressiva que uma GPL. Com o DSX, como ocultar condicionalmente um widget? Como iterar em uma coleção e mapear cada elemento para um widget? Como usar um interruptor? Agora você precisa criar sintaxe e semântica para construções que você já possui em sua GPL. Então, por que inventar o DSL em primeiro lugar?

claro que é. não é útil para desenvolvedores Flutter atuais, mas é muito útil para designers que podem produzir CSS de suas ferramentas, é muito útil para pessoas investidas na plataforma React Native.

Essa não era a questão... Que problemas uma DSL resolveria que você não pode resolver agora? Você continua dizendo que é melhor, por que é melhor? Não tenho dúvidas de que o DSX atrairia algumas pessoas do JSX. Eu sei que as pessoas não gostam de coisas que são diferentes. E a familiaridade parece ser o único argumento. Então por que não usar CSS?
Por que não usar JavaScript? Mais pessoas sabem como usá-los do que o Dart.

Se você projeta seu sistema baseado em alguma outra coisa com o único propósito de ser familiar, você não está realmente inovando.

@b-strauss para ser claro, JSX compila para chamadas de função (em chamadas React para createElement(ComponentClass) , em Dart devem ser construtores).

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

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

As únicas construções são as transformações entre os nomes dos elementos+atributos e as chamadas de função+argumentos e expressões de escape ( {...} ).

• Com o DSX, como ocultar condicionalmente um widget?

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

• Como faço para iterar em uma coleção e mapear cada elemento para um widget?

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

• Como usar um interruptor?
  Tanto quanto eu sei no Dart como no JS, você não pode usar um switch inline, pois não é uma expressão. Se você estiver fora da árvore de widgets, basta usar um switch normalmente.

Então você propõe que a equipe do flutter coloque recursos em espera para algo que é questionável e pode ou não atrair uma fração de um subconjunto específico de desenvolvedores da web?

@b-strauss, React Native não é desenvolvimento web, é desenvolvimento mobile multiplataforma que é o principal concorrente do Flutter; e sim JSX é como uma fonte de luz, atrairá muitos desenvolvedores React Native. Eu pedi esse recurso em agosto de 2017, muito falando muito pouca ação.

Toda DSL é, por definição, menos expressiva que uma GPL. Com o DSX, como ocultar condicionalmente um widget? Como faço para iterar em uma coleção e mapear cada elemento para um widget? Como usar um interruptor? Agora você precisa criar sintaxe e semântica para construções que você já possui em sua GPL. Então, por que inventar o DSL em primeiro lugar?

Você está completamente errado. A boa notícia é que uma vez eu também estava errado. A maioria (mas não todas) DSLs tentam recriar construções de programação em marcação (e isso não é muito poderoso), JSX traz marcação para programação (aproveitando ao máximo a linguagem do host). A diferença é transformacional. A resposta para todas as suas perguntas é basicamente usar a maneira como você faz isso no Dart porque é o Dart. Tudo entre '{}' é código Dart, com exceção do operador spread. São todas expressões de dardo, mas você também pode usar funções anônimas que retornam uma expressão. Como você vê no transpilador uma tag (\) é apenas uma novidade em um widget (new Text()).

Que problemas uma DSL resolveria que você não pode resolver agora?

Por que usar o Dart quando você pode usar zeros e uns, isso não é tudo o que é necessário para resolver qualquer problema de computação?

Você continua dizendo que é melhor, por que é melhor?

Eu dei minhas razões antes e não vou repeti-las aqui. As pessoas do JSX concordarão comigo, mas 'cada um na sua'.

Não tenho dúvidas de que o DSX atrairia algumas pessoas do JSX. Eu sei que as pessoas não gostam de coisas que são diferentes. E a familiaridade parece ser o único argumento. Então por que não usar CSS?
Por que não usar JavaScript? Mais pessoas sabem como usá-los do que o Dart.

Sim, usar CSS faz sentido para facilitar o fluxo de trabalho do designer-desenvolvedor. DSX suporta isso. A vantagem do Dart sobre o Javascript é a velocidade de execução (desempenho).

Se você projeta seu sistema baseado em alguma outra coisa com o único propósito de ser familiar, você não está realmente inovando.

Você está tão cheio de preconceitos errados que provavelmente estão impedindo você de alcançar todo o seu potencial. Abra sua mente, tente coisas diferentes.

@alexkrolick , obrigado pelos detalhes.

@cbazza

Você está tão cheio de preconceitos errados que provavelmente estão impedindo você de alcançar todo o seu potencial. Abra sua mente, tente coisas diferentes.

Vou cancelar a assinatura desta edição agora. Por favor, nunca me mencione aqui ou em qualquer lugar novamente, thx.

@b-strauss

Desculpe cara, eu não queria ferir seus sentimentos... Eu estava apenas tentando guiá-lo gentilmente enquanto tentava administrar minhas próprias frustrações. Afinal, somos todos humanos.

@cbazza Você pode me enviar um e-mail por favor? [email protected]

Já fiz essa proposta no tópico antigo mas ainda acho que é um ponto importante

IMHO tirando a necessidade de usar new/const já ajudou bastante. Eu tenho dificuldades reais na forma como o formato de dardo formata as árvores. não enfatiza o suficiente a estrutura de árvore IMHO em comparação com:

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

Concordo com o propósito de tornar o flutter simples que não deseja usar a sintaxe do tipo JSX, e também apoio o conceito de divisão em vários widgets, mas agora me deixa sentir que a era MVC está de volta ao jquery. Tal cenário que havia um widget simples, com layout de preenchimento, borda e centro para ele mais tarde, muitos símbolos "} " afetam seriamente a legibilidade. No entanto, é um widget integral, não quero dividi-lo, nada útil solução? Embora meu inglês seja ruim, eu me esforço muito para expressar meus pensamentos.

Senhor nos ajude a todos.

Ok, isso não vai a lugar nenhum. Parece que ninguém está prestes a mudar de lado tão cedo. Definitivamente, precisamos chegar a algum tipo de compromisso aqui. Claro que "pro-DSX" vs "anti-DSX" não tem um compromisso remotamente satisfatório, o que é uma realização frustrante. Será que poderíamos reformular nossas posições para que sejam mais compatíveis?

@naiveaiguy "eles" podem ter seu DSX.
Se a equipe do Flutter não implementá-lo, pode ser uma iniciativa de código aberto.
Isso não significa que a abordagem de dart puro como é agora não funcionará mais.
Ambos os mundos podem coexistir.

Eu concordo tanto com @zoechi que eles podem coexistir ... é isso e eu pensei que isso tinha sido resolvido no tópico antigo

@lrhn

Por favor, todos, sejam civis e construtivos. Estamos discutindo estilo aqui, algo muito subjetivo, então não importa o quanto cada um goste de sua própria preferência, é improvável que seja inerentemente superior à de todos os outros. Liste as vantagens e desvantagens que você vê nas sintaxes existentes e propostas, mas lembre-se de que nem todo mundo vê da mesma maneira, e isso está perfeitamente bem.

Bravo, é isso mesmo.

No React você pode fazer de 4 maneiras (e acabei de descobrir as outras 2 maneiras hoje !!!)

(1) Você pode usar JSX (que é o que eu gosto)
https://reactjs.org/docs/introducing-jsx.html

(2) Você pode usar a maneira original (que é semelhante ao Flutter)
https://reactjs.org/docs/react-without-jsx.html

No final do link acima eles até mencionam 2 projetos comunitários promissores

(3) Sintaxe de hiperscript para marcação React.js
https://github.com/mlmorg/react-hyperscript

(4) Sintaxe concisa para hiperscript.
https://github.com/ohanhi/hyperscript-helpers

Ter alternativas é uma coisa boa, já se foram os dias em que você podia comprar um Ford em qualquer cor que quisesse, desde que fosse preto :)

@naiveaiguy por que é um problema para você se existe a abordagem atual e o DSX?
(isso é o que eu deduzo de seus votos negativos)

@naiveaiguy "eles" podem ter seu DSX.
Se a equipe do Flutter não implementá-lo, pode ser uma iniciativa de código aberto.
Isso não significa que a abordagem de dart puro como é agora não funcionará mais.
Ambos os mundos podem coexistir.

Concordo plenamente com isto. Embora eu ache que deveria ser uma solução conectável em vez de uma solução pronta para uso. Ter um padrão que funcione, mas poder personalizar a experiência com coisas extras é um grande paradigma. Dessa forma, a equipe do Flutter pode manter o foco em (o que eu acredito ser) questões mais relevantes, a comunidade pode experimentar diferentes ferramentas/soluções e então podemos ter uma discussão com mais dados e experiência com DSX ou qualquer outra alternativa ao atual meta.

Ter alternativas é uma coisa boa, já se foram os dias em que você podia comprar um Ford em qualquer cor que quisesse
gostei desde que seja preto :)

Verdade isso. No entanto, acho que todos podemos concordar que não queremos que o Dart/Flutter se torne outro ecossistema JS/Web Frontend. O Flutter ainda nem saiu do beta e já queremos que ele tenha 2 padrões para algo meio subjetivo.

No React você pode fazer de 4 maneiras (e acabei de descobrir as outras 2 maneiras hoje !!!)

A maioria é orientada para a comunidade, embora React se refira a eles. Bom no meio. Agora, apenas 2 deles são oficialmente suportados: o React.createElement e o modo JSX, que é um wrapper sobre o outro. O valor do JSX é notório nesse contexto, mas não está tão claro aqui. Com isso em mente, podemos nos encontrar no meio do caminho tendo apenas um padrão oficial e os documentos referenciando DSX sempre que relevante?

Acredito que a equipe do Flutter deveria se concentrar nos recursos ausentes que realmente impedem os desenvolvedores de criar aplicativos. Não posso recomendar o Flutter aos meus gerentes se não pudermos adicionar suporte ao Maps e o desenvolvimento de recursos de câmera levar 2 semanas.

Tenha em mente que não vou fechar a porta do DSX para sempre. Talvez se torne a solução para a construção da interface do usuário, mas precisamos que a comunidade experimente para tomar essa decisão.

@zoechi Pessoalmente, não acredito que as duas ideias possam coexistir no estado atual do Flutter - realmente não deveríamos incentivar uma divisão dessa natureza tão cedo - mas, neste momento, parece o único compromisso.

@naiveaiguy

Pessoalmente, não acredito que as duas ideias possam coexistir no estado atual do Flutter - realmente não deveríamos estar incentivando uma divisão dessa natureza tão cedo

Você poderia ser mais específico sobre por que eles não podem coexistir? (dado o fato de que o DSX é apenas açúcar sintático; ou como @emalamela diz "apenas um wrapper da maneira atual").

Além disso, por que é muito cedo para fornecer uma sintaxe diferente exatamente para a mesma coisa? Estou basicamente perguntando por que há necessidade de adiar isso, o que seria diferente no futuro que ainda não existe agora?

@emalamela

No entanto, acho que todos podemos concordar que não queremos que o Dart/Flutter se torne outro ecossistema JS/Web Frontend.

Pessoalmente, prefiro não colocar limites no que as pessoas podem fazer com Dart/Flutter. Deixe o mercado/comunidade decidir. Basicamente, se o que é criado não agrega valor, as pessoas não o usarão e ele morrerá. Se se torna popular, é porque a comunidade o achou útil e o valorizou. Não há necessidade de escolher vencedores e perdedores agora.

A única coisa que está me impedindo de experimentar o Flutter é o fato de que eles optaram por não usar o JSX.
IMHO JSX é a melhor escolha para expressar a hierarquia de componentes

Ouvi falar sobre o Flutter, quis experimentá-lo, imediatamente parei mesmo considerando que no minuto em que vi a sintaxe, o que é uma pena, porque as chances são de que isso seja uma ótima tecnologia. para construir produtos.

Eu tenho feito desenvolvimento React/React Native nos últimos 2,5 anos, sacrificar a alavancagem de produtividade que a sintaxe JSX oferece quando se trata de descrever a interface do usuário é pedir muito. Eu consideraria seriamente gastar o tempo para aprender tudo sobre o Flutter e estudar se vale a pena mudar para quando esse recurso é suportado imediatamente.

Eu nem consigo imaginar o número de potenciais adotantes/usuários/devs que o Flutter está perdendo por causa disso, revisitará nos próximos meses.

Eu nem consigo imaginar o número de potenciais adotantes/usuários/devs que o Flutter está perdendo por causa disso, revisitará nos próximos meses.

Sim, 44 Mio acharam importante o suficiente para votar :D

Sim, 44 acharam importante o suficiente para upvote :D

Quando classificado por 'upvote', essa solicitação de recurso é listada em 7º na lista de 3131 tickets abertos.

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

@cbazza Não quero argumentar contra o recurso, mas comentários como "se você não fizer x, horrivelmente y acontecerá" são simplesmente ridículos.

Eu tenho feito desenvolvimento React/React Native nos últimos 2,5 anos, sacrificar a alavancagem de produtividade que a sintaxe JSX oferece quando se trata de descrever a interface do usuário é pedir muito. Eu consideraria seriamente gastar o tempo para aprender tudo sobre o Flutter e estudar se vale a pena mudar para quando esse recurso é suportado imediatamente.

@sonaye

Já que você mencionou a produtividade, você pode fornecer um exemplo que mostre claramente a perda de produtividade do uso do Flutter's Pattern em vez do JSX? O exemplo deve ser construído com base no conhecimento suficiente de JS e Dart para poder codificar o referido exemplo. Acredito que, se não levarmos isso em conta, também estamos comparando linguagens de programação, o que não é a mesma discussão.

Quando classificado por 'upvote', essa solicitação de recurso é listada em 7º na lista de 3131 tickets abertos.

@cbazza

É também o mais votado. É bastante controverso.

@emalamela ,

É também o mais votado. É bastante controverso.

Como essa solicitação de recurso é uma alternativa à maneira atual e não altera a maneira atual, não deve haver nenhuma controvérsia; se você não gosta de JSX/DSX continue programando como faz hoje.

A chamada controvérsia só existe porque a equipe do Flutter precisa fazer um trabalho para que a comunidade possa fazer o DSX corretamente. Se as ferramentas Flutter (compilador, analisador, suporte a ide, etc) suportassem pré-processamento com mapas de origem, o DSX já teria sido feito há muito tempo, e provavelmente outras inovações/ideias de linguagem, de desenvolvedores de terceiros, também teriam acontecido.

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

Torna-se:

<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 O argumento a favor e contra o JSX foi esgotado pela discussão, há muito material que você pode pesquisar. Estou apenas compartilhando minha opinião pessoal.

Primeiro, a legibilidade do código. Posso obter imediatamente uma ideia clara e nítida sobre a estrutura da interface do usuário em JSX (leva segundos), o modal mental é muito visual. Segundo, usabilidade. Eu diria que o JSX pode ser usado mesmo sem conhecer JS/Dart ou qualquer coisa sobre API subjacente. Isso é muito adequado para alguém que está apenas aprendendo programação, ou para alguém que faz parte da minha equipe, os designers agora podem codificar a interface do usuário.

A descrição do aplicativo é completamente declarativa (não apenas expressiva), quando você trabalha em um projeto grande com centenas de componentes, essa forma de descrever a interface do usuário faz uma enorme diferença (você precisa experimentar para realmente apreciá-la). Eu também não gostei do JSX quando o vi pela primeira vez, uma vez que o usei me senti bem, é assim que quero descrever a interface do usuário a partir de agora, foi um avanço claro na maneira como abordo a construção de interfaces.

Não se trata de escrever menos linhas de código, não se trata de ter um "açúcar de sintaxe", trata-se de construir ferramentas para humanos. Também sou contra o argumento de que todos deveriam usar JSX, isso é ridículo. Você usa a ferramenta que permite fazer seu trabalho mais rápido e com menos confusão, no caso de muitos (inclusive eu), seria JSX (ou DSX no caso do Flutter), só isso.

Estou vindo do React e pela primeira vez testando o Flutter. É realmente estranho que a equipe do flutter não tenha sintaxe JSX, quero dizer, sério! No mundo JS, JSX é extremamente prevalente em todas as alternativas React hoje em dia! JSX é super amigável para desenvolvedores. Por favor, implemente isso o mais rápido possível, para que você possa ajudar a aumentar a comunidade.

Você pode dizer que JSX (ou DSX neste caso) é um grande negócio apenas observando a quantidade de comentários nesta edição.

JSX é algo que você não sabe que ama até experimentar. É estranho no começo ter marcação em seu código, mas depois se torna incrível.

Parece desnecessário para caras que já conhecem o flutter/dart, eu entendo. Mas para alguém que nunca tocou em dardo (como eu), JSX é muito mais fácil de começar e esse é o ponto. Se vocês querem que mais pessoas venham e comecem a construir coisas muito mais incríveis, as ferramentas precisam ser mais fáceis.

E, como @eseidelGoogle (https://youtu.be/h7HOt3Jb1Ts?t=2m41s) disse ao outro cara "Flutter é uma maneira de escrever para iOS e Android em uma única base de código. Tentamos tornar isso rápido e fácil [. ..] Flutter fala até o hardware [...] Temos uma abordagem muito em camadas, então você pode levar o quanto quiser. [...] Temos muito investimento em ferramentas ."

Implemente JSX, por favor.

Eu sou um fã de Dart e também um usuário pesado de react. Eu sempre acho o Dart terser e mais sustentável do que o JSX. Então, acho que JSX/DSX poderia e talvez devesse ser implementado de forma comunitária.

@rajaraodv Só porque o Flutter é promovido como um framework de estilo reativo não significa que é apenas um sabor do ReactJS.
Da maioria dos comentários, tenho a impressão de que as pessoas têm dificuldade em aceitar que algo novo não é o mesmo que eles já sabem.

Você pode tentar trabalhar com o Flutter por um tempo como está atualmente e, em seguida, fornecer argumentos adequados por que você acha que o JSX / DSX seria melhor do que o Dart simples de uma maneira factual, em vez de apenas "por causa da preferência pessoal" ou "porque é melhor" .

@zoechi , está faltando algo: o flutter foi inspirado no React, de acordo com o documento do Flutter.
Talvez seja apenas o meu problema. Eu realmente sinto que tenho dificuldade em ler o código da interface do usuário, mesmo que esteja na sintaxe do Dart 2.

flutter foi inspirado no React Native

Não vejo como isso diz "tudo é o mesmo, exceto que a linguagem é chamada Flutter em vez de JS".

Eu realmente sinto que tenho dificuldade em ler o código da interface do usuário

e você afirma que a única solução imaginável para isso é o DSX?

Você já considerou que o Flutter não é nem 1.0 e que o suporte IDE pode melhorar com o tempo?

Houve apenas os primeiros pequenos passos dados recentemente para obter melhor suporte ao Flutter IDE no editor de código, como correções rápidas ("wrap xxx") e rótulos de fechamento.

Existem possibilidades ilimitadas para melhorar a experiência do desenvolvedor e a maioria nesta discussão é como
"Flutter ainda não é perfeito e, portanto, precisamos de DSX"
geralmente sem argumentos concretos sobre como ou por que o DSX resolveria ou melhoraria isso.

@zoechi ,

Você pode tentar trabalhar com o Flutter por um tempo como está atualmente e, em seguida, fornecer argumentos adequados por que você acha que o JSX / DSX seria melhor do que o Dart simples de uma maneira factual, em vez de apenas "por causa da preferência pessoal" ou "porque é melhor" .

Mais uma vez, Plain Dart ou DSX é simplesmente uma questão de estilo, não adianta discutir qual é o melhor. É apenas uma preferência pessoal e as pessoas têm suas razões para escolher um ou outro.

O que aconteceu no React World é que uma vez que você usa JSX, você simplesmente não volta mais. Como outros afirmaram acima, você fica viciado em JSX depois de usar por algum tempo. JSX foi adotado por outros fora do React's World (Typescript, Vue) e é uma ótima opção para o Flutter.

e você afirma que a única solução imaginável para isso é o DSX?

O que a comunidade precisa é de recursos genéricos de pré-processamento com suporte ao mapa de origem embutido nas ferramentas Dart (compilador, analisador, IDE, etc.) completo, etc).

Existem possibilidades ilimitadas para melhorar a experiência do desenvolvedor e a maioria nesta discussão é como
"Flutter ainda não é perfeito e, portanto, precisamos de DSX"
geralmente sem argumentos concretos sobre como ou por que o DSX resolveria ou melhoraria isso.

Claro, o problema é que esse ticket não é sobre uma coisa genérica de 'melhorar a experiência do desenvolvedor'. É muito específico e trata-se de obter suporte a JSX no Flutter. A comunidade quer o DSX como uma alternativa ao jeito simples do Dart.

Não consigo me ver usando isso (mas estou disposto a tentar). Eu não acho que esta é uma bala de prata, mas há tanto entusiasmo que vale a pena fazer.

Acho que o Google deveria remover os obstáculos de linguagem para permitir que a comunidade construa o que quiser.

Não estou ciente de nenhum obstáculo que impeça alguém de fora das equipes Flutter/Dart do Google de escrever algo semelhante ao JSX para Dart/Flutter. Eu adoraria ver bugs neles se alguém estiver tentando. (Também é possível que eu tenha perdido eles nos comentários acima, já que admito não ter lido todas as palavras desse bug muito longo.) :)

Obrigado! Fico feliz em ver tanto entusiasmo!

@eseidelGoogle ,

Como o Intellij e/ou o VS Code (com Dart-Code) poderiam definir pontos de interrupção e percorrer o código de um arquivo .dsx? (Quero dizer, este não é um arquivo .dart). Que tal a funcionalidade de preenchimento automático do arquivo .dsx (como em um arquivo .dart)?

Você investiu muito nas ferramentas, mas as ferramentas não suportam pré-processamento (com mapas de origem) de uma nova linguagem (como DSX) que transpila para Dart/Flutter perfeitamente.

Um transpilador está disponível, mas não há uma maneira fácil de integrá-lo totalmente:
https://spark-heroku-dsx.herokuapp.com/index.html

PS Este bilhete é apenas metade dos comentários !!!
https://github.com/flutter/flutter/issues/15922

@cbazza existe um repositório com esse compilador em algum lugar? Seria ótimo compartilhar o código e envolver a comunidade em hackear, mesmo que não seja perfeito.

@jonahwilliams , não, o código do transpilador DSX não foi lançado porque é muito cedo para isso.
Você pode simplesmente usar 2 arquivos equivalentes escritos à mão (.dsx e .dart) para testar os recursos de pré-processamento, como pontos de interrupção, depuração, preenchimento automático etc.

Uma vez que as ferramentas suportam pré-processamento com algum tipo de mapa de origem, posso adicionar isso ao transpilador e ser desbloqueado. Isso também permitiria que outros experimentassem os desejos de seus corações.

Eu não trabalho no Flutter, mas parece meio irracional exigir certas ferramentas para beneficiar outras, mas também me recusar a liberar qualquer código-fonte inicial ou exemplos do que você deseja que as ferramentas se integrem.

Se vale a pena, não conheço nenhuma linguagem ou kit de ferramentas que forneça ganchos de pré-processamento de qualquer tipo - provavelmente porque simplesmente não é fácil, há muitos casos e suposições em torno da linguagem e da sintaxe.

Se você gerou mapas de origem (https://pub.dartlang.org/packages/source_maps), imagino que obter pelo menos algum suporte básico em um IDE seja bastante trivial, independente do Dart/Flutter. Mas, novamente, tudo isso é conjectura sem saber o que seu ferramental faz e como você espera que funcione.

@matanlurey , o suporte ao pré-processamento via mapas de origem é um mecanismo genérico que não depende de nenhum transpilador específico. É uma funcionalidade destinada a suportar qualquer linguagem futura imaginável. O navegador/depurador Chrome suporta muito bem e posso depurar qualquer linguagem que transpile para JS.

Para testar, você pode criar qualquer tipo simples de transpilador para mostrar como usar mapas de origem. Por exemplo, escreva um transpilador trivial que gere código Dart/Flutter com uma linha em branco entre cada linha do arquivo original. (.d2 => .dart, .d2 é arquivo Dart/Flutter, o arquivo .dart conterá uma linha em branco entre cada linha do arquivo original).

Sim, posso trabalhar na geração do mapa de origem para um arquivo de teste.

Atualmente, o Flutter está relutante em tentar agradar NativeScript, ReactNative, Android, Web e outros desenvolvedores acostumados a layouts XML semelhantes. Eles têm coisas mais importantes para fazer, então vamos nos separar e dormir.

Desejei que Amy, proponente do JSX Syntax, passasse alguns dias realmente trabalhando com o Flutter antes de continuar lamentando. Eu vim de um sistema baseado em Xaml, mas rapidamente me acostumei. Basta dar-lhe uma verdadeira tentativa.

@escamoteur
Ei, escamoteur. Você acha que eu não passei muito tempo aprendendo flutter?
No flutter.io/tutorials/layout/, no final da seção "Embalando widgets", o código que o tutorial forneceu não funciona.
Eu mencionei o problema no bloco de problemas de vibração, mas ninguém quer se preocupar com isso.

• Código do 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 existe alguma conexão do seu comentário com o tópico desta edição?

@zoechi
escamoteur disse que espera que o proponente do JSX Syntax passe alguns dias realmente trabalhando com o Flutter antes de continuar lamentando.
Este comentário mostra que realmente passamos muitos dias trabalhando com o Flutter, e o pedido do JSX é realmente o nosso sentimento do coração.

Group Dart: "A sintaxe do Dart é muito melhor e o JSX/DSX simplesmente não é bom"
Grupo JSX/DSX: "A sintaxe JSX/DSX é muito melhor e o Dart simplesmente não é bom"

Eu não posso ser a única pessoa a ver isso? Ambos os lados fazem pontos válidos a favor e contra sua posição. Acho que o que se perde aqui é que @cbazza não só teve críticas, MAS TAMBÉM FEZ ALGO SOBRE ISSO. Tentando preencher a lacuna de web devs/react/react-native e flutter para beneficiar o Flutter.

E meus 2 centavos... Como um desenvolvedor de pilha completa, tenho exp com uma ampla variedade de linguagens e abordagens... JSX é uma das minhas maneiras favoritas de escrever código e espero que haja uma sintaxe alternativa para Darts. E não estou dizendo que a sintaxe atual é ruim, é só que eu prefiro o estilo JSX.

Tenho que discordar desta citação do Grupo JSX/DSX

Dart não é bom

Dart é uma linguagem muito boa e robusta, ninguém está falando mal da linguagem. A discussão não é sobre o Dart, mas uma camada sintética em cima dele que a maioria dos desenvolvedores de UI já usa hoje, e estamos propondo que o Flutter incorpore algo assim.

• O Android tem layouts XML.
• iOS tem Storyboard XIB (XML)
• GTK+ tem XML para Pango etc.
• Qt tem QML (como YAML)
• Xamarin tem XAML

A maioria desses frameworks e linguagens tem linguagens de marcação de interface do usuário que separam a View da lógica do Controller. Então o React vem com uma abordagem diferente (que estamos propondo aqui) e acho que temos que concordar que o RN está voando agora em termos de crescimento e popularidade de usuários, e posso estar errado, mas principalmente por causa do JSX.

...

É realmente uma proposta tão louca que temos que obter esse tipo de feedback da equipe/usuários do Flutter?

@birkir e todos eles trazem uma série de problemas que Flutter não tem \o/
Não há necessidade de outro idioma.
Você também pode separar a visualização no Flutter, mesmo com o mesmo idioma.

@birkir este tópico é 100% sobre Dart e sintaxe.

A discussão não é sobre o Dart, mas uma camada sintética em cima dele que a maioria dos desenvolvedores de UI já usa hoje, e estamos propondo que o Flutter incorpore algo assim.

Então não é sobre o Dart... mas o Flutter precisa usar algo além do Dart para layouts? Parece que você está dizendo que Dart não é bom o suficiente enquanto também afirma que isso não tem nada a ver com Dart?

Eu não acho que isso importe neste momento, a equipe do Flutter viu esse feedback (ao solicitar uma abordagem JSX/DSX) e eles querem continuar no caminho original. Eu acho que poderia ser tratado melhor, mas não parece que eles se oponham à comunidade criando soluções.

Estou feliz por haver outra opção de plataforma cruzada... a Apple será a próxima a oferecer algo? E talvez eles vejam o que tantos de nós gostamos em reagir/reagir-nativo? IDK se eles têm alguma coisa cozinhando.

a equipe do Flutter viu esse feedback (sobre a solicitação de uma abordagem JSX/DSX) e eles

Este bug ainda está aberto porque não descobrimos o que queremos fazer aqui. Estamos olhando ansiosamente para os experimentos (por exemplo, cbazza's) para ver como as pessoas os usam. Estamos planejando, em algum momento, fornecer um gancho no sistema de compilação para ferramentas codegen como essa, embora isso não seja algo que provavelmente faremos em um futuro próximo. A longo prazo, esperamos usar o que aprendemos aqui para influenciar o desenvolvimento do Dart como linguagem. Isso pode significar adicionar algo como E4X/H4X/JSX/DSX ao próprio Dart. Ou talvez aprendamos que ninguém realmente acaba usando, então não faremos nada. Ou talvez todos precisem de algo diferente, então ganchos de codegen e pacotes personalizados como cbazza's são a resposta. Nós ainda não sabemos.

@jstansbe - A Apple acha que plataforma cruzada significa IPhone, IPad e Mac OS. Eles são mais propensos a adicionar torres no topo do jardim murado do que construir algo de plataforma cruzada :)

Acho que se fosse possível recuar e formatar o widget de outra forma seria mais parecido com jsx e amigável para usuários que tem experiência com xml e html (quase todos os devs android)... verifique este código no 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
      ],
    ),
  );

verifique este código de dardo para jsx

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

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

e compare com este outro formato mais 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),),)
              ],
            )
    );

isso é um pouco mais parecido e agora você só precisa ver da esquerda para a direita para notar os diferentes widgets semelhantes a html/xml/jsx

os atributos do elemento (widget) tem mais recuo que os novos widgets, então isso deixa mais claro poder entender e verificar o código

seria ótimo se eu pudesse ter recuo automático para este formato nos diferentes lados, agora eu faço isso manualmente....

Depois de ler todos os comentários aqui e discutir em particular com meus amigos (desenvolvedores de aplicativos móveis nativos, java/kotlin/objective-c/swift guys), minha observação:

As pessoas estão pedindo duas coisas,

• __Melhor legibilidade e escrita mais fácil__. Aninhamento profundo misturado com alguns ruídos de sintaxe (parênteses, ponto e vírgula, new , child , children ) é irritante na maneira atual de codificação.
• __Estilo/design separado do código__. A separação visual é boa para leitura (diferenciando o estilo do código imperativo com um olhar) e uma separação real é boa para ferramentas (por exemplo, IDE com Layout Editor).

Há também principalmente dois grupos com opiniões diferentes,

• Melhorar a sintaxe atual sem introduzir outra complexidade para resolver o problema.
  Já houve algumas melhorias nesse sentido. Por exemplo, o opcional new , const no Dart 2.0 e o recurso virtual "closing tag" comments proposto.
• Apresentando linguagens de marcação extras (como JSX ou XML) para resolver o problema.

Você não pode concluir facilmente qual é o melhor no momento. Então deixe a comunidade fazer seus experimentos primeiro e tomar a decisão final (aceitar ou rejeitar) depois.

Comentários de tag de fechamento virtual @hooluupog já funcionam no IntelliJ, AS, VSCode há algum tempo

@Hixie

Este bug ainda está aberto porque não descobrimos o que queremos fazer aqui. Estamos olhando ansiosamente para os experimentos (por exemplo, cbazza's) para ver como as pessoas os usam.

As pessoas não podem usar meus experimentos porque eles não podem ser incorporados perfeitamente agora ao Flutter; por isso continua a ser uma experiência externa/online onde as pessoas só podem ver o potencial.

Estamos planejando, em algum momento, fornecer um gancho no sistema de compilação para ferramentas codegen como essa, embora isso não seja algo que provavelmente faremos em um futuro próximo. A longo prazo, esperamos usar o que aprendemos aqui para influenciar o desenvolvimento do Dart como linguagem.

Você pode ser mais específico em relação ao tempo para quando podemos esperar algum movimento nas alterações do sistema de compilação para dar suporte ao pré-processamento? Estamos falando de um mês, um trimestre, seis meses, um ano, 2 anos, uma década, um jubileu, etc.

Isso pode significar adicionar algo como E4X/H4X/JSX/DSX ao próprio Dart.

Por favor, leia os parágrafos principais da especificação JSX para ver que não há necessidade de alterar a linguagem Dart, pois JSX/DSX não tem semântica e não deve ser implementado por mecanismos ou incorporado em linguagens. Destina-se a ser usado em um pré-processador (transpilador). O DSX pode ser usado com o Flutter e na Web para tornar o React-Dart exatamente como o React.js, mas com a linguagem Dart.

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

Ou talvez aprendamos que ninguém realmente acaba usando, então não faremos nada.

Como as pessoas podem usar algo que não está disponível para uso em primeiro lugar e então concluir que nada precisa ser feito porque as pessoas não estão usando? Isso me lembra muito a imitação de Sean Spicer de Melissa McCarthy no SNL sobre a 'proibição de viagem'... 'uso circular da palavra' :)

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

Ou talvez todos precisem de algo diferente, então ganchos de codegen e pacotes personalizados como cbazza's são a resposta. Nós ainda não sabemos.

Os recursos de pré-processamento são extremamente necessários para permitir a experimentação. Sem ela nada avança e você não aprenderá nada de novo.

As pessoas não podem usar meus experimentos

Acho que você subestima o quanto as pessoas estão dispostas a experimentar coisas, mesmo quando não estão totalmente polidas. Por exemplo, alguém poderia facilmente escrever um shell script que envolvesse flutter run para fazer o pré-processamento primeiro e depois chamar flutter run . Eu mesmo tenho um script que envolve o hot reload para fazer algo semelhante (eu executo o analisador primeiro, então somente se ele passar eu envio o sinal de hot reload para o script flutter ).

Você pode ser mais específico em termos de tempo para quando podemos esperar algum movimento nas mudanças do sistema de compilação

Não realmente (veja, por exemplo, https://en.wikipedia.org/wiki/Forward-looking_statement para saber por que pode ser difícil fazer tais declarações), mas provavelmente não nas próximas semanas.

não há necessidade de alterar o idioma do Dart

Isso é bem possível, de fato. Estou apenas dizendo que, com base nesses experimentos, podemos chegar a várias conclusões, desde "não fazer nada" até "adicionar novos recursos radicais à sintaxe da linguagem" e qualquer coisa entre eles. A questão é que ainda não tomamos nenhuma decisão e estamos muito abertos a aprender o que precisa ser feito com base em todas essas discussões e experimentos.

Adicionar JSX à lista de pendências e deixá-lo competir, no estilo gladiador, com os mais um milhão de outros requisitos urgentes?

O React é escrito para a web e, portanto, precisa de uma solução simples para escrever HTML. JSX não se tornou popular porque é a melhor solução para escrever UIs, mas porque é a melhor solução para escrever HTML.

O Flutter não tem essa restrição, então não devemos nos contentar com uma solução medíocre e detalhada pelos motivos errados.

Se quisermos reduzir a verbosidade, prefiro me inspirar, por exemplo, no Anko (https://github.com/Kotlin/anko/wiki/Anko-Layouts). Lá você pode definir novas variáveis ​​locais em qualquer lugar e usar loops for normais para construir dinamicamente a lista de filhos, o que pode tornar o código mais fácil de seguir. Além disso, o LayoutBuilder se tornaria mais fácil aos olhos, pois cada nível de aninhamento já é uma função lambda de qualquer maneira (não há necessidade de passar um construtor lambda extra). De qualquer forma, isso é apenas para inspiração e não acho que Flutter deva copiar esse 1:1.

O React é escrito para a web e, portanto, precisa de uma solução simples para escrever HTML. JSX não se tornou popular porque é a melhor solução para escrever UIs, mas porque é a melhor solução para escrever HTML.

React Native não é desenvolvimento web nem usa HTML. Pergunte a desenvolvedores experientes do React (ou leia completamente este e o outro thread JSX) e você verá que o JSX é considerado por muitos desenvolvedores React como a melhor maneira de escrever UIs.

Lá você pode definir novas variáveis ​​locais em qualquer lugar e usar loops for normais para construir dinamicamente a lista de filhos, o que pode tornar o código mais fácil de seguir.

Esta declaração demonstra claramente que você não conhece JSX. JSX (como no DSX) usa todas as construções de programação (for-loops, etc) da linguagem de hospedagem (Javascript/Dart).

Este ticket está interessado apenas na funcionalidade do tipo JSX, para outras abordagens (como Anko), crie seu próprio ticket para discussão lá.

React Native não é desenvolvimento web nem usa HTML. Pergunte a desenvolvedores experientes do React (ou leia completamente este e o outro thread JSX) e você verá que o JSX é considerado por muitos desenvolvedores React como a melhor maneira de escrever UIs.

O React foi lançado muito antes do React Native. O design original do JSX é baseado em Rendering HTML, não em UIs nativas. Ninguém foi capaz de mostrar um único argumento convincente para o que o JSX faz melhor. Comparando

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

para

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

você não fez uma comparação atualizada e está simplesmente colocando mais coisas em uma única linha. Você deve compará-lo com:

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

Observe como todas as tags feias {<{<>} />} e </...> fechamento sumiram.

Esta declaração demonstra claramente que você não conhece JSX. JSX (como no DSX) usa todas as construções de programação (for-loops, etc) da linguagem de hospedagem (Javascript/Dart).

Não, você não pode usar instruções if ou for-loops (ou switch ou qualquer outra instrução) dentro do 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>
  )
}

Apenas expressões são permitidas. Então você deve usar operadores condicionais ( c ? x : y , o que torna else if muito feio) e Array.map etc. (o que também pode ser muito feio) ou mover partes do seu código para o topo da função de renderização ou em uma função auxiliar separada. É o mesmo com o Flutter, é claro. O Anko não tem essa limitação e torna a escrita de (alguns) códigos de interface do usuário mais natural.

Acho que em uma discussão sobre a introdução do JSX é bastante válido e necessário perguntar se essa é realmente a melhor solução ou se podemos encontrar algo melhor. Caso contrário, desperdiçaremos recursos nas tarefas erradas.

O React foi lançado muito antes do React Native. O design original do JSX é baseado em Rendering HTML, não em UIs nativas.

O design original do JSX é sobre uma maneira familiar de criar/manipular estruturas de árvore que aparecem especialmente ao fazer o trabalho de interface do usuário; pense em hierarquias de componentes (https://facebook.github.io/jsx/) que aparecem no desenvolvimento web, desenvolvimento nativo, qualquer desenvolvimento de interface do usuário, etc.

Ninguém foi capaz de mostrar um único argumento convincente para o que o JSX faz melhor.

Esse é o ponto, não estamos procurando substituir a maneira atual, estamos procurando adicionar uma maneira alternativa que seja familiar aos desenvolvedores do React.

Sua proposta do Anko seria familiar para os desenvolvedores do Android Kotlin, então vá em frente e proponha uma especificação que funcione com a hierarquia atual do Flutter em um ticket separado. Depois de ver (ou tentar uma versão on-line de sua especificação), poderei ver se ele pode gerar/interoperar com a hierarquia atual do widget Flutter.

Não, você não pode usar instruções if ou for-loops (ou switch ou qualquer outra instrução) dentro do JSX:

Não que eu recomende você fazer isso, mas é possível: crie uma função anônima e chame-a.

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>
  )
}

Acho que em uma discussão sobre a introdução do JSX é bastante válido e necessário perguntar se essa é realmente a melhor solução.

Não existe a melhor solução, trata-se de ter escolha, ter a opção de usar algo familiar que mapeia diretamente para widgets Flutter e não adiciona sobrecarga.

A propósito, tente o seguinte no meu transpilador online em:
https://spark-heroku-dsx.herokuapp.com/index.html

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

e você obtém:

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

O DSX é semelhante ao JSX, mas para Dart & Flutter, portanto, possui recursos próprios descritos no link acima.

quando vejo isso, recebo flashbacks de layouts xml do Android. Não acho que seja uma boa ideia implementar isso. Agora que você nem precisa escrever new e const fica ainda melhor.

@charafau Você pode compartilhar um exemplo/img/link de "layouts xml do Android" ao qual você está se referindo?

Não, @wkornewald. Se "JSX não se tornou popular porque é a melhor solução para escrever UIs, mas porque é a melhor solução para escrever HTML", por que o React ainda usa JSX para construir um aplicativo móvel e um aplicativo de desktop? Até mesmo seu aplicativo de desktop Github, aplicativo móvel multiplataforma Walmart, aplicativo Tesla e Skype também são criados pela RN.

O React não coloca um loop for na tag JSX porque o conceito do React é sobre o componente. A parte superior é a lógica e a parte inferior é o JSX, e é sempre assim. Tudo é separado em muitos componentes e conectado em um grande componente.

Na verdade, a maioria das pessoas aqui que são contra o JSX só podem adivinhar que o JSX é algum tipo de HTML, XML ou uma solução menos detalhada.

@JonathanSum

a maioria das pessoas aqui que contra JSX só pode adivinhar que JSX é algum tipo de HTML

Acho que é porque não havia outros argumentos a favor do JSX/DSX além da preferência pessoal. Tudo bem, é claro, como discutido acima, mas por favor, não insinue que as pessoas são contra o JSX porque não o entendem, quando não há uma lista de bons argumentos factuais que mostrem onde o JSX é melhor do que o Dart simples.

Acho que é porque não havia outros argumentos a favor do JSX/DSX além da preferência pessoal.

Não realmente, muitos foram dados antes, basta ler completamente ambos os tópicos. Eu mencionei essas 2 coisas antes:
(1) Chega de coisas de 'criança' e 'crianças'
(2) fácil para ferramentas de terceiros manipularem (analisar, analisar e regenerar)

Com (2) você pode aprimorar a marcação para fazer coisas que não são possíveis apenas com o Dart; por exemplo, o operador spread do DSX ou a geração de muitos parâmetros de função a partir de um conjunto menor.

Outros forneceram muitos pontos positivos, mas não estou descobrindo para você;)

(1) como mencionado, essas coisas também podem ser alteradas/melhoradas no Dart e já houve discussões. Isso simplesmente não acontecerá antes do lançamento do Dart 2.
Apenas assumir que o DSX permite todos os tipos de novos recursos e o Dart não não é realmente um argumento justo na minha opinião.
(2) Tenho certeza de que isso também pode ser feito com o Dart e é claro que já existe um analisador para o Dart.

Outros forneceram muitos pontos positivos, mas não estou descobrindo para você;)

Não há necessidade de desenterrá-los para mim , mas isso aparece com frequência e você pode convencer os outros de que realmente tem argumentos válidos.
Acompanhei a discussão e não me lembro de bons argumentos factuais e isso pode ser o mesmo para outros. Se você resumi-los, você pode simplesmente postar um link para o próximo que questiona isso.

Como discutido antes, posso aceitar a preferência pessoal como um argumento válido, mas se você alega ter muitos argumentos factuais também, acho válido pedir para apontá-los.

Você continua pedindo 'argumentos válidos' e quando eles são dados, você os descarta como 'futuro Dart terá isso' ou 'este não é um argumento válido'.

O fato é que agora o Dart/Flutter tem filhos/filhos barulhentos em todos os lugares ao construir um widget e o XML/DSX não. No momento, é um argumento muito válido para usar o DSX para remover esse ruído filho/filhos. Você pode simplesmente aceitar isso como um argumento válido? (só porque você diz que o Dart terá isso no futuro, isso não torna o argumento inválido).

Também é fato que analisar XML é muito mais simples do que analisar a linguagem Dart completa e todas as linguagens existentes têm um analisador XML, enquanto apenas o Dart possui um analisador de linguagem Dart completo. Você pode ver que este também é um argumento válido?

Existem muitos argumentos válidos, eles simplesmente não são válidos para você e é por isso que parei de discutir sobre isso. Se as pessoas estiverem interessadas no que foi dito, basta ler os 2 tópicos no JSX completamente. Não tenho interesse em convencê-lo a usar o DSX, você está feliz com o Dart simples, que assim seja; Eu não sou.

Argumentos para uma sintaxe DSX opcional:

1) Integrar e atrair mais desenvolvedores vindos do React (web e nativo)
2) Melhor experiência de portar componentes React Native para widgets Flutter
3) Impulsiona a consistência das propriedades filho/filho em widgets
4) Legibilidade do código (argumento opinativo)
5) Visualize o linting lógico separado do linting de dardo
6) Abre um mundo para ferramentas de construção de interface do usuário
7) Abre o ecossistema para pré-processadores

DSX +1

DSX +1

Adoraria escrever um monte de prós e contras, mas depois de ler todos esses comentários, sinto que vou repetir tudo várias vezes.
Pare de ser tão ingênuo e ignorante, ninguém diz que você será forçado a escrever UIs usando DSX, é simplesmente uma opção (melhor alternativa).
Há uma razão pela qual você pode escrever JS de 101203103 maneiras diferentes.

Bem, sempre há a opção de escrever um plug-in analisador que analisa o DSX e os converte em chamadas de função Dart regulares, para que o compilador não precise fazer nenhum trabalho extra.

A verdadeira questão é se os plugins do analisador se aplicam no contexto do compilador.

Se você me perguntar, o DSX deve ser apenas opt-in, idealmente por meio de algum tipo de plug-in. Acho extremamente desnecessário adicioná-lo à linguagem em si, pois os usuários do lado do servidor e da Web do Dart precisam se adaptar às mudanças, não apenas os usuários do Flutter. A grande maioria do código escrito em Dart não precisa nem remotamente de nenhuma sintaxe XML, portanto, impô-la a todos é uma decisão ruim.

TLDR; se você quer DSX tão ruim, escreva um plugin analisador e traga-o para o Dart você mesmo. A Internet vai te amar, você terá milhares de estrelas do Github e você se sentirá como se fosse React. Ganha-ganha.

PS eu vou até competir com você para fazer isso

Bem, sempre há a opção de escrever um plug-in analisador que analisa o DSX e os converte em chamadas de função Dart regulares, para que o compilador não precise fazer nenhum trabalho extra.

Atualmente, não há como implementar isso na linguagem dart sem hacks (pense em condições de corrida, importações recursivas e outras coisas). Isso precisa ser integrado no nível em que tudo funcionará conforme o esperado, recarga a quente, análise estática, etc.

Se você me perguntar, o DSX deve ser apenas opt-in, idealmente por meio de algum tipo de plug-in. Acho extremamente desnecessário adicioná-lo à linguagem em si, pois os usuários do lado do servidor e da Web do Dart precisam se adaptar às mudanças, não apenas os usuários do Flutter. A grande maioria do código escrito em Dart não precisa nem remotamente de nenhuma sintaxe XML, portanto, impô-la a todos é uma decisão ruim.

Se você ler o tópico, essa foi a ideia desde o primeiro dia. Queremos apenas o suporte do flutter/dart para fazer um transpilador.

TLDR; se você quer DSX tão ruim, escreva um plugin analisador e traga-o para o Dart você mesmo. A Internet vai te amar, você terá milhares de estrelas do Github e você se sentirá como se fosse React. Ganha-ganha.

Leia o tópico, isso já foi feito por @cbazza (o plugin do analisador não vai cortá-lo)

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

PS eu vou até competir com você para fazer isso

Excelente! Seria interessante ver até mesmo uma teoria de como isso funcionaria.

SGTM. Acho que estamos todos esperando por algum tipo de suporte de pré-processamento, então.

Eu prefiro a sintaxe do construtor do que passar parâmetros pelo construtor

<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 em https://fblitho.com/

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

DSX +1

Eu recebo os argumentos para o JSX, mas acho que há tantas pessoas (incluindo as próprias) que odeiam a ideia de colocar XML em uma linguagem de programação. Parece errado (mas eu entendo totalmente que os outros não se sentem da mesma maneira).

Dado que é quase impossível remover recursos uma vez implementados, sugiro o princípio da precaução. Vamos ver como alguns dos novos recursos de sintaxe do Dart 2 funcionam antes de se comprometer com uma mudança substancial na maneira como os aplicativos Flutter são criados.

@wstrange
Eu consigo te entender. Eu costumava ser contra JSX e misturar js com xml/html.... então eu tentei. Depois de alguns meses com react, me apaixonei pelo JSX. Duas vantagens matadoras são:

1. nenhuma nova sintaxe e utilitários
2. não há mais passagem de variáveis, funções etc.

@wstrange ,

Dado que é quase impossível remover recursos uma vez implementados,

Isso não é certo, quem teria pensado que o Google removeria o MathML do Chrome?

Vamos ver como alguns dos novos recursos de sintaxe do Dart 2 funcionam antes de se comprometer com uma mudança substancial na maneira como os aplicativos Flutter são criados.

Não é uma mudança na maneira como os aplicativos Flutter são construídos, é apenas uma maneira alternativa que não altera a maneira atual e, o mais importante, é simplesmente uma sintaxe diferente da biblioteca de classes. Um transpilador simples faz o mapeamento sem precisar de nenhuma informação das classes Flutter, então funciona bem para o código de qualquer pessoa, assim como para o Flutter agora e no futuro.

@Bessonov ,

Sim, você não conhece o React até passar alguns meses trabalhando com ele e então perceber o quão fenomenal é uma biblioteca para lidar com hierarquias de componentes.

@cbazza eu poderia dizer exatamente a mesma coisa sobre o Flutter. Passe algumas semanas usando-o e você não sentirá falta do JSX.

A reação nos diz tudo.

Como agora, +1 quase o dobro de -1

@escamoteur ,
Sim, uma declaração muito justa de se dizer, mas passei muito tempo com o Flutter e certamente posso ver o valor que o DSX agregaria a ele. Como @leedstyh notou, os fãs de DSX lideram a corrida por quase 2 a 1, o que é incrível, considerando que as pessoas neste fórum são pessoas do Flutter.

Eu tenho uma pergunta:

Ao usar a sintaxe DSX, assumimos implicitamente que os filhos/filhos aninhados são do tipo Widget. E se quisermos declarar explicitamente que queremos que os filhos/filhos aninhados sejam um subtipo específico de Widget?

por exemplo, quando quero que os filhos do meu widget personalizado aceitem apenas uma lista de Container, posso anotar os filhos com List<Container> e o IDE dará um erro assim que eu colocar algo diferente de Container. Como estou ciente, não há como impor o tipo seguro assim ao usar o dsx. Talvez possamos ter algum erro quando o aplicativo compilar, mas acho que o aumento de erro quando estou digitando ainda é uma experiência melhor.

Acho que devemos dar a todos algum tempo para experimentar e se familiarizar com a maneira flutter de declarar a interface do usuário, pelo menos após o lançamento da v1. Então poderíamos dar uma olhada melhor neste recurso.

@sandangel ,

Muito boa captura!!! Eu tiro meu chapéu virtual para você. Meu protótipo inicial teve alguns buracos desde o início que eu estava ciente e apenas esperando que as pessoas os encontrassem e se apresentassem. Eu só esperava que as pessoas estivessem interessadas em discutir a tecnologia em vez de brigar por ela.

A solução que tenho para isso é fornecer o tipo de array como outro parâmetro no namespace. Como o namespace está ficando grande, podemos definir o formato curto para 'filhos' como '*'.

No Exemplo 2 em https://spark-heroku-dsx.herokuapp.com/index.html , se as ações fossem uma matriz de 'Container' em vez de 'Widget' padrão, seriam as seguintes 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>

oi @cbazza , obrigado pela sua resposta.

Estou em dúvida sobre sua solução. Estamos usando mal o namespace xml conforme descrito em w3shool-XML Namespaces ?

Como afirma que o namespace é usado principalmente para resolver o conflito de nomenclatura no documento XML.

Então, quando alguém lê o XML acima, eles podem pensar que você está declarando uma tag Container sob o namespace 'children' do namespace 'actions', e não que você está impondo que todos os filhos aninhados devem ser um Container. Isso me confunde quando li pela primeira vez sua sintaxe de proposta sem ler a explicação acima.

Poderíamos ter algo melhor?

DSX não é XML, é XML-like, então não precisa seguir a semântica XML, como a linguagem de template Angular ;) De qualquer forma, estou sempre aberto a melhores alternativas ou sugestões e adoraria ter uma discussão aqui.

Vindo de React-native, eu primeiro suportei JSX como implementação, e não gostei dos objetos aninhados, mas estou começando a gostar de OOP e ver tudo como um objeto!

Para as pessoas que vêm do React-native, eu recomendo este plugin! https://marketplace.visualstudio.com/items?itemName=CoenraadS.bracket-pair-colorizer

@clarktank
Você pode expandir sua experiência com react-native (JSX), Flutter (OOP) e sua jornada de um para o outro?

@cbazza Acho que a sintaxe do modelo angular segue a semântica xml e, como sei, não há caso de uso de conflito entre a sintaxe angular e o documento xml.

Em typescript, temos suporte para componente genérico .
Então acho que poderíamos ter algo assim:

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

Mas, novamente, o componente genérico é usado para verificar o tipo de entrada da propriedade. Não sei se a sintaxe acima tem um significado semântico correto neste caso de uso.

Eu realmente sinto que a equipe do Flutter criou a API atual especificamente para a nova maneira de declarar a interface do usuário que eles supõem que é melhor que o JSX e qualquer esforço que estejamos tentando vincular a sintaxe do JSX à API atual apenas faz com que pareça pouco natural/desconfortável de usar.

A reação nos diz tudo.

Como agora, +1 quase o dobro vezes -1

Isso não significa nada.

Exceto aqueles que estão assistindo a todos os problemas do Flutter o dobro daquele que chega a esse problema porque já estão acostumados ao JSX (e estão procurando explicitamente por ele). Portanto, isso significa que _as pessoas que desejam uma experiência semelhante ao JSX dobram as pessoas que assistem a todos os problemas que votaram em -1_. (imho uma parte das pessoas que votam +1 nem sequer tentou flutter)

@sandangel ,

Acho que a sintaxe do modelo angular segue a semântica xml e, como sei, não há caso de uso de conflito entre a sintaxe angular e o documento xml.

Claro, mas o JSX não usa namespace, portanto, não é um recurso XML de interesse.

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

Já que você dividiu as 'crianças' fora de ação em sua própria tag, meio que me lembra a nova tag Fragment do React. É um equilíbrio entre verbosidade e concisão, com certeza.

Eu realmente sinto que a equipe do Flutter criou a API atual especificamente para a nova maneira de declarar a interface do usuário que eles supõem que é melhor que o JSX e qualquer esforço que estejamos tentando vincular a sintaxe do JSX à API atual apenas faz com que pareça pouco natural/desconfortável de usar.

Não há nada de novo na maneira como o Flutter declara a interface do usuário no código, talvez usar o DSX não seja natural/desconfortável para você, mas para os desenvolvedores de JSX não é. JSX/DSX é perfeito para Flutter, ele se encaixa como uma luva e se você não gosta de luvas vá descalço ;)

@a14n ,

Isso não significa nada.

com certeza sim!!! você pode argumentar com 'sentimento', 'pensamento', 'suspeito', 'imho', 'opinião', mas isso são dados, um dado concreto. Se os dados são inúteis, não devem ser coletados. Eu acho que os dados são inúteis porque não pintam sua imagem.

@cbazza Quero dizer, quando estamos tentando responder à pergunta que tenho acima sobre a aplicação de subtipo de widget para filho/filhos, sinto que o código Dart está fazendo um trabalho melhor que o JSX.

DSX não é XML, é semelhante a XML, então não precisa seguir a semântica XML

Claro, mas o JSX não usa namespace, portanto, não é um recurso XML de interesse.

Não tenho certeza, mas li alguns de seus comentários acima e acho que você mencionou o nó JSX/XML de forma intercambiável. De qualquer forma, pessoalmente, acho que usar namespace como solução não é o ideal.

Basta comparar

<actions:children:Container>

</actions:children:Container>

e

actions: <Container>[]

sintaxe.

@sandangel ,

Sim, a sintaxe de marcação é mais detalhada para este caso e é por isso que mencionei a forma abreviada para crianças sendo '*'. De qualquer forma, este caso é a exceção e não a regra. Na maioria das vezes você nem precisa especificar 'filhos', muito menos 'Contêiner'; mas a funcionalidade precisa estar lá para cobrir todos os casos de uso possíveis.

@a14n voto é voto, com certeza significa.

Respeito seu sentimento, talvez seja verdade. Mas mesmo com uma proporção inversa (1 para 2), isso ainda significa 33% de base de usuários. Você pode dizer que 33% é uma pequena parte?

pessoas que desejam uma experiência semelhante ao JSX

Sim, algumas pessoas estão assistindo. Isso também significa que _a falta de JSX-like é uma das razões que impedem as pessoas de escolher o flutter_.

O Flutter visa mais desenvolvedores, não apenas aqueles que lêem todos os problemas.

@jstansbe
Sou um programador autodidata e, como a maioria dos autodidatas, comecei com Javascript.
Então comecei a aprender React e React-Native. Acho que nos últimos anos, especialmente depois do ES6, o estilo OOP foi adicionado ao Javascript.

Então, pessoas como eu não estão acostumadas com o estilo de programação OOP. Mesmo que o React native Component sejam classes como Widgets no Flutter.

JSX meio que esconde a imagem OOP pura. Basicamente, ele esconde o que acontece sob o capô. Nota: React foi projetado para desenvolvedores web, e desenvolvedores web estão acostumados com sintaxe html. É por isso que o JSX é tão popular entre os desenvolvedores web.

Pessoalmente, acho que OOP puro faz mais sentido para grandes projetos.

@clarktank ,

Ao discutir linguagens de computador, você deve estar ciente de:
(1) Sintaxe - os caracteres e palavras que compõem o idioma
(2) Semântica - o significado desses caracteres e palavras

Por exemplo, chamadas de função em muitas linguagens se parecem com o seguinte (ou seja, têm a seguinte sintaxe):

a = someFunction(param1, param2)

Imagine agora que outra linguagem decida usar colchetes em vez de colchetes para chamadas de função; ficaria assim:

a = someFunction[param1, param2]

A coisa aqui é que a sintaxe é diferente, mas a semântica é a mesma. Quero dizer, ambos estão basicamente fazendo chamadas de função, mas com uma sintaxe diferente.

JSX meio que esconde a imagem OOP pura. Basicamente, ele esconde o que acontece sob o capô.

Não é verdade. JSX/DSX é apenas uma sintaxe diferente para exatamente a mesma coisa (a semântica é a mesma). No caso do JSX, as tags XML apenas criam React Components (assim como você pode fazer em Pure Javascript). No caso do DSX, as tags XML apenas criam Flutter Widgets (assim como você pode fazer no Pure Dart). A sintaxe é diferente, mas gera exatamente a mesma coisa, por isso é idêntica sob o capô.

Nota: React foi projetado para desenvolvedores web, e desenvolvedores web estão acostumados com sintaxe html. É por isso que o JSX é tão popular entre os desenvolvedores web.

JSX é popular porque é uma ótima maneira de gerenciar hierarquias de árvore de componentes, seja para web, mobile ou qualquer desenvolvimento de UI. Observe no código abaixo que você não sabe se o componente suspenso é para web ou mobile, por exemplo.

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);

Pessoalmente, acho que OOP puro faz mais sentido para grandes projetos.

Como é isso? (considerando que usar JSX/DSX ou Pure Javascript/Dart gera exatamente a mesma coisa sob o capô).

@cbazza

Eu usei react-native por quase um ano e não tinha ideia de que elementos JSX são objetos que estão sendo instanciados, até que comecei com Flutter/Dart. Da minha perspectiva, ele esconde a imagem OOP, embora, como você disse, semanticamente faça a mesma coisa sob o capô!

Em aplicativos grandes, o JSX também pode ficar tão feio quanto objetos fortemente aninhados. Então sintaticamente, eu preferiria permanecer consistente do que introduzir outro estilo que poderia ser tão confuso.

@clarktank ,

Em aplicativos grandes, o JSX também pode ficar tão feio quanto objetos fortemente aninhados. Então sintaticamente, eu preferiria permanecer consistente do que introduzir outro estilo que poderia ser tão confuso.

Para mim, ter uma aparência diferente do resto do código é realmente um benefício.

(Peço desculpas antecipadamente pela parede de texto.)

Como alguém que não usou React-Native ou Flutter por tempo suficiente para me considerar uma fonte definitiva, se Dart bruto ou JSX/DSX é "melhor", este tópico tem sido bastante fascinante de ler. Há algumas coisas que eu gostaria de colocar meus $ 0,02 para baixo.

Para começar, concordo com várias pessoas sobre a natureza do que o JSX realmente é e como ele beneficia os desenvolvedores. Em primeiro lugar, JSX foi projetado como uma forma de "HTML dinâmico" que pode ser embutido no código Javascript existente. É indispensável para plataformas web baseadas em JS, como React, pois permite que desenvolvedores web interajam de forma limpa e eficiente com o DOM sem ter que lutar com o modo nativo horrível (ou o jeito um pouco melhor do jQuery). Além disso, por sua própria natureza, o JSX incentiva o desenvolvimento de UI que pode ser facilmente desacoplado dos dados subjacentes, promovendo uma estrutura de projeto bem organizada. Nesse ambiente, o JSX é uma ferramenta para possibilitar maior produtividade, e acho que seria praticamente impossível contestar isso.

Como esse parágrafo se relaciona com o React-Native é que, mesmo sendo uma plataforma de desenvolvimento móvel, ele é descendente direto do React. Como tal, quase toda a sintaxe e paradigmas ainda foram originalmente criados com o desenvolvimento web em mente. Isso é por design - todo o truque do RN é que você pode "criar aplicativos móveis multiplataforma usando o React", então é _suposto_ que parece desenvolvimento web ao usá-lo. Os aplicativos RN também são predominantemente escritos em Javascript, portanto, a inclusão do JSX é natural. JSX ajuda o desenvolvimento RN por quase todas as mesmas razões que ajuda no desenvolvimento web. (Eu realmente acho que esta é uma grande razão pela qual, pelo menos no RN, a abordagem JSX é usada com muito mais frequência do que a abordagem nativa. para se tornar predominante.)

O Flutter, por outro lado, não tem essa filosofia de design. Ele se destina a ser uma solução multiplataforma puramente nativa e, embora afirme que foi inspirado pelo React-Native, ele escreve muito mais como um aplicativo móvel ou desktop nativo do que um aplicativo da web. Ele também roda usando Dart e não Javascript, que do ponto de vista de integrar algo como JSX é uma consideração importante. Por um lado, enquanto as funções JS DOM podem ser horrivelmente detalhadas (tanto por causa do design da função quanto da própria linguagem JS), o Dart como linguagem é muito mais facilitador do código declarativo de interface do usuário limpo, enquanto o Flutter na maioria das vezes faz um bom trabalho de mantendo os construtores de interface do usuário concisos. Para outro ( como @sandangel apontou ) Dart é uma linguagem de tipagem estática, então a natureza do JSX sendo projetado para uma linguagem de tipagem dinâmica como JS vai se deparar com problemas nos casos em que, por exemplo, um construtor de interface do usuário requer um Widget de um tipo específico, a única solução à qual apenas aumenta a verbosidade. Pessoalmente, parece uma solução que, com o tempo, inevitavelmente resultará em uma DSL que ficou inchada e difícil de manter, pois precisa dar conta de um número crescente de casos de uso inerentes a um sistema que não deveria ser usado para.

Como tal, eu realmente não vejo como o JSX/DSX beneficiaria a produtividade do desenvolvimento do Flutter além de ser apenas uma questão de preferência pessoal. Ambas as sintaxes em geral são aproximadamente equivalentes em verbosidade, e onde se perde verbosidade em instâncias específicas, compensa em clareza (as tags XML de fechamento, por exemplo). Em grande parte, se alguém está vindo para o Flutter a partir de um plano de fundo orientado para a web (React/RN, Angular, etc.) abordagem que prefeririam. Mesmo neste tópico sozinho, há muitas histórias de usuários que dizem que eram extremamente céticos em relação ao JSX no início, mas depois de usá-lo por alguns meses, mudaram de opinião para "não posso prescindir". (Embora a parte cínica de mim queira salientar que a mesma coisa poderia muito bem acontecer com eles para a abordagem nativa do Dart se eles dessem uma chance.)

Dito tudo isso, não consigo me ver concordando que o DSX deve se tornar oficialmente suportado pela equipe Flutter como uma alternativa aos construtores de interface do usuário nativos. Embora seja perfeitamente adequado como uma solução de terceiros (e todos os adereços para @cbazza para realmente implementá-lo), ele realmente não se encaixa na natureza central do Flutter como uma plataforma não baseada em tecnologia da Web. Como tal, mais poder para quem quiser usar o DSX em seus próprios projetos, mas eu ficaria do lado da mentalidade de que há muitas outras coisas mais importantes que a equipe do Flutter poderia e deveria gastar seu tempo.

Agora, com isso dito, embora eu realmente não concorde com o DSX sendo oficialmente suportado, acho que deveria haver um formato oficial de interface do usuário do tipo _some_. Como @birkir apontou , quase todas as principais plataformas nativas de interface do usuário, seja desktop ou móvel, têm um formato de interface do usuário além da abordagem baseada em código direto (e a maioria delas é pré-processada na abordagem baseada em código de qualquer maneira). Ter arquivos de interface do usuário separados de arquivos lógicos sempre foi a maneira recomendada de adotar o padrão MVVM (o que, aliás, é uma coisa que sempre me incomodou em relação ao JSX). O que eu argumentaria, portanto, é que o Flutter tem algo semelhante - em vez de um formato DSL de interface do usuário em linha, ele deve ter um formato de interface do usuário separado destinado a entrar em seu próprio arquivo longe do código Dart.

Como parte dessa linha de pensamento, eu realmente fiz algum trabalho no fim de semana passado nesse sentido. Se eu pudesse me dar um shill por um momento, desenvolvi um projeto que chamei de "FLUI" que é minha tentativa de mostrar como esse formato pode ser . Em vez de usar uma DSL existente (ou uma versão modificada), desenvolvi uma totalmente nova que se inspira no YAML e tentei o meu melhor para manter a "sensação" do layout da abordagem do construtor Flutter. Concedido, é uma implementação _muito_ inicial, então eu realmente não espero que não tenha uma enorme quantidade de problemas, mas incluí a fonte para o script do processador (escrito em C#/.NET Standard) para que as pessoas possam jogar com ele se quiserem. :)

Como usuário de React/RN e Flutter, discordo fortemente da ideia de "DSX".

DSX não traria nada . JSX é usado em react porque a sintaxe JS é horrível. Mas no caso do Flutter, a criação de widgets é super fácil.

O clássico:

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

já está pronto para ser lido, fácil de escrever, compatível com tipos/genéricos e sem qualquer duplicação desnecessária.

A única reclamação que você pode ter com a sintaxe atual é "É difícil saber onde está o parêntese de fechamento de um widget"

Mas, novamente, o plug-in dart dos IDEs oficialmente suportados resolve esse problema. Então, quando abrirmos o código de antes, digamos vscode, veremos

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

Quanto ao "É difícil diferenciar o código casual do código da interface do usuário", as regras de reação também se aplicam ao flutter :

Os widgets devem ser burros ou inteligentes. O widget inteligente não tem lógica de interface do usuário. Widgets idiotas não têm nada além de lógica de interface do usuário.

Se você seguir esse padrão, nunca deverá cair em uma situação em que não consiga diferenciar a interface do usuário do resto.
Isso é ainda mais verdadeiro ao seguir algo como o padrão BLoC; que impõem fortemente a separação de negócios e UI.

JSX é usado em reagir porque a sintaxe JS é horrível

Muito opinativo declaração e simplesmente não é verdade.

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>
  );
}

Muito opinativo declaração e simplesmente não é verdade.

Há muitos caracteres desnecessários na sintaxe padrão de reação.
Vamos comparar repetição de palavras e contagem de caracteres para cada sintaxe (excluindo definição de função, recuo e 'retorno')

Reagir sem JSX:

• 133 caracteres, incluindo 3 parênteses, 3 colchetes, 3 : , 4 , e 11 espaços
• React.createElement escrito duas vezes

JSX:

• 104 caracteres, com 2 parênteses, 3 colchetes, 1 : , 4 <> e 5 espaços
• Container e Text escritos duas vezes

Dardo:

• 99 caracteres, com 2 parênteses, 4 : , 3 , e 4 espaços
• Sem repetição

Em termos de caracteres, o vencedor óbvio aqui é a sintaxe de dardo.

Agora também temos que levar em consideração outras especificidades do dardo.

Tipos Dart single child vs multi-child, tem construtores const e permite genéricos e até mesmo parâmetros posicionados. JSX não suporta nada disso.

Alguns exemplos que seriam mal convertidos para JSX:

Nem sempre children :

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

OR

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

const construtor no próprio widget

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

genéricos

NotificationListener<ScrollNotification>(
  onNotification: (foo) {

  },
  child: child,
)

adereços posicionados:

Text("foo")

Construtor nomeado

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

construtores (o dart não suporta o tipo de união, então children não pode ser um widget e uma função)

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

@rrousselGit

Como mencionado várias vezes antes do DSX é simplesmente um
sintaxe e é um superconjunto do Dart, então tudo o que você pode fazer com
Dart você pode fazer isso dentro do DSX. Você também pode misturar e combinar os dois
sintaxes como achar melhor. Obviamente você nem se deu ao trabalho de verificar
quais são alguns dos recursos do DSX que foram feitos para oferecer suporte
Dardo:
https://spark-heroku-dsx.herokuapp.com/index.html

-1---------------------------------------
Em Dardo:

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

OR

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

Em DSX:

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

OR

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

-2---------------------------------------
Em Dardo:

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

Em DSX:

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

-3---------------------------------------
Em Dardo:

NotificationListener<ScrollNotification>(
  onNotification: (foo) {

  },
  child: child,
)

Em DSX:

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

  }}
  child={child}
/>

-4---------------------------------------
Em Dardo:

Text("foo")

Em DSX:

<Text ["foo"]/>

-5 ---------------------------------------
Em Dardo:

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

Em DSX:

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

-6---------------------------------------
Em Dardo:

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

Em DSX:

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

Mas então o argumento de ter uma conversão mais fácil de react para flutter é inválido. Como JSX é radicalmente diferente do seu protótipo:

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

E nenhum dos seus exemplos aqui ou do seu link realmente simplifica o código ou melhora a legibilidade

Tanto quanto eu posso relacionar com o seu sentimento de falta do JSX (tenho o mesmo ao iniciar o flutter), depois de alguma experiência, a sintaxe nativa parece muito boa na verdade

Como observação lateral, há uma solução muito melhor para sua separação de preocupações. Esse é um arquivo de modelo
Você pode ter um arquivo xml/yaml próximo ao seu widget. E, em seguida, use a incrível ferramenta de geração de código que o dart fornece.

Eu prefiro um:

// 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 com um

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

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

que, em seguida, usando uma geração de código personalizada, gera o seguinte arquivo dart:

part of 'main.dart';

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

O resultado final é ainda melhor do que um "DSX" para separação de UI/lógica. É melhor para potenciais geradores de interface do usuário também. E é muito mais fácil de implementar usando built .

Como JSX é radicalmente diferente do seu protótipo:

Mesmo !!! A única coisa radical nessas discussões foi a reação dos opositores.

Como está declarado no título deste ticket, o DSX é semelhante ao JSX, não é idêntico ao JSX ou então teria sido chamado de JSX; e as adições a ele são pequenas e fornecem opções aos desenvolvedores.

Você poderia escrever assim:

<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, você parece estar confundindo 'separação de interesses' com 'separação de tecnologia'. Essas coisas são muito diferentes; você separando código de dardo e código de marcação em arquivos diferentes, é simplesmente 'separação de tecnologia' e não oferece nenhum dos benefícios de 'separação de interesses'. Uma preocupação aqui seria um componente/widget que encapsulasse código reutilizável de forma limpa, não importa que dentro desse componente/widget ele esteja usando tecnologias diferentes.

Além disso, separar tecnologias como você recomenda é muito inferior ao JSX/DSX, que usa a linguagem host para todas as suas construções imperativas (for loops, chamadas de função, instruções if, etc).

Depois de muito código e exemplos postados aqui ( especialmente ), chego à conclusão, que JSX agrega muito mais valor ao JS em contraste com DSX e Dart. Mas uma característica é muito importante do meu ponto de vista: Tags de fechamento. Como:

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

reduz MUITA complexidade cognitiva em estruturas profundas como aqui , em contraste com:

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

Mas bem, se você usar assim:

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

há um pequeno lucro.

Como está declarado no título deste ticket, o DSX é semelhante ao JSX, não é idêntico ao JSX

Você perdeu o meu "Mas então o argumento de ter uma conversão mais fácil de reação para vibração é inválido."

Metade dos argumentos para o DSX é "JSX é popular em reagir, precisamos disso aqui também". Mas você está propondo algo diferente (e mais complexo) do JSX.
A outra metade é separar a interface do usuário do código; que um arquivo de modelo também pode fazer.

Além disso, separar tecnologias como você recomenda é muito inferior ao JSX/DSX, que usa a linguagem host para todas as suas construções imperativas (for loops, chamadas de função, instruções if, etc).

Não é verdade. Você poderia fazer if e outras coisas dentro do seu arquivo de modelo. Veja cshtml ou modelos angulares.

A coisa é um arquivo de modelo, desde que você já tenha um analisador para ele, pode ser implementado para flutter em menos de uma semana funcionando totalmente.
Seja yaml, xml, cshtml ou html com diretivas.

Enquanto um DSX exigiria muito trabalho.

@Bessonov Recentemente, eles adicionaram comentários virtuais em IDEs suportados para simular a tag de fechamento.

Então, no seu vscode, você verá o seguinte:

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

Os benefícios de fechar tags. Sem precisar digitá-los

@rrousselGit

Recentemente, eles adicionaram comentários virtuais em IDEs compatíveis para simular a tag de fechamento.

Sim, eu vi isso no comentário citado. Mas não é o mesmo. Isso introduz uma mudança de alinhamento e perturba o fluxo de leitura. E isso não me ajuda em outros IDEs e processadores de texto.

A coisa é um arquivo de modelo

Os modelos IMHO sofrem da síndrome do NIH. Não digo que a abordagem de misturar PHP e HTML seja a maneira correta de fazer isso. Mas reagir mostra com JSX como isso pode ser feito melhor.

@rrousselGit

Você perdeu o meu "Mas então o argumento de ter uma conversão mais fácil de reação para vibração é inválido."

Não, eu não perdi o comentário, simplesmente não faz sentido você me dizer que as pessoas que vêm do JSX acharão o DSX muito complexo.

Metade dos argumentos para o DSX...

Existem muitas razões para escolher o DSX, mas com alternativas as pessoas escolherão o que preferem por qualquer motivo que tenham.

Não é verdade. Você poderia fazer if e coisas dentro do seu arquivo de modelo. Olhe para cshtml ou modelos angulares.

A coisa é um arquivo de modelo, desde que você já tenha um analisador para ele, pode ser implementado para flutter em menos de uma semana funcionando totalmente.
Seja yaml, xml, cshtml ou html com diretivas.

Enquanto um DSX exigiria muito trabalho.

Totalmente ao contrário, o DSX implementa apenas 2 transformações xml e ganha todo o resto gratuitamente da linguagem de hospedagem. Imagine o esforço de tentar reimplementar o poder do Dart em sua nova linguagem de modelagem. Não, obrigado, vou levar o Dart.

Não, eu não perdi o comentário, simplesmente não faz sentido você me dizer que as pessoas que vêm do JSX acharão o DSX muito complexo.

A mesma coisa se aplica à implementação de dardo atual.

De qualquer forma, acho que não podemos nos convencer aqui. Então, vou listar mais algumas razões pelas quais não gosto de JSX em vibração e depois "esperar e ver".

1. A criação do widget é diferente do React

No react, é a biblioteca que lida com a criação de componentes. JSX é bom porque diz "Não se preocupe com como as coisas funcionam. Nós fazemos as coisas para você".

Na vibração não é assim. Instanciamos manualmente um novo widget a cada chamada de compilação. Isso é realmente importante de entender, e o JSX tornaria isso menos claro.

E, na continuação dessa lógica:

2. As pessoas podem pensar que <Foo /> faz algo especial que new Foo() não

<Foo /> em um método parece especial. Parece que faz algo estranho embutido no framework. O que é verdade em react, onde os componentes são agrupados em um React.Element .
Isso se traduz em reagir em <Foo /> != new Foo() e não tem acesso direto a Foo .

Isso não se aplica à vibração e pode causar confusão.

Além disso :

<Foo>
  <Bar />
</Foo>

Em react, se Foo nunca usa seu filho, então Bar nunca é instanciado. E Foo é instanciado após o retorno do método render .
Enquanto em vibração é o oposto. Ambos Bar e Foo são criados imediatamente

Isso potencialmente levaria os desenvolvedores do React a criar códigos de vibração não otimizados.

3. Em geral, Dart/flutter não é JS/react

Se adicionarmos JSX no dart, já consigo ver os problemas sobre o tipo union ou poder fazer
return foo && <Component /> ou a próxima renderização assíncrona em react.
Justificado com um "já temos JSX para que possamos ter isso também!"

Eu preferiria uma sintaxe proprietária ou nenhuma sintaxe, para não precisar implementar o recurso JSX/react mais recente no dart

4. O JSX torna alguns dados específicos de dardos pouco claros

Um pequeno exemplo, Scaffold requer appbar a PrefferedSizeWidget .
Se criássemos Scaffold usando JSX, as pessoas esperariam que você pudesse substituir qualquer JSX por outro. O que não é verdade

Quero dizer, deixa muito claro por que podemos fazer

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

mas não

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

@rrousselGit

De qualquer forma, acho que não podemos nos convencer aqui. Então, vou listar mais algumas razões pelas quais não gosto de JSX em vibração e depois "esperar e ver".

Discordo de muito do que você disse, mas agradeço seu esforço, pois você está dedicando um tempo para pensar profundamente sobre o assunto.

1. A criação do widget é diferente do React

Para mim isso não importa porque isso é apenas um detalhe de implementação, conceitualmente uma vez que você vê algum XML, em React é um Component, em Flutter é um Widget.

1. Os povos podem pensar faz algo especial que new Foo() não faz

Acho que as pessoas vão aprender rapidamente que Dart/DSX não é Javascript/JSX.

1. Em geral, Dart/flutter não é JS/react

Sim, finalmente concordamos em algo, mas mesmo que sejam diferentes, o ponto comum é que são estruturas de interface do usuário declarativas e acho que as estruturas de árvore declarativas são bem tratadas com JSX/DSX. Ele mantém você no modo de pensar da programação declarativa.

Se adicionarmos JSX no dart, já posso ver os problemas sobre a união de tipos ou poder fazer return foo && <Component /> ou a próxima renderização assíncrona em reagir.
Justificado com um "já temos JSX para que possamos ter isso também!"

Não estamos adicionando JSX no Dart, estamos adicionando DSX, é diferente, mas tem semelhanças com o JSX e a familiaridade é uma coisa enorme.

Eu preferiria uma sintaxe proprietária ou nenhuma sintaxe, para não precisar implementar o recurso JSX/react mais recente no dart.

Então, com esse raciocínio, por que você está usando o Dart? parece bastante semelhante ao Java e ainda é diferente do Java; dane-se, vamos descartar todas essas palavras-chave e conceitos Java e chegar a algo vagamente semelhante a Erland que você só pode programar com uma mão enquanto faz um movimento de ioga pretzel no topo do Monte Everest;)

1. JSX deixa alguns detalhes de dardo pouco claros

Não realmente, se você conectar Widgets incomparáveis, o compilador Dart emitirá mensagens de erro como se você fizesse isso no Dart simples. Não posso enfatizar o suficiente que o DSX é simplesmente um açúcar sintático fino, não há mágica, apenas uma sintaxe de diferença para a mesma coisa.

@cbazza Passei horas lendo suas postagens e realmente aprecio seu esforço nessa questão. Mas acho que é (meio que) fácil encerrar a discussão. Lembre-se que o flux era a solução oficial de gerenciamento de estado para reagir, mas agora todo mundo está usando redux? E quantas bibliotecas de navegação existem para react-native? Basta fazer um repositório DSX e deixar os desenvolvedores reagirem.

@rrousselGit

Eu nunca vi a sintaxe part / part of no Dart antes e estou tendo problemas para encontrar qualquer documentação para isso. É algo que o Dart/Flutter suporta oficialmente? Eu adoraria usar algo assim no FLUI.

@cbazza

Você continua andando em círculos com a justificativa DSX. DSX não é JSX. O DSX é semelhante ao JSX. O DSX deve ser uma sintaxe familiar para desenvolvedores React. DSX é apenas pensar em açúcar sintático para Dart. As pessoas vão aprender que DSX não é JSX. (E assim por diante.)

Enquanto eu entendo o ponto que você está tentando fazer com todas essas explicações, acho que o fato de você ter que continuar fazendo revela uma questão importante sobre a natureza do DSX em geral, e é um ponto que o rrouselGit trouxe à tona também. Mesmo que você continue dizendo que o DSX é _não_ JSX, as pessoas que o encontrarem vão pensar que é, e isso é um problema. JSX, e as pessoas que o usam, vêm de um ecossistema que é tão conceitualmente diferente em níveis fundamentais do Dart/Flutter. Como tal, desenvolver um recurso para "familiaridade" não é necessariamente uma coisa boa. Uma das razões mais aparentes para isso é, como foi apontado, as pessoas vão tentar algo assim:

Widget build(BuildContext context) {
    return isDialogVisible && <Widget>...</Widget>;
}

Como eles vêm de Javascript/JSX, eles esperam que essa sintaxe funcione no DSX. Quando isso não acontece, torna-se um ponto de dissonância cognitiva que pode realmente _ferir_ seu interesse não apenas no DSX, mas no Flutter como um todo. A familiaridade é benéfica quando é usada como um meio de facilitar as pessoas em algo novo, mas isso pode ser uma faca de dois gumes - quando 90% dos recursos são os mesmos, os 10% restantes podem servir apenas para frustrar e irritar.

Outro problema com o DSX é que provavelmente não será um recurso perfeitamente integrado tão cedo, independentemente de ser um plug-in de terceiros ou se for adotado oficialmente pelo Flutter. Como você mesmo disse, para que ele realmente funcione com o processo de depuração e implantação do Flutter, ele precisa de suporte oficial não apenas da equipe Flutter, mas também da equipe Dart. Caso contrário, sem suporte a pré-processamento e ferramentas, a única maneira de o DSX funcionar é com ferramentas externas de conversão manual, que é apenas mais uma etapa (potencialmente longa) pela qual os desenvolvedores terão que passar.

Ao digitar isso, há outra coisa que me ocorreu. Houve várias pessoas pró-JSX neste tópico que elogiaram o JSX, dizendo que a abordagem de "separação de interesses" para o design de interface do usuário é realmente a única maneira de considerar o desenvolvimento de interfaces de usuário novamente. Se for esse o caso, por que o React é o único framework com presença no mercado que o está usando? As estruturas de aplicativos móveis nativas e de plataforma cruzada ficaram com seus storyboards, seus arquivos XML, seus arquivos XAML e outros DSTs de definição de interface do usuário. Mesmo outros frameworks JS populares como Angular e o promissor Vue ainda fazem a abordagem de "separação de tecnologias". Os desenvolvedores do React falam como se o JSX fosse o caminho do futuro, mas ainda não o vi aparecer em nenhum outro lugar além do React em um framework que tenha obtido alguma tração real.

@andrewackerman

part / part of é um recurso de dardo existente. De alguma forma, une dois arquivos em um. Geralmente usado para geração de código.

Existem alguns cenários de casos reais que utilizam tal técnica. Como json_serializable que gera um método toJSON e uma fábrica fromJSON para classes baseadas em suas propriedades.

part / part of realmente não faz nada por conta própria. A parte interessante é quando você combina com algo como source_gen .

@sunnylqm

Eu não acho que colocar código em um repositório resolveria meu problema porque o problema atual é sobre a integração adequada do DSX com as ferramentas Flutter para fornecer uma ótima experiência de desenvolvedor com depurador, preenchimento automático, etc. trabalhando em arquivo .dsx.

Dizer aos usuários que eles podem usar o DSX, mas não podem usar o depurador ou aproveitar o preenchimento automático, não é um começo para mim. Se alguém quiser ajudar, o que eu preciso é descobrir uma maneira de adicionar suporte completo ao pré-processamento (com mapa de origem) para Dart Tools e VS Code Dart plug-in. é um superconjunto do Dart, mas compila tudo para o Dart) funcionaria.

@andrewackerman

Não preciso justificar nada, estou muito confiante de que o DSX será um sucesso e há quase 100 pessoas interessadas nele só neste bilhete.

Caso contrário, sem suporte a pré-processamento e ferramentas, a única maneira de o DSX funcionar é com ferramentas externas de conversão manual, que é apenas mais uma etapa (potencialmente longa) pela qual os desenvolvedores terão que passar.

O transpilador DSX é incrivelmente rápido e pode transformar arquivos .dsx em arquivos .dart mais rápido do que você pode piscar, então a velocidade não é um problema; apenas tentando obter paridade de recursos para torná-lo um acéfalo para as pessoas usarem o DSX.

Se for esse o caso, por que o React é o único framework com presença no mercado que o está usando? As estruturas de aplicativos móveis nativas e de plataforma cruzada ficaram com seus storyboards, seus arquivos XML, seus arquivos XAML e outros DSTs de definição de interface do usuário.

Basta fazer uma linha do tempo e você verá a evolução do desenvolvimento da interface do usuário. O desenvolvimento para Android e iOS por meio de suas formas atuais começou há mais de 10 anos, portanto, usa técnicas de 10 anos (técnicas totalmente imperativas). As técnicas de desenvolvimento de UI Reativas (declarativas) começaram a aparecer para a web há cerca de 8 anos. O React surgiu há 5 anos e foi o primeiro framework Reactive a combinar tecnologias perfeitamente com JSX. Vue é agora o framework Reactive mais recente que suporta as técnicas mais antigas de 'separação de tecnologias', mas também suporta JSX. Em dispositivos móveis, o Flutter é o mais recente e usa técnicas de estrutura reativa como React e pode aproveitar o DSX, assim como o Vue aproveita o JSX. O Vue está matando o Angular porque está fornecendo opções aos desenvolvedores e não sendo excessivamente opinativo.

O problema com arquivos de modelo separados é que as construções de programação imperativas (if, for loop, etc) são muito fracas em comparação com o que está disponível na linguagem de programação usada para a lógica de negócios. Combinar os 2 da maneira que o JSX faz, para mim, é claramente o futuro.

Os desenvolvedores do React falam como se JSX fosse o caminho do futuro,

Isto é !!!

mas ainda não vi isso aparecer em qualquer lugar que não seja no React em uma estrutura que tenha obtido alguma tração real.

Vue usa JSX

@cbazza

Não preciso justificar nada, estou muito confiante de que o DSX será um sucesso e há quase 100 pessoas interessadas nele só neste bilhete.

Não estou dizendo que você precisa justificar nada. Quando você estava insistindo que a equipe do Flutter pegasse essa proposta e a implementasse, sim, eu diria que você tinha uma boa quantidade de justificativas para justificar. Agora que você está tentando fazer isso sozinho, você pode fazer o que quiser para qualquer justificativa que você achar que seja suficiente, e mais poder para você. Estou apenas expondo as razões pelas quais vejo que pode não ser tão fácil ou tão popular quanto você pensa que será, e estou colocando a bola em seu campo para desafiá-los.

O transpilador DSX é incrivelmente rápido e pode transformar arquivos .dsx em arquivos .dart mais rápido do que você pode piscar, então a velocidade não é um problema; apenas tentando obter paridade de recursos para torná-lo um acéfalo para as pessoas usarem o DSX.

Presumo que, neste ponto, você já o testou em UIs e aplicativos que são triviais em tamanho. E os não triviais? E aqueles que se enquadram em casos extremos? Além disso, o tempo real que o processo leva não é a única parte relevante - apenas o fato de o desenvolvedor ter que passar por outra lista de verificação de ações manuais antes de poder construir é bastante desanimador para muitas pessoas.

Você também ainda precisa liberar o código-fonte do projeto, então ninguém foi capaz de passar pelo seu processo, verificar suas descobertas e sugerir melhorias. Neste ponto, tudo o que qualquer um pode realmente fazer é acreditar na sua palavra de que é conveniente e eficaz.

Vue usa JSX

Estou usando o Vue há quase um ano, e nesse tempo passei por um bom número de repositórios de projetos de código aberto para ver como as coisas são feitas. Embora eu não me considere um mestre do Vue de forma alguma, o que vou dizer é que em nenhum deles eu já vi o JSX realmente utilizado - as pessoas parecem preferir massivamente a abordagem .vue (modelo -script-styling) sobre a abordagem render+JSX. Eu nem sabia que o Vue suportava JSX (pelo menos através de um plugin babel) até que depois de sua resposta eu fiz algumas pesquisas na documentação do Vue e descobri um pequeno trecho de informações sobre ele na seção da função de renderização .

Mas isso é irrelevante para o meu ponto geral. Vue ainda é um framework Javascript. Flutter certamente não é. Como tal, há muitas razões que tornam o JSX a melhor coisa em um ambiente centrado em Javascript que não será traduzido para Dart+Flutter, muitos dos quais já foram abordados neste tópico.

Isto é !!!

Até que eu veja isso pegar em um ambiente de desenvolvimento não-Javascript, vou discordar respeitosamente.

Vue usa JSX

O Vue spec tem uma ampla variedade de usos. JSX está apenas "lá". Mas não é a sintaxe dominante
Você pode conectar o JSX ao Angular se quiser. Embora ninguém faça

Os desenvolvedores do React falam como se JSX fosse o caminho do futuro,
Isto é !!!

Um grande candidato para o futuro são os componentes da web. E eles são usados ​​diretamente em html semelhante ao que você encontraria em Angular ou a forma mais comum de Vue

@andrewackerman

apenas o fato de que o desenvolvedor tem que passar por outra lista de verificação de ações manuais antes que eles possam construir é bastante desanimador para muitas pessoas.

Quem falou em ações manuais? Não deixei claro que estou tentando obter uma integração IDE completa e perfeita (a melhor experiência de usuário possível para desenvolvedores).

Você também ainda precisa liberar o código-fonte do projeto, então ninguém foi capaz de passar pelo seu processo, verificar suas descobertas e sugerir melhorias.

Como isso tem a ver com as pessoas que usam o DSX? Eu usei JSX por mais de 2 anos e não poderia me importar menos com seu código-fonte. Você precisa olhar o código-fonte do compilador Dart para poder programar no Dart?

o que vou dizer é que em nenhum deles eu já vi o JSX realmente utilizado - as pessoas parecem preferir massivamente a abordagem .vue (estilo de script de modelo) sobre a abordagem render+JSX.

JSX é uma nova adição, então levará tempo para se espalhar, mas o ponto importante é que o Vue aceita outras abordagens sem forçar os desenvolvedores a usar 'a maneira correta e a única maneira' que as coisas devem ser feitas no Vue.

Vue ainda é um framework Javascript. Flutter certamente não é.

Riiiiight, então em vez de JSX você usa DSX com Flutter.

@rrousselGit

Um grande candidato para o futuro são os componentes da web.

Componentes da Web são zoobies, mortos, mas ainda andando; eles são tão difundidos quanto os cangurus no Canadá. Eu poderia continuar por dias, mas para evitar divagar...
https://dmitriid.com/blog/2017/03/the-broken-promise-of-web-components/

@cbazza

Quem falou em ações manuais? Não deixei claro que estou tentando obter uma integração IDE completa e perfeita (a melhor experiência de usuário possível para desenvolvedores).

Você também disse que precisava de suporte de pré-processamento da equipe Flutter/Dart para fazer isso. Estou errado nisso?

Como isso tem a ver com as pessoas que usam o DSX? Eu usei JSX por mais de 2 anos e não poderia me importar menos com seu código-fonte.

JSX foi desenvolvido pelo Facebook para React, submetido a um rigoroso processo de proposta/design/implementação/iteração, e então lançado no mundo anos antes de você colocar as mãos nele. Foi rigorosamente testado e comprovado várias vezes em ambientes do mundo real. É uma tecnologia madura. Não há razão para exigir ver uma folha de especificações para algo assim.

O DSX, por outro lado, está sendo desenvolvido hoje por você e um punhado de pessoas. Você falou eloquentemente sobre o que ele pode e será capaz de fazer, mas tudo o que realmente _vimos_ é um pequeno punhado de trechos de código construídos especificamente e sua palavra de que eles foram gerados pelo transpilador. As pessoas que querem experimentá-lo e sugerir possíveis mudanças ou melhorias não podem fazê-lo, então não têm motivos para apoiar seus esforços além de "Yay JSX!".

Não estou acusando você de mentir nem nada, só estou dizendo que o JSX ganhou um nível de fé que o DSX não tem, então como você vai virar a cabeça se não deixar as pessoas mexerem nele?

JSX é uma nova adição, então levará tempo para se espalhar, mas o ponto importante é que o Vue aceita outras abordagens sem forçar os desenvolvedores a usar 'a maneira correta e a única maneira' que as coisas devem ser feitas no Vue.

JSX está no Vue há quase 2 anos. E ao contrário do próprio Vue, o JSX é uma tecnologia pré-existente que dispensa apresentações, especialmente para pessoas familiarizadas com o React. Se o JSX fosse conquistar o mundo Vue.js, não posso deixar de sentir que já o teria feito. (Particularmente se for alguma indicação de que tantas pessoas estão clamando por JSX no Flutter quanto você afirma.)

Riiiiight, então em vez de JSX você usa DSX com Flutter.

JSX e DSX são o mesmo conceito sintático. O problema é que, onde o JSX foi construído em uma linguagem dinâmica de tipagem fraca como JavaScript, o DSX está sendo construído em uma linguagem estática fortemente tipada como Dart. Isso significa que há muitos problemas que o DSX terá que levar em conta que o JSX não precisou se for algo além de uma implementação de nicho "JSX for Flutter", e serão necessárias algumas modificações _engenhosas_ para fazer o DSX realmente funcionar sem torná-lo muito inchado para justificar a alegação de que é mais visualmente conciso.

E para abordar a refutação "DSX é apenas Dart, se o DSX não puder fazer algo, apenas use o Dart", minha contra-refutação seria se eu tivesse que continuar voltando ao Dart sempre que me deparar com um cenário que o DSX não t lidar, então por que eu não deveria usar o Dart o tempo todo?

E para responder à refutação dessa leitura "você pode se quiser, o DSX é apenas uma opção", então você está realmente se vendendo. Mesmo que realmente seja apenas "uma opção", ainda precisa trazer algo para a mesa que convença as pessoas a usá-lo. Você mesmo disse que DSX não é JSX, então as pessoas que querem apenas JSX não vão conseguir o que querem. Isso significa que precisa haver algumas razões tangíveis além do "apelo semelhante ao JSX" para que as pessoas queiram usá-lo.

Se você está apenas construindo uma ferramenta que você mesmo deseja usar, tudo isso é discutível e você pode enlouquecer. Mas se você está realmente construindo algo que pretende que outras pessoas usem, então você precisa colocá-lo em uma forma sólida por que você acha que eles deveriam.

Componentes da Web são zoobies, mortos, mas ainda andando; eles são tão difundidos quanto os cangurus no Canadá. Eu poderia continuar por dias, mas para evitar divagar...

Um pouco fora do tópico, mas gostaria de salientar que os componentes da Web realmente são uma visão promissora do futuro, mesmo que o suporte a eles esteja sendo adicionado mais lentamente que o tar. Pense desta forma: o React faz o que faz porque implementa essencialmente a ideia de componentes da web somente em Javascript. Imagine o quão melhor seria se esses recursos fossem suportados pelo navegador e se beneficiassem do desempenho sem sandbox e não precisando operar através da manipulação do DOM? (Concedido pode ser mais 20 anos antes de descobrirmos, mas ainda assim...)

@andrewackerman

Desculpe cara, eu não tenho tempo para discutir sem parar e repetir o que eu disse antes várias vezes; nós não vamos terminar de acordo de qualquer maneira, então boa sorte com o seu FLUI.

Você falou eloquentemente sobre o que ele pode e será capaz de fazer, mas tudo o que realmente vimos é um pequeno punhado de trechos de código construídos com propósito e sua palavra de que eles foram gerados pelo transpilador.

O transpilador DSX online está ativo desde fevereiro de 2018 e qualquer pessoa pode usá-lo, então não há necessidade de aceitar minha palavra para nada. Pressione 'Compile' e ele compila o que está escrito no painel esquerdo e coloca os resultados no painel direito. Abra o depurador e você verá o AST escrito.
https://spark-heroku-dsx.herokuapp.com/index.html

O problema é que, onde o JSX foi construído em uma linguagem dinâmica de tipagem fraca como JavaScript, o DSX está sendo construído em uma linguagem estática fortemente tipada como Dart.

Não faz grande diferença, como o conceito OOP (Programação Orientada a Objetos) e a sintaxe para 'classes'. É quase idêntico em Javascript sem tipo ou Dart digitado; o mesmo pode ser dito para declaração 'if', declaração 'for', etc.

ele ainda precisa trazer algo para a mesa que vai convencer as pessoas a usá-lo.

Aparentemente já dá para 100 pessoas nesse ingresso; e isso é 100 vezes maior do que apenas eu usando; bom o suficiente para mim.

@cbazza

Desculpe cara, eu não tenho tempo para discutir sem parar e repetir o que eu disse antes várias vezes; nós não vamos terminar de acordo de qualquer maneira, então boa sorte com o seu FLUI.

Não estou discutindo com você apenas para argumentar ou por causa de algum preconceito anti-JSX profundamente arraigado. Estou tentando fazer com que você responda a perguntas que precisam ser respondidas. Você está desenvolvendo uma ferramenta que presumivelmente pretende que outras pessoas usem, mas ainda não ofereceu uma razão convincente para eles usarem além dos benefícios vagos e subjetivos de "familiaridade" e "porque é melhor". O primeiro, como eu disse antes, não é necessariamente uma coisa boa, e o segundo ainda é uma reivindicação feita sem qualquer suporte tangível.

Se você quer que sua ferramenta seja um sucesso, ela precisa definir em pedra o que você está fazendo e por que você está fazendo isso, e você precisa fazer isso de uma forma que possa ser facilmente transmitida a outras pessoas. Isso não quer dizer que você não pode fazer um produto até que seja apreciado por _todos_, mas objetivos claros e concisos são cruciais para moldar o design e a implementação. Caso contrário, você acabará com um utilitário sem direção que será, na melhor das hipóteses, um produto de nicho e terá muita sorte se acabar no código de produção de qualquer escala.

O transpilador DSX online está ativo desde fevereiro de 2018 e qualquer pessoa pode usá-lo, então não há necessidade de aceitar minha palavra para nada. Pressione 'Compile' e ele compila o que está escrito no painel esquerdo e coloca os resultados no painel direito. Abra o depurador e você verá o AST escrito.

Eu nem vi que esse link era um exemplo de trabalho. Eu nunca usei herokuapp antes e parecia apenas uma essência ou algo assim, então isso é comigo. :P

(Embora eu aponte que mexer em uma sandbox online não é o mesmo que testar o transpilador em um ambiente mais prático.)

Não faz grande diferença, como o conceito OOP (Programação Orientada a Objetos) e a sintaxe para 'classes'. É quase idêntico em Javascript sem tipo ou Dart digitado; o mesmo pode ser dito para declaração 'if', declaração 'for', etc.

Você já teve que lidar com uma dessas diferenças na tipagem forte da criança . E quanto a tipagem forte de atributo? E quanto aos widgets em diferentes bibliotecas com o mesmo nome? O que acontece se alguém fizer um widget com mais de um argumento posicional sem nome? O que acontece se importarmos duas bibliotecas que possuem widgets com o mesmo nome? O que acontece em algum cenário que eu não pensei em aparecer para mostrar ainda mais a diferença inerente entre sistemas como Javascript e Dart? Devo dizer que você ser tão irreverente nesse ponto de discussão me preocupa com a longevidade do DSX em um cenário do mundo real.

Aparentemente já dá para 100 pessoas nesse ingresso; e isso é 100 vezes maior do que apenas eu usando; bom o suficiente para mim.

Novamente, são 100 pessoas que votaram positivamente na questão com base em "Considere sintaxe semelhante a JSX dentro do código dart". Eles votaram positivamente porque querem _JSX_ e, como você fez questão de apontar, DSX não é JSX. Então, por que mais eles iriam querer usar o DSX? Porque a declaração de interface do usuário semelhante a XML inline é "o futuro"? Mais uma vez, eu simplesmente não vejo isso.

Já cobrimos o JSX no Vue, não obtendo nenhuma tração, mas também há as duas alternativas React mencionadas no artigo de Web Components que você vinculou: Inferno e Preact. Tanto quanto eu posso dizer, ambos falharam em fazer qualquer tipo de onda no mundo de desenvolvimento de aplicativos da Web baseados em JS, apesar de também suportarem nativamente a sintaxe do tipo JSX. Eu realmente acho que as pessoas precisam dar uma boa olhada sobre _exatamente por que_ as pessoas gostam de JSX no React, porque, segundo todos os relatos, não parece ser por causa do próprio JSX. Se _essa_ pergunta puder ser respondida, então podemos avançar em direção a inovações "futuras" em vez de apenas transferir aquele recurso daquela biblioteca que gostamos em todos os outros lugares que pessoalmente achamos que deveria estar.

Pensar na quantidade de energia que foi investida apenas nesta discussão e no que poderia ter sido feito de bom para melhorar a estrutura atual me deixa triste.

@andrewackerman

O problema é que, onde o JSX foi construído em uma linguagem dinâmica de tipagem fraca como JavaScript, o DSX está sendo construído em uma linguagem estática fortemente tipada como Dart.

Desculpe, mas isso não é um problema. Além disso, isso não faz o menor sentido. Além disso, usamos JSX com TypeScript.

@escamoteur absolutamente!

@escamoteur estou com você nessa. _Os 100._

@Bessonov

Desculpe, mas isso não é um problema. Além disso, isso não faz o menor sentido. Além disso, usamos JSX com TypeScript.

O React não foi projetado para TypeScript. Ele foi projetado para Javascript. Todas as definições de widget, atributos, propriedades e tudo o mais foram projetados para serem usados ​​no ambiente dinâmico do JavaScript, portanto, a segurança de tipo do TypeScript não introduz nenhum fator novo na forma como o JSX interage com o React. Este é mais um exemplo de como o JSX foi projetado para uma configuração completamente diferente do que é o Flutter.

@andrewackerman
Por que você acha que isso importa? JSX é uma maneira de descrever a interface. É agnóstico de linguagem por si só. Olhe aqui . Não é JavaScript. Mas bem, por que não pode ser feito com JSX? (Além disso, não há implementação disso (ainda))

E .. você sabe ... o fluxo vem do fb também:

Flow é um verificador de tipos estático para JavaScript.

Por favor, pare de vender argumentos a favor e contra extensões que você nunca usou. Eu uso JSX todos os dias e estou feliz com isso ATM, embora eu estivesse muito cético sobre isso. Eu posso imaginar, que JSX evolui em outros padrões, como foi com AngularJS.

E talvez este tópico ajude a encontrar um padrão melhor para o Dart? DSX é apenas uma proposta. Veja o exemplo de padrão do construtor acima ou outros ajustes de idioma apresentados aqui. E, bem, talvez o seu fluido seja uma maneira melhor? Eu não sei. Mas vamos descobrir e ajudar uns aos outros a melhorar suas sugestões em vez de discutir sobre coisas ruins na proposta de outra pessoa.

Eu gostaria de propor fechar este tópico e abrir um novo tópico guarda-chuva com conversa limitada. Todas as propostas para melhorar a forma, como o flutter pode ser usado, discutem em tópicos próprios objetivamente com amor e sem ódio.

Sim, a quantidade de ódio aqui é épica, apenas considere isso:
Existem 3587 tickets abertos, se você os classificar por "polegar para baixo" você recebe
1 (este) com 57 "polegares para baixo"
3586 (outros bilhetes) com 1 ou menos "polegar para baixo"

@Bessonov

Por que você acha que isso importa? JSX é uma maneira de descrever a interface. É agnóstico de linguagem por si só. Olhe aqui. Não é JavaScript. Mas bem, por que não pode ser feito com JSX? (Além disso, não há implementação disso (ainda))

É uma maneira de descrever a interface do usuário _em Javascript_ (daí a parte "JS" do nome). E não, uma vez que é um DSL embutido, ele _não_ é independente de linguagem. E mesmo que fosse, isso ainda não a torna a "melhor escolha", já que existem muitas DSLs verdadeiramente agnósticas de linguagem por aí que seriam lamentavelmente inadequadas para declarações de interface do usuário.

E .. você sabe ... o fluxo vem do fb também:

O Flow é como o TypeScript: um sistema de verificação de tipo estático para Javascript. Não é uma ferramenta React, nem o React foi projetado para ser usado com ela. O React é antes de tudo uma biblioteca Javascript, e o JSX foi projetado para ser usado com o React. Quaisquer ferramentas e utilitários secundários introduzidos no desenvolvimento do React são irrelevantes para a interoperabilidade do React+JSX.

Por favor, pare de vender argumentos a favor e contra extensões que você nunca usou. Eu uso JSX todos os dias e estou feliz com isso ATM, embora eu estivesse muito cético sobre isso. Eu posso imaginar, que JSX evolui em outros padrões, como foi com AngularJS.

Eu usei o JSX e, embora tenha opiniões pessoais sobre ele, deliberadamente deixei essas opiniões fora desta discussão. Na verdade, se você tivesse lido meus comentários anteriores, saberia que eu elogiei o JSX por revolucionar o desenvolvimento de UI em React. Além de alguns comentários levemente tangenciais que fiz sobre a penetração do JSX no mercado como um todo, meus argumentos foram especificamente sobre JSX _in Flutter_. E nesse tópico, não há base prática para determinar a eficácia do DSX, então tudo o que podemos fazer é examinar como o JSX foi implementado em outros lugares, e esse exame não é um bom presságio.

A menos, é claro, que você também esteja usando o DSX todos os dias e possa nos esclarecer sobre as vantagens práticas de usar o DSX no Flutter?

E talvez este tópico ajude a encontrar um padrão melhor para o Dart? DSX é apenas uma proposta. Veja o exemplo de padrão do construtor acima ou outros ajustes de idioma apresentados aqui. E, bem, talvez o seu fluido seja uma maneira melhor? Eu não sei. Mas vamos descobrir e ajudar uns aos outros a melhorar suas sugestões em vez de discutir sobre coisas ruins na proposta de outra pessoa.

_É isso que estou fazendo._ O DSX está sendo proposto como uma solução de interface do usuário para pessoas familiarizadas com JSX. Existem elementos-chave de design no JSX que foram planejados para serem usados ​​em um ambiente completamente diferente do Dart e do Flutter. _Essas diferenças precisam ser resolvidas para que o DSX seja bem-sucedido._ Não estou sendo um _odiador_. Estou tentando promover uma discussão construtiva e fazer as perguntas importantes. No entanto, todas as respostas que tenho recebido equivalem a tautologia subjetiva ("JSX é bom porque é o futuro, e é o futuro porque é bom"), aceno de mão desdenhoso de pontos cruciais de design ("DSX não precisa levar em conta para diferenças entre JS e Dart porque não há nenhuma"), ou simplesmente hostil ("Você obviamente não gosta de JSX, então pare de falar sobre DSX").

Você não faz um produto de sucesso apenas com elogios não adulterados. Ele precisa enfrentar e responder pelas críticas também. Pessoas aparecendo e dizendo "OMG sim, por favor, faça DSX", enquanto edificante, não é útil. Houve várias pessoas ao longo deste tópico que trouxeram críticas perfeitamente válidas ao DSX, tanto com seu design inicial quanto com o conceito como um todo. E, na maioria das vezes, muitas dessas críticas ainda precisam ser abordadas diretamente, com a atitude geral sendo desdenhosa.

Meu único medo é que todo esse amor incondicional pelo JSX esteja impedindo as pessoas de verem o DSX objetivamente. Eu entendo porque vocês querem algo como JSX no Flutter, e eu posso relacionar - minha opinião de que o Flutter precisa de uma DSL de interface do usuário dedicada é o que me levou a criar o flui. Mas se as únicas pessoas autorizadas a falar sobre DSX são as pessoas que não têm nada além de coisas boas a dizer sobre ele, então ele _vai_ falhar.

Podemos recentralizar a discussão sobre este tema?
Na verdade, não vejo nenhuma razão para manter este assunto em aberto.

A equipe do Dart afirmou que eles têm outras prioridades. E o lado profissional do JSX se ofereceu para fazer sua própria implementação do DSX

Talvez devêssemos ter apenas alguns repositórios de código aberto propondo soluções diferentes (mesmo que mal funcionassem). Como DSX, ou modelos.
E então considere redirecionar do readme ou awesome_flutter do Flutter para esses repositórios. E se houver algo bloqueando uma implementação de DSX, crie outro problema com os detalhes.

Então deixe a comunidade fazer o seu trabalho.

Deixe aberto como está porque as pessoas continuarão abrindo novos tickets pedindo JSX (como já aconteceu duas vezes antes).

Deixe aberto como está porque as pessoas continuarão abrindo novos tickets pedindo JSX (como já aconteceu duas vezes antes).

A diferença aqui é que agora poderíamos responder com o seguinte:

"Não planejamos implementar isso no dart/flutter por enquanto. Mas você pode dar uma olhada nas alternativas da comunidade [aqui] e [lá] ou ler [esta edição]"

e feche o problema como duplicado.

Um lugar para comentários e votos e é aqui. A solicitação de funcionalidade semelhante a JSX não está desaparecendo e o ticket é aberto porque precisa de suporte a ferramentas Flutter (compilador e VS Code IDE) e atualizei a solicitação de ticket com essas informações (primeiro comentário). Se um grande número de pessoas começar a pedir isso, isso dará incentivo à equipe do Flutter para investir recursos nisso.

Parece que a maior parte da controvérsia aqui não está em torno do JSX neste momento, mas do DSX. Eu sugeriria dividir a discussão do DSX em seu próprio segmento e deixar este genérico para o JSX.

No final das contas, o DSX é apenas uma maneira de chegar mais perto do JSX, portanto, não devemos misturar essas duas discussões em um tópico de qualquer maneira.

Grande não para isso, eu realmente acho que 1 linguagem só é um grande ganho, a sintaxe jsx virá com mais coisas como separação de xml de js, etc... Não é bom.

Essa é a minha opinião.

Esse é o problema mais longo e inútil do Github que eu já vi.

@cbazza Bom trabalho 👍
DSX + 1

@BarryYan , obrigado

Por favor, evite esse tipo de comentário, seja "+1" ou "Obrigado".
Isso envia um e-mail para todos os assinantes sem nada de interessante.

Por favor, evite esse tipo de comentário, seja "+1" ou "Obrigado".
Isso envia um e-mail para todos os assinantes sem nada de interessante.

Nada interessante para você !!!
Por favor, evite dizer às pessoas o que elas podem dizer ou fazer e concentre-se apenas no que você pode dizer ou fazer.

@cbazza

Cara, é etiqueta básica. Qualquer nova mensagem neste tópico envia um e-mail para todos os inscritos, então é rude postar comentários que não contribuem para a discussão porque incomoda as pessoas sem motivo. Reações básicas como "+1" e "Obrigado" podem ser transmitidas com uma simples reação positiva, então faça isso.

Dito isto, se este tópico realmente se transformou em uma discussão sobre se alguém deve ou não postar uma mensagem "+1", isso é uma grande bandeira vermelha de que toda discussão construtiva morreu oficialmente e realmente deve ser fechada (talvez permanentemente desta vez).

@andrewackerman ,

Entendi, mas enquanto você está nisso, talvez você também deva considerar a etiqueta básica ao explodir este tópico com seus romances (escrita longa e ficcional).

Por favor, pare de espalhar FUD (medo incerteza e dúvida) com sua enxurrada de perguntas sem sentido (você sabe, jogue tanta porcaria na parede e veja se alguma coisa gruda) e demandas.

Depois de todos os seus escritos, você não agregou nenhum valor ao DSX, então não tenho interesse em discutir com você sobre esse assunto. Seu motivo é óbvio, porém, promova o FLUI enquanto explode o DSX.

Diga-me uma coisa, você tem respostas para suas próprias perguntas quando elas são aplicadas ao FLUI? Vamos discutir FLUI um pouco, não é?

@cbazza

Entendi, mas enquanto você está nisso, talvez você também deva considerar a etiqueta básica ao explodir este tópico com seus romances (escrita longa e ficcional).

O fato de você se referir às minhas respostas de que dediquei muito tempo e esforço para ser tão bem pensado e imparcial quanto posso fazê-las como "escrita longa e ficcional" ilustra muito sobre seu personagem e como você está se aproximando esta discussão. Estou tentando promover a discussão sobre questões muito reais em torno de qualquer implementação do JSX no Flutter, enquanto você critica qualquer pessoa com qualquer forma de opinião contrária. Qual de nós é o maior infrator da etiqueta básica?

Por favor, pare de espalhar FUD (medo incerteza e dúvida) com sua enxurrada de perguntas sem sentido (você sabe, jogue tanta porcaria na parede e veja se alguma coisa gruda) e demandas.

A única coisa que estou "exigindo" é que você aborde as inúmeras questões levantadas por muitas pessoas em relação ao DSX com mais do que um aceno de mão ou hostilidade aberta. Para alguém que está propondo uma mudança / adição significativa ao conjunto de recursos do Flutter, sinto que essa não é uma expectativa irracional.

Depois de todos os seus escritos, você não agregou nenhum valor ao DSX, então não tenho interesse em discutir com você sobre esse assunto. Seu motivo é óbvio, porém, promova o FLUI enquanto explode o DSX.

Estou pedindo a você que defenda sua posição. Você disse repetidamente que JSX/DSX é o melhor/futuro, mas ainda precisa explicar como ou por quê. Várias pessoas expressaram preocupações válidas sobre o DSX, mas em vez de abordá-las, você a ignora escondendo-se atrás do contra-argumento "se você não gosta, não use". Meu "motivo" é fazer com que você responda a perguntas que precisam ser feitas em relação a _qualquer_ projeto técnico, principalmente por que as pessoas deveriam usá-lo em vez de alternativas. (E, como expliquei antes, a familiaridade não é uma razão boa o suficiente.)

No que diz respeito ao FLUI, tudo o que estou fazendo é propor uma solução alternativa para o problema geral (sintaxe declarativa da interface do usuário para Flutter) enquanto solicita que as pessoas façam o mesmo que estou fazendo com o DSX - ofereça críticas sinceras e construtivas. Não estou dizendo que FLUI é objetivamente melhor que DSX - estou propondo uma alternativa formada a partir de uma abordagem diferente ao desenvolvimento de UI e pedindo às pessoas que formem suas próprias opiniões.

(Eu também gostaria de salientar que, além da minha menção inicial onde eu estava propondo uma possível abordagem alternativa para a representação da GUI, as únicas vezes que eu falei sobre FLUI foi quando você mencionou isso. faz sentido que meu motivo ulterior seja promovê-lo quando você está falando sobre isso mais do que eu?)

Diga-me uma coisa, você tem respostas para suas próprias perguntas quando elas são aplicadas ao FLUI? Vamos discutir FLUI um pouco, não é?

FLUI não é DSX - ele não precisa responder _todas_ perguntas que eu fiz a você sobre DSX porque muitas delas são específicas para o design do DSX. Isso não quer dizer que não tenha seu próprio conjunto de perguntas que precisam ser respondidas, e não, eu não tenho todas essas respostas. É por isso que eu valorizo ​​a discussão crítica - FLUI/DSX não vai enfrentar o tribunal da opinião pública a menos que eles possam sobreviver sendo varridos pelas brasas algumas vezes. Este não é o local apropriado para discutir FLUI. Se você quiser discutir o FLUI longamente, o projeto tem seu próprio quadro de assuntos, então sinta-se à vontade para postar lá.

Em vez de responder às críticas, você foi defensivo e evasivo, tanto que é diretamente responsável pelas duas ocasiões separadas (aproximando-se de três) em que este tópico teve que ser temporariamente fechado devido ao aquecimento excessivo. Então, vou quebrar a "etiqueta" e dizer isso uma vez: guarde seu ego, pare de interpretar críticas como ataques pessoais e responda às perguntas importantes. Ou isso, ou faça as pazes com o DSX nunca decolando.

andrewackerman Bom trabalho 👍
+ 1

@andrewackerman

Bom trabalho

Cara, você recebe um elogio do @jstansbe que transmite muito mais informações do que um polegar para cima e você diminui o elogio?

Obviamente você não levou a sério minha dica, mas não chega a conclusões sobre meu personagem porque você não me conhece.

O fato de você se referir às minhas respostas é que dediquei muito tempo e esforço para ser tão bem pensado e imparcial quanto posso fazê-las

Isso eu aprecio e leio todos os seus 'longos escritos', respondendo tudo: de jeito nenhum, mas quando eu respondo corretamente você não entende minha resposta e conclui que estou sendo desdenhoso.

É óbvio para mim que você não é muito experiente com JSX, você realmente não entende como ele funciona. Então, em vez de dobrar, basta possuí-lo e explicarei com mais detalhes. Por exemplo, JSX e DSX fazem apenas as 2 transformações a seguir (mencionadas várias vezes 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 o resto é tratado pelo idioma do host, por exemplo: como ele lida com a importação de componentes com o mesmo nome; resposta: idioma do host. Eu não estou sendo desdenhoso, é a maneira como ele é projetado e a fonte de sua força. Você vê se você separa marcação e programação em arquivos separados, você começa a duplicar a programação dentro da marcação com construções simples para 'se', etc. Você acaba construindo uma linguagem de programação declarativa dentro da marcação que nunca pode ser tão poderosa quanto a linguagem de programação principal. Então, ao trazer a marcação para a linguagem de programação, você tem o melhor dos dois mundos e esse é o poder do JSX/DSX.

Observe acima em (2) que a transformação <Widget> codificada e isso nem sempre é o caso, então agora você pode especificar isso, se necessário, conforme discutido anteriormente. Olhe para as transformações e agora todos os símbolos vêm da fonte ou podem ser especificados para que não haja grandes pegadinhas mágicas no futuro.

enquanto você critica qualquer pessoa com qualquer forma de opinião contrária.

Isso não é verdade, você pode ter opinião contrária, mas não pode afirmar algo verdadeiro quando posso provar o contrário.

Para alguém que está propondo uma mudança / adição significativa ao conjunto de recursos do Flutter, sinto que essa não é uma expectativa irracional.

Mas é isso, eu queria que a equipe do Flutter implementasse o DSX, mas depois fiz isso, então o que eles precisam implementar são coisas genéricas que não dependem do DSX e o DSX não é o único beneficiário. O mecanismo js do navegador suporta mapas de origem que habilitam um ecossistema de novas linguagens no navegador que são transpiladas para js; possibilitou a criação do Dart !!! e vários outros (Coffeescript, Typescript, Reason, etc). Dart poderia fazer o mesmo agora e se beneficiar do ecossistema que ajuda a criar, todos os barcos sobem.

Estou pedindo que defenda sua posição.

Já fiz isso muitas vezes e a conclusão é que Plain Dart ou DSX se resume à preferência do usuário; e o importante é dar opção ao invés de forçar as pessoas de um jeito.

em primeiro lugar, por que as pessoas deveriam usá-lo sobre as alternativas.

Eu usaria o DSX porque prefiro, como espaços ou tabulações, definição de tipo antes ou depois do nome da variável. Não adianta lutar por isso, apenas aceite que as pessoas têm preferências diferentes; existe mais de 1 editor de programação por aí certo?

familiaridade não é uma razão boa o suficiente

Apenas sua opinião, por que usamos declarações "if" em quase todos os idiomas, declaração 'for', 'class' e agora 'asyn/await'.

Este não é o local apropriado para discutir FLUI. Se você quiser discutir o FLUI longamente, o projeto tem seu próprio quadro de assuntos, então sinta-se à vontade para postar lá.

Muito bom, agora você ganhou meu respeito.

você é diretamente responsável pelas duas ocasiões separadas (aproximando-se de três) em que este tópico teve que ser temporariamente fechado devido às coisas ficarem muito quentes.

O problema é que, mesmo que seja fechado novamente, isso não impedirá as pessoas de solicitar recursos semelhantes ao JSX.

guarde seu ego, pare de interpretar críticas como ataques pessoais e responda às perguntas importantes.

Eu não tenho ego, mas tenho pavio curto, então não há dúvidas quando alguém me irrita (sai imediatamente). Sem querer ofendê-lo, mas suas perguntas não eram importantes.

Ou isso, ou faça as pazes com o DSX nunca decolando.

Você não é o medidor usado para medir o sucesso e não sabe o que estou fazendo.

Cara, você recebe um elogio do @jstansbe que transmite muito mais informações do que um polegar para cima e você diminui o elogio?

Você aparentemente não percebeu o sarcasmo inerente ao comentário dele. (Ele literalmente fez tudo o que eu disse para não fazer.) Embora seja um troll divertido que eu possa apreciar, não é apropriado aqui. E se, por acaso, ele estava sendo sincero, então peço desculpas pelo meu sarcasmo, mas meu ponto de vista ainda se mantém - esse tipo de comentário _ainda_ não é apropriado aqui.

É óbvio para mim que você não é muito experiente com JSX ...

Meu aviso de isenção de responsabilidade no meu primeiro comentário neste tópico talvez o tenha avisado?

...você realmente não entende como funciona.

Você me iguala a não ter muita experiência com JSX e eu não saber como funciona? Embora eu nunca tenha trabalhado em nenhum projeto sério do React, fiz meu quinhão de ajustes. Eu entendo perfeitamente como _funciona_.

Todo o resto é tratado pelo idioma do host, por exemplo: como ele lida com a importação de componentes com o mesmo nome; resposta: idioma do host.

E isso faz sentido no caso em que a linguagem de marcação e a linguagem host são distintas. Com JSX, a linguagem de marcação é projetada como uma _extensão_ da linguagem do host. Como tal, o JSX foi projetado como uma extensão do JS, e é por isso que funciona tão bem. DSX é uma implementação de JSX para Dart.

Você não vê o problema aí? Uma linguagem de marcação projetada como uma extensão de uma linguagem sendo improvisada em uma linguagem fundamentalmente diferente. É _inevitável_ que haja um monte de problemas, casos extremos e considerações.

Você vê se você separa marcação e programação em arquivos separados, você começa a duplicar a programação dentro da marcação com construções simples para 'se', etc. Você acaba construindo uma linguagem de programação declarativa dentro da marcação que nunca pode ser tão poderosa quanto a linguagem de programação principal.

Primeiro, a ideia por trás de separar marcação e programação é que, se você estiver fazendo isso corretamente, há uma separação clara entre os dois, o que resulta em _nenhuma_ duplicação.

Em segundo lugar, se você estiver fazendo algo muito mais complexo do que if s e for s em seu código de interface do usuário (que são construções que podem ser facilmente manipuladas em muitas soluções de marcação), eu diria que é um sinal de que há algo errado em seu design de qualquer maneira. De acordo com os princípios de design do MVC/MVVM, se você estiver incorporando lógica complexa em suas construções de interface do usuário, isso é um sinal potencial de código fedido e você deve considerar seriamente um redesenho de qualquer maneira.

(Isso não quer dizer que você _não pode_ escrever UI declarativa no estilo MVVM usando JSX, mas é apenas algo que convida a problemas por pouco ganho objetivo. Por que usar algo em que você _pode_ escrever código compatível com os padrões quando você pode usar algo que torna difícil escrever código que _não é_?)

Isso não é verdade, você pode ter opinião contrária, mas não pode afirmar algo verdadeiro quando posso provar o contrário.

Você não "provou" nada. Você deu um monte de afirmações subjetivas que ainda precisam ser apoiadas por qualquer lógica fundamentada. (Embora, para seu crédito, este último post seja uma grande melhoria.)

Mas é isso, eu queria que a equipe do Flutter implementasse o DSX, mas depois fiz isso, então o que eles precisam implementar são coisas genéricas que não dependem do DSX e o DSX não é o único beneficiário.

Você ainda está pedindo para eles fazerem coisas não triviais, então o ônus está em convencê-los e ao resto de nós por que eles deveriam e por que é tão importante que eles descrevam outras coisas em sua lista de tarefas.

O mecanismo js do navegador suporta mapas de origem que habilitam um ecossistema de novas linguagens no navegador que são transpiladas para js; possibilitou a criação do Dart !!!

É da própria natureza do JS que tal coisa seja facilmente factível (relativamente falando), tanto que o Dart está longe de ser a única linguagem que possui um transpilador para JS. Como já apontei muitas vezes, Dart não é JS. É estático e fortemente tipado, o que significa que muitas coisas que seriam fáceis de fazer em JS são extremamente complexas no Dart.

Eu usaria o DSX porque prefiro, como espaços ou tabulações, definição de tipo antes ou depois do nome da variável. Não adianta lutar por isso, apenas aceite que as pessoas têm preferências diferentes; existe mais de 1 editor de programação por aí certo?

Por essa lógica, devo criar uma solução de interface do usuário na qual você define construções usando braille codificado em hexadecimal. Quer dizer, se tudo o que realmente importa é a preferência pessoal, tudo o que preciso dizer para defender sua existência é que "algumas pessoas preferem", certo?

Você está desenvolvendo uma ferramenta que pretende que outras pessoas usem, então você precisa de raciocínio além de "algumas pessoas podem gostar" para se tornar convincente. Se você não pode colocar em palavras _por que_ eles deveriam usá-lo em vez de outra coisa, então o que o faz acreditar que eles o farão? E o que há para incentivá-lo a _garantir_ que eles o farão ao projetar o conjunto de recursos do DSX?

Apenas sua opinião, por que usamos instruções "if" em quase todos os idiomas, instrução 'for', 'class' e agora 'async/await'.

Primeiro, essas palavras-chave (além de async/await ) se tornaram um léxico de programação comum devido à imensa popularidade de linguagens como C e BASIC ao longo de várias décadas. Como mencionei antes, o JSX está longe de ser comprovado em sua longevidade - existe há 5 anos e ainda não viu nenhum uso significativo fora do React, apesar da opção estar disponível.

Em segundo lugar, há uma grande diferença entre familiaridade e convenção. if , while , for , struct , class , enum , try/catch/finally , async/await ... essas são ótimas maneiras de representar verbalmente um conceito. Existem razões para defender o uso dessas palavras-chave além de serem apenas o que as pessoas estão familiarizadas - elas fazem sentido conceitual. (Claro, isso não significa que elas são constantes. Algumas linguagens fazem if ... then . Algumas fazem if ... elif enquanto outras fazem if ... else if e outras ainda fazem if...endif . Alguns fazem foreach , outros fazem from . E assim por diante, e assim por diante.)

Enquanto isso, o argumento para usar JSX porque é "familiar" não se encaixa na mesma categoria. JSX é uma maneira de representar UI declarativa, mas não é a única nem a mais popular. Além disso, ele foi projetado para ser usado em um tipo de ambiente, portanto, usá-lo em outro ambiente pode transformar a familiaridade em algo ruim - a familiaridade os leva a esperar que funcione mais ou menos exatamente da mesma maneira que funciona em outros lugares, então se isso não leva a uma desconexão mental que é algo que você quer _evitar_.

O problema é que, mesmo que seja fechado novamente, isso não impedirá as pessoas de solicitar recursos semelhantes ao JSX.

Eles pedem de qualquer maneira, e o problema é redirecionado aqui da mesma forma. Não vejo como o tópico sendo fechado mudaria isso.

Você não é o medidor usado para medir o sucesso e não sabe o que estou fazendo.

Leia qualquer livro sobre design de produto. O capítulo um é sempre sobre como criar uma declaração, um manifesto, um slogan, qualquer coisa tangível e exprimível em inglês simples que descreva o que é o produto e por que as pessoas deveriam se importar com ele. Há uma razão pela qual a forma mais comum de conselho dado aos empreendedores amadores é fazer um “elevator pitch”, algo que comunique de forma clara e concisa o produto e o sorteio em 30 segundos ou menos. Se você não consegue explicar de forma sucinta por que as pessoas deveriam usar seu produto, é um sinal de que ele está passando por uma crise de identidade. Se a pessoa que projeta o produto não pode responder adequadamente às críticas, isso dá a impressão de falta de fé em seu próprio produto. Ambas as coisas são grandes bandeiras vermelhas para os investidores.

Nesta situação, o produto é DSX, e os investidores são desenvolvedores pensando em usá-lo. As únicas pessoas que você tem apoiando você são pessoas que aparentemente torcem incondicionalmente por qualquer coisa com "JSX" na descrição. Todas as outras pessoas neste tópico que eu vi questionando o que você está fazendo foram embora aparentemente não convencidas após sua resposta.

Você está atualmente com uma taxa de conversão de 0% ou perto dela, e _é disso que estou vindo quando digo que você ainda não respondeu adequadamente às críticas. Talvez você não se importe, mas se você pretende seriamente que o DSX seja um plug-in de marcação de declaração de interface do usuário utilizável e usado em projetos do mundo real, convém começar.

Mas, novamente, talvez você seja uma exceção.

Ok, esta conversa foi muito além dos tipos de discussões que consideramos aceitáveis ​​na comunidade Flutter, então vou bloquear este tópico e fechar o bug. Por favor, considere ler https://flutter.io/design-principles/#conflict -resolution para mais detalhes sobre como nos comportamos aqui.

O próximo passo, se alguém quiser contribuir com código para resolver esse problema, seria criar um design de como fazer a integração do sistema de compilação, de modo que possamos ter trabalho de geração de código com Gradle, Xcode, hot reload e integração com aplicativos existentes. Se alguém estiver interessado em trabalhar nisso, por favor, não hesite em entrar em contato comigo. Caso contrário, espero que isso seja algo em que trabalharemos no início do próximo ano. Assim que tivermos um mecanismo para fazer isso, soluções como o DSX serão fáceis de integrar ao ecossistema Flutter. Podemos até encontrar soluções que devem ser integradas por padrão. Enquanto isso, também estamos trabalhando em melhorias na sintaxe do Dart para ver se podemos tornar as expressões de interface do usuário ainda mais fáceis de escrever.

Eu gostaria de pedir que as pessoas não abram novos bugs sobre este tópico, a menos que haja algo muito construtivo e novo que valha a pena trazer à tona.