[HN Gopher] Speedy Web Compiler - a fast TypeScript/JavaScript c...
       ___________________________________________________________________
        
       Speedy Web Compiler - a fast TypeScript/JavaScript compiler
        
       Author : andrewstuart
       Score  : 55 points
       Date   : 2021-12-20 20:17 UTC (2 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | beepbooptheory wrote:
       | Even if this was faster than esbuild by whatever milliseconds, I
       | would still probably go with esbuild for the api. esbuild is a
       | delightfully raw, scriptable thing, that is as simple or
       | complicated as you want, you just make the node scripts and fun
       | the functions. Config with swc looks to more closely resemble
       | babel/webpack with extensive config objects, which is fine, but
       | it can only mean that it loses out to esbuild for me.
       | 
       | But I am not a professional or anything like that, so very much
       | YMMV!
        
         | k__ wrote:
         | I don't understand the difference between esbuild and swc.
        
           | eyelidlessness wrote:
           | SWC is built in Rust, esbuild isn't. /s
           | 
           | Realistically they have fairly different goals:
           | 
           | - esbuild's goal is to be a fast JS/JSX/TS compiler and
           | bundler with a simple plugin system to extend its behavior.
           | It's expected to largely stop adding scope there.
           | 
           | - SWC's goal is to be a fast JS/JSX/TS compiler, bundler, and
           | extensible code transformer with broad compatibility with
           | Babel and direct support for AST transformation. It's also
           | integrated into Deno, in a lower level way than APIs exposed
           | by esbuild, so it's a fair bit more general purpose (whether
           | that's intended or not, I don't know).
        
       | slig wrote:
       | I'd rather not deal with dozens of babel-plugin-*. Can this or
       | esbuild be used instead of babel?
        
         | [deleted]
        
         | leerob wrote:
         | Yes. SWC is being used by Next.js to replace Babel. With SWC,
         | compilation is about 17x faster than Babel in v12[1]. We
         | created a CSS parser in Rust (through SWC), as well as ported
         | many of the common Babel plugins to Rust[2]. Work is still
         | ongoing here[3].
         | 
         | [1]: https://nextjs.org/blog/next-12#faster-builds-and-fast-
         | refre...
         | 
         | [2]: https://nextjs.org/docs/advanced-features/compiler
         | 
         | [3]: https://github.com/vercel/next.js/discussions/30174
        
           | machiaweliczny wrote:
           | Those promises don't seem true in practice. I've tested next
           | 11 vs 12 and got 0 speedup. Maybe because of M1 mac. IDK,
           | would need to dig deeper - anyone had similar case?
        
             | nsonha wrote:
             | check the upgrading guide
             | 
             | > When an application has a custom Babel configuration,
             | Next.js will automatically opt-out of using SWC
             | 
             | if they don't show a warning like they did with webpack 5
             | then that needs to be improved.
        
               | machiaweliczny wrote:
               | Removed babel config. Maybe because I wasn't using babel
               | much (just to transpile for more compatibility).
        
               | leerob wrote:
               | (I work at Vercel) Happy to take at your application if
               | you want. You can DM me on Twitter:
               | https://twitter.com/leeerob
        
           | slig wrote:
           | Fantastic, thank you very much!
        
       | robertwt7 wrote:
       | Why are people comparing this with esbuild? Isn't esbuild a
       | minifier and bundler, so it can replace webpack. As opposed to
       | SWC replacing babel? Am i missing something?
        
         | beepbooptheory wrote:
         | I think both esbuild and SWC remove the need to distinguish
         | between a bundler and a transpiler. They both can do both.
         | Esbuild only understands an AST that can "compile" to js, so it
         | does what babel does just in that, can't speak to SWC but I bet
         | it's the same situation.
        
       | lefrenchy wrote:
       | With NextJS having a stake in this, i'm excited for the future of
       | it! Awesome project.
        
       | manigandham wrote:
       | Commonly called "swc" and often compared to esbuild:
       | https://github.com/evanw/esbuild
        
         | [deleted]
        
       | nawgz wrote:
       | 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 wrote:
         | they rolled their own. if you're not emitting types it can be a
         | lot faster than tsc
        
         | Arnavion wrote:
         | 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.
        
           | pjmlp wrote:
           | For me that is equally to not supporting Typescript.
        
             | kylecordes wrote:
             | 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.
        
           | nawgz wrote:
           | 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.
        
           | styfle wrote:
           | TS type checking is on the roadmap
           | 
           | https://github.com/swc-project/swc/issues/571
        
             | Arnavion wrote:
             | 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.
        
         | nsonha wrote:
         | tsc is a compiler with type checking capability. This is merely
         | a "transpiler" that transform TS to JS, an alternative to babel
        
       | eatonphil wrote:
       | If you're curious about the difference between this and esbuild,
       | TypeScript, and Babel, I wrote up a bit of background and did
       | some independent benchmarks of TypeScript/React app build times
       | [0]. SWC does well!
       | 
       | [0]
       | https://datastation.multiprocess.io/blog/2021-11-13-benchmar...
        
       ___________________________________________________________________
       (page generated 2021-12-20 23:01 UTC)