Qual é a diferença no CodeKit e no Composer?
Desde que escrevi sobre CodeKit e Composer (mais sobre este último em posts recentes, na verdade), ocasionalmente recebo e-mails perguntando qual eu realmente prefiro usar quando se trata de trabalhar em projetos para outras pessoas.
E a resposta curta é que eles não são mutuamente exclusivos. Se alguma coisa, eles podem se complementar. Eles não são substitutos um do outro.
À medida que migrei de projetos cada vez menos orientados para frontend, menos uso o CodeKit. E quanto mais eu migrei para o desenvolvimento orientado a backend, mais eu uso o Composer.
Além disso, o desenvolvimento front-end é diferente do desenvolvimento back-end, certo? Então, novamente, por que perguntaríamos:
Devo usar CodeKit ou Composer?
É aí que a resposta mais longa entra em jogo.
CodeKit e Compositor
Para aqueles que estão olhando para esses dois utilitários e estão se perguntando sobre a diferença em cada um, isso é uma coisa boa.
Sempre que alguém está procurando maneiras de melhorar seu processo de desenvolvimento através do uso de ferramentas para facilitar o desenvolvimento, acho que isso mostra um nível de maturidade no desenvolvimento.
CodeKit
Resumindo, o objetivo do CodeKit é ajudar a agrupar muitas das novas ferramentas que vemos frequentemente (como Sass ou LESS, frameworks como Foundation e otimização de imagem) em um único aplicativo e envolvê-lo, então há menos trabalho a fazer quando vem a configuração.
A coisa sobre isso é que ele inclui um monte de coisas. Isso não é uma coisa ruim, no entanto. Na verdade, tudo se resume a selecionar o que você deseja, clicar em algumas caixas de seleção e garantir que o aplicativo esteja ciente de sua base de código.
A partir daí, ele se encarregará de, digamos, compilar automaticamente seu Sass sempre que você salvar um arquivo que faça parte do seu projeto.
Compositor
O Composer, por outro lado, trata do gerenciamento de dependências que funcionam em conjunto com seu aplicativo. Isso pode ser algo como PHP CodeSniffer. Ou pode ser algo como uma biblioteca de terceiros como o Monolog que ajuda seu projeto a rastrear eventos que estão acontecendo durante a execução.
Seja qual for o caso, você pode ver que os pacotes que o Composer é responsável por gerenciar lidam mais com o desenvolvimento do lado do servidor do que com o desenvolvimento do front-end.
Portanto, se você estiver procurando por algo como CodeKit (ou NPM ou Yarn) para o lado do servidor, o Composer é o que você deseja usar. Ele não tem interface, então tudo é feito através de arquivos de configuração (como NPM, por exemplo), mas também é bem documentado e fácil de usar quando você estiver familiarizado com a estrutura dos arquivos de configuração.
E essa é a diferença
Como mencionado no início do post, CodeKit e Composer não são mutuamente exclusivos. Se alguma coisa, eles podem trabalhar em conjunto para ajudar a construir um projeto de front-end e back-end.
Quando se trata de desenvolvimento front-end, existem outras ferramentas que as pessoas optam por usar, como NPM e Yarn. Menciono-os aqui apenas porque eles também são gerenciadores de pacotes, bem como o Composer, mas para o front-end.
E, se alguma coisa, eles estão mais próximos de uma comparação com o Composer. Mesmo assim, eles se concentram principalmente em ferramentas de desenvolvimento front-end. Talvez valha a pena mergulhar em cada um deles em um post futuro.