Why use WebPack?

Question

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 unnec

Answer 1

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 come up with is my project Zwitterion: https://github.com/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.

Answer 2

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".

Answer 3

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 compilers can all do lots of stuff, depending on what you need:

• bundle your modules into one big old bundle.js file
• make code compatible with older legacy browsers.
• transpile scss into css, typescript into javascript, etc.
• start a development server with automatic reloading
• build your entire website folder, including only files that are actually used in the project.