Por que devo evitar scripts in-line?

what are the real problems with inline scripting? Is there a significant performance issue, or is it mostly just a matter of good style?

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

Can I justify immediate action on the inline scripting front to my superiors, when there are other things to work on that might have a more obvious impact on the site?

Não, provavelmente não. Pode ser muito difícil convencer os poderes que são de puro trabalho de manutenção, mesmo que você acredite que isso irá economizar dinheiro a longo prazo. Neste caso, porém, não acho que seja tão importante que você deva parar tudo e se livrar de seu script in-line. Em vez disso, apenas certifique-se de fazer um esforço consciente para corrigir as áreas enquanto trabalha nelas por outras razões. O código de refatoração deve ser algo que você faz regularmente, mas só um pouquinho por vez.

If you pulled up to a website, and took a peek at the source code, what factors would lead you to say "hmm, professional work here", and what would cause you to recoil from an obviously amateurish job?

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 utilizado em excesso.     

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

Todas as suas páginas iniciais usam JavaScript inline. Isso significa que todas essas empresas contratam pessoas amadores para criar suas homepages?

Sou um desses desenvolvedores que não conseguem colocar o código JavaScript dentro do HTML. Eu nunca faço isso dentro dos projetos em que trabalho (exceto provavelmente algumas chamadas como <a href="javascript:..."> para os projetos onde o JavaScript discreto não era um requisito desde o início, e eu sempre removo o JavaScript inline quando refatorio o código de outra pessoa. vale a pena o esforço? Não tenho tanta certeza.

Em termos de desempenho, nem sempre você tem um desempenho melhor ao colocar o JavaScript em um arquivo separado. Geralmente, somos tentados a considerar essa largura de banda de desperdício JavaScript inline, uma vez que ela não pode ser armazenada em cache (exceto quando você lida com HTML com cache estático). 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 a externalização do JavaScript prenderia o seu site, mas você também pode estar totalmente errado:

• E se a maioria dos seus usuários vier com um cache vazio?
• Você considerou isso 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 normalmente, não é),
• O arquivo .js está realmente em cache (com o 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 in-line.

Depois vem o argumento final: você misturou JavaScript e HTML na sua fonte, então você é um saco. 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 compactado, minimizado ou vários arquivos CSS ou JS podem ser unidos em um arquivo, mas não significa que você realmente nomeou suas 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 um código-fonte JavaScript externo injetado no HTML em tempo de compilação ou mais tarde através dos modelos.

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

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

Ento, envergonhe a pessoa que diz "site muito legal, vergonha sobre o script in-line no cdigo-fonte" olhando apenas para a fonte enviada ao navegador, sem saber nada sobre como o site foi feito.

Geralmente, é bom tentar manter o HTML e o JS geralmente separados. HTML é para a visão, JS é para a lógica da aplicação. Mas, na minha experiência, o desacoplamento extremo 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, 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 o que está provocando um evento para acontecer. A razão é que seis meses depois você pode inspecionar o elemento (por exemplo, no Chrome) e ver imediatamente o evento de javascript é acionado.

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

<input id="yourId"  />

Como você pode facilmente me dizer qual método javascript está chamando? O Chrome tornou isso mais fácil, mas talvez o evento esteja vinculado ao ID ou talvez esteja vinculado 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 diria que esconder o javascript completamente do designer pode, na verdade, aumentar a probabilidade de ele quebrá-lo em uma atualização. Se alguém edita código para um elemento magicamente ativo, que indicação no código ele informa que isso é um elemento ativo na página?

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

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

Aqui estão algumas razões.

1. O script in-line não pode ser reduzido (convertido para uma versão mais curta através 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 estão em roaming de dados global - cada byte pode contar.

2. O script in-line não pode ser armazenado em cache pelo navegador, a menos que a própria página possa ser armazenada em cache (o que tornaria uma página muito chata). Os arquivos de Javascript externos só precisam ser recuperados uma vez, mesmo se o conteúdo da página mudar sempre. Pode afetar seriamente o desempenho em conexões de baixa largura de banda.

3. O script in-line é mais difícil de depurar porque o número da linha associado a qualquer erro é insignificante.

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

5. O script in-line não pode ser testado independentemente de sua página; arquivos JavaScript externos podem ser executados por meio de testes independentes, incluindo testes automatizados.

6. O script in-line pode levar a uma má separação de interesses (conforme descrito por muitas das outras respostas aqui).

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

É possível desativar a execução do JavaScript inline no navegador moderno por meio da Política de segurança de conteúdo . Isso reduz o risco de o seu site ser vítima do XSS. Este pode ser um argumento mais convincente para fazer com que sua administração invista na remoção do script in-line.

Existem vários motivos que justificam não incluir o script em linha:

• Em primeiro lugar, a resposta óbvia é o código mais limpo, mais conciso, mais fácil de entender e ler.

• De um ponto de vista mais prático, você geralmente deseja reutilizar scripts / CSS / etc. em todo o seu site - preencher essas partes significaria ter que editar cada página toda vez que você fizer uma pequena alteração.

• Se você usar um SCM para seu projeto, ter seus diferentes componentes bem separados tornará as alterações de rastreamento e os compromissos mais fáceis para todos os envolvidos.

Tanto quanto sei, o desempenho não seria uma preocupação. Dependeria de muitas coisas relacionadas à natureza do seu site, às especificações do seu servidor, etc. Por exemplo, se a sua página usa muito JavaScript, seu navegador pode armazenar os scripts em cache, 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 rápido do que vários arquivos menores - nesse caso, pode-se argumentar que não separar o código é melhor desempenho.

Não tenho conhecimento de nenhum teste formal nesta área, embora seja muito provável que alguém tenha feito isso.

No final, eu diria que é uma questão de boas práticas mais do que qualquer outra coisa, 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 o javascript) é usado.

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

Então, para alguém fazer uma declaração geral de que o uso de "código em linha" é ruim sem entender completamente como ele é usado 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 é ruim.

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

Também é muita sobrecarga 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 inline aqui.

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

1. Você tem <script> s espalhados por toda a página
2. Tudo 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 em todo o arquivo de origem dificulta a manutenção da , porque é necessário procurar um determinado script. É muito melhor manter todo esse código em um lugar (prefiro no topo do arquivo de origem).

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

Um motivo para NÃO usar o JavaScript InLine (nem mesmo onclick="DoThis (this)" nos botões) é se você pretende tornar seu aplicativo da Web um aplicativo do Google Chrome. Portanto, se você planeja migrar seu aplicativo da web para um aplicativo nativo do Google Chrome, comece NÃO INCLUINDO QUALQUER javascript inline. Isso é explicado logo no início do que você precisará alterar (obrigatoriamente) de seu aplicativo da web se você pretende "criá-lo".

What are the real problems with inline scripting?

O script in-line é ruim e deve ser evitado porque torna o código mais difícil de ler.

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 conseguirá identificar bugs facilmente. Se for difícil de manter, perderá mais tempo 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>

O ideal é que o código seja escrito de uma maneira que facilite detectar quando há um erro. Joel Spolsky escreveu um ótimo artigo que enfatiza esse ponto em 2005 . Os exemplos de código poderiam usar alguma melhoria significativa, já que eles estão mostrando sua idade sendo de 9 anos de idade, mas o conceito subjacente ainda é strong: escrever código de uma forma que facilita a escolha de bugs.

Is there a significant performance issue, or is it mostly just a matter of good style?

O script inline 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 pouca legibilidade, afetam seriamente o desempenho do mantenedor . O tempo de programação tem um custo real que afeta a linha inferior de um negócio mais rápido do que os poucos milissegundos da maioria das otimizações de código. Certamente, otimizar os gargalos é importante, mas a diferença de desempenho do código é insignificante nesse caso.

Can I justify immediate action on the inline scripting front to my superiors, when there are other things to work on that might have a more obvious impact on the site?

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

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

What factors would lead you to say "hmm, professional work here", and what would cause you to recoil from an obviously amateurish job?

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