Prós e contras de um aplicativo da web somente HTML / JavaScript [fechado]

Eu venho de um background de formulários ASP.NET e achei a codificação do lado do servidor muito poderosa no passado. Mais recentemente, no entanto, eu queria reduzir o código do lado do servidor do front-end e substituí-lo por HTML / JavaScript puro, que acessa os dados por meio de serviços da Web JSON. Não tenho experiência real nisso, e gostaria de saber se esse é um modelo testado e comprovado. Além disso, quais são as armadilhas que o cercam?

Acho os controles de usuário do ASP.NET muito úteis, portanto, gostaria de manter a teoria por trás disso armazenando modelos de marcação em arquivos HTML separados no servidor. Estes serão recuperados e usados ​​através do jQuery AJAX e do plug-in de modelos HTML do jQuery, respectivamente.

Qualquer entrada será extremamente apreciada.

PS Desculpe pela pergunta noob, mas esse tipo de arquitetura da Web é chamado de web-2.0 ou estou completamente fora de controle?

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.

Certamente é uma estratégia viável, mas não é uma bala de prata.

Prós :

• se bem feito, os aplicativos desenvolvidos dessa maneira são muito responsivos
• você tem uma clara separação de lógica (no servidor) e apresentação (no cliente); o servidor não precisa se preocupar com os aspectos de apresentação do aplicativo
• uso potencialmente mais eficiente da largura de banda da rede (você está enviando apenas dados brutos, sem clichês de apresentação)
• mais fácil desenvolver GUIs do tipo desktop, já que você é menos dependente do paradigma de solicitação / resposta

Contras :

• você precisa escrever seu código de cliente em Javascript ou em um idioma que possa ser compilado em Javascript, porque essa é a única coisa disponível em um navegador
• o uso de recursos no cliente pode ser maior, portanto, o aplicativo pode não funcionar bem em dispositivos abaixo do padrão (pense em navegadores móveis etc.)
• não funcionará com o javascript desativado; se for um site voltado para o público, você deve pensar bastante se está disposto a correr esse risco (especialmente se considerar SEO e acessibilidade - uma abordagem com javascript pesado geralmente é devastadora nessas duas frentes)
• muita lógica deve ser escrita duas vezes: uma vez no cliente e outra vez no servidor (porque você nunca pode confiar no cliente)
• a simultaneidade pode ser um inferno, então você precisa projetar seu código do lado do cliente com muito cuidado e estar preparado para todos os tipos de problemas de simultaneidade

É definitivamente possível e provavelmente encorajável como melhor prática. O que você está propondo é separar a interface do usuário da lógica comercial, para que haja uma separação clara das preocupações. Isto é muito bom.

Muitas vezes, as estruturas que tentamos confundir as coisas e você acaba com um software monolítico em que a interface do usuário, a lógica de negócios e os dados estão todos interligados. Isso dificulta a manutenção e a modificação.

Depois de dividir o aplicativo em duas partes, você poderá substituir completamente a interface do usuário por outra coisa - um programa de desktop ou outra interface de usuário para celular em comparação com os navegadores de desktop.

Os trechos complicados que você encontrará ao fazer isso é que um pouco de código que teoricamente deveria estar no servidor seria melhor colocado no cliente - a validação, por exemplo, é mais rápida e responsiva para o usuário colocar o código de validação em um servidor. formulário no cliente do que atingir o servidor para verificar, por exemplo, um campo de texto que contém apenas caracteres alfanuméricos. O mesmo se aplica às camadas de dados e negócios. Você apenas precisa tomar decisões práticas e informadas sobre quando violar a distinção entre as camadas.

Uma desvantagem é a necessidade de duplicar parte da lógica em JavaScript e ASP.net. Isso pode não ser um grande problema para você, dependendo do seu aplicativo. Isso geralmente ocorre porque você não precisa pedir ao servidor para verificar todas as pequenas coisas ("O usuário pode pressionar esse botão ou selecionar esta opção nesta situação?"), Mas também não deseja depender no cliente como o único a validar, pois o usuário tem controle sobre o cliente.

Se você ainda estiver usando o ASP.NET WebForms e quiser acelerar seus aplicativos, eis o que você deve fazer:

• Projete seu aplicativo com o SOLID em mente
• Desativar ViewStateem todas as páginas e controles de usuário

• Não use controles do lado do servidor

  <%: VeiwModel.Title%> em vez de <asp: literal id = "Title" runat = "server">

• No back-end, substitua o método OnInit e faça toda a inicialização lá:

  substituição protegida void OnInit (System.EventArgs e) {CreateViewModel (); base.OnInit (e); }

• Compacte todos os arquivos .css e .js em 1 usando o SquishIt

• Imagens de carregamento lento
• Armazenar objetos complexos em cache

Por fim, acesse www.porsche.se. Não é um site muito rápido?