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

81–90 of 158 posts

Re: Flow vs. Typescript

#81

Post by duncanawoods »

greenspot wrote: post #42
Skinney wrote: post #14

The main problem for me, is that Flow doesn't support Windows (yet?). I've been working solo on a frontend a couple of months now, and the team has just been extended with a new developer (yay). However, he uses Windows, and so all my type annotations are worthless. We're making the switch to TypeScript once 2.0 is released (easier to port with strictNullChecks).

Really wondering: who is developing Node/JS on Windows nowadays? Not that I don't like Windows (I like W10 + the new Ubuntu within efforts a lot), but the ecosystem around Node is so much tailored around Linux. Even with OSX where we have an excellent support, there's still some slight friction when deploying to Ubuntu. Or is Windows 10 a viable alternative for Node devs?

Yeah, I do. Workstation is W10, Laptop OSX and deploy to Linux.

I don't have any problems. I have sometimes found bugs introduced into a library that only affects one platform but not the others. This has happened on things like grunt-plugins rather than more critical libraries. It hasn't caused any drama other than delaying updating a dependency until its fixed.

Re: Flow vs. Typescript

#82

Post by plgs »

chvid wrote: post #72
chvid wrote: post #49

Earlier quoted context omitted.

I work on / have worked on fairly big projects. Plenty of them have been "a challenge to work with". Always because of the code that had been written (+ other things). Never because of the language. For me the trick to big projects is strong modularisation and well-defined interfaces which you can do regardless if you have static type checks or not.

Plus. I think that there is a bit of developer-psychology-101 here. Most developers would rather go: This project sucks. This shitty language has not got a proper type system. Let's build a compiler/type-checker/use-this-cool-alpha-from-bingo-banana-I-found-last-night. Rather than: This project sucks. I cannot believe how much bad, disorganised code we have written. Let's sit down and look at our mess to see if we ca…

I don't see these as mutually exclusive. Introducing a compiler/type-checker can be (depending on your situation) a very concrete way of improving the way code is written.

Re: Flow vs. Typescript

#83

Post by aquadrop »

greenspot wrote: post #42
Skinney wrote: post #14

The main problem for me, is that Flow doesn't support Windows (yet?). I've been working solo on a frontend a couple of months now, and the team has just been extended with a new developer (yay). However, he uses Windows, and so all my type annotations are worthless. We're making the switch to TypeScript once 2.0 is released (easier to port with strictNullChecks).

Really wondering: who is developing Node/JS on Windows nowadays? Not that I don't like Windows (I like W10 + the new Ubuntu within efforts a lot), but the ecosystem around Node is so much tailored around Linux. Even with OSX where we have an excellent support, there's still some slight friction when deploying to Ubuntu. Or is Windows 10 a viable alternative for Node devs?

Node.JS is actually pretty well adjusted for Windows. They made it cross-platform from the beginning and you have zero problems unless need some linux-compiled native dependencies. VS2015 is using node successfully for built-in grunt/gulp task runner.

Re: Flow vs. Typescript

#84

Post by s_kilk »

Hurtak wrote: post #30
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:…

> - if people enter or leave your team frequently: yes Interesting, I would put that one as a no, since introducing TS to you project means longer time train new employees. On the other hand it will make sure their commits break something less often, so not so sure about this one

> 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.

Re: Flow vs. Typescript

#85

Post by chvid »

plgs wrote: post #82
chvid wrote: post #72

Earlier quoted context omitted.

Plus. I think that there is a bit of developer-psychology-101 here. Most developers would rather go: This project sucks. This shitty language has not got a proper type system. Let's build a compiler/type-checker/use-this-cool-alpha-from-bingo-banana-I-found-last-night. Rather than: This project sucks. I cannot believe how much bad, disorganised code we have written. Let's sit down and look at our mess to see if we ca…

I don't see these as mutually exclusive. Introducing a compiler/type-checker can be (depending on your situation) a very concrete way of improving the way code is written.

They are not. But the pscyhology is that people will much rather talk about introducing a new tool rather than what they have done wrong.

Re: Flow vs. Typescript

#86

Post by wpietri »

itsyogesh wrote: post #65
bsimpson wrote: post #61

Earlier quoted context omitted.

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.

The basic notion is that part of the meaning of a type is whether it's allowed to be null. As developers we have notions of whether some variable is supposed to ever be null; this is just asking the computer to make sure.

For example, suppose you're building a simple app to remind you to call your friends on their birthdays. Your fields are name (a string), birthday (a date), and phone number (a string). Since it doesn't make sense to put somebody in without a name and birthday, you say those aren't nullable. But say you want to be able to leave a phone number out, because it's easy enough to look up their phone number when you want to call. So phone would nullable.

Java, as an example, required everything variable to be typed, but all references could be null. This meant that far and away the most common error in Java logs was NullPointerException. It's great to see language features aimed at reducing that.

Re: Flow vs. Typescript

#87

Post by seanwilson »

chvid wrote: post #41

I am the only one who is happy to code without static typing? Enjoying fast compilation, small, fast editors, flexibility. I don't really make stuff like marry(a, b) and then call it with a banana and an apple by accident. Sure I make plenty of mistakes when I am coding but only very few could have been caught by a static type check. Take one of the examples in the slides: let obj: string; obj = 'yo'; // Error: Type…

I agree I don't miss types too much when the amount of code is small. However, when you have thousands of lines of code including code you didn't write and JavaScript spits out a "undefined is not a function" error in the middle of running a complex program, static typing can save you a huge amount of time and sanity.

Also, what are you losing by introducing strong types? Why wouldn't you want the compiler to verify the logic you're keeping track of manually?

Re: Flow vs. Typescript

#88

Post by shados »

greenspot wrote: post #42
Skinney wrote: post #14

The main problem for me, is that Flow doesn't support Windows (yet?). I've been working solo on a frontend a couple of months now, and the team has just been extended with a new developer (yay). However, he uses Windows, and so all my type annotations are worthless. We're making the switch to TypeScript once 2.0 is released (easier to port with strictNullChecks).

Really wondering: who is developing Node/JS on Windows nowadays? Not that I don't like Windows (I like W10 + the new Ubuntu within efforts a lot), but the ecosystem around Node is so much tailored around Linux. Even with OSX where we have an excellent support, there's still some slight friction when deploying to Ubuntu. Or is Windows 10 a viable alternative for Node devs?

I don't have a link, but there was a note on the Webstorm blog or whatever about how they were not adding Flow support because the majority of their users were on Windows. Obviously, considering the kind of tooling Webstorm provides, it would have a huge selection bias...but Jetbrains seems to be making money with a product for JavaScript that mostly caters to Windows users.

So there's "enough" Windows users doing JS on Windows.

Heck. Support/doc/headway aside, I strongly feel it was one of the big factors that pushed TypeScript beyond the critical mass. You just can't make a JS dev tool *nix only and expect critical adoption.

Atom editor had the same issue.

Re: Flow vs. Typescript

#89

Post by seanwilson »

sgift wrote: post #6
huuu wrote: post #4

Earlier quoted context omitted.

But programming with comments is bad practice. Maybe in this case it doesn't matter very much but there are a lot of ways comments can get lost or messed up.

That's a very common position, but my experience shows me if the comments are not in line with the code that is usually a very good hint that the code will be buggy. It probably has been changed in such a hurry that the comment was forgotten, which doesn't bode well for the code quality.

> That's a very common position, but my experience shows me if the comments are not in line with the code that is usually a very good hint that the code will be buggy.

An example might help but to me bad code is code that repeats itself which includes comments. To me, comments should only be used for high level explanations (e.g. architecture, algorithms, public API) and when the purpose of code is non obvious (e.g. weird bug workarounds, optimisations). The vast majority of comments can be removed by rolling their contents into better function and variable names.

Re: Flow vs. Typescript

#90

Post by shados »

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…

Java does nominal typing. That's actually a difference between Flow/TypeScript and Java/C#. The laters do nominal types (that is, if I have type Foo, that has a string property, and type bar, that also has a string property, they are NOT consider the same thing in Java/C#)

The difference is that TypeScript does structural typing exclusively, while Flow does structural for interfaces, and nominal for classes. So if you don't use classes, there's no difference (on that front), but if you use classes, there is.

Post reply on HN