Interesting, I hadn't considered that. I've always just had a build script (usually in package.json), and run that when I change something (either with an inotifywait loop or manually). It does make sense that if you're instead keeping one long-running node.js process instead of spawning a new node.js instance every time, tsc's slow start-up won't matter as much. I'll have to keep that in mind next time I end up doing typescript work.
I have used Angular, using a long-running webpack process which does angular template and typescript compilation, and I found that to be excruciatingly slow even for small changes, but I'm willing to bet that has more to do with Angular than with Typescript.
> C++ is a funny example to mention because it scales pretty poorly in the compilation time aspect
C++'s compile times are horrible, I won't try to defend it - waiting another eight hours for Chromium to compile because you need a build with debug symbols is just horrible. However, most of my time actually working on relatively small C++ code bases is pretty good; compiling each individual file doesn't take very long, and you only recompile the files which have actually changed, and recompiling one C++ file and re-linking the project takes around 0.4 seconds (unless you're doing something stupid like linking in all of webrtc, which we admittedly do for a couple of projects at work). Compiling a typescript file which just contains `console.log("Hello World");` on the other hand takes a bit over a second. (I know compiling hello world isn't very relevant when your compiler is a long-running process instead of a one-shot thing, I'm just including it because that's what my experience with tsc has been until now.)
Do you happen to know of any good resources for how you would run the compiler multiple times from one node.js process? I imagine webpack maybe does it already, but I would be interested to import the compiler as a library or something, and do some testing to see how big of a difference it actually makes to not start a new javascript VM every time.
https://github.com/Microsoft/TypeScript/wiki/Using-the-Compi...
And of course you can read the source code for Webpack's typescript support.
Sidenote: although it's less popular, I highly recommend looking into Parcel Bundler, it's much nicer to use and has no configuration required. You can, for example, point it at an HTML file with a script tag pointing to a TypeScript entrypoint that includes NPM modules and it will handle compiling, bundling, minifying transparently. And it's relatively quick.
GCC startup time is going to be faster than Node.JS startup time, but that's irrelevant. We don't need to restart the compiler on each iteration. You can just use an auto reloader for that.
And since we're real developers writing real apps, hello world is not important to us. We want to organize our code into modules and bundle those to a single JS file that is minified in production. So we're going to process the source code one way or another.
C++ is a funny example to mention because it scales pretty poorly in the compilation time aspect, because it lacks modules. Compiler startup times are good... But it's not really that fun burning all 16 cores trying to compile Qt and still having it take forever. Compare to Go where compilation is so fast most people don't even talk about compilation speed.
All languages compile eventually anyways, even JS. It just compiles in the browser. If you really want a "zero compilation step" experience, you can just load the TypeScript compiler directly in the browser. It's been done in the past for demos.