Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flow vs. Typescript

djcordhose.github.io

Post reply on HN
Print view View original

151–158 of 158 posts

Re: Flow vs. Typescript

#151

Post by CuriousSkeptic »

lobo_tuerto wrote: post #115
CuriousSkeptic wrote: post #114

One aspect to consider before jumping into TS or Flow. As is the nature of any type system they rule out some programs that are perfectly fine. A workaround for this is to infer, or explicitly annotate, things to be dynamically typed. And/or helping the typer by casting to known types it failed to recognize. And it will work fine, after all this is precisely what you do with untyped ES (in your head). This workaround…

Do you have a specific (and simple, if possible) example at hand?

Redux perhaps. Spent some time inventing a way to pass event types to reducers.

Turns out I reinvented redux-act in the end ;)

Re: Flow vs. Typescript

#152

Post by DJCordhose »

shados wrote: post #98
s_kilk wrote: post #84

Earlier quoted context omitted.

> since introducing TS to you project means longer time train new employees Does it though? I mean, we're talking about intelligent beings who can drive cars and program computers, how hard can it be for them to spend an hour reading the typescript docs? I suppose it depends on ones definition of a long time.

Learning TS itself takes minutes. Probably -seconds- if you're familiar with Java/C#. The real learning curve is in the edge cases, of which there are plenty. Fighting with a 3rd party lib with incorrect type defs, dealing with cases common to JS that are hard to properly type (such as certain functional constructs), dealing with things missing from the TS compiler that are present in ES6/babel, etc. Those things are…

IMHO the type system of flow and typescript are pretty different from Java/C#. Structural typing to name one and maybe the most important.

Re: Flow vs. Typescript

#155

Post by joshuacc »

Arnavion wrote: post #128
joshuacc wrote: post #102

Earlier quoted context omitted.

That's not entirely accurate. TypeScript 1.8 added the ability to use type information from JSDoc-style comments. For example: /** * @param {string} a * @param {number} b * @returns {string} */ function foo(a, b){ return a + b; } Is functionally identical to: function foo(a: string, b: number): string { return a + b; } See: https://github.com/Microsoft/TypeScript/issues/4790

Not equivalent - the TS compiler currently does not actually enforce the types in a JS file. See https://github.com/Microsoft/TypeScript/issues/4790#issuecom... The feature of parsing JSDoc comments is currently only used for providing completion info for JS editors and for consuming exported JS functions and variables in TS files.

Ah, you're right. Looks like I'd misunderstood the scope of that change.

Re: Flow vs. Typescript

#156

Post by shados »

DJCordhose wrote: post #152
shados wrote: post #98

Earlier quoted context omitted.

Learning TS itself takes minutes. Probably -seconds- if you're familiar with Java/C#. The real learning curve is in the edge cases, of which there are plenty. Fighting with a 3rd party lib with incorrect type defs, dealing with cases common to JS that are hard to properly type (such as certain functional constructs), dealing with things missing from the TS compiler that are present in ES6/babel, etc. Those things are…

IMHO the type system of flow and typescript are pretty different from Java/C#. Structural typing to name one and maybe the most important.

they're very different if you take them in a vacuum, but they're nearly clones when compared to ML/Haskell/Scala-style type systems.

Don't forget C# has some structural typing for some features (such as delegates)

Re: Flow vs. Typescript

#157

Post by knocte »

jeswin wrote: post #68
knocte wrote: post #33

Earlier quoted context omitted.

Right, that check-list is actually useful in any dynamically-VS-statically typed decision scenario.

IMO, that list is specific to JS because JS now gives you the ability to optionally add types. Otherwise, there are good arguments to be made for dynamically typed languages and statically typed languages. That is, I have seen a proportionally similar number of maintainable Python projects as Java.

If you bring up Java when you talk about statically typed languages, let me be sneaky as well and mention PHP as a dynamically typed language. (What I mean: both are shit and are not worth mentioning.)

Re: Flow vs. Typescript

#158

Post by natmaster »

gear54rus wrote: post #10

So today is typed JS day? https://i.imgur.com/XAEeEFm.png Guess it's time for the question then... I haven't dived into this whole types thing yet so could someone provide a TLDR about either Flow or TS being opinionated and their impact on an established toolchain? I have no intention of changing half of my tooling just to be compatible with what fb thought would be a good idea, and even less so for ms. A build step…

Flow is not a superset of any form of javascript. It is another language.

See: https://github.com/facebook/flow/issues/825

Post reply on HN