Babel vs. TypeScript in 2022

What is the best Compiler for JavaScript?

Charuka Herath
Bits and Pieces

--

Code splitting is widely used in JavaScript-based web development to improve the productivity and the maintainability of the code base with growth. However, we need to bundle and transpile these files when we execute them.

Bundling creates a set of optimized files by removing unused code snippets and transpiring converts all the new JavaScript syntaxes and features to ES5 syntax to make them backward compatible.

TypeScript and Babel are the two most used tools for Transpiling and Polyfilling, and this article will discuss the differences between them and help you choose the best for your project.

What is TypeScript?

TypeScript is one of the most used programming languages among web developers. It works as a linting layer on top of JavaScript and enforces types to help developers minimize common errors.

Most importantly, TypeScript has its own compiler. As a result, it can convert .ts files into .js files and makes it easier for browsers to execute them.

What is Babel?

Babel is another popular compiler that converts modern JavaScript syntax and features into ES5. It has significant features like syntax transformation, Polyfilling, code transformations.

Out of these, polyfilling is one of the most valuable features, and it makes sure that your application is universally compatible across different browser versions.

Furthermore, Babel supports the latest version of JavaScript through syntax transformers and allows developers to use new syntax without waiting for browser support.

Understand the Differences

Although Babel and TypeScript are compilers, they have some significant differences. Understanding these differences will help you find the best compiler for your project.

1. Type checking is not available in Babel

Typescript is strongly typed, which means developers can check the validity of their variable values. However, Babel compiles codes without checking the types.

var typeCheckString : string = 11111;

The above code will compile in Babel without any errors. But in TypeScript, you will see a type error like the below:

When the types are not correctly initialized, removing types and compiling the code is a quick method to emit JS. But, if the developers need to use the correct types, it is essential to cross-check them.

Since Babel does not type-check your code, it has a faster emit time. However, you can also configure TypeScript without type checking by running the tsc -- noEmit command.

2. Auto polyfill is not available in TypeScript

Babel includes a polyfill that has a custom regenerator runtime and core-js. This will emulate a complete ES5+ environment to be used in applications rather than a library/tool. So, a polyfill is automatically loads when using Babel.

TypeScript only downgrades some language features when targeting earlier ECMAScript versions. The syntax is the main norm used to determine if a feature will be emitted as a downgraded code or if it needs a polyfill. If the new language feature is syntactically invalid in the targeted JS version, it will be downgraded, or you will get a compile-time warning.

3. Babel is more extensible than TypeScript

If you need to use custom transformation, Babel is the best solution. It supports a variety of plugins to optimize your code, while TypeScript only supports its own Transformer API with lesser features.

4. Use of decorators

Decorator support is one of the highlighted features in TypeScript. However, the decorator proposal for JavaScript is not yet finalized, and there are some mismatches between ECMAScript spec and TypeScript about decorator behaviors.

So, able does not compile the decorators similar to TypeScript, and we have to use the legacy mode. The legacy mode will compile decorators with old behavior, and we need to use @babel/plugin-proposal-decorators plugin and set the legacy option to true in the config file.

5. Identical performance

When it comes to performance, both TypeScript and Babel are identical. Although TypeScript takes some additional time for type checking, it does not significantly affect performance. Also, there are third-party plugins like fork-ts-checker-webpack-plugin to speed up the type checking process.

What should you choose?

As discussed, both the TypeScript compiler and Babel have their own way of handling things. So, developers have many opinions, and choosing one over the other can be a challenging task.

With the latest update of Babel, it has improved a lot, and the only disadvantage I see is its inability to do type checks. You need to use s custom process for that. With all the other aspects, both Babel and TypeScript compiler seem similar, and that’s why many developers suggest using them together.

Build composable web applications

Don’t build web monoliths. Use Bit to create and compose decoupled software components — in your favorite frameworks like React or Node. Build scalable and modular applications with a powerful and enjoyable dev experience.

Bring your team to Bit Cloud to host and collaborate on components together, and speed up, scale, and standardize development as a team. Try composable frontends with a Design System or Micro Frontends, or explore the composable backend with serverside components.

Give it a try →

https://cdn-images-1.medium.com/max/800/1*ctBUj-lpq4PZpMcEF-qB7w.gif

Conclusion

Having Babel and TypeScript do part of the source transform seems unnecessarily complicated. So, if you are using both, it is better to use Babel for transpiling and the TypeScript compiler for type checking.

The TypeScript documentation also recommends this approach, and it is widely used for projects that may have been ported from JavaScript to TypeScript.Here, you can use Babel’s preset-typescript to generate your JS files, and then use TypeScript to do type checking and .d.ts file generation.

However, if your build output is similar to the source files, it is better to use TypeScript to make things simpler.

Learn More

--

--

PhD in AI and CS at Loughborough University London, UK. EX-Senior SE Sysco Houston, USA