Por que devo evitar scripts embutidos?

Um amigo experiente analisou recentemente um site que eu ajudei a lançar e comentou algo como "site muito legal, que vergonha sobre o script embutido no código-fonte".

Definitivamente, estou em posição de remover o script embutido onde ele ocorre; Estou vagamente ciente de que é "uma coisa ruim". Minha pergunta é: quais são os problemas reais com scripts embutidos? Existe um problema de desempenho significativo ou é apenas uma questão de bom estilo? Posso justificar uma ação imediata na frente dos scripts em linha para meus superiores, quando há outras coisas a serem trabalhadas que podem ter um impacto mais óbvio no site? Se você acessasse um site e espiasse o código-fonte, que fatores o levariam a dizer "hum, trabalho profissional aqui" e o que faria com que você se afastasse de um trabalho obviamente amador?

Ok, essa pergunta se transformou em várias perguntas na redação. Mas basicamente, scripts embutidos - qual é o problema?

quais são os problemas reais com scripts embutidos? Existe um problema de desempenho significativo ou é apenas uma questão de bom estilo?

As vantagens não são baseadas no desempenho, elas são (como Michael apontou em seu comentário) mais relacionadas à separação da visualização e do controlador. O arquivo HTML / CSS deve, idealmente, conter apenas a apresentação e arquivos separados devem ser usados ​​para scripts. Isso facilita para você (e seus colegas) ler e manter os aspectos visuais e funcionais.

Posso justificar uma ação imediata na frente dos scripts em linha para meus superiores, quando há outras coisas a serem trabalhadas que podem ter um impacto mais óbvio no site?

Não, provavelmente não. Pode ser muito difícil convencer os poderes do puro trabalho de manutenção, mesmo que você acredite que isso lhes poupará dinheiro a longo prazo. Nesse caso, porém, não acho tão importante que você pare tudo e se livre dos scripts embutidos. Em vez disso, certifique-se de fazer um esforço consciente para retificar áreas ao trabalhar nelas por outros motivos. O código de refatoração deve ser algo que você faz regularmente, mas apenas um pouco de cada vez.

Se você acessasse um site e espiasse o código-fonte, que fatores o levariam a dizer "hum, trabalho profissional aqui" e o que faria com que você se afastasse de um trabalho obviamente amador?

O fator número um que me diria que não é profissional é o uso excessivo de tabelas ou divs. Aqui está um artigo explicando por que nenhum deles deve ser usado em excesso.

Não serei o advogado do diabo, mas não existe uma relação estrita entre trabalho amador e JavaScript embutido. Vamos ver o código fonte de vários sites mais conhecidos:

• Google,
• Wikipedia,
• Microsoft,
• Adobe,
• Dell,
• IBM.

Todas as suas home pages usam JavaScript embutido. Isso significa que todas essas empresas contratam pessoas amadoras para criar suas páginas iniciais?

Eu sou um daqueles desenvolvedores que não podem colocar o código JavaScript dentro do HTML. Eu nunca faço isso nos projetos em que trabalho (exceto provavelmente algumas chamadas, como <a href="javascript:...">nos projetos em que o JavaScript discreto não era um requisito desde o início, e sempre removo o JavaScript embutido quando refato o código de outra pessoa. Mas vale a pena o esforço ? Não tão certo.

Em termos de desempenho, nem sempre você tem melhores desempenhos ao colocar o JavaScript em um arquivo separado. Geralmente, somos tentados a considerar essa largura de banda de resíduos de JavaScript embutida, pois ela não pode ser armazenada em cache (exceto quando você lida com HTML estático em cache). Pelo contrário, um arquivo .js externo é carregado apenas uma vez.

Na realidade, essa é apenas outra otimização prematura : você pode estar certo ao pensar que externalizar o JavaScript fixaria seu site, mas também pode estar totalmente errado:

• E se a maioria dos seus usuários vier com um cache vazio?
• Você considerou que, com um arquivo .js externo, uma solicitação será feita para esse arquivo a cada solicitação de página, se o site não estiver configurado corretamente (e geralmente não está),
• O arquivo .js é realmente armazenado em cache (no IIS, pode não ser tão fácil)?

Portanto, antes de otimizar prematuramente, colete estatísticas sobre seus visitantes e avalie os desempenhos com e sem JavaScript embutido.

Em seguida, vem o argumento final: você misturou JavaScript e HTML em sua fonte e, por isso, é péssimo. Mas quem disse que você misturou os dois? O código fonte usado pelo navegador nem sempre é o código fonte que você escreveu. Por exemplo, o código-fonte pode ser comprimido, minified, ou vários arquivos CSS ou JS podem ser unidas em um único arquivo, mas isso não significa que você realmente nomeou seu variáveis a, b, c... a1, etc., ou que você escreveu um arquivo CSS enorme sem espaços ou novas linhas. Da mesma forma, você pode facilmente ter o código-fonte JavaScript externo injetado no HTML no momento da compilação ou posteriormente através dos modelos.

Para concluir, se você misturar JavaScript e HTML no código-fonte que você escreve, considere não fazê-lo em seus projetos futuros. Mas isso não significa que, se o código-fonte enviado ao navegador contiver JavaScript embutido, é sempre ruim.

• Pode ser ruim.
• Pelo contrário, pode ser um sinal de que o site foi escrito por profissionais que se preocupavam com o desempenho, fizeram testes específicos e determinaram que seria mais rápido para seus clientes incorporar partes do JavaScript em linha.
• Ou pode não significar nada.

então, que vergonha para a pessoa que diz "site muito legal, que vergonha com os scripts embutidos no código-fonte", olhando apenas a fonte enviada ao navegador, sem saber nada sobre como o site foi criado.

Geralmente é bom tentar manter HTML e JS geralmente separados. HTML é para a visualização, JS é para a lógica do aplicativo. Mas, na minha experiência, o extremo desacoplamento de html e javascript (por uma questão de pureza) não o torna mais sustentável; na verdade, pode ser menos sustentável.

Por exemplo, às vezes eu uso esse padrão (emprestado do ASP.net) na configuração de manipuladores de eventos:

<input type="button" id="yourId" onclick="clickYourId()" />

ou

<input type="button" id="yourId" onclick="clickYourId(this)" />

Não há mistério sobre o que está causando um evento. O motivo é que, seis meses depois, você pode inspecionar o elemento (por exemplo, no Chrome) e ver imediatamente qual evento javascript é acionado.

Por outro lado, imagine que você está lendo o código de outra pessoa, que é cem mil linhas, e se depara com um elemento mágico que dispara um evento javascript:

<input id="yourId"  />

Como você pode facilmente me dizer qual método javascript está chamando? O Chrome facilitou isso, mas talvez o evento esteja vinculado ao ID ou, talvez, ao primeiro filho do contêiner. Talvez o evento esteja anexado ao objeto pai. Quem sabe? Boa sorte em encontrá-lo. :)

Além disso, eu argumentaria que ocultar completamente o javascript do designer pode realmente aumentar a probabilidade de que eles o quebrem em uma atualização. Se alguém editar código para um elemento magicamente ativo, que indicação no código eles têm que os informaram que esse é um elemento ativo na página?

Portanto, em resumo, a melhor prática é separar HTML e Javascript. Mas também entender que as regras práticas são às vezes contraproducentes quando levadas ao extremo. Eu argumentaria por uma abordagem no meio do caminho. Evite grandes quantidades de js inline. Se você usa inline, a assinatura da função deve ser muito simples como:

1. emptyFunction()
2. doCallWithThis(this)
3. atTheExtremOnlyPassOneNumber(2)

Um argumento que estou perdendo aqui é a possibilidade de maior proteção contra ataques de script entre sites .

É possível desativar a execução do JavaScript embutido no navegador moderno por meio da Política de segurança de conteúdo . Isso reduziu o risco de seu site ser vítima de XSS. Esse pode ser um argumento mais convincente a ser feito para que seu gerenciamento invista na remoção de scripts embutidos.

Aqui estão algumas razões.

1. O script embutido não pode ser reduzido (convertido para uma versão mais curta por meio da redução de símbolo). Não é uma preocupação em banda larga, mas considere um dispositivo móvel em uma área de baixa largura de banda ou usuários que estejam em roaming global de dados - cada byte pode contar.

2. O script embutido não pode ser armazenado em cache pelo navegador, a menos que a própria página seja armazenada em cache (o que tornaria uma página muito monótona). Os arquivos Javascript externos precisam ser recuperados apenas uma vez, mesmo que o conteúdo da página seja alterado sempre. Pode afetar seriamente o desempenho em conexões de baixa largura de banda.

3. O script embutido é mais difícil de depurar porque o número da linha associado a qualquer erro não faz sentido.

4. O script embutido tem a reputação de interferir nas considerações de acessibilidade (508 / WAI), embora isso não signifique que todo script embutido cause problemas. Se você terminar com um leitor de tela anunciando o conteúdo do script, você tem um problema! (Nunca vi isso acontecer embora).

5. O script embutido não pode ser testado independentemente de sua página; arquivos Javascript externos podem ser executados por testes independentes, incluindo testes automatizados.

6. O script embutido pode levar a uma fraca separação de preocupações (conforme descrito por muitas das outras respostas aqui).

Existem vários motivos que justificariam não incluir o script embutido:

• Primeiro de tudo, a resposta óbvia - torna o código mais limpo, mais conciso, mais fácil de entender e ler.

• Do ponto de vista mais prático, você geralmente deseja reutilizar scripts / CSS / etc. em todo o site - incluir essas partes significaria ter que editar todas as páginas toda vez que você fizer uma pequena alteração.

• Se você usar um SCM para o seu projeto, ter seus diferentes componentes bem separados facilitará o rastreamento das alterações e confirmará todos os envolvidos.

Até onde eu sei, o desempenho não seria uma preocupação. Isso dependeria de muitas coisas relacionadas à natureza do seu site, às especificações do seu servidor, etc. Por exemplo, se sua página da Web usa muito javascript, seu navegador pode armazenar em cache os scripts, o que resultaria em melhor desempenho quando o código é separado em vários arquivos. Por outro lado, ficaria tentado a dizer que alguns servidores podem servir um único arquivo grande mais rapidamente do que vários arquivos menores - nesse caso, pode-se argumentar que não separar o código é melhor em termos de desempenho.

Não conheço nenhum teste formal nesta área, embora seja provável que alguém tenha feito isso.

No final, eu diria que é mais uma questão de boas práticas e que as vantagens em termos de legibilidade e organização (especificamente o ponto 2) tornam a separação do código em arquivos distintos uma opção muito melhor.

A resposta realmente depende de como o código em linha (assumindo javascript) é usado.

Usamos uma combinação de código embutido, SSI (incluindo o servidor), arquivos js e arquivos css para criar os efeitos desejados e também reduzir as viagens de retorno do servidor para eventos onClick.

Portanto, alguém faça uma declaração geral de que o uso do "código em linha" é ruim sem entender completamente como ele pode ser enganoso.

Dito isto, se cada página tiver a mesma cópia e código javascript colado, em vez de usar um arquivo js, ​​digo que isso é ruim.

Se cada página tiver sua própria seção de cópia e colagem do CCS, em vez de usar um arquivo css, digo que isso é ruim.

Também é muito trabalhoso incluir toda a sua biblioteca js em todas as páginas, especialmente se nenhuma das funções estiver sendo usada nessa página.

Vou assumir o javascript embutido aqui.

Sem ver o código, é difícil ter certeza. Eu suspeito que ele estava se referindo a uma das duas coisas:

1. Você <script>está espalhado por toda a página
2. Tudo o que você JS está no cabeçalho da página, não em arquivos externos

A primeira é uma má decisão de design. A disseminação de scripts por um arquivo de origem torna a página muito mais difícil de manter, porque você precisa procurar um determinado script. É muito melhor manter todo esse código em um só lugar (prefiro na parte superior do arquivo de origem).

Quanto ao segundo - isso não é necessariamente uma coisa ruim. O código específico da página deve estar nessa página. Se você possui um código duplicado entre as páginas, deve externalizá-lo usando <script src>. Então, quando você criar uma nova página, poderá simplesmente incluir esse arquivo e todos os erros que você corrigiu não precisarão ser revisados.

Um motivo para NÃO usar o Javascript InLine (nem mesmo onclick = "DoThis (isto)" nos botões) é se você pretende tornar seu aplicativo da Web um aplicativo do Chrome. Portanto, se você planeja portar seu aplicativo Web em um aplicativo nativo do Chrome, comece por NÃO incluir QUALQUER javascript embutido. Isso é explicado logo no início do que você precisará alterar (obrigatoriamente) do seu aplicativo Web se você pretende "Chrome-etize".

Quais são os problemas reais com scripts embutidos?

O script embutido é ruim e deve ser evitado, pois dificulta a leitura do código.

Código difícil de ler é difícil de manter. Se você não conseguir lê-lo facilmente e entender o que está acontecendo, não poderá detectar facilmente os bugs. Se for difícil de manter, você perderá mais tempo mais tarde, quando houver problemas.

A dificuldade geralmente vem de codificações aninhadas. Há um problema na próxima linha de código, você consegue identificá-lo?

<a onclick='alert("What\'s going wrong here?")'>Alert!</a>

Idealmente, o código é escrito de uma maneira que facilita identificar quando há um erro. Joel Spolsky escreveu um ótimo artigo que enfatiza esse ponto em 2005 . Os exemplos de código podem usar algumas melhorias significativas, pois mostram que eles têm 9 anos de idade, mas o conceito subjacente ainda é forte: escrever código de uma maneira que facilite a detecção de bugs.

Existe um problema de desempenho significativo ou é apenas uma questão de bom estilo?

O script embutido leva à repetição. Em vez de alterar uma linha de código para afetar 100 páginas, você provavelmente precisará alterar 100 páginas individualmente. Isso, juntamente com a baixa legibilidade, afeta seriamente o desempenho do mantenedor . O tempo de programação tem um custo real que afeta os resultados de uma empresa mais rapidamente do que os poucos milissegundos da maioria das otimizações de código. Certamente otimizar gargalos é importante, mas a diferença de desempenho do código é insignificante nesse caso.

Posso justificar uma ação imediata na frente dos scripts em linha para meus superiores, quando há outras coisas a serem trabalhadas que podem ter um impacto mais óbvio no site?

Não. Se é estúpido e funciona, não é estúpido.

O corolário da programação é: se é código estúpido e funciona, não é código estúpido. Concentre-se nos problemas reais antes de tentar corrigir algo que não está quebrado. Quando o código embutido precisar de uma atualização, seja em seis horas, seis meses ou seis anos, corrija o código de uma maneira que facilite a manutenção futura.

Quais fatores o levariam a dizer "hum, trabalho profissional aqui" e o que faria com que você se retirasse de um trabalho obviamente amador?

Costumo preferir definir "profissional" apenas como alguém que é pago para executar uma tarefa, em vez de assumir que eles possuem alguma habilidade significativa no que estão sendo pagos para fazer. Muitos profissionais certamente são capazes de realizar um bom trabalho, mas, na maioria das vezes, eu me pego horrorizado com o terrível trabalho que outros profissionais fizeram, em vez de algo que um amador inventou. Grande parte do meu trabalho até o momento envolveu a recuperação de projetos de naufrágio de trem que foram danificados pelos desenvolvedores iniciais, portanto sua milhagem pode variar.

Com tudo isso dito, geralmente é fácil escolher a programação de qualidade corporativa