Frontend development without the use of Javascript is no longer an option today. Not only web applications, but also mobile apps (react-native) and backend applications (node.js) are written in Javascript.
It is one of the most widely used languages worldwide and more and more developers are getting into contact with Javascript. But if it's your first time using an untyped language, it can lead to some confusion.
What does typed mean?
Programming languages such as Java or C++ are object-oriented and define a type for each attribute of an object, but also for each variable in the code, in addition to object classes. For example, the variable X should be of type integer (a number). From now on only numbers can be assigned to this variable. In comparison, you can assign a text to the variable X in Javascript first, also in other untyped languages like Ruby, Python or PHP, and a number in the next line and the code is still valid.
With the new features of ES6, Javascript has become a very clean and usable language. If you don't know the new features of ES6 yet, you can have a look at all important ones at this page. You can use some packages for JS to enable typing, but if you really aim for object-oriented environment, Typescript is the best choice today.
At zauberware we have been developing with Ruby, Python and Javascript for years, both for the backend (Node.js) and for the frontend (react.js, react-native). But in the beginning of our careers we have learned how to code with typed languages. In our team we all had to go through the hard school: Java, C, C++. The first contact with Python, Ruby and JS was like an enlightenment: finally free, finally fast and dynamic. Non-typed does not mean that there are no advantages of object orientation: In Ruby there were no objects without well defined classes. But somehow a distance to languages like Java and C++ has built up, which has now been reduced again by Typescript.
What are the advantages of using Typescript?
The code is easier to understand
When you use code in a project that you haven't written yourself, you immediately ask yourself a few important questions: Which parameters can I use for the function or component? What is the return value? Which external objects are used? What attributes or methods do these objects have?
To open a single JS file cannot answer all these questions directly. You have to open the used modules or functions and see what happens there. If you don't understand it, the most common method is the famous console.log(e), which accordingly to some Twitter threads is the debugging tool for JS developers. If a console.log is still not enough, the developer has to find someone to explain the code to you, which is probably the wort case scenario.
With the use of Typescript these problems are gone. Every object and every method has clearly defined arguments and return values. These are getting also suggested to me by my IDE and I get instantly feedback as a developer.
New code is easier to implement:
The standard way to create a new component is the following:
- You create a template for a component, you define arguments in the constructor, as well as the business logic.
- If external objects are used, e.g. a user object, you search the code where it has been used before to see the structure.
- You set your component into the actual project with specified arguments.
- At the same time your create a unit test, in which first only the component with the arguments is tested for a "I-am-able-to-render-myself".
- You test the component directly with Browser-Refresh and the Unit-Test.
- You work on the code until unit tests and your console.log looks good and you do not detect any inconveniences.
In comparison, the way for Typescript:
- You create a template for a component, you define arguments in the constructor, as well as the business logic.
- If external objects such as the user object from the example are used, you can simply look it up with the IDE, use it partially or completely as an interface.
- You set your component into the actual project with specified arguments.
- The unit test is now limited to the business logic only, because typescript saves me to test with different arguments.
- Finished!
Refactoring source code is easier
To refactor old code is always associated with troubleshooting. Where is my component or function used? Who expects me to return which values? The normal way is often a search over the whole project. Then you may change the arguments and hope not to have broken anything.
With Typescript the thing is simplified. If I change my interface, my function or my component, the IDE knows immediately about the whole project, where something is wrong defined. I get the errors told before I have to look at them with console.log().
Fewer errors
The console.log(e)-debugging thing kept me thinking and we often just use this method to find out what's really going on. In probably 50% of the cases the use of typescript would have saved us this. In Pair-Programming sessions you often have to say to your colleague "You entered the wrong argument here. The function takes an integer, not a string" which finally solved the problem.
No boilerplate tests
Creating a typescript component takes longer than with normal JS in any case. But the time is saved later because you don't have to create dummy unit tests that just look at the correct use of properties. This is now secured by the typing.
It is easier to merge source code
We spend a lot of time merging major changes to our projects. Through unit testing you can be sure that everything should still work, but are all frontends 100% tested? Yes, that's also our goal, but the reality looks different, I suppose with you in the team as well. So I have to test everything again by hand with my browser, so that I can be really sure that the PR has been merged correctly.
Typescript and the direct feedback in the IDE are an enormous help for Pull Requests and avoid merging broken code.
Easier for juniors
The learning curve for Typescript is of course slightly higher than for ES6. But if you have an understanding for object-oriented programming, then it's only a "getting familiar" to the new syntax. If you have understood Typescript, then it is perfect for new developers to orient yourself in a new projects and you can write code that is basically valid from the very beginning.
Typescript saves a lot of time for the person doing the code review.
Typescript ships the right workflow
Typescript forces you to think about what exactly the component or function should be able to do, which arguments should be accepted, what interfaces should be used and what should be returned. The actual writing of the code follows the principles of Test Driven Development. If you add a unit test to the business logic additionally, you get clean and no longer error-prone code and can also proudly announce: We do TDD in our frontends.
Questions that we ask ourselves or have been asked:
Doesn't it take forever to introduce Typescript in the team?
I would say no, because there are very good blogposts, videos and courses about Typescript and the community is huge now. But I think it's important speak with the whole team about the topic Object-Oriented Programming. A computer scientist normally learns this in the 1st year and if someone has become a programmer and has already successfully coded JS, then he or she will be able to quickly understand the concept of OO programming. You should try it on one project. You can also program Typescript and JS in parallel in one project, which makes the shift a lot easier.
Is zauberware 100% Typescript?
No, we are not. We have just started to establish it in the team and use it in new projects.
Is Typescript also recommended for Node.js?
We will not use Typescript on the server, because we do not have the problem of 1000 different arguments like in our frontend components. In addition, an intermediate step is necessary to convert the Typescript files into JS files. In the frontend we already have this step in our development process anyway, so there is no additional effort. However, we will continue to observe the topic.
Is Typescript future-proof?
For the next years it doesn't look as if the Ecma T39 committee will introduce the "Static Type System" for JS. Of course, that would make Typescript obsolete. But if this will happen, there will be a possibility to convert the Typescript files back into valid JS files.
Original question: Why could it be worth the effort?
Fewer bugs during development and after a release leads to:
- Happy customers
- Happy developers
- Happy product owners
- Happy QA team
The time required to convert the team to Typescript will also be saved later by being much less troubleshooting.
So PLEASE YES, test TypeScript on your next JS project and gain your own experience.
Typescript stats
Popularity:
Source: https://2018.stateofjs.com/jav...
Most liked aspects of Typescript:
Source: https://2018.stateofjs.com/javascript-flav...
What other developers don't like about TypeScript:
Source: https://2018.stateofjs.com/javascrip...
I hope I could help you with the topic Typescript. If you want to try it out directly, I recommend the fast course at freecodecamp.org or have a look at typescriptlang.org directly.
