As time went by, code sizes increased of course – and let’s pause here for a moment.
Imagine a dictionary that contains words of a language. For easier orientation, verbs are in bold and nouns are underlined, that is, each word class has its own distinctive mark. Would it be easy to find an expression? Well, not really. Different fonts help a little, but since all the letters are black, by skim-reading a page the word you are looking for won’t catch your eye.
The vocabulary of JS language, code base, is divided by a kind of similar logic. There are some guidelines to help identify the different types of genres – but it does not provide significant support for developers. That’s why we say that JS is a “weakly type language”.
So, when JS’s area of use was expanded along with the code base, this weakly-type nature made the developers’ work more time-consuming. When several tens of thousands of lines of a complex program text do not differentiate the types, the developer sees only an extremely abstract, meaningless text. Their work will be really difficult. The larger the code base, the more problematic error-free interpretation becomes. They have two choices: either they interpret it by themselves (which is not typical for complex programs) or they make their own documentation for themselves (and their team mates). The latter is, again, a time-consuming task and although it is necessary, in many cases it is not the most effective method of development.
Is there no other solution? Yes, there is! Another option is TypeScript (TS).
This language is a superset of JS: it uses types and applicable methodologies known from other programming languages. While programming, you know exactly which point of the code you are working on, you do not have to guess or try to read documentation. If we stick to the dictionary metaphor, this means using colour highlighters instead of bold and underlining, verbs are yellow and numerals are red. TS can be used in simpler cases too, but the true reasons of its existence are problematic codebases. It is a real help when many people work on a project at the same time, solving tasks that require frequent consultation.
Since you have to keep defining types during encoding you need to use the ‘highlighter’ – work is somewhat slower than with a weakly type language program. But later, the invested time will be profitable: the final program will have less errors. It will be more sustainable, more durable, the use will be more problem-free. Just as it takes longer to learn a thousand words of a foreign language than it does to learn twenty you will find it is much easier to use the acquired knowledge afterwards!
Today TS is less used than JS but we at BlackBelt find supporting new colleagues very important, and with our help they can quickly learn how to use this programming language We are convinced that it is worth it, partly because Microsoft stands behind it, which means a professional guarantee, but also because of the continuous improvement and expansive tool support. Tools that speed up programming and reduce bugs. The JS-related tools are far from being this effective.
And what does all this mean for the client?
As I have already mentioned, using TS provides a more stable basic and safer operation. With the program there is less chance for developers accidentally making bugs. But if it still happens, bugs can be corrected faster and easier.
Considering all of this, our experience shows that TS is the obvious solution for larger or more complex projects.
And we are not the only ones who think so, the graph below shows an increased interest in TS: