5 ms·

How do you end up with like six "build systems" for web applications? What even is there to build? Why can't you concatenate all javascript and run it through a

• chj 9y ago
  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.
  • rimliu 9y ago
    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.
• duval 9y ago
  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
  • pdkl95 9y ago
    > 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)
    • ricardobeat 9y ago
      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.
      • RonanTheGrey 9y ago
        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.
    • RonanTheGrey 9y ago
      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.
• ahacker15 9y ago
  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 https://github.com/tdewolff/minify/tree/master/cmd/minify