Yes, because I don't want to wait seconds every time I change a typescript file and I don't want to world of complexity to make it have the same performance every other compiler has out of the box. My "solution" for this is to not use typescript. I'd like to, but it's just too painful.
The fact that you need to "setup" anything is already a problem. I want stuff to Just Work. No extra processes. No extra steps. Nothing to update. Works today, works in five years. Just start one process and it will work. I don't understand what's so hard to grasp about that.
This is trivial to do with a compiler that has an okay-ish (not even "fast") performance. It's not feasible with TypeScript today, even for fairly simple applications with a few hundred lines of code.
It's totally reasonable to keep your setup simple, all that complexity is often not required. It only really pays off on larger projects (it's super simple to set up nowadays though).
A lot of developers decided slow compiles - I don’t know what pathological case you stumbled on to make a single file take 3s tho - is far superior to needing to suss out runtime errors, and I find it hard to believe you made the choice to write naked JS instead of TS. If you picked a different language, fair enough I suppose, but I have to admit I’m not that sure why someone would tap JS/TS if another language is equally suitable. I am a front end guy after all, so I don’t particularly have a choice
It's an empty file. It's not a "pathological" use case. It's simpler than "hello world". It's literally the simplest possible use case. I do have to say I have a fairly slow laptop, but everything else is plenty fast enough.
> I find it hard to believe you made the choice to write naked JS instead of TS
Why is this hard to believe? Most things I work on are a few hundred lines, maybe 2,000 lines at the most. Not huge, but not trivial either. Some of these are personal projects, on some I work as a contractor. Many have an uneven pace of development: lots for a bit, then nothing for months or years. I want stuff to "just work", even after 2, 3, or more years, and I don't want to update loads of tooling every time I come back to it. This is already a bit of an issue in JS-world in general, so I try to keep things simple. This means, among other things, simple build steps. With a okay-ish performance (doesn't even need to be "fast") you can keep builds very simple. With the current performance this is a lot harder and you need a lot more complexity to make it work smoothly.
The type checking usually only happens during development time, continually or on demand. Shifting type checking to the IDE is how Vite can be so fast.
I don't know if there's a popular solution for immediately seeing changes in production like you seem to be looking for (running dev servers in prod is probably not a good idea), but regardless I think Vite is worth a look. It gets rid of a lot of the cruft people criticize about web development.
No, I just want to run it in dev. There is no good way to do this currently because it's just too slow to be smooth.
Vite is undoubtedly an improvement over what came before, but the entire method of operation is just not what I want. I don't want to run a Vite process in a second terminal. I don't even use npm for half the things I work on, because there is no need for it. I just want to compile a file every time I load it on my dev machine (i.e. on 'GET /file.ts' runs 'if (hash("file.ts") != cached_hash("file.ts") { tsc("file.ts", "file.js"); serve("file.js") }'). For production, I just compile the files in the binary and serve those.
There are other reasons one might want to use Vite ("hot module replacement" and such, although I personally dislike it) but currently you need to use Vite or something like it, with no realistic option to keep it simple if you want to. If tsc was faster it will become realistic to make everything a lot simpler, with a lot less tooling, and a lot less complexity.
> other, arguably better workarounds than not using Typescript
My current plan is to look at rescript when I have some time. It seems a lot faster and offers mostly the same features. Though the big advantage TypeScript has is that it's JS-compatible and "upgrading" a project is a lot easier, and that's it's kind-of standard whereas rescript is kind-of obscure (which doesn't matter for my personal projects, but does for some things I work on as a contractor, where I want to make sure the next person can work on it in 2 years after I'm gone).
He has a point, although the advantages outweigh the disadvantages for sure.
Use swc or esbuild if you want fast TS compile times and use your IDE or eslint for type checking during development
Node is fast but there is an initial startup penalty, especially if the project has many files to load at runtime for interpretation. I bet it's spending a lot of time on require().
Faster than tsc because Ruby doesn't need several seconds to start up and neither does node. Opal translates Ruby to JavaScript (and is implemented in Ruby) so we don't need to engage in unfounded speculation about non-existing implementations:
% :>a.rb
% time ./bin/opal --compile a.rb > a.js
./bin/opal --compile a.rb > a.js 0.54s user 0.12s system 90% cpu 0.735 total
Coffeescript, which uses Node, also doesn't support from multi-second startup times:
% :>a.coffee
% coffee a.coffee
% coffee a.coffee 0.10s user 0.03s system 101% cpu 0.125 total
How often do I need to repeat it? It's a single empty file. Are people even reading what I'm saying or what because I've had to repeat this more than once now. It's a a file with zero bytes. No content in the file. No diskspace is used. The number of bits in the file is zero. A single empty file.
> especially if the project has many files to load at runtime for interpretation. I bet it's spending a lot of time on require().
I am talking about tsc itself. If there are hundreds/thousands of modules to load, node will spend time on that. coffeescript is a much smaller transpiler, with just a handful of source files.
EDIT - looks like tsc might get distributed as a single file, which helps here. However, it is a 7mb source file :)
https://raw.githubusercontent.com/microsoft/TypeScript/main/...
When I execute it locally, with no arguments, it finishes instantly as far as I can tell. So maybe tsc itself is indeed super slow for just an empty file.
CoffeeScript simply compiles code and does not perform static analysis
tsc is implemented in JS and performs static analysis which makes it (unsurprisingly) slow
So again, use esbuild (go) or swc (rust) with type checking disabled if you want speed. Surprisingly, tsc doesn't have an option to disable type checking [1].
On the other hand Ezno a semi compatible TypeScript compiler can use a more low level binary format which is only one pass and whose name references are already resolved https://twitter.com/kaleidawave/status/1596445852918325250?s... . This is only really possible because it is written in Rust so low level byte and memory management is relatively simple
tsc isn't just slow, it's SLOW.
3.2 seconds is just embarrassing. Nothing is even close to this; every other compiler or interpreter is in the dozens or maybe low-hundreds of ms. clang++ -O2 and rustc are both ~150-200ms, and these are not compilers known for their excellent performance. The startup time of tsc is an order of a magnitude slower than anything else. I didn't measure lines of code/second performance, but with such a slow startup time it's not that important because no matter how small your project: typescript will be ridiculously slow.I don't want to run any "watchers" or special dev servers for the frontend or all of that ridiculously complex circus to work around this embarrassingly slow tooling. I just want to request "/file.ts" and have it serve a compiled version on the fly. This is simple, easy, and even with caching just a few lines of code. It's how everyone was using coffeescript back in the day.
What we have now is millions of lines of code and a world of complexity to work around an embarrassingly slow compiler.