المقارنة

webpack ليس أداة تحزيم الوحدات الوحيدة. إذا كنت تفاضل بين استخدام webpack أو إحدى الأدوات التالية، فهذا جدول يقارن الميزات نقطة بنقطة ويوضح كيف يقف webpack أمام المنافسين الحاليين.

الميزة	webpack/webpack	jrburke/requirejs	substack/node-browserify	jspm/jspm-cli	rollup/rollup	brunch/brunch
تحميل chunks إضافية عند الطلب	نعم	نعم	لا	System.import	لا	لا
AMD define	نعم	نعم	deamdify	نعم	rollup-plugin-amd	نعم
AMD require	نعم	نعم	لا	نعم	لا	نعم
تحميل AMD require عند الطلب	نعم	يتطلب ضبطًا يدويًا	لا	نعم	لا	لا
CommonJS exports	نعم	فقط عند التغليف داخل define	نعم	نعم	commonjs-plugin	نعم
CommonJS require	نعم	فقط عند التغليف داخل define	نعم	نعم	commonjs-plugin	نعم
CommonJS require.resolve	نعم	لا	لا	لا	لا	-
الدمج داخل require require("./fi" + "le")	نعم	لا♦	لا	لا	لا	-
دعم التصحيح	SourceUrl, SourceMaps	غير مطلوب	SourceMaps	SourceUrl, SourceMaps	SourceUrl, SourceMaps	SourceMaps
التبعيات	19MB / 127 حزمة	11MB / 118 حزمة	1.2MB / 1 حزمة	26MB / 131 حزمة	?MB / 3 حزم	-
ES2015 import/export	نعم (webpack 2)	لا	لا	نعم	نعم	نعم، عبر es6 module transpiler
التعابير داخل require (موجهة) require("./templates/" + template)	نعم (تُضمّن كل الملفات المطابقة)	لا♦	لا	لا	لا	لا
التعابير داخل require (حرة) require(moduleName)	يتطلب ضبطًا يدويًا	لا♦	لا	لا	لا	-
إنشاء bundle واحد	نعم	نعم♦	نعم	نعم	نعم	نعم
require غير مباشر var r = require; r("./file")	نعم	لا♦	لا	لا	لا	-
تحميل كل ملف على حدة	لا	نعم	لا	نعم	لا	لا
تغيير أسماء المسارات	نعم	لا	جزئيًا	نعم	غير مطلوب (أسماء المسارات لا تُضمّن في bundle)	لا
التصغير (Minification)	Terser	uglify, closure compiler	uglifyify	نعم	uglify-plugin	UglifyJS-brunch
بناء صفحات متعددة مع bundle مشترك	يتطلب ضبطًا يدويًا	نعم	يتطلب ضبطًا يدويًا	باستخدام حسابات bundle	لا	لا
عدة bundles	نعم	يتطلب ضبطًا يدويًا	يتطلب ضبطًا يدويًا	نعم	لا	نعم
مكتبات Node.js المدمجة require("path")	نعم	لا	نعم	نعم	node-resolve-plugin	-
عناصر Node.js الأخرى	process, __dir/filename, global	-	process, __dir/filename, global	process, __dir/filename, global لـ cjs	global (commonjs-plugin)	-
Plugins	نعم	نعم	نعم	نعم	نعم	نعم
المعالجة المسبقة	loaders	loaders	تحويلات	تحويل عبر plugin	تحويلات عبر plugin	compilers, optimizers
الاستبدال الخاص بالمتصفح	web_modules, .web.js, package.json field, alias configuration option	alias option	package.json field, alias option	package.json, alias option	لا	-
الملفات التي يمكن طلبها عبر require	نظام الملفات	web	نظام الملفات	عبر plugins	نظام الملفات أو عبر plugins	نظام الملفات
الكلفة الإضافية وقت التشغيل	243B + 20B لكل module + 4B لكل dependency	14.7kB + 0B لكل module + (3B + X) لكل dependency	415B + 25B لكل module + (6B + 2X) لكل dependency	5.5kB لـ self-executing bundles، و38kB للـ loader الكامل مع polyfill، و0 للـ plain modules، و293B لـ CJS، و139B لـ ES2015 System.register قبل gzip	لا توجد لوحدات ES2015 (قد توجد في الصيغ الأخرى)	-
وضع المراقبة	نعم	غير مطلوب	watchify	غير مطلوب أثناء التطوير	rollup-watch	نعم

♦ في وضع الإنتاج (والعكس في وضع التطوير)

X تمثل طول سلسلة المسار.

التحزيم (Bundling) مقابل التحميل (Loading)

من المهم توضيح بعض الفروقات الأساسية بين تحميل الوحدات وتحزيمها. أداة مثل SystemJS، وهي مستخدمة داخليًا في JSPM، تُستخدم لتحميل الوحدات وتحويلها وقت التشغيل داخل المتصفح. يختلف هذا كثيرًا عن webpack، حيث تُحوّل الوحدات عبر "loaders" ثم تُحزّم قبل أن تصل إلى المتصفح.

لكل أسلوب مزاياه وعيوبه. تحميل الوحدات وتحويلها وقت التشغيل قد يضيف كلفة كبيرة على المواقع والتطبيقات الأكبر، خصوصًا عندما تتكون من عدد كبير من الوحدات. لذلك يكون SystemJS أنسب للمشاريع الأصغر التي تحتاج إلى وحدات أقل. قد يتغير هذا جزئيًا مع HTTP/2 لأنه يحسن سرعة نقل الملفات من الخادم إلى العميل. لكن لاحظ أن HTTP/2 لا يغير شيئًا في تكلفة تحويل الوحدات، فهي ستبقى أبطأ عندما تتم من جهة العميل.