I've spent a couple days getting Webpack up and running and just got a test going. However I found that the bundle.js file that came out of webpack was doing a lot of unnecessary things that make no sense to me.
index.js
import greet from './greet';
console.log("I'm the entry point");
greet();
greet.js
function greet() {
console.log('Have a great day!');
};
export default greet;
So super simple. But bundle.js
!(function(e) {
var t = {};
function n(r) {
if (t[r]) return t[r].exports;
var o = (t[r] = { i: r, l: !1, exports: {} });
return e[r].call(o.exports, o, o.exports, n), (o.l = !0), o.exports;
}
(n.m = e),
(n.c = t),
(n.d = function(e, t, r) {
n.o(e, t) || Object.defineProperty(e, t, { enumerable: !0, get: r });
}),
(n.r = function(e) {
"undefined" != typeof Symbol &&
Symbol.toStringTag &&
Object.defineProperty(e, Symbol.toStringTag, { value: "Module" }),
Object.defineProperty(e, "__esModule", { value: !0 });
}),
(n.t = function(e, t) {
if ((1 & t && (e = n(e)), 8 & t)) return e;
if (4 & t && "object" == typeof e && e && e.__esModule) return e;
var r = Object.create(null);
if (
(n.r(r),
Object.defineProperty(r, "default", { enumerable: !0, value: e }),
2 & t && "string" != typeof e)
)
for (var o in e)
n.d(
r,
o,
function(t) {
return e[t];
}.bind(null, o)
);
return r;
}),
(n.n = function(e) {
var t =
e && e.__esModule
? function() {
return e.default;
}
: function() {
return e;
};
return n.d(t, "a", t), t;
}),
(n.o = function(e, t) {
return Object.prototype.hasOwnProperty.call(e, t);
}),
(n.p = ""),
n((n.s = 0));
})([
function(e, t, n) {
"use strict";
n.r(t);
var r = function() {
console.log("Have a great day!");
};
console.log("I'm the entry point"), r();
}
]);
It seems like WebPack is doing a lot of unnecessary code that just makes no sense to me. The bundle.js is also 3 times larger in file size than the index.js and greet.js. The development build of the app also just looks very confusing and messy for something so simple.
So why should I continue to invest time into using WebPack for my projects? What is all the extra code it is outputting and why is it there? Are the any better alternatives that will help me ship my code from a modular development environment?
I'd really appreciate your help in getting me to understand why I should or shouldn't use WebPack.
Thanks!
I've spent a couple days getting Webpack up and running and just got a test going. However I found that the bundle.js file that came out of webpack was doing a lot of unnecessary things that make no sense to me.
index.js
import greet from './greet';
console.log("I'm the entry point");
greet();
greet.js
function greet() {
console.log('Have a great day!');
};
export default greet;
So super simple. But bundle.js
!(function(e) {
var t = {};
function n(r) {
if (t[r]) return t[r].exports;
var o = (t[r] = { i: r, l: !1, exports: {} });
return e[r].call(o.exports, o, o.exports, n), (o.l = !0), o.exports;
}
(n.m = e),
(n.c = t),
(n.d = function(e, t, r) {
n.o(e, t) || Object.defineProperty(e, t, { enumerable: !0, get: r });
}),
(n.r = function(e) {
"undefined" != typeof Symbol &&
Symbol.toStringTag &&
Object.defineProperty(e, Symbol.toStringTag, { value: "Module" }),
Object.defineProperty(e, "__esModule", { value: !0 });
}),
(n.t = function(e, t) {
if ((1 & t && (e = n(e)), 8 & t)) return e;
if (4 & t && "object" == typeof e && e && e.__esModule) return e;
var r = Object.create(null);
if (
(n.r(r),
Object.defineProperty(r, "default", { enumerable: !0, value: e }),
2 & t && "string" != typeof e)
)
for (var o in e)
n.d(
r,
o,
function(t) {
return e[t];
}.bind(null, o)
);
return r;
}),
(n.n = function(e) {
var t =
e && e.__esModule
? function() {
return e.default;
}
: function() {
return e;
};
return n.d(t, "a", t), t;
}),
(n.o = function(e, t) {
return Object.prototype.hasOwnProperty.call(e, t);
}),
(n.p = ""),
n((n.s = 0));
})([
function(e, t, n) {
"use strict";
n.r(t);
var r = function() {
console.log("Have a great day!");
};
console.log("I'm the entry point"), r();
}
]);
It seems like WebPack is doing a lot of unnecessary code that just makes no sense to me. The bundle.js is also 3 times larger in file size than the index.js and greet.js. The development build of the app also just looks very confusing and messy for something so simple.
So why should I continue to invest time into using WebPack for my projects? What is all the extra code it is outputting and why is it there? Are the any better alternatives that will help me ship my code from a modular development environment?
I'd really appreciate your help in getting me to understand why I should or shouldn't use WebPack.
Thanks!
The bundle.js is also 3 times larger in file size than the index.js and greet.js
Webpack has to put in some polyfills for things the browsers are not capable of, module loading for example. If you got 2 lines of code, these polyfills look very heavy, however if you write thousands of lines of code, you won't notice any significant overhead, as those poyfills are only added once.
So why should I continue to invest time into using WebPack for my projects?
Cause it will produce smaller bundles for larger projects, also it allows you to write ESnext & clean, modular code.
What is all the extra code it is outputting and why is it there?
It keeps the global scope clean, adds some helpers and a module loader, then loads the first module:
// IIFE to keep global scope clean, ! to prevent Automatic Semicolon Insertion fun
!(function init(modules) {
var cache = {}; // cache the modules results
// All modules are in an array, their index is a unique identifier
function require/*n*/(index/*r*/) {
if (cache[index]) return cache[index].exports;
var context/*o*/= (cache[index = { index/*i*/: index, loaded/*l*/: false/*!1*/, exports: {} });
modules[index].call(
context.exports,
context,
context.exports,
require
);
context.loaded = true /*!0*/;
return context.exports;
}
require.modules = modules; // I'm not sure why?...
require.cache = cache;
// helper for adding a getter
require.addGetter /*n.d*/ = function(object, key, getter) {
require.has(object, key) || Object.defineProperty(object, key, { enumerable: true, get: getter });
});
require.prepareExport /*n.r*/ = function(export) {
if("undefined" != typeof Symbol && Symbol.toStringTag)
Object.defineProperty(export, Symbol.toStringTag, { value: "Module" });
Object.defineProperty(export, "__esModule", { value: true });
};
// I have no idea what that is doing
require.startModule /*n.s*/ = 0;
require(require.startModule); // start execution
})([
/* Your modules, identified by index */
function mainModule(context, exports, require) {
"use strict"; // better performance
require.prepareExport(export); // as you could override exports in your module, this has to be called afterwards
var otherModule = function() { // inlined!
console.log("Have a great day!");
};
console.log("I'm the entry point"),
otherModule();
} /* ... more modules would follow here if not inlined */
]);
Are the any better alternatives that will help me ship my code from a modular development environment?
There are alternatives, not sure if they are "better".
I agree that Webpack adds tons of cruft that you might not even need. It also has this crazy config file that borders on pure insanity.
For simplicity's sake, you can just load your module files with script tags, and toss Webpack out the window! (only in modern browsers (Edge16+, FF60+, Chrome61+,Safari11+)).
<script type="module" src="greet.js">
<script type="module" src="app.js">
You can also use simpler webpack alternatives like ParcelJS or Rollup. These pilers can all do lots of stuff, depending on what you need:
bundle.js file I've fought my fair share of battles with the bundlers. There are other ways. With a few years of experience and trial and error, the best alternative I've e up with is my project Zwitterion: https://github./lastmjs/zwitterion
It is designed to be a swap in replacement for a static file server. It supports ES2015+, TypeScript, AssemblyScript, Rust, C, C++ and will probably support JSX, TSX, and Vue soon. You don't have to change your file structure or the way you would intuitively develop. Just write your source code, include it with script elements or module imports, and it just works.