I actually like writing with Deno, and think the module resolution in Deno is easier to understand (it's literally url or explictely what's written on the import). But it's just sad that the TS team is not moving the same direction with the module resoultion, because it splits the TS community to those who write Deno and those who write regular TS.
I'd also like them to support importing .ts files and rewriting those imports to .js, but given that they've been clear about their position I think it's up to Deno to solve this without forking the ecosystem.
It's treating a language like it's a dumb file rewriter rather than something semantically meaningful. It would have made no sense for Deno to do the same thing - if you import a .js file from a remote server, you want that js file, if it doesn't exist automatically trying to load a .ts file from the same location would be pretty odd behaviour.
Typescript is a language, the tools should understand it as a language and it should be self-consistent.
The other thing that irritates me is that all that typing information is lost at runtime, when it could be very useful in a bunch of situations, but hey, you can't have everything.
TypeScript is best understood as a very advanced linter for JavaScript, not a separate language with its own semantics that happens to compile to JavaScript.
This has many consequences. For example, its type system is unsound to a profligate degree compared to most other typed languages. As a result, it is common for the type system to be wrong about the type of a variable, meaning that any runtime use of type information would have to also cope with being wrong, e.g. by inserting runtime type checks. Runtime type checking for structurally typed interfaces is heinously slow, as you have to type check every field of every transitively reachable interface.
edit: And I realize that Deno currently doesn't maintain your types during runtime either, but in theory that would be fixable since it doesn't have to rely on Javascript.
That seems really annoying and is something I would expect to work. From the linked issue, does the problem go away if you make sure to always just import without the extension, and does it work both directions (deno TS->TS on JS and TS on JS->deno TS)?
The no extension shortcut as well as the index file shortcut have not been included in deno as a learning from node, which in my view is probably a wise move - keep it super simple by just specifying the exact filename.
I hope that either Deno implements some 'legacy' way of working that is compatible with the way the official typescript team do it, or the typescript team realize the error of their ways. I'm not sure if that's likely to happen short of a fork though.
Given what they're doing with Deno Deploy, I almost wonder if the future of Deno is being a vendor-independent version of Cloudflare Workers.
That said, the situation is improving rapidly, and I've been personally willing to bet that the support will be solid by the time I finish prototyping and need to start adding auth to my latest project.