ASP.NET Core 2.0 Razor vs Angular / React / etc

101

Mi equipo y yo hemos recibido financiación para empezar a desarrollar una aplicación web de nivel empresarial (no entraré en detalles de lo que hace). La aplicación tendrá muchas páginas web separadas, pero dos de esas páginas estarán más enfocadas y serán muy pesadas: pesadas como en mucha interacción del usuario, modales que muestran datos masivos, conexiones websocket, chat, etc.

Se me ha asignado el cargo de arquitecto jefe en el proyecto, por lo que estoy investigando los últimos marcos web. Para el back-end, hemos hecho algunas pruebas y hemos decidido ir con la plataforma Azure SQL. Hasta ahora, me gustan las mejoras que se han realizado y se están realizando en ASP.NET con Core 2.0. Específicamente el motor Razor, sobre versiones anteriores de ASP.NET MVC.

Quería obtener algunas opiniones de expertos sobre el "nuevo" Razor vs. Angular / React y similares. En particular, me preocupa más el rendimiento. ¿Cómo se mantiene Core 2.0 Razor en los marcos de renderización del lado del cliente? ¿Son las diferencias insignificantes? Nuestra aplicación está dirigida a un potencial de 1.000.000 de usuarios (aproximadamente 100.000 simultáneos).

¡Gracias por adelantado!

— TchPowDog
fuente

¿Con " nueva Razor " te refieres a las páginas de Razor?

— Werner

Entonces, ¿cuál elegiste al final y cómo te va?

— stt106

¿Cómo te fue (o te va) con este proyecto? ¡Estoy en una situación casi idéntica a la tuya ahora y me encantaría una actualización!

— JLo

Hola JLo y stt106. Disculpe tomó mucho tiempo en responder. Terminamos optando por un front-end angular y un backend de API ASP.NET Core, utilizando Azure SQL. ¡Nos ha funcionado muy bien hasta ahora! Me imagino que React sería un reemplazo similar a Angular si te sientes más cómodo con él. Tuve que aprender Angular, que fue una transición muy fácil, ¡y ahora me encanta!

— TchPowDog

¿La comparación de velocidad de ASP.Net Core vs Angular / React está fuera de tema? Puede haber respuestas canónicas. En cuanto a hoy tenemos Core 2.2 y próximamente 3.0.

— MikroDel

Respuestas:

Terminamos optando por un front-end angular y un backend de API ASP.NET Core, utilizando Azure SQL. Probamos Core Razor y, aunque mejor que el Razor heredado, Angular fue mucho más rápido para nosotros al final. En lo que respecta a la experiencia del usuario, Angular (o React) es muy superior en términos de rendimiento. Descubrimos que los aspectos de enlace de modelos de Angular son una ventaja gigantesca de la representación del lado del servidor. Sin embargo, el uso de Razor (o la representación del lado del servidor en general) se presta a una mejor integridad general en lo que respecta a los datos y permite una mejor transición de los datos de front-end a back-end. Existe una verdadera desconexión entre un marco front-end y una API. Todos los datos que se pasan al servidor deben convertirse en objetos con tipo; esto significa que debe administrar dos conjuntos de modelos POCO separados. Esto puede causar problemas si los objetos del servidor y los objetos del front-end no se alinean. Por el momento, Entity Framework Core no está muy maduro, por lo que tenemos problemas para actualizar objetos, consultar objetos, incluidos objetos secundarios, etc.

En general, esta configuración nos ha funcionado muy bien hasta ahora. Me imagino que React sería un reemplazo similar a Angular si te sientes más cómodo con él. Tuve que aprender Angular, que fue una transición muy fácil, ¡y ahora me encanta!

— TchPowDog
fuente

En cuanto a mantener sincronizados los dos conjuntos de modelos POCO, hay una extensión realmente útil para VS que crea interfaces angulares a partir de modelos MVC, consulte la máquina de escribir

— Andy Braham

bueno, personalmente, si tuviera que ir con Angular, usaría NoSql para la parte DB.

— Venzentx

No puedo imaginarme seleccionando la maquinilla de afeitar ASP.NET por encima de Angular. En el pasado, ASP.NET proporcionó un código familiar para los desarrolladores de .NET, pero con RAZOR, la curva de aprendizaje es mayor que con Angular. MVC divide la lógica del HTML.

— Mark

@ Mark No lo creo. Las páginas de Razor son perfectas, específicamente la forma en que manejan el enlace de datos. Son demasiado buenos. Pero ofcource para su escenario angular es perfectamente adecuado.

— Mosia Thabo

@MosiaThabo, Mark no está hablando de Razor Pages, está hablando de Razor. Que es a lo que se refería mi OP. En mi publicación original, no me refería a Razor Pages (o ahora llamado Blazor, creo). Estaba hablando específicamente de la representación del lado del cliente frente a la representación del lado del servidor. Razor Pages es la versión de Microsoft de Angular / React, que creo que ven como necesaria debido a las ventajas que tiene con Angular y React.

— TchPowDog

Al usar Angular / React con api en el lado del servidor:

eliminas el proceso de generar HTML en el lado del servidor y ahorras cpu
api produce una pequeña carga útil (json) y Razor (html) de un curso sería mucho más grande en tamaño, recargas constantes de página completa y ida y vuelta de devolución de datos. entonces api y spa ahorran ancho de banda
api y spa podrían tener diferentes escenarios de versiones, escalado e implementación
Al usar api, también puede admitir la aplicación móvil y, si comienza con Razor, es posible que necesite api en el futuro

pero al usar Angular / React deberías preocuparte por los clientes.

el cliente debe habilitar javascript
el cliente debe tener navegadores modernos
el cliente debe tener suficiente hardware potente
SEO

— Mohsen Esmailpour
fuente

Entiendo las diferencias en los dos marcos, estaba más preocupado por el rendimiento.

— TchPowDog

Existe la misma pipline para ambos, pero no sé que exista ningún punto de referencia para las páginas de afeitar. este enlace puede ayudar - ASP.NET Razor Pages vs MVC: ¿Cómo encajan las Razor Pages en su caja de herramientas?

— Mohsen Esmailpour

Razor es compatible con dispositivos móviles, las desventajas que se enumeran realmente no importan. Ambos son rápidos a su manera. Prefiero Angular, pero ambos están optimizados. Razor optimiza el código al no usar un árbol como lo hace MVC. Angular es del lado del cliente, por lo que realmente no usa un árbol, sino que también optimiza los datos en el HTML hasta cierto punto.

— Nick Turner

@NickTurner Lo entendí no solo como ver la página web en su teléfono inteligente, sino como una aplicación propia completa. Por ejemplo, una aplicación de Android, que podría obtener los datos de la API del servidor sin cambios tal cual, mientras que por otro lado usa la funcionalidad que proporciona Android: mejor soporte de animación, notificaciones, mensajes de brindis, etc.

— Raphael Schmitz

No tengo puntos de referencia. Pero tengo varios proyectos que ejecutan JQuery, Razor, .NET MVC (C #), AJAX. No a la escala que estás abordando.

Consejos ... Asegúrese de pensar detenidamente y seguir las mejores prácticas. Para mantener las cosas fáciles de mantener, asegúrese de dividir controladores, vistas y modelos en grupos más pequeños y significativos. Cuando comencé, cometí el error de poner todo en un controlador de inicio y un montón de vistas en la carpeta compartida. Al principio estaba bien, pero cuando comenzó el deslizamiento de funciones, se volvió un desastre y fue difícil volver atrás y rediseñarlo.

También uso Linq2SQL. Cometí el error de crear modelos para todo y luego me di cuenta de que podía devolver el conjunto de resultados de mis consultas como modelo. duh.

Si va .NET MVC y le preocupa el rendimiento, estas son las cosas con las que me encontré:

¡NO devuelva vistas parciales que creen grandes bloques de HTML! Asegúrese de minimizar todo. Deshazte de todos los espacios en blanco. Utilice nombres de identificación más pequeños. Tómate el tiempo para crear un HTML lo más ligero posible. Devuelva JSON y haga que el cliente haga parte del trabajo.

Tenga cuidado con la forma en que desarrolla su CSS. No use muchos estilos en línea, tómese el tiempo para incorporarlos en archivos CSS que luego pueda minimizar.

Lo mismo ocurre con el JS del lado del cliente. Es tentador poner el JS dentro de vistas parciales. Mantenga las cosas organizadas.

El renderizado en IE es horrible. Especialmente si hay muchas imágenes. Asegúrese de comprimir las imágenes tanto como sea posible, sin perder calidad, por supuesto.

— Keith Aymar
fuente