Melhoria progressiva para JavaScript?

Question

A maioria das pessoas fala sobre aprimoramento progressivo agora como servir navegadores com JavaScript (versão aprimorada) e navegadores sem JavaScript (versão simples).

Mas há uma diferença tão grande no desempenho do JavaScript entre os navegadores que pode ser útil aplicar esse termo para suportar a escolha entre os recursos baseados em JavaScript entre os navegadores.

Em um aplicativo da Web complexo com inúmeros recursos (e animações) não-absolutamente essenciais, vale a pena começar a pensar em que os contratos, por exemplo, esses conjuntos de recursos devem funcionar em todos os navegadores, e esses conjuntos de recursos apenas no Chrome e Safari , e estes em Firefox, Chrome, Safari e Opera, e assim por diante, porque permitir certos recursos em certos navegadores seria muito lento.

Às vezes, sinto que a experiência do usuário melhoraria se eles não tivessem acesso a certos recursos não essenciais. Por exemplo, proibir os usuários do IE de redimensionar determinados painéis que os usuários do Chrome poderiam redimensionar.

Answer 1

Isso soa como um pesadelo de manutenção.

Sei que existem alguns aplicativos da Web em que simplesmente não faz sentido ter uma versão HTML. Dito isto, se for possível, eu começaria construindo uma versão HTML de todas as páginas primeiro, depois usaria JavaScript para realçar a experiência do usuário.

O IE é menos performante que o Safari, o Chrome e o FF quando se trata de JS - mas você realmente desenvolveu uma página inutilizável no IE com o JS ligado? Eu só não vi - na natureza, acho que as várias implementações do JS são rápidas o suficiente.

Answer 2

Eu não fiz isso sozinho, mas posso ver que faz muito sentido se o seu orçamento permitir (e você não pode controlar a escolha do navegador do seu usuário)

No final do dia, os usuários do IE podem estar usando um navegador lento, mas ainda são seus usuários. Portanto, se você deseja dar a todos os seus usuários a melhor experiência possível do usuário, pode valer a pena gastar algum tempo, dando aos usuários do IE uma versão diferente do aplicativo para fornecer a eles um nível mais alto de desempenho.

Um aplicativo rápido para 99% dos seus usuários é indubitavelmente melhor do que um aplicativo que é rápido para apenas 30% de seus usuários. A única pergunta é o que é mais importante - a experiência do usuário ou seu tempo de desenvolvimento (e leve em consideração que, em alguns anos, o usuário médio executará navegadores mais rápidos em computadores mais rápidos)

Qualquer trabalho desse tipo deve ser conduzido por benchmarks, pois minha experiência é que você geralmente ficará surpreso com a parte do código lenta e qual parte do código é rápida.

Como um aparte, Lombardi Blueprint tem uma abordagem muito interessante, embora provavelmente impraticável fora do GWT. Eles têm algoritmos de layout escritos em Java, escritos de modo que possam ser executados no lado do cliente (via GWT) e no lado do servidor (através de uma JVM padrão). Consequentemente, com base no desempenho comparado do seu navegador, eles podem alternar dinamicamente entre fazer o layout no lado do cliente (para navegadores rápidos) vs fazendo o layout no lado do servidor (para navegadores mais lentos).

Answer 3

Dois problemas diferentes com os navegadores hoje em dia:

1. Velocidade. Minha experiência foi que o IE 7 funciona bem, muito mais lento que o resto. Minha correção é fornecer atualizações de progresso mais frequente da interface do usuário para os usuários. Como a atualização da interface do usuário leva tempo, minimizo as atualizações sobre os navegadores mais rápidos. Por exemplo, no IE, atualizo a tela com mais feedback depois de processar outros 50 eventos. Para outros navegadores, depois de processar 200 eventos.

2. Falta de característica. Por exemplo, tela. Mas é uma grande despesa construir vários sites. E teste -os também. Então, gasto meu orçamento em 1 versão para todos os navegadores de desktop atuais. E faça sites adicionais para o Mobile ESP iPhone.

Hth,

Larry

Answer 4

O que faço é escrever um arquivo JavaScript básico que tenha a funcionalidade comum, indo para o denominador mais baixo (JavaScript 1.5). Então, tenho outros arquivos para versões mais recentes do JavaScript, e elas substituirão as funções nos meus objetos JavaScript, para que eu possa adicionar progressivamente mais suporte.

Se eu quiser usar a tag de tela, posso adicioná -la em um arquivo diferente, pois o IE e o Firefox/Opera/Safari diferem na maneira como eles criam o elemento Canvas.

Isso não é uma alegria na manutenção, mas se eu quiser usar os novos recursos HTML/JavaScript, esse parecia ser o melhor modelo.

Answer 5

Eu concordo com Andy. O fornecimento de uma versão diferente de um aplicativo para diferentes navegadores é um problema de manutenção em potencial no futuro. Eu sempre achei uma aposta melhor fornecer uma versão de um aplicativo, que funciona em todos os navegadores. Por exemplo, tento evitar os sniffers do navegador. O aplicativo pode não ser o mais legal, mas funciona para todos e é mais fácil de manter.

Esse tipo de coisa é mais fácil agora, com todas as bibliotecas de JavaScript bacanas que abstraem algumas das diferenças do navegador. Além disso, você pode fazer muitas coisas nos navegadores mais antigos. Está apenas feito "de maneira diferente";)

Answer 6

Então, digamos que você constrói um aplicativo de tamanho decente. Você tem abundante em abundância para determinar quais recursos estarão e quais serão desativados. Você cheirou a Opera 9.x, e agora (hoje na verdade) Opera 10 sai. Você tem que ir e atualizar cada sniffer em todas as páginas. E então outro navegador sai em breve ... e outro. Você vai gastar todo o seu tempo, determinando quais navegadores apoia e quais recursos para apoiá -los.

Eu uso vários navegadores em um dia. Então, quando vou ao seu site, vou ver três interfaces diferentes. Ficarei confuso, já que os recursos que eu esperava estar lá ou os comportamentos que eu esperava não estarão lá. Eventualmente, ficarei frustrado e nunca mais vou ao seu site.

Além disso, há mais a rapidez com que algumas partes do JavaScript são do que apenas o navegador. Eu ainda tenho um antigo Pentium executando o Firefox 3.5. Às vezes, pode ser dolorosamente lento.

Answer 7

Eu acho que a resposta é que você precisa categorizar seu código em categorias de velocidade, não apenas categorizando os recursos do navegador.

Em outras palavras, dê a seus níveis de recursos, o primeiro nível é o HTML básico, o segundo nível é o JavaScript Usability Melhorias, o terceiro nível é o Javascript Animation Eye Candy.

Em seguida, faça uma combinação de permitir que seus usuários deixem um nível sempre que quiserem: "Clique para desativar as animações!", "Clique para ativar as animações!", "Clique para ver no HTML básico" e optar por padrão para o padrão para Certas categorias de velocidade baseadas no navegador por razões de velocidade (por exemplo, se o IE7 parece evidenciar problemas de velocidade com as animações completas, faça com que ele faça o segundo nível de "melhorias de usabilidade de JavaScript").