Podemos insultar Ballmer por este colapso nervoso meio insano, mas sua mensagem acertou em cheio. Se você não fornecer aos desenvolvedores as ferramentas e o conhecimento de que precisam para trabalhar com seu sistema, eles não apenas terão dificuldades, mas também não poderão desenvolver aquilo em que você está trabalhando!



Infelizmente, na prática, vemos que, a esse respeito, os próprios desenvolvedores podem ser seus piores inimigos. Eles escolhem "estruturas" terríveis que os fazem trabalhar mais arduamente ao invés de mais inteligentes, ou eles deliberadamente ostentam sua ignorância dos fundamentos e copiam o código de outra pessoa na esperança de que ele cumpra a tarefa necessária.



Em nenhuma outra área isso é mais óbvio do que em uma atitude arrogante, indiferente, senão totalmente desdenhosa em relação ao HTML. Não há limite para infinitas declarações sem sentido e errôneas de quem não consegue escrever uma única linha neste idioma.



Resumindo, os desenvolvedores não levam o HTML a sério o suficiente, mas o que acontece se você apontar sua fraqueza para eles? Em resposta, vamos apenas esperar por um fluxo interminável de desculpas sem sentido sobre por que eles não deveriam ser distraídos por sua implementação correta!

Lista de desculpas fracas

"HTML não é uma linguagem de programação real"

É uma sequência de comandos que os computadores seguem para completar uma tarefa. Se existe outra definição de linguagem de programação, então em quatro décadas escrevendo software, eu não a ouvi. A partir de Turing está completa? Não ... mas, no entanto, diz ao computador como transmitir o significado gramatical e estrutural do conteúdo de uma forma independente da máquina. Existem regras para usar suas tags, ordem e sintaxe.

"Ninguém se preocupa com o código se ele parece correto para o usuário."

Exatamente até o momento em que você encontrar usuários cegos. HTML não é apenas a aparência da página ... Não! Eu vou consertar - HTML não tem nada a ver com a aparência de alguma coisa. O HTML é necessário para comunicar o que os elementos devem ser em termos de gramática e estrutura para que o agente do usuário possa transmitir esse valor ao usuário. Então temos CSS para descrever como os elementos devem olhar . Se alguma de suas tags, ids ou classes comunicar como os elementos deveriam ser, então você escolheu o código errado com base nas suposições erradas.



Leitores de tela (software para ler uma página em voz alta), e-books em Braille, TTYs ... todos esses são alvos não visuais; e não se esqueça de que os motores de busca também não têm olhos. Eles nem se importam com a "aparência" da sua página.



Além disso, é importante para as pessoas que sua página seja mais lenta ou mais cara para hospedar, ou que viole as diretrizes de acessibilidade para pessoas com deficiência, ou que obstrua todo o canal disponível. Marcação não semântica , DIVs infinitos e sem sentido que não fazem nada, aulas de apresentação - todos eles se somam e afetam o resultado!



Você ouvirá as mesmas desculpas para muitos outros aspectos do desenvolvimento web, e quase sempre é uma mentira. Quer se trate de semântica ruim / quebrada, problemas de acessibilidade para pessoas com deficiência, JS opcional inchado, uso de tecnologias de "aplicativo da web" para coisas que não deveriam ser um aplicativo, etc., etc.



Muitas vezes, ao usar tudo isso, o usuário percebe que algo está errado, mas não consegue explicar. Os usuários não são programadores, não sabem qual é o erro e de quem é a culpa, mas sentem que algo está errado, tudo está aleatório.



E o próximo infeliz perdedor que tem que apoiar o resultado do seu trabalho, que contém todos os erros da lista, como NÃO usar HTML? As pessoas estão sempre conversando sobre como sua terrível "estrutura" quebrada deveria "nos ajudar a trabalhar juntos". Como pode duas ou dez vezes a quantidade de código que não está em conformidade com as regras básicas do HTML e viola o próprio propósito da linguagem, pode "melhorar a colaboração"?

"Mas os exemplos em estruturas funcionam exatamente assim e foram escritos por especialistas"

Eles não são especialistas em desenvolvimento web. Em vez disso, eles são especialistas em marketing, propaganda e engano. A marcação em exemplos de sistemas como Bootstrap e Tailwind são práticas de HTML pesadelo. Eles cheiram a uma mistura horrível de “Não quero aprender HTML e CSS” e “Sinto falta da marcação dos anos 1990”, desistindo de mais de vinte anos de progresso. Só porque eles são usados ​​por milhões de sites ("a maioria não pode estar errada"), e especialistas autoproclamados cantam elogios a eles (apelam à autoridade), não os torna ou práticas semelhantes boas.

"O código Vanilla é mais difícil de trabalhar."

Você torna isso difícil. Aqui está o problema: ao ignorar as regras semânticas de estruturação e todo o propósito do HTML, você torna mais difícil trabalhar com ele. Contribuindo para isso está o fato de que as iscas noob como W3Schools (também conhecidas como W3fools) estão transbordando de informações imprecisas, simplificações vulgares e a completa ausência da maioria dos conceitos básicos de HTML.



O conteúdo deve definir a marcação, conteúdo + marcação + ambiente de destino / recursos do agente do usuário devem definir a estrutura. Seguindo a semântica básica e melhorando gradualmente e usando a separação correta de funcionalidade, você acabará com um conjunto de instruções que tornam mais fácil criar páginas de fácil manutenção. Se você está tendo problemas com isso e acha que esses "frameworks HTML / CSS" estão tornando sua vida mais fácil, então você não conhece HTML ou CSS suficiente para fazer qualquer uma das tarefas.



Em geral, o Tailwind é mais simples do que o HTML / CSS básico, você só precisa aprender mais de 500 classes, 90% das quais já existem como propriedades CSS, e então ignorar quase todas as regras de como o HTML deve ser usado!



Caso você não tenha entendido, foi sarcasmo.

"Você dá muita importância ao HTML"

Eu ouço essa bobagem o tempo todo, e fico incomodado com sua miopia!



É como dizer que presto muita atenção ao solo sob o canteiro de obras ou aos materiais usados ​​para fazer a fundação. Se você negligenciar esses detalhes, então não se surpreenda que então tudo desmoronará de uma "forma incompreensível" ou será sugado para um ralo cársico!



HTML é a base e a pedra angular. Se você negligenciar isso, não se surpreenda se os resultados serão um desastre completo.



Na verdade, muitos dos equívocos que os desenvolvedores da Web usam para se convencerem a não se preocupar com o futuro não são diferentes daqueles que levam a todos os desastres de engenharia. Economizando na qualidade, ignorando especificações ou o usuário final, alimentando seu próprio ego; além disso, muitos cometem um erro fatal - eles confundem arte com design.



Este último erro leva a edifícios que deslumbram as pessoas com a luz do sol refletida em suas janelas: alguém que se imagina um artista convence as pessoas fantasiadas a gastar bilhões em um projeto em que a forma é mais importante do que a função.

"Mas o HTML não nos fornece as ferramentas de que precisamos para oferecer a experiência do usuário."

Existem muitas versões diferentes dessa desculpa, mas em geral elas implicam no que está acima. Aqueles que dizem isso quase sempre se referem a fãs de "aplicativos da web" ou "aplicativos de página única", tentam usar JavaScript em todos os lugares, não se importam com a acessibilidade para pessoas com deficiência e insistem que "usuários" de alguma forma "precisam" de todos suas coisas sofisticadas para melhorar a "experiência do usuário".



Mas, para ser totalmente honesto, esses palhaços sabem tanto sobre UX quanto os artistas que caíram na ilusão de serem "web designers" sabem sobre design.



E você pode ver os resultados de seu trabalho AGORA em toda a nossa indústria: soluções frágeis, inchadas e lentas que "podem melhorar o script" tornam os sistemas de carrinho de compras das lojas online tão lentos que muitas delas nem conseguem manter o tempo de atividade (olá Zotac) ; ao mesmo tempo, os usuários pressionam F5 com força, na esperança de poder comprar uma placa de vídeo. Por causa do recarregamento de toda a página e da nova execução do script, todas as funções do "aplicativo" apenas levam a uma REDUÇÃO da velocidade de carregamento da página. E isso é ainda mais pronunciado se você cuspir na marcação usando as classes de apresentação.



E como os scripts podem ser desativados e o conteúdo gerado por script é mais difícil para leitores de tela, e-books em Braille e assim por diante, os aplicativos de página única (SPA) violam as diretrizes de acessibilidade para pessoas com deficiências.



Não estou dizendo que o SPA e similares não tenham usos razoáveis, mas se você não pode criar um carrinho de compras simples ou um portal bancário de carregamento rápido que perde pouco com a desativação de scripts, então provavelmente não deveria estar fazendo nenhum trabalho. Nem estava é um negócio. Os aplicativos da web NÃO devem ser usados ​​para algo ridiculamente simples, como um carrinho de compras em um site!



E se você acha que usar scripts para fazer isso realmente melhora a experiência do usuário, então obviamente não testou o sistema com usuários reais e tráfego real! No mínimo, eles não realizaram uma comparação real da divisão de tarefas usando o cache em carregamentos de página normais e em páginas com scripts modernos.

Então o desenvolvedor web é o culpado por tudo?

De jeito nenhum . Vamos voltar ao início do artigo e aos gritos de Ballmer sobre "desenvolvedores, desenvolvedores, desenvolvedores".



Quando ele fez seu pequeno esboço, ele foi projetado para resolver o problema de que, no final dos anos 90, o Windows não era de forma alguma, porque os desenvolvedores muitas vezes não usavam as ferramentas fornecidas pela Microsoft. A Borland publicou a melhor documentação para a API do Windows. As pessoas estavam usando ferramentas que não eram da Microsoft porque as linguagens "visuais" eram consideradas brinquedos. Eles estavam tão atrás das tecnologias de desenvolvimento web que podemos dizer que ainda estão tentando alcançá-los!



O W3C e o WhatWG têm problemas semelhantes com os chamados"Especificações" simplesmente não são escritas para as pessoas que escrevem sites. Deixe-me repetir: a especificação da linguagem usada para escrever sites não é para as pessoas que realmente escrevem sites . Foi escrito para pessoas que escrevem user-agents! O navegador é o agente do usuário, mas o UA nem sempre é o navegador.



Na verdade, é tão absurdo que a versão idiota do "documento dinâmico" do WhatWG se refira ao MDN para "meros mortais" entenderem.



: , « » (living document), HTML- . HTML 5, , HTML 5, HTML 5 ? !



Fato simples: para obter descrições dos significados das tags em inglês simples, você precisa recorrer a fontes de terceiros, muitas das quais nem mesmo concordam umas com as outras. Além do mais, o W3C ficou completamente desdentado, concordando cegamente com tudo o que o WhatWG diz, embora o WhatWG tenha provado repetidamente que não está qualificado para criar um descendente do HTML 4 Strict. A aceitação do EMBED como tag válida, criando e / ou mantendo tags redundantes em relação ao OBJECT, não suportava mais (felizmente) a tag HGROUP, o que mostrava que eles nem mesmo entendiam para que serviam os cabeçalhos numerados e como usá-los. .. quem trabalhou nisso, o desafio para HTML 5 nunca foi realmente criar uma especificação ou padrão que nos diga como construir sites úteis!Tratava-se de documentar se as pessoas estão agindo certo ou errado hoje e que os navegadores podem apoiar, mas não o que deveriam apoiar! Dado que durante o desenvolvimento do HTML 5, a maioria dos desenvolvedores ainda estava martelando no HTML 3.2 e rabiscando o pervertido HTML 4 doctype sobre ele, por que se surpreender que tudo acabou sendo uma coleção de práticas ruins, desatualizadas e antiquadas?



Se os desenvolvedores não levam HTML a sério o suficiente, então aqueles que o desenvolveram como uma "especificação" são os culpados; até mesmo chamá-lo de HTML 5 era um crime tão sério contra o desenvolvimento web ... Assim como um crime contra a música foi dar um Grammy para Billie Eilish por suas criações medíocres.



O W3C e o WhatWG nem mesmo são levados a sério por outras organizações de padronização, e por um bom motivo.

Qual deve ser a solução?

Seria uma boa ideia começar fazendo com que os desenvolvedores não percebessem o HTML como um filho subdesenvolvido do mundo das linguagens de programação. Em particular, fazer com que eles pratiquem a marcação semântica, separando a apresentação do conteúdo, o que aumentará muito a usabilidade, acessibilidade e eficiência.



Além disso, nós mesmos, como desenvolvedores, temos uma palavra a dizer e confundimos o W3C pelo desastroso fracasso de seu trabalho como organismo de certificação . Precisamos exigir documentação em linguagem mais simples e limpa da fonte oficial. Não se pode justificar que um documento que descreve algo tão simples como HTML seja cinco a dez vezes maior do que as constituições da maioria dos países desenvolvidos.O próprio fato de a especificação da linguagem usada para construir sites não ter sido escrita para as pessoas que a usam para construir sites é um voto de desconfiança.



Mas precisamos mais do que apenas documentação oficial melhorada, precisamos reduzir a linguagem, torná-la mais orientada para as tarefas. Reviva muitas das ideias que estavam contidas no HTML 5 antes de o W3C jogá-las no lixo e adotar a versão WhatWG. O fato de a Microsoft ter passado décadas fazendo o IE nos impedir de usar OBJECT não é um motivo não apenas para manter a tag IMG, mas para adicionar muitas novas tags desnecessariamente (VÍDEO, ÁUDIO). Só porque "artistas" e vigaristas de marketing gostam de abrir novas janelas para o usuário, quer ele goste ou não, ainda não é um motivo para a especificação incluir TARGET="_BLANK"



...



Além disso, o uso EXPLICIT e os significados das tags devem ser colocados no centro da especificação , e talvez até mesmo em um guia de uso separado para aqueles que ainda viviam em 1997.



Fazer uma versão do HTML mais simples, mais limpa e mais útil que irá guiar a todos nós não é um grande negócio.



Além disso, será útil para nós se os desenvolvedores do navegador tiverem menos peso ao criá-lo. Microsoft, Mozilla, Apple e Google têm um grande impacto no W3C e no WhatWG, e isso é totalmente antiético. Seu peso na tomada de decisões vai contra o próprio conceito de uma web livre e aberta.

---

Propaganda

Os servidores da Epic são VDS para hospedar sites de uma pequena loja online na Opencart a projetos sérios com um grande público. Crie suas próprias configurações de servidor com apenas alguns cliques!



Participe do nosso chat do Telegram .