How does removing typescript help you?
https://github.com/microsoft/TypeScript/issues
Please count the number of open bugs
JS tooling is already an enormous jenga tower as it is, with tooling breakages eating a double digit of developer time. Adding typescript on top of that would be the real madness.
Typescript will not help us a dime with type checking for most of devs we hire are long past the stage when typing errors are a thing for them.
On the down side, even certainly not cheap to hire devs with 6-7-8-10+ years of experience have to battle JS tooling every day.
Like half of all genuine bug triage time is already spent on webpack, bable, and other things in the tooling stack. 200 hours a month for $30-$40 per hour devs.
Imagine doubling that digit when they have to also spend time on learning typescript, and fixing it.
No, it does not pay off at all
You realize you're probably creating bugs yourself by removing typescript manually, which is a thing.. typescript itself can do, by compiling down to JS?
This is some prime dailywtf material.
Nothing was said about whether typescript code is more or less buggy, just that the typescript tooling had issue to work with other tooling.
Who are these mythical people?
Do they just magically decipher what interface an argument conforms to? What methods are accessible on a returned result from any random library they're using?
I see TypesScript as a VERY opinionated linter that affects how you think and write JS. JS is a dynamically typed language, which means you loose a lot of its power and flexability by shoe-horning it into strongly typed languange patterns. Yes, I get it, many programmers think best and are most productive using strongly typed languages, but for those of us that can think dynamic or both, TS just gets in the way.
>> Do they just magically decipher what interface an argument conforms to?
This is a good example of the object oriented, strongly typed way of thinking. Explore languages that follow different paradigms, where interfaces just don't apply.
>> What methods are accessible on a returned result from any random library they're using?
Do not use random libraries. A good library should have even some basic docs outline its API and how to use it.
If you held a gun to my head and forced me to recklessly provide conjecture on what the difference is, I would say that static languages encourage devs to build large interfaces that take tons of options and pass around a bunch of parameters. This is highly, highly subjective, but:
I think there's a grain of truth in what other people are saying about how Typescript projects tend to be kind of verbose. People start reaching for interfaces that are split across multiple files, people start reaching for classes. When you have really rigid types that need to be formally extended all over the place, this also encourages a lot of casting, which tends to be error prone.
I've seen some really complicated logic/type flows in Typescript that would be extremely error prone in Javascript, but there's basically no reason for them to be that complicated in the first place. There are paradigms in Javascript the codebases are not taking advantage of which are forcing them into these over-complicated logic/data flows. Basically, the more crazy boilerplate, casting, and giant interfaces that a codebase has, the more type errors will occur. The more a project is split up into dozens of dependencies and modules and whatever, the harder it is to reason about what a method or class needs passed in. But Typescript projects tend to grow in that direction very quickly, so the need for Typescript tends to become a self-fulfilling prophecy.
As a comparison, most of the personal projects I work on don't have classes at all, they're using a lot of functional interfaces, and they don't include a bunch of random libraries. Most of the dependencies in my projects are libraries that I've personally vetted. Most of my projects are careful about where state is being stored and how its being passed around.
I dunno. All of that is pure conjecture, but people in general are very dismissive of dynamic typing, but it's just not a real problem for me. There's a general consensus that dynamic languages were a mistake, and I don't dismiss the people saying this, but I also pay a lot of attention to where bugs are coming from in my own code, and I can't get past the point that typing really doesn't seem to matter that much in most things I build.
I was on the Typescript train for a while. I still use it in some projects, there are some org structures where it makes a lot of sense. If I'm working with a Java-to-Javascript dev, I want strong interfaces for them. The projects where I don't use it are because I've spent a long time paying attention to where my bugs are coming from. I can't prove to you its not a problem, I can only speak to the experiences I've had.
TS tooling either replaces JS tooling or interacts with it seamlessly. It's not like you're skipping JS altogether and there's no type-checking in JS anyway so where's the interference?
Can you give a concrete example where TS is a blocking issue for your development?
People who spent time with JS and webdev in general got to learn that JS is a minefield of a language, and they work with that in mind. Typing discipline is pretty much the first thing people learn when they try doing JS seriously.
How to say. There is no way just adding typing to JS will make JS less of a JS. You still have to be a very disciplined dev to work with a typescript for it retaining many other tricky parts from JS.
> Can you give a concrete example where typescript is a blocking issue for your development?
Typical example: the tsc transpiler plainly dies, and you know nothing how to debug it, you know nothing of its internals, and you loose the rest of the day doing fruitless email exchanges with typescript dev team, and trying to trace a breaking commit.
Second example: you got a prod breakage report in some hard to reproduce case. You fire a debugger in chrome through vscode, and then you find out that the debugger completely loses the execution flow in transpiler/tooling garbage, and broken source maps. Having a debugger pick code that went through webpack (be it cursed) is already a 50/50 lottery, and additional layer of tooling makes it even worse.
If you're saying that you can't handle the overhead of Typescript config because your devs already spend so much time struggling with the rest of your tooling, by all mean get your shit together with your tooling, this amount of time spent on it isn't any sort of acceptable. You have huge problems.
> most of devs we hire are long past the stage when typing errors are a thing for them
This is just not a thing.
You do realise the large number of open issues almost certainly relates to Typescript's compiler and language implementation? When a project is written in Typescript, it does not mean all those bugs will inevitably plague the project itself. If I wrote "hello world" in Typescript with a Webpack + Babel project starter, it doesn't suddenly mean I now have thousands of open Typescript bugs to deal with.
Also: the number of closed issues outnumbers open ones by almost x5. Moreover, the total number of issues exceeds 20 thousand; the number is only so high because so many people have already adopted Typescript into their dev workflows. It's a sign it's been battle tested extensively.
> Like half of all genuine bug triage time is already spent on webpack, bable, and other things in the tooling stack. 200 hours a month for $30-$40 per hour devs.
Half? This just seems totally implausible; this could only be true if you were constantly modifying your webpack and babel setup and config files and breaking things.
I’ve done JS with and without types. I’d find a new job before going back to working without them. That’s how dramatic the benefits have been in my code.
Nonsense. Static type systems help you write correct code. They're also extremely helpful for refactoring. They also help readability. Outside the JavaScript world, they also help performance. The list goes on.
No-one is too smart for type systems to be helpful.
> it does not pay off at all
You've entirely ignored that TypeScript helps reduce bugs, and helps catch them earlier.
It's genuinely terrifying to think that people out there with this attitude are producing software that I might be at risk of using.
