Perigos em gerar HTML

June 21st, 2005 § 9 comments

Em dez anos de trabalho com a Web, uma coisa eu aprendi: nunca confie em uma biblioteca para escrever HTML para você. Quando mais eu mexo nessa área, mais me convenço de que essa é uma boa regra. Qualquer biblioteca que esconda a geração da camada de apresentação por trás de funções ou componentes mais complexos tende a limitar as escolhas e tornar a otimização uma tarefa inglória — em muitos casos, impossível.

O problema com esse tipo de abstração é que ele tende a vazar mais facilmente, deixando o desenvolvedor em uma situação em que ele é obrigado a usar a abstração e intencionalmente quebrá-la toda vez que precisa de alguma coisa ligeiramente diferente.

O .NET, por exemplo, é especialmente doloroso nessa área. Criado com a intenção de eliminar completamente a necessidade de escrever HTML na mão, ele acaba complicando a vida dos programadores que precisam lidar com duas interfaces diferentes para atingir o objetivo de uma delas somente. O resultado é uma solução pela metade, de difícil manutenção e legibilidade, e com resultados imprevisíveis dependendo da plataforma em que está rodando.

Efetivamente, o que tais bibliotecas geralmente fazem é ignorar as decisões do programador, gerando código que pode ser comportar do jeito que o programador tencionava, mas que geralmente possui efeitos colaterais escondidos que podem causar problemas no futuro.

Isso é fatal quando os padrões Web entram na questão. Voltando ao .NET, um exemplo simples. O mesmo possui um objeto que replica a funcionalidade de uma painel da página. No Internet Explorer, o elemento é corretamente exibido como uma <div>. No Mozilla, o elemento sai como uma <table>, o que altera completamente a semântica da página, influenciando também folhas de estilo e scripts.

O que eu tenho buscado atualmente é um meio termo.

Quando eu estava começando a programar para a Web, o tedioso trabalho de criar os widgets necessários em uma página sempre me levava a criar o tipo de função nociva citado acima. Com o tempo, aprendendo que as mesmas mais atrapalhavam do que ajudavam, eu fui ao lado extremo, para mecanismos de template que simplesmente procuravam expor dados para a página, deixando toda a construção da mesma para o programador com algumas poucas funções para enumerar itens ou selecionar entre dois valores.

Com minhas recentes experiências no Rails, eu estou vendo esse meio termo em ação. O Rails oferece funções para gerar HTML, mas geralmente essas funções são tão simples e transparentes que não formam mais do que uma fina camada sobre a apresentação. Essa fina camada é flexível e não impede a fácil customização do resultado, gerando somente o que precisam gerar. Efetivamente, elas se convertem em uma ferramenta que economiza tempo nas tarefas simples sem impedir que tarefas mais complexas sejam realizadas.

O Rails, é claro, possui a sua fatia de erro, com algumas funções que só podem ser customizadas se substituídas por completo (errormessagesfor é uma que me vem à mente agora). Mas, em geral, ele faz a coisa certa.

O PHP mistura demais lógica e apresentação. O .NET presume separar, mas a ligação entre os dois é tão forte que é como se não houvesse separação. As várias bibliotecas para Java cometem os dois tipos de erro: misturam tudo ou unem tudo. O Rails atingiu um bom balanço dessa área, principalmente por causa do uso de MVC, mas precisa tomar cuidado agora com a introdução de Ajax nas bibliotecas primárias.

De qualquer forma, parece que as coisas estão começando a melhorar nessa área com mais e mais pessoas pensando em soluções para esse tipo de problema. Eu acredito que as novas safras de bibliotecas para a Web vão ser cada vez mais práticas nesse aspecto, sem perder a produtividade.

§ 9 Responses to Perigos em gerar HTML"

  • Ronaldo,

    Não tenho tempo de programador, e nem de Web, como vc, mas no pouco tempo que tenho na área(5 anos), pude ver um pouco de tudo que você comentou… já programei em ambientes onde o HTML era todo na mão e onde era todo “por funções”.
    Ultimamente tive algumas experiências que me deixaram bastante felizes:

    1) o “sistema de template” ADP do OpenAcs/AolServer é bem parecido com o Rails, funciona bem pra caramba e é bem extensível;
    2) A classe Flexy da PEAR do PHP é bem simples e ao mesmo tempo bem poderosa, chega a lembrar a TAL do Zope, mas com mais simplicidade;
    3) por último o Rails, que para mim foi um dos maiores avanços nessa área e que me deixou feliz em saber que as tecnologias para web estão cada ez mais perto do ideal.

    Assim como você, espero que em breve possamos ter algo mais “usável” sem ser tão sacal.

    Abraços

  • TaQ says:

    Eu ainda prefiro o uso do PHP “raw”, sem bibliotecas de auxílio, para gerar meu HTML. Pode dar um certo trabalho *ás vezes*, não é uma prática, ahn, bonita, mas certamente me dá o controle do que está sendo apresentado ali. :-)

  • No caso do Rails, o helper aonde achei a pior ‘amarração’ foi o stylesheet_link_tag, que seta a propriedade media=”screen”.

  • Ronaldo says:

    Rafael Ferreira, quando eu uso o PHP, eu tendo a usar o Smarty, que é um bom compromisso. Não é 100% ideal, mas previne muitos dos problemas de manutenção que podem aparecer com o uso do PHP puro. Já ouvi falar do Flexy, mas não vi código do mesmo. O TAL é interessante, mas eu não gosto muito da mistura de atributos que ele faz. Mas tem seus usos, principalmente quando usuários comuns vão fazer templates.

    TaQ, eu não vejo problemas em programadores experientes usarem PHP puro. Acho improdutivo, como eu disse, mas se a pessoa entende do negoćio, não vai sair nada ilegível. O problema são os outros programadores que podem vir depois. Disso é que eu tenho medo. :-)

    Rafael Rezende, esse é tosquinho mesmo. Alguns helpers do Rails são dureza. Acho que vem muito da herança do BaseCamp.

  • TaQ says:

    Improdutivo é questionável ehehe. :-)
    E é só deixar tudo documentadinho … e já vi alguns códigos onde houve troca de programadores e cada um instalava uma biblioteca diferente por que achava a anterior ruim. Aí, se não tiver documentação (tanto com código “raw” como com bibliotecas), a coisa complica … :-p

  • Ronaldo says:

    Por que é que eu esperava essa resposta? :-) Bem, eu me acho muito mais improdutivo, comparativamente falando, quando uso PHP puro ao invés de uma biblioteca como o Smarty. Mas também já vi código como você menciona e concordo que grande parte do problema está no programador.

    Porém, considerando a lei de Sturgeon, acho que isso não vai desaparecer tão cedo. Ergo, eu continuo com bibliotecas e Rails sempre que possível. Menos chances de dar tiros no pé. 😛

  • TaQ says:

    Digo o mesmo sobre o reply. 😉
    É, relegar código ao código somente não rola, tem que ver quem está fazendo. :-)
    “Ergo” -> não era o arquiteto da Matrix quem falava assim? Tá chique hein! 😀
    Ah, e minha espingarda está virada para outro lado … a única coisa que me incomoda no pé é uma unha semi-encravada. :-)

  • Ronaldo says:

    Hehehehe. :-) Como eu já dei muito tiro no pé, estou tentando manter a espingarda para o outro lado também agora.

    Sobre o “Ergo”, pode ser que o Arquiteto falava isso. Mas eu estou com essa mania agora. 😛

  • TaQ says:

    Se você começar a falar “concomitantemente” junto com “ergo”, eu saio correndo. :-)

What's this?

You are currently reading Perigos em gerar HTML at Superfície Reflexiva.

meta