Hacker News Reader

Comment by Ambroos | Hacker News Reader

It's a convenience thing. Once you get used to it, it works well. You define a loader in your webpack config, which then decides what to do with the PNG.

Usually, what happens if you require a PNG is that it passes via url-loader or file-loader, and optionally image-loader. This'd mean that you'd get a string (either a full URL or a base64-encoded inline image if it's small enough) that points to the image, which is optionally minified by image-loader.

If you require CSS or SASS, your webpack loaders will ensure the CSS is loaded.

View on HN

No, I get what is trying to be achieved, I am just questioning why it is being done this way and not something much simpler... I would much prefer that my JavaScript bundler only bundles JavaScript. Converting a PNG into a JavaScript module through base64 should be pretty trivial, so I'd prefer to do that with another tool. I do something similar for inlining CSS in my own projects.

You can use one tool to optimize and base64 inline images and another to compile SCSS and inline it of course. But then you discover that you also want to optimize and inline images placed within css url() properties so you implement that feature in your build pipeline, then you discover... you get the point. Webpack gives you a flexible configurable and extensible way to handle any such case in any environment which is why everyone uses it for modern frontend development. I think questioning webpack is like questioning why people are using dependency injection frameworks in modern java.

And then you wind up spending multiple days trying to figure out how to do something that doesn't quite fit in with what other people have already done.

How many times do we have to learn the same lessons over and over? Small tools that compose together is infinitely more flexible than any plugin based tool can possible be.

Importing PNGs to JS is about dependency-wrangling, not task-running.

That is, the point of using webpack isn't that it's the best way to optimize a bunch of PNGs. The point of webpack is that it can parse your dependency tree and figure out which PNGs are depended on by a given entry point. If you also want your PNGs optimized, you can do that with a webpack plugin or a separate tool, as you like - that's orthogonal to the matter of why it's useful to import PNGs into JS.

Yeah, sorry but I don't buy that. webpack outputs JavaScript bundles, not a dependency graph. Importing PNGs into JavaScript is only useful if you use a JavaScript AST to then do something with those imports.

I'm not selling it, and I don't follow what you're disagreeing with. Webpack can output JS bundles, but it understands dependencies between non-JS assets as well, and will process any file in the dependency graph any way you like.

As such the point of requiring a PNG into JS (or CSS, or a Vue/React component, etc) is to tell webpack there's a dependency on it. Then that image will get pulled in to the build process for entry points that need it, and not otherwise.

I'm sorry, but what is wrong with the <img> tag?

Reply on news.ycombinator.com