If TypeScript is so great, how come all notable ReactJS projects use Babel?

(Enrico Sada) #22

Just a note: Using a statically typed language doesnt mean you need to add type signature everywhere, these are languages who lack a good type inference (like java).
In languages with good type inference (ocaml, f#, haskell), the compiler can infer the types, and check your code at compiler time.

The style of programming change a bit with good inference, because you dont use types of arguments to document your code, or specify a behaviour or abstraction. You can create simple functions and compose that, because is not verbose and safe checked at compile time

If you want an example of a statically typed language with good type inference, F# ( http://fsharp.org ) compile to javascript (babel) with Fable ( https://fable-compiler.github.io ).

You can see some online examples https://fable-compiler.github.io/samples.html , with react too

I write that because is really easy to confuse statically typed languages with poor type inference (like Java), with others with good type inference (like ocaml). The program is compile checked in both cases, but the code is really different.

public int Add(int a, int b) {
  return a + b;


let add a b = 
  a + b

(Basarat) #23

Because learning a type system is more than just learning JavaScript, and people are free to stop at any level they feel comfortable to get stuff done and its okay :heart:. That said :

PS: I wrote an IDE in TypeScript + ReactJS : http://alm.tools/ :rose:

(l1x) #24

Would you mind sharing some example of it in a shape of a blog post? It would be helpful for companies who are in the process of adopting React together with TS.

(Kevin Dangoor) #25

My first note is that for large applications, I think that the productivity benefits of using a static type system are huge. As quick as the reload (or even hot-reload) development cycles are, it’s hard to make your iteration cycle faster than having complaints instantly in your editor if you get something wrong. Ease of refactoring is a huge difference as well.

On a recent side project, I tried out both Flow and TypeScript. It’s pretty easy to switch between the two, so it’s pretty easy to give them both a whirl (especially for something smallish). I found the editing experience to be far superior with TypeScript (Visual Studio Code was rock solid). The much larger availability of typings is another plus for TS.

Prior to TypeScript 2.0, I would have said Flow is better if for no reason other than strict null checking. TS 2 adds strict null checking as an option, so it’s moved forward on that feature.

My only advice, really, is to give both a quick try and see which you like more. I don’t think you’d go wrong with either, but I do think it’s well worth using one of them if you have a lot of JS.

(0ca0a) #26

It seems quite obvious. With Babel we get a better, more mature, more widely supported transpiler that serves a better ESnext and has a larger grasp of draft specs and future proposals. Flow is arguably a better type checker. That these two are modular, focussed tools shouldn’t rock you. If you have a modern buildsystem using Webpack everthing is modular. I find it quite strange that today there are still tools out there like TS, requiring specific workflows and IDE integrations, doing too many things at once, etc.

(DryWolf) #27

If we are talking about the average npm module I think the reason why not many open source projects are using TypeScript from the get go is because they are being written by a single person most of the time at their inception.
(and later on in the lifecycle of the module, nobody is going to change the JavaScript to TypeScript, unless there is a very good reason).

IMO TypeScript is most valuable if you are starting a “bigger” project and you are working together with a full team on the code from the very beginning. Then you should immediately recognise the benefits that typed code gives you when reading each other’s code, changing code that was written by someone else originally or if you are supposed to implement some kind of interface in an already existing API.

(Having type information readily available for developers to reason about the code and for tooling can help you a ton in those situations)

(Pine Wu) #28

There is a rewrite of TS grammar that fixes ~120 issues: https://github.com/Microsoft/TypeScript-TmLanguage/pull/257

Should come as a VSCode extension this week and improve TS experience quite a lot.

(Sophie Alpert) #29

Do you have concrete examples of how the VSCode experience was more solid with TypeScript than with Flow? The Flow team is super interested in improving editor integration so examples of what’s currently lacking could be helpful.

(Tom Duncalf) #30

Hey Ben,

I’d be happy to go into some detail on this as I’ve worked extensively with TS and have tried flow several times but ultimately gone back to TS, in part for the editor experience.

Just to check, are you interested in TS+VSCode vs Flow+VSCode or vs Flow+Nuclide?


(Andy Williams) #31

I would argue that there aren’t many use cases for static typing. It doesn’t really provide that much benefit until you reach a point where you start seeing issues with scaling your code for a big and/or distributed teams. If anything, adding a static typing makes you less productive until you reach this type of scaling issue as your code has to be that much more verbose.

How many bugs do you produce on a small/medium project because you didn’t know what type a function would return? I wish a company that uses JavaScript heavily would look into this and share their findings - that would be an interesting study to read.

(Kevin Dangoor) #32

A few weeks ago, I tried Flow with both Nuclide and VSCode. The biggest problem that I had was that I was having inconsistent results. Errors (or the clearing of errors) wouldn’t always match up with what I’d see from running Flow on the command line. With TypeScript in VSCode the interaction was always perfect… type a couple of characters and the appropriate errors showed up right away.

I’d be happy to try again sometime if you all don’t see this behavior in VSCode or Nuclide.

(Kevin Dangoor) #33

The original poster said that they have a large scale codebase.

Have you ever seen “Undefined is not a function” in your browser console? That’s a bug that Flow and now TypeScript could catch for you right away in your editor. Refactoring your code is much quicker and easier when you know exactly was is impacted.

Sure, if you’ve got a small project that isn’t going to change much over time, there’s no point. With Flow and TS, your code is not that verbose. Their type systems are really nicely defined.

(r b) #34

I for one would be interested in TS+VSCode vs Flow+VSCode. Been using VSCode and Flow for a year or so now.

(Jeffijoe) #35

I’m starting a TypeScript + React project, and am constantly being pushed back by TypeScript when writing React components. Things like object rest/spread to yank out 1 or 2 props and passing on the rest isn’t possible - first of all object rest/spread isn’t in TypeScript yet (slated for 2.1), but if you want to just wrap another component you need to extend the props interface for that component as well, else TS won’t let you add those props when using your wrapper, even when you just want to pass it on to the component you’re wrapping.

What does a typical Functional Stateless Component look like in your codebase? I’d like to compare to see if I could simplify things while remaining type safe. :slight_smile:

(Jeffijoe) #36

I think the biggest challenge is third-party libraries. I gave Flow a spin yesterday and I couldn’t find any good resources for actually using third-party libraries. Looking at flow-typed I can see there are a few typedefs available, but peeking at them I’m seeing a lot of lib$someType and that just throws me off, having no idea how to write the typedefs for missing libraries.

I think it would really help with a “tutorial series” going through every aspect of writing a full app with Flow that uses a lot of third-party packages.

(Donald Pipowitch) #37

I really missed rest/spread, too. But it is planned for 2.1 and I can wait for this feature. You can get the same functionality with a little bit help from Object.assign and similar functions. (Note you can use spread syntax for JSX props with 2.0 already.)

Also planned for 2.1 is the feature to handle children as a field of props in JSX syntax correctly (treat <Foo>bar</Foo> like <Foo children="bar"/>). See https://github.com/Microsoft/TypeScript/issues/8588. It can be a little bit annoying, but I can wait for this, too.

Besides these two features I currently miss nothing important.

What does a typical Functional Stateless Component look like in your codebase?

Good question. Yes, it can be a little bit cumbersome to get started. Maybe I write some Gists or examples in a GitHub repo and will ping you.

(Donald Pipowitch) #38

Yeah, I’ll try to create something and will ping you.

(Keith Miklas) #39

JavaScript is the native language. For browser work, it’s the bottom line; the foundation. In that way, t’s sorta like C/C++, Java, or SQL.

Nobody wants to stray too far from the foundation. There’s a new language every year, and it’s just too easy to waste years on a language that suddenly falls out of favor, or is proprietary.

Sooner or later you’ll get the rug pulled out from under you.

(Ccorcos) #40

If Flow has such great type inference, why isn’t there an option to infer all types? Especially in a small project…

(James Kyle) #41

If Flow has such great type inference, why isn’t there an option to infer all types? Especially in a small project…

I’m not sure what you mean. Flow will always infer as much as it possibly can– there would be no reason to turn down how much inference is being done… It seems what you want is already the case