Aprimoramento progressivo vs. aplicativos de página única

33

Acabei de voltar de uma conferência em Boston chamada An Event Apart .

Um tema muito popular entre os palestrantes foi a idéia de aprimoramento progressivo - o conteúdo de um site deve ser em HTML e o JavaScript deve ser usado apenas para aprimorar o comportamento.

Os argumentos que os palestrantes deram para aprimoramento progressivo foram muito convincentes. Além de ser um padrão sólido para oferecer suporte a navegadores e dispositivos mais antigos em uma rede com baixa largura de banda, o HTML falha muito mais facilmente do que o JavaScript (ou seja, a marcação que não é suportada é apenas ignorada, enquanto o navegador lança uma exceção ao executar o seu script - você está de mangueira).

Jeremy Keith deu uma conversa particularmente esclarecedora sobre isso.

Mas e os aplicativos Web de página única, como Backbone e Angular? Todo o design por trás dessas estruturas parece levar o desenvolvedor a mudar o conteúdo do HTML para algo como uma API JSON.

Não consigo combinar esses dois padrões de design: aprimoramento progressivo versus aplicativos da web de página única. Existem casos em que um é melhor que o outro? Ou elas nem são tecnologias antagônicas, e estou perdendo alguma coisa aqui com meu modelo mental?

— SeanPlusPlus
fonte

Eles têm dois casos de uso diferentes. Sim, há sobreposição quando o servidor está fazendo o trabalho pesado.

— precisa saber

5

Acho justo dizer que os requisitos do navegador para aplicativos de página única são mais rigorosos do que os requisitos para aplicativos da Web "comuns", por design.

— Robert Harvey

3

você deve pedir a Jeremy Keith para lhe dar um exemplo do mundo real, onde o aprimoramento progressivo realmente vale o incômodo de agradar de 1 a 10% do total de pessoas na Internet e perguntar os dados de outros 90% do usuário. Eles realmente se preocupam com o aprimoramento progressivo ou se estão felizes? se eles podem visitar o site com o IE 5.0 ou sem javascript

— kirie

1

Se o tipo de pessoa que desabilita o JS / images / etc não estiver no seu principal grupo demográfico, não há motivo comercial válido para buscar o Melhoramento Progressivo.

— Graham

1

O suporte a 'dispositivos em uma rede com baixa largura de banda' é, na verdade, argumento para o SPA, não contra isso! No SPA, você faz apenas um grande pedido, onde sem JS você o tem sempre!

— Dmitri Zaitsev

21

Parece-me que aplicativos de uma página desenham uma linha na areia do aprimoramento progressivo. Onde antes podemos tentar contornar o fato de que as implementações e os recursos variam entre navegadores há décadas, os SPAs assumem que há uma certa linha de base que podemos razoavelmente concordar que a maioria dos visitantes de um determinado site atenderá. Eu não acho que os dois estão em desacordo. Ainda é possível continuar aprimorando progressivamente após o início do SPA, como começar com uma <video>tag e depois colocar em camadas seu próprio player rico em recursos.

Existem visitantes com scripts desativados, mas eles sabem no que estão se metendo. Não vejo por que os desenvolvedores se inclinam para trás para esses visitantes, além da observação "Você precisa de scripts para este site". Se permitirmos isso, por que não atender também aos visitantes com CSS desativado? E as imagens desativadas? Essas são as principais tecnologias da web. Eles não devem esperar ter uma experiência na Web totalmente funcional ao escolher e escolher as peças.

Para garantir que eu não fuja sem uma analogia de carro, não devo esperar que meu carro funcione se decidir que não gosto de determinados recursos. Eu poderia dizer aos engenheiros civis: "Desliguei meus faróis; portanto, certifique-se de instalar as luzes da rua a cada 125 pés em todos os lugares que eu possa visitar". Sem faróis, meu carro funcionava a maior parte do tempo, mas em alguns lugares não poderei visitar.

— Collin Allen
fonte

3

I don't see why developers should bend over backwards for those visitors. Se o seu contrato especificar que você precisa fornecer uma versão acessível do seu site, pode ser mais difícil usar um SPA. E quanto ao SEO?

— Simon Bergot

7

@ Simon: Você também pode tornar um SPA acessível (consulte, por exemplo, stackoverflow.com/questions/15318661/… ). O mesmo vale para SEO (se SEO importa, o que dependerá do aplicativo).

— Sleske

2

Algumas de suas analogias são um pouco de palha. Desabilitar o Javascript tem um objetivo de segurança; seria difícil argumentar que a adição de faróis a uma assistência a torna menos segura.

— Robert Harvey

1

É verdade que desativar o script tem benefícios de segurança. Mas para a maioria dos visitantes, a segurança adicional oferecida por essa escolha não vale a pena. Sem scripts, o Facebook se recusa a trabalhar, o LinkedIn interrompe, o Pinterest interrompe, o Instagram carrega uma página em branco etc. Se os principais players o exigirem, seu SPA também pode.

— Collin Allen

Conhecendo apenas o FB e o LinkedIn, não há boas razões para esses sites ficarem sem o JS, exceto para aplacar os desenvolvedores que não querem se esforçar para criar um site que funcione de maneira aceitável (ou para coagir os usuários a aceitar práticas de navegação menos seguras que podem beneficiar seus resultados financeiros). Se eles eram aplicativos da Web completos, como o Plunker, você pode ter razão, mas a maioria dos "aplicativos da web" são apenas "aplicativos" no sentido de que são criados sobre algum tipo de estrutura. Em termos de uso, são apenas sites com mais sinos e assobios do que costumavam ter.

— Dissident Rage

6

O SPA é mais benéfico se você estiver criando um aplicativo que não se encaixa no modelo clássico de páginas de solicitação / resposta. Há uma tendência recente em que sites regulares são escritos como um SPA, mesmo quando se encaixam perfeitamente no ciclo de solicitação / resposta da web, IMHO o que estão fazendo são empreendimentos tolos. O que esses sites estão fazendo é reimplementar mal um navegador da Web com muito mais bugs e menos recursos.

A idéia de aprimoramento progressivo e SPA não é mutuamente exclusiva para esses aplicativos tolos de página única. Você simplesmente precisa do javascript para fazer alguma negociação de conteúdo (ou seja, cabeçalho Accept), para que eles recebam recursos JSON que o Javascript no SPA pode renderizar em si, em vez de páginas HTML pré-renderizadas. Os problemas com esse tipo de SPAs de site são óbvios; é necessário ter uma implementação duplicada da renderização do site no servidor e no cliente.

Para aplicativos da Web verdadeiros, ou seja, um que realmente precise ser um SPA, pois não se encaixa no padrão de solicitação / resposta padrão; o aprimoramento progressivo é muito mais difícil para aplicativos verdadeiros, porque eles realmente estão apenas usando um navegador como plataforma tecnológica para escrever um aplicativo de forma portável. A linguagem de script é uma parte essencial de um verdadeiro aplicativo da Web, não apenas um que pode ser opcionalmente parafusado para aprimoramentos. No entanto, algumas técnicas de aprimoramentos progressivos ainda podem funcionar (por exemplo, substituindo vídeo / áudio flash por <video>/ <audio>tag), mas os verdadeiros aplicativos da Web requerem javascript como linha de base.

— Lie Ryan
fonte

+1, mas nem sempre é fácil decidir se algo "realmente" exige um SPA. Por exemplo, aplicativos de negócios que são principalmente entrada de dados, com uma ampla variedade de complexidade nos formulários. Se a maioria dos formulários for simples, um SPA não é "verdadeiramente" necessário, portanto ainda há tensão entre o SPA e as soluções que não são do SPA.

— sinelaw

@sinelaw: a maioria dos aplicativos de negócios geralmente não deve ser um SPA. Existem algumas exceções, por exemplo, planilha, processamento de texto, mas essas são as mais estranhas. Indicadores de que você precisa do SPA: se precisar enviar dados do servidor para o cliente, não apenas para uma ou duas notificações, mas como elemento crucial do aplicativo, por exemplo, jogo, rastreamento de estoque, aplicativo de bate-papo; se seu aplicativo não tiver um conceito sensato de uma "Página" ou o conceito de "Página" tiver sido totalmente distorcido no aplicativo, por exemplo, aplicativos do Office. Os aplicativos de negócios que funcionam principalmente em formulários permanecem melhor como não-SPA.

— Lie Ryan

Aceita. Outro indicador para um SPA: se o desenvolvimento de um SPA é mais barato do que o desenvolvimento de um site "clássico". Os aplicativos de negócios que um público-alvo específico às vezes pode impor requisitos como "usar um navegador moderno", para que o aprimoramento progressivo traga pouco benefício.

— sinelaw

@sinelaw: Construir um SPA quase nunca é mais barato do que desenvolver sites de várias páginas; especialmente se você não estiver atendendo a navegadores antigos de qualquer maneira.

— Lie Ryan

Se sua equipe for formada por especialistas em SPA com pouco conhecimento em projetos centrados em servidor, será mais barato.

— sinelaw

2

Acredito que aplicativos de uma página e aprimoramento progressivo são quase antagonistas. Se o html for calculado no cliente a partir de dados recuperados de uma API json, dificilmente poderá ser degradado normalmente. No entanto, ele pode oferecer uma interface de usuário mais rica e agradável.

Você pode configurar um bot que rastreará seu aplicativo e salvará uma versão estática. Essa técnica pode ser usada para veicular HTML em navegadores sem javascript (usado por pessoas cegas ou por bots de mecanismo de pesquisa). Este é um investimento, por isso realmente se resume às suas necessidades.

Você está criando um aplicativo Web de gerenciamento de RH para uma empresa específica? Você não precisa de degradação graciosa, e um SPA pode ser mais simples de construir. A empresa pode impor o uso de um navegador específico, para que você tenha menos testes a fazer.

Você está criando um site público para uma associação com requisitos de acessibilidade e necessidades de visibilidade do mecanismo de pesquisa? Em seguida, considere criar o HTML no seu servidor. Ou criar um SPA com uma versão estática, dependendo do seu orçamento.

— Simon Bergot
fonte

1

Acho que depende de quão longe você deseja ir com o aprimoramento progressivo - é um paradigma de design, e não um conjunto de regras rígidas e rápidas.

Se você estiver usando uma estrutura de SPA, acho que permitir Javascript é um dado. No entanto, o Javascript que você escreve para aprimorar sua página deve ser inteligente o suficiente para lidar com qualquer HTML que a estrutura possa criar.

Você também pode se beneficiar de outras técnicas de PE, como aproveitar os recursos CSS mais recentes de uma versão recente do navegador ou a degradação do HTML5 para HTML4.

— philicomus
fonte

1

Parte do aprimoramento progressivo é que o conteúdo básico deve estar disponível sem javascript. Não sei como escrever um SPA sem javascript.

— Alan Shutko

@ AlanShutko Talvez com iframes. Várias páginas, mas tecnicamente o URL não está mudando ...;)

— Izkata

1

Sim, acho que estava pensando mais em termos de HTML 5 versus HTML 4, e coisas como CSS específico do navegador (por exemplo, convém usar um recurso implementado muito recentemente disponível apenas na versão mais recente do Chrome, mas que degrada para mais controle primitivo em navegadores mais antigos). Ficar sem javascript seria complicado em um SPA, mas isso é apenas uma parte do conceito de aprimoramento progressivo.

— Philicomus

O aprimoramento progressivo pode ser tão simples quanto usar o css3 quando estiver disponível para arredondar cantos. A idéia básica não tem nada a ver com JavaScript.

— Daniel Little

1

O aprimoramento progressivo e um aplicativo de página única podem coexistir. Os dois argumentos mais convincentes que ouvi sobre a criação de aplicativos dessa maneira são:

Tolerância a falhas em situações em que o arquivo HTML é baixado na íntegra, mas os scripts referenciados falham ao baixar completamente, graças à conectividade de rede que entra e sai (possível em redes móveis)
Potencial para melhorar o desempenho percebido no carregamento inicial da página (reduzindo o tempo de renderização inicial)

A renderização do lado do servidor (isso é para usuários, não apenas os motivos de SEO) e a redução da mostarda são duas técnicas que podem ajudar a criar Aplicativos de Página Única progressivamente aprimorados com modernas estruturas JS do lado do cliente.

Algumas estruturas JS do lado do cliente são mais fáceis de trabalhar com a renderização do lado do servidor do que outras ( cuidado, algumas soluções de renderização do lado do servidor e combinações de estrutura não produzem SPAs funcionais, pois a página renderizada do servidor é destinada apenas ao consumo do mecanismo de pesquisa, e não ao final -users ).

No momento da redação deste artigo, React.js e Ember (com o próximo FastBoot) são os dois que eu conheço que têm ou estão tentando tornar a renderização do lado do servidor um cidadão de primeira classe; a página renderizada no servidor ainda é um SPA em funcionamento quando analisada no navegador do cliente.

— Eliot Sykes
fonte

0

Sou da opinião de que o carregamento reduzido de páginas provavelmente é bastante bom para servidores e para a rede. Eu adoraria ver mais SPAs usados corretamente.

Estou fora de vista, porém, que isso requer duas coisas:

1) configurando todos os seus links como links padrão de solicitação / resposta no carregamento inicial, deixe a estrutura / biblioteca do SPA substituí-los por uma versão atualizada (interativa) assim que o navegador carregar e o mecanismo JS identificar que o suporte do SPA está disponível. Isso realmente é aprimoramento progressivo; o JS é carregado no topo do site html existente, e isso é melhor para mecanismos de pesquisa, tecnologias assistivas e navegadores mais antigos.

e

2) O servidor precisa ser responsivo a rotas como / foo / bar / json e foo / bar, servindo no formato correto; realisticamente, se você estiver agrupando tudo em layouts e parciais para obter a primeira página, poderá conseguir tudo por meio de layouts e parciais para a segunda e as páginas subsequentes.

Há bastante trabalho aqui; é certo, mas se você tem controle sobre a pilha completa, ele equilibra as duas tecnologias.

— Crispen Smith
fonte