How do I convince developers/companies to use TypeScript?

Is there a way you can isolate the "reasons that are well known" into "reasons that can be made to work even in non-Typescript situations"?

Or can the "reasons that are well known" be laid out for closer scrutiny and discussion?

Is it possible that there are multiple paths up the "massively improved productivity" mountain?

Any of these angles could help move the problem even further off the mark of "my subjective perceptions vs. theirs" and into the objective "our perceptions" zone through additional openness.

If this can't be done I'd guess you'd run into a lot of problems that are more psychological in nature. Generally when you say "here's a great thing," (especially if others think they have great ideas also) you get a backlash effect at the very least.

I use Typescript daily and I really enjoy working with it. I've been working with Javascript for quite a while and Typescript made my life a lot easier.

I do however (possibly controversially) find the Javascript world in general rather tiring. There are constantly new (not necessarily more advanced) ways of doing things the most basic things. For me, it's like a ZOO with loads of wild animals, frameworks, Github issues and opinionated evangelists.

Don't get me wrong here - learning new tech is great. Especially if you want to stay sharp until the old age. Nevertheless, sometimes you just want to focus on getting stuff done and not trying out a brand new invention of rendering an input field (which will work and look exactly the same to users). While Typescript is much more than that, a similar sentiment might be making your fellow devs reluctant in trying it out.

Following from the above, I'd imagine that there is some kind of a person (top-down approach: head of engineering, CTO?) that makes decisions about code standards and tech. It might be worth talking it through with them, especially if you have concrete examples how Typescript could improve productivity. That's how we got Typescript into projects at the last place where I worked.

From the perspective of the devs themselves (bottom-up approach), a good motivator might showing the momentum that Typescript has in its adoption. There is a high chance that they'll have to learn it anyway if they plan to move companies at some point which makes it a good tradeoff to start earlier. Get paid for learning kinda argument.

You seem to have made up your mind about the advantages of TypeScript. The word "evangelism" has come up several times.

I'm a fairly junior dev, but I'd like to suggest caution to anyone who might be inclined to think that a technology like TypeScript will represent a clear step forward for anyone looking to take a step into 2022 and leave Javascript behind. The "evangelist". "Organizations/decision makers who haven't adopted TypeScript yet just haven't been exposed enough/had enough misconceptions debunked, and they need to get on the same page with faster moving companies, or get left behind".

1) I don't think this is how most successful companies/orgs think. 2) It seems to me that, as is the case with literally almost every choice of technology or solution, it's a matter of tradeoffs. Pros and cons. What are the honest disadvantages of your company adopting TypeScript? What are the opportunity costs, or how much quicker could you have addressed urgent sprints if you had left the JS alone? Be honest. Will there be a learning curve? I have to imagine there would at least be some friction... I don't think writing good TypeScript is as simple as doing a 1 hour tutorial plus some fiddling, or taking out a week. The other thing to weigh against that is, companies literally never have time. There is never enough time to do everything that you want to do, especially when it comes to stuff that's probably seen as more quality of life centric. Business oriented people want and are under pressure to put out features, tangible stuff.

The sooner you come to grips with that kind of stuff, will probably be the sooner you can do a solid job of framing and selling TypeScript. Be honest about the drawbacks, and then you can give them their due, while making sure that in your pitch, the payoffs are impossible to ignore. My final piece of advice might be to be a bit more gentle in your pitch. I've definitely run into some friction with what felt to me at that time like stubborn and short-sighted decision makers. Maybe the best thing you can do is to, again, frame the pros and cons, give them a fair and even-handed lay of the land, facts only, and then let it feel like it's them that's coming to the decision to use TypeScript. Almost like Jedi mind tricks.

Here's my POV as someone who once was a big fan of TypeScript but had to learn how to live without it for a long time and is now having to jump back into TypeScript because of a project.

Extra fluff/annoying -> It only seems like it. On a sufficiently complex or wide codebase that is written in JavaScript there is going to be loads of ad-hoc types/return values. Having a compiler determine what is coming in/out helps a lot.

Dynamic type checking -> This makes it more important to make sure that any dynamic parts are contained and the results conform to something before coming back into the codebase.

As someone who feels comfortable writing plain JS coming back to TS feels hard. Things that just work in the plain JS docs for libs/frameworks don't when the auto generated types are used. An example: a lib I was using allowed almost any string but TS was only allowing strings found in the source code in thus destroying the dynamic nature shown in the docs. I could have fiddled with type signatures and overrides and the like to please TS but I ended up doing a thing that was way easier than that (at the same time having to document why). Situations like this are probably what comes to their minds.

The best way to push for TS would be show how problems/tickets could have been avoided if types had been used.

In general it sounds like you are doing what I would do (show them that it can be introduced gradually/non-disruptively, and what problems it solves).

However, you can't always do a whole lot to change a culturally embedded prejudice against certain practices/technology. The best I could really think of doing is just waiting until bugs are inevitably found, and documenting each case that could have been avoided by the compiler. If your company tracks work done, you could come to your technical leadership and say "we wasted 200 hours this quarter/year/whatever fixing TypeErrors that TS would have caught", and that _might_ move the needle. You can't change the opinion of a horde of developers by talking to them directly, but if a mandate comes to them from on high that's for their own good, that will probably at least get some of them to try it long enough to come around to the idea.

Even that idea is kind of politically risky though, so take it with a grain of salt.

What I did was to explain the advantages and disadvantages of Typescript, and document the production issues that could have been detected at the compilation time.

But the most effective for my team perhaps was enabling the checkJs option in Visual Studio Code (javascript.implicitProjectConfig.checkJs). It enables type checking on JavaScript files using The typescript compiler. Even though the files are not typescript and you don’t have a typescript project, it does find a lot of issues. The developers started to use this feature more using type annotations in JavaScript using JSDoc comments. At this point the migration to typescript was approved by everyone.

The best way that I've found to introduce new things in in new areas. Any new project, even if it works in an existing repo has the opportunity to make their own rules to a certain extent. If you can have your new ways for the new project parts that co-exists with the existing codebase, then we use and wait. Eventually people will want to use the new way in older parts too after experiencing the benefits.

I think the most common one is people using TypeScript with Vue or React. If there's another popular framework that has the use of TypeScript as the default, that would also have a good chance of adoption.

A lot of what is said here is true, but it also depends on what your position is within the organisation - if you are senior (or a peer) and have the respect of your colleagues then you can look at running a training session, followed by writing a piece of an application/a sprint using TS so that they can familiarise themselves with the reasons why it is better.

Which is really the second part of this - you need to spell out why typescript will make their life easier/better. If you can't do that succinctly then it is unlikely that you will be able to convince them.

JavaScript is Typescript except you need to do the compilation in your head!

You are always checking types anyway, so you should use TS and let the computer do that for you. There is literally zero extra work for using typescript beyond initial installation because it’s just offloading a mental requirement to the computer and the computer is much better and faster at it.

Adopting technologies within an org is a social and economic problem, that's why we have salespeople to convince orgs to do it.

You don't need to convince individual developers or groups of them to adopt it, what you need to do is convince a decision maker that it's worth it for a project and to deliver on it, or become that decision maker.

People in general tend to choose whatever is easier in front of them.

You could convert some simple work files and showcase the benefit on how it’ll be better than JS. Show them how the “extra fluff” will benefit them in a context witch everyone is familiar with.

Make it not be from Microsoft.

I thought about and wrote down my own case for it - if I did it now I'd stress how so many leading orgs are moving to TypeScript as peer pressure. Don't want to be left behind do you?

It's a dev dependency, so maybe you can get the thumbs up to use it on a small piece of the code base as a pilot?