> If you want to use any bundler or build tool created in the past 15 years, it's going to use closures for anything but the most recent projects. CommonJS whic

> If you want to use any bundler or build tool created in the past 15 years, it's going to use closures for anything but the most recent projects. CommonJS which is still ubiquitous in NodeJS is literally closures. When it was created, it literally wrapped your file in a function that passed in some variables like global or import then called eval on the module it had now created. These are all implementation details; they couldn't matter less to most application developers. I've been writing JS for a decade and while I roughly knew that bundlers did something like this, I've never once had to deal with it directly. > If someone doesn't know how the module pattern works, they are a junior JS dev and absolutely cannot move on with their career until they understand. This is extremely not true. Knowing how modules are implemented under the hood is a concern of people who work on bundlers, transpilers, etc. For regular devs, an airtight abstraction is presented and it never needs to be more than that. It's wildly wrong to suggest that a person can't be productive at more than a junior level without knowing how this particular sausage is made. > When you look into the people pushing for these features, you almost always find a Java or C# developer. There's not a mass push by JS devs to add these features. Hello. I'm a JS dev who hasn't written Java or C# in over six years, who wouldn't want to write either of them, and yet I think private class members are valuable enough to have them in the language. > even if you and your particular set of devs do not I'm talking about the average JS dev doing mainstream JS work, here. I argue that ES classes are useful and mostly devoid of footguns for most, realistic, usage in industry. Not just for myself or for one particular team. In all I think you're taking a fairly extreme purist stance, where people are disallowed from being productive with a given technology unless they have a deep understanding of how it works underneath. That deep understanding is great to have - it's part of what makes a good lead dev - but plenty of people out there are plenty effective working off of provided abstractions, and it's narrow-minded to dismiss that fact.