5 ms·

Good news. Compiler performance is pretty horrible at scale. I hope that they implement in-memory compilation, so that the compiler can work properly with Gulp

by nawitus 12y ago

Good news. Compiler performance is pretty horrible at scale. I hope that they implement in-memory compilation, so that the compiler can work properly with Gulp (which would also increase build times). I also hope that they'll support automatic generation of ambient external declaration files. TypeScript doesn't work well with npm modules just yet because of that.

benjaminjackman 12y ago
The really slow compiler performance was quite surprising. I switched back to coffeescript (then eventually switched to ScalaJs where they are much faster) because they were so long.
- frowaway001 12y ago
  Having tried using JavaScript and TypeScript, I settled with Scala.js, too. Stuff just worked better on all accounts: Language, tooling, fast compilation, good error messages, not having to touch JavaScript-related mess, etc.
SanderMak 12y ago
About TypeScript+Gulp: I was using gulp-tsc, but switched to gulp-type (https://www.npmjs.org/package/gulp-type https://www.npmjs.org/package/gulp-type). It offers incremental compilation and you can disable chasing through all references in the sourcefiles (since with Gulp you already provide all sources in the stream). This sped up our re-compilation times three-fold.
Arnavion 12y ago
>I hope that they implement in-memory compilation, so that the compiler can work properly with Gulp In-memory compilation already exists. I wrote a Gulp wrapper for TS for my own project [0] that supports both normal compilation and incremental compilation (i.e., watch functionality). The real issue with TS is that it doesn't export a programmable compiler API by default, necessitating either a process.exec to the shell script or adding an export statement using the vm module. I gather that was a low priority for the devs because they wanted to get the compiler API in shape first. [0] https://github.com/Arnavion/libjass/blob/master/gulplib/typescript.js https://github.com/Arnavion/libjass/blob/master/gulplib/type...
- nawitus 12y ago
  >In-memory compilation already exists. Well, it seems that it requires quite a lot of code. Perhaps you should publish the gulp wrapper as a Gulp plugin. By the way, does your Gulp wrapper load files from the disk, or are the files given to it as in-memory streams? That's what I mean by "in-memory compilation".
  - Arnavion 12y ago
    >does your Gulp wrapper load files from the disk, or are the files given to it as in-memory streams The latter. The TS compiler (TypeScriptCompiler) internally works with string sources and outputs strings. The official sources use a wrapper around it (BatchCompiler) that converts input file names to input file contents and output JS+sourcemaps to files. My wrapper uses file contents from gulp.src for the same. >Well, it seems that it requires quite a lot of code Yes. The first part of my code is basically a reimplementation of BatchCompiler. But my code also does other things - for example I fiddle with the AST to generate automatic JSDocs, etc.

by nawitus 12y ago

benjaminjackman 12y ago

The really slow compiler performance was quite surprising. I switched back to coffeescript (then eventually switched to ScalaJs where they are much faster) because they were so long.

frowaway001 12y ago
Having tried using JavaScript and TypeScript, I settled with Scala.js, too. Stuff just worked better on all accounts: Language, tooling, fast compilation, good error messages, not having to touch JavaScript-related mess, etc.

SanderMak 12y ago

About TypeScript+Gulp: I was using gulp-tsc, but switched to gulp-type (https://www.npmjs.org/package/gulp-type https://www.npmjs.org/package/gulp-type). It offers incremental compilation and you can disable chasing through all references in the sourcefiles (since with Gulp you already provide all sources in the stream). This sped up our re-compilation times three-fold.

Arnavion 12y ago

>I hope that they implement in-memory compilation, so that the compiler can work properly with Gulp In-memory compilation already exists. I wrote a Gulp wrapper for TS for my own project [0] that supports both normal compilation and incremental compilation (i.e., watch functionality). The real issue with TS is that it doesn't export a programmable compiler API by default, necessitating either a process.exec to the shell script or adding an export statement using the vm module. I gather that was a low priority for the devs because they wanted to get the compiler API in shape first. [0] https://github.com/Arnavion/libjass/blob/master/gulplib/typescript.js https://github.com/Arnavion/libjass/blob/master/gulplib/type...

nawitus 12y ago
>In-memory compilation already exists. Well, it seems that it requires quite a lot of code. Perhaps you should publish the gulp wrapper as a Gulp plugin. By the way, does your Gulp wrapper load files from the disk, or are the files given to it as in-memory streams? That's what I mean by "in-memory compilation".
- Arnavion 12y ago
  >does your Gulp wrapper load files from the disk, or are the files given to it as in-memory streams The latter. The TS compiler (TypeScriptCompiler) internally works with string sources and outputs strings. The official sources use a wrapper around it (BatchCompiler) that converts input file names to input file contents and output JS+sourcemaps to files. My wrapper uses file contents from gulp.src for the same. >Well, it seems that it requires quite a lot of code Yes. The first part of my code is basically a reimplementation of BatchCompiler. But my code also does other things - for example I fiddle with the AST to generate automatic JSDocs, etc.