5 ms·

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.
        pjmlp 5y ago
        I give a shit because at the end of the day I occasionally have to give support to magpie developers even when I rather be busy with something else.
        nsonha 5y ago
        > big fan of vanilajs, great framework. no one asked, did you expect a trophy or something?
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.

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.
        pjmlp 5y ago
        I give a shit because at the end of the day I occasionally have to give support to magpie developers even when I rather be busy with something else.
      - nsonha 5y ago
        > big fan of vanilajs, great framework. no one asked, did you expect a trophy or something?

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.