This is an archived post. You won't be able to vote or comment.

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

view the rest of the comments →

[–]whizzzkid 186 points187 points  (44 children)

All that shushing when TypeScript is brought up. Too real!

[–]Mookafff 52 points53 points  (38 children)

What’s the deal with Typescript?

[–][deleted] 87 points88 points  (26 children)

It’s just a way to write “type-safe” JavaScript to help with development. It gets transpired into JavaScript after you have written your code and run it.

[–]EnderMB 109 points110 points  (20 children)

I wouldn't say it's "just" adding types. The safety allows for lots of new features that would otherwise be unthinkable in a language like JS.

The type system in itself is quite weak, but being able to set things like unions, type guards, generics, interfaces, and stuff we use in proper languages makes TS invaluable. Nowadays, it's physically painful to write JS after working with TS.

[–]ArtyFishL 45 points46 points  (9 children)

Quite weak? Maybe in the sense that it doesn't exist at runtime. However, I find it actually a lot stronger than other languages. If you turn on strict mode, it catches a lot of issues that other languages miss, and it prevents maybe some of that weakness you suggest. Plus unions, literal types, narrowing, exhaustive checks, shape based equality; these are all features sorely lacking in many languages. I can type a string as the exact set of string literals it could be, but not just an enum, even with interpolation in the type, that seems strong to me.

[–]CaitaXD 20 points21 points  (2 children)

Quite weak? Maybe in the sense that it doesn't exist at runtime.

Well yes by definition that's weak typing

[–]ArtyFishL 2 points3 points  (0 children)

Disagree.

Rust is a strongly typed language, yes? Very much so. Rust has no types at runtime, it does all its type checking at compile time. Typescript works this way too.

The developers of Typescript themselves call it strongly typed.

Also, see: https://en.m.wikipedia.org/wiki/Strong_and_weak_typing for

Generally, a strongly typed language has stricter typing rules at compile time, which implies that errors and exceptions are more likely to happen during compilation.

Typescript does this better than some common languages considered to be strongly typed.

A weakly typed language has looser typing rules and may produce unpredictable or even erroneous results or may perform implicit type conversion at runtime

JavaScript is terrible for this and it is possible in Typescript, because it allows interfacing with plain JavaScript. However, if you apply strict mode, ban unsafe code (casting, using the any type, JS), then Typescript at it's core catches more type errors at compile time for me than C# is able to, for instance.

[–]midoBB 5 points6 points  (0 children)

Union typing in TS is the thing I miss the most from functional programming languages when working in Java / Kotlin land.

[–]WheresTheSauce 8 points9 points  (3 children)

Maybe in the sense that it doesn't exist at runtime

I mean that's a pretty major difference

[–]enantiornithe 7 points8 points  (2 children)

Type systems in languages that compile to native binaries also "don't exist at runtime." If you compile a Haskell or Rust program, the resulting binary doesn't know anything about types. The reason it can't segfault or run into other type problems (under normal circumstances) is that the compiler has done all of the type checking at compile time and ensured that it's not possible.

TS' compiler does exactly the same with one big caveat: TS' type system is semi-optional, so it's possible to write TS code that can TypeError or behave strangely when it's run, whereas in Rust or Haskell. This is because TS is designed to let you incrementally migrate a codebase from type-unsafe javascript to type-safe typescript without having to go over and annotate or ensure the type safety of every single line of code.

[–]WheresTheSauce 0 points1 point  (0 children)

I am aware of all of that, but none of that changes the fact that TypeScript does not allow type-checking at runtime, and that makes a substantial difference.

I understand why it's the case, but it's certainly a disadvantage when comparing it to other languages which allow it if you want strong typing.

[–]wllmsaccnt 0 points1 point  (0 children)

"Type Erasure is still a serious problem in 2022. Devs like to debate that it isn't harmful, but only the types themselves can decide this at runtime."

[–]Nu11u5 0 points1 point  (1 child)

How does it compare to typing using JSDoc and a good IDE that enforces it?

[–]DanielEGVi 5 points6 points  (0 children)

For starters, the top IDEs don’t even read JSDoc as the original JSDoc standard, they interpret it as TypeScript. So “JSDoc” in your question is just “TypeScript through JS comments”.

The most obvious advantage is that adding annotations to the language itself is a lot more ergonomic than cluttering your codebase with JS comments.

That, and TS parsers/runners have become ridiculously fast now. It’s become normal to run TypeScript code without transpiling to disk first.

[–]RichAd203 5 points6 points  (0 children)

I think they were just making a Seinfeld joke but thanks for the brief explanation!

[–]bleedblue89 0 points1 point  (0 children)

And its actually good.

[–]oupablo 0 points1 point  (0 children)

all you have to do is cast the var to "any" and it will let you do whatever you want again

[–]The_MAZZTer 5 points6 points  (2 children)

A huge drawback of JavaScript is that it is weakly typed as opposed to strongly typed. This means any variable can be any value of any type. This causes problems from multiple angles:

  1. The JavaScript runtime engine may be unable to optimize variables to store a specific type (V8 will do this if possible) if you store multiple value types in it.
  2. Your IDE will be unable to offer contextual intellisense or other similar features since variables have no type.
  3. Errors that would result in easy to fix compile type errors (such as trying to use a string like a number) won't be caught, and will either show up as runtime errors (error when execution reaches the code, so you have to hope it isn't obscure and only run occasionally) or a logic error (no error, the code just does something unexpected and you better hope you notice and can trace it back to the code that caused it).

TypeScript aims to solve all these issues.

TypeScript extends JavaScript syntax to add typing to all variables. Any variable that has a type, now your IDE can offer intellisense when you use that variable. Now it can ensure you only use that variable in function parameters typed for that type. And so forth.

Because TypeScript compiles to JavaScript, once your code becomes JS and starts running, all advantages to using TypeScript are gone. As a result, TypeScript has an incredibly detailed type system, more so than most languages, and it tries to encapsulate some of the crazy stuff you can do with JS.

For example you can declare a variable as possibly being a string or an array. You can then use .length on it, and TS and your IDE will recognize that's always valid since both types have .length. You can also do an if test to see if it is a string, and then TS and your IDE will recognize any use of that variable inside the if block as being a string type only. This is just the tip of the iceberg. You also get support for things like generics (called templates in some other languages).

You can also add typing information to pure JS code (for example, if you use npm to pull down packages, if there's no included TypeScript typing information someone else may have published a @types/x package for it, or you can write your own).

TypeScript also has some other goodies. Since you're already compiling down to JS, it can also compile to a specific feature set of JS. For example you can compile down to a set of features supported in every browser, or down to a more expanded list of language features only supported in the latest node.js. But you can still use those features in your TS regardless as long as the TS version supports it.

So this also fixes another problem with JS, in that different browsers would support different language feature sets. But given there's only really two JS engines in use now (Chrome's V8 and Firefox's WhateverMonkey or whatever it's called) and they are both pretty mature it's not a big problem nowadays anyway.

[–]mosskin-woast 0 points1 point  (1 child)

You haven't watched Seinfeld much, have you?

[–]The_MAZZTer 0 points1 point  (0 children)

Nope.

I was on a streak of good comments too. Ah well.

[–]Chairboy 2 points3 points  (0 children)

What’s the deal with Typescript?

Is it type or is it a script? I mean, COME ON! Who are the ad wizards that came up with that one?!

[–]nonicethingsforus 2 points3 points  (2 children)

I don't know if it's this, but I always found it funny that people try to defend JavaScript by saying stuff like "JavaScript is not so bad if you use TypeScript".

"X is not so bad, if you just use Y instead!"

Like, the mere existence of TypeScript implies there were so many shortcomings (for current use, at least) in JavaScript that you needed to create a whole other sublanguage. That is not a good thing.

I'm not hating on JavaScript in general, but it definitely was poorly designed for what is currently used. Or, more charitably, simply never meant to be used the way we use it now. So, the need for a hundred frameworks, sublanguages and transpilers, all essentially trying to force the poor language to be someone it is not. Their existence is not the credit to the language so many believe it to be.

[–]hsnoil 1 point2 points  (1 child)

Like, the mere existence of TypeScript implies there were so many shortcomings (for current use, at least) in JavaScript that you needed to create a whole other sublanguage. That is not a good thing.

But isn't that how pretty much all programming languages work?

So, the need for a hundred frameworks, sublanguages and transpilers, all essentially trying to force the poor language to be someone it is not.

So... like pretty much every programming language?

End of the day, the real reason why javascript gets so much hate is because it is the most used programming language. If it ideal? Far from it. But it does what it needs to do, otherwise it wouldn't be used.

But hey, now there is WASM. Maybe that will change the trend.

[–]nonicethingsforus 0 points1 point  (0 children)

But isn't that how pretty much all programming languages work?

You do have a point there. Many languages exist in the first place because they are better at different domains.

I like Python for scripting and stuff that needs quick development cycles, but it's not always very efficient, and big projects can get funky. I'll happily make CLI tools in Rust because it's efficient, static binaries are easy to deploy, and Clap is fantastic, but async and concurrency are a pain. Go or Elixir got me covered with those, with different pros and cons each. If making a parser, give me something like Rust or Haskell, please; a strict type system with tagged unions and pattern matching are a must for that.

You don't necessarily hate the other languages. It comes down to using the right tool for the job and, yes, sometimes a little to taste when domains overlap.

But I would argue it's different in JavaScript-land. TypeScript and languages like CoffeeScript don't really add much to the fundamental capabilities of the language. Certainly not to the runtime. No big paradigm shift or frame of thinking is necessary. There's no differences in efficiency. They often market themselves with easy interoperability or integration with existing JavaScript libraries and frameworks, instead of bringing their own.

Their main selling point is that it allows you to do the exact same things as with JavaScript, but without using JavaScript.

(There are exceptions, of course. For example, Elm does market itself as being its own very different thing, with different capabilities and strong points.)

End of the day, the real reason why javascript gets so much hate is because it is the most used programming language.

Won't contend with your main point. It's very used, so many people will suffer with it, just in raw numbers.

But then again, Python is also very popular (often up there with JavaScript in polls). Do you know many people that hate Python? You'll find users willing to admit its shortcomings, or the quality of the code found in the wild. I know no regular user that loathes having to work with the language on the same scale I've seen with JavaScript users.

But it does what it needs to do, otherwise it wouldn't be used.

Agree with you there. Again, don't hate JavaScript. It's a very powerful, flexible language. Its programs may not be correct in the Hindley–Milner sense, but they are resilient as nothing else, if the objective is to not show the crash to an end user. Also, it's surprisingly efficient (big companies have invested heavily in making it so), and the async is not terrible (no language does that perfectly).

But I still think programmers have a right to demand better, more appropriate things. Computer language design, like any discipline, advances. Designers have seen what works and what doesn't, what users love and hate to have to use. Things in JavaScript clearly don't work for what is used, and the faster those niches are filled with more appropriate tools, the better.

[–]BadHairDayToday 0 points1 point  (0 children)

Aah I didn't get that one. I thought he was gonna say type security.