Quando o JavaScript deve gerar HTML?

Eu tento gerar o mínimo de HTML possível do JavaScript. Em vez disso, prefiro manipular a marcação existente sempre que posso e apenas gerar HTML quando precisar inserir dinamicamente um elemento que não seja um bom candidato ao uso do Ajax. Acredito que isso facilite muito a manutenção do código e faça alterações rapidamente, pois a marcação é mais fácil de ler e rastrear. Minha regra geral é: HTML é para estrutura de documentos, CSS é para apresentação, JavaScript é para comportamento.

No entanto, eu já vi muitos códigos JS que geram montes de HTML, incluindo formulários inteiros e diálogos modais com muito conteúdo. Em geral, qual método é considerado a melhor prática? Em que circunstâncias o JavaScript deve ser usado para gerar HTML e quando não?

Sempre que encontrei forte geração de HTML em javascript, era quase exclusivamente em um plug-in de interface do usuário independente. Faz sentido, pois permite encapsular todo o plug-in em um único arquivo .js (+ a .css para personalizar estilos), tornando-o facilmente reutilizável, distribuível e independente da estrutura usada no aplicativo.

Portanto, se você estiver escrevendo um plug-in javascript autônomo ou um componente genérico da interface do usuário que gostaria de usar em diferentes aplicativos, essa abordagem terá suas vantagens. Caso contrário, acho que é mais limpo, mais fácil de escrever e mais fácil de manter quando você mantém a geração html longe do javascript e do lado do servidor.

Acho que o problema é que você está comparando modelos do lado do servidor escritos de maneira limpa com a geração de HTML ad-hoc do lado do cliente mal escrita. Obviamente, o código escrito corretamente é mais fácil de ler, manter e rastrear.

Você chama o código do lado do cliente "montes de HTML", mas é claro que é o mesmo HTML onde quer que seja gerado. O "monte" é realmente o grande pedaço de código.

Existem muitas bibliotecas de modelos do lado do cliente por aí. Eles funcionam de forma semelhante aos do lado do servidor. Como você prefere, a troca de desempenho é complicada, mas o JSON geralmente é mais compacto que o HTML e o modelo no cliente pode eliminar algumas chamadas do servidor. Por outro lado, o cliente pode ter o JS desativado ou ser muito lento para ser prático, portanto depende do seu público-alvo também. No geral, acho que as abordagens são bastante comparáveis, com o maior fator sendo os recursos de navegador do seu público-alvo.

Mas isso depende exatamente do que você está fazendo, se você prefere JS ao seu ambiente de servidor, qual solução de modelo você prefere etc.

Há uma tendência para usar modelos do lado do cliente, em casos extremos, você teria o servidor fornecendo apenas API RESTful, por exemplo, no formato JSON, enquanto fazia toda a renderização do lado do cliente. A vantagem dessa abordagem é que o código e os modelos JS são recursos estáticos que podem ser armazenados em cache, em proxy e distribuídos via CDN. O que não pode ser feito se você tiver HTML dinâmico gerado pelo servidor. Além disso, retornar apenas dados da API RESTful em formato leve utiliza muito menos recursos do servidor, tornando a resposta mais rápida. Por ser mais leve, é menos transferência de rede, o que torna mais rápido. Dessa forma, você pode ter um aplicativo de baixa latência muito responsivo, mesmo em conexões lentas, como 3G. Portanto, essa abordagem é popular para páginas e aplicativos para celular.

Existem inúmeras bibliotecas execução modelos JS, um dos mais populares são Pure , bigode e dust.js . Mais tarde, usado pelo LinkedIn, eles descreveram as vantagens em seu artigo "Deixando JSPs no pó: movendo o LinkedIn para dust.js modelos do lado do cliente" .

A vantagem de gerar HTML no cliente é transferir o trabalho de renderização para cada cliente, que geralmente fica ocioso aguardando a resposta. Liberando mais recursos do servidor para fornecer apenas dados JSON e conteúdo estático (HTML, JS e CSS).

Fazemos um aplicativo da web que gera exclusivamente HTML com Javascript. 87% das ocorrências no servidor são dados JSON, o conteúdo estático geralmente é carregado uma vez e depois no cache do navegador.

Mas você não pode usá-lo - pelo menos não facilmente - se precisar de SEO. Ou se você segmentar uma população com o Javascript desativado, mas não tenho certeza de que essa ainda seja relevante no Youtube, Twitter, Facebook, Gmail, ... forçando naturalmente as pessoas a ativá-lo.

Em relação ao carregamento dinâmico de páginas, deve-se perceber que, por trás de todo o "JQuery AJAX Cloud!" mágica, apenas duas coisas possíveis estão acontecendo:

1. O código de um elemento está sendo injetado em uma div (ruim) ou
2. O conteúdo está sendo carregado em um iframe (melhor, mas não é o mesmo ...)

Em relação à pergunta original, só crio conteúdo HTML via Javascript quando estou criando um aplicativo da Web de algum tipo que lê dados XML ou JSON armazenados no servidor e isso é alterado muito.

Não faria muito sentido carregar conteúdo estático em uma página com Javascript, pois sempre há a possibilidade de que ele não seja carregado corretamente ou o cliente o desativará ("pegue esses anúncios irritantes!"). Além disso, torna muito difícil alterar o conteúdo HTML quando ele é esmagado em um feio document.write()ou em uma cadeia de caracteres document.createElement().

Então, você está certo; digite o HTML bruto ou, se for necessário conteúdo dinâmico, use um script do lado do servidor para gerar o que é necessário. Use Javascript para injetar HTML somente se o site tiver a intenção de funcionar sem uma conexão com a Internet ou um caso semelhante.

Uma última observação: se você deseja implementar xmlhttprequests, er, AJAX, em um site, provavelmente a melhor / mais segura maneira de fazer isso é armazenar os dados em um formato de dados (como XML), carregá-los e enviá-los de acordo. no cliente. document.writee element.innerHTMLrealmente não é a melhor maneira de manipular o conteúdo e provavelmente causará dores de cabeça em potencial no futuro (por que esse script não está sendo executado? Minha <i>tag quebrada está em itálico tudo! etc.).

Meu mantra é: quando é mais fácil e ninguém se importa com a marcação.

Você também pode aproveitar os dois e definir um limite em que é muito difícil se preocupar com a marcação e preferir se concentrar na árvore DOM. Por exemplo, um formulário com linhas dinâmicas (por exemplo, "adicionar outro anexo"), você provavelmente desejaria o formulário em HTML, o botão "adicionar linha" e o botão enviar ... provavelmente não deseja gerar o HTML com a linguagem do servidor ou algo assim.

Outra regra prática pode ser a reutilização. Se sua solução puder ser aplicada a outros problemas no lado do cliente, encapsule-a em js.

Criamos aplicativos de página única (ala Google Mail) e, literalmente, não há geração de HTML no servidor em nossos aplicativos. Em vez disso, estamos usando o Backbone.js para estruturar o lado do cliente e o Handlebars para renderizar nosso JSON em modelos que vão para a página. Na verdade, funciona muito bem e estamos chegando ao fim do nosso primeiro aplicativo que o usa e enfrentaremos um projeto ainda maior no futuro.

Qualquer tipo de cliente gordo em que o servidor é usado apenas para persistir dados e retornar resultados da consulta é um filho-pôster durante um período em que você deseja que o JavaScript gere HTML. Apenas certifique-se de usar um bom mecanismo de modelo para torná-lo limpo e fácil.

Estou gerando código html no jquery porque estou usando um portlet e, após a execução do código jsp, preciso fazer um loop com código html, que não consiga entrar no loop java for com algum código javascript. Então, eu estou processando java arraylist em uma matriz javascript e usando as seqüências de caracteres para gerar html.