I completely agree with the sentiment that typed libraries are more stable and self-documenting. You can autogenerate documentation from typescript and it's guaranteed to be up to date, unlike JSDoc comments.
I personally have converted a few of my libraries [1] [2] over to Flow. It helps me personally, catches a lot of bugs, and does a great job of self-documenting while not getting in the way.
Flow has a lot of bugs and a lot of growth ahead of it, but it is far easier to get started with than TS. I highly recommend it.
I was kind of frustrated for a while with the broken type system of Javascript, as well as with the lack of easy type checking. I then wrote a simple small library to make my life a little easier. It's called types.js, in NPM as well.. Changing my entire code to TypeScript just feels a bit over the top to achieve only static type checking. I now only dynamically check if needed. I believe there are so much worse and…
Try Flow, if you haven't yet. It's not as complete as TS, but it gets out of your way and requires minimal investment. I find that the `(foo: string, bar: number)` annotation style is just far more readable than e.g. JSDoc. You don't even really need to be running Flow (babel will strip them), but it's practically free - why not.
Is this like saying that JS is the moral equivalent of assembly language for the web platform, and high-level development on the web platform should be done using something like GWT and/or GXT?
from what I've tasted of typescript build times
I hold with those who favor javascript
But then I've seen enough of bugs
To think that for frontend dev work typescript
is also great
and would suffice
This reads like knee-jerk reaction from someone who's never tried TypeScript.
Criticism of that statement kind of hinges on the source material being solid enough to be taken seriously. I mean, one of his main points is that everything written in JS should be written in typescript because it helps support typescript users. Another it is leads to better documentation, with no qualification of how that happens. It might make your intent more explicit to a reader of the source code, but that does…
> I mean, one of his main points is that everything written in JS should be written in typescript because it helps support typescript users.
I agree, that wasn't a good point.
> Another it is leads to better documentation, with no qualification of how that happens
The type annotations make the source self documenting in a way that doesn't go out of sync. There's also http://typedoc.io/
Absolutely not. This is the opposite of what you should do in my opinion. If you're writing an API to be consumed in language X then you need to write the API itself in language X. This will help you capture and handle edge cases, language idiosyncrasies and other similar issues the way you want. Using a different language that gets transpiled into a target language also increases your surface area for bugs because n…
This reads like knee-jerk reaction from someone who's never tried TypeScript.
I've used it but never in a serious project. Like I said when it can be compiled into WebAssembly then count me in I'll certainly give it another shot. But until then I just don't want to deal with an, albiet probably rare but possible, transpiling bug. Plus there is huge value, in my opinion, in writing an API in the same language it's going to be consumed in. It lets me dogfood more effectively and write better, real world unit tests.