Yours do that if you want, but then you might have customers using large parts of the code base that other don't have access to so you want to use code splitting. You probably have some images and want them to look good on all screens but also want them to be a small size so you use image srcset but you need to output 6 images for all the sizes. If you're using svgs you might want to inline these. I mean it goes on and on really, just look at all the headings within the webpack docs if you want more insight. I can understand why it seems crazy and perhaps it is more crazy than I think but if you want you can just concatenate all the scripts, if you want more bells and whistles then you can too

> code splitting

That should only take a few lines in a Makefile.

    JSTARGETS = foo.js bar.js
    
    build-js: $(JSTARGETS)
    foo.js: foo_main.js lib_a.js lib_b.js
            cat $< > $@

    bar.js: bar_main.js lib_a.js lib_x.js lib_y.js
            cat $< > $@

With make's builtin topological sort, adding dependency information to control the order or other unusual build requirements isn't hard to add.

> output 6 images for all the sizes

    IMAGES=( baz quux )
    IMGSRC=(patsubst %,src/images/%.jpg,$(IMAGES))

    IMGSML=(patsubst %,build/images/%-small.jpg,$(IMAGES))
    build/images/%-small.jpg: src/images/%.jpg
            convert $< -resize 25% $@

    build-images: $(IMGSML)

The main difference is that the JS source is being parsed, and most of the build steps operate on the AST. This is what allows things like transpiling modern language features to more broadly supported versions, doing dependency resolution, pruning, and automatic splitting (imagine your Makefile with 300 js files). Remember that JS does not yet have a built-in module system - simply pasting source files together means you'll be rolling your own.

Yep, alot of people forget that - because JS is delivered to the browser and not preemptively downloaded (or executed in a compiled form on a server), there's NO opportunity to do things like optimization, tree shaking, etc. that other JITs do, or compiled languages do.

And the moment you accept that it is necessary (and why wouldn't it be - languages are for developers, not computers, and that means they by necessity will include cruft), you require a build system to at the very least, run the optimizer and minimizer.

It seems like a trivial problem but it isn't. We are long past the days when JS was only used to make an image blink.

In fact this is exactly what early JS build systems looked like. When I worked at Bing this was exactly what the production deployment script looked like (at a simple level).

It no longer does. The tools move on because the uses get more complex. See the sibling reply here for a good reason why.

Minify [1] is a great alternative, specially if you use Go. For simple case, you don't need Node ou NPM at all.

[1]: https://github.com/tdewolff/minify/tree/master/cmd/minify

One thing I like about JS is that you don't need to compile or build anything. I get it that you will need to bundle everything in production, but I am baffled that bundling can't be automatically done. The process should be transparent to developers.

if you use ES6+ and target not so capable browsers, if you use JSX you need to compile. And while you can write React without the JSX it is not something anyone would enjoy.