[jupp0r]

I never understood this argument. You are optimizing for a few seconds per day of saved waiting time. You buy that by having to deal with obscure differences between browsers, excluding some users, potential performance problems through lack of tree shaking, missing type safety, etc. Sure it's a trade off but for any non trivial project I've worked on it heavily skewed towards using something like webpack and babel. If you mix in things like web workers, webaudio or wasm, it gets almost impossible to use without a bundler, because otherwise library developers that use {wasm,audio workers,web workers} as an implementation detail of their libraries would leak that implementation detail out all the way to deployments (because these have to be in separate files if they aren't bundled in). Insanity.

[fenomas]

Arguments against bundlers always sound to me like a person who lives next door to their job saying "I don't get why so many people commute by car, walking works just fine".

That is - some projects don't need a bundler, and for those projects, sure, do whatever. I don't think webpack is in any danger of becoming the new jQuery, where devs add it to every project because they don't know how to work without it. People using bundlers are usually doing stuff that can't be done without them, which obviates the whole argument.

[QuadrupleA]

It's more about reducing complexity than the build time I'd say. I work in C++ too, and a couple seconds of compile and run isn't the end of the world.

I don't personally have to deal with browser differences because I stick to subsets of CSS / JS that are 98%+ supported. If all your polyfills just compile down to minimal compatible JS anyway, then maybe those language features aren't that crucial. Always try to solve the problem without the new feature - almost every time I've tried this I find I get a simpler, more maintainable result without it, e.g. simple callbacks instead of promises (sacrilege), var instead of const/let (your poor namespaces), the word “function" instead of an arrow, etc. Those are probably close enough to supported to start using now, though not sure I care. Template literals might be nice, sounds like support is close.

Re: typescript, even coming from the C world, I don't personally find type safety to be a deal breaker. I work on some large python codebases - dynamic typing makes a lot of things much easier and more concise, in exchange for not catching some errors during compile. It's a tradeoff.

Avoiding all this build nonsense does make it harder to use some libraries that come out of the crazy modern node / javascript world, but in general most good ones have release builds, and I find a bit of healthy distance from the technical tail-chasing of that ecosystem is good for productivity.