Pros y contras de una aplicación web solo HTML / JavaScript [cerrado]

35

Vengo de un fondo de formularios ASP.NET y he encontrado que la codificación del lado del servidor es muy poderosa en el pasado. Sin embargo, más recientemente, he estado deseando eliminar el código del lado del servidor del front-end y reemplazarlo con HTML / JavaScript puro, que accede a los datos a través de los servicios web JSON. No tengo experiencia real en esto, por lo que me gustaría saber si este es un modelo probado. Además, ¿cuáles son las trampas que lo rodean?

Considero que los controles de usuario de ASP.NET son muy útiles, por lo que me gustaría mantener la teoría detrás de esto almacenando plantillas de marcado en archivos HTML separados en el servidor. Estos serán recuperados y utilizados a través de jQuery AJAX y el complemento de plantillas HTML jQuery respectivamente.

Cualquier aportación será extremadamente apreciada.

PD: Perdón por la pregunta novata, pero ¿es este tipo de arquitectura web lo que se conoce como web-2.0 o estoy completamente fuera de lugar?

hofnarwillie
fuente
1
¿Desea reemplazar los controles asp.net con HTML / JavaScript o desea exponer toda la lógica empresarial (validación, etc.) al frente?
šljaker
1
Buena pregunta. Estoy pensando en hacer la interfaz solo en html / javascript para aligerar la página para que sea más rápida en móviles / pads. Así que probablemente solo reemplace los controles asp.net. Todas las llamadas al servidor a través de un servicio web, por lo que el servicio wcf debería encargarse de la validación, etc. ¿Cree que esto es posible?
hofnarwillie
Estoy haciendo preguntas similares aquí: stackoverflow.com/questions/34020543/… y aquí: stackoverflow.com/questions/33934101/…
smwikipedia
@hofnarwillie para la validación, creo que deberías usar JS del lado del cliente.
smwikipedia
1
@smwikipedia Gracias, pero creo que la validación del lado del cliente solo debe usarse para facilitar a los usuarios. La validación real debe hacerse del lado del servidor. La validación del lado del cliente hace que su aplicación sea fácil de usar, pero la validación del lado del servidor garantiza la seguridad y la validez, porque la validación del lado del cliente se puede desactivar fácilmente.
hofnarwillie

Respuestas:

31

He usado esta técnica exclusivamente para una aplicación web en la que estamos trabajando. Mi backend está alojado en Google App Engine utilizando el SDK de Java, y mi interfaz utiliza HTML, CSS y JavaScript (con jQuery).

El proyecto es más pequeño con solo yo y un diseñador web, y ambos sentimos que este método nos ha ayudado a trabajar mucho más rápido y a lanzar algo al mercado mucho antes.

Ventaja: trabajar con diseñadores web

La principal ventaja de esta técnica es que el diseñador web, que conoce algo de PHP pero no se considera un programador, puede trabajar sin restricciones en HTML y CSS sin tener que atravesar innumerables líneas de JSP, etiquetas de taglib y otros servidores. Se supone que el marcado que nos han dicho durante años hace que la vida de un desarrollador front-end sea mucho más fácil.

Sin todo el marcado del lado del servidor, hemos sido más ágiles. El diseñador web ha cambiado y revisado directamente su diseño original 3 o 4 veces, con muy pocos cambios de mi parte.

Su comentario para mí fue que sentía que el HTML estaba vivo, ya que podía editarlo e inmediatamente ver los cambios en su máquina con datos dinámicos. Ambos nos hemos beneficiado de esto porque la integración es principalmente automática.

Código del lado del servidor y transferencias HTML / CSS

En proyectos anteriores, tuvo que entregar el HTML y CSS a los desarrolladores de Java que luego tomarían su HTML y CSS y lo reescribirían por completo utilizando la tecnología JSP. Esto llevaría mucho tiempo y, por lo general, daría lugar a diferencias sutiles pero importantes en la representación real de las páginas, así como su validación en el validador W3C.

En general, los dos estamos bastante contentos con esta técnica, y todavía tengo cero páginas JSP o código del lado del servidor en mis páginas HTML.

Errores de la técnica REST / JSON

Quizás los mayores escollos son los que aún no hemos encontrado. Espero tener algunos desacuerdos con los desarrolladores de Java más experimentados a quienes les ha lavado el cerebro lo que la fundación Apache y el equipo de Spring les han dicho sobre cómo las bibliotecas de etiquetas hacen que sea más fácil para los desarrolladores frontend trabajar con el código. Espero que haya una curva de aprendizaje a medida que este proyecto se expande y nos enfrentamos a más desarrolladores que podrían tener que desaprender estas técnicas obsoletas que, en mi experiencia, han hecho que el trabajo de los diseñadores web sea más difícil .

Otro escollo es que el código JavaScript se ha vuelto muy masivo. Esto es más problemático tal vez porque estoy usando esta técnica por primera vez, y porque hemos introducido una pequeña deuda técnica al trabajar hacia una liberación rápida. Quizás elegir un mejor marco habría ayudado a aliviar gran parte del código. En mi opinión, nada de esto ha sido espectacular, y me alienta a seguir usando esta técnica y refinar mis habilidades en esta área.

Ventaja: se pueden construir otras aplicaciones en la plataforma

Por último, debo mencionar una ventaja oculta. Debido a que existe un buen grado de separación entre mis servicios web RESTful de back-end y mi interfaz, también he creado una plataforma que puedo ampliar fácilmente.

Uno de nuestros muchachos de operaciones quería probar una prueba de concepto en otra aplicación, y gracias a mis servicios RESTful, pudimos crear una interfaz completamente diferente para la aplicación para resolver un problema completamente diferente. La prueba de concepto desarrollada rápidamente utilizó su propio HTML, CSS y JavaScript, pero utilizó los servicios RESTful como backend y fuente de datos.

Al final, otro gerente de proyecto vio lo que había hecho, y quedó claro de inmediato que la característica necesitaba ser más que una simple prueba de concepto, por lo que su equipo la implementó.

No puedo enfatizar lo suficiente lo reutilizable que es esta arquitectura, tanto a nivel de aplicación como a nivel de HTML / CSS / JavaScript, y definitivamente te animo a que pruebes esto en tu próximo proyecto.

jmort253
fuente
2
Gracias. Esto responde mi pregunta por completo. Aprecie el tiempo que tardó en dar una respuesta clara y concisa. +1
hofnarwillie
2
Trabajo en una compañía donde todas las aplicaciones web internas son html / js solo con servicios de back-end que sirven datos codificados json. Esto funciona muy bien y es mucho más rápido para crear nuevas aplicaciones usando este modelo, y porque los desarrolladores de backend y frontales trabajan en paralela. Realmente deberías probar esto.
nohros
@ jmort253 Muchas gracias por la excelente respuesta. Estaba pensando exactamente en la misma arquitectura y su práctica me da confianza para seguirla. He hecho preguntas similares aquí: stackoverflow.com/questions/33934101/… y aquí: stackoverflow.com/questions/34020543/… .
smwikipedia
12

Ciertamente es una estrategia viable, pero no es una bala de plata.

Pros :

  • Si se hace correctamente, las aplicaciones desarrolladas de esta manera son muy receptivas
  • tiene una separación clara de lógica (en el servidor) y presentación (en el cliente); el servidor no tiene que preocuparse en absoluto por los aspectos de presentación de la aplicación
  • Uso potencialmente más eficiente del ancho de banda de la red (solo está enviando datos sin procesar, sin repeticiones)
  • más fácil de desarrollar GUI de escritorio, ya que depende menos del paradigma de solicitud / respuesta

Contras :

  • tienes que escribir tu código de cliente en Javascript, o en un idioma que pueda compilarse a Javascript, porque eso es lo único disponible en un navegador
  • El uso de recursos en el cliente puede ser mayor, por lo que la aplicación puede no funcionar bien en dispositivos de calidad inferior (piense en navegadores móviles, etc.)
  • no funcionará en absoluto con javascript deshabilitado; Si se trata de un sitio web público, debe pensar mucho si está dispuesto a asumir este riesgo (especialmente si considera el SEO y la accesibilidad; un enfoque basado en JavaScript suele ser devastador en estos dos frentes)
  • hay que escribir mucha lógica dos veces: una en el cliente y otra en el servidor (porque nunca puedes confiar en el cliente)
  • la concurrencia puede ser un infierno, por lo que debe diseñar su código del lado del cliente con mucho cuidado y estar preparado para todo tipo de problemas de concurrencia
tdammers
fuente
2
Gracias. ¿Puede dar un ejemplo de los problemas de concurrencia que podrían ser causados ​​por este modelo?
hofnarwillie
3
Ejemplo: si el usuario hace clic en Votar arriba y luego hace clic rápidamente en Votar abajo antes de que finalice la llamada al servidor Votar arriba, ¿cuántos votos hay?
JBRWilkinson
@JBRWilkinson ¿Bandera booleana que verifica el estado o el tiempo de espera o el intervalo?
Alper Turan
1

Definitivamente es posible, y probablemente alentador como mejor práctica. Lo que está proponiendo es dividir la interfaz de usuario de la lógica empresarial para que haya una separación clara de las preocupaciones. Esto es realmente bueno.

Con demasiada frecuencia, los marcos que tratamos de confundir y terminan con un software monolítico en el que la interfaz de usuario, la lógica de negocios y los datos se entrelazan entre sí. Eso hace que sea más difícil de mantener y modificar.

Una vez que divide la aplicación en 2 partes, puede reemplazar la interfaz de usuario por completo con algo más: un programa de escritorio u otra interfaz de usuario para dispositivos móviles en comparación con los navegadores de escritorio.

Los bits difíciles que encontrará al hacer esto es que un poco de código que en teoría debería estar en el servidor se colocaría mejor en el cliente, por ejemplo, la validación es más rápida y más receptiva para que el usuario coloque el código de validación en un formar en el cliente de lo que es presionar el servidor para verificar, por ejemplo, un campo de texto solo contiene caracteres alfanuméricos. Lo mismo a menudo se aplica a los datos y las capas empresariales. Solo tiene que tomar decisiones informadas y prácticas sobre cuándo violar la distinción entre las capas.

gbjbaanb
fuente
1

Un inconveniente es la necesidad de duplicar parte de la lógica en JavaScript y ASP.net. Esto podría no ser un gran problema para usted dependiendo de su aplicación. A menudo aparece porque no desea pedirle al servidor que verifique cada pequeña cosa ("¿Se le permite al usuario presionar este botón o seleccionar esta opción en esta situación?") Pero tampoco desea depender en el cliente como el único que realiza la validación ya que el usuario tiene control sobre el cliente.

Ken Fehling
fuente
0

Si todavía está utilizando ASP.NET WebForms y desea acelerar sus aplicaciones, esto es lo que debe hacer:

  • Diseñe su aplicación con SOLID en mente
  • Deshabilitar ViewStateen todas las páginas y controles de usuario
  • No use controles del lado del servidor

    <%: VeiwModel.Title%> en lugar de <asp: Literal id = "Title" runat = "server">

  • En el backend, anule el método OnInit y realice toda la inicialización allí:

    anulación protegida anular OnInit (System.EventArgs e) {CreateViewModel (); base.OnInit (e); }

  • Comprima todos los archivos .css y .js en 1 usando SquishIt

  • Imágenes de carga diferida
  • Caché de objetos complejos

Finalmente, visite www.porsche.se. ¿No es un sitio web muy rápido?

šljaker
fuente
Eso realmente es un sitio web rápido. Muchas gracias por el aporte. Muy apreciado.
hofnarwillie