Fair. But I've seen a bunch of CI/CD flows that compile the source multiple times within the context of a single build. If you have one tsc build that checks the types first, then subsequent builds could be greatly accelerated with esbuild or scw.
The CRA example is probably a red herring. The whole point of esbuild and swc is that you do *not* need a node.js process iterating over all of your code/syntax trees, and by using CRA, you're basically saying: pick whatever tools necessary to package my project. Under the hood CRA still uses all of the usual tools, and likely one of those tools is still running node.js and touching all kinds of input. Because CRA tries to hide all that complexity under a simple cover, it's easy to miss "implementation details" that entirely defeat the point of something like esbuild or swc. In short, if you want to use CRA with esbuild, you should probably eject from CRA and pin down exactly what CRA is doing to your code - it *should* be running exactly 0 non-esbuild-or-swc modules on it, but you'll likely find it's not. Additionally, it's important to point out that these tools are not full replacements for tsc; they don't do typechecking, and their downlevelling is likely not the same as tsc's or even missing. But the whole point of typescript is type checking, so a real world esbuild config will want to have some kind of way of doing type-checking separate from the build - potentially in a background process, or hooked into whatever IDE you're using; something. But simply replacing a bog-standard webpack-with-tsc config with esbuild is a bad idea for most people; they're losing type checking without noticing!
Hi Jack! I've checked out some of your videos and you really seem professional, and I'm really interested on what a professional would put in his CV. Projects mostly, maybe? Can you make a video on your CV, what extra information you left out of it, and what you recommend for others (from beginners to professionals) to put in their CV? Thank you in advance!
In one project of my company where I can do whatever I want (as long as everything works) I replaced webpack with pure esbuild launched via node and pipelines dropped by tens of seconds Also I am working on migrating one project CRA to pure esbuild too and I spent some time on setting proper dev env using esbuild as current ones resulted in infinite refresh (websocket is a spot-on) Now, I'm working on building it and checking if it may work (quite stupid I didn't do it in the first place, but I really wanted to check it, if my idea works)
I assume you mean "quantify it"? If so, I would compare build times with and without it. And then to gauge the impact of that I would multiply that delta it by the number of builds I would expect the average developer and/or CI/CD pipeline to do daily.
Thanks for thr hard work Jack! This work has probably saved some jobs where they could have recommended swc at work and then had to backtrack to using standard tooling. I am however interested how vite projects are so blazing fast with esbuild. Worth keeping an eye on Rome build tooling?
Good video, thanks! Did you perhaps try swc and esbuild to speed up jest tests? I tried that on a fairly big project but it was actually slower, wonder if I'm missing something
i currently use nextjs and honestly after watching this video i realized that i am so illiterated about whats going on under the compiling hood . Any advice where to start to learn react compiling stuff ? we watchers really appreciate your effort to make this kind of great videos, thanks
Great video，thanks. But i have a little confused😳. Why swc performance is worse，Rust is lower level language than Go. I guessed swc should be better performance，in fact is not
Running Next 11.1.0 with Esbuild: github.com/valoricDe/esbuild-loader-examples/tree/master/examples/next In the project I freelance for we got a speed increase from 46 seconds to 24 seconds. @JHerr Maybe you could include this setup to the comparison?
10:39 watching your video is like having a senior tech-lead in our team, thanks for the precious Time Saving.
well he is basically a tech lead lol lol xD Aren't you!??
I would love to see another one of these now that nextjs 12 has SWC along with the minification
And nextJs 13 compare to turbopack too
Very insightful information in here, thanks for the research
Awesome stuff! Thanks a lot for this comparison. I will dive deeper into the compilers and try to optimize my projects.
Thanks for the crystal clear explanation!
Awesome video! Thank you for sharing your findings! Love the shirt as well!
Great video Jack Thank you.
Thanks for putting in the time to research these! Great video, will definitely look into these tools.
I would not use esbuild or swc as the replacement for tsc on ci/cd, because they do not do typecheck. You cannot ignore it.
Fair. But I've seen a bunch of CI/CD flows that compile the source multiple times within the context of a single build. If you have one tsc build that checks the types first, then subsequent builds could be greatly accelerated with esbuild or scw.
The CRA example is probably a red herring. The whole point of esbuild and swc is that you do *not* need a node.js process iterating over all of your code/syntax trees, and by using CRA, you're basically saying: pick whatever tools necessary to package my project. Under the hood CRA still uses all of the usual tools, and likely one of those tools is still running node.js and touching all kinds of input. Because CRA tries to hide all that complexity under a simple cover, it's easy to miss "implementation details" that entirely defeat the point of something like esbuild or swc.
In short, if you want to use CRA with esbuild, you should probably eject from CRA and pin down exactly what CRA is doing to your code - it *should* be running exactly 0 non-esbuild-or-swc modules on it, but you'll likely find it's not.
Additionally, it's important to point out that these tools are not full replacements for tsc; they don't do typechecking, and their downlevelling is likely not the same as tsc's or even missing. But the whole point of typescript is type checking, so a real world esbuild config will want to have some kind of way of doing type-checking separate from the build - potentially in a background process, or hooked into whatever IDE you're using; something. But simply replacing a bog-standard webpack-with-tsc config with esbuild is a bad idea for most people; they're losing type checking without noticing!
Cant wait for this 😀
@jherr I think swc is faster now. Maybe you want compare again in 2024!???
wow, this is awesome, need to share it with teammates now :)
Hi Jack! I've checked out some of your videos and you really seem professional, and I'm really interested on what a professional would put in his CV. Projects mostly, maybe? Can you make a video on your CV, what extra information you left out of it, and what you recommend for others (from beginners to professionals) to put in their CV? Thank you in advance!
That's a great idea. I would definitely put work projects and personal projects in there, particularly if they are also on github.
great video
In one project of my company where I can do whatever I want (as long as everything works) I replaced webpack with pure esbuild launched via node and pipelines dropped by tens of seconds
Also I am working on migrating one project CRA to pure esbuild too and I spent some time on setting proper dev env using esbuild as current ones resulted in infinite refresh (websocket is a spot-on)
Now, I'm working on building it and checking if it may work (quite stupid I didn't do it in the first place, but I really wanted to check it, if my idea works)
helping you to break RUclips algorithm
I have a comment! 🙂
Thank you very much, it's amazing! ⚡⚡⚡
Great content thank you sir
Best content jack :)
I would like to see these technologies in deno.
Could u plz make tutor about integrating them?🌺🌺❤❤❤
Thanks!
esbuild transpiles only index.ts file in library-pathologic example and not the whole src folder, i guess that's why numbers differ so drastically
Awesome content Jack, many thanks!
And.. nice shirt, what is that? 😬
It’s just an Eddie Bauer print shirt. I asked the saleswoman to suggest something that popped on camera and she did not disappoint. 😂
Wonder why Esbuild is faster, thought SWC would be faster because written in Rust
esbuild author @evanw: "Go version was faster because GC happened on another thread while Rust had to run destructors on the same thread"
Really nice comparison 👍. Is it also a good idea to compare snowpack and vitejs? Or not as it’s using webpack and rollup for prod build? 😬
Snowpack and vite both use esbuild for dev and webpack / rollup for build... So that way we already know how they might perform.
Needs to compere with vite also.
Today, is there better option?
Curious about how would you quantity the impact of reducing the build time by x minutes. Can you please give a rough example
I assume you mean "quantify it"? If so, I would compare build times with and without it. And then to gauge the impact of that I would multiply that delta it by the number of builds I would expect the average developer and/or CI/CD pipeline to do daily.
Thanks for thr hard work Jack! This work has probably saved some jobs where they could have recommended swc at work and then had to backtrack to using standard tooling. I am however interested how vite projects are so blazing fast with esbuild. Worth keeping an eye on Rome build tooling?
Vite is definitely worth keeping up with, as is Rome given its FB backing.
Good video, thanks! Did you perhaps try swc and esbuild to speed up jest tests? I tried that on a fairly big project but it was actually slower, wonder if I'm missing something
Great video, thanks! Are you going to do a comparison with nextjs 12 that leverages SWC?
Is it out?
@@jherr it is now :)
Good video
Probably a dumb question, but do the outputs of each builder differ? Is the output of tsc always the same as esbuild?
Thank you so much Jack for the great content. btw, I really liked your vs code theme? What theme is that? do you have your uses listed somewhere?
I've started putting my theme in the description. It's Night Wolf [dark blue] with MonoLisa.
Pimp my Compiler 😎
nice video
Since there is a reference to the good Doctor, I demand you do a research on time mechanics so I can go back in time and re-thumbs up the video.
Hahah! Nice!
nice shirt :D
i currently use nextjs and honestly after watching this video i realized that i am so illiterated about whats going on under the compiling hood .
Any advice where to start to learn react compiling stuff ?
we watchers really appreciate your effort to make this kind of great videos, thanks
Any comparison to TSC has to have type checking or else the test is completely apples to oranges imo.
I think these compilers are, at least currently, good for rapid compilation after a typechecking pass by tsc.
"npm-run-all --parallel tsc esbuild"
Great video，thanks. But i have a little confused😳. Why swc performance is worse，Rust is lower level language than Go. I guessed swc should be better performance，in fact is not
The difference at scale isn't super huge. Maybe they just have less efficient file I/O.
382 Isai Gardens
amazing content :)
Please make an update in 2024 🙏🏽 I believe swc may be faster now
ruuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuust
You rock! Subscribe + like
Bad comparison. Running on a tiny target file is super bias, because any build tool will need warmup time, and the real runtime is much different.
That’s why I compared it on large sets of files as well.
Waiting for cra and @craco to add a stable version of webpack v5 support.
Nice video.
Running Next 11.1.0 with Esbuild: github.com/valoricDe/esbuild-loader-examples/tree/master/examples/next
In the project I freelance for we got a speed increase from 46 seconds to 24 seconds.
@JHerr Maybe you could include this setup to the comparison?
Absolutely! I'll check it out!