I really can’t stand the appeal. It’s so much more verbose and clunky than Typescript. I want to understand why people choose it but I can’t justify using a worse, more verbose, less readable, and less powerful version of Typescript when I can just change a j to a t and have the real deal.
Not that I've implied it is better or worse or demanded subjective opinions about that, but when we are at it, here are some remarks:
1. No build step is an appealing feature for some.
Knowing that what is shipped is what you wrote, not what some transpiler spat out, might have some value.
2. Syntax is also subject of personal preference.
Anecdotally, I personally pretty much prefer having "non-executive content" swept aside the "executive" parts, not mixed together in single expression (when applicable).
I assume it is matter of habit, but even though I use both TS and JS, to this days, over TS
function uppercase (something: string): string {
return something.toUpperCase()
}
I'd really rather prefer seeing the "fluff" (types and comments) separated from the "meat" (actual code): in JS (JSDoc)
/**
* @param {string} something - glyphs presumably not (only) from upper case
* @returns {string} all glyphs from upper case, when applicable
*/
function uppercase (something) {
return something.toUpperCase()
}
since I still keep mentally stumbling over those :fluffy chunks in TS. Again, probably mater of habit really.
> Knowing that what is shipped is what you wrote, not what some transpiler spat out, might have some value.
There aren't that many TS features that actually require transpiling unless you want to write bleeding edge JS, and that's still a factor without typescript.
> No build step is an appealing feature for some.
ts-node exists
My question is how do you reuse and test the JS doc signatures? Can I export comments? Will my tests fail if the types mismatch?
I'm working on a JS project for a client. I can't modify the deployment procedure so I can't add a build step and ts-node is no help because it's frontend.
JSDoc comments can be checked with TSC and I get squiggly lines in VSCode. It's a major step in the right direction. Obviously tests work the same they always did, there is no runtime type checking just as there isn't in TS.
A recent example is a Chrome extension I wrote for the sake of proving out a feature.
Totally not interested in setting up a build system, dealing with dependencies, type safety, and so forth. I just want to write code and immediately see it run. Having JSDoc is nice to document more than just types, but type hints can be helpful.
> My question is how do you reuse and test the JS doc signatures? Can I export comments? Will my tests fail if the types mismatch?
You can still use `tsc` to validate the jsdoc types. It will spit out errors when types don’t match.
You can use `tsc` to export the types defined in jsdoc and other projects that import your module will get all the intellisense and type checking as if it had been written in TypeScript.
I won’t speak for others, but I for one can’t stand the amount of extra packages needed to get a TypeScript project working. I need to install adapters for my linter, formatter, test runner, editor, bundler to name a few. Hopefully it all works together with all the other plugins and adapters. With the jsdoc version, I just install the `typescript` package, and I can use that to do the typechecking as well export types to be used by a TypeScript project. Sure it’s a bit more verbose, but I’d take that over tinkering with dependencies and configurations.
That's the point. Suggested setup (editor with JS/TS language server constantly checking your code) means you will know about every problem that would possibly break something, you just don't need separate "source code" producing "build package". It means you can ship your code directly to target platform that only understands JavaScript.
AFAIK that's not what you currently can do with TypeScript (except Deno).
