Hacker News Reader

Comment by Waterluvian | Hacker News Reader

I really want to commit to TypeScript for React/Redux apps but I'm gun shy. I don't want to commit to all the added effort TypeScript brings because I'm not sure if apps of my size warrant it. I'm afraid that I will end up with an over-engineered solution for my various apps of 10-100 components.

View on HN

It's such a no brainer after you use it for a while, and the time savings after the fact far make up for the initial learning curve.

Just do a small project to muck around with first. Maybe something small that nobody has thought of, like a to-do list?

> and the time savings after the fact

Could you elaborate how? I used to heavily use typed languages, but after moving to JS 5 years ago, I don't miss types.

The one time I think, "oof I really would have liked types here" is when I begin digging deep through a stack of calls to understand what values I should expect and are valid. This hurt me in Python too until I began using type hinting, which in my opinion is the best of both worlds: documenting types but not forcefully enforcing typing.

- Get autocompletion for everything: object properties (eg. user.[firstname, lastname, etc]), type-specific methods (eg. thisIsAStringButYourEditorCantKnow.[list of string methods provided by your editor since you told him it's a string]), etc

- Detect bugs and errors early, removes some kind of bugs (eg. typo errors: user.fisrtname, your editor will tell you fisrtname is not a property of user)

- Help to refactor (eg. 'Rename Symbol' in VSC can't work on everything if your code isn't typed, eg. (X => X.someProperty), someProperty isn't renamable automatically since your editor doesn't know what's X)

- Reduce extra error handling (eg. if (a === undefined || b === undefined || a is not a number || b is not a number) throw new Error(...))

- Reduce extra unit tests (eg. expect(add(5, undefined)).toThrowAnError(); expect(add(5, 'foo')).toThrowAnError();)

- etc...

Being able to 'find all references' of a variable, do a safe global rename, and 'go to definition' saves an immense amount of time.

Not to mention preventing tons of run-time bugs which saves a ton of times having to figure out.

You just think you don't miss types but I guarantee you are doing a lot more manual work without types than with them, starting with refactorings which you must now supervise since it's pretty much impossible to guarantee the correctness of an automatic refactoring in the absence of type annotations.

I'm actually really happy to hear someone call it a "no-brainer". That's an indication that it's likely a good fit at any scale. I was always concerned that it was too much at smaller scales.

I will create the world's ~first~ millionth to-do app to experiment.

Even though I'm someone who doesn't reach for TS by choice (have had to use it for a couple of projects) I would add that even in a small or simple app, if you ever work with abstractions or wrapped values, you'll quickly feel the benefits of having types.

> You can take an incremental approach and add type annotations as you need them

Most definitely. We've added type safety to new features in our legacy codebase. It's very seamless.

Can also confirm. Recently a convert and it's a breeze. It makes for more maintainable code, ultimately, and has even cleaned up some of my poorer JS habits.

Also, for those who get caught up rewriting types for existing libraries, I recommend you check this library first:

https://github.com/DefinitelyTyped/DefinitelyTyped

I think the bigger leap is between having a transpiler and not having one.

If you are already using babel for example, you can have it compile Typescript (basically strip away all the type annotations). At that point typescript is like an optional set of javascript features.

Also the typescript compiler is very flexible, in terms of what it enforces. You can vary it from being really lax to pretty strict.

You can use babel to do the transpilation, then have the typescript compiler run off to the side doing typechecks / providing your editor with code completion.

I'm going to against the other responders and say in our case, it wasn't worth it, and we ended up ripping out Flow from our large application.

I'll preface by saying we didn't start the project with Flow but tried to add it after-the-fact.

We ran into a ton of problems with Flow itself -- posting issues that went unanswered; flow server would regularly crash or spike our dev machines to 100% CPU. We ran into problems with third-party type definitions either being completely wrong or missing entirely. I spent weeks of work trying to get Flow to work properly.

On top of all that effort, what did we get? It caught a few runtime errors (cannot find X of undefined, X might be null but isn't checked). It was nice to see the types on our action and API payloads. Autocomplete was nice.

When we add all of those things up I'm not sure it saved the amount of effort put into converting a project to Flow ... and we ended up dropping it completely because of its continued maintenance requirements.

I'm not saying that there isn't a benefit to TS or that other teams haven't used it to great benefit but it really cannot be understated how much effort it takes to get it right. There are a lot of ways to do it wrong and there are ton of articles that will lead you in the wrong direction. From getting the build system right, to third-party definitions being out-of-date, to googling around for hours to figure it all out, it is a big time investment. Every project that is brought into your repo needs to be typed to see the full benefit.

Just don't worry about typing every single piece of code in your application. Some patterns are just plain difficult/impossible to type properly. Don't try to re-architect pieces of code to type-check fully (I did that for a while, definitely a waste of time).

The low-hanging fruit of automatically inferred typed alone is great. Even adding `//@ts-check` to JavaScript code has proved helpful.

You don't have to commit to a big up-front effort. You can take an incremental approach and add type annotations as you need them.

Also, I'm not sure how adding type annotations results in over-engineered solutions. Types are just little sanity checks you spread around your code to help the compiler and linters to catch inconsistencies. You shouldn't have to re-engineer everything.

My understanding is that now I have to also manage type definitions. It ends up being more code in my files and more files.

I'm a big fan of keeping files as minimal and simple as possible. I virtually "count" the number of language concepts that exist, and try to keep it as low as possible. Makes it easy for other developers to on-board and for me to re-on-board.

You don't have to do anything. Just drop TypeScript in as a replacement for babel. Whenever you find yourself wondering if a type annotation or definition would help, then do it. Leave it optional; no commitment required.

you don't actually have to manage type definitions for your own code (unless you're referring to typing parameter/return values), just things that you eg. fetch from the backend. those can be trivially generated by a tool from sample json or you can generate it all from things like OpenAPI.

If you haven't worked with types before, you should pull the trigger. I say this because the real issue will be whether you like working in typed code or not. If you learn you do (as I did, unexpectedly) you'll probably find yourself more productive _in general_ with it, and using it on projects of all sizes.

Try cloning this small boilerplate[0] and open with VS Code. I think you'll quickly see how powerful TypeScript is, even on a small project. Feel free to browse my repos as I have several real-world TypeScript apps.

[0]: https://github.com/styfle/react-server-example-tsx

Reply on news.ycombinator.com