There are a bunch of nice languages featuring good FP support that compile to JS that are have viable sized developer communities and longer histories than TS. For example ReasonML, ClojureScript, Flow and Elm. Then you have the bunch of languages that compile to asm.js or WebAssembly. Not to mention the majority of Node and FE developers who continue to use JS.

TypeScript integrates with the JS ecosystem, often major JS libraries include typescript definitions in the box, or are even written in typescript.

Flow has been obsolete for a while now (yes I said it).

I agree that TS is closer to JS than ClojureScript is, but it seems to me to be its own compiled language with code generation targeting JS.

[1] https://www.typescriptlang.org/docs/handbook/2/generics.html

The main typescript features that require specialist codegen for ESNext targets are enums (especially const enums) and namespaces. These were added in the past when typescript was less strict about adding features that affect codegen, if proposed today they would not be accepted as typescript now has a policy of waiting for JavaScript to implement features first.

Edit: ok, it says it affects whether the program will typecheck, so it's consistent with not affecting code generation.

(More Turing completeness discussion at https://github.com/Microsoft/TypeScript/issues/14833)

Then there are other features that have no equivalent in JS. For example enums. And the handbook talks about what kind of JS they "compile to".

I don't think this is true any more. According to https://2020.stateofjs.com/en-US/technologies/javascript-fla... 78% of JS devs actively use TypeScript

Meanwhile, the StackOverflow 2020 survey, which reached twice as many JS developers (54k vs 23k), saw that only half of JS developers reported using TypeScript. (not counting any developers that reported using TS but not JS, which would drive the percentage further down). Again though—people who are more likely to fill out random surveys are going to be more plugged in to new technologies and more likely to adopt them.

I've never used Typescript, and I don't plan to. I don't care about static typing. It's nice occasionally, but I don't find that the structural problems I need to solve day to day when working on large codebases are the sorts best solved by static typing. When working on hobby projects, I don't use JS compilers at all, the set of JS supported by modern browsers is already very expressive and iterating very quickly.

Personally I find hard and scary to change things in js and being confident that it would work without breaking anything, with typescript I have that, some function rename, change parameter type, add/remove/rename object fields etc.

I found a couple of times when migrating some files to typescript misspelled names that would be hard to catch and passed the code reviews, that’s and easy task for the computer but harder for the developers, also using tools that makes your code reviews easy its great.

Python has lots of its own problems. Specifically, its type system, performance, and package management are all awful.

> Why would you ship with node_modules? ALWAYS use npm install. If you don't trust npm, the use something like CodeArtifact, but oh my, don't compress dependencies.

You've certainly convinced me that Deno's single binary deployment is a useful feature.

As a frontend dev, I use node tooling every day that has nothing to do with server code.

> Python is much better as 'general purpose'

Node is just fine for general purpose. I use it for shell scripting without any difficulty. Working with async in JS is a dream compared to most languages, and although I rarely use dependencies, when you need `em, node has a great ecosystem.

That said, I am 100% sold on Deno. Secure by default might not matter for server code that is going to have a couple of instances of it running, but the need to enable explicit flags for insecure APIs means that people who don't know how (or care) to read the code can use your program knowing that it literally can't access their filesystem or whatever.

Beyond that, Deno uses Promises for async. Node was built before promises and many APIs rely on callbacks vs promises. It also has the ability to compile to an executable.

But the number one for me is that the APIs mirror the browser APIs. This makes it much easier to extend frontend knowledge to building my own tooling.

3. I have a few internal CLIs for use in scenarios that don't have npm available by default. It's very nice to be able to ship a single runtime and not have the folks downstream from me need to worry about node version + npm version + package installs from untrusty sources, etc. I can do that work so they don't need to, and give them a single runtime. I happen to not use Deno at the moment, but it's an appealing feature. Python has a comparable problem: I run into issues with some frequency around python versions and python environments. There are solutions, yes, but there are also scenarios where you want to bring your own dependencies.

I haven't used CodeArtifact, but is it something you can deploy on-premise?

You could only ship the source code and package-lock file and run `npm ci` or `npm install --production`, which would only install dependencies you're actually using on your production machine, rather than including testing libraries or build frameworks.

Even better, you could set up a build and take advantage of tree-shaking (to some extent at least), then ship less code in fewer files.

I still use TypeScript, and I understand the benefits, but I'm not always a fan and will write plain JS when it fits better than TS.

[1] https://news.ycombinator.com/item?id=15090561

JavaScript is strongly typed in the sense that every value has a well-defined type. It's weak in the sense that it has implicit conversion between types in a lot of cases, but it's not as though those conversions don't follow particular rules if you know the types.

TypeScript gives you accurate static typing on top of that, so long as you don't use `any` as an escape. Arguably, `JSON.parse` returning `any` is the 1-million dollar mistake of TypeScript, because it leads a lot of people to think that they get automatic runtime typechecking for free, which they obviously don't, which leads to comments about how bad/slippery TypeScript is stemming from their misunderstanding.

In my experience, you only need to work around typings in TypeScript when you're dealing with some absurdly designed API that only made sense in the super-flexible world of olden-days JavaScript, or perhaps if you're doing some meta-programming, generating class definitions on the fly or such.

That may sincerely be, because how it feels as you're using it doesn't align with the objective truths of how it behaves. The definition of a strongly typed language has been well-cemented for some time. TypeScript does not completely align with that definition, thus it cannot be considered truly strongly typed.

Wikipedia disagrees with you in the opening paragraph about strong and weak typing: it's contentious. For all practical purposes that I can think of, TypeScript creates a strongly typed environment.

The problem comes when you're interacting with non-typed (or, worse, incorrectly-manually-typed) libraries, or misuse `any`. Honestly, I'd be interested to see a pure TypeScript program and where weak typing comes in. There are definitely a couple of language escapes (again, `JSON.parse`, previously `fn.bind`), but these are going away as TS gains better inference and type-propagation logic.

What is it? Is e.g. C++ strongly typed in that sense?

But when I started using it for backend and infra, the iteration speed is much slower, so even TS only saves a few % of deploys, it's still a noticeable amount of absolute time.

Everything gets compiled down to the same machine code in the end.

Yes. It seems the majority of engineering decisions are tighly coupled to this expression right there. Future be damned because a Medium.com ex-FAANG said TS is where it's at

Bless them and the hype train, woe to developers 5 years from now.

Ditto. It's also important to remember that TS transpiles to JS, so you're not locked in in that sense.

(I've actually seens TS-to-JS-transpiled code that is much better than code that was written in/as JS in the first place.)

A desire to not have IP coupled to Microsoft and a desire to put the burden/discipline on the self to ensure clean API design versus using TypeScript as a crutch to do it for you. In my experience, writing JavaScript code that's conscious of types/inputs/etc. is far easier (and more productive) than maintaining a TS codebase and all the trimmings that come with it (i.e., dependency on build tools, frameworks, etc). A lot of hidden costs.

For example, JavaScript default args are really helpful for avoiding type errors:

const nameString = (name = {}) => { return `${name.first} ${name.last}`; };

Here, because I set a default expected type (technically speaking), I get back an empty string without runtime errors. If I get an empty string during dev in my UI, I know to go handle the case, or, write a test to call my attention to the problem (often unnecessary because the "bug" is a design issue).

Just let the computer handle this trivia and concentrate your efforts on adding value I say. Sure it takes an hour or two to set up the tooling, but once you are up and running there is no overhead (unless you consider defining types an overhead). Compiles take a fraction of a second and the browser has usually already reloaded itself before you've even physically moved your eyes over to the other monitor

Well, in your example, with default params, you get back an "undefined undefined", not an empty string, so even simple code is sometimes easy to get wrong. Proper amount of typing actually helps a lot to avoid it.

  basically you just described dynamic languages here. We know why and how to program in a dynamic language. We don’t want that though. People that are using TypeScript are using it for the static typing.

Using typescript is very progressive, you can add types line by line if you want. There's not much setup really other than using TSC to compile the files.