Depois de uma longa espera, cá estamos nós novamente com mais uma edição do CodeCast! Dessa vez o assunto é Frameworks. Com a presença do Jader Rubini, falamos de tudo um pouco sobre PHP, Ruby, Python e JavaScript, e seus respectivos CakePHP, Rails, Django, jQuery e Mootools. Um bate papo bem interessante pra quem ainda não adotou alguma dessas ferramentas ou semelhantes.

Pesando 39MB, ultrapassando a marca dos 55 minutos, esperamos que gostem, enviem feedback, sigam nossas dicas, enfim. Também gostaria de agradecer muito ao Jader por aceitar nosso convite, que além de tudo rendeu um bate papo muito legal, do chimarrão ao pão de queijo, de Mootools a Django.

Até mais!

Posts Relacionados

• CodeCast #4 – Adobe Flash
• CodeCast #1 – Impressões sobre Início de Carreira
• Frameworks: Por um PHP Menos Ruim
• CodeCast #2 – XHTML 2 e HTML 5
• CodeCast #3 – Semântica e Microformatos

Ninguém está livre de um desastre. A qualquer momento seu HD pode queimar, seus arquivos podem ser infectados por algum vírus, algum raio pode cair em cima de seu computador, ou até mesmo o seu servidor de hospedagem pode explodir (pergunta, vai!). Esse é o tipo de coisa que ninguém espera, e não há como dizer “hoje vou perder todos meus arquivos, é bom fazer uma cópia”. O destino é cruel e impiedoso, principalmente com os descuidados.

A maneira mais eficaz, e também mais sensata, é sempre manter um backup de seus dados importantes. É bom sempre fazer isso com uma certa regularidade. Backups diários podem ser custosos e até impraticáveis em certos casos, então realizá-lo uma vez por semana já parece suficiente. Por pior que seja a catástrofe, você sempre terá para onde correr.

Mantendo cópias regulares, com certeza em pouco tempo você terá uma quantidade enorme de dados armazenados. Aí o jeito é organizar! Manter uma lista dos arquivos copiados, data de gravação, enfim. Não adianta TER os dados e não saber onde encontrá-los. Pode acreditar, essa sensação é ainda pior.

Por que esse texto estilo sermão? Eu explico. Semana retrasada, uma explosão no data center H1 do The Planet derrubou uma montanha de servidores (e três paredes, segundo me consta), e eu estava em um deles. Antes que eu ficasse sabendo de mais informações, se abateu o pânico: eu não tinha um backup. Por sorte não houve perda de dados, mas já foi o suficiente para abrir o olho, e ser um pouco mais cauteloso. Nem mesmo armazenados remotamente nossos dados estão seguros.

Um pequeno esforço que pode salvar muito retrabalho, e até sua vida, dependendo de quão dependente ela seja de seu trabalho. E você, mantém um backup? Nem que seja mensal, apenas de trabalhos correntes, ou o que quer que seja importante para você guardar?

Posts Relacionados

• PC formatado, e agora?
• Tragédia
• A Aplicação Ajax Perfeita
• Comodismo vs. Inovação
• 7 coisas que todo desenvolvedor web deveria saber

Linguagens de programação e frameworks de desenvolvimento surgem aos montes no ambiente web. De uma maneira ou outra, nossas velhas ferramentas acabam se tornando obsoletas. Por mais que tenhamos domínio sobre elas, o rendimento não se equipara a novas ferramentas, seja em produtividade, desempenho, facilidade de uso ou qualquer outro fator. Será que é hora de abandonar nossa velha forma de desenvolver para dar lugar a novas ferramentas?

As ferramentas com as quais estamos acostumados, como o PHP, por exemplo, foram criadas para resolver os problemas que tínhamos à época em que foram criadas, baseando-se nos métodos dessa época. Elas têm nos servido muito bem, e provavelmente ainda poderão servir por algum tempo mais. Mas a web muda, e as exigências quanto ao desenvolvimento nesse ambiente também. Não basta mais resolver um problema, esse problema deve ser resolvido de forma rápida e eficiente. Com a correria de hoje em dia, só PHP não basta mais.

Com o tempo, além de recriamos soluções para velhos problemas, novos problemas vão surgindo. A web não é mais um ambiente minúsculo como era há alguns anos atrás. Ela cresceu. Cresceu muito. A demanda por serviços, e por serviços cada vez mais rápidos é muito maior do que antes. Criamos novos problemas e precisamos de soluções para eles. Nossas antigas ferramentas não estão preparadas para tanto.

De uma forma ou outra, precisamos ser ágeis. Os frameworks estão aí para ficar. Como o capitalismo nos obriga a produzir em velocidade insalubre, somente uma boa linguagem de programação também não basta. Precisamos ser rápidos, muito, muito rápidos. Mesmo para linguagens não tão recentes, já existem soluções ótimas. Há vida além do Rails e Django!

Embora essas novas tecnologias sejam fascinantes, há um pequeno problema. Uma nova ferramenta leva a uma curva de aprendizado. Isso toma tempo, “tempo de processamento”, enfim, nos tirar de nossa zona de conforto. A questão é: devo eu partir pra outra? A minha resposta é: depende.

Tudo é relativo, e não há uma resposta pronta para esse tipo de pergunta. Você pode se sentir realmente confortável com certa linguagem, e conseguir ser extremamente produtivo com ela, ao passo que, mesmo conhecendo bem outras ferramentas, não consegue manter o mesmo ritmo. Nesse caso, sempre existem os frameworks. Não é necessário “reaprender a programar”, e ganha-se o benefício de um desenvolvimento mais rápido. Nesse caso, mudar de ares não é algo sensato a se fazer, principalmente se você tem um tempo escasso.

Já se você consegue ser produtivo em várias linguagens, opte por aquela mais moderna e robusta, ou continue buscando algo novo. Assim tem-se o benefício da versatilidade: não importa a ferramenta, importa saber fazer.

Meu caso é um pouco diferente. Apesar de trabalhar diariamente com PHP, nunca gostei da linguagem. Parece-me mais uma biblioteca de funções do que uma linguagem bem estruturada. Quando fui apresentado ao Ruby, me rendi. Apesar de não ter me aventurado muito ainda, é o que pretendo seguir. Não tanto por produtividade, nem tanto por “moda”, mas por gosto. Não deixa de ser um motivo válido…

Tenho certeza que esse assunto dá uma boa discussão. Qual sua opinião? Fixar-se em uma ferramenta e especializar-se nela, ou procurar algo diferente que melhore sua forma de trabalhar?

Posts Relacionados

• 7 coisas que todo desenvolvedor web deveria saber
• Caindo na Real
• Vale a pena arriscar em novas tecnologias?
• Digg pra quê?
• Fim ou Recomeço?

Todo blogueiro que escreve em português sabe que seu blog dificilmente será lido por uma pessoa que não fale português. Não interessa quão bom seu post seja, em português ele nunca chegará muito longe no Digg.

Temos brasileiros no Digg, mas isso não chega a ajudar muita coisa. O Digg é muito útil se você quiser encontrar alguma coisa (em inglês, lógico, na maioria das vezes), mas não para mostrar o que você escreveu. Aliás, achar alguma coisa não, muita coisa, das quais você nem imaginava que existisse. Por exemplo, digite “javascript” na busca e veja tudo o que aparece.

Me cadastrei há pouco tempo no Digg (agora o tempo não anda tão apertado, e posso procurar alguma coisa nova), e indiquei dois posts. No dia seguinte, surgiu a idéia desse post filosófico, ajudado por outros posts que li ontem (eram vários, e não lembro nem de onde). Vi que não ia ter sucesso…

Temos alguns serviços muito bons no Brasil, e passarei a usa-los. Tá certo que alguns fazem algumas sacanagens com o usuário de vez em quando (leia-se Rec6), mas nada que seja muito prejudicial ao serviço.

A partir de agora, para indicar meus posts, estarei usando os seguintes serviços: Rec6, Eu Curti e Linkk. Estarei colocando os botões pra eles também assim que fizer o próximo remendo no tema.

Já estou cadastrado, e dei uma olhada nos serviços. Gostei, mas vi que não há muito conteúdo tão interessante quanto o Digg (não em quantidade, mas a qualidade é boa, brasileiro manda bem!). Minhas buscas continuarão sendo via escavação mesmo. Ahh, também recomendo aos blogueiros pequenos usarem os serviços também, pode atrair tráfego se o conteúdo for bom… E eu fico por aqui, até!

Posts Relacionados

• Pra quem você escreve?
• Qual curso devo fazer pra me tornar um desenvolvedor web?
• Caindo na Real
• Comodismo vs. Inovação
• Vale a pena arriscar em novas tecnologias?

Não que essa idéia fosse “a aplicação ajax perfeita”, mas sim a ideal. Demoraria muito a ser feita, mas eu consideraria uma obra de arte.

Padronização

Essa parte é a parte fácil, que todo mundo sempre deveria se dar ao trabalho de fazer: manter seu trabalho dentro dos web standards.

Validar sua marcação, seus CSSs, isso todo mundo faz (ou deveria). Mas às vezes um certo item é deixado de lado: seus XMLs, que não causariam muito problema, a não ser um XML em especial: os feeds. Ou seja, valide tudo que possa ser validado.

Manutenção

Código bom é código comentado. Disso ninguém discorda. Sempre comente seus códigos, tanto para seu uso em futuras manutenções e atualizaçãoes, quanto para seus visitantes que querem descobrir o segredo daquela técnica inovadora que você implementou. JavaScript ninguém esconde, e uma técnica nova deveria poder chegar a todos que quisessem, mesmo que seja investigando seu código. Melhor ainda se ele estiver comentado, mesmo que seja somente em partes mais obscuras.

E o tamanho do código não aumentaria? Sim, mas você só precisará comentar partes essenciais, aquelas mais complicadas que você sabe que irá esquecer com o tempo. Além do mais, se você esquecer de seu código, perderá muito tempo até lembrar o que cada parte faz.

Compatibilidade

Outra parte facílima, mas indispensável. Se tudo for seguido, nem tanto, mas ainda assim se torna muito mais agradável usar uma aplicação que funcione como deveria funcionar.

Com todas as opções de browsers existentes hoje, sempre haverá aquele que terá problemas (geralmente o azulzinho que todo mundo já conhece). Mas existem maneiras de amenizar o problema. Isso não só com Ajax, mas qualquer “defeito” de JavaScript e CSS que possa atrapalhar a experiência do usuário.

Essa parte pode, sem problemas, ser deixada para os frameworks já existentes, que fazem seu trabalho muito bem. A compatibilidade vem sendo muito focada por essas bibliotecas, facilitando, e muito, seu trabalho.

Controle de readyStates

Agora começa a parte divertida. Tudo que está logo acima qualquer um faz. Vamos começar adicionando nossos diferenciais.

Geralmente, costuma-se cuidar de apenas dois readyStates: 1 e 4 (aberto e carregado), que resultam no clássico “Carregando…” e a requisição completa. Não que seja necessário, mas um controle completo de estados poderia ser bom.

O usuário saber que sua requisição está sendo processada ajuda, já que não pensaria que a requisição travou (isso acontece bastante quando a requisição demora demais).

Coloquei os readyStates, o que significam e uma sugestão para o texto de carregamento. Os readyStates 0 e 4 não precisam disso, já que 0 não tem muito uso, e 4 terá sua própria função.

• Não Inicializado (0)
• Aberto (1): “Abrindo Requisição” ou “Iniciando Requisição”
• Enviado (2): “Enviando Dados”
• Recebendo (3): “Carregando” ou “Recebendo Dados”
• Completo (4)

Não que seja necessário, mas também seria válido cuidar dos status da requisição também, pelo menos 200 (OK), 404, 500, e os outros erros mais comuns.

Histórico

Esse é o maior problema das aplicações Ajax. Já faz tempo que as primeiras soluções para histórico apareceram, e outras melhoradas, e ainda há centenas de aplicações que não se dão ao trabalho de implementar qualquer das soluções.

O histórico sempre deve ser implementado, mesmo que sua aplicação não queira dominar o mundo.

Cache

O cache, considerado uma praga por muitos, pode ser de uma grande ajuda para sua aplicação. Sempre que se faz uma requisição estática (que não muda em pouco tempo), deve-se usar o cache, pois quando refizermos essa requisição, ela terminará mais rápido.

Além do mais, usando o histórico, podemos guardar requisições “cacheadas” no próprio JavaScript. Assim, mais rápido ainda.

É claro que, em requisições dinâmicas, não devemos usar essa técnica. Ela pode prejudicar o usuário, pois não há maneira de atualizar a página através do F5.

Filas de Requisição

Todos sabem que se quando uma requisição estiver em andamento, e outra for iniciada, a primeira será cancelada.

Assim como o histórico, já existem milhares de soluções diferentes para fila de requisições. Esse recurso deve também ser usado sempre que possível (ou seja, sempre). Isso pode evitar aborrecimentos ao usuário.

Inobstrusividade

Essa é a questão mais polêmica. Sua aplicação não deve usar JavaScript obstrusivo (ou usar o menos possível), fazendo-a de maneira que funcione corretamente em qualquer browser.

E o Ajax sem JavaScript, como fica? Também tive idéias mirabolantes quanto a isso. Você deve usar o mesmo script server-side tanto para requisições assíncronas (Ajax) quanto para as síncronas (me refiro àquelas via browser). Para isso, usamos aquele header X-Requested-With, que seu server-side deve identificar.

Dessa maneira, não “trancamos” o conteúdo nem ao usuário nem aos buscadores e afins. Benefícios ao usuário e a você (e ao seu bolso, se for o caso).

Lembre-se de tornar o conteúdo Ajax-less atrativo aos olhos do usuário também, usando o mesmo layout do resto da aplicação (ou a mesma estrutura, caso seja XML).

Desempenho

O desempenho é outra característica muito essencial. Em tráfego de dados muito grande, devemos tomar cuidado com o JavaScript. Muito XML gera muitas chamadas ao DOM, e isso leva tempo. Aí o JSON entra em cena.

O Profiler do Firebug pode ser muito útil, já que ele monitora o tempo de execução da sua aplicação e das requisições que ela faz.

Bem, é isso. Quem sabe um dia veremos uma aplicação destas. Estou trabalhando em uma função que faça boa parte disso, espero que consiga terminar. Fui!

Posts Relacionados

• Hijax: Ajax Acessível
• Ajax vs. Acessibilidade
• Fila de Requisições em Ajax
• Ajax vs. Moda vs. Performance
• Ajax: Requisições HEAD

Avançando um pouco mais no tutorial, resolvi começar uma aplicação de teste, seguindo aquilo que eu já havia aprendido. A coisa mais sem graça que poderia existir, acreditem. Por quê? Não tem aquela emoção, sabe…

Você não precisa criar arquivos (o Rails faz boa parte do trabalho a partir dos geradores), até o momento não vi uma única linha de SQL (é possível usar, segundo o tutorial, mas ainda não vi necessidade), todas as operações no banco de dados são extremamente simples, não precisei nem especificar URLs para os arquivos. Por isso não tem graça, o Rails faz tudo sozinho! Eu quase nem programei!

Agora, falando sério. Gostei do Rails, gostei mesmo. Um framework muito bem pensado e bem feito, tudo automatizado, pouca configuração. Até a programação quase não existe pra fazer coisas mais simples (como minha apliteste). Feito para Ruby, o Rails permite a você se concentrar na parte criativa da programação, e cuida do trabalho pesado. Com apenas algumas horas de trabalho já tenho uma aplicação quase pronta (pra testes, claro), incluindo o layout, que pode ser desenvolvido ao mesmo tempo que a programação sem problemas, pelo menos para mim.

Amigos programadores, recomendo uma olhada no Rails. Dê uma chance a ele, e você vai dizer “Como não experimentei isso antes?”. Palavra de alguém que nunca pensou em abandonar o PHP, até porque pra abandonar uma coisa você tem que se aplicar nela, o que não foi o meu caso.

Observação: tenho um conhecimento mínimo de Rails, e resolvi compartilhar minhas primeiras impressões. Se falei alguma bobagem, me desculpem, e se possível avise nos comentários.

Posts Relacionados

• Não validou. E agora?
• Diz que até não é … um mau blog
• Backup: Um Salvador de Vidas
• Comodismo vs. Inovação
• CodeCast #5 – Frameworks

Existe muita coisa interessante na área de client-side pra se aprender hoje em dia. O problema é que algumas tecnologias só funcionam em softwares específicos, o que nos faz pensar se realmente vale a pena.

E aí? Avançar, e aprender alguma coisa diferente, ou estagnar, e se especializar no que já se domina? Isso é uma questão de gosto, e também de filosofia.

Na minha opinião, baseada na vida inteira que tenho pela frente, aprender novas tecnologias, mas que caminham para um certo padrão, como SVG, que já consta no W3C, pode ser muito útil, e trazer resultados no mínimo interessantes.

Mas também sou um entusiasta, e tenho admiração por muita coisa presente no Firefox (e algumas coisas do Opera): XUL, E4X, Canvas… Tecnologias pouco difundidas, relativamente recentes e, sem dúvida, muito poderosas para seus objetivos.

O problema é que algumas dessas tecnologias são quase-específicas, e aprendê-las restringe um pouco nosso campo de trabalho (em partes, já que será teremos um item a mais no currículo). Não acredita? Experimente morar em uma cidade atrasada, em que o pessoal pensa que Ajax é uma nova tecnologia da Macromedia (acreditem, ouvi essa pérola de um “desenvolvedor” Flash daqui). Isso quem já ouviu falar de Ajax, que é um número muito reduzido. Ninguém acredita em seu trabalho porque pra eles isso não existe. Novas tecnologias, principalmente as mais desconhecidas por quem compra nossos serviços, podem acarretar esse tipo de problema. A menos que você trabalhe com quem entende do assunto, e entende que você domina uma tecnologia com enorme potencial.

A solução que encontrei pra mim, que tenho um tempo livre considerável, é conciliar as duas coisas: especializar-se no que já existe e é conhecido (JavaScript e Ajax, no meu caso) na maior parte do tempo, e sempre que possível dar uma espiadinha em coisas novas. Não estou dizendo para virar um especialista em XUL, nem um guru em E4X, mas saber no mínimo o basicão, e com o tempo ir aumentando o conhecimento. Esse tipo de tecnologia é bastante promissor, embora talvez demore muito pra estourar. Já vi exemplos impressionantes usando JavaScript + XUL + SVG + Ajax, mas aí caímos na limitação do software.

Uma coisa que você deve ter em mente: isso se aplica apenas as linguagens client-side, que são interpretadas, e podem ter comportamentos diferentes (ou mesmo nem ter comportamento em alguns casos) em cada software. Em outros lados a coisa funciona de maneira um pouco diferente.

Tudo é uma questão de saber definir as prioridades, e dosar o novo e o velho. Adicionar alguns diferenciais em seu currículo nunca será ruim. E você, mantém-se atualizado, ou só especializa-se no que já conhece?

Voltei a falar sobre novas técnicas, sob uma óptica diferente, em Comodismo vs. Inovação.

Posts Relacionados

• Comodismo vs. Inovação
• E a tal da Web 2.0?
• Ajax Online Inovando de Novo
• Caindo na Real
• Digg pra quê?

Vou falar do pouco que sei sobre a aplicação real da
POO. O melhor lugar pra se implementar a POO são os objetos DOM, pois eles já tem uma classe criada, e o JavaScript nos permite extendê-la.
Vamos ao primeiro exemplo: um menu expansível. Normalmente, usamos algo próximo disso:

menu.onclick = function() { toggle($("menu"); }

Descontando a parte obstrusiva, nada parece errado, e na verdade não está. Toda vez que clicamos no menu, ele executa a função toggle, que executaria outra função para saber se o menu estava expandido ou não (geralmente uma verificação na classe CSS). Mas podemos melhorar.

Consideremos tudo como um objeto. Nesse caso, o menu seria um objeto. Portanto, ele precisa de uma função construtora para podermos cria-lo. Precisaremos dos seguintes atributos e métodos:

• element: o elemento DOM que representa o menu.
• contracted: atributo booleano, indica se o menu está contraído ou não.
• toggle(): nossa querida função que irá contrair e expandir o menu.

Poderíamos adicionar expand() e contract(), mas vamos resumir. Vejamos a função construtora:

function Menu(element) {
  this.element = element;
  this.element.onclick = function() { this.toggle(); }; // obstrusivo, dá um desconto né?
  this.element.className = "contract-menu"; // já escondemos o menu
  this.contracted = true; // e indicamos que ele está escondido
  this.toggle = function() {
    if(this.contracted === true) {
	  this.element.className = "expand-menu";
	  this.contracted = false;
	}
    else {
	  this.element.className = "contract-menu";
	  this.contracted = true;
	}
  }
}

Peraí, não aumentamos o tamanho de código? Sim, mas a maravilha é exatamente essa. Você precisará desse código apenas uma vez, e alguns caracteres criam vários e vários menus com as mesmas propriedades. Um var menu = new Menu($("elemento")) resolve tudo. E também poderíamos reutilizar o código fazendo sub-menus, ou adicionando novos métodos em tempo de execução, caso sejam necessários. Interessante, não?

A implementação em objetos DOM é extremamente simples. Tudo que utilizar um estado (variáveis de instância) pode partir pra orientação a objeto. Agora vamos para algo menos visível.

Uma requisição em Ajax tem variáveis de instância. Também muito simples depois que se pega a essência da coisa. Vejamos a função construtora:

function Ajax(url /*, options*/) { // simples, sem opções por agora
  this.url = url;
  var requestResponses = reqAjax(this.url); // variável privada
  // a função acima já usa POO, não vamos nos preocupar com ela dessa vez
  // ela retorna { responseText, responseXML, errors }
  this.getResponseText = function() {
    if(typeof requestResponses.errors != "undefined") this.throw(requestResponses.errors);
    else return requestResponses.responseText;
  }
  this.getResponseXML = function() {
    if(typeof requestResponses.errors != "undefined") this.throw(requestResponses.errors);
    else return requestResponses.responseXML;
  }
  this.throw = function(errors) {
    if(typeof errors == "undefined") return requestResponses.errors;
	else throw("Requisição retornou erros: " + errors);
  }
}

Só uma função extremamente simplória e não muito útil. Só pra fazer uma demonstração (estava tentando pensar em algo mais elaborado, mas fugiu da mente). Realmente deseja um desafio? Tente criar a função reqAjax com tudo que ela tem direito. Um quebra-cabeça, literalmente.

Quer mais? Bom, então recomendo ler um pouco sobre Ruby. Sim, é server-side, não tem nada a ver, mas a orientação a objeto é realmente interessante. Extremamente recomendado.

Eu até queria postar mais alguns exemplos, mas só vieram a mente coisas muito grandes, e não ando com tempo pra isso. Podem deixar sugestões nos comentários, aí eu volto e edito o post. Fui!

Posts Relacionados

• Controle de Erros em JS
• Caindo na Real
• Estendendo Objetos DOM
• Lançada a Mootools 1.2
• Fila de Requisições em Ajax

Quer construir uma aplicação web de sucesso? Então é hora de Cair na Real. Caindo na Real é o menor, mais rápido e melhor caminho para construir software.

Mudei meu jeito de pensar. A coisa faz sentido, apesar da consciência pesar pro outro lado (acho que faz parte do instinto). A primeira coisa que será mudada será o FrameWorX.
Há muito a ser repensado. A primeira coisa que fiz foi a visão:

Mais funcional, menos adicional

Explicação: sempre achei os frameworks existentes grandes demais. Não que seja tudo supérfluo, mas grande parte deles não se adaptam a nossa realidade (sim, o JavaScript no Brasil está atrasado comparando-se com lá fora). Veja o Dojo, é um framework gigantesco, tão grande que pode ser usado até fora do browser (isso deve ser legal!). Achei que precisava de alguma coisa que pudesse ser 100% usada. Não encontrei, tudo que achei era pequeno demais (só DOM, só Ajax, só isso, só aquilo). Ou faltava ou sobrava.
Quando comecei o FrameWorX, tinha isso em mente. Mas confesso: a vontade de ser maior que a concorrência (que concorrência? Mas queria ser maior) se apoderou do meu ser. Não faz mal, esse sentimento às vezes ajuda a gente a aprender mais. Aí o objetivo inicial foi por água abaixo. Até que li o GR. Mudei o escopo, mudei o estilo, enfim.
O projeto está paralisado por uns dois ou três dias, até que eu decida o que fica e o que sai, o que entra e o que não vai entrar. Aí passarei às próximas etapas.
Caí na real. Desenvolver menos e melhor. Menos é mais. Convido você a cair na real também. Vale a pena, e será muito bom. Até!

Posts Relacionados

• POO na Vida Real
• Vale a pena arriscar em novas tecnologias?
• Digg pra quê?
• Comodismo vs. Inovação
• Yoomp – Primeiras Impressões

Continuo defendendo aquele meu velho ponto de vista, mas desta vez vou ampliar um pouco minha “visão da coisa”.

Impor o Firefox como browser a ser escolhido pelo seu cliente é suicídio. Nem tente. No máximo uma sugestão. Mas aí surge um problema: se 80% dos internautas usam Internet Explorer, vale a pena usar os padrões? Já voltamos aí.

Por mais que seu ego diga “Valida logo!”, seu cliente diz “Termina Logo!”. No caso, IE, gambiarra, hack, defeito, dor de cabeça… Se você desenvolve primeiro no Firefox, há uma grande possibilidade de tudo estar validadinho. Se você desenvolve primeiro no IE, nem vou falar.

E aí, já decidiu? Crie tudo primeiro para o Firefox. Quando tudo estiver direitinho, faça as alterações, gambiarras, hacks, comentários condicionais… Vai tudo estar pronto antes (por mais que não pareça), e você satisfez seu ego (isso é bom, né?) e seu cliente (que vai estar feliz por funcionar 100% no IE e por você ter entregue na hora). Além disso, sua impressora fica livre de ter que imprimir alguns currículos…

E a pergunta de sempre: Validar ou não? Sim, sempre que possível (nem sempre há tempo). Não perca seu emprego por um bug do seu código ou do W3C, siga feliz!

Posts Relacionados

• ClientSide: Mostre seu Código!
• Não validou. E agora?
• Vale a pena arriscar em novas tecnologias?
• DIVless
• Caindo na Real