Criar um framework do zero ou adaptar um que já está pronto são estratégias diferentes para momentos diferentes dos projetos.
Os dois caminhos tem vantagens e desvantagens e é óbvio, por se tratar de algo que não será fácil voltar atrás, que o time deve pesar todos os pontos antes da decisão. Mudar de ideia no meio do caminho pode significar um grande trabalho de readaptação dos projetos e enforcamento do código legado.
Usando um framework já existente
Quando usamos como base um framework pronto (fizemos isso com o Locaweb Style usando Bootstrap), nosso trabalho é basicamente estender as funcionalidades já existentes, adaptando-as para as necessidades do seu projeto e tentando diminuir conflitos com o framework original. Já vi empresas que usaram o Bootstrap e não fizeram mudança alguma no design do framework ou no código. Isso é bom porque seu trabalho é quase nulo. No nosso projeto, precisávamos fazer mudanças de design e também estender comportamentos de alguns módulos. Há também a versão mobile, onde seria necessário adaptar elementos em diversos contextos de uso.
Criar um elemento de Collapse, Dropdown ou uma estrutura de GRIDS que funcionem de verdade é algo complexo. A grande vantagem de usar um framework pronto (como o Bootstrap ou o Foundation) é que os elementos com comportamentos complexos, que precisam de muito CSS e Javascript, já foram feitos e testados. Pensar em como e quais cenários estes elementos funcionarão não é o seu trabalho e sim de quem mantém o framework original. Isso é bom porque você pode se focar em coisas mais importantes como, por exemplo, a estratégia de implementação deste framework nos produtos, como o trabalho do back-end poderá ser afetado e como a equipe de UX pode ajudar no processo.
Nós optamos em usar o Bootstrap como base para o Locaweb Style ao invés de outras opções, como o Foundation, pois este era o framework CSS mais maduro no momento que iniciamos este trabalho.
Na época, o Foundation ainda se mostrava incompleto enquanto o código do Bootstrap era uma solução mais consolidada que contava com atualizações constantes, um roadmap interessante e uma comunidade mais ativa. O Foundation hoje, está mais estruturado e ganhou bastante espaço no mercado, está longe de ser uma opção ruim.
Usando um framework base
Escolher o framework base não é fácil. Existem algumas dicas interessantes que podem ajudar você a escolher um bom framework base para seu projeto:
Você precisa verificar a comunidade em volta desse projeto. Para evitar ficar na mão, dê preferência a uma comunidade mais ativa e com diversos colaboradores.
De quanto em quanto tempo os desenvolvedores desse framework atualizam a versão? Eles tem um roadmap? Você consegue se planejar levando em consideração o planejamento deles?
Quantidade de projetos que usam o framework
Tem muita gente usando? Você conhece algum projeto onde estejam usando esse framework?
Procure saber o que os desenvolvedores envolvidos no framework fazem além do framework. O Bootstrap, por exemplo, foi inicialmente criado para o Twitter e seus desenvolvedores são conhecidos no mundo todo.
Ou seja, seu código pode ser facilmente estendido e mantido por muito tempo? Se você quiser fazer novas funcionalidades, ele vai funcionar apropriadamente? Você pode adaptar e integrar módulos entre si? O Javascript dos módulos facilita sua vida para criar outros módulos ou adaptações?
Se você tiver que constantemente criar módulos para um framework é provável que ele não seja uma boa opção pois você estará praticamente fazendo um framework do zero. Em um framework com uma cartilha de elementos grande, você não precisa se preocupar em criar módulos básicos para as telas do seu produto.
Sistema de grid maduro
Ele aceita criar estruturas diferentes para contextos diferentes? O sistema de grids precisa ser robusto e customizável.
Os produtos que você vai desenvolver não devem ter seu framework alterado de um dia pro outro. Isto pode até acontecer mas esta decisão não deve ser feita pelo fato do framework deixar de ter atualizações. É muito importante que você tenha uma perspectiva que o framework não será descontinuado tão cedo.
Quanto mais perguntas você fizer no início, antes de escolher o framework, melhor será sua decisão e menor a chance de se arrepender.
Produzindo um framework do zero
Dizem que fazer um framework do zero não compensa… Nós não pensamos assim. Já ponderamos a ideia de largar o Bootstrap e produzirmos algo do zero, independente, muitas vezes. Desenvolver um framework próprio tem suas vantagens:
Quando o Bootstrap mudou para a versão 3.0, ele deixou de dar suporte a determinados browsers e o código estrutural de muitos módulos mudaram completamente. Várias classes essenciais para a manipulação e produção de elementos complexos também foram modificadas. Isso quer dizer que você vai precisar de um plano de migração. Se você não estiver fazendo um framework versionado, você vai ter um problema. Quando você faz algo do zero, este problema não existe.
Você cria exatamente e apenas aquilo que você vai usar. Os frameworks de mercado já prontos precisam se adaptar a qualquer tipo de situação e produzem código em excesso para prever situações hipotéticas de uso. É muito provável que você perceba que usa apenas uma pequena fatia desse código.
Em um framework feito por você, a quantidade de código criada é exatamente a que você vai usar. Não há código em excesso (claro, se a equipe for disciplinada) ou que nunca será usado. Isso é importante para que o framework não fique monstruoso.
Quando usamos um framework pronto, muitas vezes ele vem com uma camada simples de design. Esta camada, por mais simples que seja, não é a planejada pelo designer da equipe. Isso não é importante pelo designer ser chato e presunçoso mas porque a linha de identidade da empresa que você trabalha não é igual à identidade visual do framework.
Quando você usa um framework do zero, você tem liberdade de fazer o design que você quiser. Se você já usa um framework pronto, você precisa desconstruir com CSS algum determinado elemento para aplicar o design planejado. Você pode até fazer um acordo com o designer para que em alguns elementos simples o design não mudem tanto, isso ajuda bastante na quantidade de código e, consequentemente, na performance.
Essa decisão é totalmente estratégica. Depende do seu projeto, depende da sua equipe e não é uma decisão simples. É muito justo que você, antes de tomar esta decisão, pesquise como outras equipes e empresas como eles tem feito. Se você já tomou esta decisão, como tem feito? Comente.