Crockford hates TypeScript and loves og JS. He thinks the push to turn JS into c# is misguided and a waste of the original small talk-y beauty of The Good Parts - src he said as much to me at a lunch I went to where he was also attending.
Does Crockford "like" OG JavaScript? He's most famous for writing a book that shits on how much of the language should be ignored and avoided. To be fair, a lot of that was right, but it's far from comprehensive for the language we have today. Seems like despite another decade of improvements on the language The Good Parts lives on in the minds of readers as something relevant today-- while a new treatise on The Good Parts of modern JS is not present. There are definitely parts of JS today that should be discarded, like "var", but The Good Parts cannot help you with that, because when it was written you could not discard it, as there was no other option.
I've seen developers make complete messes of codebases that when using modern JS features would be mostly trivial, and they hide behind The Good Parts to justify it. And this includes suggesting that classes are somehow bad, and avoiding them in favor of POJOs and messily bound functions is preferrable despite JS not receiving a dedicated class concept until years after The Good Parts was published...
Does TS make JS non-smalltalky? Static typing which is optional.. and you still get a REPL, online compiler and the ability to dynamically inspect objects in your global object...
v1 of TS had a heavy "OO"/class-based bias to it, v3 and v4 made it viable for real-world JS code but peoples perception stayed both due to those who looked early on seeing something they didn't like or the code produced by many who loved it early on.
> the original small talk-y beauty of The Good Parts
Javascript seems much, much, much closer to Lisp than to Smalltalk. Granted, all three are very dynamic, but message passing needs to be bolted onto javascript. Meanwhile pretty much all of lisp is included "for free" (...via some of the ugliest syntax you've ever used).
Totally agree, if JS had further leaned into it's smalltalk-y-ness and ended up with dynamism similar to Ruby for example, I'd actually be really happy with it personally. True message passing and more metaprogramming features allowing you to change execution context would be fun to play around with in a forked version of JS somehow.
How long ago was this? TypeScript v1 and v2 definitely had a class-based stink to it since the typing system only handled those scenarios somewhat well.
Right around when I started using it (mid 2019) there was a bunch of V3 releases that each on it's own might've not seemed like much but they all improved small parts of the engine that made it easy to get typing on most of your code if using a functional style without adding maybe more than a few type declarations and some functions typings.
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.
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.
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.
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.
