6 ms·

> Is it really much of an issue? 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 mak

> Is it really much of an issue? 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.

nawgz 4y ago
So you are writing naked JS or what? 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
- Beltalowda 4y ago
  > I don’t know what pathological case you stumbled on to make a single file take 3s tho 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.
- deleted 4y ago
  [deleted]
Gigachad 4y ago
Your setup must not be right. The one I’m using at work reloads the page when I save in the editor so by the time I switch to the browser window it’s already loaded. Basically no perceivable compile time.
- Beltalowda 4y ago
  Yes, and that is a world of complexity that manages all of that behind the scenes. 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.
  - solarkraft 4y ago
    tsc is slow (and that's a shame), but there are Typescript compilers like swc that are quite fast. 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).
    - Beltalowda 4y ago
      I believe swc only compiles TypeScript, but doesn't actually perform any type checking (same as esbuild)? You can make tsc a bit less slow by disabling type checking (it's still slow, but less), but it seems to me that kind of defeats the point of using TypeScript in the first place. It's nice for creating builds, but not very useful during development.
solarkraft 4y ago
There are other, arguably better workarounds than not using Typescript. The main reason that so few people are bothered by tsc being so slow is that they don't actually use it for compiling! Because Typescript does absolutely nothing at runtime, you can just strip the type hints, get valid JS and be done. 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.
- Beltalowda 4y ago
  > I don't know if there's a popular solution for immediately seeing changes in production like you seem to be looking for 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).
- P5fRxh5kUvp2th 4y ago
trinovantes 4y ago
tsc is the reference implementation written in JS so of course it's slow. It has to boot up the nodejs runtime first Use swc or esbuild if you want fast TS compile times and use your IDE or eslint for type checking during development
- Beltalowda 4y ago
  Python or Ruby isn't that slow. Coffeescript isn't that slow. Several seconds really is very slow. It's a tsc problem, not a nodejs problem.
  - trinovantes 4y ago
    Python and Ruby are implemented in C, not interpreted languages 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. [1] https://github.com/microsoft/TypeScript/issues/29651 https://github.com/microsoft/TypeScript/issues/29651
  - winrid 4y ago
    A better comparison would be if the Crystal compiler was implemented in Ruby, how slow would it be? 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().
    - Beltalowda 4y ago
      > A better comparison would be if the Crystal compiler was implemented in Ruby, how slow would it be? 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 It's not very fast, but still several times faster than TypeScript, and it includes a large runtime (the resulting file is 2M); disabling that speeds it up by ~150ms (most of that seems to be in the source map generation for the runtime, since --no-source-map with the runtime gives similar results). Opal is also a fairly small not-very-active project developed by a few people in their spare time, not a major language sponsored by a major company used throughout the world. 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 > especially if the project has many files to load at runtime for interpretation. I bet it's spending a lot of time on require(). 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.

nawgz 4y ago

So you are writing naked JS or what? 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

Beltalowda 4y ago
> I don’t know what pathological case you stumbled on to make a single file take 3s tho 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.
deleted 4y ago
[deleted]

Gigachad 4y ago

Your setup must not be right. The one I’m using at work reloads the page when I save in the editor so by the time I switch to the browser window it’s already loaded. Basically no perceivable compile time.

Beltalowda 4y ago
Yes, and that is a world of complexity that manages all of that behind the scenes. 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.
- solarkraft 4y ago
  tsc is slow (and that's a shame), but there are Typescript compilers like swc that are quite fast. 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).
  - Beltalowda 4y ago
    I believe swc only compiles TypeScript, but doesn't actually perform any type checking (same as esbuild)? You can make tsc a bit less slow by disabling type checking (it's still slow, but less), but it seems to me that kind of defeats the point of using TypeScript in the first place. It's nice for creating builds, but not very useful during development.

solarkraft 4y ago

There are other, arguably better workarounds than not using Typescript. The main reason that so few people are bothered by tsc being so slow is that they don't actually use it for compiling! Because Typescript does absolutely nothing at runtime, you can just strip the type hints, get valid JS and be done. 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.

Beltalowda 4y ago
> I don't know if there's a popular solution for immediately seeing changes in production like you seem to be looking for 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).
P5fRxh5kUvp2th 4y ago

trinovantes 4y ago

tsc is the reference implementation written in JS so of course it's slow. It has to boot up the nodejs runtime first Use swc or esbuild if you want fast TS compile times and use your IDE or eslint for type checking during development

Beltalowda 4y ago
Python or Ruby isn't that slow. Coffeescript isn't that slow. Several seconds really is very slow. It's a tsc problem, not a nodejs problem.
- trinovantes 4y ago
  Python and Ruby are implemented in C, not interpreted languages 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. [1] https://github.com/microsoft/TypeScript/issues/29651 https://github.com/microsoft/TypeScript/issues/29651
- winrid 4y ago
  A better comparison would be if the Crystal compiler was implemented in Ruby, how slow would it be? 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().
  - Beltalowda 4y ago
    > A better comparison would be if the Crystal compiler was implemented in Ruby, how slow would it be? 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 It's not very fast, but still several times faster than TypeScript, and it includes a large runtime (the resulting file is 2M); disabling that speeds it up by ~150ms (most of that seems to be in the source map generation for the runtime, since --no-source-map with the runtime gives similar results). Opal is also a fairly small not-very-active project developed by a few people in their spare time, not a major language sponsored by a major company used throughout the world. 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 > especially if the project has many files to load at runtime for interpretation. I bet it's spending a lot of time on require(). 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.