Hacker News new | ask | show | jobs
by Animats 4034 days ago
In practice, that turns into far too many ways of defining classes in Javascript. There are at least four major approaches, and that was last year.
2 comments

If you want something that isn't in the language, you build it yourself. If what you build becomes popular, in the fullness of time it gets built into the language as a full feature or as syntactic sugar. That's exactly how we got the class keyword, modules, everything.

But if you choose the wrong thing, one day your choice is obsolete. That is a risk, and it's prudent consider the consequences carefully.

If that troubles you, by all means write your code without any encapsulation, and wait for the language to acquire the feature in a few years. In the mean time, your code base will grow without that kind of encapsulation. Only you can determine whether this is a bad thing or not. YMMV, and all that.

This is a very common problem to ponder, we end up arguing about whether you should be an early adopter, a main streeter, or a laggard.

But really, the post isn't a screed in favour of using private properties, it's a suggestion that making classes out of first-class values in the language gives us the flexibility to build whatever we think we need.

Private properties is a particularly simple example. Traits and mixins are also useful, but would take even more space to articulate. But the general point is still that making new things ("classes") out of the existing materials ("functions and prototypes") is a win in general.

That's part of why I think CoffeeScript isn't going anywhere anytime soon.