Skip to content

Any plan to compile TypeScript to C#, .NET CLR or other targets #29095

Closed
@HighCWu

Description

@HighCWu

Search Terms

Compile, C#, CSharp, .NET, Mono, WebAssembly

Suggestion

As I said, I hope that Typescript can compile to more targets, such as C#.
(I found a related issue, but it closed. (#9202))

Use Cases

As we all know, C# can be compiled into JavaScript (by Bridge.NET), and it can also be compiled to multiple platforms. Although TypeScript is just a superset of JavaScript, it is really another language. If it can achieve faster performance with a more static type than JavaScript, why not compile it directly, as we did with C#.

Although TypeScript was born to serve JavaScript, I think it can go further because it already has a huge user base.

Early TypeScript type support is not as good as C#, no int, etc., but as a superset of Javascript, you can completely refine the number type. It seems that 3.0 has added support like BigInt, (#4639 , #15096 ) which is a big step forward. And more types support greatly improve the performance optimization compiled to other platforms, and further improve the robustness, just as TypeScript's subset AssemblyScript uses the bytecodes like i32 and f32 for compiling to WebAssembly type.

Also, I think that the typescript should be able to AoT compile the platform on the mobile side to achieve near-native speed.

Moreover, TypeScript has a lot to do with C#. I think, borrowing C#'s compilation ideas shouldn't be difficult. I found something like this michaelcheers/TypescriptToCS2.

What triggered me was the appearance of Blazor. But it is to serve people who are familiar with C# and let them turn to the frontend. However, TypeScript seems to be serving the frontend. It doesn't seem necessary to compile TypeScript like Blazor to compile C# to wasm.

However, already with Bridge.NET compiling C# into javascript, why do they have to compile C# into WebAssembly? Actually, I didn't think about the reason very carefully, but it made me wonder if TypeScript can do it too?

Perhaps if TypeScript has more compilation targets, it will become more versatile. Frontend engineers can bring their knowledge to every part of the system. And it can also attract other types of engineers. After all, cross-platform and faster than JavaScript is undoubtedly very good. There are already many engineers who use TypeScript instead of JavaScript, right ?

Examples

Compile TypeScript to wasm. In general, compiling JavaScript to wasm seems to be a lot of work, and it's inefficient. But TypeScript has static types, even if it is doped with some dynamic types like 'any', but the speed should be faster. Like Blazor's ability to interoperate with JavaScript, replacing C# with TypeScript should be more comfortable because TypeScript is inextricably linked to JavaScript.
(Forgive me for always mentioning wasm and some frontend related things, because I am very interested in these. But TypeScript should be useful in other compiled targets.)

Checklist

My suggestion meets these guidelines:

  • This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • This wouldn't change the runtime behavior of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions
  • This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.

Written at the end

Maybe a TypeScript to C# converter is enough. But the converter I mentioned just now seems to be no longer updated. And a converter is far less efficient than direct compilation. I sincerely hope that TypeScript can add this feature. This will be a huge convenience.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Out of ScopeThis idea sits outside of the TypeScript language design constraintsSuggestionAn idea for TypeScript

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions