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?
fonte
Respostas:
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.
fonte
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?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.fonte
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.
fonte
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.
fonte
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:
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.
fonte
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.
fonte