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

61–70 of 158 posts

Re: Flow vs. Typescript

#61

Post by bsimpson »

msoad wrote: post #22

Both differences in this presentation are addressed in TypeScript 2.0 https://github.com/Microsoft/TypeScript/wiki/Roadmap#20

I talked with Lee Byron about the differences and if there's hope for convergence at React Europe. He said:

- the biggest difference is nullability (you have to explicitly set TypeScript to treat all types as non-nullable by default to get behavior similar to Flow's default).

- Flow uses nominal typing (similar to functional languages); whereas, TypeScript uses structural typing (similar to Java). To be honest, I don't remember the ramifications of this, but I think one was it makes Flow easier to work with/require less boilerplate. If you set types on your exports, Flow can infer the stuff in the middle. Flow is also compatible with prototype chains; whereas, TypeScript only knows about ES2015 classes (unless you declare types separately in t.ds files).

- Because TypeScript is a compiler, they can define their own syntax. Flow, on the other hand, tries to be compatible with pure JavaScript. (You can define Flow annotations in comments to avoid needing a tool like Babel.) This means the syntax for certain operations is a bit more verbose in Flow: I think the nullable operator was one case, where the operator Microsoft chose could be ambiguous with JavaScript code in Flow, so Facebook chose a different one.

In short, there are inherent architectural differences that make the two incompatible - there can be edge cases that make a file that works in one not work in the other. The two teams share notes and try to avoid divergence when possible, but as the slideshow shows, the projects have different aims, which can yield conflicting decisions. If Microsoft adds support for the Flow nullability operator, there ought to be a large subset of shared syntax between the two, where files that work in one should work in the other, if you set TypeScript to use Flow's defaults and don't rely on nominal typing.

These are all notes off the top of my head from last week. I haven't used either tool yet. Please feel free to correct any mischaracterizations.

Re: Flow vs. Typescript

#62

Post by imtringued »

k__ wrote: post #58
inaseer wrote: post #46

Earlier quoted context omitted.

Types are invaluable when refactoring your code. I have found Typescript to be invaluable when doing exploratory programming as it allows me to refactor heavily as I learn more about the structure of the problem. The compiler points all the affected code sites and I have reasonable confidence in the correctness of the code after the refactor.

Most static type systems really suck and I can fully understand why dynamic-coders don't like them. It often feels like they are holding you back more than they help. I also got such a moment with TypeScript. const a = A() a.b = new SubtypeOfB() a.b.attributeOfSubtypeOfB = 123 //error Because a.b is type B and not SubtypeOfB and so doesn't have the attribute of SubtypeOfB, but a.b gets its typing from A, which can't…

I would recommend you to always do the initialisation through the constructor and preferably make the entire class immutable if you can.

Re: Flow vs. Typescript

#63

Post by benjoffe »

k__ wrote: post #58
inaseer wrote: post #46

Earlier quoted context omitted.

Types are invaluable when refactoring your code. I have found Typescript to be invaluable when doing exploratory programming as it allows me to refactor heavily as I learn more about the structure of the problem. The compiler points all the affected code sites and I have reasonable confidence in the correctness of the code after the refactor.

Most static type systems really suck and I can fully understand why dynamic-coders don't like them. It often feels like they are holding you back more than they help. I also got such a moment with TypeScript. const a = A() a.b = new SubtypeOfB() a.b.attributeOfSubtypeOfB = 123 //error Because a.b is type B and not SubtypeOfB and so doesn't have the attribute of SubtypeOfB, but a.b gets its typing from A, which can't…

You can also use 'type assertions' to minimise restructuring, eg, the following is the same number of lines as your first example (and compiles to identical code):

    const a = A()
    a.b = new SubtypeOfB()
    ( a.b).attributeOfSubtypeOfB = 123 //works

Re: Flow vs. Typescript

#64

Post by [deleted] »

chvid wrote: post #57
cgag wrote: post #53

Earlier quoted context omitted.

Yeah, but when you have static typing, you can't avoid well-defined interfaces.

Let's pick an example: function renderMarkdownToHtml(text) And with static types: function renderMarkdownToHtml(text : String) : String Well-defined interfaces is mostly not about types.

[deleted]

Re: Flow vs. Typescript

#65

Post by itsyogesh »

bsimpson wrote: post #61
msoad wrote: post #22

Both differences in this presentation are addressed in TypeScript 2.0 https://github.com/Microsoft/TypeScript/wiki/Roadmap#20

I talked with Lee Byron about the differences and if there's hope for convergence at React Europe. He said: - the biggest difference is nullability (you have to explicitly set TypeScript to treat all types as non-nullable by default to get behavior similar to Flow's default). - Flow uses nominal typing (similar to functional languages); whereas, TypeScript uses structural typing (similar to Java). To be honest, I don…

I know I sound a little ignorant, but could you elaborate a little on nullability. I mean is it the same as checking whether an assignment is null or not?

P.S. I haven't used either typescript or flow.

Re: Flow vs. Typescript

#66

Post by chii »

chvid wrote: post #57
cgag wrote: post #53

Earlier quoted context omitted.

Yeah, but when you have static typing, you can't avoid well-defined interfaces.

Let's pick an example: function renderMarkdownToHtml(text) And with static types: function renderMarkdownToHtml(text : String) : String Well-defined interfaces is mostly not about types.

does renderMarkdownToHtml return a string or does it return a DOM element?

Re: Flow vs. Typescript

#67

Post by k__ »

imtringued wrote: post #62
k__ wrote: post #58

Earlier quoted context omitted.

Most static type systems really suck and I can fully understand why dynamic-coders don't like them. It often feels like they are holding you back more than they help. I also got such a moment with TypeScript. const a = A() a.b = new SubtypeOfB() a.b.attributeOfSubtypeOfB = 123 //error Because a.b is type B and not SubtypeOfB and so doesn't have the attribute of SubtypeOfB, but a.b gets its typing from A, which can't…

I would recommend you to always do the initialisation through the constructor and preferably make the entire class immutable if you can.

That's the problem, it is a 3rd party lib.

My own code doesn't give me typing headaches most of the time, but such things.

Re: Flow vs. Typescript

#68

Post by jeswin »

knocte wrote: post #33
greenspot wrote: post #29

I like very much the last slide and the author's recommendation. Helpful and better than the admonitory 'yes you should use typed JS': - if your project does not live for long: no - if your project is really simple: no - if there is a chance you will need to refactor the thing: yes - if your system is very important or even crucial for the success of your company: yes - if people enter or leave your team frequently:…

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.

Re: Flow vs. Typescript

#69

Post by chvid »

glibgil wrote: post #60
chvid wrote: post #57

Earlier quoted context omitted.

Let's pick an example: function renderMarkdownToHtml(text) And with static types: function renderMarkdownToHtml(text : String) : String Well-defined interfaces is mostly not about types.

When you want function render(markdown : Markdown) : Html then you will see the reason for types (and lots of them)

Yep.

And there you have it.

Two different approaches to buidling software.

Which is more productive, which yields higher quality?

I have build plenty of software both ways. And my answer is a confident "it depends". But I will tell you this: A fine-grained type hierarchy over either Markdown or HTML opens up a very big can of worms.

All this reminds me of SOAP vs. HTTP/JSON: I have seen plenty of SOAP webservices seriously stuffed up regardless of/because of strong typing whereas developers seem to do much better with HTTP/JSON because of the simplicity and directness of the approach.

Re: Flow vs. Typescript

#70

Post by k__ »

bsimpson wrote: post #61
msoad wrote: post #22

Both differences in this presentation are addressed in TypeScript 2.0 https://github.com/Microsoft/TypeScript/wiki/Roadmap#20

I talked with Lee Byron about the differences and if there's hope for convergence at React Europe. He said: - the biggest difference is nullability (you have to explicitly set TypeScript to treat all types as non-nullable by default to get behavior similar to Flow's default). - Flow uses nominal typing (similar to functional languages); whereas, TypeScript uses structural typing (similar to Java). To be honest, I don…

I have the opposite impression.

Structural type systems feel like dynamic typing most of the time, especially with JavaScript in mind (many {} and [] etc.)

Post reply on HN