Is it worth it to invest in learning TypeScript?

TypeScript is the biggest factor that made JavaScript coding bearable to me. Before that, I was collapsing under the weight of my ~1000-line JavaScript programs, because I couldn't mentally keep track of types and names. Similarly, revisiting my old JavaScript programs after a year, it was tedious to reread my code to infer the types and structures.

I know the rules of JavaScript, including all the weird type coercion stuff, undefined, etc. I know how to write correct programs, but I hate the human effort of having to jump around my codebase to recheck definitions and to double- and triple-check my work for silly mistakes.

Writing TypeScript code makes me do a bit more work upfront to annotate types. But in exchange, the compiler helps me tremendously in tediously checking all the types and names. Functions with types are more self-documenting than untyped functions; it's easier to read and figure out what a function does at a glance.

In a sense, compile-time type-checking is more powerful than unit tests because unit tests only cover functions and branches and (run-time) types that are actively taken, whereas type checking applies to all code all the time.

Before discovering TypeScript, I used this workaround a few times: For complicated pure algorithm / data structure stuff (not DOM or user interface stuff), I would prototype the program in Java with all the glorious types, test the heck out of it, and then translate it line by line to JavaScript.

If you want a job writing JS in 2021, then yes, you should be proficient with TS. That said, there's not really a whole lot to it, other than pre-defining types for function arguments and objects using a couple extra syntax elements. It's actually less efficient when writing, but it's significantly more efficient when testing and debugging, because issues tend to become glaringly obvious. And many developers will attest that it helps force them to write better initial code.

That said, I stick with JS and I'm perfectly happy doing so.

If you use JS to sprinkle in some jQuery style interactivity on an otherwise static website, then TypeScript is not worth it because of the additional overhead. For anything more complex and most single page applications, yes do use TS.

TS offers a better developer experience (better code completion in your IDE), types help document your code and refactoring will be less painful. Also you gain some level of type safety (though less than languages with a sound type system).

Drawbacks are slow compile times and cryptic error messages and general having a additional tool that adds complexity. Also the level of type safety is dependent on how disciplined you are (though some linting rules might help).

There are languages with much better type systems and faster compile times that transpile to JS that might also be worth noting like Elm, ReScript, Purescript and so on but TS has of course the best migration story with the "just JS but with types" promise.

So generally, yes learn it, use it.

100% yes. As someone who did JavaScript only for a while, once you make the switch, you’ll never want to go back.

The things you’ll get: 1. It’s going to force you to think more about how you structure your program. You’ll probably end up with a cleaner design. 2. It’s going to make you code faster because of the awesome autocomplete functionality you get out of the box (at least with VSCode). 3. It’s going to give you much more confidence that your code won’t break at runtime. There’s still a chance it will (write unit tests), but it’ll be much less frequent. 4. Types are a kind of documentation, so your future self will thank you.

Just to add an aspect that I haven't seen so far.

TypeScript makes your interfaces and their documentation much more explicit than with vanilla JS. If you work on your code in a team, you actually want to very clearly document the inputs and outputs of your functions and the types of your data structures. Doing this with JSDocs is cumbersome and error prone in my experience and actually more work than just using TypeScript.

Having explicit types with TypeScript helps both machines (better / safer refactoring) and the humans to reason about the code.

So the bit of extra effort to add the types is very well invested. And keep in mind that developers spend much more time reading code than writing it.

Typescript isn’t to make your code run faster- it’s to make it faster to write your code, especially in a team environment. It’s super nice to know what types that function your coworker wrote will accept, or what is in that struct. It’s really just a tool to boost programmer confidence, and a must-have for any large new project IMO.

> But I don't understand how adding types will suddenly make frontend coding more efficient.

It won't. The runtime is not affected. All it does is add meta-data to your program so static analysis gets more information about what your code is doing AKA catch type errors.

Type errors in frontend code are typically rare in comparison to state, timing and synchronization errors for example.

Learning the basics of TS is easy if you know any other typed language. However some of the concepts are fairly "unique" to TS or rather unusual in other typed languages.

Studying TS won't hurt you, you can read more code and interact better in TS codebases. However, if you plan on actually using it I very much recommend you just pick a useful subset of the features. It is already a fairly bloated language which can distract you from doing stuff that matters.

Static typing reports certain classes of error in your program at compile (aka "transpile") time. This reduces the number of tests you need to write and gives you more confidence about the correctness of your code than is possible with dynamic typing.

The alternative is finding out some time later (possibly in production) that your function that had always been assuming the arguments were non-null strings suddenly generates an error when it gets passed in null or a number or object or similar.

TypeScript is a huge productivity boost for JavaScript programmers (and similarly mypy for Python). There's no way I'd be happy working with either language without these tools. TypeScript is also useful on the backend, if you're using Node.

Others will talk about the benefits, so let me give you a few gotchas from us:

1. It does not replace type checks at runtime (in integration layers)

2. Compilation and startup (in backend land) is slow

3. Some tooling seemingly caches (webpack? ts-node?), we regularly run into situations where rebuilding locally works but then building for prod fails with type errors

The payoff is reduced cognitive load. Essentially you’re offloading a bunch of it to the type system at the cost of type annotations. A simple example:

    const add = (a, b) => a+b

can do quite a few surprising things depending on the types of a and b.

Whereas how this will behave:

    const add = (a: number, b: number) => a+b

is far easier to keep in your head. Multiply that effect by 100k lines and the TypeScript program becomes a lot more fun to build on because you get to spend less time thinking about edge cases.

Over the last couple years I've worked at a F500 company with no TS and a startup which auto generated TS types (so i.e. 100% TS) and guess which company moved faster? The F500 you literally had to get on multiple meetings across multiple teams just to figure out what values something might be. It took months to onboard new engineers and the bus factor was insanely high.

Once you've worked in a codebase with consistent TS usage, it's very, very painful to go back to vanilla JS, so imo yes, TS is worth the investment.

Yes, absolutely, 100%.

I wrote a post a couple years ago describing my journey learning and using TS, with a set of takeaways at the end:

https://blog.isquaredsoftware.com/2019/11/blogged-answers-le...

I said then that "I refuse to write any more app code that isn't TS", and that's even more true today.

TS is not perfect. It does add overhead. But, it adds a huge amount of value and safety to your app. The goal is to use it pragmatically, such that Value > Overhead.

*edit*

I'll add a bit of additional context here based on my experiences since then.

Typing application code is usually relatively straightforward. I'll use React and Redux as an example, because that's A) what I use at work, and B) I maintain Redux.

Per our Redux TS Quick Start page [0], you'd start with a few lines to infer the TS types of `RootState` and `AppDispatch` from the store, and create pre-typed React-Redux hooks (which are _much_ easier to type than the legacy `connect` API) to save from repeating those types in components. For each slice reducer, you'd add a TS type for the slice's state, and declare the type of each action's contents as `action: PayloadAction`, etc. For React components, add a type declaration for the props of each component, and add types to function arguments as necessary (change handlers, etc). The React TypeScript CheatSheet [1] is a fantastic resource for learning how to use TS + React together. Also be sure to type any data coming into the system, such as API responses, and any other "business logic" you might have.

Those should get you 80%-ish types coverage without too much effort, and all you really need to know is how to declare types for objects+primitives, and a few bits from the React and Redux lib types.

I also strongly disagree with many of the "recommended" TS-related linting rules, like "always declare a return type for every function". It's not _wrong_ to have those, but in my experience TS works best when you can let the compiler infer as much as possible.

I still firmly believe that for _app_ development, it's not worth spending hours and hours arguing with the compiler to come up with a "perfect 100% correct" type definition for more complicated scenarios. If you know that a function takes `TypeA` as an input and returns a `TypeB`, but there's really complex transformations inside and it's really hard to convince the compiler what you're doing is correct, feel free to do whatever `as` casting or `// @ts-ignore` you need to in the middle.

Library types, on the other hand, are the opposite case. Library APIs are often highly generic in both the "use case" and "TS types" senses. There, it _is_ worth spending the time to come up with very complex typedefs with tons of generics and conditional types, because those are often needed to make the _end user experience_ a lot easier. Try looking at the types for Redux Toolkit, React-Redux, or Reselect [2] [3] [4] - our types are complex, so _your_ code doesn't have to be.

I spent a ton of time just yesterday trying to make improvements to the Reselect types, because as a maintainer I want our users to have a good experience. But for you as an app dev, it should be a lot simpler. The payoff is that you get all the nice benefits of TS: static detection of common errors like typos and mismatched fields, documentation of your data structures, intellisense, confidence in refactoring, less need to write repetitive "is this argument the right type?" logic, and much more.

[0] https://redux.js.org/tutorials/typescript-quick-start

[1] https://react-typescript-cheatsheet.netlify.app/

[2] https://github.com/reduxjs/redux-toolkit/blob/v1.6.2/package...

[3] https://github.com/reduxjs/react-redux/blob/v8.0.0-alpha.1/s...

[4] https://github.com/reduxjs/reselect/blob/v4.1.2/src/index.ts...

The "pros" of Typescript are basically the same as using a typed language.

* If you don't know a typed language - learn one. TS is probably the easiest place to start.

* If you know a typed language, TS is just going to be a different flavor of that.

If you intend to work with anything front end or node related the 100% yes. I was skeptical at first, but would say I am fully converted.

The tipping point for me was when I tried to implement an order book (finance data structure) in typescript, and got it running pretty much on the first run. In the past, I would always screw up one of the structures, such as forgetting to pass an argument, or a field, or something similar.

The type system is powerful, but gives you escape hatches such as "any" which is useful when you run up against eg. interacting with the DOM where these things can get quite annoying.

Typescript doesn't necessarily make your code any more stable than equivalent vanilla JavaScript that validates function arguments properly. However, it does make the code more terse and the types more apparent. It adds some build time complexity and also requires (depending on how you configure it) that you define types for every little thing (e.g. argument objects passed into functions). In IDEs, you tend to get better autocomplete on Typescript than JavaScript. That said, I still prefer JavaScript.

Think of TypeScript as writing JavaScript with inline tests: It takes longer but it produces "safer" code (with fewer bugs)

Is it worth learning it? I'm sure type-less job offers will continue to exists in large numbers, so if you don't like it then don't study it.

Note: TS is generally not referred to as "testing", this is just my simplification. I've been using TS for years for everything and it has avoided a lot of bugs — which is something I notice when porting projects to TS.

It's probably worth it. I always use Typescript with React projects, as typing your props will make things a lot clearer. If you're using VSCode, the intellisense is very useful.

However, if you're just making a node CLI or writing a small Lambda or something, Typescript is probably not worth it. I don't believe you need Typescript with absolutely every project, but for the more complex frontend projects it will end up saving a lot of time.

I don't think there is much of a learning curve, so might as well learn it.

I think I 'learned it' because that's just what you did to use the catastrophe known as Angular.

I thought we might have the chance to move from a javascript to a typescript world, but it seems it never quite fully caught on. Maybe everyone is still just trying to figure out how to get rid of javascript, or get rid of node, or support typescript in the browser, or...

Heck yeah. I write a lot of Node and a decent bit of frontend-du-jour, and at this point, TypeScript is a requirement--not using it is a bug, on systems I touch.

"More efficient"? It's this: I make fewer mistakes. The tools are better equipped to help me by pointing out earlier when I've done something wrong because my types are detailed and specific. It also means I take a minute to think my problems through up front (both in terms of object typing and in terms of necessary function arguments) before I start whaling away at logic that may or may not actually reflect what those things are by the time I've got it sketched out.

Think of your data first, then the logic that describes the interrelation of your data, and things like TypeScript become a gimme. (And you'll learn lessons you can take forward with you to other environments, too.)

You use TypeScript with intellisense to tell you the types and shapes of variables/objects. It prevents you from accidentally, say, assigning a number to a variable that was previously a string. It prevents you from assigning a prop to an object in the wrong place.

That's all it is, and it works.

If you are writing code by yourself and your code base is relatively small, then I agree it's hard to see the benefits at first.

If your team and code base grows, one of the first things you'll notice is a lot of time wasted trying to figure out what parameter types a method takes. If you can imagine, a new person onboarding on your code base and having to figure this out constantly and then forgetting, is pretty inefficient.

TypeScript solves that problem since you declare types explicitly in code. The new person will know exactly the parameter types, the IDE can support you more intelligently, and you'll get upfront compile time errors.

The downside is the initial setup and the extra effort of declaring types, so it comes with a cost, but personally I think the benefit outweighs the cost.

Neither JS nor TS is my 'main language', but one big advantage of using Typescript I noticed immediately is that editors can provide much more Intellisense information while typing and immediately show error squiggles if a function call parameter isn't what the API expects (same as in any other statically typed language of course, but for writing 'web code' I thought that's a pretty big deal). This probably also works with WebIDL for regular JS APIs (as I said, JS is not my main language), but in TS this just works automatically also for your own APIs.

Typescript is for big code bases and big teams.

The smaller your project, the more pointless typescript will feel. Working alone on a small project, it’s a LOT of extra stuff on the screen to avoid a very specific kind of bug.

Does anyone have suggestions or experience moving a fairly large JS codebase to TS? There are libraries that will auto generate TS code but not sure what the pluses and minuses are when doing that on a live, shared codebase.

We asked ourselves the exact question and 75% of the team is in favor of moving to TS, so this thread is great validation!

There's not much to learn at first! That's what `any` is for. You can scale up your learnings over time. It's one of the amazing benefits of the language, that there's no difficult on-ramp to start using it now. Just flipping it on will give you so much without even adding complex types.

Keep in mind TypeScript is just types, an added compile step, and branding.

The ECMAScript spec will probably supersede TypeScript in the near future anyway. This has happened historically with other dead Javascript dialects (example: when classes were included in ES6).

Yes. It's a tool that helps you. It has its quirks, just like any language, but they are outweighed by the benefits.

I was hesitant at first too, but I am sold on it now. Most libraries provide types too, so the entire JS ecosystem has basically adopted it as well.

It depends on your motivation. If you want to actually work with TS, then of course learn TS. If you want to improve how you think about types in a more general sense (which is definitely a wise investment), then I'd learn Elm instead.

I just recently finished my job search and a *lot* of the startups I interviewed at were using typescript. So if you want to do frontend work at unicorn startups I suggest you get experience with that.

From my experience it is an absolute no-brainer. If you have used any typed language before I would say you can get productive in about an hour.

If it is good for your career, then it is worth the investment. Whether the tech in question makes sense or not is pretty much irrelevant.

I've found that the only real downside to typescript is that you are adding yet another layer on your at times unstable JavaScript environment.

Depends, yes, no. It's mostly for people using VS Code to have auto-completion and errors on null values

I don't like it.

Yup.