Since always software developers face problems of compatibility and performance of their software, the challenge is immense. Because, in addition to the concern with the hardware of the device that the software will run, there are still problems with the OS (Operating System) of the device.
In the development of cross-platform applications, concerns are even greater, as it is necessary to create specific solutions for each OS and hardware. In web development, we find the problems of cross-platform development, devices, operating systems and browsers extremely different.
In current times, when we talk about browsers, these problems are increasingly simple to solve, because the trend is for them to have a gradually more reusable base, an example of this is Chromium-based browsers and software, which share the same code base.
Over the years, technological evolution has become evident, bringing devices with increasingly smaller or giant screens with internet access, that is, that interact with web technologies. We have extremes where it is possible to have access to the same Site from a smart watch with a 1.3-inch display or an 85-inch smart television, notice that we are not only talking about extremely different sizes, but also about accessibility, compatibility, UX and UI.
20 years ago these problems were unimaginable, and there is no doubt about it, as there was no need or possibility to access a Site via watch or television. At that time many people were only concerned about accessing ICQ via Dial-up Internet on a Tube Monitor.
“In my day we programmed in ActionScript inside Netscape“ — some old developer.
And why do we talk so much about compatibility and reuse if we haven't even started talking about TypeScript yet? With the evolution of technology, we have greater complexity within software, the code base of a software is increasingly complex and difficult to maintain, and without a doubt, we need compatibility, standardization, reuse and the organization working together. And this is where TypeScript comes in.
In the example below using interface, we have a function that takes only one parameter of a certain type.
First, let’s define what the “person” object should contain:
Then we create a function that receives the person object, and writes it to the console:
If I try to pass an incompatible parameter, Transpiler/Linter will return a message saying that the parameter is incorrect:
Therefore, we have the possibility to document your code, and when the application is large, this makes all the difference.
The non-implementation of TypeScript is not only associated with the learning curve, but also because of the fear of breaking something that already works. This was one of the main reasons I didn't start using TypeScript earlier.
When I started to study the topic, more deeply in 2016, specifically when Angular 2 started to adopt it, I found 3 main points not to use TypeScript, and they were:
Flow.js gives you the possibility to check the quality of your code at development time through “typing”.
And indeed they are good alternatives, but in my opinion one is too basic and the other too complex, in a way, of course, it varies according to the complexity of the project. Nowadays, there is no doubt that TypeScript is indeed one of the best options for large applications, if not the one with the best cost-benefit ratio.
The reasons for not using TypeScript scared me in 2016, but I saw many benefits ahead of it, but most of these reasons are no longer valid these days, and maybe some of the reasons I mentioned may have taken you away from TypeScript.
TypeScript can even be considered an optional tool, however it has been considered a necessity, specifically because it brings numerous benefits and few or almost no negative points.