Flutter tiene una página completa dedicada a atraer personas de Xamarin.Forms. Estás diciendo que deberíamos ignorar la competencia. ¿En serio?

¡Las fijaciones Blazor son hermosas! Recién estoy comenzando con ellos y ofrecen la simplicidad que ofrece Flutter.

@davidortinau como dije en el otro hilo. La publicación del blog MAUI creó una confusión masiva. La gente ahora parece pensar que MVU = ver como código / DSL.
Pero esto es completamente independiente de lo que es MVU. MVU es perfectamente posible con XAML. No tiene nada que ver con cómo escribe la vista.
Se trata solo de crear un modelo inmutable + función de actualización que toma un modelo y un mensaje y construye un nuevo modelo y también una función de vista que no muta el modelo directamente sino que envía nuevos comandos (mensajes) al ciclo de actualización.

Creo que MAUI debería seguir con una sola forma de diseñar la interfaz de usuario, que es: XAML

Blazor Syntex está bien, pero MVU me parece un desastre totalmente innecesario. Si es para atraer a los desarrolladores de Flutter, por favor, que se queden con Flutter; NO destruya la belleza de XAML;

Está destinado a los desarrolladores de C # y .NET.

@ sim756

Creo que MAUI debería seguir con una sola forma de diseñar la interfaz de usuario, que es: XAML

Nunca ha sido de una sola manera. Las IU basadas en código se han admitido a través de Xamarin.Forms desde el principio. Hacer eso más accesible tiene sentido. Y, por cierto: MVU se puede usar fácilmente con XAML ( Xamarin.Forms , WPF ).

@ Happypig375

Flutter tiene una página completa dedicada a atraer personas de Xamarin.Forms. Estás diciendo que deberíamos ignorar la competencia. ¿En serio?

Bueno, es mejor que tengamos la página " Xamarin para desarrolladores de Flutter ".

@rohanbojja

¡Las fijaciones Blazor son hermosas! Recién estoy comenzando con ellos y ofrecen la simplicidad que ofrece Flutter.

Todo está bien excepto esto, y esta es la razón por la que no me gusta Flutter :

Imagen 0

@forki

@davidortinau como dije en el otro hilo. La publicación del blog MAUI creó una confusión masiva. La gente ahora parece pensar que MVU = ver como código / DSL.
Pero esto es completamente independiente de lo que es MVU. MVU es perfectamente posible con XAML. No tiene nada que ver con cómo escribe la vista.
Se trata solo de crear un modelo inmutable + función de actualización que toma un modelo y un mensaje y construye un nuevo modelo y también una función de vista que no muta el modelo directamente sino que envía nuevos comandos (mensajes) al ciclo de actualización.

¡¡Estoy realmente confundido !! Gracias, lo acaba de dejar en claro, la publicación es catastróficamente confusa:

Imagen 1

@ saint4eva

Creo que MAUI debería seguir con una sola forma de diseñar la interfaz de usuario, que es: XAML
Blazor Syntex está bien, pero MVU me parece un desastre totalmente innecesario. Si es para atraer a los desarrolladores de Flutter, por favor, que se queden con Flutter; NO destruya la belleza de XAML;

Está destinado a los desarrolladores de C # y .NET.

" Está destinado a los desarrolladores de C # y .NET ", exactamente, no debería dejarse influenciar por Flutter (me temo que sí ...).

@aspnetde

@ sim756

Creo que MAUI debería seguir con una sola forma de diseñar la interfaz de usuario, que es: XAML

Nunca ha sido de una sola manera. Las IU basadas en código se han admitido a través de Xamarin.Forms desde el principio. Hacer eso más accesible tiene sentido. Y, por cierto: MVU se puede usar fácilmente con XAML ( Xamarin.Forms , WPF ).

Sé. A veces escribimos new Button() { .... } , pero esta publicación ( Imagen 1 ) me confunde, y creo que muchas otras.

@ Happypig375

Flutter tiene una página completa dedicada a atraer personas de Xamarin.Forms. Estás diciendo que deberíamos ignorar la competencia. ¿En serio?

Bueno, es mejor que tengamos la página " Xamarin para desarrolladores de Flutter ".

JAJAJA. Imagine una página dedicada a "Windows Forms para desarrolladores de WPF".

XAML es solo una "herramienta" en la parte superior del modelo de objetos ... Puede usar xaml, c #. Puede diseñar su aplicación usando MVVM (con o sin XAML) o con MVU (para ser justos, los ejemplos proporcionados no eran MVU "reales", pero este es otro tema).

Si no le gusta la interfaz de usuario codificada o el enfoque MVU, simplemente ignórelo :) No hay necesidad de rechazarlo.

No creo que esto sea solo para atraer desarrolladores de flutter. El patrón MVU está en aumento y es muy adecuado para el desarrollo móvil.

También la interfaz de usuario codificada está en aumento ... reaccionar, aletear, swiftUI, ecc ... están ganando MUCHA popularidad y no solo es una exageración ... la interfaz de usuario codificada tiene grandes ventajas si se hace bien

@GiampaoloGabba
Creo que debería dejar en claro que estoy menos en contra de MVU que de Coded-UI. Estoy confundido por esa publicación de que me temo que Coded-UI va a ser la forma predeterminada de desarrollar UI (... tengo miedo de perder XAML).

Bueno, tenemos .designer.cs , pero no tuvimos que editar el código allí, incluso supongo que muchos de los desarrolladores de Windows Forms ni siquiera vieron el contenido de los archivos .designer.cs nunca. Pero aquí, tenemos el _capable_ GUI Editor que no teníamos que preocuparnos por el código de IU codificada en el archivo _.designer.cs_.

Será mejor que edite el título de este número.

Lo que quería decir:

¿Qué elegiremos entre Flutter / Swift / Coded-UI y WPF / XAML con un editor de GUI como Blend para Visual Studio ?

@ sim756

Sé. A veces escribimos un nuevo botón () {....}

A veces, las personas escriben aplicaciones XF completas sin tocar XAML, y están felices por ello ;-).

@ sim756

Sé. A veces escribimos un nuevo botón () {....}

A veces, las personas escriben aplicaciones XF completas sin tocar XAML, y están felices por ello ;-).

@aspnetde

Estoy sorprendido..!! 😢

Sin embargo, no para ellos, sino para gente como yo, que quiere Blend para Xamarin / MAUI, no está contento:

Editor de movimiento de Android Studio

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

@ sim756 Me pregunto si aún desea tener soporte de mezcla una vez que haya trabajado en un sistema con una recarga en caliente que funcione correctamente. Por lo general, la gente lo prefiere mucho.

Viniendo de un entorno XAML / Blend, mis pensamientos iniciales sobre la interfaz de usuario en el código fueron retroceder, pero una vez que lo probé, vi muchos beneficios que simplemente no había considerado. La eliminación de la necesidad de características como convertidores, recursos y similares, lo que ahora parece enormemente demasiado complejo pero en ese momento se sentía totalmente razonable, me ha hecho creer realmente en las IU basadas en el código.

Bueno, tenemos .designer.cs, pero no tuvimos que editar el código allí, incluso supongo que muchos de los desarrolladores de Windows Forms ni siquiera vieron el contenido de los archivos .designer.cs nunca.

@ sim756 : si bien un diseñador capaz suena como una gran herramienta de productividad, si ha existido por un tiempo, es posible que haya trabajado en bases de código "heredadas", donde el diseñador se rompió y dejó de funcionar en algunas versiones de Visual Studio, y tendrías que entender y editar miles de líneas en .designer.cs a mano. Dado que realizar incluso los cambios más pequeños (como alinear un botón) en tales bases de código puede llevar uno o dos días, todos esos beneficios de productividad se reconsideran. (Tuve esas experiencias con WinForms y WebForms anteriormente).

Cuando se trata de XAML, @dsyme habla sobre la dependencia de herramientas pesadas en esta charla sobre Fabulous con una sección dedicada a "El problema con XAML". Aunque Fabulous tiene muchos problemas propios, es difícil no estar de acuerdo con muchos de los puntos que se plantean.