The definitive Javascript performance comparison of Babel and SWC for your business

Babel is a free and open-source JavaScript transpiler. It is mainly converted ES6 or above version code into a backward-compatible version of JavaScript that can run in any browser along with the older one. Whereas, SWC is a typescript/javascript compiler, which takes next-generation javascript input and emits javascript codes which work on the old browsers. These two are becoming more and more evident today.

eCommerce businesses, in general, can choose whatever platform they like, depend on the scale of their businesses. Yet, the internet doesn’t have enough resources for e-merchants to choose the appropriate tool. So now, we – ArrowHiTech would like to introduce to you guys the javascript performance comparison of Babel and SWC. By reading this article, you can choose the perfect one for your business.

Compare the speed (benchmark) between Babel and SWC for Javascript performance comparison

Benchmark (in theory)

First, we compare them in an artificial way and that is running code transformation for javascript performance comparison in a synchronous manner. So now, let’s do a benchmark for the single-core workload. Note that this uses transformSync, which is rarely useful in the real world.

 [transform]
  swc (ES3) x 616 ops/sec ±4.36% (88 runs sampled)
  swc (ES2015) x 677 ops/sec ±2.01% (90 runs sampled)
  swc (ES2016) x 1,963 ops/sec ±0.45% (93 runs sampled)
  swc (ES2017) x 1,971 ops/sec ±0.35% (94 runs sampled)
  swc (ES2018) x 2,555 ops/sec ±0.35% (93 runs sampled)
  swc-optimize (ES3) x 645 ops/sec ±0.40% (90 runs sampled)
  babel (ES5) x 34.05 ops/sec ±1.15% (58 runs sampled)

Well, so SWC is very fast (which is an expected result). Although SWC (ES3) does more work than Babel (ES5), SWC (ES3) is faster than Babel (ES5).

Real speed of javascript performance comparison

However, transformSync and transformFileSync are rarely used int the real world, as it blocks the current thread, and everything stops. In other words, it would be impossible to run heavy computations in an asynchronous way in a real-life application. So, if we want to benchmark a more realistic scenario, we can run samples against await Promise.all(). This is certainly a more expensive and real scenario to compare between Babel and SWC.

With this benchmark, the number of CPU cores and parallel computations come into play instead. Both used a computer with 8 CPU cores with a parallelism of 4. Then, the output below is copied as-is from benchmark output.

 CPU Core: 8; Parallelism: 4
Note that output of this benchmark should be multiplied by 4 as this test uses Promise.all

[multicore]
swc (ES3) x 426 ops/sec ±3.75% (73 runs sampled)
swc (ES2015) x 422 ops/sec ±3.57% (74 runs sampled)
swc (ES2016) x 987 ops/sec ±2.53% (75 runs sampled)
swc (ES2017) x 987 ops/sec ±3.44% (75 runs sampled)
swc (ES2018) x 1,221 ops/sec ±2.46% (77 runs sampled)
swc-optimize (ES3) x 429 ops/sec ±1.94% (82 runs sampled)
babel (ES5) x 6.82 ops/sec ±17.18% (40 runs sampled)

Then, we need to multiply this result by 4, as we do 4 operations per iteration for Babel and SWC.

 swc (ES3) x 1704 ops/sec ±3.75% (73 runs sampled)
swc (ES2015) x 1688 ops/sec ±3.57% (74 runs sampled)
swc (ES2016) x 3948 ops/sec ±2.53% (75 runs sampled)
swc (ES2017) x 3948 ops/sec ±3.44% (75 runs sampled)
swc (ES2018) x 4884 ops/sec ±2.46% (77 runs sampled)
swc-optimize (ES3) x 1716 ops/sec ±1.94% (82 runs sampled)
babel (ES5) x 27.28 ops/sec ±17.18% (40 runs sampled)

So this is an actual result: The performance of Babel (ES5) is dropped. In general, we see a clear speed gap between the two tools, as SWC tends to be around 20 times faster than the latter on a single thread and CPU core basis while being around 60 times faster in a multi-core async operation process.

Benchmark for many works

This time, we will perform a little differently. The benchmark file is altered to make it creates 100 promises per iteration instead. As a result below:

 CPU Core: 8; Parallelism: 100
Note that output of this benchmark should be multiplied by 100 as this test uses Promise.all

[multicore]
swc (ES3) x 21.99 ops/sec ±1.83% (54 runs sampled)
swc (ES2015) x 19.11 ops/sec ±3.39% (48 runs sampled)
swc (ES2016) x 55.80 ops/sec ±6.97% (71 runs sampled)
swc (ES2017) x 62.59 ops/sec ±2.12% (74 runs sampled)
swc (ES2018) x 81.08 ops/sec ±5.22% (75 runs sampled)
swc-optimize (ES3) x 18.60 ops/sec ±2.13% (50 runs sampled)
babel (ES5) x 0.32 ops/sec ±19.10% (6 runs sampled)

After that, we need to multiply the result with 100. Then:

   swc (ES3) x 2199 ops/sec ±1.83% (54 runs sampled)
swc (ES2015) x 1911 ops/sec ±3.39% (48 runs sampled)
swc (ES2016) x 5580 ops/sec ±6.97% (71 runs sampled)
swc (ES2017) x 6259 ops/sec ±2.12% (74 runs sampled)
swc (ES2018) x 8108 ops/sec ±5.22% (75 runs sampled)
swc-optimize (ES3) x 1860 ops/sec ±2.13% (50 runs sampled)
babel (ES5) x 32 ops/sec ±19.10% (6 runs sampled)

So, you may be curious why does the performance of SWC does not drop drastically. The secret is node js. node js internally manages a worker thread pool, and SWC runs on it, obviously. Thus, even though you create 100 promises at once, the number of worker threads is much smaller than it.

Final words

So, we have covered the basics of javascript performance comparison. To conclude, the performance of SWC is much better than that of Babel, yet this tool may meet the perfect budget estimation of computations. As a result, you can choose the perfect tools you want, yet you should consider the scale of your business as well as how your website should perform for users.

arrowhitech
ArrowHiTech services

Tags

Share