Hacker News Reader

Comment by tonyhb | Hacker News Reader

Recently moved to this from webpack 1 for both personal projects and work. Webpack 2 combined with Yarn running inside of Docker to automate builds is the nicest (and fastest) frontend build pipeline I've had yet.

The experience with Webpack2 is so much better:

  - Cleaner documentation

  - Saner configuration files:

    - It errors out if you add incorrect flags!

    - This means that postcss et. al. use config files

  - Saner module definitions (now called rules):

    - No query flags!

    - Actual object support!

Plus tree shaking, code splitting etc. It's way better. Now looking forward to integrating babili within webpack to remove uglify.

If you're thinking of upgrading it's not that much effort given the new documentation, too. Definitely worthwhile, and there seems to be less occasional build bugs using this with newer babel plugins (originally switched because of a crazy stackoverflow parsing a two-deep object).

View on HN

> Webpack 2 combined with Yarn running inside of Docker to automate builds is the nicest (and fastest) frontend build pipeline I've had yet.

See, maybe this is the get-off-my-lawn coming out of me but it pains me that that complex setup is the nicest and fastest frontend build pipeline you've had.

Almost a whole decade ago we had pretty simple and straight forward build patterns for frontend. Essentially running the site as is from the VCS was in "debug" mode and you'd write scripts that combines and minifies everything and plugs it right back into the html when you "build" it. And that it was it. Simple and fast.

I'm sure using ES2015, TypeScript, SCSS, handlebars and a million other things that get transpiled, concatenated and minified help with productivity for some people but it just seems insanely overly complex to me especially when half of the examples that show how "simple" many of these technologies are can also be made very simple using standard API calls.

I like things simple. As simple as possible. Webpack is probably not for me but I wanted to provide my own perspective to see if anyone shares it or if I'm more of an outlier.

I think it really depends on what you work on.

> Almost a whole decade ago we had pretty simple and straight forward build patterns for frontend.

a decode ago, we didn't really build web apps like today though. The browser landscape was different. The technology was different.. but the most important: the expectation was different. Man, 10 years ago we still had flash.

> [...] help with productivity for some people but it just seems insanely overly complex to me

It is. To be honest, if I'd start today, I'd be super lost too.. but it is a one-time cost/investment to start to gain that productivity.

I think the biggest upside of this whole thing is working at scale in terms of human. Good modularization allows you to achieve this.. in the old school day, that was either a big javascript bundle, or a bunch of them inserted in the pages as global.

My opinion is: if you think you don't need it, don't bother with it. I didn't understand webpack until I needed it. I didn't understand React until I needed it. I didn't understand docker and kubernetes until I needed it. Trying to force yourself to use thing when you don't see the usefulness is counter productive.

Fair enough though

> a decode ago, we didn't really build web apps like today though. The browser landscape was different. The technology was different.. but the most important: the expectation was different. Man, 10 years ago we still had flash.

Other than dealing with more browser incompatibilities that we have less of most of my work was still fairly complex web applications. We just didn't have many if any frameworks so depending on the experience of the starting developer you most likely walked into a wall of spaghetti which I understand frameworks can sometimes help even new developers write cleaner code.

Also Flash was amazing back then, heh :)

Go build a simple website and use simple tools. It's that easy - people are still using `cat`, right? I just deployed a site that's just all just one HTML file with inline CSS and JS tags. 'Deploying' is as simple as copying the source files up to S3.

Meanwhile, I'm working on _another_ site that requires the hybrid approach of SPA for smooth transitions and caching and what not, yet the SEO and first-boot speed of a server-side-rendered site. This (obviously) has a more complicated build 'pipeline' to achieve a more sophisticated feature set.

I was only referring to web applications. Websites I would expect to be pretty simple and straight forward. Simple tools can be used to build both. Simply because you use simple tools doesn't mean you can't create the necessary complexity.

How have you found plug in support? The new features, etc look great, but I'm worried that there will lots of plugins that simply don't support the new version, or only have buggy bleeding edge versions that do....

There's `webpack.LoaderOptionsPlugin` which allows backwards compatibility, generally solves the problem.

One word of warning: LoaderOptionsPlugin _may_ mess with "context", so you should always redefine it in each plugin option object.

For example, using PostCSS without a .postcssrc:

    // postcss hasn't yet started to use options within rule definitons of
    // webpack 2; instead, we use a LoaderOptionsPlugin which provides
    // webpack 1 support of options to postcss.
    // https://github.com/postcss/postcss-loader/issues/92#issuecomment-251439696
    new webpack.LoaderOptionsPlugin({
      options: {
        // See https://github.com/postcss/postcss-loader/issues/99#issuecomment-248878925 and
        // https://github.com/webpack/webpack/issues/3018#issuecomment-248445176
        context: __dirname,
        postcss: [
          require('postcss-mixins'),
          require('postcss-simple-vars'),
          // TODO: Remove and use css variables (http://cssnext.io/features/#custom-properties-var)
          require('postcss-constants')({
            defaults: defaults
          }),
          require('postcss-each'),
          require('postcss-cssnext')({
            browsers: 'last 2 versions',
            features: {
              // https://github.com/robwierzbowski/node-pixrem/issues/40
              rem: false
            },
            import: true,
            compress: false,
            messages: true
          }),
          require('postcss-nested'),
          require('lost')
        ]
      }
    })

You can get around this by using a postcss plugin to read from the common config file (.postcssrc iirc) also, but I depend on requires for postcss-constants so couldn't.

Also, if you find a plugin or a loader who is struggling to support or catch up, just drop us a message on github or tweet me at @thelarkinn, and myself or one of the other maintainers will offer to help or take over the plugin. We have a whole contrib team dedicated to helping maintain our core org loaders and we are always wanting to keep the ecosystem strong and up to date.

Thank you for your hard work! You people are helping web developers tremendously.

Reply on news.ycombinator.com