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.