Speedy Web Compiler – a fast TypeScript/JavaScript compiler
github.com
github.com
[0] https://datastation.multiprocess.io/blog/2021-11-13-benchmar...
But I am not a professional or anything like that, so very much YMMV!
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).
[1]: https://nextjs.org/blog/next-12#faster-builds-and-fast-refre...
> 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.
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.
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
But what do I know, I am a big fan of vanilajs, great framework.
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.
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.
no one asked, did you expect a trophy or something?
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.
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.
Nowhere in my comment did I say that.
no, have you ever done hot reload in front-end development? When you make a typo on a type definition do you want tsc to bail & the whole application state to be lost? I guess CPU cycles are more valuable than your time?
edit: btw tcs does NOT bail, so your argument is moot because the typescript compiler itself "wastes cycles" like that.
> weakening your type safety
nothing is "weakened" here, what happens is, people can continue to work/test different parts of the codebase without having the full project type-checked out.
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.
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
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.
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
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?
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…
> 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
I really don't get this CLI "optimisations" as well.
The Jenkins server couldn't care less for a couple of shaved seconds.
If you're looking for fast compile times with type checking, we've been using JS++ [0], which is written in C/C++.
Cool to learn about JS++ but unlike babel/typescript/esbuild/swc JS++ cannot read TypeScript, it's a completely new/different language.