Endlich machte ich Sinn für Front-End-Build-Tools. Sie können auch.

Front-End-Build-Tools können selbst für erfahrene Entwickler wie mich verwirrend sein. Die Lösung besteht darin, zu verstehen, wie sie auf konzeptioneller Ebene funktionieren - und zusammenarbeiten.

Dieser Artikel stellt meinen meinungsgebundenen Ansatz vor, um Front-End-Build-Tools zu verstehen. Anstatt in Code einzutauchen, werde ich Sie durch mein mentales Modell führen, wie diese Tools funktionieren und was sie leisten.

Lassen Sie sich vom Stand der Technik nicht einschüchtern

Node, NPM, Grunt, Gulp, Bower, Webpack, Browserify, Yeoman, Brunch ... es gibt so viele Front-End-Build-Tools, dass es unmöglich erscheint, Schritt zu halten.

Der Schlüssel ist nicht einschüchternd. Alle diese Projekte sollen Ihnen das Leben erleichtern.

Um zu verstehen, was, warum und wie diese Tools funktionieren, müssen Sie nur einige Konzepte verstehen.

Konzept Nr. 1 - Die Kerndichotomie der Build-Tools lautet „Installieren vs. Ausführen“.

Build-Tools machen zwei Dinge:

  1. Installieren Sie Dinge
  2. Dinge tun

Die erste Frage, die Sie sich stellen müssen, wenn Sie mit einem neuen Build-Tool konfrontiert werden, lautet: "Soll dieses Tool Dinge für mich installieren oder Dinge für mich tun?"

Tools wie npm, Bower und Yeoman können so ziemlich alles installieren. Sie können Front-End-Bibliotheken wie Angular.js oder React.js installieren. Sie können Server für Ihre Entwicklungsumgebung installieren. Sie können Testbibliotheken installieren. Sie helfen Ihnen sogar bei der Installation anderer Front-End-Build-Tools.

Kurz gesagt, sie installieren fast alle Code-bezogenen Dinge, die Sie sich vorstellen können.

Die "Doing" -Tools wie Grunt, Webpack, Require.js, Brunch und Gulp sind viel komplizierter. Das Ziel der "Doing" -Tools besteht darin, alle grundlegenden und fehleranfälligen Aufgaben in der Webentwicklung zu automatisieren. Die Dinge, die sie tun, werden manchmal als "Aufgaben" bezeichnet.

Um diese „Aufgaben“ zu erledigen, verwenden sie häufig ihr eigenes Ökosystem aus Paketen und Plugins. Jedes Tool schreibt Aufgaben auf unterschiedliche Weise. Diese Tools machen auch nicht alle dasselbe. Einige "Doing" -Tools versuchen, jede Aufgabe zu bewältigen, die Sie darauf werfen (Grunzen, Schlucken usw.). Andere konzentrieren sich auf eine Sache, wie den Umgang mit Javascript-Abhängigkeiten (Browserify, Require.js usw.).

Manchmal verwenden Sie mehrere dieser Tools im selben Projekt.

Hier ist eine kurze Liste von "Aufgaben", die ich mit diesen "Aufgaben" -Tools automatisiert habe:

  1. Ersetzen einer Textzeichenfolge in einer Datei
  2. Erstellen von Ordnern und Verschieben von Dateien in diese Ordner
  3. Ausführen meiner Unit-Tests mit einem einzigen Befehl
  4. Aktualisiere meinen Browser, wenn ich eine Datei speichere
  5. Kombinieren Sie alle meine JavaScript-Dateien zu einer und alle meine CSS-Dateien zu einer
  6. Minimierung meiner verketteten JavaScript- und CSS-Dateien
  7. Ändern der Platzierung von Tags auf einer HTML-Seite

Sobald Sie verstanden haben, dass Tools Dinge installieren oder Dinge tun, wird das Kategorisieren viel einfacher:

Konzept Nr. 2 - Die Großeltern aller Build-Tools sind Node und npm

Node und npm installieren und führen alle diese Build-Tools aus, sodass in Ihrem Projekt immer eine Spur davon vorhanden ist. Aus diesem Grund versuchen viele Entwickler, diese beiden Tools so oft wie möglich zu verwenden, bevor sie ein zusätzliches Tool installieren.

Knoten und NPM fallen in unsere Dichotomie „Build“ und „Do“. Node ist das "do" -Tool und npm ist das "install" -Tool.

npm kann Bibliotheken wie Angular.js oder React.js installieren. Es kann auch ein Server installiert werden, auf dem Ihre App lokal für die Entwicklung ausgeführt wird. Es kann sogar Tools installieren, um beispielsweise Ihren Code zu minimieren.

Node hingegen erledigt Dinge für Sie, z. B. das Ausführen von JavaScript-Dateien, Servern und vielem mehr.

Wenn Sie einen Ort zum Lernen benötigen, beginnen Sie mit Node + npm und bleiben Sie dort eine Weile. Wenn Ihr Projekt groß genug wird, stoßen Sie an die Grenzen dessen, was Node und npm für Sie automatisieren können. Zu diesem Zeitpunkt können Sie ein anderes Build-Tool organisch integrieren.

Konzept Nr. 3 - Ein Build ist nur eine produktionsbereite Version Ihrer App

Entwickler teilen JavaScript und CSS häufig in separate Dateien auf. Mit separaten Dateien können Sie sich darauf konzentrieren, modularere Codestücke zu schreiben, die eine einzige Aufgabe erfüllen. Dateien, die eines tun, verringern Ihre kognitive Belastung. (Wenn Sie der Meinung sind, dass separate Dateien verwirrender sind als eine große Datei, versuchen Sie, in einer Datei mit 5000 Zeilen zu arbeiten, und Sie werden Ihre Meinung schnell ändern?)

Wenn es jedoch an der Zeit ist, Ihre App in die Produktion zu verschieben, ist es nicht ideal, mehrere JavaScript- oder CSS-Dateien zu haben. Wenn ein Benutzer Ihre Site besucht, erfordert jede Ihrer Dateien zusätzliche HTTP-Anforderungen, wodurch das Laden Ihrer Site langsamer wird.

Um dies zu beheben, können Sie einen „Build“ unserer App erstellen, der alle Ihre CSS-Dateien in einer Datei zusammenführt und dasselbe mit Ihrem JavaScript tut. Auf diese Weise minimieren Sie die Anzahl und Größe der Dateien, die der Benutzer erhält. Um diesen "Build" zu erstellen, verwenden Sie ein "Build-Tool".

Unten sehen Sie einen Screenshot einer App, die sich in der Entwicklung befindet. Beachten Sie, wie es 5 Tags und 3 Tags hat? Wenn Sie auf die linke Seite schauen, bemerken Sie, dass der Ordner ENTWICKLUNG 10 Dateien enthält?

Und unten ist die gleiche App, nachdem ein Build-Tool seine Magie gewirkt hat.

Beachten Sie, dass wir nur ein einzelnes Skript-Tag und ein einzelnes Link-Tag haben? Und jetzt hat der Ordner PRODUCTION nur noch 4 Dateien, verglichen mit den 10 Dateien des Ordners DEVELOPMENT.

Die App ist Zeile für Zeile gleich. Wir haben es gerade zu einem hübschen kleinen Paket komprimiert, das wir als "Build" bezeichnen.

Sie fragen sich vielleicht, warum sich ein Build überhaupt lohnt, wenn Sie Ihren Benutzern lediglich einige Millisekunden Ladezeit sparen. Wenn Sie eine Website nur für sich selbst oder einige andere Personen erstellen, müssen Sie sich nicht darum kümmern. Das Generieren eines Builds Ihres Projekts ist nur für Websites mit hohem Datenverkehr erforderlich (oder für Websites, von denen Sie hoffen, dass sie bald stark frequentiert werden?).

Wenn Sie nur die Entwicklung lernen oder nur Websites mit sehr wenig Verkehr erstellen, lohnt es sich möglicherweise nicht, einen Build zu erstellen.

Konzept Nr. 4 - Die Grenzen zwischen "Installieren" und "Ausführen" können verschwommen sein

Kein Werkzeug macht nur das eine und nicht das andere. Sie alle machen eine Mischung aus "installieren" und "tun". Im Allgemeinen kann ein Tool jedoch mehr von dem einen als vom anderen ausführen.

Manchmal führt ein "Installations" -Tool Dateien aus. npm macht das oft. npm kann auch Befehle und Skripte ausführen - nicht nur Dateien installieren. Ein Tool wie Yeoman installiert vorgefertigte Boilerplate-Apps auf Ihrem Computer, generiert aber bei Bedarf auch dynamisch neue Dateien, wodurch die Grenze zwischen Installation und Ausführung verwischt wird.

Konzept Nr. 5 - Es gibt keine richtige Kombination von Werkzeugen

Die Kombination der von Ihnen verwendeten Tools liegt ganz bei Ihnen.

Sie können wählen, überhaupt keine Werkzeuge zu verwenden. Denken Sie daran, dass das Kopieren, Einfügen, Minimieren, Starten von Servern und alles andere schnell überwältigend werden kann.

Oder Sie können Node und npm einfach ohne zusätzliche Tools verwenden. Dies ist ideal für Anfänger, aber wenn Ihr Projekt wächst, fühlt es sich möglicherweise zu manuell an.

Sie können auch einige andere Tools zusätzlich zu Node und npm in Ihrem Projekt verwenden. Ihre App verwendet also Node + npm als Kern und dann möglicherweise Grunt + Bower oder Webpack oder Gulp + Bower.

Wenn Sie eine Kombination solcher Tools über Node + npm verwenden, können Sie viele Aufgaben in Ihrem Projekt automatisieren. Der Preis, den Sie zahlen, ist, dass diese Tools eine steile Lernkurve haben.

Konzept Nr. 6 - Build-Tools haben eine steile Lernkurve. Lernen Sie also nur, was erforderlich ist

Das Erstellen einer App ist schwierig genug. Möglicherweise arbeiten Sie mit einer neuen Sprache oder einem neuen Framework. Oder Sie haben eine wirklich knifflige Geschäftslogik. Wenn Sie also ein Build-Tool einbinden, kann dies Ihrem Projekt eine zusätzliche Komplexitätsebene hinzufügen. Dies gilt insbesondere dann, wenn es sich um ein Projekt handelt, bei dem jemand anderes den mit dem Build-Tool verknüpften Code geschrieben hat.

Mein Rat ist, nur genau zu lernen, was Sie für Ihre Arbeit brauchen, und sonst nichts.

Der beste Weg, um neue Dinge zu lernen, ist, wenn Sie eine reale Aufgabe haben, die Sie erfüllen müssen. Lernen Sie beispielsweise nicht, wie Sie Dateien mit Grunt kopieren. Warten Sie stattdessen, bis Ihr Projekt das tatsächlich benötigt, und finden Sie es dann heraus.

Denken Sie daran: Vorzeitige Komplexität verlangsamt Sie.

Konzept Nr. 7 - Alle Build-Tools haben dasselbe Ziel: Sie durch die Automatisierung vieler einfacher Aufgaben glücklich zu machen

Sie nutzen Ihr Build-Tool voll aus, wenn Sie das erreichen, was ich als "Build-Tool-Nirvana" bezeichnet habe. Dies geschieht, nachdem Sie eine Datei gespeichert oder einen einzelnen Befehl ausgeführt haben und Tonnen von Aufgaben für Sie „automatisch“ ausgeführt werden.

Wenn Sie für Ihr Build-Tool weiterhin Dateien manuell verschieben, Werte ändern oder Befehle ausführen müssen, um einen neuen Build zu erhalten, haben Sie das Nirvana des Build-Tools noch nicht erreicht.

Einer der größten Vorteile von Build-Tools besteht darin, dass Sie durch einfaches Speichern einer Datei einen neuen Build Ihrer App auslösen und an Ihren Browser senden können. Dies kann Ihren Front-End-Entwicklungsworkflow erheblich beschleunigen.

Wie viel Aufwand sollten Sie in die Konfiguration und Einrichtung Ihres Build-Tools investieren? Ganz einfach: Hören Sie auf, wenn Sie mit dem, was es für Sie tut, zufrieden sind.

Konzept Nr. 8 - Es sind nicht nur Sie. Die Dokumentation ist oft schrecklich.

Du bist es nicht, das verspreche ich. Für viele dieser Tools fehlt die Dokumentation. Manchmal kann es schwierig sein, grundlegende Aufgaben zu erledigen.

Beachten Sie, dass es nur sehr wenige vordefinierte Rezepte für Build-Tools gibt. Sie werden sehen, dass Menschen auf ganz unterschiedliche Weise dieselben Ergebnisse erzielen - manchmal alle als Antwort auf dieselbe StackOverflow-Frage!

Dies ist zwar ärgerlich, bietet Ihnen aber auch die Möglichkeit, Ihre Codierermuskeln zu spielen und etwas Kreatives umzusetzen.

Tun wir das nicht auch deshalb?

Danke fürs Lesen! Hoffentlich machen diese wenigen Punkte die Annäherung an Build-Tools zu einer weniger verwirrenden Erfahrung. Wenn nicht, kläre ich gerne alle Fragen (oder korrigiere alle Fehler, die Sie hier finden), twittere mich @Roneesh!

Und wenn Ihnen das, was Sie gelesen haben, gefallen hat, lesen Sie es bitte unten und teilen Sie es mit Ihren Freunden. Als Schriftsteller bedeutet das für mich die Welt!