proposal-private-methods

ardless) would have been a much more effective way to do this. I'm shocked 5 version sin we don't have this as the default...leaving it up to the user to create a very basic abstraction around this just irks me, as I don't see how consumers benefit from that. Yet, I don't want to create _yet another library_ since redux is so well entrenched. Internally where I used to work, we had a library that basically was just what I described. You specified a special prop on a component and any reducers were created from a factory that respected the prop, worked well enough. Now, with that said, I have to say this: I think JavaScript is a great language. I think TypeScript is an even better manifestation, despite some quirks. Now, onto some technical bits. Classes are more than just fancy wrappers on prototypical inheritance. The way its going with the standards committee, and the way I've interpreted the point of having classes, is to have formal encapsulation[0]. With things like the private fields & method proposal[1] already well on their way to formal standardization, classes are starting to make more sense. They also provide a way to extend builtins in a way the engine understands (This is also the logic behind Web Components I feel like everyone misses, but that's another story). While I know there is plenty of object oriented pitfalls everyone has seen, like abuse of inheritance, I find that the very common pre-class way was just, if not more so, prone to pitfalls. Extending classes is pretty obvious to most programmers - I mean this in terms of syntax and typical expected behavior - I coded up a simple example here to illustrate just how gnarly ES5 "classes" are. https://gist.github.com/ScottAwesome/67d2d10761bd4993eec9d9d... I also think classes provide the correct abstraction for exposing public and private APIs, as I already mentioned the private fields and method proposal, but also its more conventionally straightforward to encapsulate this even using a WeakMap to make private methods/fields unexposed to the consumer, (one of its primary use cases when it was introduced). Plain objects, without some sort of system to manage their creation (like factories) and their visibility (Object.seal, Object.freeze, Object.preventExtension, Object.DefineProperty - all of which work on classes too, of course), they're otherwise going to leak their members and its all too easy to find private APIs on object members. I know you can with classses - sans using a WeakMap or the new private fields API. I find it feasibly easier however to integrate classes when I need to encapsulate a well defined interface with properties & methods, in large part because I can keep the private APIs private more easily, via an internal WeakMap, without sacrificing extensibility. I know you can do this with objects, however its much more clear that you get a discrete instance with classes. When that sort of thing is important, I think classes are useful. I also think there is a lot of value to the mixin pattern. I also think this reaches into what most developers just expect out of a language. Arguably, the complete lack of usage of the Reflect[2] APIs I see in the wild and where I've worked tells me most people just don't reach for these kinds of APIs. Therefore from a language development point of view, I can't argue classes are bad, either. Now I understand you can get there with plain objects, and I think this is an under-utilized mechanism of the language. In fact, I think the plain javascript object are amazing, and very few languages have such a powerful construct. I'm a big fan of composition over inheritance (to which end I have leveraged the stamp specification and its toolkit[3]. I think it would have been nice to see more specialty objects (with a static `Object` factory to create them) over having to just introduce classes. Alas, they are here to stay. Truth be told, I don't use classes that often, preferring pure functions & plain objects most of the time, but sometimes there just isn't a better way to encapsulate behaviors than the a class, in fewer lines of code, that's easy to reason about and maintain. Now one trend I don't like, is that a lot of things are becoming class only APIs (Web Components being a major one). This complicates things, but you can certainly 'hide' the implementation details via factories if you don't want to expose classes directly, so far in these cases, that's pretty straightforward to do. Worth noting: I'm just not strongly opinionated enough to say you're right or wrong on this. We already acknowledged a massive education problem in the industry, one that, I will admit is in my personal experience seemingly true, that not enough people take the language serious enough to spend the time to learn how to work with it appropriately. Until that's solved, I don't think its worth fighting over other minutiae in this particular discussion. Solving the problem of good developer evangelism in the JS ecosystem is a discussion for another time, though, and one that will ultimately be futile if we can't get the major stakeholders to have some agreement on what that means. [0]: https://en.wikipedia.org/wiki/Encapsulation_(computer_progra... [1]: https://github.com/tc39/proposal-private-methods#private-met... [2]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [3]: https://github.com/stampit-org/stamp-specification