People occasionally rely on compilers. I don't really see this as much different.

At the end of the day all I care about is if I build the products and solve the problems I'm hired to do. Beyond maintainability, the "engineering" stuff is a distraction we need to be careful not to obsess over.

Well yes. But as the problem solver, there is nothing better than when someone has a problem, and you have a solution ready at hand which came from lambda calculus or distributed systems tricks or some crazy shit from On Lisp. That is why they are paying you, not to cranks out good dutiful straightforward solutions but for clever ideas that are simple to implement and operate. The engineering is both awareness and skill in following processes to get great cheap and effective solutions. Otherwise you end up with 20 million lines of code and all the aesthetically sensitive people have have to leave the company.

Given that people are usually already using Babel, TypeScript isn't really any different than running a linter is. There's no additional transpilation step if you write your code in TS, but you can also run TypeScript to have it warn you of potential errors.

Why is the transpilation step an issue? You can set it up to happen whenever the file is changed with most things.

Because it's no longer the same language. You're not programming in JavaScript, you're programming in TypeScript, which happens to be compiled to something JavaScript engines accept. All the praise towards TypeScript does not necessarily apply to JavaScript. It would be like praising Assembly while you're actually programming in C.

AFAIK, the only difference between TS and JS is types. TS doesn't give you anything that's functionally different than JS -- only types that are stripped during compilation. You can't perform any logic on types at all (e.g. you can't have conditional logic based on interfaces).

Comparing assembly/C to JS/TS doesn't make sense.

Yeah, and the only difference between C and machine code is that C hasn't been compiled yet. The comparison makes perfect sense.

Writing TypeScript is like writing JavaScript but with type annotations. Writing C is not like writing assembly with type annotations.

> Writing TypeScript is like writing JavaScript but...

...but different.

> Writing C is not like writing assembly...

...it's different.

With most things, yes, if the implementation for that feature supports your operating system, and it doesn't take long enough to be noticeable, and there's no weird caching issues at any given level, then yes, it's transparent in that case.

Or you could just write the JS directly and be done with it.

> I just don't like the idea of depending on transpilers to not suck when creating the final code

How does this differ from trusting a compiler or interpreter?

Every language has to be translated to machine code in some way.

> How does this differ from trusting a compiler or interpreter?

When was the last time you found a bug and it was the compiler or interpreter's fault?

At any rate, the big difference is debugging, as I mentioned above. How fun is it to debug code which you only kind of indirectly wrote?

The code output by typescript is generally pretty readable depending on the target, and the source mapping works very well regardless. The debuggers in all major browsers and ides handle it fine.

I've not come across any bugs caused by typescript itself in the time I've been using it since 2014, and my point was that this is the same for c or any other language - how fun is it to debug assembly you only kind of wrote