The saving grace of frontend is that debugging is really easy. You can inspect the actual code of all your dependencies in node_modules, and they're almost alwa

The saving grace of frontend is that debugging is really easy. You can inspect the actual code of all your dependencies in node_modules, and they're almost always on github too (in case they bundled/minified code). The programs are mostly single-process and single-threaded. The same Chrome devtools you use to debug in the browser are used to debug NodeJS code. Yes, it's stupid that sometimes you have to set a breakpoint inside a webpack plugin to figure out what's going on, but at least it's an option. And as other commenters have echoed - you don't have to use any of this stuff. Most of it is short-lived and low-quality anyway. Half the time it's just an excuse for someone to write a blog post for clout. Expertise is as much about filtering out noise as it is digging deep into things. People complain a lot about bundlers in particular. Bundlers are "just" string concatenation. It's an easily understandable problem with a lot of weird edge cases. So you wind up with bikeshedding and a lot of bundlers and what looks like unnecessary complexity. But there's little payoff to really "learn" a particular bundler. It's more important to learn why bundling is necessary (the Vite FAQ does a decent job of this) and then some of the features that can make it complicated (e.g code transformation). Then you become an expert on the underlying problem of shipping the minimal amount of code to the browser, which isn't going anywhere. You can then understand what differentiates bundler A from B. It's usually not much beyond a simpler config file. Despite all the new hotness that exists today, the outdated Webpack 4 has feature parity with pretty much any bundler out there.