Aspnetcore: XAML en lugar de HTML y CSS

Creado en 27 mar. 2018  ·  28Comentarios  ·  Fuente: dotnet/aspnetcore

Estoy entusiasmado con este proyecto, pero espero que también haga algo sobre CSS. Creo que los estilos XAML son más amigables y se pueden traducir fácilmente a CSS. ¿Se puede hacer?
Y si el DOM se representa como clases .NET, ¿podemos usar la sintaxis XAML para representar la página en lugar de HTML5?
Sé que MVC recuperó HTML en lugar de controles web para permitirnos escribir un código html óptimo, pero creo que XAML está muy cerca de html. Solo quiero usar los controles familiares WPF / Silver Light / UWP con sus propiedades, métodos y eventos familiares, y pueden ser solo una envoltura de los controles html. Esto acortará el ciclo de aprendizaje y hará que el blazor se vea como una ventana normal de WPF / UWP, con código c # detrás de la página.

area-blazor

Comentario más útil

A muchos desarrolladores de C # les encanta usar XAML sobre HTML y CSS. Mucha gente quería compatibilidad multiplataforma oficial para UWP / WPF / XAML. Imo Microsoft también debería admitir XAML con Blazor. ¿Cuándo obtendremos soporte oficial multiplataforma para XAML?

Yo mismo soy fanático de C #, pero mi problema con el desarrollo web y Electron nunca fue Javascript. Es CSS.

¿De qué sirve Blazor si no ofrece una alternativa para HTML / CSS? ¿Por qué es tan difícil encontrar un reemplazo para HTML / CSS, por qué es tan difícil XAML multiplataforma ... Simplemente no lo entiendo. Microsoft siempre está perdiendo oportunidades y tomando decisiones imprudentes.

El día en que XAML se convierta en multiplataforma (compatible oficialmente con Microsoft), será el día en que Blazor obtenga el soporte completo de todos los desarrolladores de C #. Bueno, al menos no para mí ... porque no veo ninguna ventaja real en Blazor. Porque TODAVÍA estoy lidiando con CSS, id, class,

infierno. Solo con C # en lugar de Javascript

Todos 28 comentarios

@MohammadHamdyGhanem Ver https://github.com/aspnet/Blazor/issues/374#issuecomment -376314750

Para Blazor estamos apuntando a C #, HTML y CSS, pero para XAML puedes echar un vistazo a Ooui .

@ danroth27

Para Blazor estamos apuntando a C #, HTML y CSS, pero para XAML

No digo que dejes de usar HTML y CSS. Digo que nos dé la opción de elegir XAML si queremos. Sé que hay una comunidad web, pero también hay una comunidad de escritorio .NET que quiere escribir aplicaciones web. Por favor considérelos. Yo mismo odiaba ASP.NET a pesar de mis esfuerzos por leer y aprender durante los últimos 15 años. Por el contrario, encontré XAML atractivo, poderoso y fácil de aprender. Esperaba que la luz plateada dominara y evolucionara para convertirse en tecnología de Microsoft Wen, ¡pero murió en 2012!
Espero que aceptes esta sugerencia, incluso si la llamas Xlazor :)

XAML puedes echar un vistazo a Ooui.

No dependo de productos de terceros a una escala tan grande, porque no concedo la concesión de que duren y evolucionen, por lo que puede ser un error si un producto de terceros muere, ¡así que necesito reescribir grandes proyectos que lo utilicen!

@MohammadHamdyGhanem Blazor & Ooui son productos separados fundados en WebAssembly tanto como .NET se basa en .NET Framework. Ambos son necesarios ya que hay desarrolladores web que prefieren Razor / HTML / CSS (ASP.NET) y desarrolladores de escritorio / móviles que prefieren XAML. Entonces, creo que ambos deben fusionarse en .NET / Xamarin (blazor ya está combinado) y deben usarse por separado para que se mantengan livianos y no se ensucien entre sí.

@ plamen-i
Estoy de acuerdo. Pero todavía no estoy familiarizado con Xamarin. Prefiero usar controles similares a UWP.

@MohammadHamdyGhanem Xamarin, especialmente Xamarin.Forms es el futuro si desea escribir una vez (C # / XAML) y ejecutar en todas partes. Invierta algo de tiempo para aprender Xamarin.Forms y le pagará mucho más :-) Es una tecnología madura, usa XAML y está muy cerca de WPF / UWP.

Digo que Microsoft debería hacer una API estándar XAML (como .NET Standard) que debería ser obedecida como Xamarin, UWP y ASP.NET, sea cual sea el nombre de la maquinilla de afeitar, o extender .NET Standard para incluir esto.
Los controles y sus propiedades y métodos deben tener los mismos nombres cualquiera que sea la implementación subyacente. Esto hará que todos estos componentes sean más fáciles de aprender y hará que el código sea reutilizable al máximo.

@MohammadHamdyGhanem Lo son, creo ... Aquí está el repositorio para eso, pero ha estado bastante muerto durante los últimos meses. Espero que no sea así y espero algún anuncio en la Build 2018.

Es un alivio. Gracias.

xamarin.forms no es tan eficaz como las aplicaciones nativas de Android o iOS, es bueno para el contenido estadístico en las aplicaciones o aplicaciones conectadas a la nube, pero si realmente desea una integración profunda con las apis del sistema operativo y necesita un rendimiento nativo, xamarin no es tan eficaz, más las herramientas de xamarin.native es simplemente horrible,

Seguí adelante y comencé a construir un motor Xaml que se ejecuta de forma nativa en el navegador. Puede consultarlo aquí: https://github.com/XamlEngine/Samples

XAML tiene que ser una opción. No sé cuánto está familiarizado el equipo de Asp.Net con XAML. El equipo está dedicando tiempo a recrear la rueda. Como en Community Standup reciente, han mostrado cómo crear componentes en Blazor. ¿Dije por qué?. Y por qué tengo que aprender una nueva forma de escribir componentes. Tienes XAML que es perfecto para todas estas cosas.

Hay miles de marcos JS como VUE, Angular, React que ayudan en el enlace de datos. Y XAML fue el primero en hacer todo esto. Almenos intentalo.

Estamos familiarizados con XAML, pero nuestro objetivo principal con Blazor es apuntar a los desarrolladores web, por lo que nos quedamos con HTML y CSS. Dicho esto, ya existen varios esfuerzos para crear soporte XAML para .NET en WebAssembly (Ooui, Uno, FrogUI), por lo que recomendamos mirar esos proyectos si XAML es su preferencia.

@ danroth27
Veo que MS debe funcionar en la maquinilla de afeitar XAML para guardar VB.NET. En mi opinión, ASP.NET fue una de las razones por las que la popularidad de VB.NET disminuyó durante la última década. Los VBScripts se ejecutan solo en Internet Explorer, por lo que nace muerto y cualquier desarrollador web solo tenía que usar JavaScript que usa sintaxis similar a C, por lo que es fácil de usar con C # que con VB.NET. A lo largo de los años, los marcos de JavaScript siguieron emergiendo y MS adaptó algunos de ellos, como JQuery y Angular. TypeScript también es algo de JavaScript avanzado.
Esto hizo que C # sea la única opción lógica para los principiantes, incluso obligó a muchos desarrolladores de VB.NET a migrar a C #.
Entonces, Xaml blazoer tiene dos objetivos:

  1. Atraiga a los desarrolladores de escritorio de c #. ¡De vez en cuando acabará con los fans de HTML!
    2- Atraiga a los desarrolladores de vb.net y guarde este hermoso lenguaje fácil para principiantes.

Creo que aquí hay un concepto erróneo sobre XAML. Realmente soy un fanático de XAML en Blazor pero no de la forma discutida anteriormente y en aspnet / Blazor # 374.

Lo que soy sugerencia se describe a continuación:

El problema

Imagina que tengo estos componentes:

Drawer.cshtml:

<aside class="mdc-drawer mdc-drawer--modal">
    <strong i="10">@Header</strong>
    <strong i="11">@ChildContent</strong>
</aside>

<strong i="12">@functions</strong>
{
    [Parameter]
    DrawerHeader Header { get; set; }

    [Parameter]
    RenderFragment ChildContent { get; set; }
}

DrawerHeader.cshtml:

<div class="mdc-drawer__header">
    <strong i="16">@ChildContent</strong>
</div>

<strong i="17">@functions</strong>
{
    [Parameter]
    RenderFragment ChildContent { get; set; }
}

Ahora imagine que en mi tercer componente Main.cshtml quiero agregar un Drawer y establecer su Drawer.Header . Actualmente tengo que crear una propiedad de tipo DrawerHeader y vincularla a mi Drawer.Header :

<div class="drawer-frame-root">
    <Drawer Header="@Header">
        <DrawerContent>

        </DrawerContent>
    </Drawer>
    <DrawerScrim />
</div>

<strong i="25">@functions</strong>
{
    DrawerHeader Header
    {
        get;
    } = new SubClassOfDrawerHeader();
}

Por lo tanto, tengo que crear otro componente llamado SubClassOfDrawerHeader y asignarle la propiedad Header. Lo que hace toneladas de componentes en mi proyecto.

Mi propuesta

Mi sugerencia es usar el anidamiento de propiedades de estilo XAML:

<div class="drawer-frame-root">
    <Drawer>
        <Drawer.Header>
                <DrawerHeader>
                        <DrawerHeaderTitle>User's name</DrawerHeaderTitle>
                        <DrawerHeaderSubtitle>[email protected]</DrawerHeaderSubtitle>
                </DrawerHeader>
        </Drawer.Header>
        <DrawerContent>Some content</DrawerContent>
    </Drawer>
    <DrawerScrim />
</div>

Mire <Drawer.Header>...</Drawer.Header> en el código anterior.

@MohammadHamdyGhanem @xclud ¿Ha echado un vistazo a una plataforma similar basada en Xaml como lo desea, Platform.uno , como lo mencionó @ danroth27 anteriormente?

Si tiene XAML, creo que instantáneamente pasaríamos a blazor, porque realmente disfrutamos de Silverlight.
Codificación HTML / Javascript == forma muy molesta de escribir código (también conocido como "script")

Si tiene XAML, creo que instantáneamente pasaríamos a blazor, porque realmente disfrutamos de Silverlight.
Codificación HTML / Javascript == forma muy molesta de escribir código (también conocido como "script")

@wstaelens También disfruté mucho Silverlight e hice una docena de aplicaciones con él. Es por eso que estoy disfrutando de Uno Platform (también conocido como Silverlight con esteroides) en este momento.

Si tiene XAML, creo que instantáneamente pasaríamos a blazor, porque realmente disfrutamos de Silverlight.
Codificación HTML / Javascript == forma muy molesta de escribir código (también conocido como "script")

@wstaelens También disfruté mucho Silverlight e hice una docena de aplicaciones con él. Es por eso que estoy disfrutando de Uno Platform (también conocido como Silverlight con esteroides) en este momento.

El problema es que este no es un proyecto "oficial" de Microsoft, por lo que de por vida ... soporte ... lo que sea ... blazor solo necesita soporte XAML.

El problema es que este no es un proyecto "oficial" de Microsoft, por lo que de por vida ... soporte ... lo que sea ... blazor solo necesita soporte XAML.

@wstaelens Entendido absolutamente. Veo a Uno como algo que está sobre los hombros de los gigantes de Microsoft: UWP, mono, Xamarin ... No construyeron la plataforma desde cero, pero utilizan de manera brillante muchas tecnologías maduras que han funcionado muy bien. Me alegró mucho ver a Uno bien recibido en Microsoft Build el mes pasado y el reciente respaldo de Miguel de Icaza.

A muchos desarrolladores de C # les encanta usar XAML sobre HTML y CSS. Mucha gente quería compatibilidad multiplataforma oficial para UWP / WPF / XAML. Imo Microsoft también debería admitir XAML con Blazor. ¿Cuándo obtendremos soporte oficial multiplataforma para XAML?

Yo mismo soy fanático de C #, pero mi problema con el desarrollo web y Electron nunca fue Javascript. Es CSS.

¿De qué sirve Blazor si no ofrece una alternativa para HTML / CSS? ¿Por qué es tan difícil encontrar un reemplazo para HTML / CSS, por qué es tan difícil XAML multiplataforma ... Simplemente no lo entiendo. Microsoft siempre está perdiendo oportunidades y tomando decisiones imprudentes.

El día en que XAML se convierta en multiplataforma (compatible oficialmente con Microsoft), será el día en que Blazor obtenga el soporte completo de todos los desarrolladores de C #. Bueno, al menos no para mí ... porque no veo ninguna ventaja real en Blazor. Porque TODAVÍA estoy lidiando con CSS, id, class,

infierno. Solo con C # en lugar de Javascript

No estoy de acuerdo, todos los desarrolladores web están acostumbrados a html y css. Apégate a html y css

@GoranHalvarsson entonces ¿por qué no están acostumbrados a JavaScript o TypeScript?

No estoy de acuerdo, todos los desarrolladores web están acostumbrados a html y css. Apégate a html y css

Desafortunadamente, no todos los autores web son desarrolladores, algunos son ingenieros de software y preferimos XAML / C # para centrar los elementos verticalmente en una página. Lo que sigue siendo un misterio en HTML / CSS. XAML es muy superior.

¿Tengo un Skoda y un Porsche, pero solo conduzco el Skoda porque estoy acostumbrado? Existe Xamarin como una opción o Avalonia (si Microsoft lo posee y replica la especificación de WPF). Tal vez Microsoft debería enviar una encuesta a la comunidad de Blazor y preguntarles si tuvieran que elegir una, ¿sería XAML o HTML?

Hace más de 10 años, los desarrolladores de Silverlight se consideraban desarrolladores web. Solo porque iOS y Android decidieron no permitir complementos, muchos desarrolladores web se quedaron sin una plataforma para desarrollar.

@GoranHalvarsson Cuando dices que todos los desarrolladores web, muchos de nosotros estamos acostumbrados a html y css (porque tenemos que serlo), pero preferimos XAML / C #. No habla en nombre de la comunidad de desarrolladores web. Así que no nos digas a qué debemos ceñirnos.

¿Y qué tiene de malo tener varias tecnologías disponibles para los desarrolladores?

He usado HTML, CSS, JavaScript extensamente (trato de mantenerme alejado de JavaScript en la medida de lo posible hoy en día) para proyectos web.
Cuando se trata de aplicaciones de Internet enriquecidas (RIA) o aplicaciones de página única (SPA), Xaml y C # son el rey y la reina. No tomaré ninguna otra opción.
Debo admitir que soy de los afortunados que no están sujetos a ninguna plataforma impuesta, el lujo que no todos tienen.

Recientemente completé un Blazor Project SSB (todavía no uso CSB) usando Telerik y SyncFusion. ¡La experiencia de C # fue genial! El JavaScript / html / CSS era irritante. Parece que la mayoría de los controles de terceros tienen la mayoría de errores dentro de CSS. No querría construir un SPA a gran escala de esta manera ATM, sería una molestia mantenerlo.

En el pasado, tengo una amplia experiencia en XAML / C #. Debo decir que tener todo bajo un mismo techo hace que el desarrollo no solo sea más rápido y confiable, sino también más agradable.

Personalmente, no me importa mucho si la compatibilidad con XAML / C # no está en el navegador siempre que sea multiplataforma. Probablemente sea tan importante tener continuidad en una pila tecnológica, con formas sencillas de migrar a una tecnología más nueva. Uno de los problemas pasados ​​más importantes (dejando a un lado Silverlight) fue el uso de soluciones ORM de terceros, ¡siempre quédese con la tecnología compatible con Microsoft, siempre que sea posible, es mi consejo!

Si Microsoft agregara soporte multiplataforma / WASM a WPF y WinForms, el problema se resolvería para mí. Probablemente nunca volvería a usar Blazor si este fuera el caso, ya que todos tendríamos la solución definitiva como opción.

¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

ipinak picture ipinak  ·  3Comentarios

TanvirArjel picture TanvirArjel  ·  3Comentarios

guardrex picture guardrex  ·  3Comentarios

markrendle picture markrendle  ·  3Comentarios

ermithun picture ermithun  ·  3Comentarios