Was ist der Unterschied zwischen CodeKit und Composer?
Seit ich über CodeKit und Composer geschrieben habe (mehr über letzteres in den letzten Beiträgen), erhalte ich gelegentlich E-Mails mit der Frage, welches ich wirklich am liebsten verwende, wenn es darum geht, an Projekten für andere zu arbeiten.
Und die kurze Antwort ist, dass sie sich nicht gegenseitig ausschließen. Wenn überhaupt, können sie sich ergänzen. Sie sind kein Ersatz füreinander.
Je weniger ich von immer weniger Frontend-orientierten Projekten umgezogen bin, desto weniger verwende ich CodeKit. Und je mehr ich mich in Richtung Backend-orientierte Entwicklung bewegt habe, desto mehr verwende ich Composer.
Außerdem unterscheidet sich die Front-End-Entwicklung von der Back-End-Entwicklung, richtig? Warum sollten wir also noch einmal fragen:
Soll ich CodeKit oder Composer verwenden?
Hier kommt die längere Antwort ins Spiel.
CodeKit und Composer
Für diejenigen, die sich beide dieser Dienstprogramme ansehen und sich über den Unterschied in jedem wundern, ist das eine gute Sache.
Wann immer jemand nach Möglichkeiten sucht, seinen Entwicklungsprozess durch den Einsatz von Tools zur Erleichterung der Entwicklung zu verbessern, zeigt dies meiner Meinung nach einen Reifegrad in der Entwicklung.
CodeKit
Kurz gesagt, das Ziel von CodeKit ist es, viele der neuen Tools, die wir oft sehen (wie Sass oder LESS, Frameworks wie Foundation und Bildoptimierung), in eine einzige Anwendung zu packen und zu verpacken, sodass weniger Arbeit zu erledigen ist kommt zur Konfiguration.
Das Besondere daran ist, dass es viele Dinge enthält. Dies ist jedoch keine schlechte Sache. Es kommt wirklich darauf an, auszuwählen, was Sie wollen, ein paar Kontrollkästchen anzuklicken und dann sicherzustellen, dass die App Ihre Codebasis kennt.
Von dort aus kümmert es sich beispielsweise darum, Ihren Sass automatisch zu kompilieren, wenn Sie eine Datei speichern, die Teil Ihres Projekts ist.
Komponist
Bei Composer hingegen dreht sich alles um die Verwaltung von Abhängigkeiten, die in Verbindung mit Ihrer Anwendung funktionieren. Dies kann so etwas wie PHP CodeSniffer sein. Oder es kann so etwas wie eine Bibliothek eines Drittanbieters wie Monolog sein, die Ihrem Projekt hilft, Ereignisse zu verfolgen, die während der Ausführung stattfinden.
Wie auch immer, Sie können sehen, dass die Pakete, für deren Verwaltung Composer verantwortlich ist, sich mehr mit der serverseitigen Entwicklung als mit der Front-End-Entwicklung befassen.
Wenn Sie also nach etwas wie CodeKit (oder NPM oder Yarn) für die Serverseite suchen, dann ist Composer genau das, was Sie verwenden möchten. Es hat keine Schnittstelle, also wird alles über Konfigurationsdateien (wie zum Beispiel NPM) erledigt, aber es ist auch gut dokumentiert und einfach genug zu verwenden, sobald Sie mit der Struktur der Konfigurationsdateien vertraut sind.
Und das ist der Unterschied
Wie zu Beginn des Beitrags erwähnt, schließen sich CodeKit und Composer nicht gegenseitig aus. Wenn überhaupt, können sie zusammenarbeiten, um ein Projekt sowohl vom Front-End als auch vom Back-End aus zu erstellen.
Wenn es um die Front-End-Entwicklung geht, gibt es andere Tools, für die sich die Leute entscheiden, wie NPM und Yarn. Ich erwähne sie hier nur, weil sie auch Paketmanager sind, ähnlich wie Composer, aber für das Frontend.
Und, wenn überhaupt, sind sie einem Vergleich mit Composer näher. Trotzdem konzentrieren sie sich hauptsächlich auf Front-End-Entwicklungstools. Vielleicht lohnt es sich, in einem zukünftigen Beitrag auf jeden von ihnen einzugehen.