durante os últimos dois anos, ouvi o termo aplicativos da Web isomórficos mencionados de forma positiva com cada vez mais frequência. Também durante este tempo, eu fiz alguns pensar-me sobre a técnica. Minha conclusão é que os aplicativos da Web isomórficos são algo que não agregaria valor para mim ou para as organizações típicas para as quais trabalho. Várias coisas me levaram a essa conclusão.
mas, antes de listar os motivos, deixe-me primeiro enfatizar que acho bibliotecas javascript isomórficas (ou seja, lodash.js) são incríveis. Além disso, acho que Componentes isomórficos isolados podem ser valiosos, por exemplo, um indicador de mercado de ações atualizado ao vivo.
as razões pelas quais não acredito que os aplicativos da Web isomórficos sejam valiosos para mim ou para as organizações para as quais trabalho são:
- O servidor web agora só podem ser escritos em javascript
- Isomórficas Web Apps pode nunca ser o Aprimoramento Progressivo para não-trivial de aplicações
- Bloqueio vs não-bloqueio de fluxo de dados
- Tempo de interação e Uncanny Valley
- dispositivos Móveis congelar durante a análise de javascript
- Os melhores desenvolvedores estão agora ocupadas não produzir valor
eu quero começar com uma definição de Isomórficas Web Apps. Um aplicativo da Web isomórfico é um aplicativo da web onde o código do aplicativo não tem conhecimento de onde é executado. Em vez disso, esse conhecimento é mantido no código de infraestrutura e permite que o aplicativo como um todo seja executado no lado do cliente e do servidor.
- o servidor web agora só pode ser escrito em javascript
- aplicativos da Web isomórficos nunca podem ser aprimoramentos progressivos para aplicativos não triviais
- bloqueio vs fluxo de dados sem bloqueio
- Tempo de interação e Uncanny Valley
- os dispositivos móveis congelam durante a análise de javascript
- seus melhores desenvolvedores agora estão ocupados não produzindo valor
- resumo
- agradecimentos
o servidor web agora só pode ser escrito em javascript
se o código do cliente e o código do servidor forem os mesmos (e o cliente hoje só pode interpretar javascript), estamos limitados a usar apenas javascript no servidor. Eu gosto de nó.js muito, mas acho que é melhor estar aberto a alternativas no futuro, na minha perspectiva.
aplicativos da Web isomórficos nunca podem ser aprimoramentos progressivos para aplicativos não triviais
o javascript do lado do cliente tem acesso a uma máquina de Estado na memória que permite um nível de interação refinado, com uma latência muito baixa (sub-milissegundos). O mesmo não é verdade para a máquina de estado HTTP, que é impulsionada por cliques de links e envios de formulários.
para mim, o aprimoramento progressivo é começar com uma linha de base acessível para todos os dispositivos/navegadores possíveis, do antigo ao atual ao futuro. Na prática, isso significa uma linha de base da renderização do lado do servidor. A etapa de Aprimoramento é uma decisão comercial sobre onde aprimorar o site / aplicativo para aumentar o valor. Em outras palavras, o aprimoramento é feito no código do aplicativo (específico) e *não* no código da infraestrutura (geral), exceto para técnicas de otimização como pjax ou turbolinks.
a maneira de os aplicativos da Web isomórficos obterem aprimoramento progressivo é usar essa máquina de Estado de memória fina e” traduzi-la ” para usar apenas links e formulários. Os únicos casos em que posso ver onde isso é possível é onde você não precisava de renderização completa do lado do cliente em primeiro lugar, mas poderia confiar nas técnicas de otimização mencionadas acima e nos componentes do lado do cliente para aprimorar a experiência (ou seja, um componente de calendário para um campo de entrada para uma data).
uma variante desta solução é não suportar cada Estado/transição do lado do cliente na máquina de Estado do lado do servidor. Nesse caso, essa deve ser uma decisão comercial que precisa ser refletida no código do aplicativo, tornando o ambiente do Código do aplicativo sensível, o que vai contra a ideia de aplicativos da Web isomórficos.
a maneira de os aplicativos da Web isomórficos obterem aprimoramento progressivo é usar essa máquina de Estado de memória fina e” traduzi-la ” para usar apenas links e formulários.
bloqueio vs fluxo de dados sem bloqueio
a sequência de renderização para web do lado do servidor e web do lado do cliente é diferente: os blocos do lado do servidor e o lado do cliente não bloqueiam.
Imagine que precisamos fazer duas solicitações a alguns serviços para renderizar uma visualização. Podemos fazer essas solicitações em paralelo.
no lado do servidor, se a segunda solicitação retornar primeiro, ela pode renderizar essa parte da resposta, mas precisa bloquear o envio desses bytes até que o primeiro tenha renderizado e retornado essa parte da resposta de volta ao navegador.
no lado do cliente, essa restrição não existe: as duas respostas podem ser tratadas e renderizadas de forma independente.
além disso, acho que o acima representa o mais simples dos exemplos. Imagine que você tem uma árvore de componentes, onde o componente raiz é inteligente (consulte componentes de apresentação e Contêiner Para uma explicação dos componentes inteligentes/burros), seguido por alguns níveis de componentes burros e, em seguida, pelo menos um componente de folha que é inteligente.
A infraestrutura precisa de uma maneira de garantir que o contexto do Smart leaf não se perca, para que percamos o controle da execução de bloqueio/não bloqueio, dependendo do modo servidor/cliente. Uma maneira de resolver esse problema pode ser fazer com que todo o programa seja executado em uma mônada livre, representando a execução como dados a serem interpretados posteriormente. Outra solução pode ser usar alguma forma de padrão de visitante e permitir que os componentes declarem quais dados eles precisam (semelhante ao Tutorial: Criando um aplicativo Redux isomórfico (com amor)). Este último é provavelmente mais fácil. Meu ponto é que o problema de diferentes modos de bloqueio é provavelmente muito mais complicado que se imagina inicialmente.
um design alternativo é ter uma regra que diz “apenas o componente raiz pode ser um componente inteligente”, semelhante a como você pode usar a Mônada IO em Haskell, mantendo as folhas puras e tendo apenas efeitos colaterais no nível superior. Acho que esse design é bom no lado do servidor, mas não no lado do cliente: um componente no lado do cliente deve ser capaz de carregar seus próprios dados em pelo menos alguns cenários, por exemplo, em relação aos componentes relacionados à mídia social. Ter uma regra que nunca permita esses cenários parece muito improdutivo.
Tempo de interação e Uncanny Valley
Com o Isomórficas Web Apps abordagem, haverá um período de tempo onde o usuário vê elementos gráficos na tela que aparece para ser interativo, mas não são. Em outras palavras, o tempo entre o momento em que o navegador tenha processado a resposta do servidor e, quando o javascript está baixado, analisado e executado. Isso é chamado de “Uncanny Valley “ou”Potemkin Village”.
Veja este tweet e as respostas para mais detalhes.
os dispositivos móveis congelam durante a análise de javascript
em um telefone celular “típico”, você obtém 1 ms UI thread stall por 1KB javascript, de acordo com este tweet. Malte Ubl é o líder tecnológico do projeto AMP, então suspeito que ele saiba do que está falando.
seus melhores desenvolvedores agora estão ocupados não produzindo valor
Isomorphic Web Apps é uma abordagem que exige um alto nível de habilidade de desenvolvimento. Em muitas áreas (pelo menos no mundo ocidental), é difícil encontrar e recrutar desenvolvedores altamente qualificados. Escolher desenvolver aplicativos da Web isomórficos aloca esses desenvolvedores para fazer algo que eu questiono produz qualquer valor comercial. Existem maneiras melhores de usar seu tempo.
resumo
aplicativos da Web isomórficos limita sua linguagem de servidor web / escolha de plataforma para ser apenas javascript. Tem a ambição de permitir um aprimoramento progressivo, mas não pode entregar. Ele introduz um alto nível de complexidade técnica devido às diferenças no fluxo de dados de bloqueio/não bloqueio. Ele introduz uma janela de tempo onde as coisas parecem ser interativas, mas não são (o Vale estranho). Uma grande quantidade de javascript também congela navegadores móveis, com a regra geral de que 1KB de javascript significa 1ms de thread de IU paralisado. E, uma vez que requer um design de software complicado, leva tempo e esforço valiosos de seus melhores desenvolvedores – há uma maneira melhor de fazer uso de seu tempo.
finalmente, quero enfatizar que suas experiências podem ser diferentes das minhas. Talvez haja cenários em que os aplicativos da Web isomórficos sejam bons. Mas eles não são uma boa solução para preencher todas as lacunas entre os benefícios da web do lado do servidor e os benefícios da web do lado do cliente, sem obter nenhuma das desvantagens de ambas as abordagens.
o que você acha? Você já pensou em “ir isomórfico”? Você tem alguma idéia sobre os desafios e custos? Como você lida com eles?
agradecimentos
obrigado a Oskar Wickström e per Ökvist por valiosas discussões sobre este tópico. Oskar também revisou este post-obrigado Oskar.
