Skip to content
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

Closed
4 of 5 tasks
HighCWu opened this issue Dec 19, 2018 · 20 comments
Closed
4 of 5 tasks

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

HighCWu opened this issue Dec 19, 2018 · 20 comments
Labels
Out of Scope This idea sits outside of the TypeScript language design constraints Suggestion An idea for TypeScript

Comments

@HighCWu
Copy link

HighCWu commented Dec 19, 2018

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.

@weswigham weswigham added the Out of Scope This idea sits outside of the TypeScript language design constraints label Dec 19, 2018
@kaaninel
Copy link

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.

@HighCWu
Copy link
Author

HighCWu commented Dec 19, 2018

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.

@kaaninel

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 ?

@DanielRosenwasser
Copy link
Member

See #5200 for similar discussion.

@HighCWu
Copy link
Author

HighCWu commented Dec 20, 2018

@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.
Maybe AoT compilation or pre-release compilation will greatly promote TypeScript.
Thought this idea is out of scope, I still hope that more people can pay attention to this idea.

@aammfe
Copy link

aammfe commented Jan 16, 2019

@HighCWu yes it would be great to have Typescript supported in CLR.
Typescript would be easily compile in to WebAssambly and using blazor it would be great.

@RyanCavanaugh RyanCavanaugh added the Suggestion An idea for TypeScript label Jan 16, 2019
@RyanCavanaugh
Copy link
Member

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

@dazinator
Copy link

dazinator commented Aug 4, 2019

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.

@jcalz jcalz mentioned this issue Nov 14, 2019
21 tasks
@surfmuggle
Copy link

surfmuggle commented Oct 2, 2020

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?

@StEvUgnIn
Copy link

StEvUgnIn commented Mar 28, 2021

@surfmuggle are you looking to compile it or to call it from C#?

You could call tsc from a JS engine
https://cdn.jsdelivr.net/npm/[email protected]/bin/tsc
https://www.nuget.org/packages/Microsoft.JSInterop/5.0.4

Edit:
Yes, here is a TS compiler based on .NET
https://www.nuget.org/packages/Microsoft.TypeScript.MSBuild/
https://docs.microsoft.com/en-us/visualstudio/javascript/compile-typescript-code-nuget?view=vs-2019

@surfmuggle
Copy link

It seems that the TypeScript NuGet package adds TypeScript support but still requires Node.js. From the linked page:

If Visual Studio is installed, then the node.exe bundled with it will automatically be picked up. Otherwise Node.js must be installed on the machine.

@hoonsubin
Copy link

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.

@StEvUgnIn
Copy link

Microsoft is busy working on improving Blazor for .NET languages.

@jbennett-atreo-io
Copy link

@surfmuggle are you looking to compile it or to call it from C#?

You could call tsc from a JS engine https://cdn.jsdelivr.net/npm/[email protected]/bin/tsc https://www.nuget.org/packages/Microsoft.JSInterop/5.0.4

Edit: Yes, here is a TS compiler based on .NET https://www.nuget.org/packages/Microsoft.TypeScript.MSBuild/ https://docs.microsoft.com/en-us/visualstudio/javascript/compile-typescript-code-nuget?view=vs-2019

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?

@jarble
Copy link

jarble commented Mar 11, 2022

I also found a JavaScript interpreter in .NET that is probably capable of running compiled TypeScript programs.

@jbennett-atreo-io
Copy link

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.

@HighCWu
Copy link
Author

HighCWu commented Mar 12, 2022

I also found a JavaScript interpreter in .NET that is probably capable of running compiled TypeScript programs.

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

@avin-kavish
Copy link

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 Thread.run(() => { ... }) or go doSomething() instead of having to spawn another script and awkwardly pass messages to it. It won't have any as a type. unknown will mean something like Object and just needs to be casted before being worked on. type alias "gymnastics" will be reduced to a minimum that can work within a compiled language.

I think it's possible. Swift already feels very dynamic-y even though it's statically compiled.

@bbqchickenrobot
Copy link

bbqchickenrobot commented Dec 3, 2023

There is this.... :

TypeRunner

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.

@jarble
Copy link

jarble commented Dec 4, 2023

Can we use dotnet-webassembly to run compiled AssemblyScript programs in .NET?

@avin-kavish
Copy link

There's no point. I tried it. Node.js is faster than CLR for dynamic types.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Out of Scope This idea sits outside of the TypeScript language design constraints Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests