Hacker News Reader

Comment by gengen | Hacker News Reader

What I've always loved about Make and related tools is how directly they expose their fundamental concept in building artefacts: the DAG. I don't do that much JS, but I've not found this kind of clarity in any of the JS frontend build tools I've used.

Honest question for the webpack power-users here.

What are some important webpack features that you lose by using a Makefile like this? Because it seems like pretty much every part of a regular webpack buildchain has a command-line equivalent that you could potentially use in a Makefile.

View on HN

You wouldn't want to use it as a replacement for webpack, you'd use it alongside webpack. Webpack does a ton of stuff for Javascript compilation - heavily cached and optimized recompilation, module rolling, hot reloading, etc.

Make is for performing any variety of commands, most of which don't fit into webpack - deploy scripts, git scripts, whatever. It's a unified entrypoint for scripts project-wide. It's not a great resolver for JS dependencies, but it's a great resolver for "I need freshly-compiled JS baked into a docker container and uploaded to my docker repo".

Having something like Make is especially important in large teams in my experience. Under-the-hood tooling can often change (NPM -> Yarn, needing different test suite arguments, new docker commands, whatever) and having a single expected API for developers across your teams is particularly useful when you're the person working on dev tooling. Knowing `make test` should prepare and run a test suite or `make run` should run an app no matter which repo you're working on gives devs a consistent development workflow.

I don't know enough about make to know if this is correct, but the post last week on using make for js started of by saying "If you are writing a frontend app and you need code bundling you should absolutely use Webpack" which, aren't the majority of people using webpack writing frontend apps and need bundling?

The other issue is that essentially no one uses make in frontend development. So you go and convert to make from something that was working fine and is the standard in that part of the industry and what's the pay off? Now no one in your team or who you hire knows how to change the build chain? Great.

> aren't the majority of people using webpack writing frontend apps and need bundling?

Webpack is pretty new. Lots and lots of websites were developed before webpack existed, and some of them still use make for builds. The majority of new web projects are probably webpack now.

> The other issue is that essentially no one uses make in frontend development.

I don't know how many people do or don't use make, but I've had two web jobs that did. One was my own company and I wrote the makefiles, so that's not exactly fair. :P The other was an established web app. In both cases, the biggest reason for the makefile was to integrate the Google Closure Compiler into the build. Last time I checked, Webpack didn't have support for the Closure compiler. I am aware that the Closure compiler isn't exactly the most popular js minification tool today, and isn't generally necessary with webpack.

> So you go and convert to make from something that was working fine and is the standard in that part of the industry and what's the pay off?

I agree with you generally, but I'm old enough that this also makes me chuckle a little. make was working fine and was the industry standard for decades before webpack or npm.

Just before Webpack there was Gulp, and Gulp is essentially a re-invention of unix pipes and lots of the unix tools. Build systems made with gulpfiles have to bend over backwards to get right make's basic concepts like dependency evaluation, building a target only once, and skipping already built targets.

There's a reasonable chance I'm older than you for what it's worth.

While not nearly as popular as Webpack, Broccoli.js (used by Ember, among others) exposes the DAG concept. Webpack is fine if your task roughly matches the purpose Webpack was built for, but when using it I miss the composability of Broccoli. There's a good architecture overview here:

https://www.solitr.com/blog/2014/02/broccoli-first-release/

This is arguably not a great reason to use make at all but like another user replied, you’d use it alongside webpack

I originally did think about forgoing webpack but it does it’s job nice enough

https://github.com/shmup/react-makefile/blob/master/Makefile

> What are some important webpack features that you lose by using a Makefile like this?

Transparent cross-platform usage, specifically on Windows. Yes, you can set up Make on Windows, but it's not really the norm, especially for web developers.

You lose the simplicity of copy-pasting someone else's webpack config and then morphing it into something that works for your project.

There are tens of thousands of examples to choose from. For a makefile-based webpack, there are zero.

Unfortunately concerns like this matter.

What does building a JS app take? Linting maybe, then concatenating files, minifying them. Then there should be some maintaining tasks, like updating dependencies, testing, deploying. Am I missing anything (serious question, I'm rather unfamiliar)?

Minifiers can remove dead and unaccessible code.

They can also rename function and variable names with shorter ones, and compile code to be shorter (marginal gains since it's all going to be served compressed).

Reply on news.ycombinator.com