Tudo bem, basta me chamar de detentor de criptas em todo o necro que eu faço, mas nunca senti que o verdadeiro valor disso fosse entendido corretamente. Historicamente, foi afirmado que "JavaScript discreto" ou, mantendo seu JS fora do HTML por meio de atributos de manipulador de eventos HTML embutidos e tags de script que não se vinculavam ao arquivo o máximo possível, é um elemento importante de:
- Preocupações com acessibilidade
- SEO
- E aprimoramento progressivo
MENTIRAS! (bem, agora eles seriam)
A verdade é que você pode fazer JavaScript tecnicamente intrusivo e ainda assim retirar os três itens acima. A menos que você estivesse criando conteúdo HTML dinamicamente, o que era um grande não SEO no dia.
Mas pare e pense ... em você!
Realmente, o grande benefício, a maior e mais baixa vitória de manter a separação sempre foi o benefício direto que o desenvolvedor obtém disso. Você pode ter quantos manipuladores de eventos desejar no mesmo elemento html para o mesmo evento que for conveniente. Isso significa que, se uma tag class="some_class"sempre obtém um determinado comportamento, mas também recebe um bônus quando está dentro de uma id="bonus_behavior"div, não precisamos começar a mexer com a lógica dentro do nosso manipulador de eventos permitido para ramificar isso. Podemos apenas adicionar ou não manipuladores, dependendo do contexto.
Fácil de Ler Também
Outro benefício é legibilidade. Essa era uma preocupação mais crítica quando as ferramentas do navegador consistiam na mensagem de erro exclusiva do IE, informando que havia algo errado, [object]mas a IMO ainda é um grande problema. CSS aqui, JS lá e HTML são o local onde eles e o servidor se encontram. Com todas essas coisas reunidas em um só lugar, faz sentido confiar nos ganchos (os IDs, classes e hierarquia) para criar uma camada de abstração que tudo usa para se conectar ao HTML.
Na IMO, quanto mais você PODE manter seu HTML, CSS e JS separados, mais fácil é não apenas ler, mas também modificar e entender o que está acontecendo. Eu vejo uma div vazia com "dynamic_combo_box" como uma classe e tenho uma boa idéia de que algo está fazendo uma seleção sofisticada que carrega dados dinamicamente. Eu tenho uma liderança em como descobrir isso no JS e no CSS e se eu me deparar com a classe nessas preocupações, terei uma boa idéia do que se trata e como encontrá-lo no HTML.
Muito fácil de tornar ainda mais desleixado
E, claro, a legibilidade tende a andar de mãos dadas com a manutenção. Quando você faz as coisas diretamente, despejando tudo em tags de script em que o HTML relevante está, muitas vezes, fica mais fácil para as pessoas simplesmente recortar e colar esse script no HTML de outra página em que estão trabalhando quando eles querem funcionalidade semelhante, o que significa que agora você tem uma coisa que provavelmente se tornará duas coisas irritantemente semelhantes, mas não 100% iguais, cujo comportamento pode se tornar problemático ao longo do tempo ao desafiar as expectativas e exigir a adição de ramificações mais inúteis para lidar com as exceções necessárias. outro não.
Portanto, o comportamento de manipulação desses ganchos HTML incentiva a reutilização do código de maneira inteligente. Se você precisar ramificar o comportamento para uma implementação alternativa, basta acessar a mesma função e manipulá-la com a hierarquia HTML ou talvez com um att de dados acionando algum comportamento alternativo. É uma parada obrigatória para quem deseja entender como os elementos de interface do usuário de um determinado tipo funcionam e os tipos de recortar e colar desprezivelmente preguiçosos da maneira errada farão a coisa certa / mais sustentável apenas porque é a coisa mais fácil de fazer. faça agora e essa é a melhor maneira de fazer a manutenção acontecer. Torne a coisa mais fácil de fazer, mesmo para alguém que não se importa menos, seja por pânico ou apatia.
Mas e quanto a 2014?
Pode ser um ponto legítimo que, em aplicativos modernos de página única, algumas dessas coisas difíceis talvez não devam ser tão dogmaticamente como têm sido, mas acredite em mim quando digo que não acho que sou a única pessoa que foi vendido porque facilita o trabalho. Sou preguiçoso de uma maneira (espero) principalmente boa. Gosto quando preciso mudar as coisas em um só lugar para obter alterações em todo o aplicativo, quando só preciso procurar em um lugar para descobrir qual é o erro e quando tenho facilidade para entender o que diabos é isso. acontecendo e como melhor reutilizar esse código para fazer algo muito semelhante.
É bom que dividir um banco de dados ou uma camada de dados seja bom. Em última análise, é uma economia de tempo por que eu não fiz isso, como levar cinco minutos para lavar a roupa na noite anterior, em vez de gastar 10 minutos em congelar a boxer e realizar verificações paranóicas na manhã seguinte.
Para mim, são essas motivações egoístas que sempre foram o ponto principal do motivo pelo qual apego não apenas a JS discreta, mas a separação de estilo / comportamento / conteúdo preocupa-se o máximo possível, mesmo que O que o WG seja o mais danado possível. atrapalhe essas preocupações de maneiras compreensíveis e legais / práticas.
Agora que todo mundo está fazendo SPAs e é quase bobo tentar convencer os negócios de que devemos nos preocupar com pessoas que executam sem JS (a acessibilidade agora pode, supostamente, ser tratada com conteúdo gerado por JS), parece que a próxima geração de desenvolvedores de JS se importa menos sobre isso, mas a IMO, ainda há uma vitória por lá e é principalmente para você, o desenvolvedor, escrevendo e mantendo essas coisas. E, realmente, essa vitória sempre deve ter sido o ponto mais sublinhado, mas nunca foi por algum motivo, porque finalmente beneficia você e também o produto por um acidente feliz, devido à facilidade de ajustar / modificar / depurar.
Está tudo bem?
Bem, sim, eu acho. Em um aplicativo descartável descartável para um concurso ou algo assim, talvez. Mas eu ainda faria isso apenas porque tenho o hábito disso e não é realmente difícil de fazer.