Greatest ESLint Options of Some Time
TypeScript declining to add new runtime syntactic features over Javascript EXCEPT THE "enum" KEYWORD is still one of the more baffling design decisions. I mean, if you're going to add what is essentially syntactic sugar, couldn't you at least make if-statement brackets optional
Converting the files was pretty straightforward, too. Did the conversion take 2 hours and force me to open 60 browser tabs? Yes, but - and this is important - I've already made my peace and moved on with my life. And in the end, is that not what all manual upgrades strive to be?
Bad news, everyone. I'm actually the exact use-case that benefits from the ESLint config format change. My project has 3 different kinds of Javascript in it (TypeScript source, in-browser Javascript tests, Node scripts) and having one file that covers all of them works for me.
TypeScript is blowing my mind, which is to say that it's blowing my mind that if I want to access static properties on an instance via .constructor, I can't do it because by default .constructor's type is just Function, so I have to freaking do this:
Writing plain Javascript is a great way to make you think Javascript is an excellent language
Writing TypeScript is a great way to forcibly impress unto you that the Javascript spec, the TypeScript checker, and you the coder, are only hideous and foul, truly worm-eaten with sin.
How many people are going to look at TypeScript's gradual type system, a heavily compromised and imprecise system designed mainly for ease of porting from JS, assume that's "just what type systems are like", and copy most of it for their bespoke programming language
Leon's favourite activities include:
• Explicitly recasting .querySelector("input") to <HTMLInputElement> every single freaking time it appears
*opens TypeScript project* They call me the Colon String Slinger…
Arbitrary array indexing: guaranteed element.
The absolute simplest array methods: not guaranteed an element.
So let me get this straight. You're telling me that after all the trouble of restating the function signature three times…… it doesn't even help with narrowing??
Yeah, this language is not very good.
Ooh, look at me, I'm TypeScript Compiler, I can do control flow analysis on normal records, but not THIS record, because THIS record is PARTIAL, which means the indexed property could have fallen through a trapdoor between lines 2 and 3. Ooh! Oooh!!
AWOOO when you're using TypeScript with jQuery you have to use "'jquery' in e" to type-check because "instanceof $" doesn't work and I hate it AWOOOOOO
It's funny how TypeScript is so blatantly all-in on class inheritance that when the official docs acknowledge the existence of mixins, their proposed solution is "Just dynamically make a chain of subclasses for each mixin. It's fine. Who cares."
Microsoft Type Operating Script
Something I encountered just now… I mean, I could guess at the rationale behind this one, but……… come ON
Here's another puzzling outcome: in the standard defs, the return type of Object.create(null) is "any"?? This whole language is designed primarily for legacy code, so this feels like a big omission.
On top of that, a couple of existing JS idioms seemingly arbitrarily don't work.
For example… here, the top one works but is a terrible 2000's-era syntax pattern, the middle one doesn't work without a bunch of unenforceable type assertions, and the bottom one is just not usable.
TypeScript currently feels more like you're telling an interesting story about your program's structures and control flow, rather than actually nailing down an airtight spec. The fact that you can quite often make obviously contradictory type assertions dampens my mood a bit.
In the process of (re-)learning JS game making, I've also taken the opportunity to get in on TypeScript, and, well… I guess my recent experience with the current gold standard of type systems (Rust) set me up for a little disappointment in comparison.