> Types

There are so many better options if you want a good type system (Elm, PureScript, Rescript, GHCjs, Scala.js, and many more). TypeScript is unsound, and necessarily by it's design, it has to take on weird issues to maintain compatibility with JavaScript (null/undefined, can run effect anywhere, a lot of codebases are filled with any types). Heck, TypeScript doesn't even come with ADTs and proper pattern matching.

> There are so many better options if you want a good type system

I am looking for basic type checking to prevent me from doing stupid things and catching bugs at "compiletime" instead of runtime.

Typescript interfaces with their structural typing do the job just fine.

I think people are underestimating the power of ecosystem. I use JS daily. Deno allows me to use it on the server as well without doing crazy things.

You have been able to do something similar in Java for a very long time with Mozilla Rhino (and now GraalJs) but without the same level of comfort and convenience.

> TypeScript doesn't even come with ADTs

You still can use them [0].

> proper pattern matching

[1] is pretty good.

[0] https://itnext.io/practical-introduction-to-algebraic-dataty...

[1] https://github.com/gvergnaud/ts-pattern

They need to be first-class. Not means the ergonomics aren't great and it won't be the developer default because it requires a library. It's not good enough considering how fundamental these two are in many languages (it's even in Java now)

Similarly: https://www.assemblyscript.org/

> A TypeScript-like language for WebAssembly.

> AssemblyScript targets WebAssembly's feature set specifically, giving developers low-level control over their code.

> Being a variant of TypeScript makes it easy to compile to WebAssembly without learning a new language.

> Integrates with the existing Web ecosystem - no heavy toolchains to set up. Simply npm install it!

So TypeScript is designed for the internet, and languages with good type systems are not.

This has nothing to do with the GP's comment, which was about local scripting (replacing "shell scripts and Java")

Typescript definitely has some flaws but it also has some really powerful features that aren't found in any other type systems, like the ones you listed.

And in any case I don't think anyone is really saying "Use Deno because it has static type annotations". It's "Use Deno because it has static type annotations and is fast and easy to deploy and has a huge ecosystem and doesn't require a project setup file to use third party libraries and ..."

> Deno has replaced shell scripts and Java in a lot of places for me.

> - Single executable: Write programs that run the same on Linux/Windows without forcing the user to download the entire universe like other runtime environments.

OK, I understand your comment wrt Java, but with shellscripts? What universe are you downloading?

For that matter - your 3 listed reasons make a very argument for "a normal compiled language". Consider an older/popular one...C++. It's very typed, compiled to a single executable, and "bundling" is "linking"(you can do it any way you like, including staticly linking all your deps).

If I understand your comment, are you saying that previously you wrote software 2 ways: shellscripts and Java. You replaced them with...any entirely new interpreted language(JS)?

I'm not denigrating JS/deno/node/whatever, I'm pointing out your 3 reasons are built in features to any compiled language in the last 40 years.

> wrt Java

Not just Java. Python, Ruby, Node etc suffer from the same problem. And I am talking as an end-user here.

I once downloaded something based on one runtime which then proceeded to download another runtime which it needed to run one little script. There are programs out there that have node/npm as a dependency.[1] People are crazy.

> your 3 listed reasons make a very argument for "a normal compiled language"

One of my hobbies involves writing compilers and parsers.[2][3] I have tried a lot of "normal" languages and have stuck to Java (in spite of its excessive verbosity) for work reasons. Some languages I cannot tolerate for aesthetic reasons.

For now, there is no alternative to TypeScript.

> you wrote software 2 ways: shellscripts and Java. You replaced them with...any entirely new interpreted language(JS)

I used to run a mixed-environment (Windows + Linux) and a lot of glue code that drove other software had to be written twice (sh/bash + cmd/bat) before WSL came along. That problem has disappeared.

I also used to write a lot of tools (servers and cli apps) in Java. Some of those I have moved over TypeScript-on-Deno.

> I'm not denigrating JS/deno/node/whatever

I used to look down on JS a decade or so back. My experience with Rhino and now Deno changed that. There is a lot of stuff I do now which I simply would not do if I have to fire up an entire Java project to do.

[1] https://archlinux.org/packages/community/x86_64/nodejs/

[2] https://github.com/s-i-e-v-e/ut

[3] https://github.com/s-i-e-v-e/sxml

> OK, I understand your comment wrt Java, but with shellscripts? What universe are you downloading?

Are shell scripts cross-compatible if you haven't installed WSL?

WSL? Are you asking...is software for one operating system able to run on another operating system without installing a compatibility layer(if it exists)? If so, the answer is "no, of course not".

> - Single executable: Write programs that run the same on Linux/Windows without forcing the user to download the entire universe like other runtime environments.

So how is this statement wrong for shell scripts? You can't write a shell script that "runs the same on Linux/Windows without forcing the user to download a runtime" because you can't write a shell script that runs on Linux/Windows.

This sounds like something you can get with other languages which compile to native x86_64 or arm or whatever - specially the single executable concept is ages old and predates the entire internet. Why use js, which is slow?

This just don't make sense. People do scripting in sh, bash, python, etc all the time. Why not js?

There is always something that doesn't fit either the use case or the aesthetic sense.

> Why use js,

For someone working with JS on the front end, the ability to not only use the same language, but also the same libraries/modules/functions is very valuable.

> which is slow?

Not that slow, once a JS engine takes over.

Using Java for shell scripts (using a shebang) is on my todo list. IIRC, there's a GraalVM or Truffle or something interpreter that'd work.