My 2 cents on why you should try TypeScript

It has been said a lot about the value proposition of TypeScript. But I still want to add my 2 cents and talk about the reasons to use TypeScript from the personal perspective. So, here is my list:

  • It’s main designer is Anders Hejlsberg. Well, strange reason, I know. But this guy has designed Turbo Pascal, Delphi, and C#. All widely adopted and great technologies. People love them. Let’s face it, experience matters and I think the guy with such a background behind TypeScript increases its chances to succeed.

  • It is supported and developed by Microsoft. Again strange reason, but it seems to me companies are good at certain things and it is very hard for them to become good at other things. Look at to Google’s social network Google+. Is it nearly as good as Facebook? Another example is Microsoft’s Bing search engine. Is it as good as Google’s search? Microsoft has always been good at creating great developer tools and this increases TypeScript’s chances to succeed.

  • Scientific research shows that static typing can help developers with maintenance tasks. This is a more objective reason and it is the core one. We have hard data which proves that TypeScript improves your effectiveness at JavaScript maintenance tasks. And you don’t have to reflect hard to see the reason. I have parts of my project at work in TypeScript and after working in such a part for some time I get used to autocompletion, “Find definition/pick definition” and renames. Recently I had to fix a pretty complex bug in the pure JavaScript codebase and I struggled a lot. Not that it was very hard to understand the code, but it was extremely hard to navigate in the code. For example, I open the function. I see it calls another function with some parameter. I want to see what this parameter is, like what is its type or whether it is an array or not but I can not. Now I want to see the definition of that called function but for this, I need to search the whole codebase. After I have found the definition I want to go back to the caller but this is again not a simple key stroke as it would be in TypeScript. I don’t even think about renaming the function. It simply does not work. To rename you have to go through all the codebase again and try to understand where you function is called and if this is your function or some other function with the same name. Entering new code in TypeScript is also faster than in JavaScript. This is because you just hit dot and you have the list of API options you can select while in JavaScript you have to remember all the API details. Since remembering never works, at least in my case, you have to search the web for API documentation to recall or learn how to use it. Hence TypeScript improves API discoverability. Pathikrit Bhowmick summarized experience with type system:

    Static typing is like spell check.
    Dynamic typing = writing your essay in Notepad.
    Static typing = writing your essay in Word (or Grammarly).

  • TypeScript is the mature and open source project. And this is important for production. It was introduced in 2012, so at this point, it is 4 years old language. It has many great and stable features, its compiler is fast and can be tuned to be even faster. It has native support in most popular IDEs like WebStorm and Visual Studio. It has a lot of tooling around it and even linter. It has huge, community developed code base of type definitions for popular JavaScript libraries and frameworks. It has a vibrant community which produces courses and answers questions on the forums. All in all, today starting doing a production with TypeScript is relatively easy and smooth.

  • TypeScript can help to deal with JavaScript’s quirks. It can not fix everything as it is a superset of JavaScript, but it can help a lot with some JS problems. For example, it can help you to not mess up your “this” accidentally. It will not allow you to forget to write your return statement and fall into the trap of semicolon auto insertion. It will not give you a chance to create a global variable inside the function. It will help to avoid shooting yourself in the foot with type coercion. I will write another blog post explaining how TypeScript fixes JavaScript later.

  • Fool protection. Here in Ukraine, we tell the system is fool protected if it has means to protect itself from user’s incompetent actions. For example, one can not insert battery the wrong way into the smartphone or insert the cable into the wrong computer’s port. This whole concept of inserting something only where it fits is extremely suitable to describe a type system. With TypeScript I can only insert a variable into the function where it fits. And this is great. Not that I am a total fool. I would like to be focused on solving the business problem not on whether it is ok or not passing something into the function. I also can be tired or ill or disappointed or distracted or not fluent with current codebase or whatever. All these reasons can cause me to make a fool mistake which will be corrected immediately by TypeScript and which would live until runtime in JavaScript.

  • Typescript is zero risk to your project. This is because it generates beautiful idiomatic JavaScript. Hence had you wanted to move back to JavaScript – you would just compile your TypeScript sources to JavaScript and off you go.

  • You can generate definitions of your RESTfull API from your backend code. This way if some breaking change happens on the back-end, after declarations regeneration, you will immediately get a compiler error and we all know, the faster feedback loop the better.

To summarize, I would say I just feel more relaxed doing TypeScript. It gives similar to C# and VisualStudio joy of coding.

Facebooktwittergoogle_pluslinkedinmailFacebooktwittergoogle_pluslinkedinmail

Overcoming TypeScript’s type guards limitations in the nested scope

TypeScript has a cool feature – control flow analysis which allows to narrow down the variable’s type inside the control structure block. Like in this example:

Very different from C# or Java, right? It made me thrilled when I first learned about it. It has a limitation, though:

It is a bit puzzling at first glance. Why? How in the world x is not a number in the else block? The root cause here is that TypeScript doesn’t know what map function is going to do with the lambda function passed to it. If map will invoke the lambda right away – that’s fine, but what if it, for example, will call setTimeOut and pass the lambda function into it? In such a case i => i * x will be executed after the timeout, well after control flow will leave the else block. Because of this possibility TypeScript takes a pessimistic position and considers x to be number | string inside lambda function i => i * x.

How to deal with this problem? There are several approaches. First, you can tell TypeScript that nothing bad is going to happen by limiting the scope of x. For now, it is global. Limiting it to the function, which does not change x fixes the problem:

Second, introduce another variable of needed type inside else block. Since TypeScript now knows exactly the type of the variable, it will not complain:

Finally, let TypeScript know that you are not going to change x after it’s initialization and it will calm down:

I have introduced someFunciton only to stop type inference mechanism to infer the type of x from the assignment. If I wrote const x: number | string = 5, for example, the type inference mechanism would have inferred the type of x to be number (never inside if block) even though I have declared it to be number | string.

Facebooktwittergoogle_pluslinkedinmailFacebooktwittergoogle_pluslinkedinmail

My 7 favorite podcasts

I am a big podcasts fan. I listen to them all the time when I am waiting for something or commuting. They help me immerse into the western technology world from which Ukrainian tech community is quite disconnected. It is extremely unusual for me to meet at the conference some kind of world recognized guru or thought leader. Podcasts can not fully compensate for that because I can not ask questions while listening (and sometimes I desperately want to do so) but still I can hear other ask questions and those questions are sometimes even better then I could have asked. Podcasts also help me as non-native English speaker to improve and maintain my English communication skills. It is sometimes very difficult for the non-native speaker to understand the native speaker and accents of other non-native speakers. Podcasts actually provide great training on listening and understanding all these different accents, because podcast guests are people from all over the globe. It is hard for me to explain the reason, but podcasts help me to write and talk about technical topics in English. Probably this is the quantity to quality transformation. I listen a lot and spoken patterns are carved into my mind so that I can use them later in my own speech. Many people are surprised to learn that it is much more easy for me to explain something software related in English than in Ukrainian. So, here is my list:

.NET Rocks. I revolve mostly in Microsoft space. And there .NET Rocks is the number one podcast. It is not only about .NET, their episodes cover many different topics, related to software development in the Microsoft universe. Of course, most episodes are about .NET but often you will hear about the broad range of topics, starting from machine learning and ending with front-end stuff. Not only .NET rocks will keep you up to date with latest advances in .NET but it will also entertain you, I often find myself laughing or smiling while listening.

Javascript Jabber & Adventures in Angular. These two podcasts cover my front-end needs. I mention both because they are made by the same guy although the set of panelists differ. You will learn about advances in JavaScript and Angular worlds, learn about new libraries, front-end development problems, and possible solutions. In every episode, they discuss so-called picks, different things which podcast authors and guests are currently excited with. These picks will really teach you a lot.

SE-radio. This one was my first podcast. It mostly covers fundamental aspects of software development like refactoring, architecture, programming languages design, requirements engineering, software modeling, distributed and real-time systems. Back to the previous decade it was created and lead by Markus Voelter, who is my favorite podcaster. First, he is german but his English communication skills are extraordinary. Because he is not a native-speaker, his speech is simple and clear, the way he asks questions and digs into technical topics can be used as an etalon. It is also clear that the guy is passionate about podcasting and technology and for me it is a big deal, I love passionate people. This days se-radio is produced by IEEE Software magazine. Markus does not participate in its production anymore, but it is still pretty interesting to listen world-class experts talking on fundamental aspects of software.

Omegataupodcast. I have already mentioned Markus Voelter. After he finished with se-radio, he started Omegataupodcast. The podcast is about science and engineering. Although there are episodes on biology and social science, most episodes are about space engineering and science, aviation, physics, and computing. I have a background in radio engineering and aviation, therefore, omegataupodcast meets my interest in this kind of topics. It is a combination of Markus’ brilliance in dissecting complex technical topics and great science content which can literally go on for hours (episodes are pretty long).

Hanselminutes. It is hard to tell why am I listening regularly to this podcast. It is short, it has no specialization it looks and feels like the ordinary podcast, there are thousands of such. Probably because I have huge respect for Scott Hanselman and for all he does. He is the brilliant guy and he can combine interesting topic with fun conversation. Probably it is because ridiculously wide variety of topics covered on the podcast. One week he can talk on excel spreadsheet, another week – about toy robots, yet another week – some soft skills topic like management, motivation, and creative processes.

Developeronfire. I have recently discovered this podcast, I have listened to almost all old episodes and never miss new episodes. It is not technical and you can listen to it while working out when you can not concentrate very much. The podcast is indeed about going personal with your favorite geeks. Dave, the host, invites to talk about personal stuff active people in the software world. Mostly developers but not only, there were consultants, managers, marketers and other professions on the show, all somehow related to software development. Dave asks more or less the same set of questions like what is it the guest likes about technology, guest’s definition of value, his biggest success, and failure, her hobbies, and value delivering tips. Sometimes the guest is moderate and you will not hear something special and sometimes whole episode is full of pearls of wisdom. Take for instance episodes with Scott Hanselmann, DHH, J.B. Rainsberger or Linda Rising. Highly recommended, a lot of fun, deep conversations and you will be surprised how many things will resonate with you and your experiences in the industry. Cool stuff there.

EconTalk. This podcast is not specifically about technology or software, although some episodes are, but it is about everything else. Most episodes are discussions between the host and some brilliant personality who has written some great article or book. EcanTalk is meant to be about the economy but it is about the economy in a very broad sense. The topic can be very economy related like agriculture, chicken production, banking and monetary policy. They can also discuss somehow related to economy topics like machine learning, technology and artificial intelligence influence on the economy of the future, peoples’ ego, learning and education problems, sports, healthcare, and transhumanism. To summarize: this is a podcast where extremely smart people discuss very interesting and essential to everyday life problems.

Facebooktwittergoogle_pluslinkedinmailFacebooktwittergoogle_pluslinkedinmail