The problem with TypeScript and its practices

## Myth 1: It is typed and safe. TypeScript is either typed nor safe. Being a typed language means the compiler 100% know the type every single value, the binary representation of the value in memory and how to access it. The typescript transpiler/compiler cannot and does not know this information. The dynamic nature of JavaScript/ECMAScript prevent it. What TypeScript actually do is try to figure that information out or let you specify it, but it has no way to actually knowing. … ## Myth 2: It create less bugs Contradictory what many people say, TypeScript do not create less bugs compared to applications written in JavaScript. It's not my opinion, its research. The research study checked the 15% most popular applications on github. The study in a nutshell says the following: - The use of "any" has a positive impact on bug resolution time. - TypeScript code contains equal or more bugs than JavaScript code. - Its take longer time to fix bugs in projects that is written in TypeScript. … ## Myth 4: Future proof TypeScript is not in any way future proof. In every places you can run TypeScript today, do you actually run JavaScript. There is a proposal to add some type-annotations to the language, but if you read all issues and even meeting notes is it clear: - Annotations will just be treated as comments. You cannot trust it the type in any way. - Most TypeScript code will never work because it uses TypeScript-specific features. - It does not offer any technical benefits. - Many people are against the proposal, some of those people are inside the committee itself. … ## Problem 1: Encourage named exports Almost every module should export only one thing. There is very few exceptions to this, for example configuration files or a file containing multiple constants. And if you export only one thing, the default export is the obvious candidate. The argument TypeScript lovers usually say is it ease refactoring but it is technically impossible. If you use default exports do you hide the identifier/name of the thing you export. It is by definition better because it remove a dependency, you do not need to know what name of some thing has within a file, only the interface of the thing the file exports. It's great. It means less coupling and less "need to know". Its honor SOLID principles and is great software design. It also encourage the developer to give great names for imported modules and each file has different contexts, so it make clear sense different names/identifiers may be used depending on context. … ## Problem 2: Do not support import by .ts extension ECMAScript/JavaScript import modules by import/dependency specifiers and every plattform I know will convert the dependency specifier to some path or an url it can fetch. If the direct location cannot easily be defined, must the platform perform some kind of traversal (visit many files before it "knowns"). This process is slow, but remarkable slow if it is done over a network. This can be fixed if the developer provide more specific dependency specifiers, for example adding the file-extension. But there is a problem: TypeScript do not support if you add the .ts extension. It does not rename dependency specifiers. Its extremely weird actually: - The TypeScript team do 100% know TypeScript is not supported natively anywhere in the world. So you cannot evaluate a file containing TypeScript code. It must first be converted to JavaScript. - The TypeScript team 100% know the ".ts" extension is their own file-extension and it is extremely likely if someone want to import a ".ts" file from a TypeScript file, is the file very likely a TypeScript file. - The TypeScript transpiler itself will re-write all code, have almost in every case access to all dependencies and will create ".js" files by default. … ### Over-use strict mode. Strict mode do not produce less bugs nor it is more readable. Sure, you may believe so, but science says it's not. You should absolutely use "any" if it makes the code shorter and easy to read, yet there is an insane belief its bad. Its not! ### Overuse of unions types If your function has multiple declarations, use multiple functions. There is a reason why parseFloat and parseInt is different functions instead of just "parseNumber". ### Overuse of types You should not care about the type a specific value has, but the interface the value has. Instead of doing: … ``` const getName = ({ name = '' } = {}) => name; getName() // OK getName(123) // OK getName(true) // OK getName(undefined) // OK getName(Symbol('test')) // OK getName(null) // TypeError, but this is the only case ``` … ``` const add = (...args) => args.reduce(((s, v) => s + v), args.shift()); ```