I would make a services folder to accommodate data services, and I need to type those. Just because they are typed I won't create a new package.json to make it a sub-project. It is very impractical.
I totally agree. That is why I give some leeway in my definition of "library code" in that it can literally be any code you import from the "application code".
Monorepos are overkill, in my opinion, for the gains.
Of course! And for that reason, I reiterate that I give leeway to my definition of "library code" so that it also includes files of the same project. As long as they are imported somehow into the "application code", we may as well consider them to be "library code".
If you are promiting "developer experience" here, what is that experience, exactly? To write code in a .js file instead of a .ts file?
The main thesis of the article is that I have begun to treat the .js extension as a deliberate communication of the developer's decision to limit the application code to solely rely on type inference for type safety. In cases where type inference is insufficient, I upgrade the .js file into a .ts file but as a last resort considering the most minimal surface possible.
The "developer experience" that this scheme provides (at least in my experience) is that I can tell from the file extension alone which files in the project are "[dumb] application code" (for lack of a better word) and which files are the more interesting and meaty "library code".
Consider the application entry point for example. Seeing a main.js file certainly jumps out more than a main.ts file in a sea of .ts library code, right? Here, I find that the .js extension now takes on a new meaning: "I am consumer code!"
Clearly, you have a well-organized mind that thrives in the details. I think you are like me 7 or so years ago. I think you are over-selling this because there isn't much to sell. I say this with admiration, however. Your train of thought demonstrates cleverness. You just need to apply an extra step: Practicality.
I understand what you say fully, I think. I just see no practical, useful gains in it. To see whether code is "consumer code" or "witty, complex code" by means of a file extension is nowhere in my to-do's.
Clearly, you have a well-organized mind that thrives in the details.
Thank you! That means a lot to me.
I just see no practical, useful gains in it. To see whether code is "consumer code" or "witty, complex code" by means of a file extension is nowhere in my to-do's.
This is totally fair. I must admit that the file extension semantics are quite subtle. It is not immediately apparent why such a mix of .js and .ts files exist.
Nevertheless, I personally find them very helpful when navigating codebases nowadays. Onboarding new developers who use VS Code (for instance) renders file icons according to their file extension. The distinct yellow JS icon versus the blue TS icon is a neat visual signal for possible entry points and consumers (e.g., perhaps UI components?) in the project.
“ …esbuild has built-in support for parsing TypeScript syntax and discarding the type annotations.”.
Type discarding bundlers are used to accelerate the feedback loop that otherwise would be significantly slower if they were limited to using tsc—especially in large code bases.
Relying on TypeScript specific features (e.g. decorators) essentially blocks that build time optimization.
Using non-JavaScript TypeScript features comes with significant tradeoffs. By and large TypeScript is being used as a JavaScript type linter, either with it's own “more convenient” syntax or in combination with JSDoc.
Using TypeScript as a “language” presents it's own risk.
“ …esbuild has built-in support for parsing TypeScript syntax and discarding the type annotations.”.
The point being? I could not infer.
Type discarding bundlers are used to accelerate the feedback loop that otherwise would be significantly slower if they were limited to using tsc—especially in large code bases.
I completely agree. However, tsc !== TypeScript. The compiler of choice is not the language itself. The language still carries many benefits, regardless of the compiler/transpiler of choice. So I guess I continue to miss your point.
Regarding build times: Yes, using TypeScript adds a "transpilation/compilation" step to the CI/CD. But how much are we talking about? Does anybody have benchmarks lying around?
… TypeScript is being used as a JavaScript type linter [not as a compile-to-JS language].
step to the CI/CD.
I'm not talking about CI/CD. I'm talking about during normal development and/or micro testing; development approximating REPL-driven programming (… a set of tools and practices for programming that emphasize fast and rich feedback). It allows you to bypass many specious TS-errors until you are ready to address them in earnest and run a «full blown» type check, not just stripping the type annotations.
Ok, I saw the video. OMG. Is people like this now? In the video:
TypeScript is a linter because it produces JS.
Is C# a linter because it produces MSIL? OMG. Clearly this person and anyone that backs him up has lost the depth in their train of thought. Pretty much the entire video should be deleted.
People reading this: Did you know that before C, languages were untyped? Do you know how types are really used by compilers? My guess is No, you don't know because you keep minimizing the importance of types. I'll leave this as homework assignment to you all, avid followers of the "kill TypeScript because typing is linting" movement.
I'm talking about during normal development and/or micro testing;
This already exists and TypeScript does not interfere with it. Literally every Vite + TS + <Technology> project uses esbuild to provide this experience. Is TypeScript getting in the way of this? How? When? Where? I don't see the relation between TypeScript and the inability to have REPL-like development experiences. It sounds to me that people are thinking tsc to be mandatory when using TypeScript. Is not.
I don't see the relation between TypeScript and the inability to have REPL-like development experiences.
The (lack of) type checking speed of tsc. Nobody uses anything else for type checking as all the alternatives strictly strip but do not type check (and perhaps even transform).
As I alluded to before, TypeScript was never about type safety, it's about “somewhat safer types as long as it doesn't cause the developer any additional effort”— i.e. developer convenience first.
It has always been my contention that people who care about types would use something more like ReScript rather than TypeScript and simply accept the burden of managing JS interoperability. TypeScript makes many (permanent) compromises in order to allow progressive adoption on a JS code base and to consume pure-JS libraries.
"kill TypeScript because typing is linting" movement.
It's too far gone for that. Again: TypeScript's popularity has nothing to do with types but everything to do with developer convenience via Intellisense. Accepting anything else is just being in denial.
“Note that Vite only performs transpilation on .ts files and does NOT perform type checking. It assumes type checking is taken care of by your IDE and build process.”
Vite achieves it's level of experience by bypassing the type checking stage entirely. Most of the time people just fix the issues as they see them in their editor via LSP. Then in CI/CD tsc -noEmit is used to catch any errors that may have been missed.
The (lack of) type checking speed of tsc. Nobody uses anything else for type checking as all the alternatives strictly strip but do not type check (and perhaps even transform).
Ok, but this is tsc, the compiler, notTypeScript, the language.
It's too far gone for that. Again: TypeScript's popularity has nothing to do with types but everything to do with developer convenience via intellisense. Accepting anything else is being in denial.
Intellisense is the live reflection of the compiler. Wanting this live reflection is nothing to be ashamed of. To say that you "want Intellisense but not compilation" is impossible, as Intellisense is completely predicated in the compiliation process.
Vite achieves it's level of experience by bypassing the type checking stage entirely.
Yes, and there's nothing wrong with that. You, as a developer, should be fully aware of this. You, as a developer, once you are happy with your product, should then kick off the TS compiler to ensure your project is error-free. You, as a developer, should include TS compilation in CI/CD as well. How does any of this preventing REPL-like experiences?? The concept of TS somehow getting in the way simply escapes me. Because most people don't do it properly, then it is TypeScript's fault and must be stopped? Or are people saying that this is "a bad thing" because somehow compilation should be in every single scenario every second of the way or not exist at all? That would also be non-sense to me.
Ok, but this is tsc, the compiler, not TypeScript, the language.
Some would argue that tsc isn't a compiler in the original sense.
In the early days of C++, Cfront was identified as a cross-compiler largely because it did not change the granularity/level of it's output―it performed a code transformation but stayed on the same high level of language. Later the term transpiler was coined for transforming-compiler underlining that the transformed output wasn't operating at a finer granularity (e.g. assembler).
Given that it is possible to just strip the TypeScript annotations with minimal transformation, TypeScript is just a tsc syntax for JavaScript rather than a language. Admittedly TS JSDoc would have been the more authentic solution but that would have never gained any widespread adoption because it would have been too inconvenient for application developers.
TypeScript has always been squarely targeted at application developers rather than library authors which always had other ways of providing the “types” to support their users development environment's code completion:
“TypeScript began its life as an attempt to bring traditional object-oriented types to JavaScript so that the programmers at Microsoft could bring traditional object-oriented programs to the web. As it has developed, TypeScript’s type system has evolved to model code written by native JavaScripters. The resulting system is powerful, interesting and messy.”
should then kick off the TS compiler to ensure your project is error-free.
It emphasizes how TypeScript is just lipstick on JavaScript.
This is so harsh! Made me laugh. 😄
Ok, so this feud is making my head spin. On one side, there is people saying TypeScript should not exist. On the other, there's people like me saying TypeScript provides value. The main issue is that people whine about their source code being more difficult to maintain for something that gives them nothing. Am I correct so far? If yes, these people say that, because of its alleged zero value it should not exist. This is the overall view.
Now, especifically:
TypeScript compilation is just linting because it brings nothing to the table.
TypeScript compilation precludes or "soils" the REPL-like experience.
I think we can agree that #2 is false. Let's see about #1.
One of the things that I like the most of TypeScript because I can state the data types, is catching missing logic. A very simplified example:
Because I can specify the data types, both Intellisense and the transpilation step (tsc) will tell me that I forgot the fact that value could be undefined.
TypeScript compilation precludes or "soils" the REPL-like experience.
I think we can agree that #2 is false.
I don't see how. Starting with TypeScript the REPL-like experience can only be realized by using a type stripper. There is no --transpileOnly flag in tsc so the type checking (executing in a JS runtime) bogs the feedback cycle down. The only other way to bypass tsc is to write plain JavaScript an annotate it with TS types inside JSDoc annotations.
Aside:
Nobody is going to argue that React isn't “popular” (whatever else one might think of it). React isn't developed with TypeScript. The DefinitelyTyped types are maintained by the React team but React itself is typed with Flow. AFAIK Flow was developed with OCaml which is fairly popular with compiler writers because it's binary execution speeds are "close to a compiler written in plain C". It stands to reason that Flow never had the tsc speed issues so it never slowed the React team's development flow.
Many people prefer Flow over TypeScript however Flow never caught on, perhaps because MS Windows wasn't supported until late 2016 by which time DefinitelyTyped was already firmly established and now the Angular 2 release further increased general interest in TypeScript.
In some ways one could say that TypeScript is more a product of a "productivity culture" while Flow seems to lean more towards the outcome of an "engineering culture" (though I would classify React itself as a product designed for a "productivity culture").
Am I correct so far?
People value TypeScript for the developer convenience it provides in their development environment, primarily VSCode (or any other LSP supporting environment).
Library authors requiring strict control over the runtime JavaScript code (for whatever reason) elect to use TS JSDoc primarily to deliver consistent TypeScript types for their users, with the side benefit of (only) on demand tsc static type analysis.
Do linters do this?
Linters in the original sense no.
But in the web dev world the concept of static analysis tools for dynamic languages was virtually unheard of (example Erlang: dialyzer; Elixir: dialyxir).
Flow had the right idea: be a static analysis tool that supports an inline type syntax and be fast enough to never get in the way.
TypeScript started with ambitions to be a language but the enum fiasco just drives the home the point that deviating from the JavaScript baseline only comes back to haunt (and hurt) TypeScript.
So in the web dev world static analysis tools were explained as "type linters".
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.
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.
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.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I totally agree. That is why I give some leeway in my definition of "library code" in that it can literally be any code you import from the "application code".
Of course! And for that reason, I reiterate that I give leeway to my definition of "library code" so that it also includes files of the same project. As long as they are imported somehow into the "application code", we may as well consider them to be "library code".
The main thesis of the article is that I have begun to treat the
.jsextension as a deliberate communication of the developer's decision to limit the application code to solely rely on type inference for type safety. In cases where type inference is insufficient, I upgrade the.jsfile into a.tsfile but as a last resort considering the most minimal surface possible.The "developer experience" that this scheme provides (at least in my experience) is that I can tell from the file extension alone which files in the project are "[dumb] application code" (for lack of a better word) and which files are the more interesting and meaty "library code".
Consider the application entry point for example. Seeing a
main.jsfile certainly jumps out more than amain.tsfile in a sea of.tslibrary code, right? Here, I find that the.jsextension now takes on a new meaning: "I am consumer code!"Clearly, you have a well-organized mind that thrives in the details. I think you are like me 7 or so years ago. I think you are over-selling this because there isn't much to sell. I say this with admiration, however. Your train of thought demonstrates cleverness. You just need to apply an extra step: Practicality.
I understand what you say fully, I think. I just see no practical, useful gains in it. To see whether code is "consumer code" or "witty, complex code" by means of a file extension is nowhere in my to-do's.
Thank you! That means a lot to me.
This is totally fair. I must admit that the file extension semantics are quite subtle. It is not immediately apparent why such a mix of
.jsand.tsfiles exist.Nevertheless, I personally find them very helpful when navigating codebases nowadays. Onboarding new developers who use VS Code (for instance) renders file icons according to their file extension. The distinct yellow JS icon versus the blue TS icon is a neat visual signal for possible entry points and consumers (e.g., perhaps UI components?) in the project.
The industry is moving away from that; esbuild → Content Types → TypeScript:
“ …esbuild has built-in support for parsing TypeScript syntax and discarding the type annotations.”.
Type discarding bundlers are used to accelerate the feedback loop that otherwise would be significantly slower if they were limited to using
tsc—especially in large code bases.Relying on TypeScript specific features (e.g. decorators) essentially blocks that build time optimization.
Using non-JavaScript TypeScript features comes with significant tradeoffs. By and large TypeScript is being used as a JavaScript type linter, either with it's own “more convenient” syntax or in combination with JSDoc.
Using TypeScript as a “language” presents it's own risk.
The point being? I could not infer.
I completely agree. However,
tsc !== TypeScript. The compiler of choice is not the language itself. The language still carries many benefits, regardless of the compiler/transpiler of choice. So I guess I continue to miss your point.Regarding build times: Yes, using TypeScript adds a "transpilation/compilation" step to the CI/CD. But how much are we talking about? Does anybody have benchmarks lying around?
… TypeScript is being used as a JavaScript type linter [not as a compile-to-JS language].
I'm not talking about CI/CD. I'm talking about during normal development and/or micro testing; development approximating REPL-driven programming (… a set of tools and practices for programming that emphasize fast and rich feedback). It allows you to bypass many specious TS-errors until you are ready to address them in earnest and run a «full blown» type check, not just stripping the type annotations.
“I often wish I worked in a language where I could start dynamic and end statically”
Ok, I saw the video. OMG. Is people like this now? In the video:
Is C# a linter because it produces MSIL? OMG. Clearly this person and anyone that backs him up has lost the depth in their train of thought. Pretty much the entire video should be deleted.
People reading this: Did you know that before C, languages were untyped? Do you know how types are really used by compilers? My guess is No, you don't know because you keep minimizing the importance of types. I'll leave this as homework assignment to you all, avid followers of the "kill TypeScript because typing is linting" movement.
This already exists and TypeScript does not interfere with it. Literally every
Vite + TS + <Technology>project uses esbuild to provide this experience. Is TypeScript getting in the way of this? How? When? Where? I don't see the relation between TypeScript and the inability to have REPL-like development experiences. It sounds to me that people are thinkingtscto be mandatory when using TypeScript. Is not.The (lack of) type checking speed of
tsc. Nobody uses anything else for type checking as all the alternatives strictly strip but do not type check (and perhaps even transform).As I alluded to before, TypeScript was never about type safety, it's about “somewhat safer types as long as it doesn't cause the developer any additional effort”— i.e. developer convenience first.
It has always been my contention that people who care about types would use something more like ReScript rather than TypeScript and simply accept the burden of managing JS interoperability. TypeScript makes many (permanent) compromises in order to allow progressive adoption on a JS code base and to consume pure-JS libraries.
It's too far gone for that. Again: TypeScript's popularity has nothing to do with types but everything to do with developer convenience via Intellisense. Accepting anything else is just being in denial.
Please read the documentation:
“Note that Vite only performs transpilation on
.tsfiles and does NOT perform type checking. It assumes type checking is taken care of by your IDE and build process.”Vite achieves it's level of experience by bypassing the type checking stage entirely. Most of the time people just fix the issues as they see them in their editor via LSP. Then in CI/CD
tsc -noEmitis used to catch any errors that may have been missed.PS: Deno skips type checking by default as well.
Ok, but this is
tsc, the compiler, notTypeScript, the language.Intellisense is the live reflection of the compiler. Wanting this live reflection is nothing to be ashamed of. To say that you "want Intellisense but not compilation" is impossible, as Intellisense is completely predicated in the compiliation process.
Yes, and there's nothing wrong with that. You, as a developer, should be fully aware of this. You, as a developer, once you are happy with your product, should then kick off the TS compiler to ensure your project is error-free. You, as a developer, should include TS compilation in CI/CD as well. How does any of this preventing REPL-like experiences?? The concept of TS somehow getting in the way simply escapes me. Because most people don't do it properly, then it is TypeScript's fault and must be stopped? Or are people saying that this is "a bad thing" because somehow compilation should be in every single scenario every second of the way or not exist at all? That would also be non-sense to me.
So?
Some would argue that
tscisn't a compiler in the original sense.In the early days of C++, Cfront was identified as a cross-compiler largely because it did not change the granularity/level of it's output―it performed a code transformation but stayed on the same high level of language. Later the term transpiler was coined for transforming-compiler underlining that the transformed output wasn't operating at a finer granularity (e.g. assembler).
Given that it is possible to just strip the TypeScript annotations with minimal transformation, TypeScript is just a
tscsyntax for JavaScript rather than a language. Admittedly TS JSDoc would have been the more authentic solution but that would have never gained any widespread adoption because it would have been too inconvenient for application developers.TypeScript has always been squarely targeted at application developers rather than library authors which always had other ways of providing the “types” to support their users development environment's code completion:
“TypeScript began its life as an attempt to bring traditional object-oriented types to JavaScript so that the programmers at Microsoft could bring traditional object-oriented programs to the web. As it has developed, TypeScript’s type system has evolved to model code written by native JavaScripters. The resulting system is powerful, interesting and messy.”
This is the step that is considered "type linting" (aka static type analysis/checking).
It emphasizes how TypeScript is just lipstick on JavaScript.
This is so harsh! Made me laugh. 😄
Ok, so this feud is making my head spin. On one side, there is people saying TypeScript should not exist. On the other, there's people like me saying TypeScript provides value. The main issue is that people whine about their source code being more difficult to maintain for something that gives them nothing. Am I correct so far? If yes, these people say that, because of its alleged zero value it should not exist. This is the overall view.
Now, especifically:
I think we can agree that #2 is false. Let's see about #1.
One of the things that I like the most of TypeScript because I can state the data types, is catching missing logic. A very simplified example:
Because I can specify the data types, both Intellisense and the transpilation step (
tsc) will tell me that I forgot the fact thatvaluecould beundefined.This makes me correct my code to:
Do linters do this? Is this kind of feature available in eslint? Or is it something that only TypeScript can do?
I don't see how. Starting with TypeScript the REPL-like experience can only be realized by using a type stripper. There is no
--transpileOnlyflag intscso the type checking (executing in a JS runtime) bogs the feedback cycle down. The only other way to bypasstscis to write plain JavaScript an annotate it with TS types inside JSDoc annotations.Aside:
Nobody is going to argue that React isn't “popular” (whatever else one might think of it). React isn't developed with TypeScript. The DefinitelyTyped types are maintained by the React team but React itself is typed with Flow. AFAIK Flow was developed with OCaml which is fairly popular with compiler writers because it's binary execution speeds are "close to a compiler written in plain C". It stands to reason that Flow never had the
tscspeed issues so it never slowed the React team's development flow.Many people prefer Flow over TypeScript however Flow never caught on, perhaps because MS Windows wasn't supported until late 2016 by which time DefinitelyTyped was already firmly established and now the Angular 2 release further increased general interest in TypeScript.
In some ways one could say that TypeScript is more a product of a "productivity culture" while Flow seems to lean more towards the outcome of an "engineering culture" (though I would classify React itself as a product designed for a "productivity culture").
People value TypeScript for the developer convenience it provides in their development environment, primarily VSCode (or any other LSP supporting environment).
People valuing reliable static type analysis have to look elsewhere.
Library authors requiring strict control over the runtime JavaScript code (for whatever reason) elect to use TS JSDoc primarily to deliver consistent TypeScript types for their users, with the side benefit of (only) on demand
tscstatic type analysis.Linters in the original sense no.
But in the web dev world the concept of static analysis tools for dynamic languages was virtually unheard of (example Erlang: dialyzer; Elixir: dialyxir).
Flow had the right idea: be a static analysis tool that supports an inline type syntax and be fast enough to never get in the way.
TypeScript started with ambitions to be a language but the enum fiasco just drives the home the point that deviating from the JavaScript baseline only comes back to haunt (and hurt) TypeScript.
So in the web dev world static analysis tools were explained as "type linters".
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.
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.
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:
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
tscfrom Microsoft.tscis 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, thattsc !== 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.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 playground
tsc• variable declaration space
• type declaration space
Fixed:
Which just emphasizes again that TypeScript adoption/popularity is primarily about developer convenience rather than safe types.
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.
tscor LSP parse the type syntax inside the JSDoc annotation to fill in the "type space gaps" in the JavaScript code.tscor LSP determine whether the code type checks.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.