Discussion on: JavaScript First, Then TypeScript

[José Pablo Ramírez Vargas]

Ok, I see that you are incapable of admitting that tsc !== TypeScript, which makes you repeat over and over the idea that esbuild is a "trash remover". I guess we will just have to agree to disagree. REPL-like experiences are possible today for TypeScript-powered projects, whether you want to admit it or not. TypeScript is in no way an impediment to this.

Furthermore, I have demonstrated fully that TypeScript does bring value to the table using a 3-line example. I have fully demonstrated what probably is the greatest benefit of this language. Whether or not you want to admit it, is again, up to you.

I believe I'll just let other people reading this judge for themselves. I will end my participation here saying: Make your own minds. Always be critical to what you hear and read. I personally think this whole movement has no reason to be, and that TypeScript is an invaluable asset that helps developers produce better code faster.

[peerreynders]

I have demonstrated fully that TypeScript does bring value to the table using a 3-line example.

Value that can be delivered with static type analysis alone. No language required.

The point is that Flow delivers exactly the same value, according to some people at a higher level of quality, without proclaiming itself as a language but simply as a “static type checker”.

So:

Betting on TypeScript tooling as a static type checker (TS-as-a-devtool) is where the current value is.

Using it as a language is risky especially for features that are not on the current list of TC39 proposals.

[José Pablo Ramírez Vargas]

Ok, so clearly you want to continue arguing. The problem I have, and I say this without trying to be antagonist, is that you are like Alexa:

Me: "Alexa, isn't this a TypeScript-exclusive feature?"
Alexa: "Facebook uses Flow for type checking."

If you can actually stay on topic, I'll be glad to continue the discussion. If you, however, are incapable of reasoning within the boundaries of the topic, I'll just make myself scarce. I am not, and will not be, diverted by off-topic subjects. I am also not interested in other people's words. I'm interested in your own and my own. We are the ones in this discussion, not others. All your quoting is irrelevant to me because I make my own mind and not comply with others just because of their alleged reputations.

I'll start: I love, as many of us do, VS Code. Flow and VS Code are not a thing. Therefore, it is not going to be a thing for us to move to Flow. Let's just drop Flow. Let's talk about things that could actually happen.

Let's discuss the very important matter: TypeScript exists, is a language and comes with tsc from Microsoft. tsc is not very performant. Is this a "language" feature? It is not. Why? Anyone could make a better transpiler and the language itself would be unaffected. Agreed? If yes, you must also agree by extension, that tsc !== TypeScript. Yes? No? Discuss, but stay on topic. I am not interested in stories about the history of pictographic communications in caves found in the Middle East that date from 15.000 BC.

[peerreynders]

Anyone could make a better transpiler and the language itself would be unaffected.

Faster transpilers have already been delivered.

As far as I'm aware tsc (and LSP) is the only tool capable of type checking the TypeScript syntax and nobody is working on changing that.

And as to your example:

// @ts-check
/** @param {number | void } value */
function doSomething(value) {
    return value * 6;
}

TS playground

• Same type checking benefit
• No TypeScript syntax (or language) in value space where the JavaScript exists.
• Only TypeScript annotations to be processed by tsc
• The TypeScript syntax used here applies entirely to type space

• variable declaration space
• type declaration space

Fixed:

// @ts-check
/** @param {number | void} [value] */
function doSomething(value) {
    return (value ? value : 1) * 6;
}

I love, as many of us do, VS Code. Flow and VS Code are not a thing. Therefore, it is not going to be a thing for us to move to Flow.

Which just emphasizes again that TypeScript adoption/popularity is primarily about developer convenience rather than safe types.

[José Pablo Ramírez Vargas]

Great! We are getting somewhere now. Tell me: Is the benefit coming from JsDoc, or Typescript enforcing JsDoc? Because in jsfiddle.net:

I get no feedback.

[peerreynders]

• JSDoc simply acts as a conveyance for TypeScript's type declaration syntax
• Either tsc or LSP parse the type syntax inside the JSDoc annotation to fill in the "type space gaps" in the JavaScript code.
• Together with the information in the value space JavaScript, tsc or LSP determine whether the code type checks.
• The programming language is still just JavaScript.

[José Pablo Ramírez Vargas]

Ok, yes. I see your point more clearly now. Because JsDoc goes into comments, there's no stripping to do. That is most certainly a clear advantage, probably the greatest advantage over TypeScript, no doubt.

So, we have two options for type safety: One that uses comments, and one that doesn't, and people say the latter can go away. I guess it is only logical. Unless, that is, that TypeScript (the latter) has something else in its favor, and there is.

TypeScript can bring new JavaScript features to life faster. Yes, you have already argued about how that could be problematic. Still, it is a feature that only TypeScript provides. I believe in the democratic process of every developer to choose their tooling, and I truly believe that this is one of those cases. It is no small thing, in my opinion. Yes, there will be people that say this doesn't justify the grievances of transpiling. I get that.

At this point, I must admit you have me half-convinced. See? All that ranting about Flow and all those quoting got you nowhere with me, but your succinct demonstration got me thinking!

I could probably ask you about the capabilities of JsDoc, but I suppose that I should just investigate that on my own to determine whether or not I should opt for JsDoc. For example, it is very difficult for me (or impossible, really) to imagine I can define the types I need for an entire project with just comments. I am a back-end developer, so my experience with JavaScript is not very extensive. My main concern right now is: Can I define the data models of an entire application in JsDoc, centrally in one location and use the definitions in the rest of the project?

UPDATE: Question: Is JsDoc a thing by itself? Or must it always piggyback ride on TypeScript? I must confess I'm confused about this topic for the first time. I am concluding that in VS Code all that is needed is the language server. If this is true, and JsDoc can provide an alternative to at least most of TypeScript features, it is something I must learn ASAP. The one thing that would seriously worry me is not having a CI/CD method of making sure developers did their work of honoring all of the Intellisense feedback.