1. 0
    Webpack ignores 36 years of history javascript github.com
  1.  

  2. 27

    I don’t know about others, but I don’t enjoy seeing flamebait like this being posted to Lobsters. The actual relevance is almost zero. The only appeal I can see is that it’s a skillfully written put-down.

    1. 8

      A diff would have made it less flamebait (and a diff that made it use Makefiles would have been epic!).. but I think the point is very valid. The common trend in the industry in general seems to be “this tool is old and crufty, I will do it better with something new”.. meanwhile they didn’t have a full grasp on what that old crufty tool solved.. so they fall into all the same pitfalls.

      1. 5

        Agreed. It’s a troll, and not even a good one.

        Use make to run webpack. gcc doesn’t check file times, either, and neither do most code transformation tools, because that functionality is already in make.

        1. 1

          I thought about writing a blog post about this but I thought the GH issue illustrates the point fairly well. It’s a common problem with build tools written in Javascript.

          I could switch the title to match the issue title.

          1. 9

            I could switch the title to match the issue title.

            That would be an improvement. But to be clear, I also take issue with the way that the issue is written. Compare:

            A: “Hey, could we check timestamps on output to avoid unnecessary work?” B: “Webpack doesn’t even check timestamps on outputs? LOL. Even make, released 46 years ago, does that!”

            This feels a lot closer to B, which is why I described it as a put-down.

        2. 7

          The “problem” identified by this issue is easily solved by using Make to run Webpack:

          output.js: static/one.js static/two.js
              webpack
          
          1. 5

            This seems like useful behavior if the clocks on the system you edit inputs on and the system you run webpack on aren’t synchronized, such as they might be with Vagrant or Docker. Spending some cheap CPU time to avoid much more expensive user confusion seems like a valid strategy.

            1. 9

              Good lord, stupid workarounds for stupid systems are why we’re drowning in shitty software.

            2. 1

              I hope we can all appreciate someone with a “Go Contributor” hat posting this sensationalist post title.