Ask HN: Is it worth it to invest in learning TypeScript?

Seconded. But with an asterisk - I've found, as I've learned more and written more TypeScript, that I write significantly less object-oriented code overall. I use a lot more interfaces and a lot more types, and I use runtypes to describe domain objects (to combine runtime validation and static typing).

Classes are still useful, of course, as encapsulations of state, but I don't remember the last time I wrote something polymorphic in TypeScript that didn't feel faintly wrong. Coming from a Java/C# background, the "easy path" in TypeScript feels to me like it nudges you more towards compositional architecture (which is a good thing!).

cardanome 4y

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.

aecorredor 4y

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.

Fannon 4y

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.

MH15 4y

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.

miohtama 4y

Just to nitpick: it is to boost team programming efficiency, not confidence. TypeScript acts as a tool to force programmers to better communicate the intent of the code, so that other programmers do not guess the intent incorrectly and write bugs. Especially when there a change to old code that may cause regression. Because the compiler catches these situations, regression does not happen and programmers save a lot of time by avoiding unnecessary bug hunting trips.

MH15 4y

Fair enough- when I say “confidence” above I mean “I’m confident this function is the correct one and has the parameters I think it does”

dgb23 4y

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.

This is true, especially for experienced coders, it's not very common for you to mix up types. Especially if your code is well written; high cohesion, loose coupling. Loose coupling means that you have simple interfaces which accept simple types (e.g. strings, numbers, raw objects without internal state or methods). Simple interfaces make it easy to figure out what arguments to pass to a function... This means you don't rely so much on a type checker.

What I don't like about statically typed languages is that they seem to encourage developers to define methods which accept complex arguments of type such as 'InputController' or 'Logger' or other complex 'live instances' which makes the function interfaces more complex and encourages violation of the separation of concerns principle.

For example, instead of passing a Logger to a component, why not just make the component an EventEmitter (or similar) and it can emit/trigger an 'error' or 'warning' event on itself when it encounters an error... Then this event can be handled and logged at a higher layer in the code. High cohesion means that components should only concern themselves with one thing; if a component also has to handle its own logging, that's already 2 things... IMO, statically typed languages often encourage such types of tight coupling, low cohesion anti-patterns. Just look at what happened to Java. You need to read 5 pages of documentation to get anything done because the interfaces are so complex and rigid. It almost forces developers into anti-patterns.

> Type errors in frontend code are typically rare in comparison to state

I find that this isn't true as soon as you weld Redux, MobX, or any other distributed-logic, central-state mechanism into an application.

If you can avoid that, maybe it's superfluous.

I would not write any new code in plain JavaScript today, though.

peterkelly 4y

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.

But the node core devs have moved on to deno. They also recently ripped out their TS code. Skate to where the puck will be.

cygned 4y

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

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

1. You can deal with this with stuff like io-ts or runtypes. I strongly recommend either, though I use runtypes myself. Defining your objects in runtypes and having it implicitly return types for use elsewhere in your application is awesome, and it even works with branded types.

2. Yes and no. It's not the fastest build out there but if you've enabled incremental builds it's quite quick unless you're touching heavily related-to code (libraries that are imported all over the place). If that's not fast enough for you, I've seen people having very good success with `swc`.

3. I can't speak to webpack, but ts-node shouldn't be caching anything last I looked at it.

wereHamster 4y

2. esbuild has support for TS (it strips the type annotations out during build), and is plenty fast (compared to webpack, rollup etc). So bundling itself should never be an issue. The other aspect is type checking. If you want TS to type check your project, then yes it takes a bit of time. But that's no different than running tests. Of course running those will take some time. Once the project is bundled, the startup time should not be affected at all, it's all JS anyways.

scanr 4y

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.

notsrg 4y

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.

acemarke 4y

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:

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<string>`, 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...

xfitm3 4y

I'm interested to hear folks prediction on the future of the language.

As a greyhair I've seen many languages come and go. I don't want to sound pessimistic but the idea of trading one set of problems for another isn't novel.

I am of the opinion that all roads ultimately lead back to the fundamentals.

If we're wild-assed guessing, mine is that TypeScript eventually merges with JavaScript. It is a wisely designed set of optional type constraints that aren't incompatible with JS proper. Seeing as how every conformant TypeScript compiler is also a conformant JavaScript compilers, the split is pretty small and eating one's vegetables is good for you.

(With one nit: TypeScript enums are weird and while they work in JavaScript ways they are weird and might be best off being rethought, even if it's backwards-incompatible.)

If TypeScript becomes natively interpreted (instead of transpiled), I might actually consider using it for my personal projects. In the meantime, I don't use it because I cannot stand the build, bundling step and the problematic debugging experience with source mapping (and difficulty to debug production errors where source maps are not available). If you write code correctly with loose coupling and good tests, static typing only provides marginal benefits.

Your last sentence is writing a very large check that I'm not confident at all you can cash.

Static typing obviates most runtime type checking, which your module boundaries need to be doing (and exercising in tests). Libraries like runtypes deal with the last mile of it by generating runtime type guards that also project back into the static type system. This removes the need for entire classes of tests, as well as many of those handling intra-module transforms. It's telling that the people doing some of the best work in, say, Ruby are in on both tooling like Sorbet and libraries like dry-types/dry-struct -- because the benefits are significant in terms of minimizing engineering risk.

Static typing is also standardized and machine-readable documentation. This can't be understated. Human-written documentation rots with changes. The guarantees at module level from your static types does not.

Particularly when gradually introduced, these are significant force multipliers. If you want to take on the additional risk for your toy projects, more power to you (I sometimes write Ruby when doing something that doesn't matter) but I certainly find those benefits significantly more than "marginal" if anyone else ever has to deal with my code--including future-me.

> Static typing obviates most runtime type checking, which your module boundaries need to be doing

I've heard this argument many times but it's misleading. Well written functional tests will be able to identify type mismatches implicitly. For example if you add 10 + "1", you will get "101" - The test will fail. You don't need to check if the result is a string, you just need the assertion to expect the number 11. Tests will catch type mismatches implicitly. In practice, this applies to pretty much every kind of type mismatch. Type mismatches break functionality; so if the functionality is well tested, then type mismatches will be caught implicitly.

Thats weird, the best ppl in JS seem to be tearing TS out due to compile time/toolchain perf problems.

Do you have any large typescript projects?

I personally hate everything about the transpilation step; the time it takes (slows down dev-test iteration by a lot), the source mapping aspect, debugging in a live production environment (I hate having to debug transpiled/mangled JavaScript). I hate having to handle multiple permutations of engine versions (too many possible permutations of tsc and node.js version numbers which introduces configuration and setup difficulties; it rarely works out of the box; it's a nightmare for open source projects when you're potentially dealing with a broad range of different operating systems and environments which you have 0 control over; maybe the user needs tsc version x.x.x for some different reason and you cannot force version y.y.y onto them!!! So their tsc version will not work with your tsconfig)... It just adds a ton of bloat, dependencies (security/maintenance burden), setup/compatibility problems and the value it adds is marginal.

I think Typescript is here to stay, way more than Coffeescript was. On the other hand, I wonder if there's not a missed opportunity by compiling TS to JS. You lose all the type information that could be used to optimize the code.

How so? Coffeescript was mostly absorbed by JS, a true success story. The cutting edge JS ppl are moving away from TS right now, at least some of the ones I follow on twitter seem to be over it. OP might be on to something, not wanting to waste time chasing trend n-1

Intertia. TS is way more popular than Coffeescript ever was, so there will be more code to maintain, and the network effect applies here.

The cutting edge JS ppl are moving away from TS right now, at least some of the ones I follow on twitter seem to be over it.

Who are these people, why are they moving away from it?

OP might be on to something, not wanting to waste time chasing trend n-1

If you need static typing for JS now, TS is your best bet. You can also wait N years for TC-39 to add it but so far nothing has been proposed.

It seems to me that there is a divide of angular typescript apps that are about 3-5 years old and a new wave of react flow apps. Wonder what the stats are.

That might be just my bubble, but I've never heard of anyone using Flow, especially with React, whereas I often hear about React with TypeScript.

mcphage 4y

The cutting edge JS ppl are moving away from TS right now, at least some of the ones I follow on twitter seem to be over it.

What do you see them moving to?

Linky: https://www.google.com/amp/s/startfunction.com/deno-will-sto...

This is just a Deno-specific internal thing due to tsc being too slow for their specific case. Deno itself can read and execute TS code and they aren't planning on dropping that.

Right, they just wouldn’t use it themselves.

In the original design doc: https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS...

Update June 10 2020: I saw that this design doc was being discussed more widely. Most people don't have the context to understand this narrow technical document - it is only applicable to a very particular, very technical situation in the internals of Deno. This is not at all a reflection on the usefulness of TypeScript in general. It's not a discussion about any publicly visible interface in Deno. Deno, of course, will support TypeScript forever. A website or server written in TypeScript is a very very different type of program than Deno - maybe much more so than novice programmers can appreciate - little of Deno is written in TypeScript. The target audience is the 5 to 10 people who work on this particular internal system. Please don't draw any broader conclusions.

frosted-flakes 4y

TypeScript and JavaScript are the same language, and JS is definitely not going anywhere.

SkyPuncher 4y

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.

is0tope 4y

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.

hliyan 4y

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.

nayuki 4y

vanilla JavaScript that validates function arguments properly

Validating perfectly at run time is exceedingly difficult and tedious. Does anyone actually write defensive code like this?:

    function sum(arr) {
      if (!Array.isArray(arr))
        throw "Invalid type";
      let result = 0;
      for (const val of arr) {
        if (typeof val != "number")
          throw "Invalid type";
        result += val;
      }
      return result;
    }

By contrast, the TypeScript code is reasonable:

    function sum(arr: Array<number>) {
      let result: number = 0;
      for (const val of arr)
        result += val;
      return result;
    }

> it does make the code more terse

No, TypeScript code with explicit type annotations is less terse than the typical unsafe JavaScript code that lacks type checks.

It requires that you define types for every little thing

No, the TypeScript compiler has type inference. It can assign types based on how values are passed between known functions. While it's a good idea to explicitly type all function signatures in TypeScript, it's not mandatory unlike Rust.

cygned 4y

The thing is, though, that Typescript is not solving runtime type checks. Typescript is declarative, it does not check at runtime and if you have any code interacting with third-party data sources and you do not check there, things will explode down the line.

zkldi 4y

You would have to check your third party data sources anyway? I fail to see how this is a knock against typescript.

Setting the type of unknown data to `unknown` forces you to validate it.

nayuki 4y

I half agree with your response. It's true that third-party data sources need to be validated using runtime type checks, whether in explicit custom code or through some schema validator framework. But TypeScript is very helpful in the common case where the caller is fully typed, so the callee doesn't need to do all the needless defensive checking.

crate_barre 4y

Oddly enough, Typescript would be more useful if the type checks transpire to explicit defensive code. Otherwise, it’s just, eh.

wdfx 4y

Additionally, TS allows the team to be more confident in refactoring, or updating dependency versions, where the interfaces and argument types may change (because obviously, semver is not ubiquitous, and also not fool proof).

The incompatible changes are more likely caught at compile time, and far less likely to become apparent only when deployed.

That said, also TS itself is not fool proof - there are times where the config in use (strict vs. non strict null checks) and other factors (e.g. de-serialising JSON) can mean that your data does not in fact match the expected types.

rudian 4y

Typescript doesn't necessarily make your code any more stable than equivalent vanilla JavaScript that validates function arguments properly

You're confusing runtime checks with compile time checks. If you mess types while developing, you will know instantly with TypeScript but you'll find out during testing with JavaScript (or in production)

friedman23 4y

Typescript doesn't necessarily make your code any more stable than equivalent vanilla JavaScript that validates function arguments properly

I don't agree. 99% of javascript/typescript programs will be dealing with data that is potentially null and without strict compile time type checking that typescript affords writing correct javascript programs is almost impossible.

without strict compile time type checking that typescript affords writing correct javascript programs is almost impossible.

It's tedious but it's far from impossible.

friedman23 4y

Without an automated system telling you where to add checks for possible undefined values I think it's actually impossible in practice.

I think it is very possible. There's a simple technique for that: check everything, all the time. As I said, it's tedious but it's far from impossible. You can probably optimise it by checking less things in practice.

fregante 4y

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.

65 4y

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 find building Node CLIs to be a lot easier and less error-prone if you use `clime` or `oclif`. You can use `oclif` with raw JS, but it's kind of nasty compared to TypeScript.

readonthegoapp 4y

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.)

prohobo 4y

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.

makstaks 4y

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.

IMO every project should be kept as small as possible. Large code bases are anti-patterns. It's almost always desirable to break up functionality into independent modules. If the modules are sufficiently independent (loose coupling), then you won't get into situations such that you constantly need to modify them... Properly designed modules don't need to be changed often. In my own projects, there are many modules which I haven't modified in several years.

"TypeScript is useful for large code bases" is like saying that a truck is useful for carrying boulders up a mountain... Sure it does, but what if you don't actually need to carry boulders up the mountain to begin with?

makstaks 4y

Maybe then question then is how does one get every developer to design and build modules as you have prescribed? (Recognizing different talent levels across the industry / delivery deadlines). Genuinely curious to know a scalable solution for this.

edit: typo

Agree with this. Ppl can make a mess inside their typesystem specs esp. when making their code interface with others on a large project. Adhoc types that are just bloat. Etc.

Has anyone else had multiple years of experience with typescript in prod or what?

TBH, I feel like the TypeScript movement is driven mostly by junior developers. The software industry has always been like this; young, loud-mouthed junior devs come in thinking that they know better than all the senior people... They ridicule their elders who have an actual proven track record; they then proceed to push their naive ideas on the entire industry... 10 years later they (sometimes) realize how dumb they were (yes, I've been there myself) but by that point, the next, bigger batch of loud junior devs enter the workplace with even dumber ideas and drown out all the wisdom yet again... Again, the juniors with big egos, fresh out of MIT, think they know better than all the old dinosaurs and they perpetually keep destroying every chance of actually moving the industry forward... The cycle repeats over and over.