Jsdoc Cheatsheet
devhints.io
devhints.io
https://www.typescriptlang.org/docs/handbook/jsdoc-supported...
So they've already paid the cost of a strongly typed language without any of the benefits.
And when type validations are missing their issue tracker is full of type mismatch related bugs.
The lazy works twice. Just use types, the computer is better at comparing large amounts of strings than humans.
strict typing is great, but the rest of TS features are just trying to put Java into Javascript, empowering people to turn 100 LOC worth of functionality into 1000 LOC of cruft
- writing unit tests that will likely be not exhaustive
- refactoring your unit tests constantly each time you change something
- do all that without the assistance of a compiler telling you what broke
- having to read code to infer types by hand
All all of that for what? so that your code still breaks.
Comparing strings by hand is certainly the best use of human time. If we only had machines capable of doing that.
> My velocity is so high! Look at all those "type mismatch" Jira tickets I've closed in the last month! I am a 10xer. I've multiplied my work 10x!
- Average TypeScript hater testimonial
Never have any of the issues you mention and even better, never have to deal with the fucking Typescript compiler...
There are no other features of TS that aren't static typing. It is only static typing. (OK, I suppose you could make an argument for enums, but it's still 99%.)
Like... Half the original point of TS was to add features to JS that weren't there originally.
Granted, as the base language evolved the gap has become smaller, but it's still there.
Interfaces being one such example.
There's also things you can do in JS that TS will bitch about. For example, try using object destructuring in a class constructor to create optional named parameters for a class.
Works perfectly in Vanilla JS, but TS will throw a hissy-fit.
He (or she) is totally serious and I agree.
Here is what I wrote here in some discussion a few days ago: https://news.ycombinator.com/item?id=34454774
-----
TypeScript isn't another language though. It is the latest official ECMAScript plus type annotations. Only some very, very few, rare, old stuff like enums really is different code. 99% of TypeScript is just "remove the types to get ECMAScript".
That TypeScript, the tool,also adds a transpiler is a distraction that made a lot of people believe TS is a different language. But the TS folks have always taken great pain to only ever support features that are or are about to be in the ECMAScript standard, and not to deviate from it. That they did initially with some namespace stuff and enums was before ES2015, when JS was lacking some things many people thought were essential. Even then they only added less than a handful of "TypeScript-code".
When you look at the Babel "transpiler" for Typescript, before they added a bit more for class stuff, it pretty much showed that "transpilation" of TS to JS - as long as you targeted a recent ES version - was achieved by doing nothing more than to remove all those type annotations.
I'm still mad at the TS guiys for muddying the waters so much by confusing soooo many people by bundling type checking and transpilation in one tool. This could have been much more clear. I too stuck to using Flow for quite some time until I realized TypeScript really is Javascript, while Flow communicated in its architecture and usage already that it just "added types" (literally).
------
Actually changing the nature of Javascript, and quite radically too, were those who wrote the newer spec themselves - introducing more and more "class" things.
> Interfaces being one such example.
They are not part of the JS code produced, they are simply type annotations. They don't change the actual JS code at all.
Being fine with JSDoc but not with TS types is strange to me, there is no difference as far as the JS code outcome is concerned unless you - needlessly! - use the very few, mostly legacy (made obsolete by ES2015+), things in TS that actually end up as JS.
Just treat the TS types exactly the same as the JSDoc: It's just comments, it's not part of the code! Get it removed by Babel or tsc just like you could remove (as packers will do) the JSDoc comments for a production build.
I once started with Flow (the other JS type checker), experimented with JSDoc+Webstorm as praised here, and very quickly found an actual type checker and full type annotations are far superior.
Maintenance and team work, especially when people change what projects they are working on, and even more when you have (your own) libraries that other teams use to build something atop of, then string types are a godsend IMO. And why would I go for the far inferior JSDoc "solution"?
I too am VERY keen on using ECMAScript. If TypeScript really messed with the underlying code I would not have chosen it. I simply avoid enums and the other stuff is not even on the radar any more, nobody needs to use the namespacing hacks any more that TS once introduced because prior to ES2015 JS was severely lacking.
What?
You mean like this?
class Foo {
constructor({opt1, opt2, opt3}: {opt1: string, opt2?: number, opt3?: Object}) {
}
}
Also, I don't know what exactly you're describing, but objects as optional named parameters are a common technique in Javascript and therefore very well sorted in Typescript. I'm on my phone so this might not work brilliantly, but something like this:
// This could also be an interface... ;)
type Params = {
// These keys are optional
// (Note the question mark)
height?: number | string
width?: number | string
}
class Rectangle {
constructor({height, width}: Params = {}) {
console.log(height, width);
}
}
I can definitely empathise with the idea that some Typescript developers just use it as an opportunity to write Javascript-flavoured Java, but this is mostly a stylistic choice (and completely possible in raw Javascript too). But Typescript is very explicitly designed you match the usage patterns of Javascript directly - i.e. if your Javascript code runs (and makes sense), you should be able to write an identical version in Typescript and have it be accepted by the type checker. Obviously that's never going to be entirely the case, but I really find I have many issues porting idiomatic Javascript too Typescript - and where I do, it's usually because the Javascript was wrong in the first place.
* That's not actually entirely true, I forgot about field declarations in constructors, but I don't think I've ever seen that used in the wild outside of very old Angular codebases.
There are a few others, mostly discouraged these days (namespace and module runtime keywords come to mind). Mostly they’ve treated these as legacy mistakes (good!), but they introduced a new one recently that baffles me given that posture: `accessor` as a shorthand for getter/setter pairs, with no clear authoring benefit for working with the underlying private value.
(name: string, age: number) => ({ name, age: age * 2 })
{ name: "Bill", age: 62 }
Also, what do you mean by the accessor shorthand? I don't know what you mean off the top of my head, and searching for it has just brought me back to this post!
Accessors: https://devblogs.microsoft.com/typescript/announcing-typescr...
I hadn't noticed the accessors thing before, but it looks like that's an ECMAScript/TC39 thing, I guess to support the decorator implementation. Thanks for the link!
> Half the original point of TS was to add features to JS that weren't there originally
That’s simply not true. The TS website says “typescript becomes JavaScript via the delete key” along with many other statements that directly contradict this.
Our current project has Java in the backend written in Java and Java in the frontend written in Typescript. So many layers of abstractions for submitting forms.
Not sure what features those are, but TypeScript still has first-class functions, higher-order functions, and algebraic data types. Those are all excellent tools for not writing Java. If people are writing Java code in TypeScript, they're missing out on all the features and power available to them that aren't in Java.
I agree. The amount of JS code we have for just dealing with type mismatches is absurd.
You get 99% of the benefit, with no bitchy Typescript compiler to deal with.
Again, maybe just me. But, my brain doesn't parse them unless the code is already extremely well structured. In which case, why include annotations at all? Or in other words, isn't it always better just to improve the readability of the function itself?
Documentation tags have a machine readable structure.
That structure can be parsed and used for documents, editor hints, diagrams, and even type check validations.
Instead of having to traverse the entire callgraph of a function to have an idea of what guarantees it provides, you simply read the documentation tag.
This is O(1) instead of O(V+E) where V are the functions and E are how you call them.
> Instead of having to traverse the entire callgraph of a function to have an idea of what guarantees it provides, you simply read the documentation tag.
> This is O(1) instead of O(V+E) where V are the functions and E are how you call them.
Unless of course it is wrong, because it is just a convention for a comment and not actually an enforced type.
The wrong direction is: less information, no stable contracts, forcing people to guess, complete chaos and anarchy, make up your own format with your own tags that nobody supports.
My comparison was between:
- JavaScript with no documentation tags
- JavaScript with non-machine readable documentation
- JavaScript with documentation tags
They are (mostly) not for you.
They are for the tooling, including your editor, to detect that your declared foo(bar: string) but you're calling it as foo(5).
The value of JSDoc is the same as value of TypeScript: add static types to your code to detect bugs.
And yes, it works in practice.
I started using JSDoc quite recently.
I don't enjoy adding those type annotation comments but undeniably they (and VS Code tooling, jsconfig.json) detect errors that, if not fixed, would end up blowing up at runtime and causing me to spend more time fixing them.