Aspnetcore: Separe la experiencia de .NET Core a WASM de Blazor

¡Hola @EisenbergEffect! El trabajo principal de WebAssembly está siendo manejado por el equipo de Mono. Estamos construyendo Blazor sobre la base de lo que ofrecen. Otros en la comunidad .NET también son libres de hacerlo y varios ya lo son ( Ooui , Uno , cshtml5 ). Puede seguir el progreso de mono.wasm en el repositorio de Mono .

No estoy muy interesado en compilar Mono a WebAssembly. Solo estoy interesado en .NET Core. Lo que estoy pidiendo es algo como esto:

• Use la CLI de .NET para crear un proyecto de .NET Core C #.
• Use la CLI de .NET para compilar mi proyecto de .NET Core en WASM, con las 3 salidas descritas anteriormente.

@ danroth27 ¿

La gente de Mono también está trabajando en la compilación completa antes de tiempo (AoT) de código .NET para WebAssembly junto con el SDK de MSBuild compatible. La última actualización que publicaron sobre el esfuerzo fue http://www.mono-project.com/news/2018/01/16/mono-static-webassembly-compilation/. @mhutch es probablemente el mejor contacto para obtener el estado más reciente.

No estoy interesado en Mono. Solo me interesa .NET Core. ¿Existe una historia para .NET Core WASM?

¿Existe una historia para .NET Core WASM?

No actualmente. .NET Core se usa principalmente en la actualidad para escenarios de servidor multiplataforma. Mono es el tiempo de ejecución de .NET que se utiliza hoy en día para escenarios de clientes multiplataforma (Android, iOS, macOS, juegos). La mayoría de los escenarios de WebAssembly actuales son escenarios de clientes, por lo que Mono es la forma más barata de avanzar en este momento. Con el tiempo, es razonable esperar que haya una convergencia, pero eso llevará algún tiempo.

FWIW: Realmente creo que este problema de los tiempos de ejecución y los objetivos de la plataforma debe abordarse primero. Cuando escucho que tengo que usar dos versiones diferentes de .NET para crear una aplicación ... use Mono para su cliente y luego use .NET Core para su servidor ... no me entusiasma en absoluto. Solo quiero usar .NET Core y, francamente, olvidar que existen otros .NET. Un .NET por favor :)

@EisenbergEfecto desde la perspectiva del consumidor, debería ser más o menos un detalle de implementación qué tiempo de ejecución está ejecutando su código.

Estoy en desacuerdo. Nunca en mi historia como ingeniero de software he considerado qué tiempo de ejecución ejecuta mi código como un detalle de implementación que pueda ignorar.

@ danroth27 Solo algunos comentarios de mi equipo de desarrollo, también nos gustaría ver a Blazor usar .NET Core eventualmente. No estamos interesados ​​en Mono o incluso en el marco .NET completo. Queremos el mismo tiempo de ejecución en cliente y servidor.

No estamos interesados ​​en Mono o incluso en el marco .NET completo. Queremos el mismo tiempo de ejecución en cliente y servidor.

Bueno, no importa lo que hagamos, no tendrá exactamente el mismo tiempo de ejecución en el servidor y en el navegador: el tiempo de ejecución del navegador debe basarse en WebAssembly, pero el servidor no. No es diferente de cómo la ejecución en iOS es fundamentalmente diferente a la ejecución en el servidor. El factor unificador en el cliente y el servidor es .NET Standard. Dicho esto, creo que compartimos su objetivo de querer unificar en una única impementación en tiempo de ejecución. No tiene sentido para Microsoft a largo plazo poseer y mantener dos tiempos de ejecución al doble del precio. El trabajo de convergencia ya está sucediendo de muchas maneras. Cada vez se comparte más código en Mono y .NET Core. Pero llegar a un tiempo de ejecución único sigue siendo un esfuerzo importante que llevará algún tiempo.

Mientras tanto, Blazor es un experimento y estamos experimentando con lo que se puede hacer que funcione hoy 😃

@ danroth27 ¡ Gracias por la excelente respuesta, Dan!

Excelente totalmente de acuerdo

El martes 15 de mayo de 2018 a las 10:54 a.m., paulost [email protected] escribió:

@ danroth27 https://github.com/danroth27 Gracias por la excelente
respuesta, Dan!

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/aspnet/Blazor/issues/835#issuecomment-389046589 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/ACnwPz_cCiVg6iti9VR9pQWY34_Hibf4ks5tymapgaJpZM4T-jpA
.

@EisenbergEffect Tuve una opinión similar sobre Mono, sin embargo, cuando supe que desde que Microsoft adquirió Xamarine, Mono es tecnología de Microsoft ... Y está optimizado para escenarios de clientes ... Y puedo usarlo para ejecutar mi código ".net estándar" en el interior navegador hoy ... Todas las preocupaciones fueron dejadas de lado.

Para obtener componentes de solo tiempo de ejecución del navegador:
https://jenkins.mono-project.com/job/test-mono-mainline-wasm/label=ubuntu-1804-amd64/

... Ahora vuelvo a construir mi propia pila de IU basada en XAML en C # dirigida a WebGL

Para ser claros, no se trata de usar tecnología que no sea de Microsoft. Se trata de querer usar solo .NET Core. Estoy buscando un .NET multiplataforma de código abierto con una CLI multiplataforma unificada. No dos o tres .NET o varios compiladores. Pensé que los nuevos esfuerzos se centrarían en .NET Core y la unificación, por lo que me sorprendió que WASM fuera solo para Mono y requiriera una cadena de herramientas diferente.

Personalmente, he estado solicitando la unificación en la plataforma .NET durante más de 10 años. Entonces, perdóname si estoy un poco agitado en este hilo, ya que después de 10 años todavía necesito 3 .NET para construir mis servicios y clientes. Hay muy pocas cosas por las que estoy dispuesto a esperar 10 años. Dejé .NET hace varios años y desde diciembre he estado mirando hacia atrás para ver si la situación ha mejorado. Estoy más que un poco desanimado al encontrar muchos de los mismos problemas que dejé atrás, todavía persistentes.

Lo digo con toda sinceridad, quiero volver a amar .NET. Por favor, tómese esto en serio.

Lo digo con toda sinceridad, quiero volver a amar .NET. Por favor, tómese esto en serio.

Nos estamos tomando este problema en serio y estamos trabajando activamente en la convergencia de los distintos tiempos de ejecución de .NET. Pero llevará tiempo, y es muy posible que decidamos que, a corto plazo, debido a consideraciones prácticas, tiene sentido continuar con Mono con una hoja de ruta más larga para la convergencia con .NET Core.

Todavía necesito 3 .NET para construir mis servicios y clientes

Supongo que los tres .NET a los que se refiere son .NET Framework, .NET Core y Mono. La buena noticia es que anunciamos en BUILD que .NET Core 3 tendrá soporte para aplicaciones de escritorio de Windows, por lo que esperamos que eso reduzca la necesidad de uno de esos tiempos de ejecución y proporcione más evidencia de que la convergencia es nuestro objetivo común.

FWIW, Mono ya ha cambiado al compilador Roslyn y al sistema de compilación msbuild, por lo que en realidad no es una cadena de herramientas diferente. Puede crear proyectos basados ​​en .Net Core y Mono en una única solución, con el mismo sistema de compilación y compilador. Mono también utiliza partes grandes y cada vez mayores de las bibliotecas de clases de .NET Core.

WASM es un objetivo bastante inusual. No solo no es posible compilar JIT, cosas como subprocesos, archivos y sockets tienen modelos muy diferentes a la mayoría de las otras plataformas. Mono tiene muchas tecnologías existentes desarrolladas para puertos a otras plataformas inusuales / restringidas como iOS, watchOS, PS4, etc.que ayudan con el puerto WASM, como el intérprete IL, la suspensión cooperativa de GC, Full AOT (sorprendentemente difícil para los genéricos) con el uso compartido de genéricos. , Backend de código de bits LLVM y enlace administrado.

Espero que el tipo de proyecto WASM de Mono use proyectos de estilo SDK, con un SDK de MSBuild entregado a través de NuGet y utilizable desde dotnet .

Creo que huelo algo de odio mono aquí, ¿no?
Por favor, no se apresure a querer deshacerse de Mono. ¿Recuerdas cuando Microsoft no amaba Linux? Mono estuvo ahí para los desarrolladores de C #. ¿Recuerdas cuando Microsoft no amaba Mac OS? Mono estaba allí de nuevo. Ahora JavaScript está comiendo nuestros almuerzos, ¿adivinen quién aparece? Puedes apostar que Mono está aquí para salvar el día, siendo el primer .net completo que se ejecuta en Wasm. ¡Por favor muestre algo de respeto!

Escucha, a los desarrolladores de C # de este lado nos encanta Mono. Están haciendo un trabajo fantástico. Deja a Mono en paz. Si el chico genial .Net Core quiere ir de fiesta, también está bien, ¡PERO MONO SE QUEDA!

@humbersoft Si quieres una razón por la que "odiamos" a Mono, te daré una. Está viendo errores como este en la consola de su navegador: "WASM: debería haber sido instalado en el` / Users / builder / jenkins / workspace / test-mono-mainline-webassembly / label / highsierra / sdks / out / wasm-interp / directorio lib / mono / 4.5 / mscorlib.dll '. " ¿Quién es Jenkins? ¡Qué mensaje tan extraño! Un desarrollador de Mono evidentemente codificó su ruta personal en el tiempo de ejecución.

@paulost Jenkins es un servicio de construcción continua. Buscalo. Es muy popular

Gracias @MisinformedDNA, pero ¿por qué Mono me dice que debería instalarse en esa ruta exacta en mi sistema? No estoy tratando de construir Mono, solo lo uso para ejecutar una aplicación Blazor. Un tiempo de ejecución enviado no debería informarle sobre su ruta de servicio de compilación.

No tengo el contexto completo del error, pero puedo garantizar que verá información de depuración adicional porque Blazor no es un producto enviado. Es posible que se envíe Mono, pero es posible que también estemos usando versiones de vista previa de Mono o bibliotecas de vista previa creadas sobre Mono. Recuerde, todavía estamos en la fase experimental.

Finalmente, Xamarin se ejecuta en Mono, que probablemente ejecuta miles de aplicaciones móviles. Es una tecnología bien hecha. ¿Sería mejor tener un tiempo de ejecución? Por supuesto. Pero .NET Framework es solo para Windows y Mono se creó más tarde como un puerto para la compatibilidad con Linux y luego se creó .NET Core para una mejor escalabilidad en la nube. ¿Realmente crees que MS prefiere administrar tres tiempos de ejecución separados? Por supuesto no. Pero no todos los idiomas tienen la escala o la ambición de .NET. Además, en caso de que se lo haya perdido, MS está transfiriendo WPF, WinForms y UWP a .NET Core 3.0 . .NET Core es el futuro, pero llevará tiempo.

Sí, el soporte de montaje web Mono está en versión preliminar y aún no se ha enviado en ninguna versión.

En este caso particular, el tiempo de ejecución intenta determinar el directorio de ensamblado del tiempo de ejecución (que contiene archivos como mscorlib.dll) en función de la ubicación del sistema de archivos actual, y el último recurso es la ruta en la que se compiló el tiempo de ejecución. En wasm, el concepto de una "ubicación del sistema de archivos" no se aplica realmente ... En otras configuraciones integradas similares, el código de incrustación generalmente registra un resolutor de ensamblado personalizado (por ejemplo, para resolver desde un archivo zip de Android APK), y supongo que no se ha establecido aquí todavía.

@PaulOst
Eso es lo que pasa con vivir a la vanguardia, es probable que te corten. Mono para WASM se encuentra en sus primeras etapas y es muy experimental, pero es más completo que el DotNet Anywhere en el que se basó originalmente Blazor. Aún no está pulido, por lo que es de esperar errores como el que experimentas.

A algunos desarrolladores les gustan los hot bits, otros prefieren esperar hasta que todo esté fresco y tranquilo. Estos son puntos calientes, tal vez necesite ajustar un poco sus expectativas. Sin embargo, entiendo la perspectiva, quieres un producto pulido. ¿Te imaginas esperar a que .NET Core apunte a Wasm? Es posible que no lo consigan hasta los 3 años. Mono es un producto sólido y es una suerte que Microsoft los tenga, de lo contrario, no tendríamos una historia .NET para WASM y tantas otras plataformas.

Otra cosa, les digo que la mayoría de los desarrolladores prefieren el nuevo Microsoft que está desarrollando tecnologías importantes como esta al aire libre. Al final, obtendremos un producto mejor.

Habiendo dicho todo eso, es posible que Blazor ni siquiera vea la luz del día por una variedad de buenas razones. Planifique eso también.

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

Unirse a esta discusión un poco tarde, pero sorprendido de que tanta gente esté preocupada por cómo se ejecuta su código estándar .NET. Coloque la etiqueta que desee en el tiempo de ejecución: Mono, .NET Core, FlubberGast, cualquiera que sea el tiempo de ejecución real que será diferente. No hay forma de que .NET Core en el servidor sea igual que .NET Core en WASM o compilando contra WASM. Entonces, ¿a quién diablos le importa?

Lo que importa es cómo el caucho se encuentra con la carretera o qué tan fácil es acceder a ese código de tiempo de ejecución. Estoy de acuerdo con @EisenbergEffect en que tener una ruta de nivel inferior más fácil para obtener el arranque de .NET podría ser un gran impulso para .NET en general.

¿Por qué no hacer de esto un impulso serio además de lo que hace Blazor, ya que seguramente impulsaría la innovación en torno a diferentes formas de usar .NET en el navegador? Esto solo puede ser una gran ventaja para la visibilidad de NET si surgen muchos proyectos nuevos que utilizan .NET de formas nuevas e innovadoras en el navegador. Estoy seguro de que Rob está preguntando porque tiene algunas ideas sobre cómo construir un nuevo marco de algún tipo :-)

Esto es factible hoy con el módulo Mono.wasm actual y en el futuro con .NET Core o al menos el compilador Mono AOT, pero creo que construir una interfaz de alojamiento estándar que podría facilitar la instalación de .NET en el navegador sería de gran ayuda esta meta. El tiempo de ejecución real podría luego conectarse e intercambiarse a medida que la tecnología y los recursos actualizados estén disponibles.

Esto parece una gran oportunidad para que .NET sea uno de los primeros en adoptar el espacio de Web Assembly. Lo que he visto con Blazor parece muy prometedor, pero creo que no es pensar de manera lo suficientemente progresiva si ese es el único punto de exposición oficial de WASM de .NET. Realmente me gusta el modelo Blazor y lo que permite, pero creo que eso es solo la punta del iceberg de lo que es posible si el ecosistema para ejecutar .NET fuera tan simple como crear una aplicación .NET estándar. No estoy hablando necesariamente de marcos de interfaz de usuario aquí, sino incluso de poder iniciar y llamar a clases .NET sueltas, ya sea como un punto de entrada y un procesamiento similar al de Web Worker, o incluso como un medio para interoperar desde aplicaciones JavaScript existentes. Incluso para eso, los beneficios de compartir algún código comercial / de validación podrían ser increíblemente valiosos.

Mucho potencial: sería genial habilitar eso tanto como sea posible facilitando el uso de esta tecnología, ¡incluso los bits de nivel inferior!

@RickStrahl Puede que no parezca progresivo porque todavía se encuentran en la fase experimental, pero tienen muchas ideas en las que están trabajando, incluida la renderización del servidor, aplicaciones de escritorio / móviles, trabajadores web, etc. Esto le dará una mejor idea de qué están considerando.

Oh, no creo que Blazor no sea progresivo - aclaré en mi mensaje anterior. Incluso jugando con esto, puedo decir que será una excelente manera de crear aplicaciones. Hay tantos pequeños momentos en los que simplemente vas, esto sería una molestia en Javascript / TypeScript.

Mi punto es principalmente que creo que también deberían agregar la funcionalidad .NET en bruto

No estoy seguro de haber entendido, Blazor nos permite usar la mayor parte de la funcionalidad .NET, ¿qué funcionalidad específicamente crees que falta?

Tengo que usar Blazor. ¿Qué sucede si tengo una aplicación HTML existente o si estoy construyendo algo con otro marco y no necesito Blazor? Todavía existe un gran caso de uso para proporcionar acceso al código .NET en el navegador fuera de un marco HTML (compartir código de validación, utilidades, etc., etc.).

Tengo que usar Blazor. ¿Qué sucede si tengo una aplicación HTML existente o si estoy construyendo algo con otro marco y no necesito Blazor? Todavía existe un gran caso de uso para proporcionar acceso al código .NET en el navegador fuera de un marco HTML (compartir código de validación, utilidades, etc., etc.).

No entiendo. Blazor es esencialmente:

1. Sintaxis de Razor para componentes web,
2. varios ayudantes de interoperabilidad de JS,
3. WebAssembly .NET basado en mono

Es de suponer que quieres el segundo y el tercero, y el primero no te hace daño.

Mi punto es principalmente que creo que también deberían agregar la funcionalidad .NET en bruto además de las cosas de Blazor. Esta infraestructura debe construirse de todos modos para admitir Blazor, así que, ¿por qué no exponerla de una manera más fácil de usar para que sea más fácil colocar el 'alojamiento' .NET en una aplicación cliente?

Esa es ciertamente la intención del esfuerzo de mono.wasm tal como yo lo entiendo. A menudo nos referimos a Blazor y mono.wasm al mismo tiempo, pero en realidad Blazor es solo un marco web. Es mono.wasm que proporciona el tiempo de ejecución .NET basado en WebAssembly subyacente. Otros marcos se pueden construir libremente sobre el mismo tiempo de ejecución, y ya existen marcos alternativos ( Ooui , Uno ). @kumpera @mhutch son probablemente las personas adecuadas en el equipo de Xamarin para hablar sobre la experiencia de desarrollo que esperan habilitar con el uso de mono.wasm independientemente de cualquier marco de interfaz de usuario en particular.

El archivo zip proporciona, hoy en día, un soporte extremadamente puro para escribir aplicaciones C # sin Blazor. Es lo suficientemente bueno para validar la tecnología, pero requiere mucho trabajo manual.

Nuestro objetivo es proporcionar lo que sugiere esta descripción del problema, una cadena de herramientas completa que incluye enlaces enriquecidos y depuración.

¿Qué archivo zip?

@EisenbergEffect lo que debería preocuparle es .NET Standard, no .NET Core.
Asegúrese de que sus API dependientes se basen en .NET Standard y esté bien.

@weitzhandler Creo que puede estar perdiendo mi punto. Si quiero construir algo con .NET, tengo que instalar un conjunto concreto de herramientas, ¿no es así? Comencé a trabajar con .NET hace más de 15 años, por lo que personalmente no encuentro nada de esto abrumador o confuso (aunque prefiero no tener herramientas casi duplicadas instaladas en mi máquina). Pero imagine a alguien que no tenga experiencia con .NET y que sea usuario de Mac. Deciden que quieren crear una aplicación .NET, tanto de front-end como de back-end. Escuchan que .NET Core es lo último y elegante, por lo que pasan por el rigamarole para instalar .NET CLI y VS Code. Luego, descubren que no pueden construir su interfaz con eso. Necesitan ir a buscar un conjunto diferente de herramientas (con un nombre diferente, de un lugar diferente, con un liderazgo diferente, etc.). Nuevamente, imagine que no tienen antecedentes con .NET. Esta no es una buena experiencia para la primera vez. Bien, ahora imagine que esta persona es un arquitecto o un director de tecnología que está tratando de realizar una nueva evaluación de .NET, ya sea por primera vez o después de varios años. Tal vez estén marcando el rumbo de su empresa. ¿Es esta la experiencia que desea que tenga esa persona o sus asesores técnicos? Lo compararán con Go, Node, Rust, etc.

En cuanto a mis sentimientos personales, mi tolerancia es bastante baja después de tantos años y tantas versiones de .NET. Estoy tratando de ayudar a personas como @ danroth27 a comprender un poco lo que tiene que suceder para que personas como yo se interesen en .NET nuevamente. Hay mucho más que esto, pero tener un poco más de unificación ciertamente ayudaría. Solo quiero instalar un solo CLI y VS Code. El proceso de puesta en marcha con una aplicación .NET de pila completa en plataformas que no son de Windows no debería ser más complicado que eso.

Mi publicación original tenía la intención de pintar una imagen simple de cómo debería verse una "estrella del norte" de WASM desde una experiencia de desarrollo y una perspectiva de salida de construcción. Instalo la CLI, escribo algo de código C # (con el editor que quiera) y luego ejecuto un comando CLI para construir mi código C # en WASM, produciendo un conjunto razonable de archivos de salida (wasm, enlaces, tipos). Ese debería ser el objetivo. Si no está ahí hoy, es comprensible. Pero asegurémonos de que estamos navegando .NET en la dirección correcta, hacia la mejor experiencia posible, sin conformarnos con lo que es simplemente más fácil o más rápido para los ingenieros de Microsoft.

@EisenbergEfecto
Rob, estoy de acuerdo en que el objetivo eventualmente sería que .NET Core se ejecutara en todas partes, incluso reemplazando a Mono con él.
Incluso me gustaría que se incluyera un " .NET UI Standard " que se representa en todas partes igual con .NET Core, pero .NET Core es relativamente nuevo. .NET Standard fue la mejor solución para dar forma a esta divergencia, y actualmente no parece que pueda pedir nada mejor.

Mi voto es para reemplazar Mono con .NET Core por los mismos puntos que hizo @EisenbergEffect .

@EisenbergEffect Tengo un sueño con un micro caliburn para web, ¿es esto lo que tienes en mente? De hecho, comencé a trabajar en un sucesor espiritual con knockout y Duocode (puerto JavaScript de mscorlib) hace un tiempo antes de que el ensamblaje web fuera una cosa.

@AndersMalmgren Aurelia es muy parecido a Caliburn.Micro para web hoy. La versión vNext en la que estamos trabajando para su lanzamiento este año incluso admite renderizadores alternativos para que pueda renderizar no solo en HTML, sino también en aplicaciones nativas de escritorio, 3D y de consola. Está escrito en TypeScript, no en .NET. Podría ser posible portar Aurelia a .NET Core en algún momento en el futuro, una vez que esta tecnología madure un poco más.

Dicho esto, dado que Microsoft está construyendo Blazor, es menos probable que construya personalmente algo para .NET WASM porque eso me pondría en competencia con Microsoft. Por la historia, sabemos que ningún código abierto dentro del ecosistema .NET equivale a algo cuando Microsoft ha decidido construir algo similar, independientemente de si ese código abierto está mejor diseñado, es más extensible, más eficiente, etc. Admito que soy bastante hastiado aquí. Lo único que probablemente cambiará esto es si Microsoft me contratara para dirigir un marco y un ecosistema front-end basado en .NET Core. Aunque no sería Blazor. Blazor no está diseñado correctamente (está repitiendo los patrones de anit de .NET de hace 10 años), ni es lo suficientemente ambicioso, ni cumple con los estándares ni mira hacia el futuro, en mi opinión. Hay una gran oportunidad en juego para Microsoft, pero la ventana se está cerrando. Intenté convencer a varias personas de Microsoft para que aceptaran lo que podían hacer, pero hasta ahora no he tenido éxito. El front-end simplemente no parece ser una gran prioridad para Microsoft en este momento.

@EisenbergEffect El problema para mí es que Blazor usa Razor, que es MVC. Necesitamos un verdadero MVVM que pueda aprovechar el tiempo de ejecución de un clr completo. Como plantillas basadas en convenciones de tipo, etc. Comencé este trabajo con DuoCode y knockout y usé Knockout.BindingConventions para unirlos. Incluso tengo una sintaxis como esta funcionando

public IEnumerable<IResult> Save()
{
    var confirm = new ConfirmResult("Proceed?");
    yield return confirm;

    if (confirm.Result == ConfirmResults.Cancel)
        yield break;

    yield return new service.SendCommand(new SaveSomethingCommand(this.something));
}

https://github.com/AndersMalmgren/Knockout.BindingConventions.DuoCode/wiki/IResult-state-machine

Knockout se extinguió y mi interés por él. Pero el sueño sigue vivo: D

Bueno, podría retomar el trabajo pero con Vue o similar.

Quizás Aurelia en lugar de Vue, ya que Aurelia desciende de Durandal, que viene de Caliburn.Micro. Además, Aurelia tiene convenciones, modelos vanilla JS, funciona mejor, tiene un fuerte cumplimiento de estándares y mucha más bondad que otros marcos no tienen 😄

Aunque no sería Blazor. Blazor no está diseñado correctamente (está repitiendo los patrones de anit de .NET de hace 10 años), ni es lo suficientemente ambicioso, ni cumple con los estándares ni mira hacia el futuro, en mi opinión.

¿Qué le pasa?

@EisenbergEffect o Aurelia. Me gusta Aurelia, pero como usa JavaScript o Typescript, que es un lenguaje de borrado de tipos, pierdes toda esa dulce magia de tiempo de ejecución de CLR que puedes hacer. Además, JavaScript DI es para ser una mierda honesta en comparación con lo que puede hacer con un tiempo de ejecución de clr adecuado. Implementé un pequeño contenedor DI para Duocode para el mismo proyecto mencionado anteriormente y, en mi opinión, la inyección basada en tipos en la interfaz es el camino a seguir. Necesito analizar la modularidad de Aurelia, el nocaut era muy extensible en el pasado, y Vue parece continuar esa tendencia.

@AndersMalmgren Aurelia es probablemente el marco de front-end más extensible en la actualidad. La implementación de vNext en la que estamos trabajando también lo lleva a otro nivel. También te sorprenderá lo que podemos hacer con nuestro DI :) Está basado en tipos y tiene una vida útil extensible, etc. Dado que JS tiene soporte nativo para clases, no hay borrado. También podemos modelar interfaces con un método auxiliar DI o un símbolo Vanilla JS. Por lo tanto, TS puede fusionarlos con interfaces de TS, lo que permite los mismos patrones que .NET. En otras palabras, puedes inyectar IAuthenticationService en una clase en tiempo de ejecución 😄 Hasta donde yo sé, somos el único marco que puede hacer esto. Traté de traer la mayor parte de las partes buenas de Xaml y Caliburn.Micro a la web, dejando atrás las partes malas. Entonces MVVM también es mucho más simple y más poderoso en Aurelia. Reuniré una serie de publicaciones de blog sobre Aurelia para desarrolladores de Xaml y Aurelia para desarrolladores de ASP.NET MVC. Eso podría ayudar a las personas a conectar los puntos y comprender por qué / cómo hace que el desarrollo de front-end no solo sea rápido y fácil, sino también SÓLIDO.

@manigandham Pasé muchos, muchos años como desarrollador de .NET, líder de código abierto de .NET y MVP de Microsoft, dando muchos comentarios a Microsoft sobre cosas como esta. Incluso trabajé para Microsoft como PM Sr., Gerente de PM Sr. y Gerente de PM principal por un corto tiempo (aunque no en el equipo de .NET). Desafortunadamente, durante un período de aproximadamente 12 años mientras estaba haciendo eso, vi muy poco salir de él, particularmente con respecto a la retroalimentación que di sobre los marcos de front-end. Por lo tanto, tendrá que perdonarme si no tengo ganas de pasar el sábado escribiendo un artículo de 10.000 palabras sobre los problemas de diseño con Blazor, los problemas de estándares web, la visión del producto, etc. No estoy seguro de que así sea. una cantidad cualquiera. Si Microsoft quiere contratarme para liderar el futuro del front-end para ellos, ciertamente lo consideraría, pero como dije, el front-end no es realmente una prioridad para ellos en este momento. Y hasta donde yo sé, Blazor ni siquiera está financiado todavía.

Y para aquellos que no me conocen, solo quiero agregar que no estoy enojado por todo esto o por una persona enojada. Sé que a veces las cosas parecen un poco así cuando no me conoces y solo lees mis comentarios aquí o allá. Sin embargo, soy un apasionado del front-end. He estado creando frameworks, bibliotecas y herramientas front-end durante casi toda mi carrera. Son 15 años cortos, pero comparativamente es mucho tiempo para dedicarlo a esta área. Entonces, he visto muchas cosas, he hecho muchas cosas y tengo opiniones sólidas. Me apasiona y me frustra cuando veo que Microsoft repite viejos errores o hace cosas que ya he visto salir mal en otros lugares. Entonces, no tengo mala voluntad aquí. Realmente quiero que Microsoft tenga éxito. Quiero verlos ser el líder en el front-end. Me siento frustrado y un poco triste para ser honesto, cuando veo que eso no está sucediendo. Quiero lo mejor para .NET y su comunidad.

Tendrás que perdonarme si no tengo ganas de pasar el sábado escribiendo un artículo de 10k palabras sobre los problemas de diseño con Blazor.

El caso es que hiciste un reclamo y luego alguien simplemente te pidió que lo explicaras con más detalle:

Blazor no está diseñado correctamente (está repitiendo los patrones de anit de .NET de hace 10 años), ni es lo suficientemente ambicioso, ni cumple con los estándares ni mira hacia el futuro, en mi opinión.

Yo también tendría curiosidad por conocer ejemplos concretos.

Y dada la naturaleza de Blazor en este momento, no estoy seguro de que sea justo compararlo con un producto de Microsoft promedio. Todavía no es un producto y se está desarrollando al aire libre mucho más de lo que sería si lo fuera.

@chucker lo entiendo. Es barato de mi parte hacer una afirmación como esa y no entrar en detalles. Estoy agradecido de que esté interesado en escuchar más.

Sin embargo, desde mi perspectiva, la mayor parte de lo que diría son comentarios que le he dado a Microsoft antes, a menudo repetidamente antes. Entonces, aunque sería interesante para usted, no estoy seguro de que suponga una diferencia para Microsoft. No sé si cambiaría algo.

Dicho esto, intentaré comenzar a esbozar algo. Sin embargo, sería demasiado tiempo dejar caer un comentario de GitHub. Tengo un poco de miedo a las reacciones violentas si publico un blog al respecto. Me han acosado y odiado muchas veces en mi carrera por varios grupos a los que no les gustaba que me criticaran. Si bien recientemente han sido miembros del equipo de Facebook / React, no estoy seguro de querer abrirme nuevamente.

Tal vez haya alguna forma en la que pueda enmarcar una publicación de este tipo en la que marcaría la diferencia y no invitaría a muchas personas negativamente. Es un juego difícil de jugar. Aunque lo pensaré un poco.

Puedo confirmar que, en muchos sentidos, Blazor, tanto conocido como desconocido, no está perfectamente diseñado y agradecemos cualquier comentario constructivo para mejorarlo. Como lo demuestra nuestra acumulación de problemas, ¡hay mucho trabajo por hacer! Y aunque es casi seguro que la perfección del diseño seguirá siendo difícil de alcanzar, al final lo que realmente importa es si los desarrolladores encuentran que el uso de Blazor es productivo y útil. Eso parece alcanzable.

@EisenbergEffect Ciertamente,

Además, nadie merece ser acosado u odiado y tal comportamiento va explícitamente en contra de nuestro Código de Conducta .

En mi humilde opinión, Blazor ya lo ha logrado. En mis 20 años de desarrollo con tecnologías de Microsoft y que no son de Microsoft, he visto surgir el mismo patrón cada vez. Cada vez que sale algo nuevo, ves dos tipos de desarrolladores. Uno que ve el modelo de programación como un vehículo para llegar a algún lado y uno al que le gusta pasar horas y horas jugando con diferentes bibliotecas. He tratado de convencerme de que el uso de todas estas bibliotecas js diferentes de todas estas compañías diferentes me da más movilidad y libertad como desarrollador, pero pronto descubro cómo todas se diferencian en visión, misión y, lamentablemente, compatibilidad en algún momento. Siempre terminé buscando un modelo de programación unificado y me di cuenta de que las convenciones estrictas no siempre son algo malo. En breve. Me importa la solución y Microsoft nunca me ha defraudado. Algunas de mis mejores y más utilizadas aplicaciones web están hechas con tecnología de Microsoft y creo que Blazor traerá un buen modelo de programación unificada que funciona bien pero que no depende de que cientos de otras bibliotecas trabajen juntas.

En mi humilde opinión, Blazor ya lo ha logrado. En mis 20 años de desarrollo con tecnologías de Microsoft y que no son de Microsoft, he visto surgir el mismo patrón cada vez. Cada vez que sale algo nuevo, ves dos tipos de desarrolladores. Uno que ve el modelo de programación como un vehículo para llegar a algún lado y uno al que le gusta pasar horas y horas jugando con diferentes bibliotecas. He tratado de convencerme de que el uso de todas estas bibliotecas js diferentes de todas estas compañías diferentes me da más movilidad y libertad como desarrollador, pero pronto descubro cómo todas se diferencian en visión, misión y, lamentablemente, compatibilidad en algún momento. Siempre terminé buscando un modelo de programación unificado y me di cuenta de que las convenciones estrictas no siempre son algo malo. En breve. Me importa la solución y Microsoft nunca me ha defraudado. Algunas de mis mejores y más utilizadas aplicaciones web están hechas con tecnología de Microsoft y creo que Blazor traerá un buen modelo de programación unificada que funciona bien pero que no depende de que cientos de otras bibliotecas trabajen juntas.

Si Microsoft no tomara influencia externa, estaríamos atrapados en winforms y webforms.

https://devblogs.microsoft.com/dotnet/introducing-net-5/
Hoy anunciamos que la próxima versión después de .NET Core 3.0 será .NET 5. Esta será la próxima gran versión de la familia .NET.

Habrá solo un .NET en el futuro, y podrá usarlo para apuntar a Windows, Linux, macOS, iOS, Android, tvOS, watchOS y WebAssembly y más.

Presentaremos nuevas API de .NET, capacidades de tiempo de ejecución y características de lenguaje como parte de .NET 5.