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

51–60 of 158 posts

Re: Flow vs. Typescript

#51

Post by rubber_duck »

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

Learning time of the actual type system is nothing compared to learning/getting in to the code base if it's anything non-trivial.

At the very least type annotations are compiler verified documentation which is a huge time saver, along with better tooling that lets you navigate trough the code more efficiently.

Re: Flow vs. Typescript

#52

Post by alectic »

hoodunit wrote: post #40
solomatov wrote: post #5

The best things about flow which typescript doesn't have is sound typesystem. I hope typescript will adopt it at some point in time.

One area in which Flow may be "technically" sound but it feels illogical is how in how it infers certain types. TypeScript requires that a variable has one type that doesn't change, but Flow will infer multiple types for a variable at different points in the code depending on how it is used. Also because Flow infers types based on how they are used, there are some interesting situations where you would expect the typ…

Jeff here (I work on Flow).

I talked a bit about why we infer unions in this way in my ReactEU talk earlier this week (https://www.youtube.com/watch?v=VEaDsKyDxkY).

Ultimately it boils down to the notion that inference is about understanding the type, and annotations are about expressing it.

If you write a type annotation for a variable, then Flow will of course not infer anything more or less than your annotation. If, however, you use the variable as multiple types (but do so in a way that is clearly safe), Flow infers the union so that it doesn't give you errors for code that is clearly ok.

I think the example from the talk was something like:

  var name = "Jeff";
  name = name.toUpperCase(); // safe
  if (loggedOut) {
    name = null; // safe
  }
  var firstInitial = name ? name[0] : null; // safe
The above code has no errors in it, and because flow infers `name` as a type `null | string`, Flow is able to verify its safety and thus doesn't error.

OTOH, if we use an annotation to express the type of `name` as intended as only `string`, then we would get an error on the null assignment:

thing like:

  var name: string = "Jeff";
  name = name.toUpperCase();
  if (loggedOut) {
    name = null; // Error!
  }
  var firstInitial = name ? name[0] : null;
So in summary: Inference is the means by which Flow understands, annotations are the means by which you express to Flow your intentions.

Re: Flow vs. Typescript

#53

Post by cgag »

chvid wrote: post #49
adamors wrote: post #45

Earlier quoted context omitted.

How big are the projects you are working on though? For instance I work an a 2 year old Angular project and static typing is something we are trying to introduce because the codebase is large and challenging to work with, mostly because Javascript. There's only so much you can do with best practices and code organisation.

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.

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

Re: Flow vs. Typescript

#54

Post by LionessLover »

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 do, and I'm a Unix person, even having contributed code to the Linux kernel and I've used Unix - Solaris, HP-UX, NeXTSTEP, Linux, Reliant Unix (Siemens), IRIX (SGI) since 1994.

It's just that over time I fond it more and more of a -useless - hassle to keep a VM with Linux on my desktop, and pure Linux desktop never was a question (for various reasons).

When I install git for windows and ConEmu64 I have a good terminal and a bash and the basic Unix command line tools. The IDE and node.js are the same anyway. I configure the IDE and git so that my projects only have one type of line endings (Unix).

I have zero Windows server experience since that is all Unix for me, but on the (developer) desktop I don't feel any need for Unix.

Re: Flow vs. Typescript

#55

Post by pingec »

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 develop on Windows and deploy to Linux regularly, zero problems. Most of the projects are purely js with no dependencies on binaries.

Re: Flow vs. Typescript

#56

Post by fridek »

I think the biggest loser in this comparison is Closure Compiler, which is around for years with all those features. It's also still active with development on understanding and transpiling ES6 and even TypeScript from what I've heard [1]. There also made a good move recently, enabling ES6 modules packages instead of its own goog.provide/goog.require.

Yet, the available toolchain for it is years behind others. If you wonder how you should have any live reload development with it, you can either rely on community plugins like grunt-closure-compiler [2] or hope plovr[3] is finally resurrected back to a state where it's usable. This all sounds fine until you think about any unit testing. The only karma runner[4] for closure is simply broken and unmaintained. Even worse, most of npm packages you might want to compile with your code will output thousands of errors because there is no clear way to whitelist code as "not my code leave it alone". I can just hope one day Google will publish a yeoman generator with all those things solved and get it back in the game.

[1] https://groups.google.com/forum/#!msg/closure-compiler-discu...

[2] https://github.com/gmarty/grunt-closure-compiler

[3] https://github.com/bolinfest/plovr

[4] https://github.com/karma-runner/karma-closure

Re: Flow vs. Typescript

#57

Post by chvid »

cgag wrote: post #53
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.

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.

Re: Flow vs. Typescript

#58

Post by k__ »

inaseer wrote: post #46
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…

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 be changed on the fly later.

The solution was:

    const a = A()
    const b = new SubtypeOfB()
    b.attributeOfSubtypeOfB = 123 //here TS thinks it is SubtypeOfB
    a.b = b //now TS thinks it's B
Which felt like "Why do I have to restructure my code with extra variables when I clearly know that this object HAS that attribute?!"

And Java was full of those problems. Numerous different definitions of the same thing that aren't compatible with each other. Hell, some languages even have different string types.

But yeah, TypeScript is generally chill about most things and the hints it gives me were often right and helped to find the right methods without consulting any docs, which is a huge win, even without the refactoring stuff.

Re: Flow vs. Typescript

#59

Post by imtringued »

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…

undefined is not a function

Re: Flow vs. Typescript

#60

Post by glibgil »

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.

When you want

    function render(markdown : Markdown) : Html
then you will see the reason for types (and lots of them)
Post reply on HN