O JavaScript embutido é bom ou ruim?

16

Atualmente, mudei do WordPress para o framework Yii e um desenvolvedor externo está reconstruindo meu site.

Uma coisa que noto é que cada vez que ele invoca o AJAX / jQuery da maneira Yii, ele incorpora o ~~JavaScript embutido~~ na página da web. Embora pareça que o código JavaScript esteja abaixo do rodapé, ele ainda está embutido.

Em geral, parece que o código JavaScript é mais frequentemente colocado dentro da página da web. Sempre pensei que os scripts JavaScript deveriam, tanto quanto possível, ser colocados em arquivos JavaScript. Esta é uma tendência "nova" que vem? Ou ainda devo tentar manter o código JavaScript em arquivos separados?

html javascript

— Steven
fonte

O que exatamente você quer dizer com insere JavaScript embutido na página da web ?

— Salman A

3

Para o bem dos outros que acham esta questão e está pensando em coisas como <a onClick="function(){/* do stuff */} ">Click Here</a>esta, eu entendo, é considerado muito ruim e deve-se separar o seu código de seu HTML See: Este artigo

— TecBrat

1

@ user1066946 t.co/j1RpJgwoku :-)

— Kos

1

@ user1066946 Gosto muito de usar o Angular, apenas observei que a "web semântica" fez um círculo (em termos de manter algum código de cola próximo ao DOM) #

— 275 Kos Kos

1

"Embora pareça que o código JavaScript esteja abaixo do rodapé, ele ainda está embutido." - Parece que você está se referindo ao JavaScript incorporado , em vez do JavaScript "embutido" (ao qual o TecBrat se refere).

— MrWhite

13

O JavaScript embutido aumenta o tempo de download da página, o que não é bom. Com uma chamada para um .jsarquivo, pelo menos essas podem ser chamadas paralelas e o tempo de download do conteúdo diminuído. Sim, há momentos em que não há problema em colocar o JavaScript diretamente no código HTML, mas geralmente é melhor descarregar o máximo possível.

Lembre-se de que os tempos de download da página (ou seja, o HTML) e nem todas as chamadas de recursos afetam as métricas que afetam a classificação (embora o PageRank ou os SERPs não importem). O ponto é que afeta o desempenho de sites para SEO, no entanto, ele se manifesta.

— closetnoc
fonte

7

Negociar uma segunda conexão com um presumivelmente o mesmo host para baixar a mesma quantidade de dados é mais rápido do que dentro do fluxo ativo? normalmente, se você obtém, por exemplo, 50 Kbps em um arquivo para um host, iniciar uma segunda sessão pode reduzir o tempo para que ambos agora tenham 25 Kbps. A menos que o host esteja limitando por conexão por algum motivo.

— EkriirkE

Há um engodo para arquivos externos. Se não for feito corretamente, você cria o código de bloqueio do DOM, ou seja, o gatilho doc.ready é mais lento, o que afeta a velocidade alcançada . Mas, se feito corretamente, externa é o caminho a percorrer

— Martijn

4

.jsComo os arquivos são melhores para armazenamento em cache, não faz sentido que duas conexões com o mesmo host aumentem magicamente a velocidade do download.

O pensamento de dividir a largura de banda, enquanto eu entendo sua lógica e não está totalmente errado, é um pouco enganador. O HTML é menor, levando menos tempo e qualquer chamada subsequente pode realmente esperar.

— Closetnoc 14/05

3

se você está esperando tempo, está errado ao analisar a largura de banda. observe o profiler nos horários de carregamento: normalmente, os tempos de conexão são 10 a 100 vezes maiores que o tempo real de troca de dados. isso significa que a FRAGMENTATION é um problema real e o uso de um arquivo externo dedicado para js muito pequenos pode ser o pior da linha. Inline é melhor no navegador que não faz a paralelização reais

— Lesto

29

No meu site de conversão de moeda, a maioria das sessões são visualizações de página única. Isso ocorre porque os usuários podem fazer o cálculo da moeda diretamente na página de destino (todo o cálculo é tratado no lado do cliente com JavaScript).

Minha página é baixada e renderizada em aproximadamente metade do tempo em que todos os recursos (css, js e até imagens ) estão alinhados na página. Como poucos dos meus usuários visualizam várias páginas, eu não me beneficiaria muito com o armazenamento em cache de alguns desses recursos entre as visualizações de página.

Meu site não é típico. A maioria dos sites possui várias páginas por sessão e imagens grandes que tornariam minha técnica menos aplicável. Não existe uma solução correta para essa pergunta; isso depende do site. Você precisa medir isso com base no comportamento típico de seus usuários.

— Stephen Ostermiller
fonte

12

Não é necessariamente ruim ter JavaScript dentro do seu arquivo HTML, mas você deve fazer um julgamento.

Ele é ruim se você tem uma grande quantidade de JavaScript que está sendo usado em várias páginas. Nesse caso, o JavaScript deve estar em um arquivo externo, compactado e configurável e se o seu site tiver tráfego muito pesado, você deverá usar uma CDN.

No entanto, se você tiver uma pequena quantidade de JavaScript, a economia de colocá-lo em um arquivo externo pode ser negada pelo fato de que você precisa fazer uma solicitação HTTP adicional para recuperá-lo. Nesse caso, seria mais eficiente manter o JavaScript na sua página.

Por outro lado, se esse mesmo pequeno trecho de JavaScript for usado em várias páginas, seria benéfico colocá-lo em um arquivo externo para aproveitar o cache.

Por fim, você deve ponderar o tamanho do JavaScript em relação à sobrecarga de fazer solicitações HTTP adicionais. Na maioria das vezes, para um site "médio", provavelmente não fará muita diferença apenas colocá-lo em um arquivo externo.

— foamcow
fonte

4

Sou desenvolvedor do Yii e posso lhe dizer que o Yii não tem nada a ver com isso . É totalmente do lado do desenvolvedor , se ele coloca o código Javascript em um arquivo separado e o registra na página HTML (view) com o CClientScript::registerScriptFilemétodo ou coloca diretamente no código HTML (view) e o registra usando o CClientScript::registerScriptmétodo

De acordo com sua resposta, a maioria dos desenvolvedores (profissionais?) Do Yii vota fortemente na primeira abordagem, ou seja, mantendo o máximo de código Javascript em arquivos separados possível. Portanto, essa certamente não é uma nova tendência de codificação, mas uma prática ruim do desenvolvedor. Pelo menos, é assim que é visto na comunidade Yii.

Edição : Na verdade, eu esqueci o argumento mais importante. O Yii (assim como a maioria das outras estruturas profissionais de PHP) é baseado no padrão de design do MVC (na verdade: padrão de arquitetura). E o mesmo padrão pode ser usado na frente: o código HTML é o modelo (dados), CSS é a visualização (decorador) e Javascript é o controlador. Todos eles são colocados em arquivos separados , .jse .cssarquivos - compactados, obsfucados e compactados no melhor cenário.

Ao criar seu aplicativo Yii, você pode quebrar o padrão MVC e manter tudo no mesmo arquivo. A questão é - vale a pena fazê-lo, quais são os benefícios (nenhum?) E aonde isso o levará? Você pode usar a mesma argumentação ao perguntar se deve manter o código JS embutido ou não?

— trejder
fonte

Está bem. O desenvolvedor parece usar widgets de terceiros para tudo; Preenchimento automático, upload de imagens ajax etc. Tudo isso adiciona js inline.

— 1411 Steven

Não, não posso concordar. Estou usando o Twitter Bootstrap em meus aplicativos Yii (provavelmente a maior extensão do Yii e um enorme conjunto de widgets), além de muitas outras extensões do Yii e nenhum deles usa JS embutido. Seu desenvolvedor precisaria ter muita sorte para encontrar widgets e extensões, que usam apenas Javascript embutido. Você precisa ter bastante experiência no Yii para começar a escrever extensões próprias (com exceção das poucas, realmente mal escritas) e até mesmo o desenvolvedor semi-experiente do Yii usa o código embutido como última opção, se tudo mais falhar.

— Trejder

Usar extensões e widgets de terceiros no Yii é uma ótima idéia (você não precisa inventar a roda novamente). Mas, usar código JS embutido no aplicativo ou extensão Yii é realmente uma má atitude. Então, force o seu desenvolvedor a escrever um código melhor / use melhores extensões e widgets ou ... obtenha um desenvolvedor melhor! :]

— Trejder

Ok, obrigado pelo feedback. Além do Stackoverflow, onde posso encontrar uma boa comunidade Yii?

— 1411 Steven

No fórum Yii . A maioria das páginas é acessível gratuitamente. Alguns exigem o registro de uma conta e o login. A maioria dos desenvolvedores Yii no Stack Overflow tem contas próprias no fórum. Depois de quase seis anos de existência, a estrutura do Yii conquistou uma grande comunidade de desenvolvedores; portanto, se você observar com cuidado, poderá encontrar poucos desenvolvedores do Yii na sua comunidade local ou mesmo na vizinhança. Boa sorte.

— #

3

Na verdade, depende do objetivo da página da web que você está desenvolvendo:

Eu uso uma pequena quantidade de JavaScript embutido, enquanto eu prefiro usar arquivos JavaScript externos, se ele for grande.

De qualquer forma, quando a página carrega JavaScript, ela deve ser executada primeiro. A melhor prática é usar JavaScript externo para não aumentar o conteúdo da página. Também facilita a depuração.

— Abhijith Bhattu
fonte

2

A resposta realmente depende do que está sendo feito.

Se você observar o JavaScript embutido usado em todo o site (por exemplo, um widget exibido dentro do cabeçalho em todas as páginas do site), seria apropriado movê-lo para um arquivo JavaScript "comum".

Na verdade, eu moveria o máximo de JavaScript possível para um arquivo JavaScript comum, mesmo que fosse usado em uma única página. Eu configuraria o servidor para enviar cabeçalhos fortes de cache e compactação para arquivos JavaScript; o que reduz o tamanho das páginas, mas não aumenta em muito o tamanho do arquivo JavaScript.

Por outro lado, se o JavaScript é simplesmente um monte de opções de configuração / inicialização, por exemplo:

$(function () {
    myplugin({
        images: ["img1", "img2", "img3"]
    });
});

onde, por algum motivo, não era possível mover o código para um arquivo JavaScript externo (por exemplo, quando os parâmetros da imagem vêm do banco de dados), eu o mantinha alinhado. Dito isto, eu escolheria plugins de terceiros que sejam "discretos" (ou os converterão como tal).

— Salman A
fonte

2

Essas respostas erram o alvo. Dê uma olhada no cache Inline .

Como o Yii é codificado em PHP, um padrão PHP comum (ou talvez incomum) que você encontrará é que às vezes os desenvolvedores escrevem código PHP para gerar código Javascript dinamicamente no servidor - com base em algum estado, condição ou valor conhecido pelo servidor - e envie tudo para o cliente em um lote, permitindo que o cliente execute a função e pule parte da computação que já foi feita pelo servidor.

Em vez de enviar um monte de funções Javascript genéricas em um arquivo .js para o cliente que não têm contexto até que sejam fornecidos dados (dados que podem estar no servidor e exigir uma viagem de ida e volta), podemos "assar" contexto / dados como parte da função Javascript. Isso é econômico porque significa que você está enviando a funcionalidade / dados juntos e apenas a funcionalidade / dados que um cliente pode precisar no momento, em vez de enviar o aplicativo inteiro no carregamento da primeira página. Isso também significa que você não precisa expor seu aplicativo inteiro a ser facilmente baixado e com engenharia reversa no carregamento da primeira página, porque você está injetando apenas pequenas porções de funcionalidade que cada cliente individual pode precisar no momento. Não tenho certeza do quão bom isso é para o SEO, mas tenho certeza de que ele pode ser otimizado de acordo.

Considere o caso de um usuário final escrever uma página em algum software CMS usando um editor WYSIWYG. Como esse usuário adiciona novas funcionalidades à página quando não tem acesso aos arquivos .js de origem no servidor? Eles alternam para a guia HTML e usam Javascript embutido.

Nem todo o Javascript embutido é ruim; Às vezes, o onclick também é bom. Como recomendação geral, evite escrever Javascript embutido e você estará no caminho de criar bons hábitos.

Referências:

— perada
fonte

0

Normalmente, o código JS embutido é ruim, como os outros disseram antes de mim.

Mas penso em um caso de uso em que o JS embutido é melhor .

Pense em um CMS que insere uma galeria orientada por JS. A galeria pode ser feita em jQuery. É identificado por um atributo id, que não é apenas exclusivo na página, mas também exclusivo em todo o site. Nesse caso - acho - o JS embutido seria melhor, porque o código JS é usado apenas em uma página e você não tem sobrecarga HTTP

— yunzen
fonte