Flutter tem uma página inteira dedicada a atrair pessoas de Xamarin.Forms. Você está dizendo que devemos ignorar a competição. Mesmo?

As ligações do Blazor são lindas! Estou apenas começando com eles e eles oferecem a simplicidade que o Flutter oferece.

@davidortinau como eu disse no outro tópico. A postagem do blog MAUI criou uma confusão massiva. As pessoas agora parecem pensar MVU = view as code / DSL.
Mas isso é completamente independente do que é MVU. MVU é perfeitamente possível com XAML. Não tem nada a ver com como você escreve a visão.
Trata-se apenas de criar um modelo imutável + função de atualização que pega um modelo e msg e constrói um novo modelo e também uma função de visualização que não altera o modelo diretamente, mas envia novos comandos (mensagens) para o loop de atualização.

Acho que o MAUI deve se ater a apenas uma maneira de projetar a interface do usuário, que é: XAML

Blazor Syntex está bem, mas MVU parece uma bagunça totalmente desnecessária para mim. Se for para atrair os Devs do Flutter, por favor, deixe-os ficar com o Flutter; NÃO destrua a beleza do XAML;

Destina-se a dev C # e .NET.

@ sim756

Acho que o MAUI deve se ater a apenas uma maneira de projetar a interface do usuário, que é: XAML

Nunca foi apenas em um sentido. UIs baseadas em código foram suportadas por meio de Xamarin.Forms desde o início. Tornar isso mais acessível faz sentido. E a propósito: MVU pode ser usado facilmente com XAML ( Xamarin.Forms , WPF ).

@ Happypig375

Flutter tem uma página inteira dedicada a atrair pessoas de Xamarin.Forms. Você está dizendo que devemos ignorar a competição. Mesmo?

Bem, é melhor termos a página " Xamarin for Flutter devs "!

@rohanbojja

As ligações do Blazor são lindas! Estou apenas começando com eles e eles oferecem a simplicidade que o Flutter oferece.

Tudo está bem, exceto isso, e _isso_ é por isso que não gosto de Flutter :

Imagem 0

@forki

@davidortinau como eu disse no outro tópico. A postagem do blog MAUI criou uma confusão massiva. As pessoas agora parecem pensar MVU = view as code / DSL.
Mas isso é completamente independente do que é MVU. MVU é perfeitamente possível com XAML. Não tem nada a ver com como você escreve a visão.
Trata-se apenas de criar um modelo imutável + função de atualização que pega um modelo e msg e constrói um novo modelo e também uma função de visualização que não altera o modelo diretamente, mas envia novos comandos (mensagens) para o loop de atualização.

Estou muito confuso !! Obrigado, você acabou de deixar claro, a postagem é catastroficamente confusa:

Imagem 1

@ saint4eva

Acho que o MAUI deve se ater a apenas uma maneira de projetar a interface do usuário, que é: XAML
Blazor Syntex está bem, mas MVU parece uma bagunça totalmente desnecessária para mim. Se for para atrair os Devs do Flutter, por favor, deixe-os ficar com o Flutter; NÃO destrua a beleza do XAML;

Destina-se a dev C # e .NET.

" Ele se destina a C # e .NET dev. ", Exatamente, não deve ser influenciado pelo Flutter (temo que seja ..).

@aspnetde

@ sim756

Acho que o MAUI deve se ater a apenas uma maneira de projetar a interface do usuário, que é: XAML

Nunca foi apenas em um sentido. UIs baseadas em código foram suportadas por meio de Xamarin.Forms desde o início. Tornar isso mais acessível faz sentido. E a propósito: MVU pode ser usado facilmente com XAML ( Xamarin.Forms , WPF ).

Eu sei. Às vezes escrevemos new Button() { .... } , mas este post ( Imagem 1 ) me confundiu, e muitos outros, acredito.

@ Happypig375

Flutter tem uma página inteira dedicada a atrair pessoas de Xamarin.Forms. Você está dizendo que devemos ignorar a competição. Mesmo?

Bem, é melhor termos a página " Xamarin for Flutter devs "!

LOL. Imagine uma página dedicada a "Windows Forms for WPF devs".

XAML é apenas uma "ferramenta" no topo do modelo de objeto ... Você pode usar xaml, c #. Você pode arquitetar seu aplicativo usando MVVM (com ou sem XAML) ou com MVU (para ser justo, os exemplos fornecidos não eram MVU "reais", mas este é outro tópico).

Se você não gosta de interface do usuário codificada ou da abordagem MVU, simplesmente ignore :) Não há necessidade de empurrá-la de volta.

Eu não acho que isso é apenas para atrair o desenvolvedor de vibração. O padrão MVU está em ascensão e é muito adequado para desenvolvimento móvel.

A IU codificada também está em ascensão ... react, flutter, swiftUI, ecc ... eles estão ganhando MUITA popularidade e não é apenas um exagero ... a IU codificada tem ótimas vantagens se bem feita

@GiampaoloGabba
Acho que devo deixar claro que sou menos contra MVU do que Coded-UI. Estou confuso com aquela postagem de que temo que a Coded-UI seja a maneira padrão de desenvolver UIs (.... Tenho medo de perder o XAML).

Bem, nós temos .designer.cs , mas não tivemos que editar o código lá, mesmo eu acho que muitos dos desenvolvedores do Windows Forms nem mesmo viram o conteúdo dos arquivos .designer.cs nunca. Mas aqui, temos o Editor de GUI _capable_ que não precisa nos preocupar com o código de IU codificado no arquivo _.designer.cs_.

É melhor eu editar o título desta edição.

O que eu quis dizer:

O que escolheremos entre Flutter / Swift / Coded-UI e WPF / XAML com um Editor de GUI como o Blend for Visual Studio ?

@ sim756

Eu sei. Às vezes, escrevemos new Button () {....}

Às vezes, as pessoas escrevem aplicativos XF inteiros sem tocar no XAML - e ficam felizes com isso ;-).

@ sim756

Eu sei. Às vezes, escrevemos new Button () {....}

Às vezes, as pessoas escrevem aplicativos XF inteiros sem tocar no XAML - e ficam felizes com isso ;-).

@aspnetde

Estou surpreso..!! 😢

Porém, não para eles, mas para pessoas como eu, que quer o Blend for Xamarin / MAUI, está infeliz:

Android Studio Motion Editor

https://developer.android.com/studio/write/motion-editor

@ sim756 Eu me pergunto se você ainda deseja ter suporte para blend depois de trabalhar em um sistema com o hot reload funcionando corretamente. Normalmente as pessoas preferem muito isso

Vindo de um histórico de XAML / Blend, meus pensamentos iniciais sobre a interface do usuário no código foram recuar, mas depois que tentei, vi muitos benefícios que simplesmente não havia considerado. A remoção da necessidade de - o que agora parece excessivamente complexo, mas na época parecia totalmente razoável - recursos como conversores, recursos e similares me fizeram acreditar muito em IUs que priorizam o código.

Bem, nós temos .designer.cs, mas não tivemos que editar o código lá, mesmo eu acho que muitos dos desenvolvedores do Windows Forms nem mesmo viram o conteúdo dos arquivos .designer.cs nunca.

@ sim756 - embora um designer capaz soe como uma ferramenta de grande produtividade, se você já está por aí há um tempo, pode ter trabalhado em bases de código "legadas", onde o designer foi quebrado e parou de trabalhar algumas versões do Visual Studio atrás, e você teria que entender e editar milhares de linhas em .designer.cs manualmente. Como fazer até mesmo a menor das alterações (como alinhar um botão) em tais bases de código pode levar um ou dois dias - todos os benefícios de produtividade são reconsiderados. (Tive essas experiências com WinForms e WebForms anteriormente).

Quando se trata de XAML, @dsyme fala sobre a dependência de ferramentas pesadas nesta palestra sobre Fabulous com uma seção dedicada a "O problema com XAML". Mesmo que Fabulous tenha muitos problemas próprios, ainda é difícil discordar de muitos dos pontos levantados.