Corra para o lado do cliente no desenvolvimento web


10

Nos últimos meses, reconheci uma grande empolgação com os scripts do lado do cliente no desenvolvimento da Web. Porém, embora as tecnologias do lado do servidor sejam maduras, estáveis ​​e bem aceitas pelos desenvolvedores de back-end, as tecnologias do lado do cliente são imaturas (isto é, comparadas à grande estrutura do lado do servidor) e não são apreciadas por muitos desenvolvedores de longa data. No entanto, todos estão desenvolvendo o lado do cliente atualmente. Pessoalmente, espero que essas grandes estruturas do lado do servidor desapareçam em 2 a 5 anos, observando a tendência atual.

Por que? Como o desenvolvimento novo e "difuso" do lado do cliente em HTML5 / JS pode ser superior às soluções grandes e bem pensadas do lado do servidor?


4
Você tem alguma fonte para verificar suas suposições? O Javascript é quase tão antigo quanto a própria Internet, e não vejo a programação do servidor indo a lugar algum tão cedo.
tdammers

11
Para esclarecer, minhas suposições são limitadas ao front-end. Eu vejo uma mudança para o lado do cliente, na lógica da interface do usuário, renderização e coisas assim. É claro que o lado do servidor nunca desaparecerá, mas será reduzido a uma API REST (ou SOAP).
Bruno Schäpper

3
Essa mudança vem e vai. Normalmente, o desenvolvimento de front-end fica mais popular quando novas tecnologias interessantes são introduzidas (Shockwave, Flash, JavaFX, Flex) ou grandes novas estruturas js estão tentando "dominar o mundo" (motools, jquery etc.)
Andrzej Bobak

11
@VainFellowman: Você realmente não deseja usar o SOAP no script do lado do cliente. Há muita sobrecarga, analisá-la é uma dor e você não ganha muito porque o Javascript com sua disciplina de digitação dinâmica não será capaz de fazer muito uso das informações de tipo do SOAP de qualquer maneira.
tdammers

11
@ Tdammers eu não quero, realmente não quero. Não vejo sentido em usar SOAP sobre HTTP. O REST é adequado para quase tudo.
Bruno Schäpper

Respostas:


7

Isso é verdade:

Corra para o lado do cliente no desenvolvimento web

Mas não está confinado ao lado do cliente, é um movimento de pilha cheia.

Eu sei que isso pode ser surpreendente. Por favor, me ouça.

Por que? Como o desenvolvimento novo e "difuso" do lado do cliente em HTML5 / JS pode ser superior às soluções grandes e bem pensadas do lado do servidor?

Primeiro de tudo, ambos são bem pensados.

Em segundo lugar, porque é melhor.

Boa pergunta.

Mas "melhor" é subjetivo, então a resposta para sua pergunta é: o que especificamente é melhor?

Re-visite a pergunta:

Como o desenvolvimento "difuso" do lado do cliente em HTML5 / JS pode ser superior às grandes soluções do lado do servidor?

Because small is nimble.
And big is clunky.

É flexibilidade.

Não parece grande coisa. Faz isso? Flexibilidade.

No entanto, a flexibilidade está subjacente a tudo. Uma melhoria na flexibilidade - melhora tudo.

Manutenção. Extensibilidade. Escalabilidade. Modularidade. Usabilidade. UX.

E é mais rápido de implementar. Essa é a realidade. Mais rápido e melhor.

This is why Windows 8 made JS a first-class citizen.

HTML5 - JS, não é uma moda passageira e não desaparece. Estamos vendo apenas as sementes de uma tecnologia que crescerá para fornecer conteúdo de computação e comportamento de interação aos tablets. Comprimidos.

Os telefones inteligentes foram a adoção mais rápida da mídia de massa desde a TV nos anos 50. Agora, não apenas temos smartphones - temos tablets.

Já em desenvolvimento na Mozilla e no Windows, o sistema operacional será executado em dispositivos futuros em seus mercados -> HTML / JS.

Muitas soluções e inovações permanecem.

Uma pilha completa de JS está surgindo, com base na flexibilidade.

Espero que ajude.


11
Ótima resposta! Mas as estruturas do lado do servidor prometem os mesmos benefícios, não é?
Bruno Schäpper

11
Sim senhor, estruturas do lado do servidor prometem os mesmos benefícios, sim. O que precisa ser conhecido é que existem benefícios adicionais, encontrados inesperadamente, em tecnologias emergentes. Está no nível mais baixo (c) no io. Os threads esperam. Em JS, ele tem um retorno de chamada. Isso não espera. Portanto, há uma otimização io no nível mais baixo. Essa percepção agora é silenciosamente adotada em grande parte pela Microsoft. É por isso que o SO deles é JS. Ponto final, isso gera otimização e meta otimizações - em todos os níveis. Porque a linguagem é flexível. Uma coisa simples e invisível. Não conhecido. Espero que ajude.
22612 Jack Stone

11
Eu escolhi aceitar essa resposta, porque é a mais completa. Todos os outros têm bons pontos, mas este é o mais conclusivo. Obrigado a todos!
Bruno Schäpper

9

Essa história sempre teve dois lados; o código do lado do servidor e do cliente tem seus prós e contras.

As vantagens do script do lado do cliente incluem:

  • Pode ser feita de maneira mais responsiva, são possíveis alterações extensas sem ida e volta do servidor.
  • O código é executado no cliente, reduzindo o uso de recursos no servidor.
  • A separação entre lógica e apresentação se torna física.
  • Às vezes, é mais fácil balancear a carga, especialmente se a autenticação por solicitação for usada.

Mas o script do servidor também tem muitas vantagens:

  • Você controla a máquina na qual o código é executado.
  • Praticamente tudo é possível - se o seu servidor pode fazê-lo, o mesmo acontece com o seu script.
  • Os usuários não podem modificar seu script antes de executá-lo.
  • Os usuários não podem usar bloqueadores de scripts para impedir a execução do seu script.
  • Os usuários não podem ver o que seu script faz, eles podem apenas observar a saída.
  • O código funcionará de maneira confiável com todos os clientes que você possa imaginar, incluindo leitores de tela, navegadores de texto, aranhas de mecanismos de pesquisa, raspadores, acumuladores, robôs IRC, máquinas de última geração, navegadores bloqueados por script, etc.
  • Os plugins de usuário têm menos probabilidade de quebrar.

Para aplicativos da Web altamente dinâmicos, a abordagem centrada no cliente sempre foi uma escolha popular, porque é a única maneira de fornecer uma experiência de usuário decente, semelhante a uma área de trabalho: sem scripts no lado do cliente, cada uma das ações do usuário exige um processo redondo. viagem, o que significa um atraso de pelo menos meio segundo, geralmente mais. Mas para um site informativo que é basicamente apenas um monte de páginas estáticas veiculadas em um banco de dados (por exemplo, wikipedia), a vantagem é marginal, enquanto os benefícios dos scripts no servidor ainda são impressionantes.

O hype observado vem de uma combinação de dois desenvolvimentos recentes:

  1. HTML5 e sua coroa de tecnologias relacionadas. Demorou muito tempo, mas agora finalmente temos um padrão que contém tudo o que você precisa para criar aplicativos da Web dinâmicos semelhantes a desktops sem acumular hacks e navegadores principais que os implementam corretamente.
  2. Poder de processamento disponível. Os PCs de mesa de hoje são tão poderosos quanto um servidor Web básico, os celulares de nível de cliente são praticamente os desktops de 2005 e as implementações modernas de javascript são eficientes o suficiente para inclinar o equilíbrio de desempenho: agora, os recursos do cliente são mais baratos que o servidor Recursos.

De fato, nada mudou em termos das abordagens centradas no servidor e centradas no cliente; o que mudou é que o foco no cliente agora é mais fácil e barato de executar e tem um desempenho melhor do que alguns anos atrás, tornando-o uma opção viável para muito mais aplicativos do que costumava ser.


verdades difíceis ... +1.
Jack Stone

8

O lado do servidor estará sempre por perto. Você não pode se sentar do lado do cliente por tudo. Por exemplo, você não deseja usar um design MVC do Backbone.js para o seu microcontrolador, enviando parâmetros em tempo real a partir de um guindaste aéreo de produção.

Não acredite no hype.


Conte-me. JS é no Windows 8, hype? -1. Concordo com o primeiro ponto, mas seu segundo ponto no hype precisa de esclarecimentos.
Jack Stone

JS não é exclusivo para o cliente e não existe há algum tempo.
Erik Reppen

@ClintNash ya, na verdade. Ms permitiu que o js criasse aplicativos win8 para aumentar o número potencial de desenvolvedores de sua plataforma. É uma resposta para as pessoas que optam por aprender essas tecnologias sobre as tecnologias de desktop. Mas como uma rev que já conhece c # / wpf, não vejo razão para criar um aplicativo win8 com html / js.
Andy

@ ErrikReppen, isso é verdade, mas o js sozinho não o interrompe no servidor, você precisa de uma estrutura para incorporar. Francamente, o desejo de usar scripts no servidor me deixa desconcertado. Já fizemos isso, era clássico ASP, e eu realmente não desejo repetir essa experiência.
Andy

@ Andy No ASP clássico (formulários da Web em particular), você não encontrará um acordo final com qualquer desenvolvedor JS que teve o infortúnio de se deparar com essas ferramentas que definitivamente não queremos voltar lá novamente. Mas essa é a ferramenta de script do lado do servidor menos lembrada com carinho da yesterdecade e provavelmente a solução de cliente thin mais desprezada com mais veemência que já viu qualquer nível de popularidade. Comparar isso a algo como Python e agora o JS no lado do servidor está próximo de dizer às pessoas para pegar um cavalo.
precisa saber é o seguinte

6

Em 2009, mudei de uma estrutura PHP do lado do servidor para uma solução ExtJS do lado do cliente vinculada a serviços Web do lado do servidor.

Os motivos da migração para mim foram:

  1. Melhor segurança, reduzindo a quantidade de terminais e código no servidor.
    Ao passar para os serviços da Web, você valida a entrada no limite do serviço da Web e tem um controle mais exato sobre a E / S do servidor. Não há camada de interface do usuário no servidor para alterar sua arquitetura de segurança.
  2. Desempenho aprimorado por causa de menos ida e volta do servidor
    A arquitetura é alterada para que as buscas de dados ocorram com menos frequência e os dados possam ser armazenados em cache localmente com a renderização da interface do usuário, sem a necessidade de uma ida e volta. As viagens de ida e volta matam o desempenho de aplicativos da web.
  3. Desempenho aprimorado devido à capacidade de cache da interface do usuário
    A camada da interface do usuário pode ser hospedada completamente em uma CDN. Até construí aplicativos da Web offline, colocando o código da interface do usuário no cache do aplicativo HTML5.
  4. Maior fidelidade da interface do usuário (controles avançados do lado do cliente)
  5. Os desenvolvedores de terceiros podem usar a mesma API que meu próprio front-end está usando, e eu posso reutilizar facilmente as APIs entre os módulos se eles compartilharem recursos.
    Isso significa menos desenvolvimento, controle de qualidade, documentação, ...
  6. Eu gosto de programar em JavaScript melhor que PHP, Python ou Java

Mas, não se engane, o que está acontecendo agora é um hype. Ele explodirá e muitos aplicativos da Web usarão uma arquitetura de interface do usuário do servidor novamente.


O que, hype? -1 Boa sorte quando o Windows 8 faz do JS um cidadão de primeira classe. Sim, talvez a arquitetura da interface do usuário do servidor escrita em node.js. Precisamos aprender porque é sem bloqueio.
Jack Stone

Acho que não voltaremos às soluções de clientes grossos tão cedo. Mas, se eu me deparasse com o ExtJS por qualquer problema que fosse mais complicado do que criar uma interface de usuário da Web pré-fabricada (ou seja, todos os problemas, independentemente do plano original), eu poderia ver por que a alternativa pode parecer menos do que ideal.
Erik Reppen

6

Outro fator que está motivando o entusiasmo por soluções do lado do cliente é o crescimento de aplicativos móveis. Se você criar um site com base em JavaScript e AJAX do lado do cliente, e também criar aplicativos iOS e Android nativos, há uma boa chance de que todos os três possam usar os mesmos serviços REST para executar todos os seus dados. .


Bem dito ... +1.
Jack Stone

Muito bom ponto de fato.
Bruno Schäpper

4

Primeiro de tudo, o usuário não vê (e às vezes nem se importa) com o que não é o servidor. Não importa o quão bem o código do servidor seja escrito, os usuários não apreciarão o aplicativo se a parte do cliente não for bem-sucedida. Às vezes, até a interface do usuário agradável é mais importante que a funcionalidade.

Um servidor de hospedagem grande e poderoso é bastante caro. É muito mais barato implementar parte da lógica (exceto a validação) no lado do cliente. Portanto, você pode usar um servidor menor (portanto, mais barato) de hospedagem, uma vez que não seria carregado tanto.

É por isso que, apesar da instabilidade, as tecnologias do lado do cliente estão ganhando mais popularidade. Além disso, JS e HTML / CSS são suportados por (quase) todos os navegadores modernos.

Essas duas partes de aplicativos não podem existir separadamente. E a Internet não parece estar saindo de lugar algum no futuro próximo.
Eu também não acho que isso big server-side frameworksdesapareça. Sempre haverá empresas que podem pagar por elas e usarão suas vantagens significativas.


4

O desenvolvimento da Web do lado do cliente está fortemente associado aos navegadores da Web e alterações neles ao longo do tempo. A solução que você fornece agora pode não funcionar em alguns meses devido a alterações significativas nos mecanismos de renderização de página dos navegadores da web. Alguns navegadores são / eram incompatíveis com os padrões e, portanto, exigiam ainda mais esforço extra dos desenvolvedores apenas para alcançar o resultado esperado.

Existem algumas soluções tentando corrigir esse problema. Por exemplo, se você usa o jquery, pode ter certeza de que seu script funcionará nos navegadores suportados por essa biblioteca jquery específica. Mas depende apenas de seus autores fornecer compatibilidade com alguns / a maioria / todos os navegadores. A questão é qual equipe o apoiará melhor. Será time de motools, time de jquery, outro time? Se eles não fornecerem suporte para um navegador da web específico, seu projeto poderá não funcionar nesse navegador.

A emoção que você parece já existe há muito tempo. Eu o vi quando o Shockwave e seu sucessor Flash foram introduzidos, houve um "grande retorno" de interfaces de usuário avançadas depois que as bibliotecas js complexas foram enviadas, primeiro com motools e depois com jquery (comecei a usá-las nessa ordem). Havia Flex e JavaFX. Mas nenhum deles pode ter uma grande participação no mercado. Alguns exigem plug-ins que, com o tempo, costumam expor o usuário final a vulnerabilidades de segurança, outros podem não funcionar no lado do cliente devido a algumas configurações personalizadas (por exemplo, JavaScript desativado no navegador do cliente).

Por outro lado, a solução do servidor geralmente é escrita apenas uma vez. Você não precisa se preocupar que tudo irá falhar e terá que ser reescrito assim que o novo Firefox / Chrome / IE / Opera for lançado. Você também não precisa se preocupar com o fato de o cliente tentar adulterar seu aplicativo e / ou corromper os dados.


11
Isso não é pura imaginação? Você possivelmente terá que alterar as coisas do lado do servidor quando os clientes mudarem, pois você não poderá gerar HTML / JS / CSS em algum momento.
Bruno Schäpper

11
Mais uma coisa: 'O desenvolvimento da Web do lado do cliente está fortemente associado aos navegadores da Web' - as tecnologias da Web são padrões oficiais, desde que você se atenha a isso e esteja implementando um padrão, não acoplando seu aplicativo a um navegador. Embora não muito tempo atrás isso não fosse verdade, parece ser o momento.
Bruno Schäpper

Antes de tudo, leia como alguns navegadores simplesmente não seguem os padrões (Internet Explorer, por exemplo). Algumas coisas mudaram com o tempo, mas mesmo com o IE7, tive problemas horríveis devido à sua própria maneira de interpretar o que escrevi. Leia também alguns artigos sobre compatibilidade entre navegadores. Esse problema não existiria se todos os fornecedores de navegadores seguissem os padrões. Em segundo lugar, se o conjunto de dados for alterado, você precisará alterar sua lógica de negócios, isso é óbvio. Mas quando o novo IE é enviado e é necessário reescrever cerca de 30% do código apenas para fazer com que o código funcione no novo navegador - algo está errado
Andrzej Bobak

É claro que sei como é doloroso e foi fazer tudo funcionar em todos os navegadores. Mas esse trabalho precisa ser feito independentemente do servidor ou do lado do cliente (pois você precisa usar um navegador no final). Eu certamente concordo com o seu segundo ponto. No entanto, não vejo 30% a serem reescritos. Possivelmente algumas alterações são necessárias, mas duvido que seja tão ruim quanto nos velhos tempos. Por outro lado, você precisa refazer tudo com base na camada de serviço, se desejar substituir sua pilha do lado do servidor. Então você está MUITO fortemente acoplado à sua implementação no lado do servidor. Possivelmente do topo da interface do usuário ao modelo.
Bruno Schäpper

-1

Concordo absolutamente com seus sentimentos. Eu também acredito que, além do que você está dizendo, veremos uma queda dramática no REST e um aumento maciço nos websockets pela principal maneira como vemos os sites se comunicarem com seus servidores. Vert.x, Node.js etc .. todo o lado do servidor, bem como o lado do cliente, está passando para a programação orientada a eventos. Java EE, PHP, Rails, etc. todos eles precisam se adaptar ou perderão muito rapidamente.


Sem uma explicação, essa resposta pode se tornar inútil se outra pessoa postar uma opinião diferente. Por exemplo, se alguém postar uma declaração como "não veremos uma queda dramática no REST e um aumento maciço nos websockets", como essa resposta ajudaria o leitor a escolher essas opiniões diferentes? Considere editar ing-lo em uma melhor forma
mosquito
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.