4 ms·

None of that code is any more clear, either conceptually or syntactically than a simply implemented and well designed library that does something purposeful and

None of that code is any more clear, either conceptually or syntactically than a simply implemented and well designed library that does something purposeful and applied, like their "application" of handling validation. And if you want "private" variables in javascript, just use a closure! Do people who write these blog posts even know basic javascript these days? If you really want all the features of java [said no one ever], than why don't you just.....use java?? It's just extra cruft we're going to have to support now in our javascript runtimes. </slams door>

nickfargo 10y ago
> just use a closure! Of course, but that means allocating a closure object per method per instance. When people say they want private variables, they mean they want them available in regular prototype-mounted methods. Proxies are one way ES6 lets you implement that. (Another is to use a WeakMap structure alongside a constructor, where each instance created by the constructor is mapped to a separate object that holds the "private" properties of that instance. Methods close over the WeakMap, but, crucially, are defined once on the constructor's prototype.)
- iamleppert 10y ago
  There's nothing preventing you from defining your private variable, method, whatever within the same scope as your prototype method. That could mean (for commonJS anyways) the same file. As long as you don't export those, they are effectively private.
  - Touche 10y ago
    Those wouldn't be private to each instance though, they'd be shared by all instances.
- adrusi 10y ago
  I suppose I don't know for sure how JS runtimes implement them, but closures ought to be very cheap. They just need a reference to a static block of code and to any variables declared or referenced within. The most expensive part of using a closure is a heap allocation, and one extra allocation while creating an object in javascript is almost always negligible.
allendoerfer 10y ago
Right when I started to enjoy the in some ways lisp-like style you can program in JavaScript all these ES6 stuff came along. I have to say, I do not like it either. The problem is that now the language becomes more and more impure introducing syntax and keywords left and right. The language lives inside browser. The old ways to do it will never go away, it will just get worse and worse and become a mixture of all kinds of patterns. All of this just because some people cannot wrap their head around scoping and prototypes. I am fine with the rapid pace of change in tooling or libraries, but I think browsers could improve in other areas (DOM), so we could still move forward.
- gavinpc 10y ago
  I agree with you and the parent, but let me play devil's advocate for a minute... CSS? Put that sh!t in feature freeze, like, yesterday. Because javascript. Javascript? Put that sh!t in feature freeze, like yesterday, because wasm. Except... at least the reflection API's seem to "get it"—that you can't just keep adding features willy-nilly. I'll take a new metaprogramming feature that deprecates an equal number of old ones. And if you look at the MDN article the OP referred to, the reflection API is apparently intended to obsolete several existing built-ins. And as the OP also indicates, Proxy also lets programmers implement things that would otherwise be the VM's job. But of course, unlike the auto industry, we can't actually realize obsolescence, so, like I said, I agree with you.
  - allendoerfer 10y ago
    True. I just fear that all languages are approaching each other until we arrive at some mess that is optionally statically-typed, object-oriented, but with functional patterns.
- girvo 10y ago
  > Right when I started to enjoy the in some ways lisp-like style you can program in JavaScript all these ES6 stuff came along. To be honest, it's _easier_ to do nice functional-programming in Javascript with ES6 in my opinion, just due to the cleaner syntax for destructuring assignment, lambdas, and block-scoped variables. See: https://github.com/hemanth/ramda-repl https://github.com/hemanth/ramda-repl
thenewregiment 10y ago
Says the father of JavaScript
qwertyuiop924 10y ago
Well, if you weren't careful and didn't use UAP, proxies can save your bacon. They are also useful for object.observe like functionality. And that's pretty cool.

nickfargo 10y ago

> just use a closure! Of course, but that means allocating a closure object per method per instance. When people say they want private variables, they mean they want them available in regular prototype-mounted methods. Proxies are one way ES6 lets you implement that. (Another is to use a WeakMap structure alongside a constructor, where each instance created by the constructor is mapped to a separate object that holds the "private" properties of that instance. Methods close over the WeakMap, but, crucially, are defined once on the constructor's prototype.)

iamleppert 10y ago
There's nothing preventing you from defining your private variable, method, whatever within the same scope as your prototype method. That could mean (for commonJS anyways) the same file. As long as you don't export those, they are effectively private.
- Touche 10y ago
  Those wouldn't be private to each instance though, they'd be shared by all instances.
adrusi 10y ago
I suppose I don't know for sure how JS runtimes implement them, but closures ought to be very cheap. They just need a reference to a static block of code and to any variables declared or referenced within. The most expensive part of using a closure is a heap allocation, and one extra allocation while creating an object in javascript is almost always negligible.

allendoerfer 10y ago

Right when I started to enjoy the in some ways lisp-like style you can program in JavaScript all these ES6 stuff came along. I have to say, I do not like it either. The problem is that now the language becomes more and more impure introducing syntax and keywords left and right. The language lives inside browser. The old ways to do it will never go away, it will just get worse and worse and become a mixture of all kinds of patterns. All of this just because some people cannot wrap their head around scoping and prototypes. I am fine with the rapid pace of change in tooling or libraries, but I think browsers could improve in other areas (DOM), so we could still move forward.

gavinpc 10y ago
I agree with you and the parent, but let me play devil's advocate for a minute... CSS? Put that sh!t in feature freeze, like, yesterday. Because javascript. Javascript? Put that sh!t in feature freeze, like yesterday, because wasm. Except... at least the reflection API's seem to "get it"—that you can't just keep adding features willy-nilly. I'll take a new metaprogramming feature that deprecates an equal number of old ones. And if you look at the MDN article the OP referred to, the reflection API is apparently intended to obsolete several existing built-ins. And as the OP also indicates, Proxy also lets programmers implement things that would otherwise be the VM's job. But of course, unlike the auto industry, we can't actually realize obsolescence, so, like I said, I agree with you.
- allendoerfer 10y ago
  True. I just fear that all languages are approaching each other until we arrive at some mess that is optionally statically-typed, object-oriented, but with functional patterns.
girvo 10y ago
> Right when I started to enjoy the in some ways lisp-like style you can program in JavaScript all these ES6 stuff came along. To be honest, it's _easier_ to do nice functional-programming in Javascript with ES6 in my opinion, just due to the cleaner syntax for destructuring assignment, lambdas, and block-scoped variables. See: https://github.com/hemanth/ramda-repl https://github.com/hemanth/ramda-repl

thenewregiment 10y ago

Says the father of JavaScript

qwertyuiop924 10y ago

Well, if you weren't careful and didn't use UAP, proxies can save your bacon. They are also useful for object.observe like functionality. And that's pretty cool.