5 ms·

Well seeing how it is an alternative to babel (which also does not check types) it makes sense. Type checking can be a lot slower than an AST transformation, e

Well seeing how it is an alternative to babel (which also does not check types) it makes sense. Type checking can be a lot slower than an AST transformation, especially for a gradually typed language like typescript with tons of inferred types. For this reason most large typescript code based I’ve seen run their build and type checking steps separately. Personally my workflow is to get it working, do a refactor or 2, then check the type checker, linter and full test suite at the end of the implementation.

nawgz 5y ago
> For this reason most large typescript code based I’ve seen run their build and type checking steps separately How big are we talking here? I have a mid-6-figures LOC codebase and the TypeScript compiler time is essentially negligible. I can't really understand how TSC is being compared to a full test suite in your world, the code is invalid if the types don't pass, so I'm more than happy to give it 1sec to tell me if I have a type mismatch
- nsonha 5y ago
  > compiler time is essentially negligible It is, but not neligible enough for hot reload. But people don't want to run tsc mostly because their IDEs already do and give them a better experience than constantly checking the terminal.
  - nawgz 5y ago
    > not negligible enough for hot reload How trivial does a change have to be that a subsecond compile time is offensive? The IDE takes longer than the terminal and is much less consistent. Anyhow, if this crowd truly exists then this is the tool for them, these optimizations seem to be simply for something to do rather than a real development issue in my opinion
    - nsonha 5y ago
      > The IDE takes longer than the terminal and is much less consistent I don't think that's true given tsc in the terminal needs to cold-start. Do you only do back-end? Let me paint the picture of a front-end workflow for you: - You are using VSCode or InteliJ, there is no way to opt-out of typescript, so even if you prefer the terminal, the IDE already runs tsc - You update the code, IDE tells you error. If you are running TSC in the terminal, it tells you error too, but why would you switch to the terminal to see what you already know? - You've just change the string in your tsx, why isn't the browser updated now 2 seconds after the change, don't you do this like a hundred times everyday, why put up with this for some terminal message you never read? - You run tsc in git hook/CI too, so for any version of the code, tsc runs 3 or 4 times: once in the IDE, once in the terminal and once or twice for CI & githook. Doesn't it sound dumb?
      - nawgz 5y ago
        > backend only Lol, not even close pal > tsc cold starts in terminal ??? Why would it be only possible to cold start in the terminal and hot start in the IDE? > you update the code, the IDE tells you the error Well, we’re making ridiculous assumptions about each other, do you only code in a single TS file? How on earth do you never impact a call site that isn’t the one you’re looking at immediately? The IDE is useless in this case. Option click to open offending lines is way more valuable than red highlighting that may or may not be stale > why isn’t the browser updated 2sec after But it clearly is? Maybe you have some bad use of tsc watch or something. I suggest you revisit your dev command…
        nsonha 5y ago
        could you maybe chill, no need to "pal"... lol? > Why would it be only possible to cold start in the terminal why do you ask me, do you know the command to start tsc "hot"? Please tell me? > How on earth do you never impact a call site that isn’t the one you’re looking at immediately? The IDE is useless in this case even if you've never used an IDE before, the whole idea is that it understands the concept of a project and does static check project-wide. I would call what you said a "ridiculous assumption", because of course IDE shows errors project-wide. Actually speaking of which, good luck with project-wide errors that overflow your terminal buffer. > I suggest you revisit your dev command… the 2 secs is just an example, I don't do that stuff anymore, like you I'm just engaging in the conversation to project my opinions. I would like to add that making a tsc alternative is a massive job & not proven possible so far, so the only room left for performance improvements is making alternative "transpilers". That's probably the answer to why these tools started as babel alternatives and not tsc alternatives

nawgz 5y ago

> For this reason most large typescript code based I’ve seen run their build and type checking steps separately How big are we talking here? I have a mid-6-figures LOC codebase and the TypeScript compiler time is essentially negligible. I can't really understand how TSC is being compared to a full test suite in your world, the code is invalid if the types don't pass, so I'm more than happy to give it 1sec to tell me if I have a type mismatch

nsonha 5y ago
> compiler time is essentially negligible It is, but not neligible enough for hot reload. But people don't want to run tsc mostly because their IDEs already do and give them a better experience than constantly checking the terminal.
- nawgz 5y ago
  > not negligible enough for hot reload How trivial does a change have to be that a subsecond compile time is offensive? The IDE takes longer than the terminal and is much less consistent. Anyhow, if this crowd truly exists then this is the tool for them, these optimizations seem to be simply for something to do rather than a real development issue in my opinion
  - nsonha 5y ago
    > The IDE takes longer than the terminal and is much less consistent I don't think that's true given tsc in the terminal needs to cold-start. Do you only do back-end? Let me paint the picture of a front-end workflow for you: - You are using VSCode or InteliJ, there is no way to opt-out of typescript, so even if you prefer the terminal, the IDE already runs tsc - You update the code, IDE tells you error. If you are running TSC in the terminal, it tells you error too, but why would you switch to the terminal to see what you already know? - You've just change the string in your tsx, why isn't the browser updated now 2 seconds after the change, don't you do this like a hundred times everyday, why put up with this for some terminal message you never read? - You run tsc in git hook/CI too, so for any version of the code, tsc runs 3 or 4 times: once in the IDE, once in the terminal and once or twice for CI & githook. Doesn't it sound dumb?
    - nawgz 5y ago
      > backend only Lol, not even close pal > tsc cold starts in terminal ??? Why would it be only possible to cold start in the terminal and hot start in the IDE? > you update the code, the IDE tells you the error Well, we’re making ridiculous assumptions about each other, do you only code in a single TS file? How on earth do you never impact a call site that isn’t the one you’re looking at immediately? The IDE is useless in this case. Option click to open offending lines is way more valuable than red highlighting that may or may not be stale > why isn’t the browser updated 2sec after But it clearly is? Maybe you have some bad use of tsc watch or something. I suggest you revisit your dev command…
      - nsonha 5y ago
        could you maybe chill, no need to "pal"... lol? > Why would it be only possible to cold start in the terminal why do you ask me, do you know the command to start tsc "hot"? Please tell me? > How on earth do you never impact a call site that isn’t the one you’re looking at immediately? The IDE is useless in this case even if you've never used an IDE before, the whole idea is that it understands the concept of a project and does static check project-wide. I would call what you said a "ridiculous assumption", because of course IDE shows errors project-wide. Actually speaking of which, good luck with project-wide errors that overflow your terminal buffer. > I suggest you revisit your dev command… the 2 secs is just an example, I don't do that stuff anymore, like you I'm just engaging in the conversation to project my opinions. I would like to add that making a tsc alternative is a massive job & not proven possible so far, so the only room left for performance improvements is making alternative "transpilers". That's probably the answer to why these tools started as babel alternatives and not tsc alternatives