6 ms·

I have found it a bit difficult to understand how TypeScript is involved here. Are they using the actual `tsc` library, or have they rolled their own? It is not

by nawgz 5y ago

I have found it a bit difficult to understand how TypeScript is involved here. Are they using the actual `tsc` library, or have they rolled their own? It is not very clear from the docs, overall I feel TypeScript support seems a bit of an afterthought reading thru the docs - they are very JS heavy in all examples

replygirl 5y ago
they rolled their own. if you're not emitting types it can be a lot faster than tsc
Arnavion 5y ago
The parser supports parsing TS enough to be able to strip the TS-specific syntax. It doesn't run `tsc`, and it doesn't type-check or anything like that.
- styfle 5y ago
  TS type checking is on the roadmap https://github.com/swc-project/swc/issues/571 https://github.com/swc-project/swc/issues/571
  - Arnavion 5y ago
    Interesting. I agree with the discussion thread that it would be a monumental task both to implement and then to keep up-to-date. I personally don't see the point, but I wish them luck.
- pjmlp 5y ago
  For me that is equally to not supporting Typescript.
  - kylecordes 5y ago
    The general idea, I think: Run something like this for low latency development. Edit, save, see results, repeat. In parallel, run the TypeScript compiler to eventually display type errors, inform your IDE with what it needs to deliver great completion, etc.
    - pjmlp 5y ago
      The Typescript compiler already generates the JS that we need, so nothing gained.
      - nsonha 5y ago
        you don't care about speed, we get it if things like swc does not exist then deno would have to use tsc, which is slower and contradict with being a replacement to nodejs, which is what tsc runs on
        pjmlp 5y ago
        The judge is still out there if Deno will ever matter on the great scheme of things. But what do I know, I am a big fan of vanilajs, great framework.
        nsonha 5y ago
        that doesn't matter, I don't use deno either. The point is that this makes it possible.
        pjmlp 5y ago
        Probably, just like plenty of other cool frontend stuff that keeps trying to be the next best thing. But I don't mind, after all where would all those consulting gigs to port back to boring tech originate from? We need to keep the economy wheel turning.
        nsonha 5y ago
        In my observation, the people who complains about kool-aid are often the ones who are obsessed with kool-aid. They may not drink it, but they learn about where the stuff is sold, what's in it and everything. Why do you even give a shit dude? Use what you like and let other people do their things. What's with all these snobbish comments about vanilajs and this industry? They are a dime dozen and don't make you worth listening to.
- nawgz 5y ago
  Yes, it was what I feared, this to me is terrible news. I have experience with libraries running fake TS clones and then requiring an endless pile of type refactoring if you need to extend it in some way. That said, I can understand one would want to use TypeScript and this in parallel, I just caution those going down this road that it is very easy to find yourself not really using TypeScript, and the second your TS doesn't compile with the official TS compiler, you are going to have upset users - and they might even be yourself! I for example quite liked ESBuild until I found situations where it didn't work, and then all those "instant" compiles were forgotten because I had to dig through esoteric, outside-of-my-expertise error messages and issues. Quick, type-safe hot reloading should be the target of course, but giving up type safety for speed is really not a good tradeoff.
  - Arnavion 5y ago
    The existence of a fast type-stripping compiler like swc just means that people would use `tsc` to only type-check, then use swc to compile to JS. The expectation being that the cost of invoking swc is outweighed by it being faster than tsc's emit and/or generating better output. TS is already designed around having the type-checking and the JS output be completely independent, so `tsc` cannot do a better job than an external compiler in regards to the quality of the generated code. In other words, instead of `tsc` you run `tsc --noEmit && swc` You still need to know about the actual types in the program, and you still need to run them through `tsc` first regardless of whether `swc` accepts them or not.
    - nawgz 5y ago
      Simply put, compiling code that does not pass the type checking is a waste of cycles, and I have seen footguns in this way. I don’t really see the value in weakening your type safety and compiler guarantees in exchange for 100ms compile time.
      - Arnavion 5y ago
        >Simply put, compiling code that does not pass the type checking is a waste of cycles, and I have seen footguns in this way. Nowhere in my comment did I say that.
- Rapzid 5y ago
  It supports decorators and emit decorator metadata so it does go just that bit further to make it mostly work for everything.
nsonha 5y ago
tsc is a compiler with type checking capability. This is merely a "transpiler" that transform TS to JS, an alternative to babel
- nawgz 5y ago
  Yes, that I think is the source of my confusion - labelling oneself as a TypeScript compiler while actually not doing any type checking is slightly misleading, and the resultant builds being legal even while the TS is not is a strange paradigm to me, even if I recognize workarounds / other strategies exist
  - charrondev 5y ago
    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.

by nawgz 5y ago

replygirl 5y ago

they rolled their own. if you're not emitting types it can be a lot faster than tsc

Arnavion 5y ago

The parser supports parsing TS enough to be able to strip the TS-specific syntax. It doesn't run `tsc`, and it doesn't type-check or anything like that.

styfle 5y ago
TS type checking is on the roadmap https://github.com/swc-project/swc/issues/571 https://github.com/swc-project/swc/issues/571
- Arnavion 5y ago
  Interesting. I agree with the discussion thread that it would be a monumental task both to implement and then to keep up-to-date. I personally don't see the point, but I wish them luck.
pjmlp 5y ago
For me that is equally to not supporting Typescript.
- kylecordes 5y ago
  The general idea, I think: Run something like this for low latency development. Edit, save, see results, repeat. In parallel, run the TypeScript compiler to eventually display type errors, inform your IDE with what it needs to deliver great completion, etc.
  - pjmlp 5y ago
    The Typescript compiler already generates the JS that we need, so nothing gained.
    - nsonha 5y ago
      you don't care about speed, we get it if things like swc does not exist then deno would have to use tsc, which is slower and contradict with being a replacement to nodejs, which is what tsc runs on
      - pjmlp 5y ago
        The judge is still out there if Deno will ever matter on the great scheme of things. But what do I know, I am a big fan of vanilajs, great framework.
        nsonha 5y ago
        that doesn't matter, I don't use deno either. The point is that this makes it possible.
        pjmlp 5y ago
        Probably, just like plenty of other cool frontend stuff that keeps trying to be the next best thing. But I don't mind, after all where would all those consulting gigs to port back to boring tech originate from? We need to keep the economy wheel turning.
        nsonha 5y ago
        In my observation, the people who complains about kool-aid are often the ones who are obsessed with kool-aid. They may not drink it, but they learn about where the stuff is sold, what's in it and everything. Why do you even give a shit dude? Use what you like and let other people do their things. What's with all these snobbish comments about vanilajs and this industry? They are a dime dozen and don't make you worth listening to.
nawgz 5y ago
Yes, it was what I feared, this to me is terrible news. I have experience with libraries running fake TS clones and then requiring an endless pile of type refactoring if you need to extend it in some way. That said, I can understand one would want to use TypeScript and this in parallel, I just caution those going down this road that it is very easy to find yourself not really using TypeScript, and the second your TS doesn't compile with the official TS compiler, you are going to have upset users - and they might even be yourself! I for example quite liked ESBuild until I found situations where it didn't work, and then all those "instant" compiles were forgotten because I had to dig through esoteric, outside-of-my-expertise error messages and issues. Quick, type-safe hot reloading should be the target of course, but giving up type safety for speed is really not a good tradeoff.
- Arnavion 5y ago
  The existence of a fast type-stripping compiler like swc just means that people would use `tsc` to only type-check, then use swc to compile to JS. The expectation being that the cost of invoking swc is outweighed by it being faster than tsc's emit and/or generating better output. TS is already designed around having the type-checking and the JS output be completely independent, so `tsc` cannot do a better job than an external compiler in regards to the quality of the generated code. In other words, instead of `tsc` you run `tsc --noEmit && swc` You still need to know about the actual types in the program, and you still need to run them through `tsc` first regardless of whether `swc` accepts them or not.
  - nawgz 5y ago
    Simply put, compiling code that does not pass the type checking is a waste of cycles, and I have seen footguns in this way. I don’t really see the value in weakening your type safety and compiler guarantees in exchange for 100ms compile time.
    - Arnavion 5y ago
      >Simply put, compiling code that does not pass the type checking is a waste of cycles, and I have seen footguns in this way. Nowhere in my comment did I say that.
Rapzid 5y ago
It supports decorators and emit decorator metadata so it does go just that bit further to make it mostly work for everything.

nsonha 5y ago

tsc is a compiler with type checking capability. This is merely a "transpiler" that transform TS to JS, an alternative to babel

nawgz 5y ago
Yes, that I think is the source of my confusion - labelling oneself as a TypeScript compiler while actually not doing any type checking is slightly misleading, and the resultant builds being legal even while the TS is not is a strange paradigm to me, even if I recognize workarounds / other strategies exist
- charrondev 5y ago
  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.