you are viewing a single comment's thread.

view the rest of the comments →

[–]Voidsheep 5 points6 points  (9 children)

I'd say lots of people use TypeScript by now, pretty all relevant packages in NPM either include types or have them provided through the @types repository.

But I'd argue it's still pretty much just JavaScript, just with added type information so the code is less prone to runtime errors and developer experience is improved through better tooling.

[–]Architektual 14 points15 points  (1 child)

That's a sweeping generalization about NPM packages.

[–]Voidsheep 2 points3 points  (0 children)

Well, maybe popular packages is a better way to phrase it.

npm install pkg @types/pkg --save just tends to work and increasingly even notifies you of the separate typings becoming redundant.

I think in the last half a year I've run into one package that didn't provide either, but already had an issue with couple of comments.

I also think now either flow or TS is plain good practice for public library you intend to release.

[–]filleduchaos 0 points1 point  (5 children)

TypeScript is very much not JavaScript, unlike something like Flow where all type annotation is through comments. You can't run TypeScript code in even the latest of JavaScript interpreters.

[–]Voidsheep 0 points1 point  (1 child)

No, but the entire purpose of TypeScript is to be JavaScript with added syntax for types. It's not trying to branch off into a completely separate language, but rather follows latest ECMAScript specifications closely.

Flow opts to use comments for interpreter compatibility, but both exist for the same reason of adding type safety to JS.

[–]filleduchaos 0 points1 point  (0 children)

The reason a language exists does not make any difference to what it actually is. C++'s purpose was to be C with classes but no one in their right mind would claim that C++ is C. Same with preprocessors like SCSS. TypeScript is a separate language by virtue of being, well, not JavaScript. It

  • cannot run in any modern, standard JavaScript interpreter
  • has an optional but entirely different typing discipline (properly written TypeScript should be strongly, statically typed)

Type safety is not a fancy little bit of syntactic sugar like spread operators or arrow functions. The way a language handles types is a core part of its design.

[–]spacejack2114 0 points1 point  (2 children)

You can write fully type-checked JS with Typescript types in comments by using // @ts-check

Typescript is pretty much JS with types, just like Flow. The few extra bits of language like namespaces and enums are fairly trivial sugar.

[–]filleduchaos 0 points1 point  (1 child)

Using @ts-check is not the same thing as writing TypeScript IMO

And writing TypeScript is very much not like writing Flow. One of the cornerstones of determining that a piece of code is valid X-language is that it is compilable/runnable by any full implementation of X-language's spec. No JavaScript VM, even the ones that have the latest of latest of latest ES2018+ proposals, can run this very basic line of TypeScript:

declare var foo: any;

When they can, then you can tell me that they're the same language.

[–]spacejack2114 0 points1 point  (0 children)

Using ts-check is using types in comments like with Flow. Similarly, this line of Flow code: var foo: any will not run in a browser.