7 ms·

I honestly think the newer ECMAScript features with static blocks, private fields are a little strange. I get that some people really want JavaScript to be obje

by geewee 5y ago

I honestly think the newer ECMAScript features with static blocks, private fields are a little strange. I get that some people really want JavaScript to be object-oriented - but I wonder if we wouldn't be better off embracing and building on its functional side.

fiddlerwoaroof 5y ago
The worst part is that the syntax is designed to make JS look like other object-oriented languages without changing the prototypical object system to match the semantics of such languages.
nicoburns 5y ago
Yeah, I find them utterly bizarre. I find it hard to believe that people using private implementation details is a real problem that people have. Underscore prefixing is a well-established convention within the JavaScript ecosystem, and with typescript it's easy to hide fields from the static types. I'm usually up for new language additions, but I can't see the benefit to this added complexity at all.
- vaughan 5y ago
  It's driven by library developers wanting to prevent access to internals. I was annoyed by it initially because I love poking around in internals and it makes it easy to add missing functionality or fix bugs, but I can kind of understand from popular library maintainers. If Bar depends on a private internal of Baz, and Foo depends on Bar, then if Baz publishes a patch version that changes an internal to fix a bug, Bar breaks, and so does Foo.
  - ectopod 5y ago
    Can't you already hide your implementation details using a closure?
    - kccqzy 5y ago
      Yes you can. But few libraries actually do that.
  - nicoburns 5y ago
    I think React have the right approach. If something isn't part of the committed to public API, then it's named `__unstable_foo`. Consumers of the library are free to use them, but they can and will change at the whim of the maintainers regardless of any stability guarantees that the library usually provides. This allows advanced consumers to tinker where they need to and are prepared to take on the maintenance while leaving potential complainers no leg to stand on if the API changes.
xpressvideoz 5y ago
Some JavaScript people have been hostile to functional concepts since the beginning. See the missed opportunity to make Promise a monad.[1] [1] https://github.com/promises-aplus/promises-spec/issues/94 https://github.com/promises-aplus/promises-spec/issues/94
- Waterluvian 5y ago
  I’m curious if someone can sell me, practically, in relatively few words, what that would gain us compared to Promises today. That link wasn’t sufficient to teach me. I’m a bit dense. :(
  - hajile 5y ago
    Basically, the current promises take a shortcut. If your promise returns a promise, the two promises are automagically combined into one promise. foo .then(() => returnsAnotherPromise()) .then(() => { /*only receives the nested promise*/}) The correct solution would not automatically flatmap foo .then(() => returnsAnotherPromise()) .then(innerPromise => { innerPromise.then(() = {}) //now we have access to the nested promise }) The second API is easier to statically type (creating a type that automatically, but conditionally removes a type is not necessarily0 easy). The second API makes some abstractions easier. The second API more intutitive for most people new to promises (I've seen it done a lot -- especially a few years ago). The second API allows you to interface with other monads without constantly having to do a special conversion any time you touch a promise. The current API is way more ergonomic for most current developers. In any case, it seems like there should a way to create your own proper monad promises along with an interface to normal promises when needed.
    - Waterluvian 5y ago
      I’m surprised to discover that promise flattening. Never noticed it before. Thanks!
brundolf 5y ago
IMO classes are almost pointless without private fields; hiding state (in the handful of cases where that's really actually what you want) is one of their main legitimate uses But using static members in a language with module-level constants, functions, etc. just seems incredibly silly to me. And then expanding on that feature with exotic new syntaxes like this feels regressive.
- jancsika 5y ago
  Yes! In Javascript I write a closure that returns an object full of methods. If I want private state I put the variables in that closure. Nothing bad has happened to me yet. :)
  - brundolf 5y ago
    I would argue that that method (no pun intended) is less clear about intent and harder to read There are lots of things like this where the OOP version and the FP version are technically interchangeable in terms of capability, but not in terms of ergonomics or readability. A beautiful thing about working in a multi-paradigm language like JS is that you can reach across the aisle for the best tool for any given job. You can use classes to hide state, plain functions instead of statics, lambdas instead of anonymous classes, etc.
    - hajile 5y ago
      I don't get the intent argument. Closures are private by default while JS classes are public by default. If anything, closures have a more desirable default. The issue is that private variables cause a ton of implementation complexity. The add more overhead when thinking about classes too. In the end, they don't add very much of value except allowing Java or C# programmers to feel more comfortable. Meanwhile, it's giving them a giant footgun in the form of class syntax that looks like what they know, but operates on completely different underlying principles. JS continues to be the only language that people commonly use without having actually bothered to learn properly.
antihero 5y ago
I wish they could add pattern matching statements.
- graftak 5y ago
  That is a stage 1 proposal[1]. [1] https://github.com/tc39/proposal-pattern-matching https://github.com/tc39/proposal-pattern-matching
Waterluvian 5y ago
I’m perfectly happy for a language to have feature coverage for others to do what they like. I’ve found incredible success using JS (TS) as a functional language. Oh my god I love it. It’s so easy to test. So easy to reason about. So predictable. State is my enemy. Optimization can be hidden away in the form of memoization rather than partially mutating object state. Does this work for all use cases? Nope. Classes are fine. They sure beat the five or so fake ways to do classes before ES6. I’ll settle down now.
- Scarbutt 5y ago
  I’ve found incredible success using JS (TS) as a functional language. Oh my god I love it. Immutability is still very tedious and kludgy.
  - Waterluvian 5y ago
    Oh yes. I do use Immer for this but I’d kill for first class support.
eventreduce 5y ago
With real private fields you can make a minifier that minifies the fieldname/functionname which is not possible before.
dragonwriter 5y ago
> I get that some people really want JavaScript to be object-oriented JavaScript has always been OO, just originally exclusively prototypical OO rather than class-based OO. > but I wonder if we wouldn't be better off embracing and building on its functional side. But modern JS has tended to reinforce both the functional and OO sides of JS. Reinforcing one doesn't prevent the other.

by geewee 5y ago

fiddlerwoaroof 5y ago

The worst part is that the syntax is designed to make JS look like other object-oriented languages without changing the prototypical object system to match the semantics of such languages.

nicoburns 5y ago

Yeah, I find them utterly bizarre. I find it hard to believe that people using private implementation details is a real problem that people have. Underscore prefixing is a well-established convention within the JavaScript ecosystem, and with typescript it's easy to hide fields from the static types. I'm usually up for new language additions, but I can't see the benefit to this added complexity at all.

vaughan 5y ago
It's driven by library developers wanting to prevent access to internals. I was annoyed by it initially because I love poking around in internals and it makes it easy to add missing functionality or fix bugs, but I can kind of understand from popular library maintainers. If Bar depends on a private internal of Baz, and Foo depends on Bar, then if Baz publishes a patch version that changes an internal to fix a bug, Bar breaks, and so does Foo.
- ectopod 5y ago
  Can't you already hide your implementation details using a closure?
  - kccqzy 5y ago
    Yes you can. But few libraries actually do that.
- nicoburns 5y ago
  I think React have the right approach. If something isn't part of the committed to public API, then it's named `__unstable_foo`. Consumers of the library are free to use them, but they can and will change at the whim of the maintainers regardless of any stability guarantees that the library usually provides. This allows advanced consumers to tinker where they need to and are prepared to take on the maintenance while leaving potential complainers no leg to stand on if the API changes.

xpressvideoz 5y ago

Some JavaScript people have been hostile to functional concepts since the beginning. See the missed opportunity to make Promise a monad.[1] [1] https://github.com/promises-aplus/promises-spec/issues/94 https://github.com/promises-aplus/promises-spec/issues/94

Waterluvian 5y ago
I’m curious if someone can sell me, practically, in relatively few words, what that would gain us compared to Promises today. That link wasn’t sufficient to teach me. I’m a bit dense. :(
- hajile 5y ago
  Basically, the current promises take a shortcut. If your promise returns a promise, the two promises are automagically combined into one promise. foo .then(() => returnsAnotherPromise()) .then(() => { /*only receives the nested promise*/}) The correct solution would not automatically flatmap foo .then(() => returnsAnotherPromise()) .then(innerPromise => { innerPromise.then(() = {}) //now we have access to the nested promise }) The second API is easier to statically type (creating a type that automatically, but conditionally removes a type is not necessarily0 easy). The second API makes some abstractions easier. The second API more intutitive for most people new to promises (I've seen it done a lot -- especially a few years ago). The second API allows you to interface with other monads without constantly having to do a special conversion any time you touch a promise. The current API is way more ergonomic for most current developers. In any case, it seems like there should a way to create your own proper monad promises along with an interface to normal promises when needed.
  - Waterluvian 5y ago
    I’m surprised to discover that promise flattening. Never noticed it before. Thanks!

brundolf 5y ago

IMO classes are almost pointless without private fields; hiding state (in the handful of cases where that's really actually what you want) is one of their main legitimate uses But using static members in a language with module-level constants, functions, etc. just seems incredibly silly to me. And then expanding on that feature with exotic new syntaxes like this feels regressive.

jancsika 5y ago
Yes! In Javascript I write a closure that returns an object full of methods. If I want private state I put the variables in that closure. Nothing bad has happened to me yet. :)
- brundolf 5y ago
  I would argue that that method (no pun intended) is less clear about intent and harder to read There are lots of things like this where the OOP version and the FP version are technically interchangeable in terms of capability, but not in terms of ergonomics or readability. A beautiful thing about working in a multi-paradigm language like JS is that you can reach across the aisle for the best tool for any given job. You can use classes to hide state, plain functions instead of statics, lambdas instead of anonymous classes, etc.
  - hajile 5y ago
    I don't get the intent argument. Closures are private by default while JS classes are public by default. If anything, closures have a more desirable default. The issue is that private variables cause a ton of implementation complexity. The add more overhead when thinking about classes too. In the end, they don't add very much of value except allowing Java or C# programmers to feel more comfortable. Meanwhile, it's giving them a giant footgun in the form of class syntax that looks like what they know, but operates on completely different underlying principles. JS continues to be the only language that people commonly use without having actually bothered to learn properly.

antihero 5y ago

I wish they could add pattern matching statements.

graftak 5y ago
That is a stage 1 proposal[1]. [1] https://github.com/tc39/proposal-pattern-matching https://github.com/tc39/proposal-pattern-matching

Waterluvian 5y ago

I’m perfectly happy for a language to have feature coverage for others to do what they like. I’ve found incredible success using JS (TS) as a functional language. Oh my god I love it. It’s so easy to test. So easy to reason about. So predictable. State is my enemy. Optimization can be hidden away in the form of memoization rather than partially mutating object state. Does this work for all use cases? Nope. Classes are fine. They sure beat the five or so fake ways to do classes before ES6. I’ll settle down now.

Scarbutt 5y ago
I’ve found incredible success using JS (TS) as a functional language. Oh my god I love it. Immutability is still very tedious and kludgy.
- Waterluvian 5y ago
  Oh yes. I do use Immer for this but I’d kill for first class support.

eventreduce 5y ago

With real private fields you can make a minifier that minifies the fieldname/functionname which is not possible before.

dragonwriter 5y ago

> I get that some people really want JavaScript to be object-oriented JavaScript has always been OO, just originally exclusively prototypical OO rather than class-based OO. > but I wonder if we wouldn't be better off embracing and building on its functional side. But modern JS has tended to reinforce both the functional and OO sides of JS. Reinforcing one doesn't prevent the other.