When building applications nowadays, we can feel flattered by the variety of tools and concepts that aim to help us ship more reliable code to production. There are many ways for us to become more confident about the code we write.
Among the options for shipping reliable code is static typing, which is a good way to catch errors early in the development cycle. Static typing allows for a faster development process while helping check the correctness of our code. In this article, we’ll talk about two languages that offer static typing: Dart and TypeScript.
We’ll cover:
Although the focus of this article is not to define static typing, it is important to revisit the reason why writing statically typed code can be a great benefit to the development experience.
Static typing allows us to analyze variable types at compile time, meaning that before executing your code, you will be able to know if there are errors with the way you’re using variables, like what types of values you’re assigning to them, for instance.
This helps decrease the amount of time spent debugging errors that might happen during runtime simply because, for example, you are calling a string related method on a variable that holds an integer value at some point in your code.
Because nothing comes without sacrifice, we should take into consideration the extra work we have to do when defining functions and variables that have explicit types. That work can vary from a few extra keystrokes to defining an entire object structure, specifying types for its keys and values while thinking about how to organize those types for reusability.
The examples below show what a simple code for the same functionality looks like in TypeScript and plain JavaScript, respectively:
Among statically typed languages, Dart and TypeScript are well-known and well-established options, each with distinct features. The goal of this article isn’t to take sides but to review the features of each language and how they compare to each other. Hopefully, this will give you useful insights on when and how to use them.
Dart, developed by Google, was first announced in 2011 as a replacement for JavaScript. According to their official website, “Dart is a client-optimized language for developing fast apps on any platform.” Dart is a more general-purpose language that offers optimization for writing and shipping code, not only for the web but for other client-oriented projects, such as mobile apps.
From the official TypeScript website, “TypeScript is JavaScript with syntax for types.” That definition, on its own, already clarifies a lot about what the language is. Launched back in 2012 by Microsoft, the language is a superset of JavaScript, meaning it was built on top of JavaScript, with new features added to it, such as type checking and resources for classical object-oriented programming.
Both Dart and TypeScript are open source languages and hosted on GitHub.
Based on the characteristics briefly described above, one might argue that it is illogical to compare the two languages, considering that TypeScript is a superset of JavaScript, while Dart is a full and entirely new scripting language, not built on top of JavaScript. However, for this post, we are looking at both of them from the perspective that they can be an option when working with statically typed languages. Also, when trying to move from JavaScript to a more robust language focused on building large-scale applications, Dart and TypeScript are both good options to consider.
For easier comparison, let’s select a few main points in which the two languages show differences and similarities.
Both Dart and TypeScript are considered multi-paradigm languages, meaning they offer features that allow the usage of techniques included in more than one programming paradigm.
For example, you can use either Dart or TypeScript when following a functional paradigm, where a program is built around functions that should handle immutable data and avoid sharing state. This is also true when you want to work with an object-oriented paradigm because both of them offer features included in classical OOP programming, such as classes, inheritance, encapsulation, and polymorphism.
Developers might have a preference for either Dart or TypeScript because there are a few differences in the way such features are implemented in each. One example of something that is not offered in Dart is method overloading, a useful technique where a single method name is used for multiple methods that implement different behaviors based on the method’s input.
Trying to achieve method overloading with Dart will require you to implement workarounds that might not always look great. Meanwhile, TypeScript officially supports the technique, which is implemented with its own specificities and limitations, like not being able to have different bodies for each method definition, forcing you to handle the different input types within one scope.
Before choosing Dart or TypeScript, you might want to not only do research on which paradigm you plan on following for your code, but also on how specific features or patterns are offered within each language.
When it comes to syntax, if you’re coming from JavaScript, Dart might be the bigger leap to take. This is because Dart is a full-on programming language with more robust features, instead of a superset of JavaScript, which might result in a steeper learning curve.
Dart might be a more appropriate option if you are coming from languages like C# and Java, because it has a syntax similar to theirs. Dart isn’t too far from JavaScript, but the learning curve is something you should keep in mind.
Below are examples of the same program in Dart and Typescript, respectively. Both scripts take one random and one hardcode integer, multiply them, and print the result:
As mentioned, both languages are open source and offer a welcoming environment for contributions. This is something to keep in mind and track because it tells you how willing developers will be to help improve the language and build tools surrounding it.
At the time of writing, Dart sdk repository on GitHub has over 8.5K stars and its package repository (pub.dev) for the language and for Flutter has over 29,000 packages.
As for TypeScript’s GitHub repository, as of the time of writing, it has 84.7K stars. For this comparison, the total number of npm packages with type declarations for libraries hosted on npm is 8,803. This is, of course, not including all other TypesScript-related packages that are not prefixed by “@types/” (the term used for the search in npm).
Dart has become more and more famous, especially after the release of Flutter, an open source framework that helps with shipping code to different platforms using a single codebase. Similar to that in the JavaScript world is React Native, which offers support for TypeScript by default. Considerations for choosing one or the other when building mobile apps is a topic for a more robust blog post, though.
As previously mentioned, Dart is a general-purpose language, meaning that even with its optimization surrounding client-focused projects, it is also used on the server side, with applications on command-line apps and IoT projects. Here is an example.
That is possible due to the multi-platform characteristic of Dart, which compiles optimized code to different platforms:
When it comes to TypeScript, there is a broad range of uses if we consider that whatever environment that you can use JavaScript in, you can also use with TypeScript. Ranging from building servers to game development and smartwatch apps, there is a universe of applications for TypeScript, simply because it is a version of the JavaScript language with extra features.
Choosing Dart or TypeScript for your next project is a matter of weighing the factors you are dealing with and the goals for your project. Both of them will offer you features for developing reliable large-scale applications. But time, developer experience, community, and the type of application you’re developing are all variables that will help you choose one or the other.
LogRocket is a frontend application monitoring solution that lets you replay problems as if they happened in your own browser. Instead of guessing why errors happen or asking users for screenshots and log dumps, LogRocket lets you replay the session to quickly understand what went wrong. It works perfectly with any app, regardless of framework, and has plugins to log additional context from Redux, Vuex, and @ngrx/store.
In addition to logging Redux actions and state, LogRocket records console logs, JavaScript errors, stacktraces, network requests/responses with headers + bodies, browser metadata, and custom logs. It also instruments the DOM to record the HTML and CSS on the page, recreating pixel-perfect videos of even the most complex single-page and mobile apps.
Let’s see how SolidJS props work to promote component reusability, exploring basic to advanced concepts for a complete understanding.
We evaluate Eleventy and Next.js and compare both static site generators in terms of performance, developer experience, scalability, and ecosystem.
We show how to use Goxgen to scaffold a full-stack React app. See how to integrate React with Go and modify Goxygen to suit your project requirements.
Express.js is a Node.js framework for creating maintainable and fast backend web applications in JavaScript. In the fast-paced world of […]
Learn more →
2 Replies to "Comparing Dart and TypeScript"
In the language comparison, it looks like Dart takes twice (16) as many lines of code than TypeScript (8). But that’s because the implementations are different. The Dart code can be greatly simplified to look like a 1 to 1 match of the TypeScript code:
“`dart
import ‘dart:math’;
int multiply(int a, int b) {
return a * b;
}
void main() {
int a = Random().nextInt(10);
int b = 3;
print(‘$a * $b = ${multiply(a, b)}’);
}
“`
Now it takes the same number of lines as the TypeScript counterpart: 8, excluding the import and the wrapping main function, which are indeed an unavoidable.
Hey wilsonsilva, thanks for your comment. It’s good to see how that code can be altered to look more compact.
The comparison in the post though was targeted at showing the differences in syntax between the two, rather than which one needs more lines of code.
Again, appreciate your feedback and I hope the post helped with giving you insights on the two languages.