NetJs: A .NET to TypeScript and JavaScript compiler
github.com
github.com
There were also other projects that allowed this with C#, I just forget their names.
This way, the JS output can be considered source, checked in, diffs might make sense, and the real source could be hidden in a tarball until it's too late.
I see something like this really being beneficial when building a Single Page Application, or porting a Desktop Application to a SPA.
however on second glance ... there have been numerous times where I have written c# server side with 'UI Model' Classes that use to serialize to XML/json for consumption by the client/browser and corresponding models in javascript/typescript. The C# -> Typescript conversion would save me a lot of time (and automate keeping the two in sync) and I would imagine for that niche case it would be totally worth it.
the js one is so slow it's barely usable. It should be priority 1! write something in C# or even C++,that should'nt be that hard,or is it?
I believe that their compiler also runs under Node.JS, which is easily a much lighter cross-platform solution than requiring Mono (which would be needed for a C# compiler).
Especially when you consider a "just hit reload" development cycle as the competition.
Since the Typescript compiler itself is > 2MB of minified js, it doesn't surprise me that compiling any TS has at least a second overhead.
What's more important to me is that:
- The compiler performance scales as the codebase increases in size.
- Incremental builds are fast. (ie the -watch option).
So far I have found both to be true. Incremental builds take < .5 sec on my laptop. That means I get a cute red-squiggly in Visual Studio in a convenient amount of time. Ultimately, that's half the reason for using TS in the first place; if it didn't improve our productivity, we wouldn't be using it.
I think the point is that you have some existing libraries that would be useful in a web application, you could go ahead and compile those down to TS and use them within your TS code.
I found that converting 10k of C# was incredibly quick and the overall build time was still totally dominated by the slow TypeScript compiler.
You are right that the development time is spent unit-testing C# and very rarely invoking the TS compiler so rather than making the workflow worse, it improves it immeasurably. The alternative to recompile TS each time and use Karma and Chrome dev tools is unbearably slow and clunky in comparison.
The real win I was after was that the quality of the test tools and debugger for .Net. Using a tool like TestDriven.Net from visual studio so from a r-click I have test coverage, performance, edit-and-continue and all the benefits of the Visual Studio debugger.
The generation to typescript is more of a publish step than part of the development cycle. I also convert the NUnit tests to Jasmine so I run the same test suite across the generated javascript. This does catch issues because there are differences, like lexical scoping, that my cs2ts tool did not try to solve.
http://channel9.msdn.com/Events/Build/2014/9-010
"That is darn near impossible to do with any level of fidelity that is meaningful"
"If you're going to write for the web, write for the web."
Write for the web seems like a lame excuse to not embrace better languages and deal with the issues in cross compilation.