Microsoft-ui-xaml: Discussão: WinUI vs ElectronJS e multiplataforma (aprimore o WinUI para eliminar os motivos para usar o ElectronJS em vez do WinUI)

O mesmo acontece com o novo aplicativo Xbox Beta. Ele usa 400 MB apenas sendo aberto como uma loja glorificada. A Microsoft Store usa apenas 117 MB enquanto ativa.

Até que a Microsoft desenvolva uma estrutura de interface de usuário de plataforma cruzada, que permita uma única interface de usuário e design de controle em todas as plataformas, o ElectronJS e similares continuarão sendo usados.

Exemplo da incrível velocidade do ElectronJS/Teams:
Em primeiro lugar, como comparação, cronometrei quanto tempo leva para abrir o Microsoft Outlook e visualizar a mensagem mais recente na caixa de entrada (uma caixa de entrada que contém um número muito grande de mensagens). Levou apenas alguns segundos - na verdade, foi tão rápido que não consegui parar o cronômetro rápido o suficiente para obter uma medição precisa.
Em seguida, cronometrei quanto tempo leva para abrir o Microsoft Teams e visualizar a mensagem mais recente no bate-papo com um colega: 27 segundos! Esse tempo pode ser maior ou menor dependendo de quantas mensagens e imagens existem no painel de bate-papo.

( ATUALIZAÇÃO 9-NOV-2019: _Uma nova versão do Teams foi lançada e melhora o tempo necessário para visualizar a mensagem de bate-papo mais recente. O exemplo mencionado de 27 segundos agora descreve a versão anterior do Teams. Obrigado à equipe da Microsoft membros que trabalharam nesta melhoria._)

Na semana passada, cliquei no ícone Ajuda no Teams, cliquei em "Fornecer feedback" e digitei uma mensagem. Foi surpreendentemente lento: cada vez que eu pressionava uma tecla no teclado, levava vários segundos para cada caractere aparecer! (No entanto, quando testei "Dar feedback" novamente hoje, ficou muito menos do que na semana passada, então aparentemente é complicado reproduzir esse problema específico.)

Se o Teams fosse escrito usando WinUI, não teria esses problemas de velocidade e vários outros bugs incomuns. Por exemplo, os aplicativos WinUI usam a formatação de data/hora definida nas configurações do Windows, enquanto o Teams sempre usa a formatação de data/hora dos EUA de 12 horas quando o Teams está definido para o idioma inglês e ignora as configurações do Windows - não é assim que o Windows aplicativos devem funcionar. Então eu testei mudando o idioma do Teams hoje e ele disse _"Houve uma falha, o Teams está se recuperando"_. E, em seguida, várias imagens em mensagens no painel de bate-papo falharam ao carregar.

Da mesma forma, se o Teams fosse escrito usando WinUI, ele não criaria 5 processos do Teams.

@mdtauk

Até que a Microsoft desenvolva uma estrutura de interface de usuário de plataforma cruzada, que permita uma única interface de usuário e design de controle em todas as plataformas, o ElectronJS e similares continuarão sendo usados.

Embora eu geralmente concorde, deve haver mais nessa história do que isso, porque, por exemplo, o Microsoft OneNote está disponível para Windows, Android e Mac, mas não usa ElectronJS (AFAIK) e não sofre desempenho terrível como Equipes.

@mdtauk

Até que a Microsoft desenvolva uma estrutura de interface de usuário de plataforma cruzada, que permita uma única interface de usuário e design de controle em todas as plataformas, o ElectronJS e similares continuarão sendo usados.

Embora eu geralmente concorde, deve haver mais nessa história do que isso, porque, por exemplo, o Microsoft OneNote está disponível para Windows, Android e Mac, mas não usa ElectronJS (AFAIK) e não sofre desempenho terrível como Equipes.

A Microsoft tem os recursos para criar aplicativos para cada plataforma, compartilhando código o máximo possível - mas não usando uma interface de usuário compartilhada

Eu adoraria ouvir quaisquer argumentos contra o uso da plataforma Uno que visa várias plataformas (Windows, iOS, Android, Web) produzindo pacotes de aplicativos de alto desempenho usando API UWP agora, WinUI depois. Ele usa tudo Microsoft - VS, C#, Xaml, Xamarin, mono, .Net...
Não é vindo diretamente da Microsoft o principal motivo para alguns evitá-lo?

Eu adoraria ouvir quaisquer argumentos contra o uso da plataforma Uno que visa várias plataformas (Windows, iOS, Android, Web) produzindo pacotes de aplicativos de alto desempenho usando API UWP agora, WinUI depois. Ele usa tudo Microsoft - VS, C#, Xaml, Xamarin, mono, .Net...
Não é vindo diretamente da Microsoft o principal motivo para alguns evitá-lo?

Este teria sido um argumento melhor alguns anos atrás, mas muitas empresas que desejam investir na construção de um aplicativo ou sistema precisam saber que a plataforma para a qual estão desenvolvendo tem o suporte e a longevidade de uma grande empresa com vastos recursos como a Microsoft.

O problema com esse argumento é que a última década mostrou a Microsoft abandonando plataformas e bases de usuários, e o Windows sendo movido para o legado ou diminuindo a prioridade dentro da Microsoft.

Portanto, você não pode culpar os novos desenvolvedores por migrarem para plataformas da Web, se desejam executar serviços conectados - ou se concentrar em plataformas que estão sendo desenvolvidas ativamente e parecem ter um forte suporte no futuro.

Ao mesmo tempo, existem algumas grandes empresas como a Adobe, com aplicativos legados - portanto, mover plataformas com eles será quase impossível. Há também amadores e empresas com software personalizado.

A Microsoft se saiu bem com o suporte a .NET e Win32. E WinUI pode ser a chance de permitir Win32 e .NET - mas com uma interface de usuário moderna.

Silverlight, WinRT, UWP - foram todos abandonados. (Eu sei que o UWP não é tecnicamente, mas o WinUI provavelmente será visto como um substituto).

Zune, Windows Media Center, Windows Phone 7, Windows Phone 8, Windows 8 - decepcione os entusiastas e aqueles que eles tentaram evangelizar.

Como a Microsoft posiciona o WinUI e também garante que o futuro do Windows seja garantido, será _absolutamente essencial_

O WinUI for Desktop parece promissor, mas acho que pelo menos um subconjunto de seu XAML deve poder ser executado na Web; WinUI na Web, como um novo Silverlight, mas rodando em .NET 5 e WebAssembly.

Silverlight, WinRT, UWP - foram todos abandonados. (Eu sei que o UWP não é tecnicamente, mas o WinUI provavelmente será visto como um substituto).

Zune, Windows Media Center, Windows Phone 7, Windows Phone 8, Windows 8 - decepcione os entusiastas e aqueles que eles tentaram evangelizar.

Concordar.
Não posso acreditar em alguns dos meus aplicativos Silverlight (aplicativos web0 ainda são usados ​​diariamente por alguns usuários.
Seguir a Microsoft tem sido cada vez mais difícil. O pessoal por trás da Uno Platform a desenvolve e mantém para dar suporte ao seu negócio de aplicativos de pão com manteiga. É de código aberto com muitos contribuidores. Sinto que estou pegando carona em um ônibus muito bom com motoristas de alto nível que sabem bem como navegar pelo labirinto ou bagunça da Microsoft.

Meus 2 centavos: a única esperança do UWP e do WinUI é se eles rapidamente o tornarem multiplataforma, incluído na web, antes que não haja mais nada.
A Uno Platform é uma maneira rápida, fácil e provavelmente também a maneira mais segura de conseguir isso.
Como o @zipswich mencionou, o Uno sempre foi a Microsoft; nas diretrizes de codificação, nas ferramentas, na seleção de idioma e na renderização, e está pronto para o design Fluent.
É 100x mais voltado para a Microsoft do que o Xamarin, por exemplo. Muito menos React ou Electron, e todas as tecnologias feias de HTML e CSS ou JS que a MS é tão obcecada em lisonjear e trapacear.

E deixe-me ser duro, C# é apenas uma linguagem de servidor com a falta de uma estrutura de interface do usuário do .NET Standard.
Quanto mais tempo permanecer assim, Dart ou outras tecnologias se tornarão linguagens de servidor e assumirão completamente o controle.
Você vê que as pessoas estão dispostas a usar linguagens desagradáveis ​​(JS), como um sacrifício para poder usar uma base de código de um único idioma, tanto no cliente quanto no servidor. O C# pode desaparecer como o XAML, ou pode vencer junto com o XAML se o resgate de emergência for fornecido.

Não acredito que o Uno seja o futuro. É muito semelhante ao Xamarin.Forms, sendo um framework Xaml despojado com muitas funcionalidades ausentes e muitas coisas extras complicadas sendo adicionadas para permitir que ele se integre de alguma forma em todas as plataformas, com alguns hacks e soluções alternativas. Claro que você pode usá-lo, mas você é muito limitado em quais controles você tem e quais APIs você pode usar. O principal problema é que ele tenta realizar a interface do usuário do Xaml com os controles nativos de cada plataforma. Isso é sempre problemático e deixa você com apenas um pequeno subconjunto de funcionalidades que funcionam em todas as plataformas.

O futuro seria usar o WinUI real e fornecer um renderizador real para cada plataforma, implementado no mecanismo 3D nativo da plataforma. Isso nos daria o conjunto completo de recursos, toda a bondade do WinUI, rodando com desempenho nativo, multiplataforma.

Na verdade, a Microsoft já tinha algo assim rodando muito bem: a UWP UI era baseada principalmente no código Silverlight, e a Microsoft tinha plugins Silverlight para todas as principais plataformas, o que significa que eles já possuem mecanismos básicos de renderização para todas essas plataformas. Eles não estão atualizados, pois agora o UWP tem muitas adições em comparação com o Silverlight. Mas é uma base que pode ser construída.

A Microsoft com certeza tem os recursos para fazer isso. Isso é o que as pessoas querem, e é isso que elas devem fazer.

C# pode desaparecer como XAML >

Definitivamente não concordo com esta afirmação sobre C#. C# é muito maior que XAML. Se você está seguindo o Blazor, saberá que isso não pode ser verdade. Eu vejo o Blazor como um divisor de águas para mim principalmente usando UWP/Xamarin e para desenvolvedores C# em geral visando especificamente usuários corporativos.

Seria bom ter WinUI x-platform, mas acho que o caminho mais fácil para a web /x-platform é o Blazor, especialmente agora que o Blazor também suporta classes parciais, o que significa que posso pegar a maior parte do meu código existente como está e começar a usá-lo em Blazor. Alguns soluços podem ser alternativas ao Sqlite , Shared Projects e ReactiveUI. Devo ser capaz de usar minha arquitetura MVVM existente e portá-la para o Blazor com bastante facilidade.

O obstáculo mais importante para mim é a falta de suporte ao .net core 3 em UWP. Acho fundamental para a MS alinhar Blazor + UWP na experiência do desenvolvedor. Eu sei que a equipe UWP está trabalhando nisso.

Além disso, gostaria de ver as páginas Blazor em aplicativos UWP / WInUI. O modelo de interface do usuário híbrida funcionaria muito bem para mim em aplicativos UWP para que eu possa usar os melhores ativos de interface do usuário disponíveis. (html5 versus XAML) e também não replicar meu esforço de interface do usuário entre UWP e Blazor onde faz sentido.

Atualmente Electron está usando Javascript, HTML + CSS. Não há razão para não usarmos Electron com Blazor => C# , HTML + CSS + gRPC

mas você é muito limitado em quais controles você tem e quais APIs você pode usar.

@lucasf Já experimentou o Uno? Você sabia que o Uno permite o uso de qualquer API nativa via Xamarin caso não haja uma API UWP adequada. Eu uso apenas algumas APIs nativas em meus aplicativos baseados em Uno, mesmo para meu aplicativo de streaming de vídeo em tempo real que usa codec de hardware e requer baixa latência.

mas você é muito limitado em quais controles você tem e quais APIs você pode usar.

@lukasf Você já experimentou o Uno? Você sabia que o Uno permite o uso de qualquer API nativa via Xamarin caso não haja uma API UWP adequada. Eu uso apenas algumas APIs nativas em meus aplicativos baseados em Uno, mesmo para meu aplicativo de streaming de vídeo em tempo real que usa codec de hardware e requer baixa latência.

@zipswich O conjunto de controles Xaml padrão no Uno é bem pequeno, nem perto do que UWP ou WinUI3 completos têm a oferecer. Para realizar UIs boas/complexas, você geralmente precisa incorporar controles e códigos de UI nativos específicos da plataforma adicionais. Então, no final, você se encontrará com uma mistura de várias plataformas de interface do usuário (Uno Xaml, Android nativo, iOS nativo, talvez Windows nativo ou WebAssembly). Isso não é o que eu chamo de uma ótima experiência de desenvolvedor.

Se tivéssemos renderizadores nativos da plataforma x para WinUI, teríamos apenas uma única interface do usuário com o conjunto completo de recursos do WinUI, sem nenhum tipo de coisa específica da plataforma. E o WinUI renderizaria diretamente na GPU com desempenho total, exatamente como você esperaria. Não há necessidade de adicionar controles extras do Android ou controles extras do iOS. É assim que o desenvolvimento da x-plataforma deve ser.

O que está faltando no WinUI (e como ele pode ser melhorado) para convencer os gerentes de programa da Microsoft para o Microsoft Teams a mudar do ElectronJS para o WinUI/UWP?

Ótima pergunta. Um grande número de usuários ficará muito feliz se fizer isso.

Um grande fator é a falta de medidas de desempenho comparando frameworks. Uma página que compara aplicativos equivalentes feitos em UWP e Electron e compara velocidade e uso de memória seria suficiente. Isso pode se estender a outros frameworks. A partir desses custos para os usuários, os efeitos no uso e os benefícios da consolidação de código podem ser avaliados em relação aos custos financeiros.

A atual falta dessa pesquisa está ajudando os frameworks ineficientes a se tornarem populares.

Falando honestamente: duvido que a MS tenha planos de tornar o "WinUI" ( Windows UI) multiplataforma. Além disso, o fato de agora ser de código aberto geralmente significa que a Microsoft não a considera mais uma tecnologia crítica/estratégica. Eles estão tentando explorar os recursos da comunidade em vez de diminuir o número de funcionários internos, mantendo-os vivos. Não me entenda mal, estou feliz que o WinUI seja de código aberto agora e aprecio todo o tempo que os desenvolvedores da Microsoft estão dedicando à plataforma levando-o para o WinUI 3.0 - é um grande passo para consolidar a plataforma de apresentação do Windows para nativos e aplicativos gerenciados. Eu simplesmente não acho que a Microsoft veja o Windows como o futuro e não acho que eles estejam interessados ​​em torná-lo multiplataforma (é claro que é um erro deles se for verdade).

Uma verdadeira estrutura de desenvolvimento multiplataforma que não force os desenvolvedores a usar tecnologia abaixo da média é o que o mundo precisa. Parece que a maioria aqui concorda. O que isso significa em grande parte é:

• Uma biblioteca de controle e marcação (XAML) que pode renderizar exatamente como designs nativos de plataforma (precisamos apenas de estilos de controle para iOS, Android etc.)
• Precisa ser escrito em código gerenciado como o WPF. Apenas as camadas base em C++, os controles nunca devem ser nada além de C#.
• A renderização precisa ser feita com Metal/Vulcan/DirectX (não em cima de controles existentes como Uno)
• A entrada deve ser reimplementada em uma forma de plataforma X
• Acessibilidade é um grande problema que infelizmente é muito mais fácil de resolver usando a abordagem do Uno

Se é isso que queremos, o WinUI não vai fazer isso, eu acho. O fato e a maneira como é implementado nativamente (alguma camada COM/.net intermediária) significa que seria muito complicado usar essa plataforma cruzada. Em vez disso, temos UNO e Avalonia. Avalonia é a verdadeira luz no fim do túnel, mas eles não têm recursos. O que é mais ou menos possível agora é usar a tecnologia de renderização do Avalonia como backend para o WPF (a parte gerenciada). Isso nos daria uma verdadeira estrutura de interface do usuário multiplataforma em um curto período de tempo. O problema é que o WPF foi projetado para desktop e muito trabalho foi feito no UWP para tornar o WPF/Silverlight amigável para dispositivos do tamanho de telefones e entradas modernas de toque/interativa.

Sinceramente, acho que neste momento estaríamos melhor se todos nós apenas dermos dinheiro e contribuições de código na Avalonia. Há muito tempo pedimos à Microsoft uma interface do usuário multiplataforma e eles estão satisfeitos em mudar para tecnologias da Web. A Microsoft está até convertendo aplicativos UWP como XBox em tecnologias Electron e web agora. Os aplicativos também não estão sendo vendidos na Microsoft Store.

A ironia é que a Microsoft teve tanto sucesso no passado porque deu aos desenvolvedores as ferramentas necessárias para criar ótimos aplicativos. Isso atrai usuários e você tem um ciclo de feedback muito construtivo. Em algum momento isso foi esquecido. Agora os desenvolvedores estão recorrendo a tecnologias abaixo da média (HTML/CSS nunca foi originalmente projetado para aplicativos... foi para marcação de documentos!) superam em muito os sacrifícios em funcionalidade, integração de sistema e desempenho atualmente.

A ironia é que a Microsoft teve tanto sucesso no passado porque deu aos desenvolvedores as ferramentas necessárias para criar ótimos aplicativos. Isso atrai usuários e você tem um ciclo de feedback muito construtivo. Em algum momento isso foi esquecido. Agora os desenvolvedores estão recorrendo a tecnologias abaixo da média (HTML/CSS nunca foi originalmente projetado para aplicativos... foi para marcação de documentos!)

Bem dito. Além do BASIC, comecei a usar as IDEs da Microsoft do Quick C, depois do VC++... A Microsoft costumava evoluir, inovar de forma constante, consistente, um tanto previsível. Tentamos segui-lo, e parece seguir a tendência daqueles que deveriam nos seguir. Eu costumava dizer a estagiários de universidades de pesquisa de primeira linha para usar as tecnologias da Microsoft para aplicativos corporativos nos quais eles eram solicitados a trabalhar. Não havia resistência zero, e eles rapidamente pegaram as coisas da Microsoft. Eu tenho me perguntado se a Microsoft está olhando para o que as crianças gostam hoje em dia, então siga-as.

Os aplicativos também não estão sendo vendidos na Microsoft Store.

Verdade infelizmente. No entanto, culpo a pior loja de aplicativos (para usuários e editores), não as tecnologias de desenvolvimento. A proporção de downloads diários da versão UWP x Android de um aplicativo: 1:20 . Eles custam aproximadamente a mesma quantidade de esforço para desenvolver. Isto não é um exagero. Acabei de dar uma olhada nos dados de download de ontem. Se eu trabalhasse para um contador de feijão, seria demitido imediatamente por gastar tanto esforço na versão UWP que gera tão pouco retorno.

Verdade infelizmente. No entanto, culpo a pior loja de aplicativos (para usuários e editores), não as tecnologias de desenvolvimento.

@zipswich , sim, você tem um bom ponto. Eu estava apenas assumindo que a Microsoft vê internamente os números de vendas e assume (corretamente) que o ecossistema está morrendo. Isso os convence de que os tipos de tecnologias de desenvolvimento subjacentes de que estamos falando são obsoletos, então eles começam a investir e seguir outras direções. Na verdade, a maioria dos desenvolvedores de aplicativos da Microsoft pode ver a clara necessidade de uma estrutura multiplataforma que não seja escrita esquecendo os últimos 20 anos de avanço tecnológico da interface do usuário (o WPF realmente mudou o jogo quando apareceu).

Não precisamos apenas de plataforma cruzada: precisamos de algo que seja feito com linguagens e marcação poderosas/escaláveis ​​e que tenha um escopo significativo (destinado a aplicativos, bom catálogo de controle) desde o início. Acho que não podemos mais contar com a Microsoft para isso. Eles deixaram claro que veem maiores lucros gastando seu tempo/recursos em outras áreas.

Eu seria demitido imediatamente por gastar tanto esforço na versão UWP que gera tão pouco retorno.

Eu ouço você, eu fiz essa declaração com base no meu próprio aplicativo na Microsoft Store também.

@robloo Você tem alguns pontos positivos, mas eu realmente não te sigo. Aqui estão alguns pensamentos:

• A Microsoft também investiu muito esforço e recursos em outras estruturas de código aberto, como .NET Core, ASP.Net Core, EF Core. Obviamente, eles veem o futuro no desenvolvimento de plataforma cruzada de código aberto (pelo menos para aplicativos de servidor). Eles também colocam recursos na compilação AOT, para que o .NET Core também possa ser compilado para iOS e Android (onde JIT não é permitido). Então eu não posso seguir você dizendo que o WinUI está morto agora, só porque eles o tornam de código aberto. Quero dizer, pode ser verdade, mas se o seu único argumento for "porque eles o tornam de código aberto", isso não é muito convincente.

• Qt é um framework de interface do usuário multiplataforma, sendo implementado em C/C++ nativo. Possui renderizadores OpenGL/Direct3D acelerados por hardware, por isso parece o mesmo e tem ótimo desempenho em todas as plataformas. Nenhum código específico da plataforma é necessário, todos os controles são executados em todas as plataformas, incluindo iOS e Android. Então, por que não seria tecnicamente possível executar o WinUI no iOS e no Android, se o Qt pode fazer exatamente isso? O WinUI é implementado no WinRT, que é C++ nativo, assim como o Qt. Internamente, ele usa apenas algumas tecnologias COM (interface desconhecida mais o sistema de fábrica COM). Não deve ser muito difícil abstrair isso ou reimplementar o que é necessário para outras plataformas. Eu não acho que qualquer código COM seja usado diretamente no código WinUI.

• Silverlight usou a mesma tecnologia e estava disponível na plataforma x.

• O Windows ainda é o SO de desktop número 1, muito usado, não apenas em casa, mas também (especialmente) pelas empresas. Combinado com as licenças do Office, gera muita receita sólida para a Microsoft. Eles perderiam essa receita se deixassem todas as principais plataformas de desenvolvimento de interface do usuário morrerem. WinForms e WPF já estão mortos, então WinUI é a única plataforma de UI ativa no Windows. Eu não acredito que eles querem se livrar do sistema Windows/Office/Enterprise completo, então eu não acredito que eles querem se livrar do WinUI.

• Tornar o código aberto do WinUI é ótimo para desenvolvedores, não apenas para a Microsoft.

• Pode ser que UWP vai morrer. Muitos desenvolvedores evitam isso por causa de todas as limitações estúpidas. A Windows Store não é remotamente bem-sucedida. O Windows Phone está morto, que foi o principal motivo para iniciar toda a coisa UWP.

• Trazer o WinUI para aplicativos de desktop com o WinUI 3.0 e torná-lo de código aberto pode ser o passo para salvá-lo, não para matá-lo!

Eu estava apenas assumindo que a Microsoft vê internamente os números de vendas e assume (corretamente) que o ecossistema está morrendo. Isso os convence de que os tipos de tecnologias de desenvolvimento subjacentes de que estamos falando são obsoletos, então eles começam a investir e seguir outras direções.

@robloo Não precisa ser o caso. Eu tenho dito o tempo todo que é a pior loja de aplicativos que matou o Windows Phone, a melhor plataforma móvel.

Eles podem matar dois coelhos com uma cajadada só: terceirizar a loja para um terceiro competente e acabar com o pesadelo dos .Net Native. Isso reduzirá seu custo e (acredito) dobrar, quadruplicar... downloads de aplicativos do Windows rapidamente. Mais de 90% dos meus problemas com aplicativos UWP estão relacionados exclusivamente ao pesadelo do .Net Native.

@lukasf Acho que você interpretou mal muito do que eu estava dizendo.

Eu não posso seguir você dizendo que o WinUI está morto agora, só porque eles o tornam de código aberto.

Eu nunca diria que o WinUI está morto. Eu disse que a Microsoft provavelmente não o vê mais como um produto crítico/estratégico de longo prazo. Eles veem lucros mais altos em outras áreas (serviços e nuvem), portanto, certificam-se de gastar seu tempo onde há lucros mais altos para os acionistas. Isso significa que acho que eles não aumentarão significativamente o WinUI para torná-lo multiplataforma e apenas mantê-lo vivo , o que fiz questão de dizer em vez de "morto". (Eu não sou alguém no UWP/WinUI é um movimento morto). Eu também sinto fortemente que a Microsoft está fazendo uma grande coisa com o WinUI 3.0 que eu afirmei. Está permitindo que todo o Windows, nativo e gerenciado do win32, seja consolidado com uma estrutura de interface do usuário.

Então, por que não seria tecnicamente possível executar o WinUI no iOS e no Android

Tudo é tecnicamente possível. Eu estava dizendo que seria extremamente difícil, pois foi projetado e implementado exclusivamente para o Windows. Eu também dei o exemplo de como ele se comunica com o código gerenciado como algo que acho que seria muito complicado de ser multiplataforma. Seria bom para todos nós se eu estivesse errado aqui.

Silverlight usou a mesma tecnologia e estava disponível na plataforma x.

E o Silverlight está morto não porque não fosse tecnicamente possível, mas porque não era mais um bom caso de negócios, que é realmente meu ponto mais crítico. Observe que ele também morreu para as mesmas tecnologias HTML/CSS/JS que agora assumem o desenvolvimento para desktop e dispositivos móveis.

Eles perderiam essa receita se deixassem todas as principais plataformas de desenvolvimento de interface do usuário morrerem.

Isso provavelmente poderia ser discutido de várias maneiras diferentes, mas provavelmente fica totalmente fora do escopo do tópico rapidamente (o que eu sei que já estou fazendo). Resumindo, é claro que a Microsoft não deixará todas as plataformas de interface do usuário do Windows morrerem. Você ainda tem que escrever aplicativos para Windows... Eu nunca disse o contrário.

Tornar o código aberto do WinUI é ótimo para desenvolvedores, não apenas para a Microsoft.

Eu disse "Estou feliz que o WinUI seja de código aberto agora e aprecio todo o tempo que os desenvolvedores da Microsoft estão colocando na plataforma levando-o para o WinUI 3.0 " A intenção era transmitir meu sentimento de que também acho que o código aberto é ótimo para vários de razões que eu não toquei. Como exemplo, mesmo a Plataforma Uno agora tendo acesso à fonte é ótimo como eles afirmaram na UnoConf.

Pode ser que UWP vai morrer.

Espera, de que lado você está? haha. Mas sério, considero o WinUI/UWP essencialmente a mesma coisa e o UWP terá apenas uma pequena evolução no WinUI sem grandes problemas para os desenvolvedores.

Trazer o WinUI para aplicativos de desktop com o WinUI 3.0 e torná-lo de código aberto pode ser o passo para salvá-lo, não para matá-lo!

Concordo com você e nunca quis dizer o contrário. Eu estava olhando para algumas tendências mais amplas e também falando sobre levá-lo a uma plataforma cruzada.

@zipswich

Eles podem matar dois coelhos com uma cajadada só: terceirizar a loja para um terceiro competente e acabar com o pesadelo dos .Net Native. Vai reduzir o custo deles e (acredito) dobrar, quadruplicar.

A boa notícia é que a Microsoft já decidiu matar o .net nativo. Tecnicamente, ele tinha uma série de restrições ridículas que não seguiam as especificações .net com as quais parece que você está mais do que familiarizado. Eu acho que foi algo que foi feito rápido / sujo para corrigir problemas de inicialização e desempenho no Windows Phone e eles nunca se preocuparam em voltar e consertar as coisas desde que o Windows Phone morreu.

Agora, a Microsoft está desenvolvendo uma compilação AOT completa e de alto desempenho usando tecnologias Mono e LLVM. Isso deve sair no próximo ano, eu acho, e também é útil para Blazor do lado do cliente com webassembly. Miquel de Icaza fez uma boa apresentação tocando no assunto no início deste ano na UnoConf: https://www.youtube.com/watch?v=tYk2us6W6Gg (ele é o primeiro apresentador).

@robloo Ok, talvez eu tenha entendido errado em alguns pontos.

Então, por que não seria tecnicamente possível executar o WinUI no iOS e no Android

Tudo é tecnicamente possível. Eu estava dizendo que seria extremamente difícil, pois foi projetado e implementado exclusivamente para o Windows. Eu também dei o exemplo de como ele se comunica com o código gerenciado como algo que acho que seria muito complicado de ser multiplataforma. Seria bom para todos nós se eu estivesse errado aqui.

Silverlight usou a mesma tecnologia e estava disponível na plataforma x.

E o Silverlight está morto não porque não fosse tecnicamente possível, mas porque não era mais um bom caso de negócios, que é realmente meu ponto mais crítico. Observe que ele também morreu para as mesmas tecnologias HTML/CSS/JS que agora assumem o desenvolvimento para desktop e dispositivos móveis.

Meu ponto aqui é: Silverlight já estava rodando multiplataforma. Pode ser usado com código gerenciado. A camada UWP Xaml UI do Windows 8 era basicamente Silverlight, apenas com um novo namespace e alguns metadados adicionados. Até agora ele evoluiu, mas no início era claramente apenas Silverlight Xaml com um novo namespace. Portanto, se eles pudessem executar a plataforma cruzada Silverlight naquela época, eles também poderiam executar a plataforma cruzada WinUI. E não acredito que isso seja "extremamente difícil", mas prefiro dizer que seria bastante fácil para uma grande empresa como a Microsoft. Eles já tinham uma camada de renderização multiplataforma para Silverlight Xaml. Não deve ser muito difícil atualizá-lo para que ele possa executar o WinUI mais recente.

Pode ser que UWP vai morrer.

Espera, de que lado você está? haha. Mas sério, considero o WinUI/UWP essencialmente a mesma coisa e o UWP terá apenas uma pequena evolução no WinUI sem grandes problemas para os desenvolvedores.

O WinUI é apenas uma camada de interface do usuário Xaml, enquanto o UWP é uma estrutura de aplicativo completa e uma camada de API do sistema, vinculada à Windows Store e com muitas limitações em comparação com os aplicativos de desktop clássicos. Então são duas coisas muito diferentes. Eu realmente não sei se a Microsoft vê um futuro na UWP e na Windows Store. Não corrigir as limitações severas da UWP e não trabalhar realmente nos problemas da Windows Store não me deixa muito otimista. Mas eles definitivamente precisam de algum tipo de estrutura de interface do usuário, e isso será WinUI, não importa se usado de UWP ou de aplicativos de desktop. E se eles realmente querem que seja bem-sucedido, eles devem torná-lo multiplataforma. Caso contrário, as pessoas irão para outras estruturas e, em algum momento, também poderão deixar a plataforma Windows completamente. Tornar o WinUI multiplataforma seria um meio de fazer com que os desenvolvedores se apeguem ao Windows.

Meu ponto aqui é: Silverlight já estava rodando multiplataforma. Pode ser usado com código gerenciado. A camada UWP Xaml UI do Windows 8 era basicamente Silverlight, apenas com um novo namespace e alguns metadados adicionados. Até agora ele evoluiu, mas no início era claramente apenas Silverlight Xaml com um novo namespace. Portanto, se eles pudessem executar a plataforma cruzada Silverlight naquela época, eles também poderiam executar a plataforma cruzada WinUI. E não acredito que isso seja "extremamente difícil", mas prefiro dizer que seria bastante fácil para uma grande empresa como a Microsoft. Eles já tinham uma camada de renderização multiplataforma para Silverlight Xaml. Não deve ser muito difícil atualizá-lo para que ele possa executar o WinUI mais recente.

Eu não sabia que a história da base do Silverlight sendo usada para UWP/Win8 naquela época, se for esse o caso, definível me deixa mais otimista sobre o quão viável isso é. Obrigado pela correção!

O WinUI é apenas uma camada de interface do usuário Xaml, enquanto o UWP é uma estrutura de aplicativo completa e uma camada de API do sistema, vinculada à Windows Store e com muitas limitações em comparação com os aplicativos de desktop clássicos. Então são duas coisas muito diferentes.

Sim, você está certo e eu deveria ter escolhido minhas palavras com mais cuidado. Certamente UWP no modelo de aplicativo e empacotamento continuará existindo por enquanto. No entanto, a camada da interface do usuário mudará para o WinUI, que é o que eu estava tentando comunicar. Acho que haverá mais mudanças nos próximos anos com a substituição do .net nativo, mas o empacotamento/modelo de aplicativo/APIs introduzidos com UWP ainda existirão de alguma forma. Eu definitivamente concordo que a Microsoft pode não ver um futuro aqui. Felizmente, desde que o XAML e o C# ainda estejam lá, a migração para um novo modelo de aplicativo ou empacotamento/distribuição geralmente é relativamente rápida. Se ao menos Avalonia tivesse terminado...

E se eles realmente querem que seja bem-sucedido, eles devem torná-lo multiplataforma. Caso contrário, as pessoas irão para outras estruturas e, em algum momento, também poderão deixar a plataforma Windows completamente. Tornar o WinUI multiplataforma seria um meio de fazer com que os desenvolvedores se apeguem ao Windows.

Também concordo com você 100% e já disse o mesmo em vários lugares. Cheguei à conclusão de que, por uma série de razões, isso não vai acontecer.

Eu não posso discordar fortemente o suficiente com os comentaristas dizendo:

WinUI 3.0 deve ser multiplataforma!

1) Precisamos de uma estrutura de interface do usuário agora, não em outros N anos, quando o projeto teórico multiplataforma estiver estável.
2) Precisamos de uma estrutura de interface do usuário o mais próxima possível do sistema operacional. Com multiplataforma, há sempre uma troca. Ou menor denominador comum para funcionalidade ou renderização de controle inconsistente devido à renderização personalizada.

A solução, na minha opinião, é ter outra estrutura que se baseie no WinUI 3.0 (se você quiser manter o Fluent e tiver pouco trabalho em renderização, teste de acerto, etc.), ou desde o início com WinUI Composition se você deseja desempenho máximo e não se importa em fazer toda a renderização e testes de acerto (com o custo potencial de não ser consistente).

Lembro-me de ter visto essas linhas alguns dias atrás:
"O sistema operacional não é mais a camada mais importante para nós... O mais importante para nós é o modelo do aplicativo e a experiência."
Portanto, é óbvio que o WinUI deve ser a melhor experiência de GUI, e acho que será, como o melhor do WPF, UWP e Windows 10,

Mas é óbvio que a Web e seu antigo javaScript+HTML estão sendo usados ​​em todos os lugares, e suas estruturas e pilhas da Web estão sendo usadas massivamente, não porque sejam melhores, mas porque estão prontamente disponíveis no navegador da Web do telefone e no navegador da Web do desktop. Você pode criar um arquivo HTML no Bloco de Notas, colocar uma tag Script com um alert('Hello World'); e você tem um aplicativo.

Então vejo que é possível e até necessário substituí-lo por .NET+XAML usando WebAssembly. Precisamos que o .NET seja tão onipresente quanto o javaScript é hoje.

O Silverlight foi uma luz de esperança... e agora com o WebAssembly, vejo que é possível o retorno do Silverlight.

Eu ficaria feliz com isso:
WinUI sendo a GUI completa do sistema operacional e pelo menos um subconjunto de seu XAML capaz de ser executado no WebBrowser.

Portanto, vejo a equipe da UNO como muito importante e espero que eles se juntem à Microsoft em um futuro próximo para unir forças nesse esforço maravilhoso que é o WinUI.

@MarkIngramUK Yesssss

Faça do WinUI a melhor escolha de interface do usuário para qualquer pessoa que esteja considerando o desenvolvimento nativo do Windows. Terminar:

• Validação de entrada e um controle de datagrid nativo
• As outras ~170 propostas de recursos aqui
• Os outros ~300 ingressos abertos
• .NET Native > Migração do .NET Core (para .NET Core 3+5, .NET Standard 2.1+ e C# 8...)
• Novo compilador AOT
• Obtenha diretrizes de design fluente mais coerentes liberadas e publicadas
• Refinar o sistema de estilo/tema
• Não enfatize os recursos de composição que distraem (inclinação, uso pesado de acrílico, revelação) e concentre-se mais no sistema e nas animações de profundidade + sombra (que trazem clareza e guiam os usuários)

Estas são as coisas que tornarão o WinUI mais atraente para as pessoas que o consideram versus o Electron no futuro.

A cereja do bolo seria então:

• Ferramenta(s) para ajudar a manter seu estilo CSS <-> XAML sincronizado
• Diretrizes para manter a lógica do aplicativo separada das exibições para reutilização máxima de código .NET em outras plataformas
• Alguma ferramenta para gerar uma tradução aproximada de HTML > controles XAML para que os desenvolvedores comecem com seus aplicativos WinUI nativos (em vez de assumir que a maioria dos desenvolvedores começará com aplicativos XAML e o desejo de seguir para HTML)

2. We need a UI framework that is as close to the OS as possible. With cross-platform, there is always a trade off. Either lowest common denominator for functionality, or inconsistent control rendering due to custom rendering.

@MarkIngramUK Silverlight era multiplataforma, cheio de recursos e renderizado exatamente da mesma forma em todas as plataformas. O Qt é multiplataforma, cheio de recursos e renderiza exatamente o mesmo em todas as plataformas. Você só obtém renderização inconsistente e controles de menor denominador comum se tentar realizar seus controles traduzindo-os internamente para controles nativos de uma plataforma diferente (que é o que o Xamarin e o Uno tentam fazer). Se você fizer a abstração não no nível de controle, mas no nível mais baixo (a camada de renderização da GPU), poderá obter 100% a mesma saída em todas as plataformas com o conjunto de controle completo. O conjunto de controle já está lá, é o WinUI 3.0, e é ótimo até agora. A única coisa que está faltando são as implementações de camadas de renderização para as outras plataformas (e elas podem ser parcialmente tiradas de fontes antigas do Silverlight).

Eu realmente gostaria de fazer desenvolvimento de aplicativos multiplataforma. Mas nem Xamarin nem Uno parecem atraentes para mim e eu realmente não gosto de JS/HTML e tudo que é baseado nele. Infelizmente, desenvolver exclusivamente para a Windows Store é uma má escolha se você pretende realmente ganhar dinheiro com isso. Pelo menos eu tive experiências bastante ruins com isso, e depois que a Microsoft matou o ecossistema do Windows Phone, eu mais ou menos acabei com isso (apesar de alguns pequenos projetos "apenas por diversão"). Eu começaria instantaneamente a trabalhar em novos aplicativos novamente se o WinUI fosse multiplataforma.

Todos os frameworks multiplataforma atuais têm limitações mais ou menos severas e/ou uma experiência de desenvolvimento ruim. Se a Microsoft pudesse tornar o WinUI multiplataforma, realmente poderia ser uma tecnologia inovadora. O Xamarin já é bastante bem-sucedido, apesar de todas as suas arestas, cantos e limitações. Imagine o quão bem-sucedido o WinUI poderia ser se ele fosse executado em todas as plataformas com um conjunto completo de recursos e a experiência de desenvolvimento de alto nível do Visual Studio.

@lukasf , este é o meu ponto:

O Silverlight era multiplataforma, cheio de recursos e renderizado exatamente da mesma forma em todas as plataformas.

Eu não quero a mesma renderização em todas as plataformas. Quero que cada aplicativo pareça consistente com outros aplicativos na plataforma de destino. É por isso que os controles nativos precisam ser agrupados - mas isso leva ao menor denominador comum.

@MarkIngramUK Eu vejo assim: aplicativos simples seguem os controles de interface do usuário de uma plataforma. Ótimos aplicativos têm sua própria aparência. Eles não precisam de controles de plataforma de ações. Veja Spotify, Netflix ou outros aplicativos excelentes e bem-sucedidos disponíveis para várias plataformas. Você não pode dizer a plataforma que eles usam, apenas observando seus controles.

Eu gostaria que meus aplicativos multiplataforma tivessem a mesma aparência em todas as plataformas.

@MarkIngramUK Que bom que você está abordando a realidade além da teoria. Aqui está a realidade para mim: eu tenho um monte de aplicativos que evoluíram de SL/WP > WinRT > UWP que precisavam ter como alvo várias plataformas ontem. Eu dei uma olhada no Phonegap/Cordova e passei muito tempo explorando o Xamarin muito a sério, e acabei desistindo. Eu me apaixonei pelo Uno por vários motivos assim que comecei a usá-lo. Neste momento não conheço nenhuma outra tecnologia de plataforma X promissora e prática amigável para C# e Xaml que eu possa usar agora . Quando o WinUI evoluir para uma API de plataforma X 1, 2 ou 3 anos depois, o pessoal de alto nível do Uno migrará o Uno de UWP para WinUI, e todos os meus aplicativos baseados em Uno poderão migrar de acordo e rapidamente. Não tenho nada com que me preocupar agora.
De forma alguma, sou contra intrigantes discussões teóricas aqui. Adoro ouvir todos os tipos de ideias.

O WinUI / MS não pode aproveitar o projeto Blazor para renderizar o WinUI como um aplicativo "Blazor Native"?

Eu sei que Steve Sanderson apresentou o Blutter onde o Flutter do Google pode ser renderizado usando o Blazor (e essa é uma interface do usuário baseada em XML). Parece que a equipe do Blazor tem uma boa tecnologia no lado da renderização da interface do usuário para alavancar diferentes estruturas de interface do usuário. Se o Blazor puder lidar com o Flutter, ele deverá ser capaz de lidar com um equivalente do tipo WinUI / Sillverlight.

O potencial é um ecossistema MS menos fragmentado e muito mais poderoso, começando na web e terminando com aplicativos nativos x-plataforma usando um .net 5 unificado.

@lukasf :

@MarkIngramUK Eu vejo assim: aplicativos simples seguem os controles de interface do usuário de uma plataforma. Ótimos aplicativos têm sua própria aparência. Eles não precisam de controles de plataforma de ações. Veja Spotify, Netflix ou outros aplicativos excelentes e bem-sucedidos disponíveis para várias plataformas. Você não pode dizer a plataforma que eles usam, apenas observando seus controles.

Eu gostaria que meus aplicativos multiplataforma tivessem a mesma aparência em todas as plataformas.

Combinamos ambas as abordagens para nossos aplicativos (https://affinity.serif.com). Nossos clientes podem ser bastante expressivos se não adotarmos padrões de plataforma comuns, por exemplo, ordenação de botões nas caixas de diálogo (o Windows normalmente é OK e Cancelar, enquanto o macOS é Cancelar e OK), botões com cantos arredondados, estados de foco, caixas de seleção versus interruptores, layout de controles etc. Então, sim, na superfície, nossos aplicativos têm a mesma aparência nas plataformas Windows e macOS, mas temos diferenças sutis (renderização e interação com a interface do usuário). Também aproveitamos ao máximo nossa plataforma host usando suas APIs nativas e, portanto, nunca estamos sujeitos a problemas de menor denominador comum.

Ainda acho que a discussão acima é enganosa, o WinUI é a estrutura de interface do usuário de nível mais baixo que a Microsoft fornece. Se você deseja uma biblioteca multiplataforma, crie em cima disso. É o equivalente a dizer: "O Win32 deve ser multiplataforma!". Não, o Win32 deve ser o melhor framework para a plataforma Windows. É o mesmo argumento aqui, o WinUI deve ser a melhor estrutura para a plataforma Windows 10.

@MarkIngramUK escreveu:

WinUI é a estrutura de interface do usuário de nível mais baixo que a Microsoft fornece. Se você deseja uma biblioteca multiplataforma, crie em cima disso.

Isso me parece uma solução prática que pode realmente ter sucesso, dependendo dos detalhes (embora não necessariamente a única solução). Duas camadas:

1. Microsoft WinUI: Não é multiplataforma.
2. Microsoft CrossXYZ-UI: plataforma cruzada. Sua implementação interna para Windows seria escrita usando WinUI.

Essa solução de 2 camadas ajudaria a mitigar o problema que mencionei na minha mensagem original:

Possivelmente novas versões do WinUI podem ser substancialmente atrasadas devido ao aumento da quantidade de trabalho/dificuldade de manter o suporte para vários sistemas operacionais diferentes. Por exemplo, "Poderíamos ter lançado esta nova versão do WinUI já, meses atrás, exceto pelo problema de que terminamos de depurá-lo apenas para Windows e ainda não para Android, MacOS ou Apple iOS".

De acordo com minha experiência com desenvolvimento multiplataforma no passado, eu observaria que essa solução de 2 camadas seria mais bem-sucedida se várias alterações/adições fossem implementadas no WinUI com a finalidade de apoiar e auxiliar a plataforma cruzada separada "CrossXYZ -UI". Caso contrário, se o WinUI não fizer nada para ajudar a camada multiplataforma, então, na minha experiência, isso geralmente significa que a camada multiplataforma é muitas vezes forçada a passar por aros contorcidos que dificultam a programação e a confiabilidade e atrasam.

De acordo com a teoria de camadas, o WinUI não precisa conhecer ou se preocupar com uma camada "CrossXYZ-UI" que usa o WinUI, mas essa teoria funciona mal na prática no mundo real, portanto, digo que o WinUI precisaria levar em conta e ajudar a camada "CrossXYZ-UI", mas não me refiro à idéia horrível de criar dependências em "CrossXYZ-UI" dentro do WinUI, e não me refiro a ganchos privados especiais dentro do WinUI que são usados ​​apenas por "CrossXYZ-UI ". As 2 camadas ainda devem ser mantidas separadas de maneira limpa. Estou apenas dizendo que, quando as decisões de design da API são tomadas para o WinUI, essas decisões precisam ser executadas levando em consideração seu impacto na camada "CrossXYZ-UI" separada e considerando como o WinUI pode facilitar a vida do " CrossXYZ-UI", não apenas considerando aplicativos que usam diretamente o WinUI.

Não sei se o Xamarin já tenta operar da maneira de 2 camadas descrita acima, mas se isso acontecer, imagino que atualmente exclua a parte da ideia em que o WinUI suporta/ajuda a camada de plataforma cruzada separada. É difícil confiar no Xamarin quando a Microsoft não confia no Xamarin o suficiente para usá-lo no Microsoft Teams e em vários outros aplicativos da Microsoft.

No passado, publiquei software multiplataforma que funcionava com sucesso e bom desempenho, mas acabei cancelando o trabalho multiplataforma por motivos não técnicos. Por exemplo, os clientes que usam a versão Linux do software insistiram que o preço do software deveria ser $0. Assim, o custo de produção e manutenção da versão Linux excedeu em muito o $ 0 de receita dos "clientes" usando Linux, portanto, era obviamente insustentável.

Como desenvolvedor de aplicativos, só porque você _pode_ teoricamente produzir um aplicativo multiplataforma, nem sempre significa que você _deveria_. Curiosamente, noto em discussões multiplataforma hoje em dia que as pessoas mencionam o Android, mas não o Linux mais. Uma das maiores razões para essa mudança é provavelmente o problema de $ 0 mencionado acima.

Plataforma Re Uno:

Mesmo que o Uno tenha um design e implementação técnicos sólidos e confiáveis, o risco e a preocupação é que o Uno desapareça dentro de alguns anos devido a um problema semelhante de $ 0 ou renda insuficiente que eventualmente desencadeie o esgotamento e o cancelamento ou estagnação do projeto. Ou simplesmente o desenvolvedor mais importante do Uno um dia de repente obtendo um novo hobby/interesse/obsessão e perdendo o interesse no Uno, ou um novo emprego/empregador e não mais tempo para trabalhar no Uno. Como @mdtauk disse:

muitas empresas que procuram investir na construção de um aplicativo ou sistema, precisam saber que a plataforma para a qual estão desenvolvendo tem o suporte e a longevidade de uma grande empresa com vastos recursos como a Microsoft.

Eu também concordo com o outro comentário de @mdtauk :

O problema com esse argumento é que a última década mostrou a Microsoft abandonando plataformas,

Sim A Microsoft perdeu algum grau de reputação/confiabilidade/confiabilidade por meio do cancelamento de plataformas. Acho que a Microsoft precisa ter cuidado para evitar mais perda de reputação e confiabilidade por meio de novos cancelamentos. Uma nova versão de uma plataforma existente é melhor do que uma nova plataforma.

Mesmo que uma nova versão importante de uma plataforma existente precise introduzir alterações importantes, ainda é melhor (ou menos ruim) do que uma nova plataforma com perda de reputação/confiabilidade/confiabilidade. Para os desenvolvedores de aplicativos, o custo de mudar para uma nova plataforma é muito alto e às vezes completamente inacessível, portanto, sempre que a Microsoft cancela uma plataforma, é uma notícia muito ruim e prejudica o relacionamento/parceria entre o desenvolvedor do aplicativo e a Microsoft.

Se vocês acham essa abordagem de duas camadas tão atraente, podem continuar agora e usar Xamarin ou Uno. Você não precisa esperar por esses frameworks, eles já estão lá e funcionam muito bem. Mas você perderá todos os benefícios e melhorias do WinUI assim que segmentar o Android ou iOS. Sem mais NavigationView, sem AppBars, sem SemanticZoom, etc etc. Qualquer coisa que seja feita neste repositório, todas as melhorias não estão disponíveis em plataforma cruzada, porque plataforma cruzada significa menor denominador comum. Você só pode usá-los se tiver como alvo especificamente a plataforma Windows. Então você terá que reimplementar todas as coisas legais do WinUI novamente manualmente, usando controles nativos do Android ou iOS.

Se isso soa bem para você, basta usar Xamarin ou Uno. Não há necessidade de uma terceira estrutura como esta. Mas para mim isso não soa nada bem. Eu quero um framework com um ótimo conjunto de controles, que possa ser usado para direcionar todas as plataformas diretamente, com funcionalidade completa em todas as plataformas. Não quero reimplementar a navegação e outras coisas do meu aplicativo em cada plataforma separadamente, tendo definições de interface do usuário complicadas e duplicadas. Para mim, isso soa como uma ideia horrível. Se o WinUI fosse multiplataforma usando a abordagem de renderizador, eu poderia usar diretamente todos os seus recursos e todas as melhorias aqui em todas as plataformas. E se eu quiser que meus controles se pareçam mais com o iOS nesse destino, eu poderia simplesmente aplicar um iOS ResourceDictionary. Problema resolvido, sem ter que mexer com controles nativos e implementações de UI duplicadas.

O argumento de que os lançamentos seriam adiados porque um "renderizador para outra plataforma não foi atualizado" é um argumento irreal. Uma camada de renderização funciona em comandos de desenho de baixo nível como "desenhar retângulo, desenhar linha, desenhar texto". Se você adicionar um novo controle ao WinUI, você escreve sua lógica de controle e fornece um modelo de controle, que usa Grid, Borders, TextBoxes e coisas assim. Nenhum novo controle exigirá atualizações nos renderizadores, os renderizadores serão de nível muito baixo e com taxa de alterações muito baixa. Existem apenas casos raros em que os renderizadores precisam ser tocados, por exemplo, ao adicionar novos pincéis ou efeitos. O Qt usa a abordagem de renderizador e é um dos frameworks de interface do usuário multiplataforma mais populares. A abordagem parece funcionar muito bem para eles.

@lukasf

Eu quero um framework com um ótimo conjunto de controles, que possa ser usado para direcionar todas as plataformas diretamente, com funcionalidade completa em todas as plataformas.

Cada engenheiro e cada dólar gasto fazendo o WinUI cross-plat é um engenheiro e cada dólar que poderia ter sido usado para tornar o WinUI no Windows melhor.

O argumento de que os lançamentos seriam adiados porque um "renderizador para outra plataforma não foi atualizado" é um argumento irreal.

Não é apenas uma tarefa simples criar um mecanismo de renderização 1:1 perfeito que funcione em iOS, Android, MacOS, Linux e Windows 7/8. Há um grande número de APIs do Windows 10 nas quais os aplicativos e a estrutura dependem. Você basicamente estaria criando uma estrutura de aplicativo completamente nova.

Além disso, veja este tópico recente do Reddit: O que devo usar para a interface do usuário em C #

Literalmente zero menções de WinUI e uma única meia recomendação para usar UWP. Os desenvolvedores precisam estar entusiasmados com o uso do WinUI no Windows muito antes de tentar torná-lo multiplataforma, considerando todos os enormes investimentos que seriam necessários.

@lukasf ,

você pode continuar agora e usar Xamarin ou Uno

Eu aludi a isso no meu post anterior, mas escrevemos front-ends separados para cada plataforma que segmentamos. Windows (WPF), macOS (Cacau), iOS (UIKit).

se eu quiser que meus controles se pareçam mais com o iOS nesse destino, eu poderia simplesmente aplicar um iOS ResourceDictionary. Problema resolvido

Até que o usuário atualize o sistema operacional e todos os aplicativos mudem de aparência, exceto o seu.

Uma camada de renderização funciona em comandos de desenho de baixo nível como ...

Você precisa de mais do que renderização para multiplataforma. Gerenciamento de janelas, entrada, manipulação de texto, renderização, integração de sistemas (por exemplo, Barra de Tarefas / Aero Peek etc). Não há como tentar alterar o foco do WinUI de apenas Windows para plataforma cruzada não causar um atraso extremo.

Em termos de renderização, o WinUI é construído em Windows.UI.Composition , então você teria que substituir completamente essa biblioteca de nível inferior por algo que fosse multiplataforma e, esperançosamente, não incorreria em nenhuma penalidade de desempenho de sua abstração e, em seguida, portar para outras plataformas. Ou reescreva completamente o WinUI para não depender de Windows.UI.Composition . Novamente, nenhum trabalho pequeno.

Apenas para reiterar - não sou contra bibliotecas multiplataforma. Eles servem a um propósito, só não acho que o WinUI deva se tornar um.

@lukasf

porque multiplataforma significa o menor denominador comum. ...... Eu quero um framework com um ótimo conjunto de controles, que possa ser usado para direcionar todas as plataformas diretamente, com funcionalidade completa em todas as plataformas.

Você quer isso com funcionalidade completa em todas as plataformas - eu também - parece maravilhoso; um sonho -- mas só porque você e eu queremos, não significa que deve ser possível e prático. O desejo e o resultado podem ser muito diferentes. O desejo pode ser a funcionalidade completa, enquanto o resultado acaba sendo principalmente o mesmo problema que você mencionou - menor denominador comum. Sua ideia tem mérito, mas não está imune a ser vítima do problema do menor denominador comum que você mencionou.

Se o WinUI fosse multiplataforma usando a abordagem de renderizador, eu poderia usar diretamente todos os seus recursos e todas as melhorias aqui em todas as plataformas.

Realmente TODOS os seus recursos e TODAS as melhorias em TODAS as plataformas? Você tem certeza de que um objetivo tão impressionante pode ser alcançado simplesmente baseando o WinUI em um renderizador multiplataforma? Tão fácil é a solução? Acho que você está fazendo a ideia parecer muito mais fácil do que é na realidade, porque na verdade é necessário muito mais do que o renderizador, como:

• Gerenciamento de janelas mais submenus, pop-ups, menus de contexto, diálogos modais.
• Gerenciamento e resoluções de exibição e resposta a alterações.
• Dispositivos de entrada (teclado, mouse, tela sensível ao toque com gestos, caneta).
• Animação.
• Fontes e estilos, obtendo informações e medidas, não apenas renderizando. Também processamento de texto unicode.
• Arraste e solte.
• Recortar/copiar/colar da área de transferência que funciona com vários formatos, não apenas texto.
• Rolagem com bom desempenho, ao contrário do péssimo desempenho de rolagem dos painéis de bate-papo no MS Teams.
• Lendo/carregando recursos (de vários tipos) armazenados dentro do pacote do aplicativo, como recursos de imagem e outros.
• Reprodução de áudio e vídeo.
• Automação para leitores de tela etc para acessibilidade.
• Tema/aparência consistente com o que está atualmente configurado no sistema operacional.
• Recuperação de várias configurações do SO que afetam a GUI, como formatação internacional, configurações de mouse e teclado, etc.
• Problemas para oferecer suporte a dispositivos móveis, tablets e desktops.
• E várias outras coisas além de centenas de detalhes que são facilmente esquecidos ao estimar o tamanho do projeto e a data de lançamento.

Ainda acho que sua ideia tem mérito, mas é muito mais difícil e muito menos clara do que você fez parecer. Também pode retardar muito o desenvolvimento e o progresso do WinUI.

O WinUI / MS não pode aproveitar o projeto Blazor para renderizar o WinUI como um aplicativo "Blazor Native"?

@pinox , sim, definitivamente poderíamos, mas o Blazor Native não seria multiplataforma, a menos que visasse o Uno (o que seria minha preferência pessoal).

A plataforma cruzada é definitivamente algo em que pensamos e fizemos algumas investigações bastante completas de diferentes arquiteturas de estrutura de plataforma cruzada. Chegamos às mesmas conclusões que todos neste tópico, que é que ambas as soluções têm prós e contras e que nossos clientes estão bastante divididos 😃

@lukasf Acho que o "menor denominador comum" que existe atualmente no Uno é um problema de limitação de recursos e não devido a camadas. Eu adoraria estar errado, mas acho que esse problema pode ser resolvido e não piorar no futuro.

Existe um subconjunto de XAML para oferecer renderização de controles e janelas de interface do usuário de aparência nativa - ou você pode possuir o renderizador no macOS, iOS, Android, Linux - e renderizar os mesmos controles e modelos "Fluent" em todas as plataformas.

Além de fazer algum tipo de variante da implementação CoreWindow / App Window para trabalhar com o sistema operacional nativo - tudo dentro da janela poderia ser renderizado.

No Windows é DirectX, mas a Apple tem Metal e Linux tem OpenGL. Os desenvolvedores teriam que fazer algum tipo de instrução IF para lidar com IO de arquivo nativo, notificações, etc - mas o Xamarin ajudaria com isso

@stevenbrix -- Vejo que você respondeu à ideia do @Pinox _"renderize o WinUI como um aplicativo nativo do Blazor",_ mas o que você acha da _outra_ ideia do Pinox? Curiosamente, @Pinox também escreveu:

Atualmente Electron está usando Javascript, HTML + CSS. Não há razão para não usarmos Electron com Blazor => C# , HTML + CSS + gRPC.

@Pinox - Eu concordo que "Electron C#" parece fazer muito mais sentido do que "Electron JS", mas se usar C# e Blazor como você sugeriu, acho que o aplicativo MS Teams provavelmente não precisaria do Electron mais porque Blazor substituiria completamente o Electron? Posso estar enganado - não sei o suficiente sobre quais recursos o Electron suporta. Embora, se o ElectronJS atualmente tiver algum recurso útil que o Blazor não tenha, esse recurso ausente poderá ser suportado na próxima versão do Blazor, potencialmente.

Então eu acho que você levantou um ponto importante ao mencionar Blazor. Uma solução decente para o aplicativo MS Teams pode ser mudar de ElectronJS para Blazor + WebAssembly. Isso é muito interessante.

Se o aplicativo MS Teams mudou de ElectronJS para Blazor, ele poderá ou não usar qualquer parte do WinUI. Uma conexão ou não conexão entre Blazor e WinUI pode ser explorada ainda mais, como você já começou a fazer. Interessante!

Silverlight, WinRT, UWP - foram todos abandonados. (Eu sei que o UWP não é tecnicamente, mas o WinUI provavelmente será visto como um substituto).

Meu entendimento é que UWP é o tempo de execução, enquanto WinUI é a camada GUI / widget / etc. Ou seja, Win UI será executado em Win32, ou .NET, sem a API UWP.

O que me deixa louco é que a UWP é na verdade uma API bastante competente. Não é tão poderoso quanto o Win32, mas comparado ao Android (por exemplo) é muito mais sensato. Acho que os desenvolvedores perderam o ponto de que agora existe uma API de tempo de execução unificada, que possui um modelo de objeto consistente, API, não é obtusa, etc, etc .... alguém aqui escreveu aplicativos Win32 nos anos 90 ou no início 00s antes do .NET entrar em cena? Usar as APIs da plataforma nativa foi terrível.

De volta ao problema em questão, eu adoraria ver a plataforma cruzada do WinUI. Há posts sobre ele estar vinculado ao COM etc... O framework do plugin Core Foundation da Apple (CFPlugin) é, IIRC, baseado em COM, então talvez um aumento e mudança seja tão simples quanto escrever um renderizador para plataformas Apple. O mais lógico seria disfarçar as diferenças de plataforma e manter os objetos WinUI de alto nível.

Eu adoraria ver um esforço coeso e multiplataforma da Microsoft, voltado principalmente para o Windows, mas comprou um modelo de objeto completamente compatível e dialeto XAML para dispositivos móveis, Linux e macOS. Já existe um fantástico ecossistema multiplataforma (menos uma GUI) no .NET Core. Junte-se a uma estrutura XAML competente e seria fácil para todo o desenvolvimento do lado do cliente, principalmente se os visuais pudessem parecer nativos. Por exemplo, CommandBar -> NSToolbar no Mac, Navigation View -> NSOutlineView no Mac, etc.

Meu 2c vale, mas vejo um grande foco nisso.

Também estou esperançoso (apesar de não prender a respiração) que a Microsoft volte a entrar no mercado com um telefone baseado em Windows. Ser um ambiente de plataforma cruzada convincente ajudaria enormemente esse objetivo.

Assistirei a esta discussão com interesse.

Silverlight, WinRT, UWP - foram todos abandonados. (Eu sei que o UWP não é tecnicamente, mas o WinUI provavelmente será visto como um substituto).

Meu entendimento é que UWP é o tempo de execução, enquanto WinUI é a camada GUI / widget / etc. Ou seja, Win UI será executado em Win32, ou .NET, sem a API UWP.

Tecnicamente, acho que o WinRT (Windows RunTime) é o tempo de execução, e o UWP (Plataforma Universal do Windows) é construído em cima desse tempo de execução. E a UWP oferece suporte ao uso de XAML como uma estrutura de interface do usuário.

WinUI será a parte XAML da UWP, mas expandida para permitir que seja usada com código Win32, com interoperabilidade por meio de ilhas XAML com as estruturas WPF e WinForms.

O que me deixa louco é que a UWP é na verdade uma API bastante competente. Não é tão poderoso quanto o Win32, mas comparado ao Android (por exemplo) é muito mais sensato. Acho que os desenvolvedores perderam o ponto de que agora existe uma API de tempo de execução unificada, que possui um modelo de objeto consistente, API, não é obtusa, etc, etc .... alguém aqui escreveu aplicativos Win32 nos anos 90 ou no início 00s antes do .NET entrar em cena? Usar as APIs da plataforma nativa foi terrível.

O UWP é construído com uma abordagem moderna para duração da bateria, segurança, identidade, validação de loja - tudo o que os desenvolvedores esperam de plataformas como macOS, iOS e Android. É por causa dessas qualidades inerentes que ele pode funcionar em muitos fatores de forma e tipos de dispositivos.

De volta ao problema em questão, eu adoraria ver a plataforma cruzada do WinUI. Há posts sobre ele estar vinculado ao COM etc... O framework do plugin Core Foundation da Apple (CFPlugin) é, IIRC, baseado em COM, então talvez um aumento e mudança seja tão simples quanto escrever um renderizador para plataformas Apple. O mais lógico seria disfarçar as diferenças de plataforma e manter os objetos WinUI de alto nível.

Quando você considera o suporte ao .NET Core, que já é compatível com várias plataformas, a camada de interface do usuário é a parte que está faltando. O WinUI inicialmente é totalmente focado no Windows, mas espero que, com o tempo, a Microsoft possa refatorá-lo de tal forma que as plataformas possam substituir sua própria renderização, o que permitiria que UI idênticas fossem executadas em várias plataformas.

Eu adoraria ver um esforço coeso e multiplataforma da Microsoft, voltado principalmente para o Windows, mas comprou um modelo de objeto completamente compatível e dialeto XAML para dispositivos móveis, Linux e macOS. Já existe um fantástico ecossistema multiplataforma (menos uma GUI) no .NET Core. Junte-se a uma estrutura XAML competente e seria fácil para todo o desenvolvimento do lado do cliente, principalmente se os visuais pudessem parecer nativos. Por exemplo, CommandBar -> NSToolbar no Mac, Navigation View -> NSOutlineView no Mac, etc.

Assim que você começar a olhar para ele dessa maneira, onde você está traduzindo controles e conceitos do Windows para Platform Native, você acaba com Xamarin Forms. Você visa uma abordagem de menor denominador comum, em vez de permitir que uma UI Identitcal seja executada em todos os lugares.

Meu 2c vale, mas vejo um grande foco nisso.

Também estou esperançoso (apesar de não prender a respiração) que a Microsoft volte a entrar no mercado com um telefone baseado em Windows. Ser um ambiente de plataforma cruzada convincente ajudaria enormemente esse objetivo.

Assistirei a esta discussão com interesse.

Acho que uma parte dessa história, ainda a ser detalhada, é permitir que aplicativos UWP sejam compilados e executados no Android - o que resolveria o problema de aplicativos executados no Surface Duo.

Havia o projeto Astoria... O Android no Windows Bridge, que poderia vir para o Windows para permitir que os aplicativos Android chegassem à Microsoft Store. Uma vez que a Microsoft tenha sua própria base de código Android, isso torna a perspectiva mais fácil de conceber.

Vejo que você respondeu à ideia do @Pinox "renderizar o WinUI como um aplicativo nativo do Blazor", mas o que você acha da outra ideia do Pinox? Curiosamente, @Pinox também escreveu:

Atualmente Electron está usando Javascript, HTML + CSS. Não há razão para não usarmos Electron com Blazor => C# , HTML + CSS + gRPC.

Eu concordo que "Electron C#" parece fazer muito mais sentido do que "Electron JS", mas se usar C# e Blazor como você sugeriu, acho que o aplicativo MS Teams provavelmente não precisaria mais do Electron porque o Blazor substituir completamente o Electron? Posso estar enganado - não sei o suficiente sobre quais recursos o Electron suporta. Embora, se o ElectronJS atualmente tiver algum recurso útil que o Blazor não tenha, esse recurso ausente poderá ser suportado na próxima versão do Blazor, potencialmente.

@verelpode como eu entendo, o Electron sempre precisará estar na foto. Se as equipes hipoteticamente mudassem para o Blazor, elas ainda iriam querer um aplicativo cliente autônomo como fazem hoje, e o Electron faz mais sentido para eles. Em teoria, e alguém pode me corrigir se estiver errado, mas mudar para Blazor + WebAssembly tornaria o desempenho do aplicativo muito melhor ao rodar no Electron. Embora eu aposto que seus problemas de desempenho são devido a problemas de arquitetura mais do que qualquer outra coisa, o VS Code é um aplicativo Electron e estou muito impressionado com o desempenho lá.

Tenha em mente que o WebAssembly também pode ser executado fora do WebBrowser...
Vejo o Blazor como um caminho daqueles vindos do ASP.Net, um experimento trazendo o .NET para o WebBrowser, mas o caminho mais completo seria XAML no .NET Core, Xamarin, UWP/WinUI e UNO; O XAML completo no WinUI/Windows 10 e uma parte de seu XAML também podem ser executados na Web.

@verelpode @stevenbrix Meu entendimento é que Blazor roda no fio em Electron. Então, diretamente do .net core para o Electron com o uso do gRPC. Portanto, o canal gRPC se comunica com o elétron e não mais com o renderizador JS que eu assumo. Por favor me corrija se eu estiver errado. Não há WASM envolvido.

Seria realmente interessante ver as melhorias de velocidade usando gRPC diretamente com o Electron. Na minha opinião, pode ser enorme se otimizado.

No clipe do youtube de Steve Sanderson, ele menciona o uso de não WASM (53:13 min em vídeo)
https://www.youtube.com/watch?v=uW-Kk7Qpv5U

Não me lembro onde li a parte do gRPC, de qualquer forma, para mim sondando a comunidade se algo como um equivalente do Silverlight ao WinUI usando gRPC com Electron é possível? Não WASM , no fio, por assim dizer.

@verelpode @stevenbrix Meu entendimento é que Blazor roda no fio em Electron. Então, diretamente do .net core para o Electron com o uso do gRPC. Portanto, o canal gRPC se comunica com o elétron e não mais com o renderizador JS que eu assumo. Por favor me corrija se eu estiver errado. Não há WASM envolvido.

Seria realmente interessante ver as melhorias de velocidade usando gRPC diretamente com o Electron. Na minha cabeça, pode ser enorme.

No clipe do youtube de Steve Sanderson, ele menciona o uso de nenhum WASM (53:13 min) no vídeo.
https://www.youtube.com/watch?v=uW-Kk7Qpv5U

Obrigado @Pinox! Parece que eu tenho alguma observação para fazer! O que você está descrevendo soa como o lado do servidor Blazor para mim, eu estava pensando/falando sobre o lado do cliente que roda no navegador e manipula diretamente o DOM. Eu não vou dizer mais até depois de ver esse vídeo, porque eu poderia estar colocando meu pé na boca dizendo essas coisas 😄

@stevenbrix você pode estar certo, mas o aplicativo electron é executado offline para mim, assumindo que isso não é renderização do lado do servidor.

Meu palpite seria se o renderizador JS usasse o gRPC para falar com o Electron, então você poderia usar o blazor razor engine para fazer o mesmo.

gRPC é um novo recurso do .net core 3.0. Suporte Blazor .net core 3.
Portanto, o gRPC no .net core 3 abre a possibilidade de substituir as tecnologias JS existentes por c# usando o "link comum" (gRPC). Movimento inteligente MS ;))

mas o aplicativo electron é executado offline para mim, assumindo que isso não é renderização do lado do servidor.

@Pinox - sim, isso me deixa um pouco confuso. Eu estou supondo que está usando https://github.com/ElectronNET/Electron.NET , mas isso é puramente especulativo

Se o aplicativo MS Teams mudou de ElectronJS para Blazor, ele pode ou não usar qualquer parte do WinUI. Uma conexão ou não conexão entre Blazor e WinUI pode ser explorada ainda mais, como você já começou a fazer. Interessante! >

@verelpode o que deixa essa imagem muito emocionante é o "alcance" do Blazor. Como um cara de aplicativos, posso dizer que minha experiência limitada com o Blazor até agora é => uau, isso parece extremamente performático, quase como um aplicativo. Olhando para a imagem, o roteiro quase certamente incluirá o WinUI como uma plataforma nativa. (embora não comprometido atualmente)

Se eles podem fazer o flutter funcionar no lado do Blazor Native, o que impede a equipe do Blazor de conectar a plataforma React Native para alcançar todas essas plataformas nativas. Blazor pode facilmente se tornar a cola para desenvolvedores C# em tudo.

Para mim, o objetivo de curto prazo é entrar no ônibus com uma interface do usuário HTML para complementar meu WinUI existente.
Entre WinUI / Xamarin e Blazor não há quase nada que eu não possa fazer. Uma base de código, 3 estruturas de interface do usuário. Vai ser extremamente emocionante ver onde isso vai, porque as opções parecem infinitas.

Para mim, o melhor é sempre o .net core de alto desempenho (C#) => Blazor ??? => UI's nativas - será o esforço final de engenharia.

Devo dizer que esta é uma discussão muito inspiradora! Muitas visões e argumentos diferentes, muitos fatos que eu nem sabia ("Blazor + Native UI?? Uau").

Como @stevenbrix já mencionou, parece haver uma divisão na comunidade entre aqueles que gostariam de executar exatamente a mesma interface do usuário em diferentes estruturas (abordagem do renderizador) e aqueles que gostariam de renderizar em cada plataforma usando os controles nativos. Ambas as abordagens têm suas vantagens e desvantagens. Concordo com @stevenbrix que, com mão de obra suficiente, o problema do "menor denominador comum" pode ser superado (por exemplo, um controle WinUI não disponível nativamente na plataforma X pode ser realizado internamente no Uno por vários controles nativos de nível inferior dessa plataforma X, ou com renderização personalizada parcial). Então poderíamos ter quase todo o conjunto de controle WinUI disponível, mas ainda obter renderização nativa. Infelizmente, os recursos do Uno parecem ser bastante limitados no momento, dado o grande número de problemas abertos em seu github.

O que é óbvio aqui é que há uma alta demanda na comunidade por uma estrutura atraente, de alto desempenho e multiplataforma. E nenhum dos frameworks atualmente disponíveis realmente satisfaz qualquer um dos dois lados da comunidade (dividida). Será muito interessante ver se a Microsoft tem planos para melhorar a situação.

Eu diria que, com o Surface Duo e o Neo no horizonte, a Microsoft deve apresentar uma história adequada de como desenvolver aplicativos multiplataforma que sejam executados no Surface Duo e no Surface Neo. Talvez a Microsoft deva comprar o Uno e financiá-los adequadamente, para que eles possam corrigir todos esses problemas em aberto e adicionar mais suporte ao controle. Ou desenvolva uma camada de renderização Android para WinUI. Com os dispositivos planejados para o feriado de 2020, as coisas precisam começar a se mover em breve.

@lukasf

com mão de obra suficiente, o problema do "menor denominador comum" poderia ser superado

Mão de obra suficiente... Concordo com tudo em sua mensagem, mas também gostaria de enfatizar a desvantagem significativa que @kmgallahan mencionou:

Cada engenheiro e cada dólar gasto fazendo o WinUI cross-plat é um engenheiro e cada dólar que poderia ter sido usado para tornar o WinUI no Windows melhor.

Estou dividido porque, por um lado, multiplataforma seria ótimo (se realmente funcionar bem), mas por outro lado, não gostaria de multiplataforma se isso causasse grandes atrasos na correção de vários problemas no WinUI no Windows, ou se atrapalhar demais o progresso do WinUI e impedir melhorias e novos recursos.

E se o tópico multiplataforma significar que todos somos forçados a escolher entre um dos seguintes resultados?

1. Uma excelente versão do WinUI que roda apenas no Windows; ou
2. Qualidade média, não confiável e/ou WinUI lento que roda em todas as plataformas, e que sofre de um ritmo de desenvolvimento extremamente lento, com muitos problemas pendentes permanecendo sem solução por 5 a 10 anos.

Esse é um grande problema que precisaria ser evitado. Na empolgação pela multiplataforma, é muito fácil parar acidentalmente de prestar atenção na prevenção desse grande problema.

E se o tópico multiplataforma significar que todos somos forçados a escolher entre um dos seguintes resultados?

1. Uma excelente versão do WinUI que roda apenas no Windows; ou

2. Qualidade média, não confiável e/ou WinUI lento que roda em todas as plataformas, e que sofre de um ritmo de desenvolvimento extremamente lento, com muitos problemas pendentes permanecendo sem solução por 5 a 10 anos.

@verelpode Primeiro, você está exagerando muito aqui. Segundo: a Microsoft tem vastos recursos disponíveis. Não deve ser um problema financiar melhorias nativas do WinUI e uma solução multiplataforma, se a Microsoft estiver realmente interessada em fornecer uma estrutura multiplataforma. Na verdade, eles estão fazendo isso agora: eles desenvolvem e aprimoram o WinUI e, ao mesmo tempo, desenvolvem e aprimoram o Xamarin. Eles têm muitos projetos acontecendo ao mesmo tempo. Portanto, se a Microsoft está realmente comprometida em fornecer uma excelente estrutura de interface do usuário do Windows (o que com certeza é) e fornecer uma estrutura multiplataforma (o que faria muito sentido com o Surface Neo e o Duo no horizonte), não temos escolher. Ambos podem ser realizados sem compromisso. (E geralmente não é algo que podemos escolher. A Microsoft tomará suas decisões e veremos qual é o resultado.)

Portanto, financiar uma estrutura multiplataforma não significa que o desenvolvimento e a estabilidade do WinUI tenham que sofrer. Se a estratégia Uno foi escolhida, o Uno é completamente independente do WinUI, porque fica no topo. O WinUI pode ser ainda mais evoluído, e o Uno tenta pegar novos controles e conceitos do WinUI (provavelmente em um ritmo mais lento). Além disso, se uma abordagem de renderização foi escolhida, isso não significa que ela atrasará o WinUI no Windows. Pode ser que uma nova versão do WinUI seja lançada, mas ainda não há um renderizador Android. Em seguida, o desenvolvimento de plataforma cruzada usaria a versão mais antiga do WinUI, até que o renderizador do Android seja atualizado para o WinUI vLatest. Os desenvolvedores do Windows podem usar o WinUI vLatest desde o início. Se os recursos existem, ambos podem ser desenvolvidos no mesmo ritmo.

@lukasf

A Microsoft tem vastos recursos à mão.

Verdade, verdade, mas existe um outro lado que também é verdade: muitos gerentes de projeto aprenderam da maneira mais difícil que investir mais dinheiro, pessoal e recursos em um projeto não necessariamente produz sucesso.

A Microsoft tem vastos recursos à mão.

Verdade, verdade, mas existe um outro lado que também é verdade: muitos gerentes de projeto aprenderam da maneira mais difícil que investir mais dinheiro, pessoal e recursos em um projeto não necessariamente produz sucesso.

Então o problema pode ser esses gerentes de projeto e estrutura organizacional ;)

Talvez a Microsoft deva comprar o Uno e financiá-los adequadamente, para que eles possam corrigir todos esses problemas em aberto e adicionar mais suporte ao controle.

Eu sei que a nventive vem cortejando a Microsoft nos últimos meses (uma aquisição da Microsoft é provavelmente sua estratégia de saída). Na Uno Conference também houve uma grande participação da Microsoft. Até o Xamarin está usando o Uno agora para dar suporte à web.

Eu sei que podemos debater as opções (1) renderizações nativas ou (2) outra implementação/camada de interface do usuário infinitamente, mas olhando para o que está disponível agora e o que precisamos para o Surface Duo, o Uno é na verdade a única solução que faz sentido. Como @lukasf disse, a Microsoft deveria investir seus recursos e ver até onde eles podem chegar em um ano. Se for bem-sucedido (recurso completo, estável), não acho que os desenvolvedores realmente se importem muito com a forma como ele é implementado nos bastidores. Se ficar aparente que a abordagem correta é renderizada nativamente pelo WinUI para cada plataforma, isso pode ser uma discussão por alguns anos. No momento, é melhor começar com uma plataforma Uno 25% completa do que nada.

@stevenbrix aqui :

@lukasf Acho que o "menor denominador comum" que existe atualmente no Uno é um problema de limitação de recursos e não devido a camadas. Eu adoraria estar errado, mas acho que esse problema pode ser resolvido e não piorar no futuro.

Vocês estão errados.
O Uno não segue o mantra do 'menor denominador comum' do Xamarin, mas, pelo contrário, tenta garantir que todos os controles XAML (e até mesmo o Windows Community Toolkit!) funcionem em todas as plataformas.

O Uno não segue o mantra do 'menor denominador comum' do Xamarin, mas, pelo contrário, tenta garantir que todos os controles XAML (e até mesmo o Windows Community Toolkit!) funcionem em todas as plataformas.

@weitzhandler você está totalmente certo! Acredito que sua arquitetura se prestará a um dia ter paridade completa com o conjunto de controle WinUI, o que pode não ser possível com o Xamarin.Forms. Se bem entendi, esse conjunto de controle ainda não foi construído, que é a que @lukasf e eu estávamos nos referindo. Eu posso estar errado, porém, eu não joguei o suficiente para saber, estou apenas confiando no que ouvi de todos os outros :)

A abordagem do @weitzhandler Uno de reimplementar as APIs UWP/WinUI reais é muito melhor do que a invenção do Xamarin de um novo dialeto XAML. Mas se você executar a Galeria de Controles Uno Xaml, encontrará algumas áreas vazias. Seu conjunto de controle com certeza é melhor que o Xamarin.Forms, mas ainda não é um UWP/WinUI completo. Acho que o Uno precisa de mais trabalho na superfície da API, e também mais trabalho para tornar os controles disponíveis realmente estáveis ​​e cheios de recursos.

Pude ver o Uno como uma opção viável. Mas precisa de algum progresso real, que é onde a Microsoft pode entrar em jogo.

Em um ponto diferente, concordo completamente com o que @lukasf disse aqui :

Ótimos aplicativos têm sua própria aparência. Eles não precisam de controles de plataforma de ações. Veja Spotify, Netflix

Também acho que, idealmente, a solução é ter o design WinUI + Fluent renderizado da mesma forma em todas as plataformas e talvez fornecer temas de aparência nativa para quem precisa do design de ações, para ser aplicado nas plataformas específicas.
Eu acho que web deve ser o mesmo que desktop, então apenas Droid e iOS são candidatos para isso de qualquer maneira.

Os controles de plataforma cruzada são, na verdade, independentes de estruturas de plataforma cruzada.

Hipótese: no futuro, os controles .Net não serão restritos a plataformas específicas.

Existem estruturas de plataforma cruzada .Net UI (Xamarin.Forms, Avalonia). Haverá também FutureXplatDotNetUI com o qual todos estão sonhando e ninguém pode definir.

Ao criar um controle, você pode fazer com que ele use recursos específicos da plataforma. Por exemplo, um player de vídeo usando players nativos em cada plataforma. Ou você pode fazer isso de forma independente de plataforma, por exemplo, usando SkiaSharp.

De qualquer forma, seu controle pode ser instalado em qualquer projeto .Net UI.

Corolário: FutureXplatDotNetUI precisará apenas de um conjunto mínimo de controles

Ele precisará definir uma classe de visualização e uma infraestrutura de layout, mas visualizações específicas ou grupos de visualizações podem ser adicionados instalando pacotes .Net UI padrão do nuget.

(Esta postagem é um comentário sobre a interface do usuário .Net multiplataforma e, portanto, não está relacionada ao WinUI.)

Tenho a sensação de que a prioridade atual da equipe WinUI não é para "novos aplicativos nativos do Windows". Em vez disso, eles estão se concentrando mais na modernização de aplicativos existentes e tornando o WinUI o suporte subjacente de alguma estrutura de interface do usuário de nível superior...

@reli-msft
Tenho a sensação de que a equipe do WinUI já desistiu de esperar que as pessoas escrevam novos aplicativos nativos do Windows, e o WinUI foi projetado para atualizar aplicativos existentes

Vindo de uma pessoa que trabalha na Microsoft, isso é meio estranho.

Tenho a sensação de que a equipe do WinUI já desistiu de esperar que as pessoas escrevam novos aplicativos nativos do Windows, e o WinUI foi projetado para atualizar aplicativos existentes

Vindo de uma pessoa que trabalha na Microsoft, isso é meio estranho.

@weitzhandler
Eu deveria usar uma palavra mais precisa da palavra que usei... Não é "desistir", mas "me importar menos". De qualquer forma, isso é apenas uma sensação de alguém de fora da equipe WinUI.
Mas, modernizar os aplicativos existentes pode ser mais importante _por enquanto_, e essa pode ser a razão pela qual o WinUI decidiu oferecer suporte ao Win32.

Você estava falando sobre o que a equipe do WinUI pensa.

Como MS geral, infelizmente, isso realmente faz sentido.
Eu gostaria que a Microsoft tivesse dado ao WinUI o amor React ou Electron ou qualquer outra tecnologia HTML CSS e JS (leia meu comentário acima ).

@charlesroddie

Você sempre precisa de uma estrutura para desenvolver seus controles. Você precisa de classes base para herdar, interfaces para implementar. Você precisa de classes para acessar árvores de controle, templates, etc etc. Então você realmente não pode separar controles de frameworks. Nenhum controle pode funcionar em vários frameworks, a menos que esses frameworks usem exatamente os mesmos conceitos, classes e namespaces.

Você pode compartilhar algum código entre controles WinUI (baseados em C#) e WPF, mas ainda seria difícil devido a diferentes namespaces e APIs diferentes. Mas é simplesmente impossível compartilhar controles XAML com estruturas Android ou iOS.

Além disso, não tenho certeza se o .NET é a tecnologia certa para construir uma pilha de interface do usuário. A Microsoft tentou com WPF e finalmente desistiu e mudou para C++. Ter quebras de GC durante o layout e a renderização simplesmente não causa a melhor impressão para os usuários finais, em tempos em que as animações se tornam cada vez mais importantes. Talvez isso não seja mais verdade se um Compositor estiver disponível, que cuida de animações suaves completamente independentes do thread da interface do usuário. Em seguida, a pilha de controle poderia ser C# e apenas a parte de renderização e animação de nível mais baixo seria código nativo. Mas naquela época, o desempenho era o principal motivo pelo qual o C# foi completamente abandonado nas seguintes estruturas de interface do usuário XAML (Silverlight e UWP/WinUI).

@lukasf Nenhum controle pode funcionar em vários frameworks

Isso não é verdade. Eu dei duas maneiras pelas quais os controles podem funcionar em vários frameworks. A primeira abordagem é escrever código específico da plataforma. Em seguida, você precisa conhecer os frameworks suportados para conectar seu código específico da plataforma a cada framework; você pode fazer isso agora, mas o andaime pode ser facilitado no futuro. A segunda abordagem (renderização independente de plataforma) é muito fácil e está sendo feita agora. Por exemplo, CSharpMath.SkiaSharp pode ser usado em todas as plataformas .Net UI.

@charlesroddie Ok, talvez eu tenha errado seu post. Mas então o controle não é realmente independente da estrutura. Ele só pode ser instalado nos aplicativos cuja estrutura é explicitamente suportada pelo controle. E a renderização é apenas uma pequena parte de um controle. Lógica de controle, vinculação de dados e manipulação de entrada devem ser implementadas para cada estrutura suportada, em cada controle, mesmo se você usar um renderizador independente de plataforma. Isso não me parece muito eficaz, a menos que os frameworks suportados sejam muito semelhantes. Como afirmei, é possível compartilhar algum código entre WPF, Silverlight e UWP. Mas além disso fica muito difícil, e duvido que algum dia verei tal controle.

Uma estrutura de plataforma cruzada geralmente permite que você escreva toda a lógica de controle, manipulação de dados e entrada (e às vezes até mesmo a renderização) apenas uma vez para uma API e, em seguida, mapeará isso automaticamente para cada estrutura. Assim, uma vez que a estrutura está lá, a implementação do controle é muito mais eficiente.

Ele só pode ser instalado nos aplicativos cuja estrutura é explicitamente suportada pelo controle.

Isso é verdade, mas o suporte a mais plataformas é/pode ser facilitado.

Lógica de controle, vinculação de dados e manipulação de entrada devem ser implementadas para cada estrutura suportada.

A vinculação de dados não precisa ser implementada por uma estrutura de interface do usuário. Este é um equívoco fomentado pelas abordagens .Net populares, mas inferiores. Os controles só precisam especificar construtores e propriedades. Eles não precisam especificar nenhuma maneira específica de vincular dados porque, uma vez que as propriedades gettable/settable são especificadas, os consumidores podem usar qualquer estrutura de abordagem para mover os dados que desejarem. (E quase qualquer abordagem/framework é melhor do que WPF/UWP/Xamarin data-binding.)

A lógica de controle é naturalmente implementada em .Net de forma independente de plataforma, de modo que é perfeitamente atendida em qualquer uma das abordagens que dei.

A manipulação de entrada se beneficia de uma "estrutura de plataforma cruzada", mas esta pode ser uma estrutura de controle muito pequena, que pode ser referenciada em projetos específicos de plataforma e de plataforma cruzada, com uma API muito pequena que apenas define mouse/toque e entrada do teclado. O projeto de controles SkiaSharp.Extended está se movendo nessa direção.

Se você quiser que a vinculação de dados funcione no WPF ou no WinUI, você deve declarar DependencyProperties. Duvido muito que alguém use um controle XAML que não funcione com vinculação de dados. A vinculação de dados está no cerne dessas estruturas e exige que DependencyProperties funcione, quer você goste delas ou não. Se você não adicioná-los, não poderá usar seu controle em nenhuma das estruturas atuais da plataforma Windows.

Com a "lógica de controle" mento mais a interação com outros controles, como definir ou criar sub-controles para seu controle de nível superior, manipulação de dados e status entre esses controles, layout, sincronização com sub-controles. Este é todo o trabalho específico do framework. Isso combinado com o código de vinculação de dados (se exigido pela estrutura de destino) e manipulação de entrada provavelmente compõe > 90% do código de controle. A parte comum entre diferentes implementações de framework para um desses controles é provavelmente tão pequena, simplesmente não faz sentido para mim trabalhar dessa maneira.

Não digo que isso não possa ser feito. Mas será muito complicado, já que os frameworks são muito diferentes. Quer dizer, é possível escrever um controle assim agora, ainda assim eu nunca vi um. E, pessoalmente, não acredito que isso se tornará uma abordagem nem um pouco popular.

você não pode usar seu controle em nenhuma das estruturas atuais da plataforma Windows

Isso não é verdade. Um controle que não implementa DependencyProperties pode ser usado no WPF/WinUI. Essa é uma das falhas da vinculação de dados .Net tradicional: ela incentiva a adição de DependencyProperties espúrias a controles que já definem propriedades configuráveis. Grande duplicação de código. (A propósito, um controle de plataforma cruzada não seria um "controle XAML" e você não deve ser enganado pelo uso indevido de "XAML" na linguagem de marketing do WinUI. Xaml é uma linguagem de marcação opcional que pode ser usada com vários Estruturas de interface do usuário .Net.)

subcontroles para seu controle de nível superior

Sim, um controle precisará especificar subcontroles, portanto, para que os controles de nível superior estejam disponíveis em várias plataformas, os de nível inferior também estarão. Se os controles de nível inferior estiverem disponíveis em várias plataformas, integrá-los é fácil. Você está imaginando escrever controles de nível superior antes dos de nível inferior, o que não é uma abordagem eficiente.

A boa notícia é que a Microsoft já decidiu matar o .net nativo.

@robloo farei uma festa para comemorar quando isso acontecer.

Mesmo que o Uno tenha um design e implementação técnicos sólidos e confiáveis, o risco e a preocupação é que o Uno desapareça dentro de alguns anos devido a um problema semelhante de $ 0 ou renda insuficiente que eventualmente desencadeie o esgotamento e o cancelamento ou estagnação do projeto. Ou simplesmente o desenvolvedor mais importante do Uno um dia de repente obtendo um novo hobby/interesse/obsessão e perdendo o interesse no Uno, ou um novo emprego/empregador e não mais tempo para trabalhar no Uno.

@verelpode
Eu compartilho a mesma preocupação provavelmente mais do que a maioria dos outros. Eu uso muito menos pacotes de código aberto não apoiados por grandes empresas (por exemplo, Oracle, Google, Microsoft) do que a média. Acredito que as duas condições a seguir devem ser atendidas para que isso aconteça:

1. A Nventive fecha seus negócios. A Nventive conta com a Uno para seus negócios de pão com manteiga.
2. As principais pessoas por trás do Uno perdem o interesse neste projeto maravilhoso.

Quanto ao número 1, ouvi dizer que a Nventive está ampliando seu prédio atual e se mudando para uma instalação maior, então a Uno Conf 2020 expandida (2 dias a 3 dias) terá uma parte realizada em um prédio diferente. Não sou economista, portanto não posso prever se haverá uma recessão severa levando muitas empresas à falência. Pelo menos não vejo um colapso econômico no futuro próximo (a taxa de desemprego em nossa área está abaixo de 2% há algum tempo).

Quanto ao número 2, raramente vejo o tipo de paixão que os principais caras do Uno têm por seu projeto. É quase como uma causa nobre, não um mero produto de software para eles. Bem, só um tolo não muda de ideia, então eu não diria que a probabilidade de perder o interesse é zero, mas provavelmente não muito longe de zero. Para ser sincero com você, esse é o principal motivo para eu curtir e ficar com o Uno agora. Assim como qualquer outra plataforma, o Uno tem muitos problemas (BTW, a falta de alguns recursos interessantes não é problema para mim.), Mas eles resolvem problemas críticos rapidamente. Eu acho que eles têm meia dúzia ou mais lançamentos todos os dias. Um dos meus aplicativos não pôde ser publicado devido a um bug conhecido de uma plataforma, e literalmente levou mais de meio ano para uma grande empresa (😉) corrigi-lo (arquivei o ticket).

Com base em minha vasta experiência com Sliverlight, SDKs do Windows Phone 7/7.1/8/8.1, Windows 8/8.1/10 (WinRT, UWP…) (Meu telefone principal era um Windows Phone, a melhor plataforma móvel da história humana, até o último minuto antes de não ter escolha a não ser mudar para um Android este ano), tenho mais confiança na longevidade da Uno Platform do que em coisas semelhantes da Microsoft. Sim, o Uno é baseado em todas as tecnologias da Microsoft, mas eles cuidam da migração quando a Microsoft muda as coisas nos bastidores.

Eu tenho me perguntado se uma razão pela qual Miguel endossa Uno e proferiu a palestra na Uno Conf é que ele vê Uno como seu bebê Mono nos primeiros dias, e Nventive como seu Ximian.

Eu me preparo para o pior cenário – falecimento de Uno. Como todos os projetos do Uno usam minhas duas tecnologias favoritas – C# e Xaml, posso migrá-los facilmente para qualquer plataforma emergente baseada neles. Pelo menos posso dizer que o código C# envelhece muito bem. Grande parte do código na minha biblioteca de utilitários principal compartilhada por todos os projetos tem mais de uma década. Eles ainda funcionam perfeitamente, e suspeito que funcionarão nas próximas décadas.

@stevenbrix @weitzhandler @Pinox

Uma discussão interessante, também notei que Blazor Native foi mencionado aqui também.

Houve um novo NDC conf de Steve com Blazor que pode ser interessante considerar, o vídeo acima usando Blazor + Native usou Flutter como renderizador. Mas em um novo vídeo NDC Conf, Steve agora usa Xamarin.Forms para renderizar a interface do usuário móvel com marcação semelhante a XAML. Eu poderia ver o Blazor Native como a solução x-plataforma mais prática que pode funcionar agora com o WinUI, pois suportará o React Native da mesma forma que eu poderia vê-lo suportando o Blazor Native dessa maneira. Assim, o .Net agora pode segmentar (Web, Mobile, Win Desktop).

ATUALIZAR:
Uma nova versão do MS Teams foi lançada recentemente e melhora o tempo necessário para visualizar a mensagem de bate-papo mais recente. Em uma mensagem anterior, mencionei que demorou aproximadamente 27 segundos, mas felizmente a nova versão é mais rápida em mostrar a mensagem de bate-papo mais recente.

Obrigado aos membros da equipe da Microsoft que trabalharam nesta melhoria. :sorriso:

Minha perspectiva:

Microsoft: Pode desenvolver um Webview2 mínimo (Semelhante a Carlo) que pode desabilitar quase todos os recursos e reduzir a apenas vinculação de eventos à interface do usuário HTML... biblioteca de back-end nativa).
Eu sabia o quão complexo o lado HTML/CSS, mas eu adoraria aproveitar esse conhecimento da interface do usuário e uma ligação de um para um no código C# por trás do código de evento etc.

Microsoft: Pode desligar uma ram de 8/32gb daquelas que tinham 4x 8gb/ 4x 32gb...Economizando muita energia.

Para isso, eliminamos dezenas de aplicativos desenvolvidos com Electron... que dependem do objetivo da Microsoft e do Bill Gates.

Embora o melhor objetivo seja que todos comecem a desenvolver aplicativos e ganhem tração de algum framework GUI padrão CSS3...possível como QT/GTK... mas muito ruim GTK não é não copyleft, e possível como QML com equivalência .net.

ATUALIZAR:
Cancele o que eu disse na minha mensagem anterior sobre o problema ser corrigido ☹️ Não foi corrigido. Isso é bizarro: por algumas semanas, parecia que o problema havia desaparecido, mas o problema voltou recentemente! O MS Teams está novamente me causando dificuldades e atrasos ao simplesmente tentar visualizar a mensagem de bate-papo mais recente.

A bugginess do MS Teams não é surpreendente quando você considera que é escrito em JavaScript. _Claro_ um aplicativo escrito em JavaScript tem bugs - por que alguém esperaria o contrário? O MS Teams usa o ElectronJS, que usa JavaScript, apesar do fato de que o JavaScript nunca foi concebido para ser uma linguagem de programação real, mas apenas um complemento de script casual para navegadores da web.

JavaScript nem sequer inclui verificação de tipo em tempo de compilação - isso é o quão ruim é. Daí a necessidade do TypeScript tentar corrigir esse _major_ problema no JavaScript. Na verdade, é um problema muito ruim se você pensar em JavaScript como uma linguagem de programação -- JavaScript é terrível como uma linguagem de programação -- mas como eu disse, foi planejado para ser uma linguagem de script casual, não uma linguagem de programação, portanto você pode perdoe o JavaScript por não incluir o essencial de uma linguagem de programação, porque programar aplicativos não era o propósito do JavaScript.

O que não é realmente perdoável é a decisão incompreensível de usar uma linguagem de script casual como se fosse uma linguagem de programação. Fiquei realmente surpreso ao ver que a Microsoft escolheu uma linguagem não profissional para um aplicativo tão importante quanto o Teams. Eu não achei que fosse possível para alguém dizer o nome "JavaScript" enquanto ao mesmo tempo esquecesse que "JavaScript" tem "Script" em seu nome porque é de fato uma linguagem de script e não uma linguagem de programação. De alguma forma, a existência da palavra "Script" em "JavaScript" acabou de ser completamente misturada.

Os membros da equipe do WinUI têm trabalhado arduamente em muitas melhorias no WinUI. A decisão da Microsoft de usar uma linguagem de script casual em vez do WinUI não faz sentido.

Existem muitos aplicativos Web JavaScript de alto desempenho e muito bem escritos. Claro que você pode obter um desempenho ainda melhor com outras tecnologias. Mas a razão pela qual o Teams é lento para você certamente não é o fato de ser baseado em JavaScript. Isso é causado por alguma implementação ruim no lado do servidor ou no lado do cliente (provavelmente problemas de assíncrona/threading). Certamente seria possível escrever Teams em JavaScript com um desempenho muito melhor.

Não me interpretem mal, eu não sou um fã de JavaScript. Na verdade, acho que é uma linguagem horrível. Apenas dizendo que os problemas que você vê não são causados ​​pelo fato de o Teams usar a tecnologia JavaScript. É até possível executar o mecanismo Unreal em JavaScript com bom desempenho (não de primeira).

WinUI é apenas uma estrutura de área de trabalho do Windows. Então não foi possível desenvolver o aplicativo x-platform Teams baseado nele, e ainda hoje não é possível. Mas talvez os problemas com o Teams ajudem a Microsoft a considerar tornar o WinUI multiplataforma. Com uma verdadeira plataforma x WinUI e .NET Core, seria muito mais fácil desenvolver aplicativos responsivos que fossem bem dimensionados.

WinUI é apenas uma estrutura de área de trabalho do Windows. Então não foi possível desenvolver o aplicativo x-platform Teams baseado nele, e ainda hoje não é possível. Mas talvez os problemas com o Teams ajudem a Microsoft a considerar tornar o WinUI multiplataforma. Com uma verdadeira plataforma x WinUI e .NET Core, seria muito mais fácil desenvolver aplicativos responsivos que fossem bem dimensionados.

Usando o Uno, o WinUI é multiplataforma. Veja a Calculadora UNO na loja Google Play. É uma versão portada da calculadora do Windows 10.

Alguém estava pedindo uma comparação UWP vs Electron, aqui estão alguns:

https://twitter.com/emiliano84/status/1198177284533956608

https://twitter.com/emiliano84/status/1198179206548602881

o novo aplicativo XBOX é ridículo, pode levar facilmente 1,5 gb de RAM para nada

seria bom se alguém pudesse fazer um vídeo para mostrar o quão mais lento eles são comparados ao UWP

Eu pensei que a maioria dos participantes desta discussão sobre WinUI & X-platform leu sobre esta história, mas caso alguns tenham perdido, aqui está o WinUI no Windows 7 – Sim, é possível com a Uno Platform . Uma vez que um aplicativo é baseado no Uno, ele tem como alvo Windows, Web, iOS e Android.

@lukasf

Certamente seria possível escrever Teams em JavaScript com um desempenho muito melhor.

Sim, é _possível_, e também é _possível_ escrever MS Teams no PowerShell com desempenho aceitável (eu gosto do PowerShell), e também é _possível_ que a SpaceX se mude para a Rússia e ainda consiga lançar satélites, mas ainda seria um gerenciamento incompetente decisão de realocar a SpaceX para a Rússia ou escrever o aplicativo MS Teams em uma linguagem de script como PowerShell ou JavaScript. Se a SpaceX se mudasse para a Rússia, sim, a SpaceX ainda poderia operar, é possível, mas honestamente teríamos que dizer que Elon Musk não seria realmente um gerente eficaz e não saberia realmente o que estava fazendo.

Não estou 100% convencido de que a Electron seja a culpada. Diz-se que o Visual Studio Code também é baseado no Electron, mas seu desempenho é bastante sólido. Os aplicativos Electron são basicamente aplicativos da Web, e existem milhares de razões por trás de um aplicativo da Web mal executado.

Não há muito que o WinUI possa fazer para "conquistar o Teams". Não é a tecnologia, é o produto. O Teams é como uma empresa iniciante que se estabeleceu em um caminho de rápido crescimento. Ele precisa ser executado em várias plataformas com paridade de recursos e eles precisam fazer isso o mais rápido possível. Esta é a única razão para escolher a tecnologia baseada na web. No celular, eles podem usar o React Native porque é a única maneira de acessar o hardware com JavaScript, mas no desktop, eles precisam manter a paridade de recursos e a manutenção do código com o aplicativo da Web, o mac e a versão Linux. Eles precisam usar uma estrutura direcionada ao win32 porque não podem esperar que o modelo de aplicativo UWP adicione os recursos necessários. Ser capaz de compartilhar a área de trabalho com a opção de escolher qual área de trabalho ou qual aplicativo específico compartilhar é um de seus principais recursos. É assim que os produtos do tipo startup são desenvolvidos. O Slack usou o jquery para hackear o crescimento quando eles começaram e terminaram com um código muito ruim, mas depois que tiveram algum tempo para refatorar, eles rapidamente reescreveram tudo com o react, e o Slack agora é muito mais rápido do que antes. O WinUI e o Electron não estão na mesma categoria e, por esse motivo, não substituirão o Electron pelos aplicativos que realmente precisam, independentemente do recurso que ele adiciona.