[1] https://github.com/promises-aplus/promises-spec/issues/94
That link wasn’t sufficient to teach me. I’m a bit dense. :(
foo
.then(() => returnsAnotherPromise())
.then(() => { /*only receives the nested promise*/})
foo
.then(() => returnsAnotherPromise())
.then(innerPromise => {
innerPromise.then(() = {}) //now we have access to the nested 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.
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.
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. :)
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.
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.
> I don't get the intent argument.
Classes, from day one, have always been about encapsulating state behind a set of methods (or "passed messages" if you want to go all the way back). If I define a class in my JS codebase, it gives strong signals to others about what my intent was with this code, how it works[0], and how it should be used. A newcomer who encounters the closure method, on the other hand, has to mentally reverse-engineer how it works and what its goal is if they haven't seen that pattern before, because closures are much more general than classes and because returning a closure is less common and its behavior less obvious compared to other ways closures tend to be used in JS.
> The issue is that private variables cause a ton of implementation complexity.
I think a case could be made that private members should have been left up to type systems like TypeScript (which I believe virtually every JS codebase should be using at this point anyway) instead of implemented in the JS engine at runtime. At this point I see plain JS as a bit of an "all bets are off" language, so maybe it wasn't worth trying to plug one hole given how many others still remain. But on the other hand, like I've said, I think classes are nearly useless without private members, and they do exist in JS already so there's an argument to be made that we should at least make them useful.
> In the end, they don't add very much of value except allowing Java or C# programmers to feel more comfortable.
It's a tired trope that every single feature associated with Java or C# is "just there to make Java and C# programmers feel comfortable" and is therefore invalid and useless.
> 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.
The only footgun I've encountered with the ES class syntax is when passing classInstance.someMethod as a value (`this` is normally unbound because the method exists on the prototype instead of the instance). But a) this is not something (to my knowledge) that you can even do in those other languages, so the proverbial "Java and C# programmers" should have no preexisting expectations around how it behaves, and b) the solution is just "always use arrow syntax for methods if you want this to work the way JS would have you expect". I've worked with many junior programmers who have no problem doing the latter, even when they don't yet have a full understanding of why it's needed.
[0] How it works at the application logic level; the underlying way that classes work is rarely an issue that comes up.
I didn't intend to be rude (I'm sorry for any offense it might have caused). It was a general complaint not aimed at you or anyone else in particular.
> A newcomer who encounters the closure method, on the other hand, has to mentally reverse-engineer how it works and what its goal is if they haven't seen that pattern before, because closures are much more general than classes and because returning a closure is less common and its behavior less obvious compared to other ways closures tend to be used in JS.
The second part here is simply not the case. If you want to use any bundler or build tool created in the past 15 years, it's going to use closures for anything but the most recent projects. CommonJS which is still ubiquitous in NodeJS is literally closures. When it was created, it literally wrapped your file in a function that passed in some variables like global or import then called eval on the module it had now created.
Before CommonJS, there was AMD (asynchronous module definition). Before that, libraries would wrap themselves in an IIFE which returned only the public parts of the library.
If someone doesn't know how the module pattern works, they are a junior JS dev and absolutely cannot move on with their career until they understand. At that point, there should be zero issues with them using the pattern.
> It's a tired trope that every single feature associated with Java or C# is "just there to make Java and C# programmers feel comfortable" and is therefore invalid and useless.
When you look into the people pushing for these features, you almost always find a Java or C# developer. There's not a mass push by JS devs to add these features. In the case of private variables, it seemed to be more-or-less the JS community vs the spec committee and the committee just ignored what most devs wanted (without any evidence) because they thought they knew best.
> The only footgun I've encountered with the ES class syntax is when passing classInstance.someMethod as a value (`this` is normally unbound because the method exists on the prototype instead of the instance).
This is too big of a topic for here, but there are many pieces of weirdness in the JS prototypal system. Classes don't fix them, they just add another layer of abstraction with its own rules (eg, methods aren't enumerable). There are lots of footguns and other people run into them even if you and your particular set of devs do not.
These are all implementation details; they couldn't matter less to most application developers. I've been writing JS for a decade and while I roughly knew that bundlers did something like this, I've never once had to deal with it directly.
> If someone doesn't know how the module pattern works, they are a junior JS dev and absolutely cannot move on with their career until they understand.
This is extremely not true. Knowing how modules are implemented under the hood is a concern of people who work on bundlers, transpilers, etc. For regular devs, an airtight abstraction is presented and it never needs to be more than that. It's wildly wrong to suggest that a person can't be productive at more than a junior level without knowing how this particular sausage is made.
> When you look into the people pushing for these features, you almost always find a Java or C# developer. There's not a mass push by JS devs to add these features.
Hello. I'm a JS dev who hasn't written Java or C# in over six years, who wouldn't want to write either of them, and yet I think private class members are valuable enough to have them in the language.
> even if you and your particular set of devs do not
I'm talking about the average JS dev doing mainstream JS work, here. I argue that ES classes are useful and mostly devoid of footguns for most, realistic, usage in industry. Not just for myself or for one particular team.
In all I think you're taking a fairly extreme purist stance, where people are disallowed from being productive with a given technology unless they have a deep understanding of how it works underneath. That deep understanding is great to have - it's part of what makes a good lead dev - but plenty of people out there are plenty effective working off of provided abstractions, and it's narrow-minded to dismiss that fact.
* JS modules are in the seminal "Javascript: The Good Parts".
* "Eloquent Javascript" has an entire chapter called "modules" and that has existed across all three versions
* "Javascript: The Definitive Guide" also has a section on modules.
* Javascript.info contains an entire section about modules.
* "Exploring JS" contains a section on the module pattern.
* "You Don't Know JS" has even more about it.
I don't see how someone could know JS as a senior or even mid-level developer without having read at least one of these sources let alone the years-long barrage of blog articles.
I can say with 100% certainty that you cannot write properly using any modern framework without understanding closures (of which modules are one of the easiest patterns).
That's not "being purist". That's not requiring everyone to read the latest ECMAScript spec. That's a simple acknowledgement of the day-to-day reality of the job in a typical company.
I've found understanding exactly how JS works to become more confusing with class structures.
It feels like you need a PHD in JS to have a good grip on how it all works under the covers.
Using Crockfords closure strategy for me was quite straightforward and simple, and I've enjoyed doing:
const MyClass = {}; MyClass.new = () => {}; const instance = MyClass.new();
Which leaves all the "this." ugliness behind and provides a ruby-like instantiation.
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.
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.
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.
Immutability is still very tedious and kludgy.
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.