[netcraft]

offtopic, but I'm in the middle of trying to convince my small team to pick up typescript for a new significant node backend for our company. It seems like a no-brainer from my perspective. Compilation is fast, we would use `strict` but would allow devs to default to `any` if the types got too hard. There are no downsides but so many upsides - better refactoring, intellisense, documentation, communication of interfaces, protection against the javascript and library minefields. Glad to see there are lots of other people thinking this is valuable - wish I could figure out the right way to convince my team.

[swatcoder]

If you have influence over these kinds of decisions, then I expect have the experience to know that every choice has downsides.

If you haven't found any yet, that should be a Big Red Flag to you. It means you've let yourself get blinded by hype. The good news is that you're part of a team, and your team will probably be able to point some out to you.

Listen to them.

Once you've finally gotten yourself a sense of both the upsides and downsides, and have considered the latter seriously, work with your team to make a decision together. Then try to let yourself buy into whatever decision gets made!

There are definite benefits to TypeScript, but remember that no change comes for free!

[netcraft]

I responded to someone else saying this, but I guess it bears repeating. I'm not saying its a free lunch - it is a build step - there are things to learn - some of the more esoteric types can be very hard to understand. I exaggerated when I said there was no downsides, what I mean to say is that in the cost benefit analysis as I see it so far, the benefits massively outweigh the costs. I've written a fair bit of TS so far and I find it hard to imagine writing a significant side code base without it in JS-land.

I'm not blinded by the hype, im here asking people for what they see as the downsides, the reasons they may have or have heard of why teams didn't pick TS (or better yet did and had some reason it didn't work out).

[brylie]

For what it's worth, your grandparent comment didn't ask any questions, particularly about potential downsides of migrating to TypeScript. Perhaps there is a different comment where you asjed such questions?

In any case, happy coding

[jasonkillian]

There are _some_ downsides:

* Slightly more complex build workflows

* Integrating with non-TypeScript libraries can be difficult depending on the quality of external typings available

* Error messages can at times be slightly obtuse (especially depending upon the complexity of types used)

* Learning curve of TypeScript (Certain language features can be a bit complex. For example, mapped/conditional types might seem tough for a beginner. See here for an example[0])

That said, to me, it's still a no-brainer to use TypeScript for anything beyond the most trivial of apps. The advantages it gives you have heavily outweighed the disadvantages in my experience so far.

[0]: https://github.com/piotrwitek/utility-types/blob/532fe5cfcc5...

[akiselev]

My favorite is [1]. The downstream errors that type generates are "fun."

"Slightly obtuse" is an understatement when dealing with `Pick` and the errors the complimenting mapped types generate. Once you throw in React and higher order components, you can get errors that are literally several console pages long - although that's usually just tsc "tracing" the error through the complex types.

[1] https://github.com/piotrwitek/utility-types/blob/532fe5cfcc5...

[jasonkillian]

Yes, your experience mirrors mine completely. It's quite difficult to get complex higher-order components working correctly, especially if you're throwing in things like defaultProps and propTypes. For example, some issues I've hit recently: [0][1].

I think this is likely an artifact though of how powerful TS's type system is. I'm sure there're error-readability improvements possible, but with such complex type constructs, it's not all together surprising to me that the error messages can be difficult.

My worry with these challenges is not that they make TS unworthwhile (it's still completely worth it), but they do make it a little harder to convince a team to adapt TS and sell TS to React developers who are use to working in JS.

I know the TS team has React support as a priority and they've done a pretty great job of making TS React-friendly. I do wish they'd be slightly more hands on with maintaining `@types/react` and even publishing documentation, but perhaps it's fine to leave that to the community.

For those struggling with React typings, https://github.com/piotrwitek/react-redux-typescript-guide is my current favorite resource.

[0]: https://github.com/Microsoft/TypeScript/issues/27484 [1]: https://github.com/DefinitelyTyped/DefinitelyTyped/issues/28...

[bjz_]

I always found react-redux's connect function maddeningly hard to understand, because it does far too many things all in one function. The types just expose that complexity, and make it plainly obvious that it should be split apart.

The great thing about types is that the make you think more about keeping you APIs nice and clean on a semantic level, not just about if the syntax in your examples look pretty. I really hope more library authors use them early on so they avoid such mistakes in the future. There's only so much the Flow and TypeScript devs can do to make up for those existing problems.

[WorldMaker]

Which gets to my wish that instead it is the React team themselves that adopt and maintain @types/react more directly, rather than leaving it to the community and/or Typescript devs. Seeing CRA add default support for Typescript transpilation with easy opt-in for type checking, is a great sign that plenty more React developers are going to have a chance at Typescript. Hopefully it becomes more of a two-way street where the Typescript community isn't just typing major React libraries after the fact, but more of the libraries are directly written in Typescript or at least the types are directly maintained by the authors of the APIs.

[testvox]

They have been working on the error UX for the last 2 releases and still have some things planned https://github.com/Microsoft/TypeScript/issues/26077

[woutr_be]

I recently updated our small node backend to Typescript and it's absolutely great to work with. Even backend people who come from strict languages Scala / Kotlin / Java, are now able to use and understand this.

I've been doing the same thing on our Angular app, but it has become clear that most of the frontend developers here lack the understanding on type safety, they're just unable to comprehend it for some reason. I've seen PRs that were just completely wrong because they couldn't understand how to do things correctly now that it's all typed. These are purely frontend people tho, they hardly work with any other language than JavaScript. But I don't consider Typescript a massive change from JavaScript, it just adds typing to it. Which any programmer should be able to comprehend.

Personally for me it has been great, it forced me to refactor really bad code, because I noticed that multiple methods kept returning different things, so the backend codebase is a lot cleaner now. Tests also have improved a lot because of all this.

Perhaps it might be worth trying to figure out how your team thinks about this, they might just be worried that they won't be able to work on it.

[qudat]

If people are not onboard with the the idea then it might be an uphill battle. There is value in TS but it will be frustrating at times, you will get resistance from other developers, and every once in awhile it will not feel worth it.

The other issue is that if people don't know what they are doing with TS, then imo it's worthless. I don't know your experience level with TS, but it is a non-trivial problem to build types such that it provides all the benefits you describe.

It is, in a lot of ways, a different language with its own set of problems to "solve."

Tread lightly, because adopting TS could be a blessing or a massive time sink for people not familiar with it.

[netcraft]

I wouldnt call myself an expert by any means, and sure there are lots of complicated types out there - but I feel we would get 90% of the benefits if all we did was 1) turn on the compiler in the first place 2) document the argument and return types of functions and 3) build some general interfaces of objects we are passing around.

If we bailed out and typed anything more complicated as `any` it would still be a huge improvement over writing vanilla js IMO.

[sibeliuss]

Yeah, there are so many crazy benefits just by naming your file `.ts` and writing vanilla JS. People can go as lightly or as deeply as they want once they understand how tsc works.

[alexnye]

I had a similar discussion with some good points in this thread.

https://users.rust-lang.org/t/what-have-been-the-drawbacks-o...

[lj3]

Who's in charge of making the decision to switch? What are his priorities? What problems is he trying to solve? How does switching to typescript help him do that better/faster/cheaper/easier?

[netcraft]

Thats the problem, I dont really have answers to those questions about his priorities/motivations/reservations yet - just that there are some. Hope to find out soon.

[natural219]

The tradeoff between flexibility and reliability in the interface engineering world is very poorly understood. There's several dozen layers of reliability abstractions you can add to your Javascript code. Each one individually is probably a smart idea; taken together, you can create an endless array of overhead to even complex Javascript apps that massively reduce flexibility and slow down the iterative process if you want to continue improving and experimenting on your UI.

[ergothus]

> There are no downsides but so many upsides

I've not used TS, but from what I've read the types from TS are not js compatible, so once you go into TS you have code that just isnt js.

(As opposed to flow, where you can just have it not be used)

While transpiling is normal, I'm as hesitant to tie myself to TS as I am to, say, a non-standard decorators syntax. Anyone coming to me with "there are no downsides" in such a case doesnt sound very credible.

Assuming I'm wrong, how would you address this?

[Zarel]

I'm not sure what you mean by "not JS compatible" here.

TypeScript obviously compiles into JavaScript, and any valid JavaScript is also "valid" compilable TypeScript (the compiler will complain, but it will still compile it into JavaScript that does the same thing). With the right assertions (and @ts-ignore where necessary), you can even get the compiler to stop complaining!

TypeScript does have some differences beyond just type annotations: namespaces and enums come to mind. But it's easy enough to just not to use those features - they're not even supported by Babel.

The main downside is that you have a compile step where you might not have had one before. And it can be frustrating to deal with situations where there's no way to "fix" an error except by suppressing it – but these are really rare. But these are relatively minor issues.

[WorldMaker]

Also, even namespaces and enums aren't that foreign, and are still "JS compatible" in that they transpile to perfectly normal JS code that you can still use quite obviously in other JS code (enums create a list of constants and sometimes a reverse lookup map; namespaces create ugly, nested, mergeable object literals and IIFEs just like Grandma jQuery used to bake back in the bad old days before module systems). From one point of view they are nothing but syntactic sugar for common JS patterns.

[netcraft]

There is a significant difference between TS and a non-standard anything. Nothing goes into typescript until it is stage 3, meaning intent to ship. There is now two compilers supporting the syntax. It is well supported.

Also, if that was a concern I would be willing to say we start out with jsdoc style types - I would much prefer the regular syntax and would like to use things like enums, but it would be a massive improvement over not having it.

In my mind, you are writing javascript with types whether you use typescript or not - using TS makes those types explicit and allow a compiler to check your work, on top of the other benefits.

I will rephrase though - instead of "there are no downsides" I'll say "Any downsides I have found are minute in comparison to the benefits", but my intent behind bringing this up in the first place is to hear from anyone else who does see more downsides than I do and to understand those.

[smt88]

You're wrong.

Once you transpile the TS, you have standardized ECMAScript. Want to stop using TS? No problem. Just delete your TS files and work from your JS files.

And, beyond that, TS is intended to be a superset -- never incompatible, just "extra".

Finally, you can use TypeScript the same way Flow is used, through comments.

Tying yourself to TS isn't really something you can do, and there's zero risk in using it. You can always throw it out later.

[h1d]

> No problem. Just delete your TS files and work from your JS files.

This is quite an irresponsible comment.

The JS code generated isn't really meant for editing especially if you used a feature that isn't present on the runtime (like async/await in browser), not to mention all the formatting is rearranged.

If you're willing to go back to JS, you want to keep the original source.

[smt88]

"Irresponsible" is a bit of an overstatement, don't you think? The TS team explicitly says their goal is to generate readable JS, unlike (for example) Clojure or Scala.

Also, the async/await thing isn't an issue if you target the latest ECMAScript version. That's the only really ugly thing, and it's been easily avoidable for over a year.

[h1d]

Readable JS doesn't mean, convert back to the file in the format you used to for editing.

That comment could make people throw away the original and end up with machine generated code when going back.

[smt88]

Have you read transpiled TS before? It's sometimes almost identical to the source. It's as close as you can get to just removing the static typing. Variables have the same names, for example.

I used to have a problem where I'd be debugging the JS instead of TS file because visually, they were almost identical.

[mattmanser]

Have you seen the code the TS compiler spits out?

You do not want to work on that. It readable to an extent, but it's definitely not pleasant.

I don't think you could just go back.

[smt88]

If you're referring to generator-style async/await, you can change that now.

Otherwise you can just prettify it and be on your way.

Sure you don't want to go back, but that's the whole reason TS exists: writing JS with good organization and discipline is impossible at worst, full of boilerplate at best.

[AgentME]

TypeScript and Flow are very similar. Compilation of both of them mainly consists of removing type annotations. TypeScript has a few extra things it adds but they're very minor and not that hard to translate into Javascript.

[olingern]

I had the advantage of working with people who had a background in typed languages, so everyone was onboard with giving Typescript a try a year ago.

The thing is, I found you have to be very diligent about how you organize your interfaces and how you might namespace them. I had some C# background, and had made a PR or two to the vscode repo -- so I had an idea of "good" code.

I think without some background in how you'll organize you types and, most importantly, types themselves you'll have some legwork in proving Typescript useful.

___

A suggestion I might have, because I found this mentally pleasing: start your project off small (get a few endpoints and some minimal database interaction). Let your co-workers look over it / maybe even do some small amount of work.

Create a typescript branch, where you convert each file to `.ts`. Typescript's compiler `tsc` can copy over all files `.js` and converted `.ts` so it's not essential you do this all at once, but I also found it not-so-painful either.

Demo this branch and show your co-workers that Typescript provides:

- A nice boost in productivity (autocomplete, hurray)

- Some confidence in how you're using types (this isn't a sound type system like flow)

- A way for people who don't have a background in javascript to feel more comfortable

[eksemplar]

Does it add value? I manage enterprise and we’ve tested typescript and found it added little value, but brought in complexity that slowed production.

Type safety isn’t worth having more complex prototypes, and having to keep up with both JS and Tyoescript, for us.

It’s very easy and forgiving to do a proof of concept though, because it integrates so easily into your existing code base.

Just be sure it actually adds real value and isn’t something you do for hype.

I’d certainly utilise it if we were building something as complex as VSC, but we aren’t, and I think it’s important to keep in mind that typescript isn’t all positive gains but that it also has downsides.

[h1d]

Not sure why you're downvoted but for me vanilla JS is like cars running without traffic lights, you know it when you crash but with TS, chance of doing something wrong, like parameters have wrong key or type, before it runs gets less especially under multiple devs.

And then, you can code with TS on the server side as well as take that approach and write with modern language features on the browser side where you still have to write in ES5 (IE11) if it isn't for transpilation and develop with 1 consistent language throughout.

[h1d]

Out of curiosity, how do you let everyone take the build process in a consistent way?

I've only used TS as a single dev but with multiple editors and they could have different version of TS from the other, I wonder what's the best way. Do you just help a guy with vim/vs code/IntelliJ/sublime/etc to set up to use auto TS compile and ask everyone to stick with a specific TS version? Or is it better to use something like Prepros to handle all the builds?

[lima]

We have the entire development environment in Kubernetes. IDE is only used for code editing, which is then synced to the cluster. Auto-generated code and node_modules are synced back for code completion.

That way, everyone has an identical dev environment and we don't depend on any particular IDE (want to use Emacs? sure). No setup steps, just running one script to create a new namespace with all applications running inside. Broke it, messed up an upgrade? Just destroy and redeploy.

We hacked Arcanist[1] to run linters in the cluster. Modified a TypeScript file? "arc lint" will make sure your TypeScript pod is up-to-date and run the linter there, etc.

We're using custom tooling which is faster than https://github.com/GoogleContainerTools/skaffold, but it's the same approach.

Thinking about open sourcing it.

[1]: Phabricator's CLI client

[h1d]

Having the build on server side seems like the way when you don't have to ask each dev to set stuff up and it will be a hassle to change environment once deployed. I also auto upload my TS to server and let the server handle it but I do wonder if there's an easy way for average shops to deploy.

It seems everyone is doing their own way of build process from local build, gulp, webpack or custom server processing and all has their downsides.

It does seem like a hurdle when this process isn't easy for everyone involved when switching to TS.

[255kb]

usually you try to stick to the Typescript version defined in dependencies. In VSCode for example you can easily switch Typescript from editor version to project dependencies version. And most of the time what we do where I work is only triggering `tsc` commands (or any other dependency command) through NPM scripts, because they use the dependency installed locally instead of any other globally installed or editor specific version.

[smt88]

TypeScript supports Flow-like type annotation in comments, which allows you to take advantage of static type-checking without transpiling.

That's as much as I know about it. I don't use that feature because transpiling is such a minor issue that I can't imagine any universe in which I would use comment-style types, which are slightly more cumbersome to use.

[kumarharsh]

That feature is for JS files. It helps you convert your JS project into flow/TS in a piecewise manner. Otherwise you'll have to do a major rewrite in a very short amount of time.

[smt88]

> Otherwise you'll have to do a major rewrite in a very short amount of time.

This just isn't true. TS was designed from the beginning to allow gradually adding types. Whether transpiling or using comments, you can change one file at a time.

[sibeliuss]

Indeed -- interop works _very_ well.

[golergka]

Strange: you're trying to convince someone, but instead of writing about their thinking and their arguments, you're writing about yours. If you want to convince another human being, shouldn't you focus on their mental picture of the problem more than on your own?

[jczhang]

why not just ask how they feel about it and try to address concerns if they come up?

[netcraft]

That will certainly happen - my intent behind this comment is to hear from other people who have looked at it and decided against it. Or devils advocates - I'd like to hear anyones reservations either to convince me its not as good as I think it is, or at least allow me to come up with a response.