Why do companies prefer Node.js with TypeScript instead of plain JavaScript?

Your arguments are that JS is better because (a) there’s some deep capitalist motive behind TS and (b) it takes too long to re-deploy if you make a change in TS?!

You said it in your question --> "...at compile time".

If there's a defect in your code and you deploy it to me as plain JavaScript then the problem is detected when I run your script on my device. I see the crash and I get cranky.

Whereas if you have a build cycle before deployment (such as TypeScript) then some classes of errors can be detected when you build it on your machine before it ever is deployed to me, and therefore before it is ever seen by me or my device.

This lets problems be caught by you, the developer, instead of by me, the user. This improves stability of the software, improves my user experience and improves my opinion of your product.

Plain JavaScript may more tersely express the solution to a particular problem. The extra verbiage that TypeScript asks of the developer to ensure that certain problems do not occur may be seen as an annoyance or unnecessary by the developer. Do you use safety equipment for every task you do? Some people do not because, for some tasks that they're very confident in, they choose to do them without additional safety measures in favour of speeding up or simplifying the work. Is this wise? Perhaps not. Is it the safest choice available? No. But it's a risk/reward decision that people are free to make.

Some companies mandate that the safest choice available is always made in order to prevent people from taking shortcuts that cause problems, purely as a matter of policy. The practice, in spite of any additional development effort, is perceived to pay off as a business case.

For some use cases (and often in hobby development) the consequences of software defects are extremely minor so it's more useful to have quick, freely expressive languages like plain JavaScript that people enjoy using as a tool because it's productive for them.

I always use TypeScript when using JavaScript because of code editor checking and autocomplete - for example, if I have a complex object, I would rather use a schema than keep looking back at documentation when I want to access one of its properties. It also doesn't reduce runtime performance. So, in my opinion, TypeScript's benefits are just compile-time checking and autocomplete. The only time I would use JavaScript is for a very simple project or for something that can't be compiled for some reason.

The answer could be too long to be compherensive and reasonable. I suggest you read related documentation and articles.

Of course, all problems solved with TypeScript can be solved with JavaScript. So what? Programming is not just final results, it is also a kind of human activity, and this activity should be supported well for the sake of efficiency, productivity and maintainability. How efficient is using JavaScript compared to TypeScript? It depends on many factors. I personally prefer using plain JavaScript, but I cannot insist on my preference when it comes to other people.

You suggest using validation/middleware checks instead of TypeScript. Are you sure it could be more efficient than immediate use of TypeScript? How? TypeScript is lightweight and provides validation of every line you put right under your fingers. Everything else would require a lot more bothering.

That's the essence of things. I don't think your specific questions makes a whole let sense. The best answer to any concerns related to decision making in general would be: it depends.

Times JavaScript makes more sense are prototyping, simple code you work on alone, and hobby work.

I work alone and for production code I mostly use JavaScript, but if I worked on a team TypeScript would be much more valuable, and for complex code I still prefer TypeScript to prevent mistakes. In complex cases it's definitely well worth the setup time.

If TypeScript is primarily used for type safety, why do companies strongly prefer Node.js + TypeScript instead of writing well-structured JavaScript with runtime validation/middleware checks?

For type safety and tooling.

I am in the camp of plain js.

However, I see the two sides. Typescript prioritizes type safety. And modern editors are built around evangelizing this paradigm. On a side note, perhaps there are some corporate capitalistic motives behind this. I will leave you to ponder on that. The second point is maintainability, like others have said emphasized.

On the js camp I believe that if you happen to crash in production, and, you understand that the level of change is minor, then we have the flexibility to change the code quickly and re-run the app. Modern software engineering purists will frown on this. Saying that it is a careless thing to do.

Ultimately you should be in a position to judge and estimate the final cost. It is often hard. Usually in corporate environments it is safe to stick with type safety paradigm. Since violation often leads to, in the worst scenario, unexpected and unnecessary legal costs.

TS typing requires 10% more work on the average than plain JS and pays off most time, that's why.

At the very least it's a fool proof against human mistakes. How they are frequent and expensive to detect at runtime depends on a human and a project. Even if you have enough attention, competence and code discipline to write "well-structured JavaScript with runtime validation/middleware checks", other team members may not.

Then there are tools that rely on static analysis like IDEs that save time to write code when it's typed.

And AI brings it to another level because it can provide an uncontrollable amount of non-human mistakes if not detected at good time. On the other hand, it can greatly benefit from types because it can get enough context from them without digging deeply into code base or requesting additional information.

Compile-time checking is the only considerable reason. There are possible design benefits like providing metadata with decorators (TypeORM, Nest, Angular, etc) but they aren't indispensable and they suffer from restrictions imposed by long-standing problems with decorators.

This isn't specific to JS in any way, check this and this for some insights.

Ehh it requires a lot more than 10% more up-front work if you're going to use it in any meaningful way. The payoff is in time you don't spend debugging later, and even then its value is situational, although the number of situations is rapidly increasing in the age of LLMs.

I'll be honest that I find this a strange argument, something like VSCode does the autocomplete and object types automatically for javascript if they are at least defined somewhere. I personally prefer javascript but with a good dollop of JSDoc to allow for typing and the like.

Fact is stranger than fiction sometimes.

In early 2000's ECMAScript 4.0 was proposed with types, classes, generics, etc. Javascript is based on the ECMAScript standard and had that proposal been formalized those features would have been implemented back then.

Do you know what killed it? Someone from Microsoft citing it as inadequate during a summit gathering of all the major players in tech at the time.

We could have had all those features baked into the Javascript itself decades ago were it not for that. At the time MS had their own agenda, trying to push their own scripting language for browsers, so undermining the competition probably seemed prudent.

But Javascript was too well entrenched and they ultimately had to acquiesce. Then they followed up Typescript in 2011/2012. I always chuckle at the irony of it all.

The history of tech is littered with stories like these.

It sounds curmudgeonly but I honestly think a big value to Typescript in a larger organization is that it slows down not-quite-ready programmers (sometimes by a lot, browse questions here) because the type system forces them to get their understanding of their own code right. I personally don't like it much but then I've had much luxury in being almost the only front-end coder in some roles.