It's probably worth taking a step back and interrogating why the actual "Why was I Anti-TypeScript?" a little bit more and use it as an opportunity for broader self development. The author didn't use and understand something, and rather than trying to they instead just defaulted to rejection. It's midly disapointing seeing this in people who label themselves as "Senior".
Ironically, as someone who has experience w/ both fast-and-loose JS and with "properly" statically typed languages, my beef with typescript is precisely that it allows people to be fast and loose, sometimes in ways that are not super obvious. For example: type Thing = { name: string, }; function getThing(): Thing { return JSON.parse('{"error": "invalid id"}') } const thing: Thing = getThing(); // lie to me! console.l…
How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan
201–210 of 400 posts
Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan
#202More than that, when you use JS in the back and the front, your types can follow from the database, to the api, to react... even to your integration tests or your public SDK.
Add one more column in your DB and suddenly 1000 errors pops, but those are good errors, you just have to follow them until nothing scream and you have done a perfect migration. It can feels negative at first but it is actually very pleasant and reassuring, like having an angel watching over your code.
Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan
#203 type State = { id: "initial" } | { id: "running", speed: number }
const f = (s: State) => {
switch (s.id) {
case "initial": // s.id available
break;
case "running": // s.id and s.speed available
break;
}
}
The problem with Typescript shows up when people with background in Java or C# starts taking oo design patterns into js-land where they don't really belong (patterns like dependency injection, factories, singletons etc.).Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan
#204Earlier quoted context omitted.
Ironically, as someone who has experience w/ both fast-and-loose JS and with "properly" statically typed languages, my beef with typescript is precisely that it allows people to be fast and loose, sometimes in ways that are not super obvious. For example: type Thing = { name: string, }; function getThing(): Thing { return JSON.parse('{"error": "invalid id"}') } const thing: Thing = getThing(); // lie to me! console.l…
This is the one thing that bothers me about TypeScript as well. I've ended up using frameworks like `zod` to do runtime type checking of endpoints. It has gone a long way towards decreasing edge case failures -- I just wish they had something like this built into the language.
So Zod it is. I like it.
Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan
#205Earlier quoted context omitted.
The "curse" of Typescript is that it's built on Javascript, so you can tell it to lie to you all the time. This is the problem with introducing Typescript to a larger group of Javascript developers who arent all on board (because of either experience or being stubborn) - you still need to establish good habits and patterns for how to write typescript. I'm working through the very lie you're showing now because the di…
> you still need to have good developers writing good code, but TS will make it easier Very true. Typescript is still immensely helpful in the sense that it will complain if you pass a Thing to a function expecting a Foo, regardless of the fact that Thing is meant to be a thing but is actually an error. But IMHO, by sticking to a decision to be lean in terms of transpiled JS, TS suffers greatly from cases like the on…
function isThing(value: unknown): value is Thing {
return typeof value === 'object' && typeof value.name === 'string'
}
The `unknown` type in general is still pretty new, but will be greatly helpful for cleaning up a lot of code that assumes a type or used to use `any` or `{}` because there wasn't a better type to use in that situation. The Typescript team is hesitant to change the last few cases of `any` in lib.d.ts to `unknown` directly (such as `JSON.parse`) because that would be a big compatibility breaking bug. There was a proposal for a flag to do that (treat `any` as `unknown` in lib.d.ts), but I'm not currently aware of whatever happened to that idea. I would love to see it or something like it happen.Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan
#206I feel that things like using WebAssembly to bring in other languages, or compiling down Ocaml/Ocaml-like languages such as with BuckleScript or Reason etc. is more appealing than TypeScript to me.
Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan
#207While I'm fan of statically typing, there is something with Typescript I don't like, but don't know exactly what it is. In my day-to-day it's mostly Kotlin and Elm, which also are both statically typed, which I don't mind and mostly don't even notice. But with Typescript it is as if I'm always fighting the compilator, trying to make it happy with whatever code I wrote. Maybe it's just the JS ecosystem being too lax t…
Kotlin and Elm are more functional, don't know about Elm but Kotlin has non-null pointers as a base feature of it's language, not some later bolted on tie-wrapped solution.
Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan
#208Earlier quoted context omitted.
1) TypeScript has local type inference, meaning that `let x = returnsComplicatedThing();` will work, where in Java it would be `Complicated > x = returnsComplicatedThing();`. (At least up until the last few years) 2) TypeScript has type aliases, meaning you can write `type MyTable = List >` and not have to repeat yourself everywhere. 3) TypeScript has anonymous unions and tuples, so instead of writing `Triple ` you c…
Don't know about the other two, but the first one is available in java 10 and later.
(That part has also gotten better, but especially the Java 8 -> anything later upgrade has been extremely painful because of modularization. Past Java 9 it usually isn't that much of an issue. However, JDK 11 was the first LTS release after 8, so most shops basically delayed the transition until JDK 11.)
Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan
#209 > const x = 'xxxx'
> if(x === undefined) {
> console.log('never happens')
> }
will compile without any problemsRe: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan
#210> I always felt that adding types to the functions/variables and satisfying the TypeScript compiler is an over-engineering and not providing any meaningful benefits. I honestly find this attitude horrifying. I'm glad the author was able to move on from this, but it is utterly pervasive in some parts of our industry. As far as "engineering" goes, specifying your types is about as low-hanging, basic a step as you can t…
But I don't enjoy it. I like writing JavaScript. I think I can often do it elegantly and that the perceived elegance at least somewhat corresponds to objective quality. TypeScript makes my code uglier, to my taste at least, and makes development less fun for me. This impacts not just my feelings, but also my productivity. TypeScript had better provide me with something great to make up for this. I rarely make the kind of errors that TypeScript is capable of catching or feel like I need the help with readability and code discovery that it provides. But other people, I recognize, do benefit from it sometimes and in any case, other people pay me to use TypeScript.