Separando Javascript do HTML até demais

June 18, 2007 at 7:02 am · Filed under Boa prática, Javascript, Web Standards

É interessante notar como alguns programadores seguem padrões com afinco, até as últimas consequências, onde houver código lá está ele impondo todos os padrões possíveis. Existe a boa prática em separar comportamento e apresentação, no caso de páginas HTML, os arquivos javascript são o comportamento e os arquivos CSS a apresentação, e o HTML faz uso de ambos, como pode ser observado aqui.

Observem o exemplo:

Trocar para texto plano
HTML:
  1. <input type="button" value="botão" id="meuBotao" onclick="meuEventoAqui()">

Algo que tem-se pregado por aí é retirar o totalmente o Javascript do HTML, ou seja, o exemplo acima ficaria assim:

Trocar para texto plano
HTML:
  1. <input type="button" id="meuBotao" value="botão">

E teríamos um arquivo .js com o seguinte código para ligar o evento onclick do button:

Trocar para texto plano
JAVASCRIPT:
  1. function ligacaoDeEventos() {
  2.       var botao = document.getElementById('meuBotao');
  3.       botao.onclick = function() {
  4.           finalmenteMeuEventoAqui();
  5.           }
  6.    }
  7.    window.onload = ligacaoDeEventos;

Puxa vida, toda essa volta só para não usar a propriedade onclick no HTML e se livrar totalmente do Javascript, isso vale a pena ?

Há vários motivos para que eu não concorde com isso:

  • Mais código para dar manutenção, foram criadas várias linhas de javascript para algo que funcionaria no primeiro exemplo usando a propriedade onclick da tag input.
  • E quando eu quiser saber qual evento o button aciona, será fácil de achar ? Podem haver vários objetos na página, todos com seus eventos ligados apenas no momento do onload da página. Vários objetos é igual a várias linhas de código javascript com as ligações, se você estiver usando um editor de textos comum, bem... boa sorte, e mesmo com uma IDE não é tão simples assim.
  • A propriedade onclick, onkeypress, etc faz parte da especificação HTML, justamente para facilitar isso, porque iria deixar de usá-los ?

Então muito cuidado ao seguir padrões ao extremo, questione-os, cada um tem o seu lugar e hora certa.

8 Comments »

  1. Ramon said,

    June 18, 2007 @ 12:25 pm

    Olá,
    leio algumas matérias suas e gosto do seu ponto de vista, porém hoje no entanto, não concordo com a sua opinião. Vc está certíssimo em afirmar que vai gerar mais linhas de códigos, porém se parar pra contar não são tantas linhas a mais, são duas ou três linhas a mais, que dependendo do tamanho do seu arquivo vai te ajudar bastante para fazer uma futura manutenção. Com certeza, para quem não é acostumado com esse método pensa que é um desperdício de tempo e que não vai afetar em nada colocando no botão já que é aceito e é muito mais fácil (eu tb pensava assim), mas fui acostumando e percebi que chamando pelo javascript evitava uma dor de cabeça imensa. Vou te dar um exemplo:

    Tenho uma função de validação de data, que é usada em um monte de botões do meu site (a efeito de exemplo 20 botões) e fui atribuindo essa função em cada botão via html, pois bem, em um determinado dia meu chefe fala que vai haver uma mudança nas funções desses botões (agora sim, vc vai ver o efeito devastador disso), então o que você faz? Tem que ir no html, procurar os botões que irão sofrer a alteração e mudar a função a ser chamada, ou seja, uma mudança apenas de comportamento vc tem que ir na estrutura para fazer tal mudança (o que é algo sem sentido). Mas da outra forma esse problema é facilmente resolvido, vc não precisa ir na parte estrutural do site para fazer a mudança. Vc sabe que fez a atribuições dos elementos no window.onload, então vc vai direto lá e faz a alteração da chamada da função ;) . Dessa forma, não gastou tempo procurando pelos botões e o mais importante não precisou ir na parte estrutural para fazer uma alteração comportamental.

    Com isso, quero dizer que de fato para começar a fazer o código é mais demorado (só o início, pq depois toda a estrutura está feita e é só atribuir o evento à função), mas para a manutenabilidade é muitooo mais fácil.

    fuiii…
    ps:Espero não ter sido arrogante no meu ponto de vista.

  2. Carlos Oliveira said,

    June 18, 2007 @ 3:52 pm

    Oi Ramon, de forma alguma foi arrogante, pelo contrário, adoro quando alguém comenta porque me faz refletir se o que eu escrevi está mesmo certo, afinal não sou dono da verdade e estou aberto a mudar meu ponto de vista, refatorá-lo por assim dizer =D.

    Então vamos lá, realmente você está certo em afirmar que ao colocar a chamada no window.onload, para “linkar” os objetos com os eventos, vai ajudar no momento em que for necessário uma mudança de evento para N objetos que tem o mesmo comportamento.

    Gostei do seu ponto de vista, vou tentar refatorar o meu então, vamos ver se você concorda comigo.

    No caso acima, você está certíssimo, mas e nos casos em que o evento+objeto existem uma única vez em toda a aplicação? Isso é comum, sendo assim todo evento que estiver ligado a um objeto você tem que colocar no window.onload que vai crescer vertiginosamente a medida que sua aplicação cresce, se não tomar cuidado vai perder o controle da manutenção facilmente, pra não falar que se este window.onload estiver grandíssimo pode sobrecarregar a engine de javascript, tornando o browser lento, claro que isso só ocorreria em casos extremos, mas como estamos falando de tirar todo o comportamento da parte estrutural, dependendo da quantidade de objetos e eventos isso pode ocorrer.

    Então novamente, concordo com você, mas somente para os casos em que o mesmo evento é usado N vezes, já para os casos de eventos únicos, para o bem da minha sanidade prefiro continuar usando o onclick inline mesmo ;)

    Aliás para esses casos em que uma objeto+evento é repetido várias vezes, como o seu caso de um botão para validar data, ao invés de criar o mesmo botão manualmente, prefiro deixar ao cuidados de um framework ou criar um um pequeno componente para esta funcionalidade que vai ser reutilizado para renderizar da mesma forma em N lugares. Sendo assim poderia manter o onclick inline, e quando quisesse alterar, bastaria alterar nesse único componente.

    Espero não ter sido confuso.
    Abraços

  3. Ramon said,

    June 19, 2007 @ 6:04 am

    Bom ponto de vista e com isso não tenho mais argumentos, pois já virou uma questão de gosto e gosto é igual ao c… cada um tem o seu e o defende como pode, porém em relação ao window.onload o código não cresce vertiginosamente por alguns motivos:

    1. A função window.onload, provavelmente, irá fazer apenas as chamadas para as funções.

    2. Você só vai fazer a chamada da função no window.onload, quando essas funções forem necessárias serem carregadas lá!

    3.Para cada chamada de função vai ter apenas uma linha de código, vc pode fazer a chamada da função sem a necessidade de uma variável.
    Ex: document.getElementById(“meubotao”).onclick = minhafuncao();

    4. Para mim esse motivo é o mais importante, quando vc for fazer a manutenção do código (comportamento), vc não precisa ir no html(estrutura), e com isso vc ganha bastante tempo, pois não precisa fazer a mudança de dois arquivos para uma simples manutenção.

    Conclusão:
    Eu sou extremamente a favor de chamar a função pelo javascript e vc nem tanto, não creio que há um certo ou errado nessa história, mas gostei dessa “discussão”, porque nunca tinha parado para analisar essas diferenças e isso só amadureceu a minha opinião.

    ps: Depois dessa “discussão” toda vou roubar o tema e abordar lá no meu blog! :)

    Abraços.

  4. Carlos Oliveira said,

    June 19, 2007 @ 8:36 am

    De fato tem razão se analisarmos as duas formas chega a ser uma questão de gosto mesmo.
    Pensando agora acho que nunca tive o problema que você apresentou no item 4 porque dificilmente eu faço uma página html sem utilizar partes reutilizáveis, então por exemplo em Rails se houver um botão com estrutura+comportamento iguais em N lugares posso criar um arquivo partial com esse carinha e reutilizá-lo, quando precisar alterar o comportamento não preciso ir no window.onload, posso alterar a chamada no partial e no arquivo .js.
    Claro, como você disse vai mudar em dois arquivos, mas novamente o bendito gosto ;) , a divisão fica melhor assim pra mim, pode ser que futuras implementações me façam mudar de idéia.
    Mas gostei muito do seu ponto de vista, vou lembrar disso em minhas futuras implementações com certeza, não havia lembrado desses pontos e são muito importantes para quem ler este post decidir por uma forma de implementar.
    Já adicionei seu link rss no meu google reader :D , fico no aguardo do post hein!

    Abraços!

  5. Ramon said,

    June 19, 2007 @ 5:12 pm

    Pode ter certeza, logo logo, vou postar…

    Abraços!

  6. anderson said,

    July 10, 2007 @ 9:03 am

    pois bem, gostei mto do ponto de vista de todos os expositores de ideias.. hehe, virou moda nesta pagina “gostar do ponto de vista” ..( piadinha )..

    eh claro, as ideias sao boas, todas, e o mundo ideal é : pegar as partes boas de cada ponto de vista, remodelar, criticar, e formular uma nova ideia “ideal”.. assim evoluiu a humanidade.. e a internet ne..

    o meu ponto de vista é: eu colocaria TUDO assim, separado de javascript e do html e do css… sempre. Minha razao? evitar q o designer arrebendo com o codigo. Isso aconteceria mais facilmente ainda se fosse um site tableless…
    Ou seja, se vc entrega pro seu designer SÓ os html com só tags htmls ( divs e tabelas ), nenhum acidente nunca acontecerá.. e o trabalho será mto mais facil. Dando inclusive pra trabalhar os 2 em paralelo ( designer e programador )….

    caras, eu acho q a minha sugestao nao eh unanime, mas ajuda a clarear alguns “ponto-de-vista” ne

  7. Walter Cruz said,

    August 2, 2007 @ 7:25 pm

    Uma boa razão: HTML 5 não suportará mais eventos diretamente dentro do HTML (http://www.quirksmode.org/blog/archives/2007/04/html_5.html). Tudo bem basta não usar, usar XHTML ou o que existir. Outra coisa que fico pensando: quando o documento tiver o doctype do HTML 5 o browser vai desabilitar o binding de eventos. Acho difícil disso acontecer.

  8. Higor said,

    June 26, 2008 @ 3:23 pm

    Fala Cara,post realmente muito bom.. Olha depois de tantos pontos abordados pelos outros amigos fica dificil deixar de lado os diversos pontos de vista abordados. No primeiro momento em que vi seu post concordei com sua afirmação, considerei exagero separar o código de tal maneira..Eu tinha o hábito de criar um arquivo .js com minhas funções e dessa forma na página eu importava os arquivos com as funções desejadas e pronto.Usando arquivos js o comportamento fica centralizado porem continuamos com as referências nos inputs(eu preferia assim!!) E isso galera..Carlos Parabéns pelo excelente post..

RSS feed for comments on this post · TrackBack URI

Deixe seu comentário