Will TypeScript ever run on the .NET CLR (Virtual Machine)?

Topics: General
Apr 4, 2014 at 5:01 AM
JavaScript is a powerful and flexible language, if used properly. TypeScript and VisualStudio is a step in the right direction. But, to only run it on typical JavaScript runtime platforms such as NodeJS and web browsers is very, very limiting.

What we need is running TypeScript and more importantly, run JavaScript on the .NET CLR (Virtual Machine) with full debugger support to enable stepping thru code in Visual Studio.

Once the above is accomplished, I would run Amber Smalltalk on top of such a JavaScript development / deployment platform.
Amber Smalltalk: http://amber-lang.net/
Learn Smalltalk in 5 minutes: http://amber-lang.net/learn.html

Question: Are there plans or some way to run JavaScript (or TypeScript) on .NET for deployment?
Apr 4, 2014 at 5:15 AM
Hosting the IE11 script engine in a managed process is already supported. See http://code.msdn.microsoft.com/JavaScript-Runtime-Hosting-d3a13880 - it's as close as you're likely to get to directly running JavaScript on top of .NET given the huge disparity in their architectures.
Apr 4, 2014 at 5:19 AM
There's also ClearScript and V8.Net.
Apr 4, 2014 at 6:57 PM
Thank you for the references to the IE11 script engin, ClearScript and Google's V8 JavaScript VM integration. These projects are only viable for light weight execution of scripts to extend .NET apps. Very limiting and not viable for actually building apps in JavaScript to run on the .NET runtime.

I've also looked at Jurassic, which seems the best option, so far. https://jurassic.codeplex.com/ Jurassic compiles JavaScript into .NET bytecode (CIL); not an interpreter. This is the start of what I'm looking for. Debugger support and JavaScript as a first-class citizen in Visual Studio would be the most powerful and flexible development environment.

I've been developing in Smalltalk since the 90's. Using C# is like reverting to a typewriter, after using a Wordprocessor (Smalltalk & it's development environment). Sadly, I need to deploy on a .NET runtime so am limited to the current state of Visual Studio's support for dynamic languages. Iron Python, Ruby just don't compete with Smalltalk's productivity. JavaScript compiled to .NET, with Amber Smalltalk would bring me closer to the kind of flexibility, interactiveness, productivity and joy I've experienced. Here's a comparison: http://www.cincomsmalltalk.com/main/products/why-smalltalk/cincom-smalltalk-vs-visual-studio/

So far, Jurassic seems my best option, but is still not ready to use in a first-class way, within Visual Studio. Is Dave Simmons still at Microsoft? He developed a working prototype of Smalltalk on .NET, called S#

In the mean while, I'll keep using my C# typewriter and dream of using a wordprocessor once again.
Apr 5, 2014 at 5:31 AM
Not sure what you mean be "light weight". You can expose any CLR object to the script environment and use it. In fact, V8 has the fastest execution time around (see this Jurassic page: https://jurassic.codeplex.com/wikipage?title=Benchmarks&referringTitle=Home). That said, if speed is not an issue, and VS debugging is a requirement, then Jurassic sure seems the best bet. If cross-platform integration is important, then V8.Net has had a successful port to Mono already, and Jurassic is Windows only at the moment.

Also, important to note, ALL of the script engines I know of currently (including Jurassic) do not expose .NET to the script world by default. See this link:
You have to REGISTER the .NET types first (perhaps for security reasons). Same thing with ClearScript and V8.Net. In fact, their quote "An exception thrown within the provided delegate cannot be caught within JavaScript (unless it is a JavaScriptException)." means that any normal .NET exception in callbacks will not be caught, unless you catch it and pass along the error as another exception object. Similar things can be done with the other engines also.
Apr 5, 2014 at 5:04 PM
A CLR Smalltalk seems like a much better idea than trying to compile a prototypal dynamically typed scripting language to bytecode for a classical statically typed VM.