Facebook Launches Flow, Static Type Checker for JavaScript

Post by jbergens » Wed, Nov 19, 2014, 3:47 PM UTC

ep103 wrote: post #103

inglor wrote: post #78

Earlier quoted context omitted.

Well, here are some things that it does that other tools don't: - It type checks JSX - It supports some ES6 features others don't (like destructuring) as the build step - It has union types (TS will get those soon, already in master) - It does a lot more inference and a lot more assumptions. It assumes you won't multiply a string by a number for example (although technically '10' * 5 is legal in JS). So it's opiniona…

I digress but... you're not wrong, but out of curiosity, I just genuinely wonder how often modern programmers really hit type errors on smaller projects (obviously not FB size). I don't think I've ever had a type cast bug in my js code, provided we don't include accidental nulls in that statement. So in my experience, if I were ever told that I now had to always use annotations, I would feel like I was losing flexibi…

Post by jbergens » Wed, Nov 19, 2014, 3:50 PM UTC

ajuc wrote: post #226

ep103 wrote: post #103

Earlier quoted context omitted.

I digress but... you're not wrong, but out of curiosity, I just genuinely wonder how often modern programmers really hit type errors on smaller projects (obviously not FB size). I don't think I've ever had a type cast bug in my js code, provided we don't include accidental nulls in that statement. So in my experience, if I were ever told that I now had to always use annotations, I would feel like I was losing flexibi…

I do hobby level small js projects, I make type errors quite often, but they are easily found the moment I run the tests/the app. I would prefer to find them at compile time, but it's not a big deal. Interstingly it's almost always the same kind of type error- accessing nested maps/arrays and forgetting to go deep enough before I call some method on the elements in that collection. I can't remember one example of typ…

Post by jbergens » Wed, Nov 19, 2014, 4:12 PM UTC

emmanueloga_ wrote: post #230

There's some tremendous effort being poured into making a crippled language like javascript usable, but when talking about solutions for maintainable frontend code, I'm more excited about compile-to-js languages like haxe [0], purescript [1] or ceylon [2]. The caveats I heard about transpilers often boil down to difficulty of debugging and lack of libraries. But with the amazing browser dev tools we have, debugging p…

Post by ajuc » Wed, Nov 19, 2014, 4:18 PM UTC

jbergens wrote: post #263

ajuc wrote: post #226

Earlier quoted context omitted.

I do hobby level small js projects, I make type errors quite often, but they are easily found the moment I run the tests/the app. I would prefer to find them at compile time, but it's not a big deal. Interstingly it's almost always the same kind of type error- accessing nested maps/arrays and forgetting to go deep enough before I call some method on the elements in that collection. I can't remember one example of typ…

And in a large app it is hard to know if all relevant code has ran. Finding pieces that uses the code you just changed is much easier in static languages. We might not go to a fully statically typed javascript but supporting optional typing seems like a really good idea.

Post by oyvindkinsey » Wed, Nov 19, 2014, 7:01 PM UTC

ufo wrote: post #58

slashnull wrote: post #34

Earlier quoted context omitted.

If only to remove syntactically invalid type annotations, I guess. Strong typing is not incompatible with the absence of run-time typing information, due to the magic of type erasure.

Type erasure is only safe if the whole program is statically typed though - you are still going to need to use runtime checks if you want to interface with dynamic code.