October 30, 2018

The use of TypeScript. Why?


I am searching for the real use of TypeScript.


disclaimer: I am going to write TypeScript as Typescript, just as a heads-up for the critical reader.


In my life as a developer I tried to understand why people want to make certain choices for languages and tools. I don’t want to go pick a tool or language just because people order me to do that. I always wonder why they do that. Is it policy or is did they actually think of it.
I mean I understand why people want to use Typescript from certain perspectives.


  • The use of types,
  • My framework uses typescript (Eg. Angular),
  • The ease of use of OOP programming,
  • My Java developers can immediately start programming because of the familiarity Typescript has with Java,
  • Typescript allows me to use my tooling like autocompletion,


Of all these arguments I can just as easily say a counter argument. For me the only really valid point is the second argument in above list.  
When you choose a framework where all the documentation is written in a language it is hard to break out of that language.

Let me try to explain why I am not convinced in these arguments.

Types


In using good programming (mind you I say programming not Typescript) we make use of Types (often seen as objects in OOP).Types are defined by a contract not by using a keyword that loses its purpose in runtime.
The use of types in Typescript are only used to satisfy the compiler, but then we added this compiler as a language tool (like any compiler). But here it comes, the angular compiler is not so much as a compiler but more of a transpiler. It transforms the Typescript to Javascript and it erases all type information once the resulting code is left as Javascript. Also what I have found is that the use of types is often neglected as I will argue in a later reasoning here.

I like dynamic languages. The give me an feeling of productivity that I cannot achieve with statically typed languages like Java (or Typescript).
I like to work with the mantra: 
if it walks like a duck and if it talks like a duck, it's probably a duck
For me this is all about the contract. 
When the object in question does not follow the contract it just isn't the type we need in this context. If we use Typescript to define our types we know it is fine during compilation however in runtime there is no such confirmation or construct that we are using the expected type. The only way to way to verify this is to test. 
Why do I say we have no such confirmation in runtime? Well too often I see developers make use of the 'any' type. 'any' basically says: I don't know what type we're using here but trust me it's gonna be alright.... 😑
This 'any' and the loosing of typing in runtime can give us false safety.

Frameworks


Currently amongst the most used frameworks in the enterprise is Angular. Angular is written in Typescript. All the documentation is written in Typescript. All the examples likewise. I understand this as a valid point in using Typescript. It makes your productivity much higher especially when you program and use the likes as stack overflow and the official examples as your way to solve your programming issues. No questions asked no answers given. I take this as fact. However, I still wonder why these frameworks would be written in Typescript in the first place.

OOP

Typescript promotes the use of object oriented programming. I agree. Since Typescript is modelled after C# and Java, it promotes the use of the class construct and hence object constructs. Typescript however also is a so called supertyped javascript it allows you to write plain javascript without the added features Typescript has. The class construct is not the classical construct as we know from Java and C#, basically it is syntactic sugar over the prototypal inheritance structure Javascript offers.
In fact ES6 offers this construct so it is not even exclusive to Typescript.

Now I favor the use of functional programming over oop, while this is not entirely so. I really prefer the use of a hybrid approach of using both functional and oop in my code.
I see the use of services best described in a functional pattern, not in the way Java promotes. Java services are often a collection of related methods combined in an object. To me this is more or less a Façade without the usage of multiple delegated extra components. 

Coming from a different language

I heard a few of my peers tell me: "well thanks to Typescript my java developers were able to code for the frontend because the language is practically the same."
There is so much wrong with this argumentation, I hardly know where to begin. Let me try though.
Being able to program in another language because the syntax is so familiar is like saying you can use oranges for your apple pie because they are both fruits and hang both on a tree and you have to peel their skin off.
Go and tell an average Java programmer to start programming in C# because the syntax is nearly the same. It just doesn't work that way. Sure the programmer is able to produce some code, but let's call it at that ok? Tell a windows engineer to setup a linux server, they are both servers and have a cli. I think you got my meaning.
apples and oranges who cares?


Typescript is just no Java. Don't pretend it is because of syntax similarity. We hide behind a layer of semantics that we try to map on javascript. 
We hide the concept of the actual workings of prototypal inheritance in Typescript or even in ES6 for that matter. The interface semantics are different in Typescript than in Java. In Java an interface is meant to be a contract, in Typescript it is meant as a struct a type without any specific behaviour. Though the documentation claims the interface to be a contract as well, I even see this construct in a Typescript interface:
[propertyName: string]: any;
What this allows you to do, is to basically say: any property you add to this interface is allowed.
Object literal? Any? (pun intended).
We basically leave the contract so wide open it basically becomes void.

I just think you just need to take the fear of using a different language away from the Java developer Typescript is just another trick to persuade the Java developer to become a frontend developer, but it leaves the developer in no-mans land. 
The real solution is to just educate the Java developer in javascript. But don't fool the developer. It's just not right. Either point out he has to do the dam job and suck it up or stay out of webdevelopment, just be honest.

Tools

tools

Typescript allows me to use tooling for my productivity.
Well this seems to me it's the other way around. Aren't tools used to enhance our productivity? Shouldn't tools provide a means to make our work easier? In that way Typescript is a tool but so is javascript. And this is exactly my question: Why should I use Typescript? 

Visual Studio is an editor that allows me to use plugins to enhance my writing of code. but it also allows me to enhance me my writing of javascript code, not just Typescript.
Personally I have a multitude of tools I write my code in. I am a vim user (neovim for that matter). I have found lots of ways to increase my productivity in that editor.

Do I want to be convinced to use Typescript?
Well I certainly want to understand why I should use Typescript over javascript. I just don't see it.
I would be very happy if someone could point out to me what I am missing. I want to share knowledge and I certainly will try to provide this found knowledge to others in helping them.