Ponieważ pisałem o CodeKit i Composer (więcej o tym ostatnim w ostatnich postach), od czasu do czasu otrzymuję e-maile z pytaniem, którego tak naprawdę wolę używać, gdy chodzi o pracę nad projektami dla innych.
Krótka odpowiedź brzmi, że nie wykluczają się wzajemnie. Jeśli już, mogą się wzajemnie uzupełniać. Nie zastępują siebie nawzajem.
W miarę jak odchodzę od projektów coraz mniej zorientowanych na frontend, tym mniej używam CodeKit. A im bardziej skłaniam się ku programowaniu zorientowanemu na backend, tym częściej używam Composera.
Co więcej, programowanie front-end różni się od programowania back-end, prawda? Więc znowu, dlaczego mielibyśmy zapytać:
Czy powinienem używać CodeKit czy Composer?
W tym momencie wchodzi w grę dłuższa odpowiedź.
CodeKit i Composer
Dla tych, którzy patrzą na oba te narzędzia i zastanawiają się nad różnicą w każdym z nich, to dobrze.
Zawsze, gdy ktoś szuka sposobów na ulepszenie procesu rozwoju poprzez użycie narzędzi ułatwiających rozwój, myślę, że pokazuje to poziom dojrzałości w rozwoju.
CodeKit
Krótko mówiąc, celem CodeKit jest pomoc w zintegrowaniu wielu nowych narzędzi, które często widzimy (takich jak Sass lub LESS, frameworki, takie jak Foundation, i optymalizacja obrazu) w pojedynczą aplikację i zamknięcie jej, dzięki czemu jest mniej pracy do wykonania, gdy jest to chodzi o konfigurację.
Chodzi o to, że zawiera wiele rzeczy. Nie jest to jednak zła rzecz. To naprawdę sprowadza się do wybrania tego, co chcesz, kliknięcia kilku pól wyboru, a następnie upewnienia się, że aplikacja zna bazę kodu.
Stamtąd zajmie się, powiedzmy, automatyczną kompilacją Sassa za każdym razem, gdy zapiszesz plik, który jest częścią twojego projektu.
Kompozytor
Z drugiej strony w Composer chodzi o zarządzanie zależnościami, które działają w połączeniu z Twoją aplikacją. Może to być coś w rodzaju PHP CodeSniffer. Lub może to być coś w rodzaju biblioteki innej firmy, takiej jak Monolog, która pomaga Twojemu projektowi śledzić zdarzenia, które mają miejsce podczas wykonywania.
Niezależnie od przypadku, można zauważyć, że Composer pakietów jest odpowiedzialny za zarządzanie, zajmując się bardziej programowaniem po stronie serwera niż programowaniem front-end.
Więc jeśli szukasz czegoś takiego jak CodeKit (lub NPM lub Yarn) po stronie serwera, to Composer jest tym, czego szukasz. Nie ma interfejsu, więc wszystko odbywa się za pomocą plików konfiguracyjnych (jak na przykład NPM), ale jest również dobrze udokumentowane i wystarczająco łatwe w użyciu, gdy zapoznasz się ze strukturą plików konfiguracyjnych.
I to jest różnica
Jak wspomniano na początku wpisu, CodeKit i Composer nie wykluczają się wzajemnie. Jeśli już, mogą współpracować ze sobą, aby pomóc w tworzeniu projektu zarówno z poziomu front-endu, jak i back-endu.
Jeśli chodzi o programowanie front-end, istnieją inne narzędzia, z których ludzie decydują się korzystać, takie jak NPM i Yarn. Wspominam o nich tutaj tylko dlatego, że są także menedżerami pakietów, podobnie jak Composer, ale dla front-endu.
A jeśli już, to bliżej im do porównania z Composerem. Mimo to skupiają się przede wszystkim na front-endowych narzędziach programistycznych. Być może warto będzie zagłębić się w każdą z nich w przyszłym poście.