JulioGreff.net

O Internet Explorer 6 é culpa nossa!

2009-07-06T11:20:24Z

Não há nada que um desenvolvedor web odeie mais do que o Internet Explorer 6. Por mais que desejemos, parece que ele não vai embora. Entretanto, e por incrível que pareça, a permanência do Internet Explorer 6 no mercado é culpa nossa!

Logo que o IE7 foi lançado em 2006, parecia algo lógico manter a compatibilidade com o IE6 por algum tempo, por mais doloroso que isso fosse. Usuários comuns mal sabem diferenciar entre um browser e o Google, atualizar para o IE7 nos primeiros dias seria pedir demais. O estranho é que, até hoje, quase 3 anos depois, muitos de nós continuam a dar suporte ao browser. Perdemos tempo, paciência e alguns anos de vida corrigindo bugs e assegurando que tudo funcione relativamente bem. Isso significa que nivelamos nosso desenvolvimento por baixo, deixando de usar coisas como PNGs transparentes, muitos seletores CSS e scripts mais eficientes, só para começar a listar alguns. Algo está errado aí, você não acha?

Mas se o browser é usado pelo usuário, como isso pode ser culpa nossa? Simples: enquanto tudo funcionar, o usuário não fará o menor esforço para atualizar seu software. O usuário é acomodado (pra não dizer ignorante). É preciso tomar atitudes para que ele se atente que seu software está muito ultrapassado, e essa atitude cabe a nós. Por pressão dos clientes e dos nossos superiores, o máximo que conseguimos foram barrinhas sutis no topo da página que, convenhamos, não servem para nada mais do que decoração e alívo de consciência. Será preciso muito mais que isso.

Até que as coisas deixem de funcionar, o usuário não fará nada. Fato. Em um mundo ideal, os sites de maior tráfego não dariam mais suporte a browsers legados, e a evolução começaria a acontecer. Como não vivemos em um mundo ideal, precisamos dar o nosso jeito. Educar o cliente, os parentes, os amigos, pode até parecer legal, mas é numa escala muito pequena. Em meus projetos pessoais, coisas como a singela tela acima começarão a aparecer. Como freelancer, o suporte ao IE6 terá seu preço (e as telas de aviso serão um pouco mais educadas). Na agência onde trabalho ainda enfrento alguns problemas, mas na maioria dos projetos o IE6 é completamente ignorado, e simpáticas telas explicando como atualizar o browser estão sendo implementadas.

Não existe mais motivo algum para a existência do IE6. Não deveriam mais existir motivos para mantermos a compatibilidade. Eu seria um profissional muito mais feliz se, em 2010, eu nunca mais ouça falar em Internet Explorer 6. Acredito que esse seja o desejo de muitos, e espero que ele consiga ser realizado dessa vez. Vamos fazer nossa parte e acabar com o monstro que criamos?

Novatec – 20% de desconto!

2009-04-15T12:01:02Z

Recentemente fui contatado pela Editora Novatec para participar do programa de afiliados deles. Tenho certeza que vou demorar um bom tempo pra receber qualquer coisa que seja, mas há um lado bom: eles me ofereceram um código promocional, com 20% de desconto.

O esquema funciona assim: você compra qualquer livro do catálogo da Novatec e, na hora de fechar o pedido, entra com o código promocional JULIOGREFF. Você ganha um bom desconto, e eu uns trocados.

Caso você queira comprar algum livro, mas ainda não tem idéia do que, aí vão alguns que podem valer a compra:

Expressões Regulares – Uma Abordagem Divertida (2a Edição), do Aurélio
Extreme Programming, do Vinícius Manhães Teles
jQuery – A Biblioteca do Programador JavaScript, do Maujor
Ruby on Rails, do Rodrigo Urubatan

Se você precisava de (mais algum) incentivo pra comprar um livro, esse é um. Tá esperando o que?

Fórum do Spaghetti*

2009-04-30T15:04:03Z

O Spaghetti*, desde o dia de seu lançamento, precisava de um fórum. Muita gente pediu, implorou, alguns até mandaram cartas ameaçando a nós, nossa família e nossos repositórios por aí. Só que o que nem todos sabiam é que estávamos construindo uma solução há um bom tempo, mas por motivos diversos ela demorou muito mais do que esperávamos. Mas, como somos pessoas muito legais, resolvemos terminar isso de uma vez, e foi lançado o Fórum do Spaghetti*, finalmente.

Como dito no nosso blog, queríamos algo que compartilhasse da filosofia do framework: simplicidade e descomplicação. Por isso, descartamos IPB, SMF, phpBB, entre outras sugestões, e construímos nosso próprio sistema. Como qualquer um pode notar, ele ainda não está completo, mas aos poucos estamos trabalhando nisso. Queremos um produto de qualidade!

Esperamos que o fórum ajude a tirar as principais dúvidas do Spaghetti*, e a alavancar o crescimento da comunidade, conectando desenvolvedores e se tornando uma boa fonte de informações para os que estiverem chegando. E você, já se cadastrou lá? Esperamos você!

Spaghetti* Framework Lançado!

2009-01-03T16:06:16Z

O ano de 2009 chegou, e com ele trouxemos junto o Spaghetti* Framework 0.1, a primeira versão do nosso framework para PHP. Exatamente na virada do ano, o site do Spaghetti* foi liberado, assim como downloads, documentação, screencasts e tutoriais. E você, já deu uma passada por lá?

Recepção

Antes de tudo, gostaria de agradecer muito a recepção que o Spaghetti* já vem tendo. Em apenas 3 dias de vida, já recebemos vários elogios, agradecimentos, twittadas e sugestões (críticas são muito bem aceitas, estamos esperando elas também!). Vários downloads foram feitos, os screencasts estão gastando uma banda considerável, e pelo jeito o pessoal anda gostando. Se você também gostou (ou não gostou), nos deixe saber! É só entrar em contato direto com a gente.

Documentação

Pelo menos para mim, uma documentação razoável é um dos fatores chave para a adoção de uma nova ferramenta. Por isso, trabalhamos bastante em cima dessa parte, e o resultado é uma documentação que cobre boa parte do que o Spaghetti* faz. Gostamos tanto do resultado que até fizemos um PDF para download. Quem me segue no Twitter deve ter notado o quanto falamos dessa documentação.

Além da própria documentação, fomos um pouco mais longe, e também já temos alguns screencasts e tutoriais, especialmente para o pessoal que já quer ver alguma coisa funcionando antes de colocar a mão na massa. Já estou devendo um screencast meu, abordando outros aspectos do framework, deve sair em breve. Ou pelo menos assim espero.

O que já está por aí

O Spaghetti* não foi criado em um laboratório fechado, baseado em hipóteses e teorias. Construímos ele em aplicações já em produção. Já existem vários projetos prontos, funcionando, com versões alfa e beta do Spaghetti*. Além disso, o Rafael também criou uma aplicação super legal, uma lista de tarefas. Toda a aplicação feita em menos de duas horas de trabalho. Divirta-se!

E o que vem por aí

Não estamos parados, e já estamos trabalhando para a próxima versão, programada para primeiro de maio, se tudo der certo. Fomos amadurecendo ainda mais a idéia, e vimos que muito ainda falta no Spaghetti*. Você deve ter sentido falta de suporte a vários bancos de dados, validação, além de vários outros detalhes no próprio core, helpers e componentes. Você pode nos acompanhar pelo Trac, ou então pelo nosso Twitter. Sinta-se livre para se cadastrar no Trac, submeter tickets, anexar sugestões de código, e nos ajudar a melhorar nosso framework.

Espero que o nosso trabalho possa tornar o seu mais fácil e mais divertido. Também espero que você possa usar o Spaghetti* em seus projetos, e adoraria ouvir qualquer coisa sobre a experiência. Assim que alguém já estiver usando o framework em algum projeto internet afora, farei questão de dizer isso aqui ou mesmo no site do Spaghetti*. Até mais!

7 coisas que todo desenvolvedor web deveria saber

2008-12-06T00:24:04Z

Desenvolvimento Web é coisa séria, e evoluiu muito em termos de maturidade e complexidade. Para fazer frente ao crescente níveis de exigência, nós, desenvolvedores, devemos estar aprendendo a todo instante. Não importa qual campo você deseja seguir, seja ele no lado cliente ou servidor. Mas acredito que existam coisas que todo desenvolvedor web de verdade deveria saber.

Web Standards

Hoje em dia, o mínimo que se espera de um bom desenvolvedor web é o conhecimento dos Web Standards, XHTML e CSS. Eles contribuem para a criação de documentos mais consistentes entre si, mais compatíveis e de manutenção extremamente mais simples. Aliás, o conhecimento dos padrões não é mais um diferencial como era há alguns anos atrás, mas sim um requisito básico. Se hoje sonhamos com a web semântica, os padrões web são o primeiro passo. Com documentos mais semânticos, temos mais acessibilidade e também mais relevância, principalmente no que diz respeito a motores de busca.

Mesmo depois de muita evangelização, ainda temos desenvolvedores que acabam de descobrir as maravilhas do mundo validado. Também temos aqueles que não fazem a mínima idéia do que isso signifique, ou que não tem o mínimo interesse em aprender. Se você é um desses, hora de rever seus conceitos…

JavaScript

O JavaScript, apesar de ter sido muito injustiçado no passado, é uma linguagem onipresente, e de extrema importância. Qualquer usuário tem pelo menos um interpretador instalado em seu computador. Além do mais, ela é a única linguagem client-side disponível, e permanecerá assim por um bom tempo.

JavaScript vai ser a próxima grande linguagem. Apesar de ainda estarmos longe de resultados surpreendentes, caminhamos rápido nesse sentido. Muita coisa que antigamente só era possível com Flash hoje é feita com JavaScript.

Além da própria linguagem, aprenda a usar alguma biblioteca, como Mootools, jQuery ou Prototype. Aliado a essas ferramentas, você poderá criar aplicações muito mais interessantes em muito menos tempo. Mas atenção: não aprenda somente a biblioteca, sem aprender antes JavaScript puro. Afinal, saber só jQuery é coisa de designer.

Expressões Regulares

Um simples replace nem sempre é suficiente quando trabalhamos com manipulação de textos. Aí entram as Expressões Regulares, poderosa ferramenta que todos conhecem, alguns usam, e poucos realmente sabem. Seja em PHP, Ruby, Python ou mesmo JavaScript, algum dia você precisará delas.

Se você leva desenvolvimento a sério, dedique um tempo a aprender expressões regulares (Expressões Regulares – Uma Abordagem Divertida é um bom começo!). Além de uma ferramenta de desenvolvimento, elas podem se tornar ferramentas de produtividade. Se você usa IDEs com suporte a busca e substituição com expressões regulares, pode se beneficiar muito disso.

Controle de Versão

Para alguns, o Controle de Versão mudou completamente, e para a melhor, a forma de trabalhar. Para outros, parece simplesmente inútil, principalmente para quem trabalha sozinho. Seja CVS, SVN, GIT, Mercurial ou qualquer outro, o controle de versão, aliado a ferramentas como o Trac, pode fazer maravilhas. Além de manter controle de suas alterações, podendo sempre voltar atrás caso alguma modificação dê errado ou mesmo quando o cliente não aprova, você pode manter um controle de sua produtividade, analisando quantos commits foram feitos em quanto tempo, quantos tickets foram fechados, quantos ainda permanecem pendentes.

Desde que passei a utilizar SVN em alguns projetos, como no próprio Spaghetti, notei uma grande melhora no controle sobre o código. Nunca mais pensei duas vezes em apagar grandes blocos de código pensando que eles poderiam ser úteis outra vez (e geralmente nunca seriam realmente necessários). Uma excelente forma de analisar seu progresso, uma excelente forma de backup, uma excelente forma de manter seu código sincronizado. Esqueça aquele colega que tem uma versão ultrapassada de seu código e sobrescreve partes importantes. Quando passei a utilizar ferramentas de tracking, bugs não eram esquecidos, idéias estavam sempre à mão. Digo, como muitos por aí: isso realmente mudou a minha maneira de desenvolver.

MVC

O Model-View-Controller, ou MVC para os íntimos, nunca fez tanto sentido quanto na web. Depois do Ruby on Rails, virou quase um requisito básico para o desenvolvimento de bons projetos. E desde então, desenvolver não tem mais graça. Além disso, a separação de aplicações nessas 3 camadas torna o desenvolvimento e manutenção muito mais simples.

Se você não quer ficar para trás, adote seu framework. O pattern é usado na maioria deles, e de brinde você ganha muita produtividade. Frameworks tornam as linguagens menos ruins. Se você usa PHP, eu sugeriria o Spaghetti. Se você usa Ruby ou Python, e é seu primeiro contato com frameworks, siga a tendência e adote Rails ou Django. Se você é corajoso, faça como fizemos na minha agência: crie seu próprio framework. Usando algum framework ou não, o que importa é pegar o espírito da coisa.

SQL

Mesmo com toda a flexibilidade e abstração da camada de dados que os frameworks MVC nos oferecem, SQL ainda é necessário. Apesar de você não vê-lo, ele ainda está lá. Consultas complexas ou mais específicas nem sempre são disponibilizadas pelos frameworks, e sempre pode haver a necessidade de uma incursão via terminal, para tarefas de manutenção, por exemplo.

Talvez você não acredite no retorno que isso pode trazer. Até ter nas mãos uma aplicação gigante e extremamente dependente de banco de dados, onde as consultas devem ser otimizadas ao máximo para minimizar a carga do servidor. Você não quer sua aplicação baleiando por você não saber SQL, quer?

Desenvolvimento Guiado a Testes

Test Driven Development, ou simplesmente TDD, é, na minha opinião, a melhor maneira de manter seu código livre de bugs. Fazer o desenvolvimento guiado a testes significa desenvolver o teste antes da funcionalidade. A cada iteração, os testes são rodados novamente, de maneira automática, e você sempre saberá se alguma modificação quebrou o restante do código.

Sem testes automatizados, aplicações nunca são testadas como deveriam. São tarefas repetitivas e cansativas. Com o auxílio de ferramentas de testes, eles podem ser rodados várias vezes, certificando de que tudo está correndo bem. Se um novo bug é descoberto, um novo teste é criado, as modificações são feitas, e você terá a certeza de que o problema foi resolvido para todo o sempre, sem quebrar o restante da aplicação. E convenhamos, não há nada pior do que bugs…

Não é obrigatório que um desenvolvedor saiba tudo isso, embora eu considere extremamente importante, mesmo alguns não sendo necessários todos os dias, todos podem melhorar nossa maneira de trabalhar. Ainda não domino todos os itens citados, mas tenho um bom conhecimento em todos eles. O que importa mesmo é buscar isso, e sempre continuar aprendendo. Mexa-se! Você não quer ficar para trás, quer?

Hello, Good to be Back!

2008-11-06T17:22:37Z

Dois meses, e nada de postagens. Sou um blogueiro um tanto relapso, admito. Cuidar do trabalho, escola, vestibular e ainda manter a sanidade mental não é uma tarefa fácil, e certas coisas acabam ficando para trás por um tempo. O blog, infelizmente, foi uma delas. Felizmente, trago algumas novidades.

O blog está em novo domínio: JulioGreff.net. Se você está lendo esse post pelo feed, tudo já está transferido, graças ao FeedBurner. O novo domínio agora é hospedado na DreamHost. Ou seja: adeus problemas com banda e disco excedentes. Isso significa que mais novidades estão por vir. Sabem que eu adoro screencasts? Aproveitando a mudança, também fiz algumas pequenas modificações no tema do WordPress, agora um pouco mais limpo do que antes.

Nesse tempo que fiquei fora, dediquei bastante tempo a outro projeto com o Rafael Marin, na CodeBrasil: o Spaghetti. O Spaghetti é um framework MVC para pequenas e médias aplicações, ainda está em desenvolvimento e beirando o lançamento, programado para no máximo 30 de dezembro. Esse projeto diminuiu um pouco meus desentendimentos com o PHP, e estou tomando mais um pouco de gosto pela linguagem. Caso deseje, você pode fazer o checkout do Spaghetti através do SVN. Sinta-se a vontade para testá-lo, submeter bugs e sugestões, e nos ajudar no desenvolvimento.

Também estou participando do Blogging Idol 2, do Daily Blog Tips. Isso significa que estarei mais dedicado ao blog pelo menos até 30 de novembro. Tenho metas grandes (embora ganhar não seja uma delas), e acredito que será proveitoso tanto para mim quanto para você, leitor. Se você ainda não assina o feed principal e gostaria de me ajudar, assine agora! Se você já é assinante, convide seus conhecidos desenvolvedores a conhecerem o blog. Eu agradeço, e você também ganha com conteúdo de qualidade.

Agradeço a todos que me contataram nesse afastamento, com dúvidas, agradecimentos e pedidos de postagens, e que aguardaram minha resposta (sim, demorou…). Também agradeço a todos que assinam o feed ou lêem o blog, nunca imaginei que chegaria a quase 300 pessoas. Meu sincero muito obrigado. Espero poder satisfazer as expectativas, e postar mais regularmente. Até breve, pessoal!

Interfaces de Usuário com JavaScript

2008-11-24T20:14:32Z

A web vai se tornando uma plataforma cada vez mais próximas das aplicações desktop que temos. Temos várias aplicações por aí para provar isso. Mas aos olhos do usuário, uma aplicação só com XHTML+CSS às vezes pode não ser tão interessante. De uns tempos pra cá, entretanto, várias bibliotecas surgiram para acabar com esse problema, e trazer interfaces de usuários realmente interessantes. Preparado para algo fora de série?

O número dessas bibliotecas é incontável, algumas mais simples, outras mais complexas, outras mais famosas, algumas nem tanto. Fiz uma breve pesquisa, e trouxe as mais conhecidas (e algumas nem tanto) para quem ainda não teve a oportunidade de conhecer. Só para lembrar, hoje não vou tratar sobre o uso dessas bibliotecas, isso fica pra uma próxima oportunidade, já que a idéia é um pouco extensa.

ExtJS

A ExtJS é de longe a biblioteca mais conhecida. Provavelmente você já deve ter pelo menos ouvido falar sobre, a menos que você viva na Sibéria. Também acredito que deva ser uma das mais antigas, e por isso uma das mais completas também.

Seu visual é espetacular, mas tem seu preço: ela é muito lenta. Todos os efeitos de transparência, os drag ‘n’ drops, tudo isso exige muito do pobre navegador. Pense bem antes de escolher onde usá-la, faça somente se for necessário, nunca para simples “enfeites”. Lenta, mas uma obra de arte.

E os desenvolvedores AIR não precisam ficar tristes: há até um demo do bichinho em funcionamento. Ainda não tive muito tempo com o AIR, mas acredito que a questão da velocidade não seja tão crítica quanto em um navegador, quem puder falar sobre, agradeço.

Yahoo User Interface

A Yahoo User Interface, ou YUI, deve ser a primeira user interface a se popularizar. Foi a base do nascimento da ExtJS. Tem lá seus defeitos, como o prefixo YUI para todos os métodos, mas tem um poder imenso. Me parece ser bem mais leve que a Ext, e usa gráficos bem mais simples também.

A documentação é um dos pontos fortes. Mantida pela comunidade de desenvolvedores do Yahoo, você nunca estará sozinho. Apesar disso, achei o site um pouco confuso para encontrar alguma coisa, principalmente os demos. Mas o material está lá, e há muito…

MochaUI

Ainda beta, a MochaUI seria a minha preferida. Adivinhem por quê? Sim, baseada na Mootools… A demonstração realmente me deixou impressionado, talvez tenha sido o relógio.

Aparenta ser bem leve, tanto que na demonstração você pode modificar propriedades das janelas sem travar o navegador. Usa gráficos simples, mas não menos atraentes. De longe, seria a primeira que eu escolheria para trabalhar (sim, opinião extremamente parcial). Mal posso esperar pela versão 1.0!

Dijit

Falando em Dojo, nem é preciso dizer muito. O framework mais abrangente que conheço também conta com sua interface de usuário, o Dijit. Não consegui encontrar demonstrações no site, mas as imagens mostram algo realmente promissor.

Lendo a descrição do projeto, você verá que o Dijit não é apenas uma simples interface de usuário. É extremamente customizável, extensível, acessível e localizável. O que isso significa? Bem, dê asas à imaginação, o céu é o limite…

jQuery UI

O jQuery UI, bem jovem ainda, também é espetacular. Baseado na brilhante jQuery, tem tudo para deixar qualquer um de boca aberta. A demonstração de efeitos, por exemplo, me impressionou muito. A própria tela de demonstrações é uma obra de arte.

Apesar de baseada no jQuery, achei a biblioteca ligeiramente lenta. Talvez tenha sido impressão, mas não esperava isso de jQuery. Entretanto, pela sua idade, é muito madura, muito poderosa. Se jQuery não havia me chamado atenção ainda…

Prototype UI

Até então desconhecido pra mim, o release candidate Prototype UI não conseguiu me chamar a atenção. Não por ser baseado em Prototype e Scriptaculous (o que já considero um ponto contra), nem por usar um tema do Mac, mas por parecer muito prematura. Os demos apresentados são bonitinhos, mas um tanto “crus”. Prefiro não dar minha opinião, vai que o negócio vire um Ext-killer?

SproutCore

O SproutCore, iniciativa da Apple, tem uma proposta um tanto “utópica”, pelo que entendi é trazer o Cocoa para a web. As demonstrações são interessantes, mas o pobre navegador sofreu as conseqüências. Esse negócio consegue ser mais pesado que a própria Ext! Além disso, vi mais opiniões negativas do que positivas…

UIZE

O UIZE (pronuncia-se “you eyes”) é outro que nunca havia sido apresentado a mim. Concordo com o pessoal do Ajaxian: são os efeitos mais legais que já vi. Apesar disso, a biblioteca ainda necessita muito mais trabalho, já que tem poucos recursos (poucos, mas legais).

Não tive a oportunidade de trabalhar por algum tempo com nenhuma dessas bibliotecas, e nem falar muito sobre as quais tenho mais experiência. Somente uma breve opinião sobre cada uma. Caso tenha esquecido de alguma, por favor, cite-a nos comentários, terei prazer em falar um pouquinho. Só uma precaução: cuidado onde você irá usar tudo isso… Existem aplicações e aplicações. Até mais!

Mootools vs. jQuery

2008-10-28T19:30:12Z

A batalha final: Mootools versus jQuery. Quem será o vencedor dessa sangrenta batalha? Tudo bem, sem violência então. Como mais novo usuário de jQuery e ainda usuário de Mootools, tive a idéia de fazer apenas uma breve comparação com as duas bibliotecas, nada de luta…

Antes de tudo, nem pensem os usuários de Mootools que sou um traidor, um subversor, nem os usuários de jQuery achem que sou um “fiel convertido” e abandonarei a Mootools para todo o sempre. Ambos dois lados de acordo e em paz, vamos à comparação.

Propósito

A primeira coisa que me fez dar uma segunda chance ao jQuery foi minha maturidade adquirida de uns tempos pra cá. Pude perceber que jQuery e Mootools têm propósitos diferentes. Pode-se usá-las para a mesma coisa, mas mais código terá que ser escrito.

A Mootools é uma biblioteca bem mais complexa e mais completa. Seu escopo é bem maior, e permite muito mais coisas. Algumas dessas coisas são a criação de classes, vários métodos para os tipos nativos da linguagem (funções para Strings, Números, Arrays), JSON, cookies, e tudo o mais que você puder imaginar através de plugins. É bem mais voltada a “programação de verdade”, ou seja, trabalhar mais com a linguagem e processamento do que seu resultado no documento.

A jQuery tem um escopo muito mais fechado: DOM. Criação e edição de objetos, seletores muito poderosos e simples, baseados em CSS e XPath e manipulação de eventos. Tudo isso integrado dentro de uma mesma função. Indo um pouco mais além, a biblioteca também inclui a criação de efeitos básicos e requisições Ajax. Ainda dentro do cifrão bombado.

DOM

Tanto Mootools quanto jQuery lutam nesse campo: DOM. Ambas também possuem a mesma função $, que vem me confundindo muito quando trabalho com uma ou outra biblioteca. Na Mootools, somente IDs. no jQuery, qualquer seletor CSS3 ou XPath. Não que a Mootools não tenha todos os seletores que jQuery, mas em uma função diferente: $$. Particularmente gostei separação, mas a versatilidade da jQuery absolutamente não me incomoda. Nessa parte, pra mim é um empate.

Ainda não tive a oportunidade de inspecionar o código da jQuery, mas posso dizer que o John Resig é um gênio: além de recuperar elementos do documento, o $ ainda os cria. E não através da criação manual de elementos e nós de texto. Você digita o HTML, e a função os cria sozinha. Adeus innerHTML… Na Mootools? Bem, acho melhor pular essa parte, vocês já devem ter percebido… jQuery na cabeça.

Quanto às outras funções, como definição e recuperação de atributos, ambas bibliotecas não deixam a desejar. A jQuery, entretanto, tem o diferencial de usar a mesma função para definição de uma ou várias propriedades, além de recuperá-las. Na Mootools, temos o get e set. Pra mim não faz diferença alguma em termos de desenvolvimento, ambas são intuitivas. Empate novamente.

No final das contas, jQuery é excepcional em tarefas de DOM, e supera, e muito, a Mootools, até por ser seu “habitat natural”.

Ajax

Ajax é outra frente de batalha em que as duas bibliotecas se enfrentam. jQuery conta com métodos extremamente simples para a tarefa, muito bons para requisições simples em aplicações pouco exigentes em relação a requisições assíncronas. Já a Mootools conta com uma classe bem mais trabalhada, mais extensa e mais flexível, principalmente para eventos.

Mesmo trabalhando com, as duas bibliotecas não o fazem para o mesmo propósito na minha opinião. A jQuery me parece melhor para requisições simples: enviar a requisição e fazer alguma coisa com a resposta. Já a Mootools trabalha com os aspectos mais “sórdidos”, como as mudanças de estado, headers, enfim. Até prefiro não falar muito sobre jQuery aqui pois não tive muito tempo com Ajax, posso ainda não ter visto algumas funcionalidades.

Efeitos

Existe algo que deixe uma aplicação mais interessante do que coisas se mexendo? Eu acho que não, mas esse não é o caso. Na jQuery, temos poucos efeitos built-in, mas me parece ser bem extensível. Já a Mootools tem uma gama enorme de transições, e podemos escolher qualquer propriedade do CSS para animar, e o melhor: ainda contamos com uma maneira muito fácil de criar novas transições. Mas a Mootools, principalmente nessa nova versão, peca em manter esses efeitos fáceis de aplicar. No jQuery, só um fadeIn ou fadeOut e presto, temos um efeito. No entanto, por mais chato que seja, ainda fico com a Mootools…

Plugins

Quando só a biblioteca sozinha não dá conta, hora de chamar os plugins. Ambas bibliotecas são extremamente extensíveis, cada uma a sua maneira. Na Mootools através da extensão das classes, no jQuery através de um “mecanismo” muito interessante, que “gruda” suas funções na função jQuery.

Mesmo sendo um fã da programação orientada a objetos e da maneira como a Mootools o usa, gostei muito mais da maneira como o jQuery faz a inclusão de plugins. Eles realmente passam a fazer parte da biblioteca. Vitória do jQuery, embora no final das contas não faça diferença alguma…

Facilidade de Uso

Nenhuma das bibliotecas tem um uso complicado. Além disso, ambas tem um foco diferente.

Talvez você já tenha notado, mas a maioria dos designers e programadores JavaScript menos experientes preferem jQuery. Não é à toa, ela é extremamente simples de ser usada. Nunca ouviu dizer que jQuery é para designers? Isso também não significa que usuários mais experientes ou experts na linguagem não irão gostar ou conseguir trabalhar.

Já a Mootools, como diz o próprio site, é direcionada a usuários intermediários ou avançados. À primeira vista ela é realmente mais complicada, sem dúvida. Talvez por isso não chame tanto a atenção quanto jQuery.

E o vencedor é…

Como disse logo no início do texto, jQuery e Mootools são bibliotecas diferentes, servindo para propósitos diferentes. Não é possível compará-las em sua totalidade, por isso não falei sobre muitos recursos que a Mootools oferece e jQuery não tem (built-in, é claro). jQuery é para DOM, Mootools é para facilitar sua programação. Já imaginou ambas bibliotecas juntas? Enfim, tenha bom senso e saiba utilizar as bibliotecas onde elas se dão bem, e não seja cabeça-dura como eu era tentando usar a Mootools em qualquer situação…

jQuery – Segundas Impressões

2008-10-28T19:29:44Z

Por algum motivo de natureza desconhecida, nunca gostei muito de jQuery. Talvez eu não tenha gostado muito do $ pau-pra-toda-obra, ou então da excessiva facilidade que a biblioteca propõe. Por alguma outra razão também desconhecida, há alguns dias atrás resolvi dar uma segunda olhada na biblioteca-prodígio. Se tem tanta gente usando, algo de bom deve ter.

Durante os Testes

Depois alguns minutos testando a biblioteca direto no Firebug, tive a mesma impressão do que na última vez em que a usei: cada função, cada método faz no mínimo umas três coisas diferentes. Definir um atributo, recuperar seu valor, definir vários atributos ao mesmo tempo e ainda pode servir um cafezinho. Talvez esse tenha sido um dos motivos para me afastar da biblioteca. A diferença é que de uns tempos pra cá venho aumentando bastante minha maturidade na programação, e vi que esse conceito pode servir muito bem. Ponto pro jQuery.

Outra característica que não me agradou muito na primeira experiência com jQuery é o retorno da função $: ela sempre retorna um objeto jQuery, e não o objeto DOM que eu escolhi. Isso, na época, me incomodou muito. E se, na pressa, eu quiser jogar um innerHTML e não quiser me preocupar com criar e injetar nós? Mais uma estupidez minha, o método html cuida de tudo isso, e nunca mais vou precisar me preocupar em criar nós… Além do mais, acabei descobrindo que não estender objetos nativos é bem melhor em questões de performance. Mais um ponto pro cifrão polivalente.

Durante a Produção

Hora de passar para a prática. Como qualquer outra nova ferramenta, é complicado usar jQuery quando se está acostumado à Mootools. Estou me atrapalhando bastante, principalmente na hora de usar os seletores. Já cansei de usar $$, esquecer o # antes de IDs, trocar nomes de métodos, enfim. Tudo normal, eu pego o jeito…

Esquecendo a questão da produtividade em período de adaptação, fiquei bastante satisfeito com a biblioteca. No que ela se propõe a fazer, é simplesmente fenomenal, algo fora de série. Versátil, simples e poderosa. Gostei muito dos métodos relacionados a Ajax que, para qualquer requisição simples, são úteis e otimizados ao extremo em termos de código.

E a escolha?

Gostei de jQuery, muito. Acredite, se você nunca usou, não sabe o que está perdendo, e se já usou e não gostou antes de testar mais aprofundadamente, não seja cabeça-dura como eu e dê outra chance. John Resig, o criador da jQuery, com certeza sabia o que estava fazendo, até porque ele é o cara!

Mas e a Mootools, onde fica nessa história? Não vou abandoná-la, ainda é minha biblioteca preferida. Ela é imbatível em características que o jQuery não tem. Ambos servem para propósitos diferentes. Não vou “escolher” alguma das duas, o ideal é unir o potencial de ambas, não sou xiita.

Essa experiência serviu para me mostrar que uma ferramenta não pode resolver todos os seus problemas de maneira eficiente, mas podemos unir várias ferramentas para resolver vários problemas da melhor maneira possível. Aguardem os próximos capítulos dessa história…

Scroller Made in Mootools

2008-10-31T19:23:08Z

Mesmo a Mootools sendo a biblioteca perfeita (pra mim, pelo menos), algumas vezes é preciso de uma pequena ajudinha externa. Exemplo de hoje: scrollers! Nada mais fácil do que fazer um deles exclusivamente com Mootools, mas é meio chato ter que criar os controladores (ou setinhas) e saber quem é o anterior ou o próximo.

Como acabei precisando de um scroller assim, aproveitei e criei uma classe que poderei reutilizar em algum outro projeto em que ela se faça necessária. Já que gostei do resultado, vou aproveitar e deixar o script pra vocês. O resultado será algo parecido com esse exemplo. Prontos? Então vamos lá!

O Código

O script não poderia ser mais simples, em torno de umas 50 linhas de código (você precisaria de centenas se não fosse a Mootools, ou alguma outra biblioteca que faça o serviço sujo). Você pode fazer o download dele aqui. Para “instalá-lo”, basta incluí-lo em seu documento, assim como a Mootools. Além disso, você também vai precisar do plugin Fx.Scroll, que pode ser conseguido no More Builder da Mootools, e incluí-lo no seu documento também.

Update: logo que precisei usar a classe novamente, vi que cometi um erro grotesco. Código atualizado, com erro corrigido e uma nova funcionalidade, explicada logo abaixo. Valendo uma mariola pra quem descobrir minha estupidez, os dois códigos estão disponíveis para download.

O HTML

O HTML necessário é a parte que eu considero a mais complicada, chata e sem graça. Sem o HTML criado direitinho, o scroller não vai funcionar. A lógica é a seguinte: precisamos de um container (geralmente uma div) de uma largura (ou altura) fixa. Esse container é quem vai esconder os itens que não serão mostrados no scroller. Dentro desse container, vamos precisar de mais um container (geralmente mais uma div, ou então uma lista), também de altura/largura fixa, mas que seja igual a toda a extensão dos itens. Ou seja, o container de dentro será maior do que o container de fora.

<div id="container">
    <div></div>
</div>

Acredite, é mais complicado do que parece. Agora sim, podemos colocar nossos itens dentro do container que está dentro de outro container (hein?). Fora isso, precisamos apenas de mais dois elementos (podem ser links) para serem os handlers de anterior e próximo e pronto, aí está o HTML. Só precisamos do CSS que vai ajudar na mágica do script.

O CSS

Como o nosso container externo precisa esconder o que há no container interno (que é maior), ele precisará de um overflow: hidden. Sem isso, tudo o que há no container interno ficará exposto, e aí o scroller perde a graça. Também não podemos nos esquecer de definir as alturas/larguras dos containers e itens. Vamos fazer primeiro um scroller vertical, ligeiramente mais fácil:

* {
  margin: 0;
  padding: 0;
}
#container {
  height: 20px;
  overflow: hidden;
  width: 100px;
}
#container div {
  /* Não é necessário definir a altura, o elemento irá "crescer" sozinho */
  width: 100px;
}
#container p {
  /* A mesma altura de #container, mas isso pode variar com o gosto do freguês */
  height: 20px;
}

O Script

Agora sim, vamos colocar a mão na massa. Minha classe, quando instanciada, leva apenas dois parâmetros: o container exterior (o container interior é deduzível…) e as opções. Dentre elas, temos à disposição todas as opções da classe Fx, e também previousButton e nextButton, que são os handlers para o elemento anterior e posterior do scroller.

var myScroller = new Fx.Scroller("container", { previousButton: "previous", nextButton: "next" })

Aproveitando a atualização da classe, também criei vergonha na cara e adicionei os eventos onNext e onPrevious, executados quando o scroller vai para frente ou para trás, respectivamente.

Pronto! Você escreveu apenas uma linha de script e seu scroller já está funcional, passando de um elemento para outro com apenas um clique!

Scrollers Horizontais

A termos de script, um scroller horizontal é idêntico. A mágica se esconde toda no CSS para este caso. Primeiro precisamos colocar os elementos um ao lado do outro dentro do container interior, certo? Certo. Para isso, usamos a propriedade float, sinta-se à vontade para escolher a qual lado flutuar.

Passando ao segundo passo, devemos definir a largura. A fórmula é a seguinte: número de elementos vezes a largura de qualquer um deles. Se você usar margins ou paddings, não esqueça de levá-los em consideração também.

Usando a técnica de scrollers horizontais, também podemos criar scrollers “mistos”. Nesse caso, há várias linhas e várias colunas de itens ao mesmo tempo. O efeito, se bem usado, pode ficar muito interessante. Quem teve a oportunidade de observar os demos da versão 1.1 da Mootools deve saber do que estou falando.

Dicas para Ir Além

Bem, só fazer itens se mexerem pode não ter tanta graça assim pra você. Como eu disse, minha classe usa todas as opções da classe Fx, ou seja, eventos, transições, offsets, enfim. Agora é sua vez de brincar! Use o offset para mudar a posição dos itens, eventos para mudar sua opacidade, criatividade! Também sinta-se livre para usar os métodos da classe também: next, previous, scrollTo, enable e disable (para ativar ou desativar os botões).

Espero que isso sirva pra alguma coisa! E também espero postar em um intervalo um pouco menor… O pessoal deve ter pensado que eu fugi do país depois de uma certa polêmica. Mas não, só estive ocupado mesmo… Até mais!