Eu usei essa técnica exclusivamente para um aplicativo da Web em que estamos trabalhando. Meu back-end está hospedado no Google App Engine usando o Java SDK e meu front-end usa HTML, CSS e JavaScript (com jQuery).
O projeto é menor, apenas eu e um designer da Web, e nós dois sentimos que esse método nos ajudou a trabalhar muito mais rápido e a lançar algo no mercado muito mais cedo.
Vantagem: Trabalhando com Web Designers
A principal vantagem dessa técnica é que o web designer, que conhece algum PHP, mas não se considera um programador, pode trabalhar sem ônus no HTML e CSS sem precisar percorrer inúmeras linhas de JSP, tags taglib e outros servidores. a marcação que nos disseram há anos deve facilitar a vida de um desenvolvedor front-end.
Sem toda a marcação do lado do servidor, fomos mais ágeis. O web designer trocou diretamente e revisou seu design original 3 ou 4 vezes, com muito poucas alterações da minha parte.
Seu comentário para mim foi que ele sentia que o HTML estava vivo, pois podia editá-lo e ver imediatamente as alterações em sua máquina com dados dinâmicos. Nós dois nos beneficiamos disso, pois a integração é quase sempre automática.
Código do lado do servidor e transferências de HTML / CSS
Em projetos anteriores, ele teve que transferir o HTML e CSS para desenvolvedores de Java, que pegariam seu HTML e CSS e os reescreveriam completamente usando a tecnologia JSP. Isso levaria muito tempo e normalmente resultaria em diferenças sutis, porém importantes, na renderização real das páginas, bem como em sua validação no validador W3C.
No geral, estamos muito felizes com essa técnica e ainda tenho zero páginas JSP ou código do lado do servidor em minhas páginas HTML.
Armadilhas da técnica REST / JSON
Talvez as maiores armadilhas sejam aquelas que ainda não encontramos. Eu espero ter algumas divergências com desenvolvedores Java mais experientes que sofreram lavagem cerebral com o que a fundação Apache e a equipe do Spring disseram a eles sobre como as bibliotecas de tags facilitam o trabalho dos desenvolvedores de front-end com o código. Espero totalmente que haja uma curva de aprendizado à medida que esse projeto se expande e contratamos mais desenvolvedores que talvez precisem desaprender essas técnicas ultrapassadas que, na minha experiência, tornaram o trabalho dos designers da Web mais difícil .
Outra armadilha é que o código JavaScript se tornou muito grande. Isso é mais um problema, talvez porque estou usando essa técnica pela primeira vez e porque apresentamos uma pequena dívida técnica ao trabalhar em direção a uma liberação rápida. Talvez a escolha de uma estrutura melhor ajudasse a aliviar grande parte do código. Na minha opinião, nada disso foi um empecilho para o show, e eu sou encorajado a continuar usando essa técnica e refinar minhas habilidades nessa área.
Vantagem: Outros aplicativos podem ser criados na plataforma
Por fim, devo mencionar uma vantagem oculta. Como existe um bom grau de separação entre meus serviços Web RESTful de back-end e meu front-end, também criei uma plataforma que posso estender facilmente.
Um de nossos funcionários de operações queria tentar uma prova de conceito em outro aplicativo e, graças aos meus serviços RESTful, conseguimos criar um frontend totalmente diferente para o aplicativo para resolver um problema completamente diferente. A prova de conceito desenvolvida rapidamente usou seu próprio HTML, CSS e JavaScript, mas usou os serviços RESTful como back-end e fonte de dados.
No final, outro gerente de projetos viu o que eu havia feito e ficou imediatamente claro que o recurso precisava ser mais do que apenas uma prova de conceito, para que sua equipe o implementasse.
Não posso enfatizar o suficiente como essa arquitetura é reutilizável, tanto no nível do aplicativo quanto no nível HTML / CSS / JavaScript, e eu definitivamente o encorajaria a tentar isso em seu próximo projeto.