Microsoft-ui-xaml: Discusión: WinUI vs ElectronJS y multiplataforma (mejore WinUI para eliminar las razones para usar ElectronJS en lugar de WinUI)

Lo mismo ocurre con la nueva aplicación Xbox Beta. Utiliza 400 MB solo por estar abierto como una tienda glorificada. Microsoft Store usa solo 117 MB mientras está activo.

Hasta que Microsoft desarrolle un marco de interfaz de usuario multiplataforma, que permita una única interfaz de usuario y un diseño de control en todas las plataformas, se seguirá utilizando ElectronJS y sus similares.

Ejemplo de la asombrosa velocidad de ElectronJS/Teams:
En primer lugar, como comparación, calculé el tiempo que lleva abrir Microsoft Outlook y ver el mensaje más reciente en la bandeja de entrada (una bandeja de entrada que contiene una gran cantidad de mensajes). Solo tomó un par de segundos; de hecho, fue tan rápido que no pude detener el cronómetro lo suficientemente rápido para obtener una medición precisa.
A continuación, cronometré el tiempo que lleva abrir Microsoft Teams y ver el mensaje más reciente en el chat con un colega: ¡27 segundos! Este tiempo puede ser más o menos dependiendo de cuántos mensajes e imágenes existan en el panel de chat.

( ACTUALIZACIÓN 9-NOV-2019: _Se lanzó una nueva versión de Teams y mejora el tiempo necesario para ver el mensaje de chat más reciente. El ejemplo mencionado anteriormente de 27 segundos ahora describe la versión anterior de Teams. Gracias al personal de Microsoft miembros que trabajaron en esta mejora._ )

La semana pasada, hice clic en el ícono de Ayuda en Teams, luego hice clic en "Enviar comentarios" y escribí un mensaje. Fue asombrosamente lento: ¡Cada vez que presionaba una tecla en el teclado, tomaba varios segundos para que apareciera cada carácter! (Sin embargo, cuando probé "Dar comentarios" nuevamente hoy, se retrasó mucho menos que la semana pasada, por lo que aparentemente es complicado reproducir este problema en particular).

Si Teams se escribiera usando WinUI, no tendría estos problemas de velocidad y otros errores inusuales. Por ejemplo, las aplicaciones de WinUI usan el formato de fecha/hora que está configurado en la configuración de Windows, mientras que Teams siempre usa el formato de fecha/hora de EE. UU. de 12 horas cuando Teams está configurado en inglés e ignora la configuración de Windows; Se supone que las aplicaciones funcionan. Luego probé cambiando el idioma de Teams hoy y decía _"Hubo un problema técnico, Teams se está recuperando"_. Y luego varias imágenes en mensajes en el panel de chat no se cargaron.

Del mismo modo, si Teams se escribió con WinUI, no crearía 5 procesos de Teams.

@mdtauk

Hasta que Microsoft desarrolle un marco de interfaz de usuario multiplataforma, que permita una única interfaz de usuario y un diseño de control en todas las plataformas, se seguirá utilizando ElectronJS y sus similares.

Aunque generalmente estoy de acuerdo, debe haber más en esta historia que eso, porque, por ejemplo, Microsoft OneNote está disponible para Windows, Android y Mac, pero no usa ElectronJS (AFAIK) y no sufre un rendimiento terrible como equipos

@mdtauk

Hasta que Microsoft desarrolle un marco de interfaz de usuario multiplataforma, que permita una única interfaz de usuario y un diseño de control en todas las plataformas, se seguirá utilizando ElectronJS y sus similares.

Aunque generalmente estoy de acuerdo, debe haber más en esta historia que eso, porque, por ejemplo, Microsoft OneNote está disponible para Windows, Android y Mac, pero no usa ElectronJS (AFAIK) y no sufre un rendimiento terrible como equipos

Microsoft tiene los recursos para crear aplicaciones para cada plataforma, compartiendo el código tanto como sea posible, pero sin usar una interfaz de usuario compartida.

Me encantaría escuchar cualquier argumento en contra del uso de Uno Platform que se dirija a múltiples plataformas (Windows, iOS, Android, Web) que produzcan paquetes de aplicaciones de alto rendimiento usando UWP API ahora, WinUI más tarde. Utiliza todo Microsoft - VS, C#, Xaml, Xamarin, mono, .Net...
¿No viene directamente de Microsoft la razón principal por la que algunos lo evitan?

Me encantaría escuchar cualquier argumento en contra del uso de Uno Platform que se dirija a múltiples plataformas (Windows, iOS, Android, Web) que produzcan paquetes de aplicaciones de alto rendimiento usando UWP API ahora, WinUI más tarde. Utiliza todo Microsoft - VS, C#, Xaml, Xamarin, mono, .Net...
¿No viene directamente de Microsoft la razón principal por la que algunos lo evitan?

Este habría sido un mejor argumento hace algunos años, pero muchas empresas que buscan invertir en la creación de una aplicación o sistema necesitan saber que la plataforma para la que están desarrollando tiene el soporte y la longevidad de una gran empresa con vastos recursos como Microsoft.

El problema con ese argumento es que la década pasada mostró que Microsoft abandonó plataformas y bases de usuarios, y que Windows pasó a ser un legado o una prioridad decreciente dentro de Microsoft.

Por lo tanto, no puede culpar a los nuevos desarrolladores por moverse hacia las plataformas web, si desean ejecutar servicios conectados, o centrarse en plataformas que se están desarrollando activamente y parecen tener un fuerte apoyo en el futuro.

Al mismo tiempo, hay algunas grandes empresas como Adobe, con aplicaciones heredadas, por lo que mover plataformas con ellas será casi imposible. También hay aficionados y empresas con software personalizado.

A Microsoft le ha ido bien con la compatibilidad con .NET y Win32. Y WinUI puede ser la oportunidad de permitir Win32 y .NET, pero con una interfaz de usuario moderna.

Silverlight, WinRT, UWP: todos fueron abandonados. (Sé que UWP no lo es técnicamente, pero lo más probable es que WinUI se vea como un reemplazo).

Zune, Windows Media Center, Windows Phone 7, Windows Phone 8, Windows 8: defraudaron a los entusiastas ya quienes intentaron evangelizar.

La forma en que Microsoft posicione a WinUI y también se asegure de que el futuro de Windows esté asegurado, será _absolutamente esencial_

WinUI para escritorio parece prometedor, pero creo que al menos un subconjunto de su XAML debe poder ejecutarse en la Web; WinUI en la Web, como un nuevo Silverlight pero ejecutándose en .NET 5 y WebAssembly.

Silverlight, WinRT, UWP: todos fueron abandonados. (Sé que UWP no lo es técnicamente, pero lo más probable es que WinUI se vea como un reemplazo).

Zune, Windows Media Center, Windows Phone 7, Windows Phone 8, Windows 8: defraudaron a los entusiastas ya quienes intentaron evangelizar.

Concurrir.
No puedo creer algunas de mis aplicaciones Silverlight (algunos usuarios todavía usan a diario las aplicaciones web0.
Seguir a Microsoft ha sido cada vez más difícil. La gente detrás de Uno Platform la desarrolla y mantiene para respaldar su negocio de aplicaciones de pan y mantequilla. Es de código abierto con muchos colaboradores. Siento que estoy montando a cuestas un autobús muy bueno con conductores de primer nivel que saben bien cómo navegar por el laberinto o el desorden de Microsoft.

Mis 2 centavos: la única esperanza de UWP y WinUI es si rápidamente lo hacen multiplataforma, incluida la web, antes de que no quede nada.
Uno Platform es una forma rápida, fácil y probablemente también la más segura de lograrlo.
Como mencionó @zipswich , Uno ha sido Microsoft todo el tiempo; en las pautas de codificación, las herramientas, la selección de idioma y la representación, y está listo para Fluent-design.
Es 100 veces más sesgado por Microsoft que Xamarin, por ejemplo. Por no hablar de React o Electron, y todas las desagradables tecnologías HTML y CSS o JS, MS está tan obsesionado con halagar y engañar.

Y seamos duros, C# es solo un lenguaje de servidor con la falta de un marco de interfaz de usuario de .NET Standard.
Cuanto más tiempo permanezca así, Dart u otras tecnologías se convertirán en lenguajes de servidor y se harán cargo por completo.
Ves que la gente está dispuesta a usar lenguajes desagradables (JS), como un sacrificio para poder usar una base de código de un solo idioma, tanto en el cliente como en el servidor. C# puede desaparecer como lo hizo XAML, o puede ganar junto con XAML si se proporciona un rescate de emergencia.

No creo que Uno sea el futuro. Es muy similar a Xamarin.Forms, ya que es un marco Xaml simplificado con muchas funciones faltantes y muchas cosas adicionales complicadas que se agregan para permitir que se integre de alguna manera en todas las plataformas, con algunos trucos y soluciones. Claro que puede usarlo, pero está muy limitado en cuanto a los controles que tiene y las API que puede usar. El principal problema es que intenta realizar la interfaz de usuario de Xaml con los controles nativos de cada plataforma. Esto siempre es problemático y lo deja solo con el pequeño subconjunto de funcionalidad que funciona en todas las plataformas.

El futuro sería utilizar WinUI real y proporcionar un renderizador real para cada plataforma, implementado en el motor 3D nativo de la plataforma. Esto nos daría el conjunto completo de funciones, todas las bondades de WinUI, ejecutándose con rendimiento nativo, multiplataforma.

En realidad, Microsoft ya tenía algo como esto funcionando muy bien: la interfaz de usuario de UWP se basaba principalmente en el código de Silverlight, y Microsoft tenía complementos de Silverlight para todas las plataformas principales, lo que significa que ya tienen motores de representación básicos para todas estas plataformas. No están actualizados, ya que UWP ahora tiene muchas adiciones en comparación con Silverlight. Pero es una base sobre la que se puede construir.

Microsoft seguro tiene los recursos para lograr esto. Esto es lo que la gente quiere, y esto es lo que deberían hacer.

C# podría desvanecerse como XAML >

Definitivamente no estoy de acuerdo con esta afirmación sobre C#. C# es mucho más grande que XAML. Si sigue a Blazor, sabrá que esto no puede ser cierto. Veo a Blazor como un punto de inflexión para mí principalmente cuando uso UWP/Xamarin y para los desarrolladores de C# en general, dirigidos específicamente a usuarios empresariales.

Sería bueno tener WinUI x-platform, pero creo que el camino más fácil hacia la web/x-platform es Blazor, especialmente ahora que Blazor también admite clases parciales, lo que significa que puedo tomar la mayor parte de mi código existente tal como está y comenzar a usarlo en Blazor. Un par de contratiempos podrían ser alternativas a Sqlite, Shared Projects y ReactiveUI. Debería poder usar mi arquitectura MVVM existente y migrarla a Blazor con bastante facilidad.

El obstáculo más importante para mí es la falta de compatibilidad con .net core 3 en UWP. Creo que es fundamental que MS alinee Blazor + UWP en la experiencia del desarrollador. Sé que el equipo de UWP está trabajando en ello.

Además, me gustaría ver las páginas de Blazor en las aplicaciones UWP/WInUI. El modelo de IU híbrida funcionaría muy bien para mí en las aplicaciones UWP para que pueda usar los mejores recursos de IU disponibles. (html5 versus XAML) y tampoco replicar mi esfuerzo de interfaz de usuario entre UWP y Blazor donde tiene sentido.

Actualmente, Electron usa Javascript, HTML + CSS. No hay razón por la que no podamos usar Electron con Blazor => C#, HTML + CSS + gRPC

pero está muy limitado en cuanto a los controles que tiene y las API que puede usar.

@lucasf ¿Has probado Uno? ¿Sabía que Uno permite usar cualquier API nativa a través de Xamarin en caso de que no haya una API UWP adecuada? Uso solo unas pocas API nativas en mis aplicaciones basadas en Uno, incluso para mi aplicación de transmisión de video en tiempo real que usa códec de hardware y requiere baja latencia.

pero está muy limitado en cuanto a los controles que tiene y las API que puede usar.

@lukasf ¿Has probado Uno? ¿Sabía que Uno permite usar cualquier API nativa a través de Xamarin en caso de que no haya una API UWP adecuada? Uso solo unas pocas API nativas en mis aplicaciones basadas en Uno, incluso para mi aplicación de transmisión de video en tiempo real que usa códec de hardware y requiere baja latencia.

@zipswich El conjunto de controles Xaml estándar en Uno es bastante pequeño, no se acerca a lo que UWP completo o WinUI3 tienen para ofrecer. Para realizar interfaces de usuario buenas/complejas, por lo general tiene que incrustar código y controles de interfaz de usuario nativos específicos de la plataforma adicional. Entonces, al final, se encontrará con una combinación de múltiples plataformas de interfaz de usuario (Uno Xaml, Android nativo, iOS nativo, quizás Windows nativo o WebAssembly). Esto no es lo que yo llamo una gran experiencia de desarrollador.

Si tuviéramos renderizadores nativos de la plataforma x para WinUI, solo tendríamos una única interfaz de usuario con el conjunto completo de funciones de WinUI, sin ningún tipo de contenido específico de la plataforma. Y WinUI se representaría directamente en la GPU con pleno rendimiento, tal como lo esperaba. No es necesario agregar controles adicionales de Android o controles adicionales de iOS. Así es como debería verse el desarrollo de la plataforma x.

¿Qué le falta a WinUI (y cómo se puede mejorar) para convencer a los administradores de programas de Microsoft para que Microsoft Teams cambie de ElectronJS a WinUI/UWP?

Gran pregunta. Una gran cantidad de usuarios estarán muy contentos si hicieran esto.

Un factor importante es la falta de medidas de rendimiento que comparen los marcos. Una página que compare aplicaciones equivalentes hechas en UWP y Electron y compare la velocidad y el uso de memoria sería suficiente. Esto podría extenderse a otros marcos. A partir de estos costos para los usuarios, los efectos sobre el uso y los beneficios de la consolidación del código se pueden sopesar frente a los costos financieros.

La falta actual de esta investigación está ayudando a que los marcos ineficientes se vuelvan populares.

Hablando honestamente: dudo que MS tenga planes para hacer que "WinUI" (UI de Windows ) sea multiplataforma. Además de eso, el hecho de que ahora sea de código abierto generalmente significa que Microsoft ya no la considera una tecnología crítica/estratégica. En su lugar, están tratando de aprovechar los recursos de la comunidad para reducir el personal interno y mantenerlo vivo. No me malinterpreten, estoy feliz de que WinUI sea de código abierto ahora y agradezco todo el tiempo que los desarrolladores de Microsoft dedican a la plataforma llevándola a WinUI 3.0; es un gran paso para consolidar la plataforma de presentación de Windows tanto para nativos como para aplicaciones administradas. Simplemente no creo que Microsoft vea a Windows como el futuro y no creo que estén interesados ​​en llevarlo a través de varias plataformas (por supuesto, ese es su error si es cierto).

Lo que el mundo necesita es un verdadero marco de desarrollo multiplataforma que no obligue a los desarrolladores a usar tecnología deficiente. Parece que la mayoría de la gente aquí está de acuerdo. Lo que eso significa en gran medida es:

• Una biblioteca de control y marcado (XAML) que se puede representar como diseños nativos de la plataforma (solo necesitaríamos estilos de control para iOS, Android, etc.)
• Debe escribirse en código administrado como WPF. Solo las capas base en C++, los controles nunca deben ser otra cosa que C#.
• La renderización debe hacerse con Metal/Vulcan/DirectX (no sobre los controles existentes como Uno)
• La entrada tiene que ser reimplementada en forma de plataforma X
• La accesibilidad es un gran problema que, lamentablemente, es mucho más fácil de resolver con el enfoque de Uno.

Si eso es lo que queremos, creo que WinUI no lo hará. El hecho y la forma en que se implementa de forma nativa (alguna capa COM / .net en el medio) solo significa que sería muy complicado tomar esta plataforma cruzada. En cambio, tenemos UNO y Avalonia. Avalonia es la verdadera luz al final del túnel pero no tienen recursos. Lo que es más o menos posible ahora es usar la tecnología de renderizado de Avalonia como backend para WPF (la parte administrada). Eso nos daría un verdadero marco de interfaz de usuario multiplataforma en poco tiempo. El problema es que WPF está diseñado para escritorio y se invirtió mucho trabajo en UWP para hacer que WPF/Silverlight sea compatible con dispositivos del tamaño de un teléfono y entrada táctil/interactiva moderna.

Honestamente, creo que en este punto estaríamos mejor si todos nosotros solo pusiéramos dinero y contribuciones de código en Avalonia. Hemos estado pidiendo a Microsoft una interfaz de usuario multiplataforma durante demasiado tiempo y ellos mismos están contentos de cambiar a tecnologías web. Microsoft incluso está convirtiendo aplicaciones UWP como XBox en Electron y tecnologías web ahora. Las aplicaciones tampoco se venden en Microsoft Store.

La ironía es que Microsoft tuvo tanto éxito en el pasado porque les dio a los desarrolladores las herramientas que necesitaban para crear excelentes aplicaciones. Esto atrae a los usuarios y tiene un circuito de retroalimentación muy constructivo. En algún momento eso se olvidó. Ahora los desarrolladores están recurriendo a tecnologías por debajo de la media (HTML/CSS nunca se diseñó originalmente para aplicaciones... ¡fue para el marcado de documentos!) superan con creces los sacrificios en funcionalidad, integración de sistemas y rendimiento en este día y momento.

La ironía es que Microsoft tuvo tanto éxito en el pasado porque les dio a los desarrolladores las herramientas que necesitaban para crear excelentes aplicaciones. Esto atrae a los usuarios y tiene un circuito de retroalimentación muy constructivo. En algún momento eso se olvidó. Ahora los desarrolladores están recurriendo a tecnologías por debajo de la media (HTML/CSS nunca se diseñó originalmente para aplicaciones... ¡fue para el marcado de documentos!)

Bien dicho. Además de BASIC, comencé a usar IDE de Microsoft desde Quick C, luego VC++... Microsoft solía evolucionar, innovar de manera constante, consistente y algo predecible. Tratamos de seguirlo, y parece seguir la tendencia de quienes se supone que nos siguen. Solía ​​decirles a los pasantes de universidades de investigación de primer nivel que usaran las tecnologías de Microsoft para las aplicaciones empresariales en las que se les pedía que trabajaran. No hubo resistencia, y felizmente recogieron las cosas de Microsoft rápidamente. Me he estado preguntando si Microsoft ha estado observando lo que les gusta a los niños en estos días, y luego siguiéndolos.

Las aplicaciones tampoco se venden en Microsoft Store.

Cierto lamentablemente. Sin embargo, culpo a la peor tienda de aplicaciones (para usuarios y editores), no a las tecnologías de desarrollo. Proporción de descargas diarias de la versión UWP frente a Android de una aplicación: 1:20 . Cuestan aproximadamente la misma cantidad de esfuerzo para desarrollar. Esto no es una exageración. Acabo de echar un vistazo a los datos de descarga de ayer. Si trabajara para un contador de frijoles, me despedirían de inmediato por dedicar tanto esfuerzo a la versión de UWP que genera tan poco retorno.

Cierto lamentablemente. Sin embargo, culpo a la peor tienda de aplicaciones (para usuarios y editores), no a las tecnologías de desarrollo.

@zipswich , sí, tienes un buen punto. Solo estaba asumiendo que Microsoft ve internamente los números de ventas y asume (correctamente) que el ecosistema se está muriendo. Esto los convence de que los tipos de tecnologías de desarrollo subyacentes de los que estamos hablando son obsoletos, por lo que comienzan a invertir y van en otras direcciones. En realidad, la mayoría de los desarrolladores de aplicaciones de Microsoft pueden ver la clara necesidad de un marco multiplataforma que no esté escrito olvidando los últimos 20 años de avance tecnológico de la interfaz de usuario (WPF realmente cambió las reglas del juego cuando apareció).

No solo necesitamos multiplataforma: necesitamos algo que se haga con lenguajes y marcas potentes/escalables y que tenga un alcance significativo (destinado a aplicaciones, un buen catálogo de control) desde el principio. Sin embargo, no creo que podamos contar más con Microsoft para eso. Han dejado en claro que ven mayores ganancias al invertir su tiempo/recursos en otras áreas.

Me despedirían de inmediato por dedicar tanto esfuerzo a la versión de UWP que genera tan poco rendimiento.

Te escucho, hice esa declaración basada en mi propia aplicación en Microsoft Store también.

@robloo Tienes algunos buenos puntos allí, pero realmente no te sigo. Aquí hay algunos pensamientos:

• Microsoft también ha puesto mucho esfuerzo y recursos en otros marcos de código abierto, como .NET Core, ASP.Net Core, EF Core. Obviamente, ven el futuro en el desarrollo multiplataforma de código abierto (al menos para aplicaciones de servidor). También ponen recursos en la compilación AOT, por lo que .NET Core también se puede compilar para iOS y Android (donde JIT no está permitido). Así que no puedo seguirte diciendo que WinUI está muerto ahora, solo porque lo hacen de código abierto. Quiero decir, podría ser cierto, pero si su único argumento es "porque lo hacen de código abierto", entonces esto no es muy convincente.

• Qt es un marco de interfaz de usuario multiplataforma que se implementa en C/C++ nativo. Tiene renderizadores OpenGL/Direct3D acelerados por hardware, por lo que se ve igual y tiene un gran rendimiento en todas las plataformas. No se necesita un código específico de plataforma, todos los controles se ejecutan en todas las plataformas, incluidos iOS y Android. Entonces, ¿por qué no debería ser técnicamente posible ejecutar WinUI en iOS y Android, si Qt puede hacer precisamente eso? WinUI se implementa en WinRT, que es C++ nativo, al igual que Qt. Internamente, utiliza solo unas pocas tecnologías COM (interfaz IUnknown más el sistema de fábrica COM). No debería ser demasiado difícil abstraer eso o volver a implementar lo que se necesita para otras plataformas. No creo que ningún código COM se use directamente en el código WinUI.

• Silverlight usó la misma tecnología y estaba disponible en la plataforma x.

• Windows sigue siendo el sistema operativo de escritorio número 1, muy utilizado, no solo en el hogar sino también (especialmente) por las empresas. Combinado con las licencias de Office, genera muchos ingresos sólidos para Microsoft. Perderían estos ingresos si dejaran morir todas las principales plataformas de desarrollo de UI. WinForms y WPF ya están muertos, por lo que WinUI es la única plataforma de interfaz de usuario activa en Windows. No creo que quieran deshacerse del sistema Windows/Office/Enterprise completo, así que no creo que quieran deshacerse de WinUI.

• Hacer que WinUI sea de código abierto es excelente para los desarrolladores, no solo para Microsoft.

• Puede ser que UWP vaya a morir. Muchos desarrolladores se mantienen alejados debido a todas las estúpidas limitaciones. La tienda de Windows no tiene un éxito remoto. Windows Phone está muerto, que fue la razón principal para iniciar todo el asunto de UWP.

• ¡Llevar WinUI a las aplicaciones de escritorio con WinUI 3.0 y hacerlo de código abierto, en realidad podría ser el paso para salvarlo, no matarlo!

Solo estaba asumiendo que Microsoft ve internamente los números de ventas y asume (correctamente) que el ecosistema se está muriendo. Esto los convence de que los tipos de tecnologías de desarrollo subyacentes de los que estamos hablando son obsoletos, por lo que comienzan a invertir y van en otras direcciones.

@robloo No tiene por qué ser así. He estado diciendo todo el tiempo que es la peor tienda de aplicaciones que mató a Windows Phone, la mejor plataforma móvil.

Pueden matar dos pájaros de un tiro: subcontratar la tienda a un tercero competente y acabar con la pesadilla de .Net Native. Reducirá su costo y (creo) el doble, el cuádruple... La aplicación de Windows se descarga rápidamente. Más del 90 % de los problemas de mi aplicación UWP están relacionados únicamente con la pesadilla de .Net Native.

@lukasf Creo que malinterpretaste mucho de lo que estaba diciendo.

No puedo seguirlo diciendo que WinUI está muerto ahora, solo porque lo hacen de código abierto.

Nunca diría que WinUI está muerto. Dije que Microsoft probablemente ya no lo vea como un producto crítico/estratégico a largo plazo. Ven mayores ganancias en otras áreas (servicios y la nube), por lo que se aseguran de pasar su tiempo donde haya mayores ganancias para los accionistas. Esto significa que creo que WinUI no crecerá significativamente para que sea multiplataforma y simplemente lo mantenga vivo , lo que me aseguré de decir en lugar de "muerto". (No soy alguien en el carro UWP/WinUI está muerto). También creo firmemente que Microsoft está haciendo un gran trabajo con WinUI 3.0, como dije. Está permitiendo que todo Windows, win32 nativo y administrado, se consolide con un marco de interfaz de usuario.

Entonces, ¿por qué no debería ser técnicamente posible ejecutar WinUI en iOS y Android?

Todo es técnicamente posible. Estaba diciendo que sería extremadamente difícil, ya que fue diseñado e implementado únicamente para Windows. También di el ejemplo de cómo se comunica con el código administrado como algo que creo que sería muy complicado de llevar a cabo en varias plataformas. Sin embargo, sería bueno para todos nosotros si me equivocara aquí.

Silverlight usó la misma tecnología y estaba disponible en la plataforma x.

Y Silverlight está muerto no porque no fuera técnicamente posible, sino porque ya no era un buen caso de negocios, que es realmente mi punto más crítico. Tenga en cuenta que también murió a las mismas tecnologías HTML/CSS/JS que ahora se hacen cargo del desarrollo de escritorio y móvil.

Perderían estos ingresos si dejaran morir todas las principales plataformas de desarrollo de UI.

Esto probablemente podría discutirse de varias maneras diferentes, pero probablemente queda totalmente fuera del alcance del tema con bastante rapidez (lo cual sé que ya estoy haciendo). En pocas palabras, por supuesto, Microsoft no dejará que todas las plataformas de interfaz de usuario de Windows mueran. Todavía tienes que escribir aplicaciones para Windows... Nunca dije lo contrario.

Hacer que WinUI sea de código abierto es excelente para los desarrolladores, no solo para Microsoft.

Dije: "Estoy feliz de que WinUI sea de código abierto ahora y agradezco todo el tiempo que los desarrolladores de Microsoft están dedicando a la plataforma llevándola a WinUI 3.0". La intención era transmitir mi sentimiento de que también creo que el código abierto es excelente para un número de razones que no mencioné. Como ejemplo, incluso la Plataforma Uno que ahora tiene acceso a la fuente es excelente, como afirmaron en UnoConf.

Puede ser que UWP vaya a morir.

Espera, ¿de qué lado estás? ja ja. Pero en serio, considero que WinUI/UWP es esencialmente lo mismo y UWP solo tendrá una evolución menor hacia WinUI sin grandes contratiempos para los desarrolladores.

¡Llevar WinUI a las aplicaciones de escritorio con WinUI 3.0 y hacerlo de código abierto, en realidad podría ser el paso para salvarlo, no matarlo!

Estoy de acuerdo contigo y nunca quise decir lo contrario. Sin embargo, estaba mirando algunas tendencias más amplias y también hablando de llevarlo a varias plataformas.

@zipswich

Pueden matar dos pájaros de un tiro: subcontratar la tienda a un tercero competente y acabar con la pesadilla de .Net Native. Reducirá su costo y (creo) el doble, el cuádruple.

La buena noticia es que Microsoft ya decidió acabar con .net native. Técnicamente, tenía una serie de restricciones ridículas que no seguían las especificaciones de .net con las que parece que estás más que familiarizado. Creo que fue algo que se hizo rápido/sucio para solucionar los problemas de inicio y rendimiento en Windows Phone y nunca se molestaron en volver y arreglar las cosas desde que Windows Phone murió.

Ahora, Microsoft está desarrollando una compilación AOT completa y de alto rendimiento utilizando tecnologías Mono y LLVM. Esto debería salir el próximo año, creo, y también es útil para Blazor del lado del cliente con ensamblaje web. Miquel de Icaza hizo una buena presentación al respecto a principios de este año en UnoConf: https://www.youtube.com/watch?v=tYk2us6W6Gg (es el primer presentador).

@robloo Bueno, tal vez te equivoqué en algunos puntos.

Entonces, ¿por qué no debería ser técnicamente posible ejecutar WinUI en iOS y Android?

Todo es técnicamente posible. Estaba diciendo que sería extremadamente difícil, ya que fue diseñado e implementado únicamente para Windows. También di el ejemplo de cómo se comunica con el código administrado como algo que creo que sería muy complicado de llevar a cabo en varias plataformas. Sin embargo, sería bueno para todos nosotros si me equivocara aquí.

Silverlight usó la misma tecnología y estaba disponible en la plataforma x.

Y Silverlight está muerto no porque no fuera técnicamente posible, sino porque ya no era un buen caso de negocios, que es realmente mi punto más crítico. Tenga en cuenta que también murió a las mismas tecnologías HTML/CSS/JS que ahora se hacen cargo del desarrollo de escritorio y móvil.

Mi punto aquí es: Silverlight ya se ejecutaba en varias plataformas. Podría usarse con código administrado. La capa de interfaz de usuario UWP Xaml de Windows 8 era básicamente Silverlight, solo que con un nuevo espacio de nombres y algunos metadatos agregados. Ahora ha evolucionado, pero al principio claramente era solo Silverlight Xaml con un nuevo espacio de nombres. Entonces, si podían ejecutar Silverlight multiplataforma en ese entonces, también pueden ejecutar WinUI multiplataforma. Y no creo que esto sea "extremadamente difícil", pero prefiero decir que sería bastante fácil para una gran empresa como Microsoft. Ya tenían una capa de renderizado multiplataforma para Silverlight Xaml. No debería ser demasiado difícil actualizarlo para que pueda ejecutar la última versión de WinUI.

Puede ser que UWP vaya a morir.

Espera, ¿de qué lado estás? ja ja. Pero en serio, considero que WinUI/UWP es esencialmente lo mismo y UWP solo tendrá una evolución menor hacia WinUI sin grandes contratiempos para los desarrolladores.

WinUI es solo una capa de interfaz de usuario de Xaml, mientras que UWP es un marco de aplicación completo y una capa de API del sistema, está vinculado a la Tienda Windows y tiene muchas limitaciones en comparación con las aplicaciones de escritorio clásicas. Así que estas son dos cosas muy diferentes. Realmente no sé si Microsoft ve un futuro en UWP y Windows Store. No solucionar las graves limitaciones de UWP y no trabajar realmente en los problemas de la Tienda Windows no me hace ser muy optimista. Pero definitivamente necesitan algún tipo de marco de interfaz de usuario, y ese será WinUI, sin importar si se usa desde UWP o desde aplicaciones de escritorio. Y si realmente quieren que tenga éxito, deben hacerlo multiplataforma. De lo contrario, las personas se irán a otros marcos y, en algún momento, también podrían abandonar la plataforma Windows por completo. Hacer que WinUI sea multiplataforma sería un medio para que los desarrolladores se adhieran a Windows.

Mi punto aquí es: Silverlight ya se ejecutaba en varias plataformas. Podría usarse con código administrado. La capa de interfaz de usuario UWP Xaml de Windows 8 era básicamente Silverlight, solo que con un nuevo espacio de nombres y algunos metadatos agregados. Ahora ha evolucionado, pero al principio claramente era solo Silverlight Xaml con un nuevo espacio de nombres. Entonces, si podían ejecutar Silverlight multiplataforma en ese entonces, también pueden ejecutar WinUI multiplataforma. Y no creo que esto sea "extremadamente difícil", pero prefiero decir que sería bastante fácil para una gran empresa como Microsoft. Ya tenían una capa de renderizado multiplataforma para Silverlight Xaml. No debería ser demasiado difícil actualizarlo para que pueda ejecutar la última versión de WinUI.

No sabía que la historia del uso de la base Silverlight para UWP/Win8 en ese entonces, si ese es el caso, definible me hace más optimista acerca de cuán factible es esto. ¡Gracias por la corrección!

WinUI es solo una capa de interfaz de usuario de Xaml, mientras que UWP es un marco de aplicación completo y una capa de API del sistema, está vinculado a la Tienda Windows y tiene muchas limitaciones en comparación con las aplicaciones de escritorio clásicas. Así que estas son dos cosas muy diferentes.

Sí, tiene razón y debería haber elegido mi redacción con más cuidado. Ciertamente, UWP en el modelo y el empaquetado de la aplicación seguirá existiendo por ahora. Sin embargo, la capa de la interfaz de usuario cambiará a WinUI, que es lo que estaba tratando de comunicar. Creo que habrá más cambios en los próximos años con el reemplazo de .net nativo, pero el paquete/modelo de aplicación/API introducido con UWP seguirá existiendo de alguna forma. Sin embargo, definitivamente estoy de acuerdo en que es posible que Microsoft no vea un futuro aquí. Afortunadamente, siempre que XAML y C# sigan ahí, la migración a un nuevo modelo de aplicación o empaquetado/distribución suele ser relativamente rápida. Si tan solo Avalonia estuviera acabada...

Y si realmente quieren que tenga éxito, deben hacerlo multiplataforma. De lo contrario, las personas se irán a otros marcos y, en algún momento, también podrían abandonar la plataforma Windows por completo. Hacer que WinUI sea multiplataforma sería un medio para que los desarrolladores se adhieran a Windows.

También estoy de acuerdo contigo al 100% y he dicho lo mismo en varios lugares. Sin embargo, he llegado a la conclusión de que, por varias razones, no va a suceder.

No puedo estar lo suficientemente en desacuerdo con los comentaristas que dicen:

¡WinUI 3.0 debe ser multiplataforma!

1) Necesitamos un marco de interfaz de usuario ahora, no en otros N años cuando el proyecto teórico multiplataforma sea estable.
2) Necesitamos un marco de interfaz de usuario que esté lo más cerca posible del sistema operativo. Con multiplataforma, siempre hay una compensación. El mínimo común denominador para la funcionalidad o la representación de control inconsistente debido a la representación personalizada.

La solución, en mi opinión, es tener otro marco que se construya sobre WinUI 3.0 (si desea mantener Fluent y tiene poco trabajo en renderizado, pruebas de impacto, etc.), o desde cero con WinUI Composición si desea el máximo rendimiento y no le importa hacer todo el renderizado y las pruebas de posicionamiento usted mismo (al costo potencial de no ser consistente).

Recuerdo que vi esas líneas hace unos días:
"El sistema operativo ya no es la capa más importante para nosotros... Lo más importante para nosotros es el modelo de aplicación y la experiencia".
Entonces, es obvio que WinUI debería ser la mejor experiencia de GUI, y creo que lo será, como lo mejor de WPF, UWP y Windows 10,

Pero es obvio que la Web y su antiguo javaScript+HTML se utilizan en todas partes, y sus estructuras y pilas web se utilizan masivamente, no porque sean mejores, sino porque están disponibles en el navegador web del teléfono y en el navegador web de escritorio. Puede crear un archivo HTML en el Bloc de notas, poner una etiqueta de secuencia de comandos con una alerta ('Hola mundo'); y tienes una aplicación.

Entonces veo que es posible e incluso necesario reemplazarlo con .NET+XAML usando WebAssembly. Necesitamos que .NET sea tan omnipresente como lo es javaScript hoy.

Silverlight fue una luz de esperanza... y ahora con WebAssembly, veo que es posible que Silverlight regrese.

Yo estaría feliz con esto:
WinUI es la GUI con sistema operativo completo y al menos un subconjunto de su XAML puede ejecutarse en WebBrowser.

Así que veo al equipo de UNO como muy importante y espero que se unan a Microsoft en un futuro cercano para unir fuerzas en este maravilloso esfuerzo que es WinUI.

@MarkIngramUK Síssss

Haga de WinUI la mejor opción de interfaz de usuario para cualquiera que esté considerando el desarrollo nativo de Windows. Terminar:

• Validación de entrada y un control de cuadrícula de datos nativo
• Las otras ~170 propuestas de características aquí
• Los otros ~300 boletos abiertos
• .NET Native > Migración de .NET Core (para .NET Core 3+5, .NET Standard 2.1+ y C# 8...)
• Nuevo compilador AOT
• Obtenga pautas de diseño fluidas más coherentes que se eliminen y publiquen
• Refinar el sistema de estilo/tema
• Reduzca el énfasis en las funciones de composición que distraen (inclinación, uso intensivo de acrílico, revelación) y concéntrese más en el sistema de profundidad + sombra y animaciones (que aportan claridad y guían a los usuarios)

Estas son las cosas que harán que WinUI sea más atractivo para las personas que lo estén considerando en comparación con Electron en el futuro.

La guinda del pastel sería entonces:

• Herramienta(s) para ayudarte a mantener tu estilo CSS <-> XAML sincronizado
• Directrices para mantener la lógica de la aplicación separada de las vistas para una reutilización máxima del código .NET en otras plataformas
• Alguna herramienta para generar una traducción aproximada única de HTML > controles XAML para que los desarrolladores comiencen con sus aplicaciones WinUI nativas (en lugar de asumir que la mayoría de los desarrolladores comenzarán con aplicaciones XAML y desean dirigirse hacia 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 fue multiplataforma, con todas las funciones y renderizado exactamente igual en todas las plataformas. Qt es multiplataforma, tiene todas las funciones y se muestra exactamente igual en todas las plataformas. Solo obtiene una representación inconsistente y controles de mínimo común denominador si intenta realizar sus controles traduciéndolos internamente a controles nativos de una plataforma diferente (que es lo que intentan hacer Xamarin y Uno). Si realiza la abstracción no en el nivel de control sino en el nivel más bajo (la capa de procesamiento de la GPU), puede obtener el 100 % del mismo resultado en todas las plataformas con el conjunto de control completo. El conjunto de controles ya está ahí, es WinUI 3.0, y es excelente incluso ahora. Lo único que falta son las implementaciones de la capa de representación para las otras plataformas (y podrían tomarse parcialmente de fuentes antiguas de Silverlight).

Realmente me gustaría hacer desarrollo de aplicaciones multiplataforma. Pero ni Xamarin ni Uno me parecen atractivos y realmente no me gusta JS/HTML y todo lo que se basa en él. Desafortunadamente, desarrollar exclusivamente para Windows Store es una mala elección si realmente pretende ganar dinero con él. Al menos tuve experiencias bastante malas con eso, y luego, después de que Microsoft eliminó el ecosistema de Windows Phone, más o menos le puse fin (a pesar de algunos pequeños proyectos "solo por diversión"). Inmediatamente comenzaría a trabajar en nuevas aplicaciones nuevamente si WinUI fuera multiplataforma.

Todos los frameworks multiplataforma actuales tienen limitaciones más o menos severas y/o una mala experiencia de desarrollo. Si Microsoft pudiera hacer que WinUI fuera multiplataforma, realmente podría ser una tecnología revolucionaria. Xamarin ya tiene bastante éxito, a pesar de todas sus ventajas, rincones y limitaciones. Imagínese el éxito que podría tener WinUI si se ejecutara en todas las plataformas con un conjunto completo de funciones y la experiencia de desarrollo de Visual Studio de primer nivel.

@lukasf , este es mi punto:

Silverlight era multiplataforma, con todas las funciones y renderizado exactamente igual en todas las plataformas.

No quiero el mismo renderizado en todas las plataformas. Quiero que cada aplicación se vea consistente con otras aplicaciones en la plataforma de destino. Es por eso que los controles nativos necesitan envolverse, pero eso lleva al mínimo común denominador.

@MarkIngramUK Lo veo así: las aplicaciones simples se adhieren a los controles de la interfaz de usuario estándar de una plataforma. Las grandes aplicaciones tienen su propio look+feel. No necesitan controles de plataforma de valores. Mire Spotify, Netflix u otras aplicaciones excelentes y exitosas disponibles para múltiples plataformas. No se puede saber la plataforma que utilizan, con solo mirar sus controles.

Me gustaría que mis aplicaciones multiplataforma se vieran y se sintieran exactamente igual en todas las plataformas.

@MarkIngramUK Me alegro de que esté tocando la realidad más allá de la teoría. Esta es la realidad para mí: tengo un montón de aplicaciones que evolucionaron desde SL/WP > WinRT > UWP que necesitaban apuntar a múltiples plataformas ayer. Investigué Phonegap/Cordova y pasé mucho tiempo explorando Xamarin muy en serio, y finalmente me di por vencido. Me enamoré de Uno por muchas razones tan pronto como comencé a usarlo. En este momento, no conozco ninguna otra tecnología de plataforma X práctica y prometedora compatible con C# y Xaml que pueda usar en este momento . Cuando WinUI evolucione a una API de plataforma X 1, 2 o 3 años después, la gente de Uno de primer nivel migrará Uno de UWP a WinUI, y todas mis aplicaciones basadas en Uno podrán migrar en consecuencia y rápidamente. No tengo nada de qué preocuparme ahora.
De ninguna manera, estoy en contra de discusiones teóricas intrigantes aquí. Me encanta escuchar todo tipo de ideas.

¿No puede WinUI/MS aprovechar el proyecto Blazor para representar WinUI como una aplicación "Blazor Native"?

Sé que Steve Sanderson presentó Blutter donde Flutter de Google se puede representar usando Blazor (y esa es una interfaz de usuario basada en XML). Parece que el equipo de Blazor tiene buena tecnología en el lado de la representación de la interfaz de usuario para aprovechar diferentes marcos de interfaz de usuario. Si Blazor puede manejar Flutter, debería poder manejar un equivalente de tipo WinUI/Sillverlight.

El potencial es un ecosistema MS menos fragmentado y mucho más poderoso, comenzando en la web y terminando con aplicaciones nativas x-platform usando un .net 5 unificado.

@lukasf :

@MarkIngramUK Lo veo así: las aplicaciones simples se adhieren a los controles de la interfaz de usuario estándar de una plataforma. Las grandes aplicaciones tienen su propio look+feel. No necesitan controles de plataforma de valores. Mire Spotify, Netflix u otras aplicaciones excelentes y exitosas disponibles para múltiples plataformas. No se puede saber la plataforma que utilizan, con solo mirar sus controles.

Me gustaría que mis aplicaciones multiplataforma se vieran y se sintieran exactamente igual en todas las plataformas.

Combinamos ambos enfoques para nuestras aplicaciones (https://affinity.serif.com). Nuestros clientes pueden expresarse bastante si no adoptamos los estándares comunes de la plataforma, por ejemplo, el orden de los botones en los cuadros de diálogo (normalmente, Windows es Aceptar y luego Cancelar, mientras que macOS es Cancelar y luego Aceptar), botones con esquinas redondeadas, estados de desplazamiento, casillas de verificación frente a interruptores, diseño de controles, etc. Así que sí, en la superficie, nuestras aplicaciones se ven iguales en las plataformas Windows y macOS, pero tenemos diferencias sutiles (representación e interacción de la interfaz de usuario). También aprovechamos al máximo nuestra plataforma de host mediante el uso de sus API nativas y, por lo tanto, nunca estamos sujetos a problemas del mínimo común denominador.

Sigo pensando que la discusión anterior es engañosa, WinUI es el marco de interfaz de usuario de nivel más bajo que proporciona Microsoft. Si desea una biblioteca multiplataforma, construya sobre eso. Es el equivalente a decir "¡Win32 debería ser multiplataforma!". No, Win32 debería ser el mejor marco para la plataforma Windows. Es el mismo argumento aquí, WinUI debería ser el mejor marco para la plataforma Windows 10.

@MarkIngramUK escribió:

WinUI es el marco de interfaz de usuario de nivel más bajo que proporciona Microsoft. Si desea una biblioteca multiplataforma, construya sobre eso.

Eso me parece una solución práctica que realmente podría tener éxito, dependiendo de los detalles (aunque no necesariamente la única solución). Dos capas:

1. Microsoft WinUI: no multiplataforma.
2. Microsoft CrossXYZ-UI: multiplataforma. Su implementación interna para Windows se escribiría utilizando WinUI.

Tal solución de 2 capas ayudaría a mitigar el problema que mencioné en mi mensaje original:

Las versiones potencialmente nuevas de WinUI pueden retrasarse sustancialmente debido a la mayor cantidad de trabajo/dificultad de mantener la compatibilidad con múltiples sistemas operativos diferentes. Por ejemplo, "Podríamos haber lanzado esta nueva versión de WinUI hace meses, excepto por el problema de que hemos terminado de depurarlo solo para Windows y aún no para Android ni MacOS ni Apple iOS".

De acuerdo con mi experiencia con el desarrollo multiplataforma en el pasado, me gustaría señalar que esta solución de 2 capas tendría más éxito si se implementaran varios cambios/adiciones en WinUI con el fin de admitir y ayudar a la multiplataforma separada "CrossXYZ -UI" capa. De lo contrario, si WinUI no hace nada para ayudar a la capa multiplataforma, entonces, en mi experiencia, esto generalmente significa que la capa multiplataforma a menudo se ve obligada a saltar aros retorcidos que dificultan y retrasan la programación y la confiabilidad.

De acuerdo con la teoría de capas, WinUI no necesita saber o preocuparse por una capa "CrossXYZ-UI" que usa WinUI, pero esa teoría funciona mal en la práctica en el mundo real, por lo tanto, digo que WinUI debería tener en cuenta y ayudar a la capa "CrossXYZ-UI", pero no me refiero a la horrible idea de crear dependencias en "CrossXYZ-UI" dentro de WinUI, y no me refiero a ganchos privados especiales dentro de WinUI que solo son utilizados por "CrossXYZ-UI ". Las 2 capas aún deben mantenerse separadas de manera limpia. Solo digo que cuando se toman decisiones de diseño de API para WinUI, estas decisiones deberían tomarse teniendo en cuenta su impacto en la capa separada "CrossXYZ-UI", y teniendo en cuenta cómo WinUI puede hacer la vida más fácil para el " CrossXYZ-UI", no solo teniendo en cuenta las aplicaciones que usan WinUI directamente.

No sé si Xamarin ya intenta operar de la manera de 2 capas descrita anteriormente, pero si lo hace, imagino que actualmente excluye la parte de la idea en la que WinUI admite/ayuda a la capa multiplataforma separada. Es difícil confiar en Xamarin cuando Microsoft no confiaba lo suficiente en Xamarin como para usarlo para Microsoft Teams y otras aplicaciones de Microsoft.

En el pasado, publiqué software multiplataforma que funcionaba con éxito y con buen rendimiento, pero terminé cancelando el trabajo multiplataforma por razones no técnicas. Por ejemplo, los clientes que usaban la versión Linux del software insistieron en que el precio del software debería ser de $0. Por lo tanto, el costo de producir y mantener la versión de Linux excedía con creces los $0 de ingresos de los "clientes" que usaban Linux, por lo que obviamente era insostenible.

Como desarrollador de aplicaciones, el hecho de que _pueda_ producir teóricamente una aplicación multiplataforma no siempre significa que _debería_. Curiosamente, hoy en día noto en las discusiones multiplataforma que la gente menciona Android pero ya no Linux. Una de las principales razones de este cambio es probablemente el problema de $0 antes mencionado.

Plataforma Re Uno:

Incluso si Uno tiene un diseño e implementación técnica buenos, sólidos y confiables, el riesgo y la preocupación es que Uno podría desaparecer en unos pocos años debido a un problema similar de $0 o ingresos insuficientes que eventualmente desencadena el agotamiento y la cancelación o estancamiento del proyecto. O simplemente el desarrollador más importante de Uno un día, de repente obtiene un nuevo pasatiempo/interés/obsesión y pierde interés en Uno, o un nuevo trabajo/empleador y no tiene más tiempo para trabajar en Uno. Como dijo @mdtauk :

muchas empresas que buscan invertir en la creación de una aplicación o sistema necesitan saber que la plataforma para la que están desarrollando tiene el soporte y la longevidad de una gran empresa con vastos recursos como Microsoft.

También estoy de acuerdo con el otro comentario de @mdtauk :

El problema con ese argumento es que la última década ha mostrado a Microsoft abandonando plataformas,

Sí, Microsoft ha perdido cierto grado de reputación/confiabilidad/confianza debido a la cancelación de plataformas. Creo que Microsoft debe tener cuidado para evitar una mayor pérdida de reputación y confiabilidad a través de más cancelaciones. Una nueva versión de una plataforma existente es mejor que una nueva plataforma.

Incluso si una nueva versión importante de una plataforma existente necesita introducir cambios importantes, sigue siendo mejor (o menos mala) que una nueva plataforma con la consiguiente pérdida de reputación/confiabilidad/confianza. Para los desarrolladores de aplicaciones, el costo de cambiar a una nueva plataforma es muy alto y, a veces, completamente inasequible, por lo tanto, cada vez que Microsoft cancela una plataforma, es una muy mala noticia y daña la relación/asociación entre el desarrollador de la aplicación y Microsoft.

Si les parece tan atractivo ese enfoque de dos capas, pueden continuar ahora mismo y usar Xamarin o Uno. No tiene que esperar a tales marcos, ya están ahí y funcionan muy bien. Pero perderá todos los beneficios y mejoras de WinUI tan pronto como apunte a Android o iOS. No más NavigationView, no AppBars, no más SemanticZoom, etc., etc. Cualquier cosa que se haga en este repositorio, todas las mejoras no están disponibles entre plataformas, porque entre plataformas significa el mínimo común denominador. Solo puede usarlos si se dirige específicamente a la plataforma Windows. Por lo tanto, tendrá que volver a implementar todas las cosas geniales de WinUI nuevamente manualmente, usando los controles nativos de Android o iOS.

Si eso le parece bien, simplemente use Xamarin o Uno. No hay necesidad de un tercer marco como este. Pero a mí esto no me suena nada bien. Quiero un marco con un gran conjunto de controles, que se pueda usar para apuntar a todas las plataformas directamente, con funcionalidad completa en cada plataforma. No quiero volver a implementar la navegación y las cosas de mi aplicación en cada plataforma por separado, con definiciones de interfaz de usuario complicadas y duplicadas. A mí me parece una idea horrible. Si WinUI fuera multiplataforma usando un enfoque de renderizador, podría usar directamente todas sus funciones y todas las mejoras aquí en cada plataforma. Y si quisiera que mis controles se parecieran más a iOS en ese objetivo, podría simplemente aplicar un ResourceDictionary de iOS. Problema resuelto, sin tener que meterse con controles nativos e implementaciones de interfaz de usuario duplicadas.

El argumento de que los lanzamientos se retrasarían porque "no se actualizó un renderizador para otra plataforma" es un argumento poco realista. Una capa de representación funciona con comandos de dibujo de bajo nivel como "dibujar rectángulo, dibujar línea, dibujar texto". Si agrega un nuevo control a WinUI, escribe su lógica de control y proporciona una plantilla de control, que usa Grid, Borders, TextBoxes y cosas por el estilo. Ningún control nuevo requerirá actualizaciones de los renderizadores, los renderizadores tendrán un nivel muy bajo y una tasa de cambios muy baja. Solo hay casos excepcionales en los que sería necesario tocar los renderizadores, por ejemplo, al agregar nuevos pinceles o efectos. Qt utiliza el enfoque de representación y es uno de los marcos de interfaz de usuario multiplataforma más populares. El enfoque parece funcionar muy bien para ellos.

@lukasf

Quiero un marco con un gran conjunto de controles, que se pueda usar para apuntar a todas las plataformas directamente, con funcionalidad completa en cada plataforma.

Cada ingeniero y cada dólar gastado en hacer que WinUI sea multiplataforma es un ingeniero y cada dólar que podría haberse usado para mejorar WinUI en Windows.

El argumento de que los lanzamientos se retrasarían porque "no se actualizó un renderizador para otra plataforma" es un argumento poco realista.

No es solo una tarea simple crear un motor de renderizado 1:1 perfecto que funcione en iOS, Android, MacOS, Linux y Windows 7/8. Hay una gran cantidad de API de Windows 10 en las que se basan las aplicaciones y el marco. Básicamente, estaría creando un marco de aplicación completamente nuevo.

Además, mire este hilo reciente de Reddit: ¿Qué debo usar para la interfaz de usuario en C#?

Literalmente, cero menciones de WinUI y una sola recomendación a medias para usar UWP. Los desarrolladores deben estar entusiasmados con el uso de WinUI en Windows mucho antes de intentar hacerlo multiplataforma, considerando todas las enormes inversiones que requeriría.

@lukasf ,

puedes continuar ahora mismo y usar Xamarin o Uno

Lo mencioné en mi publicación anterior, pero escribimos front-end separados para cada plataforma a la que nos dirigimos. Windows (WPF), macOS (Cocoa), iOS (UIKit).

si quisiera que mis controles se parecieran más a iOS en ese objetivo, podría simplemente aplicar un ResourceDictionary de iOS. Problema resuelto

Hasta que el usuario actualice su sistema operativo y todas las aplicaciones cambien de apariencia, excepto la tuya.

Una capa de representación funciona con comandos de dibujo de bajo nivel como...

Necesita más que renderizar para multiplataforma. Gestión de ventanas, entrada, manejo de texto, representación, integración de sistemas (p. ej., barra de tareas, Aero Peek, etc.). No hay forma de que intentar cambiar el enfoque de WinUI de solo Windows a multiplataforma no cause una demora extrema.

En términos de representación, WinUI se basa en Windows.UI.Composition , por lo que tendría que reemplazar por completo esa biblioteca de nivel inferior, con algo que fuera multiplataforma y, con suerte, no incurrir en ninguna penalización de rendimiento por su abstracción, y luego portar a otras plataformas. O bien, reescriba completamente WinUI para que no dependa de Windows.UI.Composition . Una vez más, no es un trabajo pequeño.

Solo para reiterar: no estoy en contra de las bibliotecas multiplataforma. Tienen un propósito, simplemente no creo que WinUI deba convertirse en uno.

@lukasf

porque multiplataforma significa mínimo común denominador. …... Quiero un marco con un gran conjunto de controles, que se pueda usar para apuntar a todas las plataformas directamente, con funcionalidad completa en cada plataforma.

Lo quieres con funcionalidad completa en todas las plataformas, yo también, suena maravilloso; un sueño, pero solo porque tú y yo lo queramos, no significa que deba ser posible y práctico. El deseo y el resultado podrían ser muy diferentes. El deseo podría ser una funcionalidad completa, mientras que el resultado termina siendo principalmente el mismo problema que mencionó: el mínimo común denominador. Tu idea tiene mérito, pero no es inmune a ser víctima del problema del mínimo común denominador que mencionaste.

Si WinUI fuera multiplataforma usando un enfoque de renderizador, podría usar directamente todas sus funciones y todas las mejoras aquí en cada plataforma.

¿Realmente TODAS sus características y CADA mejora en CADA plataforma? ¿Está seguro de que se puede lograr un objetivo tan impresionante simplemente basando WinUI en un renderizador multiplataforma? ¿Tan fácil es la solución? Creo que está haciendo que la idea parezca mucho más fácil de lo que es en realidad, porque en realidad se requiere mucho más que el renderizador, como:

• Gestión de ventanas más controles flotantes, ventanas emergentes, menús contextuales, cuadros de diálogo modales.
• Gestión de pantallas y resoluciones y respuesta a cambios.
• Dispositivos de entrada (teclado, mouse, pantalla táctil con gestos, lápiz).
• Animación.
• Fuentes y estilos, obteniendo información y medidas, no solo renderizado. También procesamiento de texto Unicode.
• Arrastrar y soltar.
• Portapapeles para cortar/copiar/pegar que funciona con varios formatos, no solo texto.
• Desplazamiento con buen rendimiento, a diferencia del terrible rendimiento de desplazamiento de los paneles de chat en MS Teams.
• Leer/cargar recursos (de varios tipos) almacenados dentro del paquete de la aplicación, como recursos de imagen y otros.
• Reproducción de audio y vídeo.
• Automatización para lectores de pantalla, etc. para accesibilidad.
• Tema/apariencia coherente con lo que esté configurado actualmente en el sistema operativo.
• Recuperación de varias configuraciones del sistema operativo que afectan la GUI, como el formato internacional, la configuración del mouse y el teclado, etc.
• Problemas para admitir dispositivos móviles, tabletas y computadoras de escritorio.
• Y varias otras cosas más cientos de detalles que se olvidan fácilmente al estimar el tamaño del proyecto y la fecha de lanzamiento.

Sigo pensando que su idea tiene mérito, pero es mucho más difícil y mucho menos clara de lo que hizo parecer. También podría ralentizar mucho el desarrollo y el progreso de WinUI.

¿No puede WinUI/MS aprovechar el proyecto Blazor para representar WinUI como una aplicación "Blazor Native"?

@pinox , sí, definitivamente podríamos, pero entonces Blazor Native no sería multiplataforma, a menos que apuntaran a Uno (que sería mi preferencia personal).

La multiplataforma es definitivamente algo en lo que hemos pensado, y hemos realizado algunas investigaciones bastante exhaustivas de diferentes arquitecturas de marcos multiplataforma. Hemos llegado a las mismas conclusiones que todos en este hilo, que ambas soluciones tienen pros y contras, y que nuestros clientes están bastante divididos 😃

@lukasf Creo que el "mínimo común denominador" que existe actualmente en Uno es un problema de limitación de recursos, y no debido a la estratificación. Me encantaría que se demuestre que estoy equivocado, pero creo que ese problema podría resolverse y no empeorar en el futuro.

Hay un subconjunto de XAML para ofrecer la representación de ventanas y controles de interfaz de usuario de aspecto nativo, o puede tener el representador en macOS, iOS, Android, Linux, y representar los mismos controles y plantillas "fluidos" en todas las plataformas.

Además de hacer algún tipo de variante de la implementación de CoreWindow / App Window para que funcione con el sistema operativo nativo, todo lo que se encuentra dentro de la ventana podría renderizarse.

En Windows es DirectX, pero Apple tiene Metal y Linux tiene OpenGL. Los desarrolladores tendrían que hacer algún tipo de declaraciones IF para manejar archivos nativos IO, notificaciones, etc., pero Xamarin ayudaría con eso.

@stevenbrix -- Veo que respondiste a la idea de @Pinox _"procesar WinUI como una aplicación nativa de Blazor",_ pero ¿qué opinas sobre la _otra_ idea de Pinox? Curiosamente, @Pinox también escribió:

Actualmente, Electron usa Javascript, HTML + CSS. No hay razón por la que no podamos usar Electron con Blazor => C#, HTML + CSS + gRPC.

@Pinox : estaría de acuerdo en que "Electron C#" parecería tener mucho más sentido que "Electron JS", pero si usa C# y Blazor como sugirió, entonces creo que la aplicación MS Teams probablemente no necesitaría Electron más porque Blazor reemplazaría por completo a Electron? Podría estar equivocado: no sé lo suficiente sobre las funciones que admite Electron. Aunque, si ElectronJS actualmente tiene alguna característica útil de la que carece Blazor, entonces esta característica faltante podría admitirse en la próxima versión de Blazor, potencialmente.

Así que supongo que planteaste un punto importante al mencionar a Blazor. Una solución decente para la aplicación MS Teams podría ser cambiar de ElectronJS a Blazor + WebAssembly. Eso es realmente interesante.

Si la aplicación MS Teams cambió de ElectronJS a Blazor, entonces podría o no usar alguna parte de WinUI. Se podría explorar más a fondo la conexión o no conexión entre Blazor y WinUI, como ya comenzó a hacer. ¡Interesante!

Silverlight, WinRT, UWP: todos fueron abandonados. (Sé que UWP no lo es técnicamente, pero lo más probable es que WinUI se vea como un reemplazo).

Tengo entendido que UWP es el tiempo de ejecución, mientras que WinUI es la GUI/capa de widget/etc. Es decir, Win UI se ejecutará en Win32 o .NET, sin la API de UWP.

Lo que me vuelve loco es que UWP es en realidad una API bastante competente. No es tan potente como Win32, pero comparado con Android (por ejemplo) es mucho más sensato. Creo que los desarrolladores han perdido el punto de que ahora hay una API de tiempo de ejecución unificada, que tiene un modelo de objeto consistente, API, no es obtuso, etc., etc.... ¿Alguien más aquí escribió aplicaciones Win32 en los años 90 o principios? 00s antes de que .NET apareciera en escena? El uso de las API de la plataforma nativa fue terrible.

Volviendo al tema en cuestión, me encantaría ver WinUI multiplataforma. Hay publicaciones sobre su vinculación a COM, etc. El marco del complemento Core Foundation (CFPlugin) de Apple es, IIRC, basado en COM, por lo que tal vez un ascensor y un cambio serían tan simples como escribir un renderizador para las plataformas de Apple. Lo más lógico sería ocultar las diferencias de plataforma y mantener los objetos WinUI de alto nivel.

Me encantaría ver un esfuerzo cohesivo y multiplataforma de Microsoft, que apuntara principalmente a Windows, pero comprara un modelo de objetos completamente compatible y un dialecto XAML para dispositivos móviles, Linux y macOS. Ya existe un fantástico ecosistema multiplataforma (menos una GUI) en .NET Core. Atornille un marco XAML competente y sería una obviedad para todo el desarrollo del lado del cliente, especialmente si las imágenes pudieran parecer nativas. Por ejemplo, CommandBar -> Apariencia de NSToolbar en Mac, Vista de navegación -> NSOutlineView en Mac, etc.

Mi valor de 2c, pero veo un gran enfoque en esto.

También tengo la esperanza (aunque no aguantaré la respiración) de que Microsoft vuelva a entrar en el mercado con un teléfono basado en Windows. Ser un entorno multiplataforma convincente ayudaría enormemente a este objetivo.

Seguiré esta discusión con interés.

Silverlight, WinRT, UWP: todos fueron abandonados. (Sé que UWP no lo es técnicamente, pero lo más probable es que WinUI se vea como un reemplazo).

Tengo entendido que UWP es el tiempo de ejecución, mientras que WinUI es la GUI/capa de widget/etc. Es decir, Win UI se ejecutará en Win32 o .NET, sin la API de UWP.

Técnicamente, creo que WinRT (Windows RunTime) es el tiempo de ejecución, y UWP (Universal Windows Platform) se basa en ese tiempo de ejecución. Y UWP admite el uso de XAML como un marco de interfaz de usuario.

WinUI será la parte XAML de UWP, pero ampliada para permitir su uso con código Win32, con interoperabilidad a través de islas XAML con los marcos WPF y WinForms.

Lo que me vuelve loco es que UWP es en realidad una API bastante competente. No es tan potente como Win32, pero comparado con Android (por ejemplo) es mucho más sensato. Creo que los desarrolladores han perdido el punto de que ahora hay una API de tiempo de ejecución unificada, que tiene un modelo de objeto consistente, API, no es obtuso, etc., etc.... ¿Alguien más aquí escribió aplicaciones Win32 en los años 90 o principios? 00s antes de que .NET apareciera en escena? El uso de las API de la plataforma nativa fue terrible.

UWP está diseñado con un enfoque moderno de la duración de la batería, la seguridad, la identidad, la validación de la tienda: todo lo que los desarrolladores esperan de plataformas como macOS, iOS y Android. Es debido a esas cualidades inherentes que puede funcionar en muchos factores de forma y tipos de dispositivos.

Volviendo al tema en cuestión, me encantaría ver WinUI multiplataforma. Hay publicaciones sobre su vinculación a COM, etc. El marco del complemento Core Foundation (CFPlugin) de Apple es, IIRC, basado en COM, por lo que tal vez un ascensor y un cambio serían tan simples como escribir un renderizador para las plataformas de Apple. Lo más lógico sería ocultar las diferencias de plataforma y mantener los objetos WinUI de alto nivel.

Cuando tiene en cuenta la compatibilidad con .NET Core, que ya es compatible con varias plataformas, la capa de la interfaz de usuario es la parte que falta. Inicialmente, WinUI está completamente enfocado en Windows, pero con el tiempo, Microsoft puede refactorizarlo de tal manera que las plataformas puedan sustituir su propia representación, lo que permitiría que la interfaz de usuario idéntica se ejecute en múltiples plataformas.

Me encantaría ver un esfuerzo cohesivo y multiplataforma de Microsoft, que apuntara principalmente a Windows, pero comprara un modelo de objetos completamente compatible y un dialecto XAML para dispositivos móviles, Linux y macOS. Ya existe un fantástico ecosistema multiplataforma (menos una GUI) en .NET Core. Atornille un marco XAML competente y sería una obviedad para todo el desarrollo del lado del cliente, especialmente si las imágenes pudieran parecer nativas. Por ejemplo, CommandBar -> Apariencia de NSToolbar en Mac, Vista de navegación -> NSOutlineView en Mac, etc.

Tan pronto como comience a verlo de esta manera, donde está traduciendo los controles y conceptos de Windows a Platform Native, termina con Xamarin Forms. Su objetivo es un enfoque de mínimo común denominador, en lugar de permitir que una interfaz de usuario idéntica se ejecute en todas partes.

Mi valor de 2c, pero veo un gran enfoque en esto.

También tengo la esperanza (aunque no aguantaré la respiración) de que Microsoft vuelva a entrar en el mercado con un teléfono basado en Windows. Ser un entorno multiplataforma convincente ayudaría enormemente a este objetivo.

Seguiré esta discusión con interés.

Creo que una parte de esta historia, aún por detallar, es permitir que las aplicaciones UWP se compilen y se ejecuten en Android, lo que resolvería el problema de las aplicaciones que se ejecutan en Surface Duo.

Estaba el proyecto Astoria... El Android en Windows Bridge, que podría llegar a Windows para permitir que las aplicaciones de Android lleguen a Microsoft Store. Una vez que Microsoft tiene su propio código base de Android, eso hace que la perspectiva sea más fácil de concebir.

Veo que respondiste a la idea de @Pinox "representar WinUI como una aplicación nativa de Blazor", pero ¿qué opinas sobre la otra idea de Pinox? Curiosamente, @Pinox también escribió:

Actualmente, Electron usa Javascript, HTML + CSS. No hay razón por la que no podamos usar Electron con Blazor => C#, HTML + CSS + gRPC.

Estoy de acuerdo en que "Electron C#" parecería tener mucho más sentido que "Electron JS", pero si usa C# y Blazor como sugirió, entonces creo que la aplicación MS Teams probablemente ya no necesite Electron porque Blazor lo haría. ¿Reemplazar completamente a Electron? Podría estar equivocado: no sé lo suficiente sobre las funciones que admite Electron. Aunque, si ElectronJS actualmente tiene alguna característica útil de la que carece Blazor, entonces esta característica faltante podría admitirse en la próxima versión de Blazor, potencialmente.

@verelpode según tengo entendido, Electron siempre tendrá que estar en la imagen. Si Teams se mudara hipotéticamente a Blazor, todavía querrían una aplicación de cliente independiente como la que tienen hoy, y Electron tiene más sentido para ellos. En teoría, alguien puede corregirme si me equivoco, pero cambiar a Blazor + WebAssembly mejoraría mucho el rendimiento de su aplicación cuando se ejecuta en Electron. Aunque apostaría a que sus problemas de rendimiento se deben más a problemas de arquitectura que a cualquier otra cosa, VS Code es una aplicación de Electron y estoy muy impresionado con el rendimiento allí.

Tenga en cuenta que WebAssembly también puede ejecutarse fuera de WebBrowser...
Veo a Blazor como una forma de los que vienen de ASP.Net, un experimento que trae .NET al WebBrowser, pero la ruta más completa sería XAML en .NET Core, Xamarin, UWP/WinUI y UNO; El XAML completo en WinUI/Windows 10 y una parte de su XAML también se puede ejecutar en la Web.

@verelpode @stevenbrix Tengo entendido que Blazor se ejecuta en el cable en Electron. Entonces, directamente de .net core a Electron con el uso de gRPC. Por lo tanto, el canal gRPC se comunica con electron y ya no con el renderizador JS, supongo. Por favor, corrígeme si me equivoco. No hay WASM involucrado.

Sería muy interesante ver las mejoras de velocidad usando gRPC directamente con Electron. En mi opinión, puede ser enorme si se optimiza.

En el clip de YouTube de Steve Sanderson, menciona el uso de no WASM (53:13 min en el video)
https://www.youtube.com/watch?v=uW-Kk7Qpv5U

No recuerdo dónde leí la parte de gRPC. De todos modos, ¿por lo tanto, estoy investigando a la comunidad si es posible algo como un equivalente Silverlight de WinUI usando gRPC con Electron? No WASM, en el cable, por así decirlo.

@verelpode @stevenbrix Tengo entendido que Blazor se ejecuta en el cable en Electron. Entonces, directamente de .net core a Electron con el uso de gRPC. Por lo tanto, el canal gRPC se comunica con electron y ya no con el renderizador JS, supongo. Por favor, corrígeme si me equivoco. No hay WASM involucrado.

Sería muy interesante ver las mejoras de velocidad usando gRPC directamente con Electron. En mi opinión, puede ser masivo.

En el clip de YouTube de Steve Sanderson, menciona el uso de no WASM (53:13 min) en el video.
https://www.youtube.com/watch?v=uW-Kk7Qpv5U

¡Gracias @Pinox! ¡Parece que tengo algo que ver! Lo que estás describiendo suena como Blazor del lado del servidor para mí, estaba pensando/hablando del lado del cliente que se ejecuta en el navegador y manipula directamente el DOM. No diré más hasta después de ver ese video, porque podría estar poniendo mi pie en mi boca al decir esas cosas 😄

@stevenbrix , es posible que tenga razón, pero la aplicación de electrones se ejecuta sin conexión, por lo que asumo que esto no es una representación del lado del servidor.

Supongo que si el renderizador JS usó gRPC para hablar con Electron, entonces puede usar el motor blazor razor para hacer lo mismo.

gRPC es una característica nueva en .net core 3.0. Blazor admite .net core 3.
Por lo tanto, gRPC en .net core 3 abre la posibilidad de reemplazar las tecnologías JS existentes con c# mediante el uso del "enlace común" (gRPC). Movimiento inteligente MS ;))

pero la aplicación de electrones se ejecuta sin conexión, por lo que asumo que esto no es una representación del lado del servidor.

@Pinox : sí, eso me tiene un poco desconcertado. Supongo que está usando https://github.com/ElectronNET/Electron.NET , pero eso es puramente especulativo

Si la aplicación MS Teams cambió de ElectronJS a Blazor, entonces podría o no usar alguna parte de WinUI. Se podría explorar más a fondo la conexión o no conexión entre Blazor y WinUI, como ya comenzó a hacer. ¡Interesante! >

@verelpode lo que hace que esta imagen sea muy emocionante es el "alcance" de Blazor. Como experto en aplicaciones, puedo decir que mi experiencia limitada con Blazor hasta ahora es => wow, esto se siente extremadamente eficaz, casi como una aplicación. Mirando la imagen, es casi seguro que la hoja de ruta incluirá WinUI como plataforma nativa. (aunque no comprometido actualmente)

Si pueden hacer que flutter funcione en el lado de Blazor Native, ¿qué impide que el equipo de Blazor conecte la plataforma React Native para llegar a todas esas plataformas nativas? Blazor puede convertirse fácilmente en el pegamento para los desarrolladores de C# en todo.

Para mí, el objetivo a corto plazo es subirme al autobús con una interfaz de usuario HTML para complementar mi WinUI existente.
Entre WinUI/Xamarin y Blazor no hay casi nada que no pueda hacer. Una base de código, 3 marcos de interfaz de usuario. Va a ser extremadamente emocionante ver a dónde va esto porque las opciones parecen infinitas.

Para mí, lo último siempre es super .net core (C#) => Blazor ??? => interfaz de usuario nativa: será el máximo esfuerzo de ingeniería.

¡Tengo que decir que esta es una discusión muy inspiradora! Muchos puntos de vista y argumentos diferentes, muchos hechos que ni siquiera sabía ("¿Blazor + interfaz de usuario nativa? Wow").

Como @stevenbrix ya mencionó, parece haber una división en la comunidad entre aquellos a quienes les gustaría ejecutar exactamente la misma interfaz de usuario en diferentes marcos (enfoque de renderizador) y aquellos a quienes les gustaría renderizar en cada plataforma usando los controles nativos. Ambos enfoques tienen sus ventajas y desventajas. Estoy de acuerdo con @stevenbrix en que con suficiente mano de obra, el problema del "mínimo común denominador" podría superarse (por ejemplo, un control WinUI que no está disponible de forma nativa en la plataforma X podría realizarse internamente en Uno mediante un grupo de controles nativos de nivel inferior de esa plataforma X, o con representación personalizada parcial). Entonces podríamos tener casi todo el conjunto de controles de WinUI disponible, pero aún así obtener una representación nativa. Desafortunadamente, los recursos de Uno parecen ser bastante limitados en este momento, dada la gran cantidad de problemas abiertos en su github.

Lo que es obvio aquí es que existe una gran demanda en la comunidad de un marco multiplataforma atractivo, de alto rendimiento. Y ninguno de los marcos actualmente disponibles satisface realmente ninguno de los dos lados de la comunidad (dividida). Será muy interesante ver si Microsoft tiene algún plan para mejorar la situación.

Diría que, con Surface Duo y Neo en el horizonte, Microsoft debe idear una historia adecuada sobre cómo desarrollar aplicaciones multiplataforma que se ejecuten tanto en Surface Duo como en Surface Neo. Tal vez Microsoft debería comprar Uno y financiarlos adecuadamente, para que puedan solucionar todos esos problemas abiertos y agregar más soporte de control. O desarrolle una capa de representación de Android para WinUI. Con los dispositivos planeados para las vacaciones de 2020, las cosas deben comenzar a moverse muy pronto.

@lukasf

con suficiente mano de obra, el problema del "mínimo común denominador" podría superarse

Suficiente mano de obra... Estoy de acuerdo con todo en su mensaje, pero también me gustaría enfatizar la desventaja significativa que mencionó @kmgallahan :

Cada ingeniero y cada dólar gastado en hacer que WinUI sea multiplataforma es un ingeniero y cada dólar que podría haberse usado para mejorar WinUI en Windows.

Estoy dividido porque, por un lado, la multiplataforma sería excelente (si realmente funciona bien), pero por otro lado, no me gustaría la multiplataforma si causa grandes retrasos en la solución de varios problemas en WinUI. en Windows, o si atasca demasiado el progreso de WinUI y bloquea las mejoras y las nuevas funciones.

¿Qué pasa si el tema multiplataforma significa que todos estamos obligados a elegir entre uno de los siguientes resultados?

1. Una excelente versión de WinUI que se ejecuta solo en Windows; o
2. WinUI de calidad media, poco confiable y/o lento que se ejecuta en todas las plataformas y que sufre de un ritmo de desarrollo terriblemente lento con muchos problemas pendientes que permanecen sin solucionar durante 5 a 10 años.

Ese es un gran problema que tendría que ser prevenido. En el entusiasmo por la multiplataforma, es muy fácil dejar de prestar atención accidentalmente a la prevención de este gran problema.

¿Qué pasa si el tema multiplataforma significa que todos estamos obligados a elegir entre uno de los siguientes resultados?

1. Una excelente versión de WinUI que se ejecuta solo en Windows; o

2. WinUI de calidad media, poco confiable y/o lento que se ejecuta en todas las plataformas y que sufre de un ritmo de desarrollo terriblemente lento con muchos problemas pendientes que permanecen sin solucionar durante 5 a 10 años.

@verelpode Primero, estás exagerando mucho aquí. Segundo: Microsoft tiene vastos recursos disponibles. No debería ser un problema financiar tanto las mejoras nativas de WinUI como una solución multiplataforma, si Microsoft está realmente interesado en proporcionar un marco multiplataforma. De hecho, lo están haciendo ahora mismo: desarrollan y mejoran WinUI y, al mismo tiempo, desarrollan y mejoran Xamarin. Tienen muchos proyectos en marcha al mismo tiempo. Entonces, si Microsoft está realmente comprometido a proporcionar tanto un excelente marco de interfaz de usuario de Windows (lo que seguro es así) como un marco multiplataforma (que tendría mucho sentido con Surface Neo y Duo en el horizonte), entonces no tenemos elegir. Ambos se pueden realizar sin compromiso. (Y, en general, no es algo que podamos elegir. Microsoft tomará sus decisiones y veremos cuál es el resultado).

Por lo tanto, financiar un marco multiplataforma no significa en absoluto que el desarrollo y la estabilidad de WinUI tengan que sufrir. Si se eligió la estrategia Uno, Uno es completamente independiente de WinUI, porque se encuentra en la parte superior. WinUI puede evolucionar aún más, y Uno intenta adquirir nuevos controles y conceptos de WinUI (probablemente a un ritmo más lento). Además, si se eligió un enfoque de renderizador, no significa que retrasará WinUI en Windows. Es posible que se lance una nueva versión de WinUI, pero todavía no hay un renderizador de Android. Luego, el desarrollo multiplataforma usaría la versión anterior de WinUI, hasta que el renderizador de Android se actualice a WinUI vLatest. Los desarrolladores de Windows podrían usar WinUI vLatest desde el principio. Si los recursos están ahí, ambos pueden desarrollarse al mismo ritmo.

@lukasf

Microsoft tiene vastos recursos a mano.

Cierto, cierto, pero existe otro aspecto que también es cierto: muchos gerentes de proyecto han aprendido por las malas que invertir más dinero, personal y recursos en un proyecto no necesariamente produce el éxito.

Microsoft tiene vastos recursos a mano.

Cierto, cierto, pero existe otro aspecto que también es cierto: muchos gerentes de proyecto han aprendido por las malas que invertir más dinero, personal y recursos en un proyecto no necesariamente produce el éxito.

Entonces el problema puede ser esos gerentes de proyecto y la estructura organizacional ;)

Tal vez Microsoft debería comprar Uno y financiarlos adecuadamente, para que puedan solucionar todos esos problemas abiertos y agregar más soporte de control.

Sé que nventive ha estado cortejando a Microsoft durante los últimos meses (una adquisición de Microsoft es probablemente su estrategia de salida). En Uno Conference también hubo una gran participación de Microsoft. Incluso Xamarin está usando Uno ahora para admitir la web.

Sé que podemos debatir las opciones (1) representaciones nativas u (2) otra implementación/capa de interfaz de usuario sin cesar, pero observando lo que está disponible ahora y lo que necesitamos para Surface Duo, Uno es en realidad la única solución que tiene sentido. Como dijo @lukasf , Microsoft debería invertir sus recursos y ver qué tan lejos pueden llegar en un año. Si tiene éxito (característica completa, estable), no creo que a los desarrolladores les importe mucho cómo se implementa entre bastidores. Si se hace evidente que el enfoque correcto es WinUI representado de forma nativa para cada plataforma, eso puede ser una discusión durante algunos años en el futuro. En este momento, es mejor comenzar con una plataforma Uno completa en un 25 % que nada en absoluto.

@stevenbrix aquí :

@lukasf Creo que el "mínimo común denominador" que existe actualmente en Uno es un problema de limitación de recursos, y no debido a la estratificación. Me encantaría que se demuestre que estoy equivocado, pero creo que ese problema podría resolverse y no empeorar en el futuro.

Ustedes están equivocados.
Uno no sigue el mantra del 'mínimo común denominador' de Xamarin, sino todo lo contrario, intenta asegurarse de que todos los controles XAML (¡e incluso Windows Community Toolkit!) funcionen en todas las plataformas.

Uno no sigue el mantra del 'mínimo común denominador' de Xamarin, sino todo lo contrario, intenta asegurarse de que todos los controles XAML (¡e incluso Windows Community Toolkit!) funcionen en todas las plataformas.

@weitzhandler tienes toda la razón! Creo que su arquitectura se prestará algún día para tener una paridad completa con el conjunto de controles de WinUI, lo que puede no ser posible con Xamarin.Forms. Si entiendo correctamente, ese conjunto de control aún no se ha creado, que es a lo que @lukasf y yo nos referíamos. Sin embargo, podría estar equivocado, no he jugado lo suficiente como para saberlo, solo confío en lo que he escuchado de todos los demás :)

El enfoque de @weitzhandler Uno de volver a implementar las API reales de UWP/WinUI es mucho mejor que la invención de Xamarin de un nuevo dialecto XAML. Pero si ejecuta la Galería de controles Uno Xaml, encontrará bastantes áreas vacías. Su conjunto de controles es mejor que Xamarin.Forms, pero aún no es un UWP/WinUI completo. Creo que Uno necesita más trabajo en la superficie de la API, y también más trabajo para que los controles disponibles sean realmente estables y con todas las funciones.

Podría ver Uno como una opción viable. Pero necesita un progreso real, que es donde Microsoft podría entrar en juego.

En otro punto, estoy completamente de acuerdo con lo que dijo @lukasf aquí :

Las grandes aplicaciones tienen su propio look+feel. No necesitan controles de plataforma de valores. Mira Spotify, Netflix

También creo que, idealmente, la solución es hacer que el diseño de WinUI + Fluent represente lo mismo en todas las plataformas, y tal vez proporcionar temas de aspecto y funcionamiento nativos para aquellos que necesitan el diseño estándar, para que se apliquen en las plataformas específicas.
Considero que la web debería ser lo mismo que el escritorio, por lo que solo Droid e iOS son candidatos para eso de todos modos.

Los controles multiplataforma son en realidad independientes de los marcos multiplataforma.

Hipótesis: en el futuro, los controles de .Net no estarán restringidos a plataformas particulares.

Existen marcos multiplataforma de interfaz de usuario de .Net (Xamarin.Forms, Avalonia). También habrá FutureXplatDotNetUI con el que todos sueñan y nadie puede definir del todo.

Cuando crea un control, puede hacer que use características específicas de la plataforma. Por ejemplo, un reproductor de video que usa reproductores nativos en cada plataforma. O podría hacerlo de una manera independiente de la plataforma, por ejemplo, usando SkiaSharp.

De cualquier manera, su control se puede instalar en cualquier proyecto de interfaz de usuario de .Net.

Corolario: FutureXplatDotNetUI solo necesitará un conjunto mínimo de controles

Tendrá que definir una clase de vista y una infraestructura de diseño, pero se pueden agregar vistas o grupos de vistas específicos mediante la instalación de paquetes estándar de interfaz de usuario de .Net desde nuget.

(Esta publicación es un comentario sobre la interfaz de usuario .Net multiplataforma y, por lo tanto, no está relacionada con WinUI).

Tengo la sensación de que la prioridad actual del equipo de WinUI no es para "nuevas aplicaciones nativas de Windows". En cambio, se están enfocando más en modernizar las aplicaciones existentes y hacer de WinUI el soporte subyacente de algún marco de interfaz de usuario de nivel superior...

@reli-msft
Tengo la sensación de que el equipo de WinUI ya ha dejado de esperar que la gente escriba nuevas aplicaciones nativas de Windows, y WinUI está diseñado para actualizar aplicaciones existentes.

Viniendo de una persona que trabaja en Microsoft, eso es un poco extraño.

Tengo la sensación de que el equipo de WinUI ya ha dejado de esperar que la gente escriba nuevas aplicaciones nativas de Windows, y WinUI está diseñado para actualizar aplicaciones existentes.

Viniendo de una persona que trabaja en Microsoft, eso es un poco extraño.

@weitzhandler
Debería usar una palabra más precisa que usé... No es "rendirse" sino "preocuparse menos". De todos modos, eso es solo una sensación de alguien fuera del equipo de WinUI.
Pero modernizar las aplicaciones existentes puede ser más importante _por ahora_, y esa puede ser la razón por la que WinUI decidió admitir Win32.

Estabas hablando de lo que piensa el equipo de WinUI.

Como EM general, desafortunadamente eso sí tiene sentido.
Desearía que Microsoft le hubiera dado a WinUI el amor React o Electron o cualquier otra tecnología HTML CSS y JS (lea mi comentario anterior ).

@charlesroddie

Siempre necesita un marco contra el cual desarrollar sus controles. Necesita clases base para heredar, interfaces para implementar. Necesita clases para acceder a árboles de control, plantillas, etc., por lo que realmente no puede separar los controles de los marcos. Ningún control puede funcionar en múltiples marcos, a menos que esos marcos usen exactamente los mismos conceptos, clases y espacios de nombres.

Podría compartir algo de código entre los controles WinUI (basados ​​en C#) y WPF, pero aun así sería difícil debido a los diferentes espacios de nombres y diferentes API. Pero es simplemente imposible compartir controles XAML con marcos de Android o iOS.

Además de eso, realmente no estoy seguro de si .NET es la tecnología adecuada para construir una pila de interfaz de usuario. Microsoft lo probó con WPF y finalmente se dio por vencido y cambió a C++. Tener pausas de GC durante el diseño y el renderizado simplemente no da la mejor impresión a los usuarios finales, en momentos en que las animaciones se vuelven cada vez más importantes. Tal vez esto ya no sea cierto si hay un Compositor disponible, que se encarga de animaciones fluidas completamente independientes del subproceso de la interfaz de usuario. Entonces, la pila de control podría ser C# y solo la parte de renderizado y animación de nivel más bajo sería código nativo. Pero en aquel entonces, el rendimiento era la razón principal por la que C# se abandonó por completo en los siguientes marcos de trabajo de la interfaz de usuario XAML (Silverlight y UWP/WinUI).

@lukasf Ningún control puede funcionar en múltiples marcos

Esto no es verdad. Di dos formas en que los controles pueden funcionar en múltiples marcos. El primer enfoque es escribir código específico de la plataforma. Luego, debe conocer los marcos que admite para conectar el código específico de su plataforma a cada marco; puede hacer esto ahora mismo, pero el andamiaje se puede hacer más fácil en el futuro. El segundo enfoque (renderizado independiente de la plataforma) es muy sencillo y se está realizando ahora mismo. Por ejemplo, CSharpMath.SkiaSharp se puede utilizar en todas las plataformas de interfaz de usuario de .Net.

@charlesroddie Bueno, tal vez me equivoqué en tu publicación. Pero entonces el control no es realmente independiente del marco. Solo se puede instalar en aquellas aplicaciones cuyo marco sea compatible explícitamente con el control. Y el renderizado es solo una pequeña parte de un control. La lógica de control, el enlace de datos y el manejo de entrada deben implementarse para cada marco compatible, en cada control de este tipo, incluso si utiliza un renderizador independiente de la plataforma. Eso no me parece muy efectivo, a menos que los marcos compatibles sean muy similares. Como dije, es posible compartir código entre WPF, Silverlight y UWP. Pero más allá de eso, se vuelve realmente difícil, y dudo que alguna vez vea tal control.

Un marco multiplataforma generalmente le permite escribir toda la lógica de control, el manejo de datos y entradas (y, a veces, incluso la representación) solo una vez para una API, y luego lo asignará automáticamente a cada marco. Entonces, una vez que el marco está allí, la implementación del control es mucho más eficiente.

Solo se puede instalar en aquellas aplicaciones cuyo marco sea compatible explícitamente con el control.

Eso es cierto, pero admitir más plataformas es/puede ser fácil.

La lógica de control, el enlace de datos y el manejo de entrada deben implementarse para cada marco compatible.

El enlace de datos no necesita ser implementado por un marco de interfaz de usuario. Este es un concepto erróneo fomentado por los enfoques de .Net populares pero inferiores que prevalecen. Los controles solo necesitan especificar constructores y propiedades. No necesitan especificar ninguna forma particular de vincular los datos porque una vez que se especifican las propiedades configurables/obtenibles, los consumidores pueden usar cualquier marco de enfoque para mover los datos que deseen. (Y casi cualquier enfoque/marco es mejor que el enlace de datos WPF/UWP/Xamarin).

La lógica de control se implementa naturalmente en .Net de una manera independiente de la plataforma, por lo que está perfectamente atendida en cualquiera de los enfoques que di.

El manejo de entrada se beneficia de un "marco multiplataforma", pero este puede ser un marco de control muy pequeño, al que se puede hacer referencia tanto en proyectos específicos de plataforma como multiplataforma, con una API muy pequeña que solo define mouse/touch y entrada de teclado. El proyecto de controles SkiaSharp.Extended se está moviendo en esta dirección.

Si desea que el enlace de datos funcione en WPF o WinUI, debe declarar DependencyProperties. Dudo mucho que alguien use un control XAML que no funcione con el enlace de datos. El enlace de datos está en el corazón de estos marcos y requiere DependencyProperties para funcionar, le gusten o no. Si no los agrega, no puede usar su control en ninguno de los marcos de trabajo actuales de la plataforma Windows.

Con "lógica de control" menciono más la interacción con otros controles, como definir o crear subcontroles para su control de nivel superior, manejo de datos y estado entre estos controles, diseño, sincronización con subcontroles. Todo esto es trabajo específico del marco. Eso, combinado con el código de enlace de datos (si lo requiere el marco de trabajo de destino) y el manejo de entrada, probablemente constituya> 90% del código de control. La parte común entre diferentes implementaciones de marco para un control de este tipo es probablemente tan pequeña que simplemente no tiene sentido para mí trabajar de esa manera.

No digo que no se pueda hacer. Pero será muy complicado, ya que los marcos son muy diferentes. Quiero decir, es posible escribir tal control en este momento, aún así nunca he visto uno. Y personalmente, no creo que esto se convierta en un enfoque ligeramente popular.

no puede usar su control en ninguno de los marcos actuales de la plataforma Windows

Eso no es cierto. Se puede usar un control que no implemente DependencyProperties en WPF/WinUI. Este es uno de los defectos del enlace de datos .Net tradicional: fomenta la adición de DependencyProperties falsas a los controles que ya definen propiedades configurables. Gran duplicación de código. (Por cierto, un control multiplataforma no sería un "control XAML" y no debería dejarse engañar por el mal uso de "XAML" en el lenguaje de marketing de WinUI. Xaml es un lenguaje de marcado opcional que se puede usar con varios Marcos de interfaz de usuario .Net).

subcontroles para su control de nivel superior

Sí, un control deberá especificar subcontroles, por lo que para que los controles de nivel superior estén disponibles en varias plataformas, los de nivel inferior también lo estarán. Si los controles de nivel inferior están disponibles en varias plataformas, es fácil integrarlos. Está imaginando escribir controles de nivel superior antes que los de nivel inferior, lo que no es un enfoque eficiente.

La buena noticia es que Microsoft ya decidió acabar con .net native.

@robloo haré una fiesta para celebrarlo cuando esto pase.

Incluso si Uno tiene un diseño e implementación técnica buenos, sólidos y confiables, el riesgo y la preocupación es que Uno podría desaparecer en unos pocos años debido a un problema similar de $0 o ingresos insuficientes que eventualmente desencadena el agotamiento y la cancelación o estancamiento del proyecto. O simplemente el desarrollador más importante de Uno un día, de repente obtiene un nuevo pasatiempo/interés/obsesión y pierde interés en Uno, o un nuevo trabajo/empleador y no tiene más tiempo para trabajar en Uno.

@verelpode
Comparto la misma preocupación probablemente más que la mayoría de los demás. Utilizo mucho menos paquetes de código abierto que no cuentan con el respaldo de las principales empresas (por ejemplo, Oracle, Google, Microsoft) que el promedio. Creo que se deben cumplir las dos condiciones siguientes para que esto suceda:

1. Nventive cierra su negocio. Nventive confía en Uno para su negocio de pan y mantequilla.
2. Las personas principales detrás de Uno pierden su interés en este maravilloso proyecto.

En cuanto al número 1, escuché que Nventive está ampliando su edificio actual y mudándose a una instalación más grande, por lo que la Uno Conf 2020 ampliada (de 2 a 3 días) tendrá una parte en un edificio diferente. No soy economista, por lo que no puedo predecir si habrá una recesión severa que lleve a muchas empresas a la quiebra. Al menos no veo un colapso económico en un futuro cercano en este momento (la tasa de desempleo en nuestra área ha estado por debajo del 2% por un tiempo).

En cuanto al n. ° 2, rara vez veo el tipo de pasión que los muchachos principales de Uno tienen por su proyecto. Es casi como una causa noble, no un mero producto de software para ellos. Bueno, solo un tonto no cambia de opinión, por lo que no diría que la probabilidad de que pierdan interés sea cero, pero probablemente no esté lejos de cero. Para ser honesto contigo, esta es la razón principal por la que disfruto y me quedo con Uno en este momento. Al igual que cualquier otra plataforma, Uno tiene muchos problemas (por cierto, la falta de algunas características agradables no es un problema para mí), pero solucionan los problemas críticos rápidamente. Creo que tienen media docena o más de lanzamientos todos los días. Una de mis aplicaciones no se pudo publicar debido a un error conocido de una plataforma, y ​​una empresa importante (😉) tardó literalmente más de medio año en solucionarlo (he archivado el ticket).

Basado en mi amplia experiencia con Sliverlight, SDK de Windows Phone 7/7.1/8/8.1, Windows 8/8.1/10 (WinRT, UWP…) (Mi teléfono principal era un Windows Phone, la mejor plataforma móvil en la historia de la humanidad, hasta el último minuto antes de que no tuviera más remedio que cambiarme a Android este año), tengo más confianza en la longevidad de Uno Platform que en cosas similares de Microsoft. Sí, Uno se basa en todas las tecnologías de Microsoft, pero se encargan de la migración cuando Microsoft cambia las cosas bajo el capó.

Me he estado preguntando si una de las razones por las que Miguel respalda a Uno y pronunció el discurso de apertura en Uno Conf es que ve a Uno como su bebé Mono en los primeros días, y a Nventive como su Ximian.

Me preparo para el peor escenario: la muerte de Uno. Dado que todos los proyectos de Uno usan mis dos tecnologías favoritas: C# y Xaml, puedo migrarlos fácilmente a cualquier plataforma emergente basada en ellos. Al menos puedo decir que el código C# envejece muy bien. Gran parte del código en mi biblioteca de utilidades principal compartida por todos los proyectos tiene más de una década. Todavía funcionan perfectamente, y sospecho que lo harán en las próximas décadas.

@stevenbrix @weitzhandler @Pinox

Una discusión interesante, también noté que Blazor Native también se menciona aquí.

Ha habido una nueva conferencia de NDC de Steve con Blazor que podría ser interesante considerar, el video de arriba usando Blazor + Native usó Flutter como renderizador. Pero en un nuevo video de NDC Conf, Steve ahora usa Xamarin.Forms para representar la interfaz de usuario móvil con marcado similar a XAML. Veo que Blazor Native es la solución de plataforma x más práctica que puede funcionar en este momento con WinUI, ya que admitirá React Native de la misma manera en que lo veo compatible con Blazor Native de esa manera. Entonces, .Net ahora puede apuntar (Web, Móvil, Win Desktop).

ACTUALIZAR:
Recientemente se lanzó una nueva versión de MS Teams y mejora el tiempo necesario para ver el mensaje de chat más reciente. En un mensaje anterior, mencioné que tomó aproximadamente 27 segundos, pero afortunadamente la nueva versión es más rápida para mostrar el mensaje de chat más reciente.

Gracias a los miembros del personal de Microsoft que trabajaron en esta mejora. :sonrisa:

Mi perspectiva:

Microsoft: puede desarrollar un Webview2 mínimo (similar a Carlo) que puede deshabilitar casi todas las funciones y reducir solo el enlace de eventos a la interfaz de usuario HTML... es posible que todas las demás funciones se desarrollen en C#/nativa/fuera del alcance de la comunidad (como multiplataforma biblioteca back-end nativa).
Sabía lo complejo que es el lado HTML/CSS, pero me encantaría aprovechar ese conocimiento de la interfaz de usuario y el enlace uno a uno en el código C# detrás del código de evento, etc.

Microsoft: Puede apagar una ram de 8/32gb de las que tenían 4x 8gb/ 4x 32gb... Ahorrando mucha energía.

Para ello, nos deshacemos de decenas de apps que se desarrollan con Electron... que dependen del objetivo de Microsoft y Bill Gates.

Aunque el mejor objetivo es que todos comiencen a desarrollar aplicaciones y obtengan tracción de algún marco GUI estándar de CSS3... posible como QT/GTK... pero lástima que GTK no sea sin copyleft, y posible como QML con equivalencia .net.

ACTUALIZAR:
Cancele lo que dije en mi mensaje anterior sobre la solución del problema ☹️ No está solucionado. Esto es extraño: durante un par de semanas, parecía que el problema había desaparecido, ¡pero luego volvió a aparecer recientemente! MS Teams vuelve a darme dificultades y retrasos cuando simplemente intento ver el mensaje de chat más reciente.

Los errores de MS Teams no sorprenden si se tiene en cuenta que está escrito en JavaScript. _Por supuesto_ una aplicación escrita en JavaScript tiene errores, ¿por qué alguien esperaría lo contrario? MS Teams usa ElectronJS, que usa JavaScript a pesar de que es bien sabido que JavaScript nunca tuvo la intención de ser un lenguaje de programación real, sino que es solo un complemento de secuencias de comandos casual para navegadores web.

JavaScript ni siquiera incluye verificación de tipo en tiempo de compilación, así de malo es. De ahí la necesidad de que TypeScript intente corregir este _principal_ problema en JavaScript. En realidad, es un problema muy grave si piensa en JavaScript como un lenguaje de programación, JavaScript es terrible como lenguaje de programación, pero como dije, estaba destinado a ser un lenguaje de secuencias de comandos informal, no un lenguaje de programación, por lo que puede perdone a JavaScript por no incluir los elementos esenciales de un lenguaje de programación, porque la programación de aplicaciones no era el propósito de JavaScript.

Lo que no es realmente perdonable es la incomprensible decisión de usar un lenguaje de script casual como si fuera un lenguaje de programación. Me sorprendió mucho ver que Microsoft eligió un lenguaje no profesional para una aplicación tan importante como Teams. No pensé que fuera posible que alguien dijera el nombre "JavaScript" y al mismo tiempo olvidara que "JavaScript" tiene "Script" en su nombre porque de hecho es un lenguaje de secuencias de comandos, no un lenguaje de programación. De alguna manera, la existencia de la palabra "Script" en "JavaScript" se ha eliminado por completo.

Los miembros del equipo de WinUI han estado trabajando arduamente en muchas mejoras de WinUI. La decisión de Microsoft de utilizar un lenguaje de secuencias de comandos casual en lugar de WinUI no tiene sentido.

Hay muchas aplicaciones web de JavaScript de alto rendimiento y muy bien escritas. Seguro que podría obtener un rendimiento aún mejor con otras tecnologías. Pero la razón por la que Teams es lento para usted seguramente no es el hecho de que esté basado en JavaScript. Esto se debe a una mala implementación en el lado del servidor o en el lado del cliente (probablemente problemas de sincronización/subprocesamiento). Seguramente sería posible escribir Teams en JavaScript con un rendimiento mucho mejor.

No me malinterpreten, no soy fanático de JavaScript en absoluto. De hecho creo que es un lenguaje horrible. Solo digo que los problemas que ve no se deben al hecho de que Teams use tecnología JavaScript. Incluso es posible ejecutar el motor Unreal en JavaScript con un buen rendimiento (no de primera clase).

WinUI es solo un marco de escritorio de Windows. Por lo tanto, no fue posible desarrollar la aplicación X-platform Teams basada en él, y aún hoy no es posible. Pero tal vez los problemas con Teams ayuden a Microsoft a considerar hacer que WinUI sea multiplataforma. Con una verdadera plataforma x WinUI y .NET Core, sería mucho más fácil desarrollar aplicaciones receptivas que escalen bien.

WinUI es solo un marco de escritorio de Windows. Por lo tanto, no fue posible desarrollar la aplicación X-platform Teams basada en él, y aún hoy no es posible. Pero tal vez los problemas con Teams ayuden a Microsoft a considerar hacer que WinUI sea multiplataforma. Con una verdadera plataforma x WinUI y .NET Core, sería mucho más fácil desarrollar aplicaciones receptivas que escalen bien.

Usando Uno, WinUI es multiplataforma. Mira la Calculadora UNO en la tienda Google Play. Es una versión portada de la calculadora de Windows 10.

Alguien estaba pidiendo una comparación entre UWP y Electron, aquí hay un par:

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

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

la nueva aplicación XBOX es ridícula, puede tomar fácilmente 1.5 gb de RAM por nada

sería bueno si alguien pudiera hacer un video para mostrar cuán lentos son en comparación con UWP

Pensé que la mayoría de los participantes de esta discusión sobre WinUI y X-platform habían leído sobre esta historia, pero en caso de que algunos se lo hayan perdido, aquí está WinUI en Windows 7: sí, es posible con Uno Platform . Una vez que una aplicación se basa en Uno, se dirige a Windows, Web, iOS y Android.

@lukasf

Seguramente sería posible escribir Teams en JavaScript con un rendimiento mucho mejor.

Sí, es _posible_, y también es _posible_ escribir MS Teams en PowerShell con un rendimiento aceptable (me gusta PowerShell), y también es _posible_ que SpaceX se traslade a Rusia y aún logre lanzar satélites, pero aún así sería una gestión incompetente. decisión de trasladar SpaceX a Rusia, o de escribir la aplicación MS Teams en un lenguaje de secuencias de comandos como PowerShell o JavaScript. Si SpaceX se mudara a Rusia, entonces sí, SpaceX aún podría operar, es posible, pero honestamente tendríamos que decir que Elon Musk no sería realmente un gerente efectivo y no sabría realmente lo que está haciendo.

No estoy 100% convencido de que Electron tenga la culpa. Se dice que Visual Studio Code también se basa en Electron, pero su rendimiento es bastante sólido. Las aplicaciones electrónicas son básicamente aplicaciones web, y hay miles de razones detrás de una aplicación web mal ejecutada.

No hay mucho que WinUI pueda hacer para "ganarse a Teams". No es la tecnología, es el producto. Teams es como una empresa nueva que se ha establecido en un camino de rápido crecimiento. Necesita ejecutarse en múltiples plataformas con paridad de funciones, y deben lograrlo lo más rápido posible. Esta es la única razón para elegir la tecnología basada en web. En dispositivos móviles, pueden usar React Native porque es la única forma de acceder al hardware con JavaScript, pero en Desktop, necesitan mantener la paridad de funciones y la capacidad de mantenimiento del código con la aplicación web, Mac y la versión de Linux. Deben usar un marco que apunte a win32 porque no pueden esperar a que el modelo de la aplicación para UWP agregue las funciones que necesita. Poder compartir el escritorio con la opción de elegir qué escritorio o qué aplicación específica compartir es una de sus características clave. Así es como se desarrollan los productos tipo startup. Slack usó jquery para piratear el crecimiento cuando comenzaron y terminaron con un código realmente malo, pero una vez que tuvieron algo de tiempo para refactorizar, rápidamente reescribieron todo con reaccionar, y Slack ahora es mucho más rápido que antes. WinUI y Electron no están en la misma categoría y, por esa razón, no reemplazará a Electron para las aplicaciones que realmente lo necesitan, sin importar qué función agregue.