Fantastic, now what if your domain model actually requires an underscore in things? Or more realistically umm ... ooh ... I dunno, how about I want to write some infrastructure, that iterates over objects? Surely, that's not a thing we use literally all the time. But hey, just write the code to filter out underscores.

Oh wait, now I'm passing my object to a third party library that preforms infrastructure? I guess they better provide a hook that I can inject my own naming conventions.

Yes, underscore fields work, until they don't. Is a function that returns an object really that hard for beginners? I can answer that as I actually teach beginners - yes, it's hard for like two class sessions, after the third homework assignment they have no other issues. So yeah, closures are the way to solve this.

I wouldn't use what this article proposes unless I definitely needed classes, but for the 1% of the time that I do this is a pretty nifty solution to one of my biggest gripes.

I like the simple syntax of the underscore convention, and I also appreciate that the article's approach actually enforces the encapsulation. I wonder if there's a convenient way to use this structure and also keep the simpler syntax.

Heck, you could probably make a macro such that `this._foo` compiles to `this[privateProperties.foo]`, but I'd probably scream about how misleading that is…

What are the reasons for keeping components of a 'thing' private? I go back and forth on this.

1. expose a clean API surface so users don't care how it works (as long as it works :)

2. make it easier to change the innards without changing its public behavior

3. keep malicious programmers from delving into the innards of our precious code.

It seems like a lot of the discussions on encapsulation (over many years) focuses on #3. Especially in the C++ and Java world. But worrying about that leads to various forms of obfuscation that make the code worse. And who cares about folks who will hack our objects? That's their problem.

It doesn't have to be "malicious" programmers. It can be less experienced, lazy, or under-pressure colleagues.

You can't check that the convention is being broken which makes refactoring more difficult. There will always be a temptation for some developers in some situations to mess with the internal state of objects.

In general, js is more about good practices and craftsmanship, and less about finding ways for the language to force people to do things.

I find this argument to be lacking; if you're using good practices and craftsmanship then nothing is being forced on you as you would not encounter an error for doing something improper.

I prefer to mark up my code as private/protected/public for my own purposes both as built-in documentation and to have one less thing to think about after it's done. Plus underscores are ugly.

Yes, but you have to do a lot more typing, plus you have to do a lot of things to satisfy a stricter language. There are a lot of abstractions like interfaces, delegates, etc, that exist to get certain logical patterns past the language's strictness. In loose languages you can just write the patterns you want without the overhead.

In other words, with less strict languages you can be sloppier. Once projects get to a certain size, language strictness is a huge benefit.

And, in some extent, it's actually freeing. I can reach in and change something big in a strict/compiled language and the compiler/IDE will tell me where I have to make other changes throughout the whole project. In a dynamic language, I either have to rely on unit testing, grep, or just having it break at runtime. But the real truth is, you just don't make those kind of changes when your language isn't strict. The pain isn't worth the payoff.

Developers willing to make messes in the code must be identified ASAP, and the "_" acts as an easy to see red flag.

As they say in Python - we're all consenting adults.

Python has been doing this forever and it just works. Objective-C has had access modifiers and such but I find nobody uses them either. It's a baroqueism.