4 ms·

I find that the TypeScript compiler is annoyingly slow and I cringe imagining a workflow that involves another compiler in front of the TypeScript compiler. Gra

by dangoor 13y ago

I find that the TypeScript compiler is annoyingly slow and I cringe imagining a workflow that involves another compiler in front of the TypeScript compiler. Granted, you'd probably do most of your tests and such at the C# level and only step into JS as the final step... but iterating through those last steps would be annoying. Especially when you consider a "just hit reload" development cycle as the competition.

peterchon 13y ago
I couldn't agree more.
sherbet 13y ago
Our TypeScript project is ~20K SLOC. It compiles in roughly (I haven't measured exactly) the same amount of time it takes to compile 100 SLOC. 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.
- dangoor 13y ago
  Thanks for that bit of data. That makes good sense, and I should give it another try.
- jordibunster 13y ago
  -watch doesn't find new files yet, does it?
- Keats 13y ago
  Are you using a grunt/gulp task to do the incremental build or doing it via VS/tsc directly ?
Touche 13y ago
I don't think the point here is to write your entire app in C#. TypeScript is already close enough. 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.
duncanawoods 13y ago
I wrote myself a similar tool for myself using NRefactory so I can fill you in: 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.

by dangoor 13y ago

peterchon 13y ago

I couldn't agree more.

sherbet 13y ago

Our TypeScript project is ~20K SLOC. It compiles in roughly (I haven't measured exactly) the same amount of time it takes to compile 100 SLOC. 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.

dangoor 13y ago
Thanks for that bit of data. That makes good sense, and I should give it another try.
jordibunster 13y ago
-watch doesn't find new files yet, does it?
Keats 13y ago
Are you using a grunt/gulp task to do the incremental build or doing it via VS/tsc directly ?

Touche 13y ago

I don't think the point here is to write your entire app in C#. TypeScript is already close enough. 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.

duncanawoods 13y ago

I wrote myself a similar tool for myself using NRefactory so I can fill you in: 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.