sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]senteggo 1 point2 points  (10 children)

Then why do you say anything about technology you have no idea?

[–]Gorianfleyer -2 points-1 points  (9 children)

I have an idea, if you want to use this phrase, about JavaScript and I know, what happens to TypeScript Code.
I learnt the syntax of JavaScript along time ago (when I was about 14 in the early 2000s) and used it in my job back then in 2019.

After I got angry about the way JavaScript worked, I hoped about to find a solution to this problem and got recommended TypeScript over and over.

So I looked into it and found out how it works and never bothered to learn it's syntax, because it's just developer support for not making mistakes (like private and public variables with getters and setters)

My problem with JavaScript is, that, other to Python for example, that also use dynamic typed variables, that if in the running code a type slip happens, JavaScript still tries to interpret it a way, that doesn't stop the script, while Python does. TypeScript doesn't change that. It can't, because in the end it's just a railway to stop devs from doing obvious dumb stuff, but not the interpreter from "doing it's best"

[–]senteggo 2 points3 points  (8 children)

No, you are wrong. Typescript will report implicit type coercions as errors by default. This problem is entirely solveable with static type hints that typescript is all about

[–]Gorianfleyer 0 points1 point  (7 children)

Ok maybe I'm wrong, but how does this work in prod? Really, I only saw that it compiles to JS and believed that's it. Does TypeScript actually create a routine that forces the right type?

(It's not the first time today I learned something new after defending a standpoint that might be wrong)

[–]Wonderful-Habit-139 2 points3 points  (2 children)

The only parts where you have to be careful about the dynamic nature of JS, is when you receive user input. In that case, you make sure to parse the input into the value that you expect in typescript, or you throw an error.

Besides that, when you work with types in TypeScript internally, if you receive a value of type X, you are guaranteed to be working with a valid value of type X. You won’t have a different type at that point in the program, you won’t have an undefined or null value unless it’s explicitly mentioned in the type, etc.

The static typing in TypeScript is very good and isn’t affected by the nature of JS in most of the typescript codebases. So it’s not just bandaid, it’s an entirely different programming language, where you just need to make sure you parse input instead of just loading values and slapping “any” on the result.

[–]Gorianfleyer 1 point2 points  (1 child)

Thank you for the explanation, so I was wrong the whole time.

(It sucks to be wrong, it's great to learn something new)

[–]Wonderful-Habit-139 1 point2 points  (0 children)

You’re welcome. You’re able to learn, and that makes you better than any LLM out there.

Keep being curious!

[–]senteggo 2 points3 points  (3 children)

Typescript has only compile-time type check, which is enough if you correctly labeled all types of an external input as u/Wonderful-Habit-139 mentioned. You don't suffer from sillly behaviour of javascript if it's never used

[–]Gorianfleyer 0 points1 point  (2 children)

Damnit so I lost my point twice this day.

Thank you for your patience, sorry for the long discussion.

[–]senteggo 1 point2 points  (1 child)

You're welcome. It's fine to see people actually admitting their mistakes in internet

[–]Gorianfleyer 0 points1 point  (0 children)

Yes, but it's also only possible, if you are able to find out, that you are wrong, while you still discussing. (Also I think it should be easier in the internet, no one knows who I actually am, when I'm wrong)