Os front ends do site devem ser renderizados no lado do cliente ou no lado do servidor?

5

Eu tenho conversado com um colega que vem de AS3 para o HTML world. Ele criou um pequeno site (aparentemente não há conteúdo dinâmico) seguindo as regras do não flash pela primeira vez, e como se você tivesse um martelo, você tende a martelar tudo, ele decidiu criar um framework em JavaScript , então ele poderia fazer todo o " AS3 way", com frames, animação de coordenadas XY puras e assim, animar o conteúdo. A página seria totalmente carregada no início, carregar a grande quantidade de JS no início e, em seguida, a página seria acessível sem alterar o URL.

As exibições se transformariam em métodos de classe (em que a classe representa uma seção e o método representa uma exibição), que acrescenta texto a uma variável que é então adicionada a uma div. Ele defende essa situação com muitas razões:

  • Sites com uma grande quantidade de usuários fazem isso para evitar sobrecarga do servidor.
  • É mais fácil criar novas seções.
  • É mais fácil traduzir, como traduções, textos e quase tudo é carregado de um JSON .
  • Você pode expandir mais seções diretamente de um arquivo JSON .
  • Tudo está tranquilo, pois você não muda para outra página.

Agora, vem o desenvolvedor leal do PHP, que defende o lado oposto. Digo que as visualizações devem ser divididas em arquivos menores, mas contidos em arquivos .php ou mesmo .html , com a lógica de negócios em um controlador e a lógica de exibição nesses arquivos. Isso libera o cliente, já que ele pode desabilitar JavaScript e ainda mostrar o conteúdo sem problema. É claro que seu servidor precisa fazer cálculos, mas é apenas renderizar arquivos. Alguns benefícios podem ser:

  • Você não precisa carregar o site inteiro primeiro. Páginas da Web carregadas mais rapidamente.
  • Seus URLs estão sempre limpos e (no caso de você ser) amigáveis, sem plug-ins e funcionando perfeitamente em navegadores antigos, à medida que você passa para outra página.
  • As visualizações são mantidas em arquivos independentes, por isso é mais fácil trabalhar com elas em uma equipe.
  • As exibições são regulares em html arquivos, em vez de chamadas para métodos anexando cadeias, portanto, editá-las é natural.
  • Você ainda precisa de PHP (ou qualquer outro idioma) para carregar dados de um servidor (NodeJS não considerado aqui)

E, claro, aqui vem a verdadeira questão. As visualizações devem ser renderizadas no cliente ou no servidor?

    
por Korcholis 16.04.2013 / 19:16
fonte

1 resposta

4

RobertHarvey está totalmente certo : depende. Pode ser uma boa solução, mas também é uma solução terrível para alguns projetos.

Em sua pergunta, você afirma:

He has created a small website (there are apparently no dynamic contents)

Com base nisso, ele escolheu a solução errada. Agora você também nota que existem animações. Então, talvez, se forem excepcionais, pode ser uma boa solução. Vamos afirmar que essas animações também podem ser feitas com soluções normais.

Se é bom ou certo é então simples: se funcionar como um site normal, então com uma boa classificação nos motores de busca, a boa acessibilidade e todos os outros web-developers padrão cuidam disso é simplesmente errado. Você constrói um site com um objetivo. Se for assim: pessoas normais o visitam para se inscrever / comprar / ver, etc. ele não atingirá esse objetivo.

Seus argumentos:

Websites with a high amount of users do this to prevent server overloading.

Sim, mas esse é um site pequeno, certo? link

É mais fácil criar novas seções.

Likely he is unaware of other solutions. No problem, it's his first one. This is something where training / reading could do a lot.

It is easier to translate, as translations, texts and almost everything is loaded from a JSON.

O mesmo aqui, a localização é algo muito mais complexo do que apenas traduzir algumas partes do texto de qualquer maneira. A educação é aqui também a chave.

You can expand more sections directly from a JSON file.

Pode estar correto, parece simples de fazer. Se um usuário tiver que fazer isso, ficará mais difícil. Com um banco de dados, por exemplo, pode ser possível criar um formulário para isso.

Everything is smooth, as you don't move to another page.

Isso é verdade, mas não pode ser desfeito com outras soluções. Carregar partes do conteúdo com o ajax (com a alteração do histórico do navegador) pode resolver isso bem. link

Para levar isso a um nível mais amplo: é um absurdo criar um framework dedicado se for apenas um site simples. Use o básico ou um sistema existente para isso. Por outro lado, é uma boa experiência de aprendizado. Todos nós tentamos construir um CMS uma vez certo? ;) Seus argumentos não são strongs, se ele quiser trabalhar mais nesta área mais conhecimento seria aconselhável.

    
por 16.04.2013 / 19:47
fonte