Hacker News Reader

Comment by mattferderer | Hacker News Reader

I'm hesitant to work in any JavaScript code base that isn't using TypeScript at this point. Two years ago, it was painful to use as any early release is but the benefits were obvious.

My biggest wish for TypeScript is that it was easier to use experimental flavors that supported JS features currently being considered, such as the pipeline operator proposal.

View on HN

The codebase powering www.twitch.tv utilizes TypeScript and I can’t imagine working on a project of any significant size without leveraging it going forward.

So I know you also use React extensively at twitch, so how are you finding react and typescript working together?

I've been using the two together recently and its been great. Like you I don't think I could ever go back to not using typescript for anything but the smallest projects.

However, often times I've found some common react patterns to be difficult to express in typescript. Namely default props and high order components. The type signatures I'v ended up with for my HoCs aren't as simple as I'd like, but I guess there is no way getting around that.

I've actually started to prefer render props over HoCs simply because the type signatures are simpler. Still no idea how to handle default props correctly.

Maybe use the defaultProps HOC from recompose? Or take example from it!

For the default props side of things, as of typescript 3 and the latest @types/react it should work as you would expect:

https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in...

I saw that for default props, but can I use it yet?

The React typescript definitions are still on 2.8 [1], and I imagine that they plan to stick with 2.8 until maybe the next major react release? I have no idea where people discuss things like react types for DefinitelyTyped. Github issues seem like a mess due to the sheer number of different projects sitting in a single repo.

[1] https://github.com/DefinitelyTyped/DefinitelyTyped/blob/1d96...

Yeah you should be able to, the minimum typescript version required and the one they test at is 2.8 for now but the LibraryManagedAttributes type is present [1]. On 2.8 and 2.9 it has no effect but if you're using 3.0 you should see it working.

[1] https://github.com/DefinitelyTyped/DefinitelyTyped/blob/1d96...

My pet peeve with TypeScript and React isn't with React but some parts of the ecosystem, like redux-saga: there are subtle issues with using the saga operators that mean that although the compiler makes it look like type inference is working, you've actually lost the type being ``taken`` from redux with redux-saga. To maintain type safety, you need to do funny things like "typeof sagaFunction".

Little things like this can add up to subtle bugs and tech debt if you're not careful.

The vast majority of web development is done using JavaScript without TypeScript despite headlines on HN and reddit.

The vast majority of web development was also done without jQuery in 2007 despite headlines on HN and reddit.

That did not mean jQuery wasn't better than the ugly ad-hoc kludges in vanilla JS most web developers used at the time.

Whether jQuery, which is written in vanilla JavaScript, was better or not has nothing to do with my point.

TypeScript was released in 2012, I wouldn't call a 4 year old tool an early release. And if you were already using Webpack picking it up was as easy as adding a loader.

IMO, using such early proposals isn't worth the risk in production. Especially for proposals that are so young that they haven't even settled on a clear spec as to its behavior, like the pipeline operator.

Sorry this is self promotion but I think it's relevant if you need something like the pipe operator now: https://github.com/egeozcan/ppipe

It's also ironic that I couldn't write this in Typescript because I simply couldn't figure out how. These days when I use my helper, I just use any and cast the result. It sucks but until I figure out how to type proxies and use variadic generic type parameters (if and when these are supported) I don't have another solution.

The "official" Typescript solution to variadic type parameters is to write a bunch of overloads covering the most frequent cases, e.g. from 1 to 5 parameters.

TypeScript 3.0 fixed this: https://blogs.msdn.microsoft.com/typescript/2018/07/30/annou...

no yet really. But it's good first step to have "true" variadic types support. Right now I think you still can't represent stuff like `Promise.all` without many numbers of overloads.

> TypeScript was released in 2012, I wouldn't call a 4 year old tool an early release.

Goddamn time travelers, stop messing with chronology!

4-year old by the time GGP found it "painful to use as any early release", which was 2 years ago.

I could be slightly off on when I first used it by a year or two. Years start to blend together. It's almost 2019 already! Maybe I shouldn't have used exact numbers.

Either way it wasn't Typescript itself that made it difficult. There wasn't as large of community yet, documentation was much less, editor support wasn't as great and very few packages had type definition files. Definitely typed could show all or most of their packages on GitHub at the time and many were incomplete. That was the sole way to get any type definitions.

Agreed with your comment on early proposals. Still would like to have the option to use it and double check the transformation of how it outputs. And not everything needs to be for production use. Writing for fun is an enjoyable hobby.

Have you spent any real time with Flow?

As I’m starting to get into the modern front end world… I do want the safety of a stronger type system but it doesn’t look like the React ecosystem has really decided which way to go.

TypeScript is popular. But flow was developed by Facebook and so it’s obviously heavily used by some of the top people.

I’ve only been reading about them, I haven’t chosen to use one yet. But I’ve been leaning on flow since it’s developed by the React team at Facebook.

From my personal experience, Flow prioritises soundness in its type system, and thus can catch some bugs that TS won’t, but the TS tooling and editor support is drastically better than Flow’s.

Edit: oh and it’s worth noting that I’ve had much more luck finding TS definitions for third party packages than I have with Flow.

Could you expand some more on the tooling/editor support?

I’ve only done a cursory look. My editor (IntelliJ) supports both to some level. Webpack/Babel do too.

I’m very new to writing React and modern front end JS so it’s quite possible there are things that I should be looking out for that I don’t even know about.

Typescript compiler architecture is quite different to flows. Typescript was written from the get go to provide really fast and accurate intellisense to IDEs. The newer refactoring powers are super nice too. Most ides just ask typescripts language service “hey, my user’s cursor is here, what should I show for code completion?”

I think that’s what differentiates TS from flow. Typescript thought about the whole developers workflow while flow is just a compile time typechecker.

To Flow's credit, their language server does provide IDE features:

https://github.com/flowtype/flow-language-server#supported-f...

I still have found TypeScript to be an overall more pleasant developer experience, though.

That’s awesome, I didn’t know that.

At this point, I think Flow clearly has a minority mindshare & is looked at more skeptically all around the JS ecosystem, and maybe even the React ecosystem based on what I see talked around. TS does a much better job integrating with existing JS and is much more practical about incremental updates whereas Flow bleeds all too easily into needing to add typing to a significant amount of code in order to add a type.

That's not to say that either TypeScript or Flow are perfect - they both are constraining with typing when it comes to composing functions last I checked.

I didn't have too many problems with typescript and ramda. I occasionally have to explicitly send in types to the first function of a pipe, which is a little annoying, but for the most part it seems to just work for how I use it. What problems have you run into?

Have a look at the typescript declaration for Node's util.promisify (sorry on mobile can't find it right now). It's something like 10 lines long and covers only a handful of cases.

It's not something you'd want to find in the middle of your code, yet you may have to if you want to do generic/functional programming in TS.

For what it's worth typescript is developed by Microsoft. Doesn't get much bigger than that

I know, and that’s a definite plus. I don’t have to worry that it will go away or lose all the main contributors.

But is not developed by the same developers/company as React.

I will say given what TS is competing against the fact that it so well used is rather compelling. I know all of Angular is also written in TS. It’s clearly very heavily used.

React can fade but JavaScript won't..(it could only evolve). outside react Typescript is the clear winner and even most of the react projects I am seeing is using Typescript. I would say Typescript is the clear winner. Also VSCode is now far popular than other editors which is developed by Microsoft as well..

Also typescript and React go really really well because typescript can do tsx which is a strongly typed flavor of jsx.

Being able to use good code completion when using other people’s components is a huge boon.

Isn't React in itself a view library? What's there to develop on it?

I'm really interested in this, as I'm a happy Angular user. (I'm primarily a non-frontend dev/tech/ops, but I occasionally I do frontend development.) So every time I look at a React component/codebase I'm completely lost, and I'd like to understand why and what and how.)

I've spent time with Flow, and I like some aspects of it (the type system seems a little more expressive, at least in the ways I know how to bend it). But it seems like TypeScript has fairly soundly won, as far as the two of them go. I've moved to writing almost exclusively TypeScript and I really don't regret it.

I worked with both. Without going into details - I recommend TS as it's better documented and easier to work with. With 3.0 they also improved error messages.

EDIT: one thing I miss from flow is https://github.com/gcanti/babel-plugin-tcomb - it's quite handy to spot data errors (before you have big static coverage)

Although it's clear that Facebook's libraries, among which React, favour Flow, there's strong community demand for TypeScript even around React. Thus, the type definitions that are available for React are excellent, Redux even includes its type definitions natively, and most of the large tools in the React ecosystem work pretty well with TypeScript.

The main large project you're likely to use that does not really play well with TypeScript yet is create-react-app. There's a TypeScript fork [1] which works reasonably well, but "reasonable" is not really what you'd hope.

That said, the strong community push means that they're at least considering it. [2]

[1] https://github.com/wmonk/create-react-app-typescript [2] https://github.com/facebook/create-react-app/pull/2815

Create React App is the first link that TS gives you in "getting started". Is there something wrong with it?

https://github.com/Microsoft/TypeScript-React-Starter#typesc...

CRA is a set of packages, among which the most important is react-scripts (contains all build and publish commands). For Typescript you use rect-scripts-ts, a fork that usually is some versions behind the main one.

It does work fine, but sometimes you don't get some of the gooddies that you get in the latest js version.

I agree, the TypeScript team loves React and one of the reasons I started using React was because JSX/TSX is one of the few ways to type check views.

I have been maintaining some boilerplate to demonstrate TypeScript + React SSR that should point the reader in the right direction https://github.com/styfle/react-server-example-tsx

We're actually looking at removing the type definitions from the Redux core and punting them over to DefinitelyTyped, because neither of us primary maintainers use TS ourselves and we don't have the experience to maintain the type definitions.

Also, the CRA-TS fork runs, but the one time I played with it was when I tried to help another team set up their project, and that's when I found out it has _ridiculously_ restrictive default linting rules. Every lint error is a compile error, and it flags things like using arrow functions in render methods, which is absurd (see discussion at https://github.com/wmonk/create-react-app-typescript/issues/... ).

Haha right, it's still the case that the type definitions for Redux are very much usable though :)

The first thing I do in a new CRA-TS project is make the tslint.json rules default to warnings instead. Or just disable them completely. After that, it's great! I'm actually surprised that they still haven't loosened the rules after Dan called it out a month or two ago. Seems like an easy enough fix to at least make them warnings until they choose better defaults.

Here is another PR, more recent, based on Babel 7 and its TS support: https://github.com/facebook/create-react-app/pull/4837

I'm waiting it to be merged to switch to TS.

I've reported 5 bugs about Flow and can list at least 10 other bugs reported by other people that I experience on a daily basis. Most of them have been upvoted by hundreds of people. Most of them have been opened 1 or 2 years ago. Most of them don't have a single reply from people working on Flow (or one of these: "yes I guess it's a valid point", "pull requests are welcome", "it's not a bug" , "we would have to rewrite a lot of stuff", without any follow-up).

That's what really frustrates me about Flow after using it for many years. We shouldn't have to rewrite valid code, write unreadable workarounds or add // $FlowFixMe annotations to avoid Flow's issues. I lead a small team of junior developers to whom I presented Flow. We now use it everywhere. But they often experience difficulties when they try to type their code. When I see what blocks them, my answer is too often "oh yeah, it's a bug in Flow. There is an issue about it on GitHub opened in 2016".

I'm right now waiting for this https://github.com/facebook/create-react-app/pull/4837 to be merged to move all my projects to TS.

Edit: and I don't blame the devs working on Flow. I guess it's more a priority issue at Facebook. Or maybe they just gave up on the community support since TS is too ahead.

I hope the work they did with the Babel team with help with this.

https://blogs.msdn.microsoft.com/typescript/2018/08/27/types...

I'm really eager to see availability of some extra features via this new pathway.

But I am less excited about projects containing TypeScript plus the large number of transitive dependencies from a typical Babel set up; I've been greatly enjoying TypeScript instead of that.

For my part, my web projects have generally ended up with both Typescript and Babel because of old-browser-support reasons, so integrated parsing simplifies things for me.

100% agreed. It was incredibly liberating to move from Babel with its byzantine level of configuration and plugins to "just run tsc". So much easier to reckon with - Typescript is Typescript is Typescript.

I am looking forward to see some production ready versions of RY latest project Deno "A secure TypeScript runtime on V8"

https://github.com/denoland/deno

Written in Go rather than C++ no less.

Edit: wait it looks like they’ve changed to all Rust with C++ for the libraries. I haven’t looked at the codebase since the spring. Am I crazy that i could have sworn it was written in Go previously?

It was in Go, but in Ryan’s announcement, he said he was considering switching, and has since done so.

Cheers, Steve. I missed that.

https://github.com/denoland/deno/commit/86354a29a40fb97e334f...

https://github.com/denoland/deno/pull/276

Thanks guys. I'm out of the loop.

Until this showstopper is fixed (it's been almost 9 months now), some of us can't move forward with Babel 7: https://github.com/babel/babel/issues/7074

Yeah, agreed.

If I were looking for a regular job, I would probably filter employers based on whether they use TypeScript or not at this point (assuming it was some JavaScript-adjacent project). I'm not sure if there's really a good way of doing this sort of filtering.

That's the main reason I use Flow almost exclusively. I don't like sacrificing really useful features for the sake of a cleaner code base.

Reply on news.ycombinator.com