Feels like Typescript is building (or has built up?) more momentum than Flow.
I see 2 main reasons:
- TS has been released before Flow
- TS has the support of the Angular community
Announcing TypeScript 2.1
71–80 of 226 posts
Re: Announcing TypeScript 2.1
#72Question:
Is it possible to have a setup with TypeScript where it is guaranteed that no code changes occur other than removal of the type information?
I started using Flow, found what it can and can't do and would like to try TypeScript. But only if I can have "types-only", I don't want my code "translated" in any way. I'm writing for the latest node.js version and not for x different browsers, I want to use exactly what that version supports and have no code-changing steps.
With Flow I use flow-remove-types (https://github.com/leebyron/flow-remove-types) to remove the types. It leaves spaces where there was type-related code and doesn't touch the code itself.
Re: Announcing TypeScript 2.1
#73If you still haven't given TypeScript a go as a Javascripter, now is a great time to do so. Whether you end up adopting it or not, it's interesting to get the types out of your mind and into the code. The first time you feel the speed/confidence of refactoring with accurate 'Find usages', you'll decide if the undeniable overhead of types is worth it.
Can anyone weigh in on TypeScript vs Elm?
TypeScript has an easier learning curve (for people with a JS background) and it's really popular.
Elm is sometimes on the frontpage of HN but let's be honest, it's not really used.
Re: Announcing TypeScript 2.1
#74Anyone knows any good resources to learn typescript? The tutorials on the official site are really... bad. Like I would not even call them tutorials.
Re: Announcing TypeScript 2.1
#75Earlier quoted context omitted.
I have to second Mr.timruffles. After using TS in a couple of projects I grew to miss it when I couldn't use it. If you don't like the C#-ness of Typescript, try using Facebook's flow. Typing isn't a magic bullet, typescript isn't even type safe, but it sure makes development easier and your apps more stable.
"Typing isn't a magic bullet, ..., but it sure makes development easier and your apps more stable." That right there is the whole essence of typed programming :)
Going one level deeper, the underlying truism is that computers make better bean counters than people, even programmers. Type systems are good insofar as they free up cognitive resources of the programmer. Conversely, type systems are bad when they make programmers burn attention resources without enough return. (This is a difficult thing for people to evaluate, because sometimes the "return" from a type system can pay off many years later.)
Again, it all comes down to cost-benefit. A new, modern 21st century language should be designed with the above in mind. The type system should make the resulting apps more stable, stay out of the way of coders reading code and writing new code, yet enable powerful tooling that doesn't need a heavyweight background process running a O(n^4) algorithm to collate meta-level information to enable all the IDE features. (Ideally, the tooling should be able to parse everything it needs to parse at some small multiple of the time it takes to read the source files off the drive.)
Again, it's all about cost-benefit! "Elegance" or popularity with tech hipsters be damned, what's the cost, and what does it get you? (The nickel-and-dime costs of waiting around for lugubrious and unresponsive tools not only add up, they operate with some huge multiplier effect.)
Re: Announcing TypeScript 2.1
#76It's interesting to me that all of the initial reactions I've seen to this announcement have been around the introduction of async and object spread, which are available with babel, but the typescript specific features such as mapped types are completely ignored. I don't really have any particular meaning behind that observation, only that it tickled my funny bone a little bit.
Maybe it is me, but I feel like mapped types and keyof are terrible features, and using them would be a sign of a bad design/architecture. In general, I don't think using a string that represents a static symbol (such as the name of a var, an attribute or a class) is a good idea. I try to keep a simple stack (Typescript + NPM at the moment), and I prefer to wait for Typescript to have the feature I want, than to inst…
I assume you mean lookup types rather than mapped types; the latter has nothing to do with strings.
In general, in application-facing code I think you're absolutely correct: using strings as lookups is a hack that should be discouraged. (Though sometimes it's convenient when dealing with other JS libraries).
However the feature brings some strong metaprogramming abilities that wouldn't be possible otherwise. For instance I'd have to imagine that mapped types were implemented by using those features, and the ability to define types as variants of other types (beyond ordinary generics) is something very powerful.
I'm primarily an F# user and have been begging for something like this there. The ability to define variations on record types (without and id/timestamp for inserts, with those fields otherwise; hashed/raw password fields for your various user records; etc) in a typesafe manner without a ton of repetition is a game changer.
Re: Announcing TypeScript 2.1
#77Question: Is it possible to have a setup with TypeScript where it is guaranteed that no code changes occur other than removal of the type information? I started using Flow, found what it can and can't do and would like to try TypeScript. But only if I can have "types-only", I don't want my code "translated" in any way. I'm writing for the latest node.js version and not for x different browsers, I want to use exactly…
TypeScript seems to have been very religious about following "Bracha's law" (types shouldn't effect program semantics), and I'm unaware of any translations they do beyond supporting some new features on previous platforms (e.g. classes on pre-es6).
It is kind of annoying sometimes actually, in that typescript can't support niceties like operator overloading or extension methods because that would require de-sugaring.
Re: Announcing TypeScript 2.1
#78If you still haven't given TypeScript a go as a Javascripter, now is a great time to do so. Whether you end up adopting it or not, it's interesting to get the types out of your mind and into the code. The first time you feel the speed/confidence of refactoring with accurate 'Find usages', you'll decide if the undeniable overhead of types is worth it.
> The first time you feel the speed/confidence of refactoring with accurate 'Find usages', you'll decide if the undeniable overhead of types is worth it. For your information: in VSCode, the "Find all references" and "Rename symbol" work out-of-the-box, even if your code isn't typed. Edit and disclaimer: Not sure why I'm getting downvoted, my comment doesn't contradict parent message. I personally type my code too (w…
VSCode, the "Find all references" and "Rename symbol" work out-of-the-box, even if your code isn't typed.
With good coding practice, references, "senders" and "implementers," and renaming worked well in Smalltalk. Where I missed types was during refactoring, and that also worked well about 99% of the time without types. It was that one last thing that we couldn't be 100% sure of that blocked the big refactoring we all wanted to do badly -- that's when I missed types!
Re: Announcing TypeScript 2.1
#79Question: Is it possible to have a setup with TypeScript where it is guaranteed that no code changes occur other than removal of the type information? I started using Flow, found what it can and can't do and would like to try TypeScript. But only if I can have "types-only", I don't want my code "translated" in any way. I'm writing for the latest node.js version and not for x different browsers, I want to use exactly…
TypeScript and Flow have the same behavior with regard to removing types, and TypeScript and Babel have the same behavior with regard to downleveling ES6+ code to ES5-
If you target ES6 with TypeScript and only write ES6-compliant code (plus types), you won't get any downleveling of features, so your code will always be the same as you wrote it (other than the removal of types).
If you use TS-specific features like 'enum' or 'namespace', there will necessarily be some rewriting of your code to turn it into usable JS, but those features are entirely optional.
Re: Announcing TypeScript 2.1
#80Question: Is it possible to have a setup with TypeScript where it is guaranteed that no code changes occur other than removal of the type information? I started using Flow, found what it can and can't do and would like to try TypeScript. But only if I can have "types-only", I don't want my code "translated" in any way. I'm writing for the latest node.js version and not for x different browsers, I want to use exactly…
With flow you can do one better: type comments! https://flowtype.org/blog/2015/02/20/Flow-Comments.html
You actually wrap the type annotations in comments and flow will recognize them. You can use the source with the type comments in your browser!
As an example, the flow checker will read the annotations from `function f(n/:number/, s/:string/) { ... }` but since they are commented in the source code your JS engine ignores them.
This is amazing for typing existing code, since at every step you are merely inserting comments into your code. And your existing minification step will strip them out :)