Typescript doesn’t make sense

Been in always polarised Front-End space for 5 years or more, always hot discussions are around. Solutions or packages fallen from the sky, out of nowhere, libraries that die in few years and here we go! There is a debate between lovers and haters of Typescript.

The Noise and News around Typescript

Heard quite frequently, “Typescript is a solution to **problem of types** in JavaScript” or something like “With Typescript you can enjoy good structure and high quality code in JavaScript ! ”. Something called “Type safety” is told to have been brought to FE world by invention of Typescript and its pros say “everyone is converting to it” or it is replacing JavaScript in couple of months from now! Some people, maybe including you, love it and take its side. But let’s see 1 by 1 as a list how much these all make sense?

Are types missing in JavaScript?

This is the base of all the debates, claims and philosophy. Are types needed in JavaScript? Did JavaScript developers forget types and do types make JavaScript a better language for its primary purpose?
The best way to answer is to look at purpose of JavaScript which is the script to run inside web-browsers and see where do “types” stand in browsers? Reason we have types in compiled languages is CPU/VM getting memory for data and know how to interpret them (their bit/byte-wise meaning) when loading them for operations. In browsers/front end applications, before making any assumption, we need to first get our hands on user input (which is type-less by nature), therefore all we can assume is a series of characters. Scripts must interact with different systems/users cross-platform running on all kinds of hardware/OS and they have engines not needing types. The script engines interpret code and data before executing them on CPU and are written and compiled separately for each system/OS. Usually the lower-level a language is the more type strict it will be and scripts are very high level languages either non-typed or inferring types from usage. JavaScript is not the only typeless script. There are Perl and bash and many other typeless scripts interconnecting different software/systems. Based on what we said:
Scripts are written intentionally typeless for a reason and Being typeless is not JavaScript’s problem but its strength. Because of these and some other reasons genius programmers spent a significant effort achieving typelessness developing JavaScript engines using typed languages like Java and C/C++.

Assumed solution to the presumed problem

But ignoring what’s above, TypeScript proposed a solution for (the problem of ) types in JavaScript. “Type safety” in Typescript is actually forcing developers to define and mention a type for all the inputs and outputs ( ideally if you adhere strongly to Typescript pillars) while developers don’t know what the actual type will be in run-time. As a result Typescript developers put presumed/imaginary types on inputs/outputs and Typescript syntax check enforces those types everywhere on the developer himself. Since we need to make it JavaScript to run it, Typescript compiles this to a type agnostic output which cannot enforce types. Congratulations buddy, you nailed it!
Guess what happens? Yes, typechecking was only for development time. The edge input may break your code! no matter you imagined what you used over JavaScript, if the code is not written robust for some kind of inputs, will break with those inputs.

Coming from a code-background with types?

If you have a development background ( like I and many others had) that got used to types, you miss them for a while when you start in a new paradigm like when you are new to front-end. In this case it is better to adapt differences and try to realise new situations which are not exactly the same in front and back end. Denying this causes the headache and an example can be defining imaginary (not practically runtime ) types , then enforcing them, while they do not really exist. This could put limits on your freedom which will in turn limit your ability to code and your productivity.
Like driving a boat, or a small plane , or a tractor, after years in a city centre where lots of traffic lights around and strict road-signs supervised and police around, yeah you might feel unsafe/uncomfortable at start. But to be efficient and useful, you must believe and enjoy the freedom of no traffic lights in farm, no road block signs in the sky and no ped-lanes in the river! Otherwise Imagining rules, you would end up putting a handcuff on your own hands for nothing. JavaScript (and scripts in general) not having types is your right not your limit! It is a gift that you need it to develop efficiently.

What you actually get and what you loose when doing Typescript

Since user does not know about types, not limits on her, she doesn’t appreciate your usage of typescript! Front-end functions are not API/Library functions and hence typed signature is not source of valuable knowledge while it still annoys programmer when testing edge/invalid input. It is not comments in the code either because comments and documents do not raise compiler errors but typescript does. A developer will gain knowledge more by reading code/tests and that is why he probably won’t use type definitions to understand the code either. And while tests are still needed in repo, in presence of Typescript, they might be given up under the burden and illusion of type safety. Let’s say Typescript does not pay back the effort, you will be around 30% less productive managing types and the burden they put on you while writing code.

TypeScript takes even more

Lack of creativity
When you are creating something you need to test ideas and thats when you write a lot of throw away code. In these occasions you normally want the code be as simple and as ad-hoc as it can be and you don’t want someone to stop you and ask you a type for everything you type. Unless you write a “:any” in front of everything, Typescript will not let you get away with it and believe me for that it will piss you off very quick. Typescript takes creativity out of you when you cannot try things because you will have to define types for whatever you want to imagine/try which is impossible if you are at early stages of creating something.

Mixing concerns (contradicting pattern of separation of concerns)
Sometimes Types make separation of logic/view concerns impossible because they make file and concept inter-dependencies. You will have separate files like types.ts to share custom defined types within multiple files which makes code even harder to understand when you’ll have to look at multiple files to understand definition of a typed function.
Was encapsulation of knowledge and independent libraries, separate from business concepts a value and a paradigm once upon a time? I am wondering those values gone? Types even some times (**some times**) flying from server to UI in JSONs in case you using Typescript for both sides. and GraphQL! Think of what professor was teaching in Uni? how can we want types to fly off the server? Was the whole purpose of JSON to communicate key-values between systems without taking knowledge, concepts and concerns over?

Making code hard to test
a lot of tests in JavaScript are:
1- using mocks
2- written for invalid or edge case inputs
typescript makes mocking very hard since you have to adhere to defined types when providing data, actually what you mock will have to exactly follow the types you defined (or you will extensively use any/never/null types which is against a good Typescript practice). Also Typescript will usually stop you from applying invalid inputs to a function which will either make you spend days dealing with Typescript errors for a small test or will push you to completely give up on testing.

Problem of dependency

Assume you want to put some helper functions in a helpers.ts file. For having typed function params you will have to import the types from the file defining them and normally the file defining them will be the file needing to import the helper functions and thats called a circular dependency which is a programming anti-pattern. To avoid that you will have to put all the type definitions in a third file and since you will need to compose custom types using each other, you end up making modules type dependent because you are using Typescript. As an example , you will never be able to share your helpers.ts as a library unless you include every single file defining types with it and this includes not just ones used in the helpers but the whole inheritance and hierarchy of types down to primary types.

Not paying back the expense
At compile time, Typescript might occasionally raise something useful but at the other hand you have to spend significant time creating and applying types and maintaining another hierarchy of dependencies (type hierarchy, and type imports/exports) which you’ll have to respect and that makes your code complicated and harder to maintain. Achieving the same features/values takes longer time in Typescript than JavaScript and it involves more stress and effort which as a result of makes stress that will not be so fruitful while developer concern is more about syntax than the business value, algorithms and features. After all when Typescript is (trans/com)piled to JavaScript in browser and type checking is gone, still a non-typed data is coming in, you probably did not test it because you were restricting inputs with your types. This might break your code because in runtime Typescript is not there and is not protecting you.

Typescript takes side in office politics

Apart from some developers like it because of their way of programming, in some large IT organisations,Typescript is supported by non-technical org-chart climbers, who rarely read code or documentation and types on variables is pobably their last and least of concerns. Promoted hand-offs (people in IT not doing IT) love Typescript show offs of care for governance, tidiness, documentation and formality and this is why push for Typescript is usually having a top down nature, main reason JavaScript is replaced in some places is non-technical reasons(fixing problem of scalability! for example like problem of typesafety!). Typescript gives a clue obvious enough for handoffs to understand and use letting them enter previously grey or unreachable areas, helps some people to micromanage and is used as their personal-development tool rather than software development tool. This is why criticising Typescript is taken a personal attack and is usually responded with a personal attack.

The ugly and confusing code
Typescript function and variable definitions are more complex and crowded and contaminated with more concerns and concepts compared to JavaScript counterparts. The same you can assume for programmers mind reading it. People say it is understandable because of types but exactly opposite is true if you have actually been in a TS environment. You won’t understand code written in Typescript by just knowing typescript because in every definition having custom types you always get a mix of business-logic (which is types) with language keywords and paradigms(which is syntax) and the syntax is more complicated than JavaScript syntax.

Is Typescript a superset of JavaScript ?
It is told to be once upon a time! I really was not a good student at history class and therefore I do not challenge that but out of the box 2 things are obvious:
- Typescript syntax has more keywords/literals compared to JavaScript (this is not counted as an advantage in languages world if not a disadvantage)
- Unless you have a native engine for Typescript(which is safe to assume you don’t) everything doable by TypeScript is a subset of JavaScript (because it is compiled to JavaScript) which means in best/limit cases you can get close to the borders but not exceeding JavaScript performance/possibilities. (again safe to assume you will get less)

The persuasive myth(Switch now or I eat you):
By the way why a lot of people are pushing for it? will Typescript replace JavaScript anytime soon ?
When big companies start something not making sense , one of the things they do is repetitively saying it makes sense and actually you are the one who does not make sense!
“You are alone in JavaScript!” while 100s of millions of code repos use it, is in fact told by Microsoft and Google who are pushing for Typescript and by this myth they try to terrorise the night of JavaScript developers to switch or you will loose everything. However with the way that Typescript compiles to JavaScript it can never replace it. Any time in near future will there be a Typescript native engine ? well I can imagine it for Node.ts thing to come but very hardly for browsers (because of the problems we mentioned above). Still productivity problem exists even if you want to use Typescript in a back-end project also there will be many other competitors other than JavaScript in that case.

Is it possible to have a mix?

Once you let it in, it is not that easy to co-maintain Java/Type or wipe TypeScript out. With the pressure around your developers might even hesitate to tell you the truth about what pressure Typescript puts on them. Persuasive sentence of “Typescript is JavaScript” is ignoring the fact that once you change the extension of a file from js to ts the compiler will start raising error messages on the code that once was being compiled without warning and without error as js and the opposite is also true(you cannot interpret/compile ts as js).

If a Warning-less / Error-less code in a language raises Errors/Warnings in other language, then those are not same languages!

Something very obvious commonly ignored by pro-Typescript texts.

What is positive about Typescript?

Working on Angular 2+ code, there is almost no choice of opting out of Typescript(If this is a positive?), one of the reasons I prefer React.js over Angular 2+. If you are doing Node.js back ends / Libraries it is somehow good to have types around (types help in Back-End so whether script wron or right for Back-End typed does better than un-typed) . If you are remaining a Back-Ender not doing FrontEnd most of the time it can help you feel at home. Programmers can get better IDE hints in Visual studio code and after all, if types defined and followed strictly, you might pick some wrong parameters passed to some function before testing(which is good). Still lots of other ways to achieve all these above, but you might like to get these things through Typescript and might be willing to spend the extra effort. Your boss might be happy to pay you the extra time of writing types and If taking longer time is not that much of problem then, enjoy Typescript if you like it or love it or its your personal preference. If you think it is good, despite the effort, the expense and despite all we said!

When the truth is offensive

Common guys! I really didn’t want to offend anyone, exactly the opposite, wanted Typescript people to read this and think. Of course you are more than welcome to leave a reply, but please cover the points proposed in the article not the atuhor (me) as a person! I have seen and felt the pressure pro-Typescript hand-offs put on developers in workplaces and any critics is regarded a crime and makes you a target for organisational offence for non-technical reasons. While I did not see any real benefit coming out of Typescript, no safety, no better code, not easier development, code harder to understand and tangling yourself in restrictions which all once did not exist and everything was fine. For what? I brought you examples and facts from the nature of front-end work and my experience years of both JavaScript and Typescript. Expecting types in scripts? Probably not looking for them in the right place. None of these I wanted or dictated or built. Problem of productivity is real and is out there when 15%-40% more time spent for the same features and when doing a more complex job achieving less, and it causes you stress, more pressure, less creativity and less likely to think about the good of business and users, all things that you can find out without needing me to tell you, then Typescript really does not make sense and it is not my fault and it is not personal. Remember lot of people doing something, does not necessarily means it’s good, nor if something is backed by VSCode, or big-techs, or is new, or uptown chicks like it or is written in holy books, or whatever, you still need to think about what this thing does at what price?. After all here comes human right of choice and with the rights, responsibilities!

Conclusion

Based on what we said, it looks like, at least in Front end, where user interaction matters, and asynchronous non deterministic input is around, using Typescript over JavaScript is not just a bad idea, it is horribly raising a lot of issues some of them mentioned above and doesn’t make sense at all.
In back-end obviously JavaScript resigns to be the language of choice ( as its primary purpose wasn’t BE) the competitors are much more. Whether Typescript is the chance of choice over Python or Java or Golang and tons of other languages? Well (I guess what but) not a subject for this article. So thats it folks and your critics and Ideas are always welcome.