-
Notifications
You must be signed in to change notification settings - Fork 12.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Any plan to compile TypeScript to C#, .NET CLR or other targets #29095
Comments
This doesn't fit to typescipt's goals. If you want c# go write c# actually its much more efficient instead of transforming typescript into c#. what can be done is multiple target. Like some hot parts of code can be targeted as wasm and other parts plain old js this would improve lots of things actually but again wasm is not exactly catching up yet. And i think u should recheck your check list. |
You're right.But what I actually think is to use C# as an intermediate language. After all, there is a little bit of ready-made stuff. But with TypeScript updates, the converter is more complicated. Direct compilation to multiple targets is undoubtedly correct. Does the 'out of scope' tag mean that multi targets support is impossible to be added ? Or just not goal now ? I changed the last item of the checklist to be not satisfied. Is it a right ? |
See #5200 for similar discussion. |
@DanielRosenwasser It is analogous. But the answer is a little different from my thoughts. I hope to compile directly to multiple platforms, not using javascript as an intermediary. Unfortunately, I can't search out for related project that directly compiles ts. |
@HighCWu yes it would be great to have Typescript supported in CLR. |
Compilation targets outside of JS are very much outside our design goals. You might try https://github.com/JavascriptNet/Javascript.Net if you want to run JS code inside a .NET program |
Searched for this feature because, with the advent of Blazor, there are lots of available components written in typescript today but no way to leverage them from a blazor app (you can write an interop layer but it's not pretty). If there was some way to convert the typescript source to c# I thought that might be a useful start on the journey to reusing stuff within a blazor app. Reading the above I understand this is not a goal of typescript but just wanted to add why I was looking for this feature. |
A little off-topic: i was wondering if there is a typescript to javascript transpiler that does not depend on node.js (nor deno) but depends only on .NET Core? |
@surfmuggle are you looking to compile it or to call it from C#? You could call tsc from a JS engine Edit: |
It seems that the TypeScript NuGet package adds TypeScript support but still requires Node.js. From the linked page:
|
Considering that we have AssemblyScript, which is growing so fast, I don't understand why this isn't an ongoing conversation. I guess it's not a topic for this specific repo, but .Net could use more languages outside of C#, C++, and the dying VB if CLI is its sales point. |
Microsoft is busy working on improving Blazor for .NET languages. |
Question for you, how can you access the ts compiler in the Microsoft.TypeScript.MSBuild package. I can't figure out how to do that from C#, any idea? |
I also found a JavaScript interpreter in .NET that is probably capable of running compiled TypeScript programs. |
I ended up just installing ts-node into my C# project in visual studio, creating my .ts files in a local temp location, transpiling them and then calling the transpiled code. It works and you don't have to use an interpreter which is a little sketchy for production code if you expect it to behave the same on the frontend and backend. |
I already know there is this javascript compiler. But when I asked the question, my thought was that typescript has type annotations, which should allow the compiler to do special optimizations on the type annotation part, similar to AssemblyScript. That should run faster than the javascript executor |
What I am thinking is to obtain a statically compilable sub-set of Typescript and build a seperate runtime with it. CLR might be a good target because it is already a very fast run-time and I bet emitting IL code will be easier than anything else. maybe bytecode (jvm). And this is not going to be javascript compatible at all. It'll be a seperate language. The reason is I find TypeScript more expressive than modern alternatives like Kotlin, Swift or Go. (Or maybe I'm just used to it) But JS as a runtime is much slower than these. So ideally we get to use TypeScript at the speed of these languages and with a much better standard library. Multi-threading will be something like I think it's possible. Swift already feels very dynamic-y even though it's statically compiled. |
There is this.... : C++/CLI isn't x-plat so I guess it would have to be ported over to C#. I'd be willing to help in whatever capacity I can. |
Can we use dotnet-webassembly to run compiled AssemblyScript programs in .NET? |
There's no point. I tried it. Node.js is faster than CLR for dynamic types. |
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:
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.
The text was updated successfully, but these errors were encountered: