311–320 of 469 posts
My only issue with TS is that there are no runtime type guarantees. That, and a few odd syntax choices that I mostly don't have to deal with.
I've been working with JavaScript for 20 years. And 5 years with TypeScript. And, well. I still am not convinced. Too much overhead for me. I really dislike typing obvious things and boilerplate. Probably my fluency with JS is to blame. I don't need to see types and autocompletion. If I really need to — I just go to the source and inspect the source code, that is how I familiarise myself with the interface. I also th…
Why don't exhaustive matches, unions, and data modelling not get mentioned more often? That's where the true strength lies.
#1 – You don't have to upgrade TypeScript versions till you are ready, and newer versions never have breaking changes anyways. The syntax remains strictly compatible with ES6 and beyond. Packages you consume publish compiled JS and aren't dependent on specific TypeScript versions at all. #2 – If libraries haven't published types, just use them as pure JavaScript (which is what you would have done anyways). Lack of do…
I honestly don't understand why it's even optional, as being able to know what is nullable or potentially undefined is extremely important, and not having it can lead to tons of bugs.
Hoenstly, for production code, TS makes me sleep better. No matter how many tests you write, that one undefined object will get you at some point. TS helps to eliminate a complete set at compile time (as you know) and that's great! Anecdotal evidence from my Haskell experience: If my Haskell programs compiled, they usually worked. Which is amazing. Powerful types for the win.
> Anecdotal evidence from my Haskell experience: If my Haskell programs compiled, they usually worked. Which is amazing. Powerful types for the win. I have the same feeling regarding Haskell, Elm and Swift, the latter I program in 99% of the time. I really don't feel like I get the same sense of security from Typescript, to be honest. Maybe I'm not using it correctly? I tend to lean more towards OP's opinion. I would…
Short answer: It is worth it if you want me on the team. I refuse to work with anyone who throws out TS for JS in 2023. Slightly longer answer: I have said a number of times "Javascript is a simple version of Java in the same way as a bike with one wheel is a simpler version of an ordinary bike." The same can be said about JS and TS. If you want to do any serious work you go for the serious thing even if it means occ…
I feel that using it optionally where it's easier to maintain and feel its value is the best of both worlds.
Earlier quoted context omitted.
I think stuff like this really comes down to getting used to and accepting. I had the same views on code prettiers. I thought, aligning your code by hand makes you think about the structure. That you'd invest more time in making your code readable and thus it would be more readable. When I first got to use prettier on a team and accepted it's value, the benefits I perceived were so vast, that my arguments seemed irre…
Sure! I want prettier for types. So I don't have to manually type the obvious things. The IDEs are smart, but I haven't found one that would be that smart.
You can also generate API types based on your backend.
Earlier quoted context omitted.
> I think its good to bring up SPAs in this context: fundamentally, they shouldn't exist, and you're using the browser wrong. They are the poster child of design smell when it comes to "web apps". So a universal, cross platform, cross device, responsive, accessible UI stack that has simple distribution, avoids walled gardens and has excellent performance is a "design smell"? > Do you need SEO to work, even though Goo…
I agree someone is doing something wrong, wrt sluggish browser performance and routing. However, I keep being exposed to this in random SPAs I get exposed to; I can only conclude this continues to be a problem that developers have and the popular frameworks somehow footgun them into this.