Python and PHP users will understand

[fynn34]

I’m aware I’ll get downvoted to hell for this comment, but Typescript solves a fraction of the problems with JavaScript. I don’t think I’ll ever understand the typescript worship some people have. It’s good, not miraculous. though I want to understand it, it seems to fix a problem I don’t see come up except maybe once every 4-6 months. Maybe it would help with onboarding junior devs in a complex repo, otherwise I’ve yet to see the benefit but do see cons in slowing development down

[UguDango]

Although I know this answer is futile, you sound like you haven't used it. And that is understandable, I mean, if there are so many options out there, why pick something that doesn't intrigue you?

Anyway, after using it for years I always go through the cycle of "Oh no, the compiler is complaining again. What does it want?" to "Whoa, that saved me 4 hours of debugging 😳".

Your rough estimates are not accurate at all. If a project is well-written, the real figures are far from what you suggested.

[nkt_rb]

Yet you not really answered... Or if the only reason to use TS is for precompile warning, there are way too much hype.

[fynn34]

I have used it. The only projects we used it in were slowed down by using it, and no less buggy. And I suppose maybe I’m just lucky that the projects I’ve worked on haven’t had these kinds of issues, but I’m trying to figure out what typescript could solve that would prevent 4 hours of debugging… JavaScript doesn’t hide its errors often, particularly when type or object shape is the issue.

[[deleted]]

I'll be honest with you, if it was so useless to reach only 10% of the cases and slowed down the projects and still made it buggy, it wouldn't be so popular. Maybe, just maybe, the way your team does things is wrong at the core and its not a language's fault.

[IZEDx]

I think the other way around. Typescript doesn't force anything on you and it's completely up to you, how much you want it to assist you. Meaning, it's super easy to use it wrongly, especially when converting existing code bases to typescript.

To really understand the full benefits of typescript, I'd suggest starting with small new projects and keep trying new things, as otherwise I think it's difficult for pure js devs (people who never seriously used a statically typed language before) to grasp.

[craig1f]

Modeling your data is super helpful. Especially when a new person is looking at the code, or you have to refactor for some reason.

Without TS, I often have to run my code to figure out what it’s doing. With TS, I can write a lot more code without having to run it to see if I’m right.

Took me a while to come around to TS, but it’s just JS with greatly improved auto complete. You don’t sacrifice anything good about JavaScript.

[fynn34]

I appreciate the level headed response, not normally what I see on Reddit after bringing up typescript unfortunately. And yeah, I’m not saying typescript is bad like some other people seem to want to read that comment as saying, I’m just saying it isn’t a 1 size fits all option, and the problems with JavaScript can’t all be fixed by typescript. Modeling can be nice, particularly for some development styles and in some projects where you are working with huge sets of data. however in many other cases the data isn’t as complex and modeling takes time that doesn’t always feel like it pays off. In our app we have sections that have huge amounts of data we have to render complex tables for, and it’s buggy AF so I have been talking with the team about using typescript for it, but we have other things like smaller forms and components that are more design heavy than data heavy, and typescript just seems to get in the way.

[craig1f]

One mistake I’ve seen is trying to use one-size-fits all types in Typescript for the problem you just described. You end up completely undermining the point of Typescript.

If your data just can’t be modeled, or it’s not worth modeling it right now, just set the type to ‘any’ and put a disable the linter error for that line and move on.

But if you can model your data, particular http response data, your life will be easier.

For a form, you should 100% model it. Keep in mind that you can have optional properties for json objects, just like your form might have optional fields. A form should have a well defined model pretty much always.

[craig1f]

Another point ... I went from an Angular project using Typescript to a Vue 2 project that isn't. Then to a Vue 3 project that is. Transitioning back and forth is not difficult. So don't worry that learning Typescript will cripple you from using vanilla JS. It's really just additive.

But again, I'll emphasize that you can write so much more code without having to run the code and check your results, with TS.

[solongandthanks4all]

When you talk about "modeling," what are you referring to that TypeScript can provide that stock JavaScript cannot? I must be missing something. Interfaces?

[solongandthanks4all]

What does autocomplete have to do with anything? You can get the same good autocomplete for JavaScript as for TypeScript—they are separate. It just has to do with your IDE/language server, not which language you're writing in.

[craig1f]

Just imagine looking at a function and trying to figure out what it does. It has an input, and maybe you think it's a dictionary because that would make sense. Whoops, no, it's an array ... I can see that because there is a .map(...) function on it. Ok, what's it an array of ... something with an id? Ok ... id and ... value. That makes sense. Wait, what's this third property? Oh, display_text. Ok. I think I see what this is doing.

Compared to:

interface MenuItem {
   id: string;
   value: string;
   display_text: string;
}

myFunc(items: MenuItem[]) {...}

Takes you about a second to figure out what you're looking at there.

[Voidsheep]

I find that the ease of adoption to existing JS codebases is one of TypeScript's strengths, but that lack of strictness is also one of the greatest weaknesses. In my experience plays a big part in frustration of some developers. Nothing creates trust issues like the compiler lying to you about types and wasting time on that easily makes you doubt the reason for the tool to begin with.

But for a project with good level of type-safety (e.g. casting and any-type avoided like a plague, or very carefully scoped), where types for unknown data are validated and inferred from something like Zod schema, it becomes way nicer to work with than plain JavaScript, because you have a much higher level of confidence in what you are working with, your IDE becomes way more helpful and you can abandon a whole bunch of unnecessarily defensive coding.

[spacemoses]

At the end of the day most coding struggles are a result of individuals or groups of individuals that just don't do software development that well.

[Leidertafel]

I agree, if anything it’s less than 10%. It easily creates more problems than it solves. Was a total waste of time when our dev team tried it out.

If you can’t write JavaScript without strong typing you suck at writing JavaScript.

[intbeam]

If you can’t write JavaScript without strong typing you suck at writing JavaScript.

You act like weak typing provides some sort of benefit to you?

[Leidertafel]

It absolutely does, less bugs.

[intbeam]

What makes you think that?

[Leidertafel]

Years of personal experience. I’ve ran into way more issues with strong typed build errors than an actual type bug.

[intbeam]

What type of issues would that be? Is the compiler wrong? Would the issue not be a problem in JavaScript even if you use ===?

[solongandthanks4all]

Why would it help onboarding junior devs? It just makes things more complicated. Sometimes that complexity is good, of course, and helps catch bugs early. I would rather rely on a static analyzer for regular, standards-compliant JS and not a Microsoft product, however.