Me recordo que há uns dois anos atrás mais ou menos, isto lá por meados de 2010/2011, os layouts eram simples e não ricos, e que os problemas de compatibilidade eram resolvidos com algum hack sem vergonha usando CSS ou então algum JS que o cara da outra sala falou. As vezes tenho saudades de tempo…mentira, tenho não.
O maior problema antigamente era a necessidade de colocarmos a página disposta em duas ou três colunas, sem contar o terrível fato de ter que fazer isso rodar mais ou menos no IE 6 e 7. E como dizem, a fila anda, e realmente andou …
Os problemas que temos agora, é uma explosão que vem pipocando a não muito tempo, que são os layouts responsivos para 2499193 navegadores para Desktops, 991931 de modelos de plataformas de dispositivos móveis e ainda o IE 7,8 e sei lá mais qual.
Se fizermos uma pequena comparação, ali por 2010/2011, a estrutura posicionar os elementos de um layout era bem pequena, ainda mais se fosse empregada a técnica ‘fuild’ onde o ‘witdh:90%;’ era uma bala de prata. Já hoje temos de cara a CSS3, que possui uma carada de recursos maneiros para atender a demanda atual, isso sem contar que a questão de responsividade é muito complexa, na boa, não é qualquer Cidão que coda um CSS para atender duas ou três plataformas, o cara tem que ser o cara, tecnicamente só trabalhar com isso.
A partir dessas tretas, a adoção de frameworks CSS/JS responsivos foi crescendo. Além dessas novas ferramentas, algumas já tradicionais também começaram a se “auto ajustar a si próprias”, como o caso da jQuery que adicionou suporte gradativamente as plataformas móveis.
Nesta cena ainda podemos destacar o lance dos componentes, que na minha visão foi uma grande sacada, logo porque os front-end frameworks já traziam consigo os seus próprios componentes ricos, como autocompletes, modais, validação, etc. Esta forma “embutida” deu uma quebrada em alguns caras clássicos como a própria jQuery.UI.
Ok, deixa eu voltar o assunto…
O framework em questão é a bola da vez, o Twitter bootstrap, os caras tomaram conta, literalmente.
Ao adotarmos um framework CSS/JS, tecnicamente acabamos com a centralização do conhecimento de um “guru” da equipe, logo porque basta a equipe dar uma lida na documentação do seu sistema de grid e componentes para que todos lindamente possam falar um mesmo idioma, programaticamente falando.
Uma segunda vantagem é que pelo alinhamento no conhecimento e desenvolvimento da equipe, para fazermos rodízio entre projetos distintos, apenas necessitamos alinhar o conhecimento na regra de negócio final, a parte técnica já está pronta.
Forks, clones, etc. não necessito do arquiteto ultra power plus para preparar um novo projeto (isso pode ter um pouco de discussão…), mas se você tem um produto que ele pode ser separado em partes como financeiro, loja-web, etc…e que estes tenham um comportamento meio que padrão, a equipe somente precisa novamente entender da regra de negócio : ).
Em breve, se a preguiça me permitir, quero fazer uma série de posts sobre o Twitter bootstrap.
Alternativas ao TB:
Abraços e até a próxima.