Is it really much of an issue? I work on a large TS project on a 2020 m1 MacBook and I’ve never been aware of the ts compilation. It seems snappy enough.
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.
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 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).
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. I suppose you can make the argument that tsc should have an early exit for empty files but that's just unnecessary bloat to the code base.
Surprisingly, tsc doesn't have an option to skip type checking [1]. The best you can do is run using --skipLibCheck to skip checking node_modules.