Ein simpler Git Gist brachte Aufregung in der javaScript Community. An der einen Hand hat Substrack (Der Autor von Browserify) sein Projekt mit all seinen Features beworben.

Auf der anderen Seite hat Pete Hunt, der Autor von Webpack, die extreme Modalität von Webpack hervorgehoben. Ich beleuchte also diesen Konflikt und stelle diese beiden Technologien gegenüber.

Im Vordergrund deren Auseinandersetzungen steht die Kompatibilität zu node.js.

Betrachtet man die Beliebtheit der beiden Manager, gemessen an den Github Repositories, dann sieht man, dass Webpack mit 27.000 Github Stars weit vor Browserify mit 11.000 Stars liegt.

Browserify

Browserify wurde erstellt um deinen Node-code im Browser laufen lassen zu können. Bis heute unterstützt es nur einen Hauch von node’s Common (inkl. JSON Support) und stellt eingebaute shims für viele node Core Module. Alles andere ist ein anderes Paket. Musst du Dateien überwache um die inkrementell zu kompilieren? Nutze Watchify… Musst du deine Bundles aufteilen? Schau dir Factor-Bundle an. Brauchst du AMD-Support? Da gibt es deAMDify.

Browserify schiebt alle Features die nicht gerade in die Philosophie passen, node Code im Browser lauf zu lassen, in transforms und Plug-ins.

Zur gleichen Zeit, Browserify erwartet nur in einem Node.js Projekt verwendet zu finden. Es empfiehlt kleinere Module zu erstellen, sie auf NPM zu veröffentlichen und die Konfiguration in die package.json zu verlagern

Webpack

Webpack ist eine ganz andere Nummer. Es lernt von Tools wie Browserify und Require.js und probiert nie wirklich kompatibel mit node.js zu sein. Es wurde von der Pike so geschrieben, dass es statische Assets des front-end verwaltet. Während Browserify den BRFS (Buffered Read File System) verwendet, welche eine native Funktion von node.js ist, überlädt man in Webpack die require Funktion und benutzt eine loader der die Datei lädt, welche ein bestimmtes Muster enthält.

Webpack halt also keine Voraussetzungen zu common.js über AMD. Es unterstützt alle Module-Formate out of the box. Du kannst als dein ganzes Projekt mit AMD schreiben und trotzdem Webpack nutzen. Natürlich funktioniert der Code in Node.js nur mit ein wenig Arbeit.

Unterschiede in der Philosophie

Diese Unterschiede können weitreichende Konsequenzen haben. Webpack zum Beispiel wendet alle loaders auf alle Dateien die zutreffen, außer du exkludiert den node-modules Ordner.Browserify wendet in der Standard-Konfiguration keine transforms zu den Dateien im node_modules Ordner an.

Das ist eigentlich ein wichtiges Detail, wenn man die beiden Technologien miteinander vergleicht. Browserify ist ein wenig mehr „modular“ und kann und sollte mit vielen plug-ins und transforms zusammen arbeiten. Webpack bringt mehr Features mit und packt sie in den Kern. Allerdings ist Browserify mehr konventioneller als Webpack.

Webpack ist mit all seiner Größe und Features eigentlich ziemlich flexibel im Umgang. Du kannst es auf verschiedene Art benutzen, solang du bereits bist, ein dementsprechendes config-File zu schreiben.

Wenn du nur commonjs und nicht Webpack benutzt um deine CSS-Dateien oder graphischen Assets zu verwalten, dann kannst du auch Browserify nutzen und die Kompatibilität zu node bleibt.

Browserify allerdings ist kleiner und durchgesetzt und einfach sich anzueignen. Und wenn du dich an die Konventionen hältst, hast du einen nur sehr kleinen Aufwand in der Konfiguration um es für dich arbeiten zu lassen.

Browserify muss man nur minimal konfigurieren, man muss sich allerdings an einige Konventionen halten. Webpack benötigt immer ein wenig mehr Konfiguration um im geringsten Fall zu arbeiten.


Static Asset Management

Webpack lässt dich deine CSS-Dateien direkt zur Laufzeit des Browser injecten. Node.js an sich, kann nicht wirklich CSS requiren. Aber mit Webpack, hast du die Möglichkeit, es zu konfigurieren wie du möchtest.

In der Browserify Welt, würdest du das gleiche Problem mit Konventionen und Modularität lösen. Mit dem Tool Parcelify, welches Browserify ergänzt, kannst du deine Abhängigkeiten mit der package.json verfolgen. CSS-Dateien werden mit javascript Pakete ausgeliefert. Dieses System zwingt dich deine Anwendungen so modular wie möglich zu entwickeln. Das hilft dir auf lange Sicht deine ganze Codebase wieder benutzbar zu halten.

Ähnlich für Bilder und andere statische Assets, zu denen du nur die URL haben möchtest. Browserify bietet mit urify-emmiter ein Tool, welches sich gerade in „experimental“ Status befindet. Aber bringt statisches Asset-Managment zu Webpack welches komplett kompatibel zu node.js ist. Anstatt die require Funktion zu überladen, es importert ein Modul, welches dich diese statischen Assets requieren lässt. Die required-Datein geben einfach einen String des Pfades wieder. Mit ein wenig Konfiguration kannst du es auch automatisch deine Assets zu einem bestimmten Ordner kopieren lassen. Diese haben dann eindeutige Hashnames. Ist dies fertiggestellt, wird das zu einer generellen Verbesserung im Asset-Managment für javascript werden. Und somit wird Webpack auch beliebter.

Bundle Splitting

Es wurde viel über Webpack’s eingebauten „bundle splitting“ gesagt. Wie auch immer. Mit Factor-Bundle und Partition-Bundle hat Browserify die gleichen Möglichkeiten.

React Hot-Loading

Eine Sache in der Webpack Browserify voraus ist, ist das Webpack Server Utility. Es viele coole Features wie zum Beispiel React Hot-Loading welches DOM-Elemente auf deiner Seite aktuell hält, ohne die Seite zu aktualisieren. Es kann zwar schwierig sein, es aufzusetzen allerdings ist es ein gutes Tool wenn du es einmal hast.

Webpack’s fix für Node.js

Wenn du den Webpack Weg gehst, hast du zwei Möglichkeiten den in Node laufen zu lassen. Du kannst den Code mit node export-en, so dass der Code, der exportiert wurde mit node kompatibel ist.

Das Enhanced-Require-Module überlädt die require-Funktion von node.js, sodass dein Code auch läuft.

Ich habe keines der beiden Systeme probiert und ich bin mir um die verschiedenen Grenzen nicht sicher.

Eine Entscheidung treffen

Eine Entscheidung zwischen den beiden Modul-Managern ist schwieriger den die meisten Leute denken. Im Feature-Battle hat Webpack ein Feature, welche Browserify nicht hat. Wenn du deine Entscheidung nur auf Grund der Features triffst, dann wird Webpack deine Wahl sein. Denn Features wie Hot-Loading gibt es nur bei Webpack.

Wenn du allerdings von dem NPM-Ökosystem abhängig bist, aber ein Tool möchtest, welches eine nur kleine aber dafür gute API hat und nur minimalen Konfiguration-Aufwand möchtest, solltest du die für Browserify entscheiden. Es hat nicht alle Feature von Webpack aber es hat die meisten in sich. Es ist wirklich einfach damit zu starten. Durch die Konventionen zwingt dich Browserify eine modulare Codebase aufzubauen, die dir in der Zukunft helfen könnte. Mit dem Browser-key in der package.json kannst du einfach die gleiche API in verschiedenen Implementationen verwenden.

Die Glaskugel

Mit dem Aufstieg von javaScript ES6 entwicklen sich auch die Tools. Das jüngste Kinde ist system.js mit ihrem eigenem Packet-Manager jspm. System.js hat einen ganz anderen Ansatz das Problem zu lösen. Da mit HTTP 2.0 es schneller ist viele kleine Dateien zu laden als eine Große. Somit fällt das „bundling“ dort raus.

Schreibe einen Kommentar