3 ms·

Did a personal web project and chose TypeScript to see what the rage was about. I spent a ridiculous amount of time trying to design types. At some points I co

Did a personal web project and chose TypeScript to see what the rage was about. I spent a ridiculous amount of time trying to design types. At some points I couldn't figure it out, or I ran into some limitation of the language to express what I need. So my code has a bunch of exclamation points everywhere to assert that a null ain't coming. It feels dirty. Just too hard to use for me.

rektide 4y ago
It's just so awesome that a thread on "Silent Majority" has the typical loud protests against JavaScript, against the web, against React, against TypeScript. The irony is loud to me. It's not even that there's only happy heads-down programmers off HN who support these mainstream techs. Even in the active userbase here, I'd wager there are tons of people who have an adequate or better experience with typescript or react, and may disagree with the dislikers. But we're not as invested in our liking, don't feel like it's worth engaging in, and none of the banter changes what is or where things are going. These are the de-jure tools that the majority definitely uses widely, which at least the first anti- comment, on front-end frameworks, acknowledged. Whatever the targets-of-the-day happen to be, they will crop up repeatedly, which further dissuades from trying to come back with a positive or even neutral opinion that might represent that silent majority's take. And the silent majority must constantly face Brandolini's Law; what it's doing may be working & have good reason, but it's hard to keep supporting & reasoning through with a pact invested in disbelieving. I liked the top post talking about disagreeing with the direction. That can be contributive, be value based. So often though the protests amount to gatekeeping "you've done too much." I evaluate where these comments would fall on Steve Yeggie's Software Political axis, from Notes from the Mystery Magic Bus[1], and almost universally the voices are conservative; they object rather than suggest, they refuse rather than support. I'd like to see more progressive protests, that can surface good, that acknowledge value & need but reflow or redirect the energy elsewhere, rather than being unhappy with what is. [1] https://gist.github.com/cornchz/3313150 https://gist.github.com/cornchz/3313150
- wnolens 4y ago
  HN can be conversational, not always a well researched debate. Most of us are over-involved with these debates with coworkers at our day jobs, where we HAVE to spend the energy having productive disagreements. I appreciate the high quality HN posts, but sometimes just like at a water cooler a bunch of us just wanna say, "agh I'm so sick of object oriented" and it doesn't mean "all object oriented programming is of no use".
mikewhy 4y ago
Threads like these are why I don't pay attention to HN anymore.
- wnolens 4y ago
  I'm sorry I didn't sufficiently entertain you.
vbezhenar 4y ago
What's so hard about designing types? I'm Java developer and when I need to use TS, I just write Java with it. Works fine. The only times I encounter weird types is when for some reason I need to read type definitions for some weird JS library. But that's relatively rare.
- wnolens 4y ago
  Good for you.
- danielvaughn 4y ago
  I’ve found that working with the DOM can be really difficult because the types built into TS don’t accurately capture the underlying API. In just a few hours I found 2 cases where it seemed obvious that the type definition was incorrect.
overgard 4y ago
A few things you might consider... Are you using "?" optional fields in your classes/interfaces a lot? If so, do you need to? Unless it's truly optional, you're basically making the type system less useful if you put that all over the place. If you have a lot of sparse objects, it's probably an indicator of a data type doing too much. You might be much better off splitting it into smaller interfaces and using union types when you need combined objects. Even if you can't do the above, checking for null at the start of a function/block will "prove" to the compiler that it's not-null for the rest of the block, so an upfront check can save you from a lot of "!" assertions. Even if you can't do either of the above, you can probably use the elvis operator "?." to safely dereference things that might possibly be undefined. In my experience with typescript, there's a few good rules of thumb and things to keep in mind: - Prefer "interface" over "class" for describing most data types. Especially plain old data objects that don't have methods. I'd forget about the definition of "interface" you might know from Java. It can be used that way, but it can also be used like you would use "struct" in C - Use the "Partial" modifier instead of using "?" in the base structure if you need to do something like sparse updates. For instance a pattern I use a lot is: interface MyStruct { a: number, b: string } function update(original: MyStruct, updatedFields: Partial<MyStruct>) { return {...original, ...updatedFields} } - Always prefer readonly fields and non-optionality. - If you're not worried about GC pressure, it's almost always better to return a new object than mutate an old one. The spread operator is great for this. - Within reason, it's better to prefer smaller data structures and use type unions when you need fields from both in one object.
- wnolens 4y ago
  Thanks. It's definitely not obvious to me coming from Java/c++/python. I think I went into the deep end with some non trivial generic functions. It's been a few months, but I remember ditching interfaces for classes so I could do some run time type checking. I wouldn't have fallen into these traps with something like Java.
llllIIIIllll 4y ago
After years and years in C# I spent half a year writing Typescript full time. IMO it's not that Typescript is limited at all, it's just that the type system is different, more complex and also more flexible - there are typically more ways to define types compared to Java/C#, so a lot more decision points trying to write something elegant, or even just idiomatic/understandable, so IMO the learning curve is steep. And then you get to the fun stuff with more abstract type definitions, infer keyword... It screwed with my head way more than I thought it would. Structural typing was really different, I had to spend a long time rewiring my brain. But when I went back to C#, I felt like the type system was crude. I lost all the nice and easy ways of writing dynamic code and had to revert to defining surplus kludgy interfaces, delegates, etc. And in Typescript I'd finally figured out how to write null-safe code and remove almost all ugly coercions, then back in C# null references were a real possibility.
- wnolens 4y ago
  Interesting, yeah I had one or two good moments after spending a few hours wrangling my interfaces. But the frustration left a worse impression than did the benefits. Perhaps if I was being paid to do it and had mentors around to ask for help. But I couldn't find any good advice online.
  - llllIIIIllll 4y ago
    I had a pretty terrible experience at that job - no engineering manager, never had any code reviewed, hardly any collaboration with other team members so I was basically stabbing away in the dark trying to get my shit together in TS. It took me far longer than a few hours to feel comfortable, probably more like over a month of coding to get to the point where I mostly understood how to express what I wanted with the type system, and had stopped doing C# things in TS and adhering to style guidelines - functional modules, types instead of classes, injecting dependencies etc. And another month or two? to really figure out how everyone has been (ab)using the type system to do more complex stuff.

rektide 4y ago

It's just so awesome that a thread on "Silent Majority" has the typical loud protests against JavaScript, against the web, against React, against TypeScript. The irony is loud to me. It's not even that there's only happy heads-down programmers off HN who support these mainstream techs. Even in the active userbase here, I'd wager there are tons of people who have an adequate or better experience with typescript or react, and may disagree with the dislikers. But we're not as invested in our liking, don't feel like it's worth engaging in, and none of the banter changes what is or where things are going. These are the de-jure tools that the majority definitely uses widely, which at least the first anti- comment, on front-end frameworks, acknowledged. Whatever the targets-of-the-day happen to be, they will crop up repeatedly, which further dissuades from trying to come back with a positive or even neutral opinion that might represent that silent majority's take. And the silent majority must constantly face Brandolini's Law; what it's doing may be working & have good reason, but it's hard to keep supporting & reasoning through with a pact invested in disbelieving. I liked the top post talking about disagreeing with the direction. That can be contributive, be value based. So often though the protests amount to gatekeeping "you've done too much." I evaluate where these comments would fall on Steve Yeggie's Software Political axis, from Notes from the Mystery Magic Bus[1], and almost universally the voices are conservative; they object rather than suggest, they refuse rather than support. I'd like to see more progressive protests, that can surface good, that acknowledge value & need but reflow or redirect the energy elsewhere, rather than being unhappy with what is. [1] https://gist.github.com/cornchz/3313150 https://gist.github.com/cornchz/3313150

wnolens 4y ago
HN can be conversational, not always a well researched debate. Most of us are over-involved with these debates with coworkers at our day jobs, where we HAVE to spend the energy having productive disagreements. I appreciate the high quality HN posts, but sometimes just like at a water cooler a bunch of us just wanna say, "agh I'm so sick of object oriented" and it doesn't mean "all object oriented programming is of no use".

mikewhy 4y ago

Threads like these are why I don't pay attention to HN anymore.

wnolens 4y ago
I'm sorry I didn't sufficiently entertain you.

vbezhenar 4y ago

What's so hard about designing types? I'm Java developer and when I need to use TS, I just write Java with it. Works fine. The only times I encounter weird types is when for some reason I need to read type definitions for some weird JS library. But that's relatively rare.

wnolens 4y ago
Good for you.
danielvaughn 4y ago
I’ve found that working with the DOM can be really difficult because the types built into TS don’t accurately capture the underlying API. In just a few hours I found 2 cases where it seemed obvious that the type definition was incorrect.

overgard 4y ago

A few things you might consider... Are you using "?" optional fields in your classes/interfaces a lot? If so, do you need to? Unless it's truly optional, you're basically making the type system less useful if you put that all over the place. If you have a lot of sparse objects, it's probably an indicator of a data type doing too much. You might be much better off splitting it into smaller interfaces and using union types when you need combined objects. Even if you can't do the above, checking for null at the start of a function/block will "prove" to the compiler that it's not-null for the rest of the block, so an upfront check can save you from a lot of "!" assertions. Even if you can't do either of the above, you can probably use the elvis operator "?." to safely dereference things that might possibly be undefined. In my experience with typescript, there's a few good rules of thumb and things to keep in mind: - Prefer "interface" over "class" for describing most data types. Especially plain old data objects that don't have methods. I'd forget about the definition of "interface" you might know from Java. It can be used that way, but it can also be used like you would use "struct" in C - Use the "Partial" modifier instead of using "?" in the base structure if you need to do something like sparse updates. For instance a pattern I use a lot is: interface MyStruct { a: number, b: string } function update(original: MyStruct, updatedFields: Partial<MyStruct>) { return {...original, ...updatedFields} } - Always prefer readonly fields and non-optionality. - If you're not worried about GC pressure, it's almost always better to return a new object than mutate an old one. The spread operator is great for this. - Within reason, it's better to prefer smaller data structures and use type unions when you need fields from both in one object.

wnolens 4y ago
Thanks. It's definitely not obvious to me coming from Java/c++/python. I think I went into the deep end with some non trivial generic functions. It's been a few months, but I remember ditching interfaces for classes so I could do some run time type checking. I wouldn't have fallen into these traps with something like Java.

llllIIIIllll 4y ago

After years and years in C# I spent half a year writing Typescript full time. IMO it's not that Typescript is limited at all, it's just that the type system is different, more complex and also more flexible - there are typically more ways to define types compared to Java/C#, so a lot more decision points trying to write something elegant, or even just idiomatic/understandable, so IMO the learning curve is steep. And then you get to the fun stuff with more abstract type definitions, infer keyword... It screwed with my head way more than I thought it would. Structural typing was really different, I had to spend a long time rewiring my brain. But when I went back to C#, I felt like the type system was crude. I lost all the nice and easy ways of writing dynamic code and had to revert to defining surplus kludgy interfaces, delegates, etc. And in Typescript I'd finally figured out how to write null-safe code and remove almost all ugly coercions, then back in C# null references were a real possibility.

wnolens 4y ago
Interesting, yeah I had one or two good moments after spending a few hours wrangling my interfaces. But the frustration left a worse impression than did the benefits. Perhaps if I was being paid to do it and had mentors around to ask for help. But I couldn't find any good advice online.
- llllIIIIllll 4y ago
  I had a pretty terrible experience at that job - no engineering manager, never had any code reviewed, hardly any collaboration with other team members so I was basically stabbing away in the dark trying to get my shit together in TS. It took me far longer than a few hours to feel comfortable, probably more like over a month of coding to get to the point where I mostly understood how to express what I wanted with the type system, and had stopped doing C# things in TS and adhering to style guidelines - functional modules, types instead of classes, injecting dependencies etc. And another month or two? to really figure out how everyone has been (ab)using the type system to do more complex stuff.