3 ms·

I'm all for people writing functional code with Javascript-- but when people eschew classes because of their "stink" and proceed to use all of the stateful prot

I'm all for people writing functional code with Javascript-- but when people eschew classes because of their "stink" and proceed to use all of the stateful prototypal archaic features of JS instead of classes, I have to protest. If you are using this and function binding and state extensively in your "functional" JavaScript, you are reinventing classes poorly. And classes are a part of JS itself, not something added on to JS by Typescript (in the current day). The Crockford crowd would like us to live in a world of ES5 as if that's some kind of badge of pride, while justifying it with a warcry of "functional", while breaking the preconceptions of functional programming all throughout.

Swalden123 2y ago
Classes are still built around prototype inheritance, there are some differences, however they are still an easier to use api on top.
- LegionMammal978 2y ago
  Yeah, iirc private properties (added in ES2022) are currently the only part of ES6 classes that can neither be created nor accessed using prototype-based code, to the consternation of some people when they were added. Of course, provate properties can still be readily emulated with a WeakMap in a function scope.
wk_end 2y ago
Using JS/TS in a functional style doesn’t mean using prototypes or function binding or anything. I’m not sure how you inferred that from the comment you’re replying to…it just means using plain objects (TypeScript even, a little awkwardly, lets you express ADTs) and plain functions, perhaps with the module system to organize them.
whizzter 2y ago
My point was rather that a functional style with plain old data was always preferable, the "stink" was that early TS versions _favored_ non-functional OO style that suited the TS type system at a time when most modern JS code already had a functional approach, so you ended up writing non-idiomatic JS because the TS type system wouldn't handle idiomatic code (this also contributed to a lingering distrust in TypeScript that persists to this day despite the upgrades to the typing system). Personally I prefer neither prototypal or classes, 90% of the time you just want the interfaces, unions or inferred types and the few places where you actually want inheritance and/or object methods you really are just better off with a factory method that then creates a literal that is used or suits an interface.

Swalden123 2y ago

Classes are still built around prototype inheritance, there are some differences, however they are still an easier to use api on top.

LegionMammal978 2y ago
Yeah, iirc private properties (added in ES2022) are currently the only part of ES6 classes that can neither be created nor accessed using prototype-based code, to the consternation of some people when they were added. Of course, provate properties can still be readily emulated with a WeakMap in a function scope.

wk_end 2y ago

Using JS/TS in a functional style doesn’t mean using prototypes or function binding or anything. I’m not sure how you inferred that from the comment you’re replying to…it just means using plain objects (TypeScript even, a little awkwardly, lets you express ADTs) and plain functions, perhaps with the module system to organize them.

whizzter 2y ago

My point was rather that a functional style with plain old data was always preferable, the "stink" was that early TS versions _favored_ non-functional OO style that suited the TS type system at a time when most modern JS code already had a functional approach, so you ended up writing non-idiomatic JS because the TS type system wouldn't handle idiomatic code (this also contributed to a lingering distrust in TypeScript that persists to this day despite the upgrades to the typing system). Personally I prefer neither prototypal or classes, 90% of the time you just want the interfaces, unions or inferred types and the few places where you actually want inheritance and/or object methods you really are just better off with a factory method that then creates a literal that is used or suits an interface.