TypeScript vs JavaScript and OOP vs FP

[staltz]

Hi Andre,

I've been following your work for a while and I can't overestimate how much value I get just by watching what you're up to and by reading your opinions on twitter re decentralisation and JavaScript in particular. Especially in the times when everything is bloated, low quality and so on.

There's one thing I find myself struggling to settle on is TypeScript vs JavaScript and OOP vs FP. As someone who've put a lot more hours in the craft, would you mind giving your opinion on why you prefer TypeScript to JavaScript. And also your view on the place of OOP in JavaScript ecosystem and the particular reason you use this approach in your own work.

Thanks in advance.

Maxim

Hi Maxim! Thanks for asking, if you don't mind, I'll answer here because it's publicly-useful information to share.

About OOP vs FP, I highly recommend checking a talk I gave in 2017, my opinion is still pretty much the same. In summary: there is no clear definition of "OOP" and no clear definition of "FP". Instead, there are 5 properties that sometimes OOP languages have or sometimes FP languages have:

• Execution vs Evaluation
• Mutation vs Immutability
• Objects vs Closures
• Assignment semantics vs Assignment syntax
• Types

This is a topic I could write a lot about, so I'll be brief:

• Evaluation seems to be better (for programmer understanding) than Execution (which seems to be better only for performance, and you shouldn't prematurely optimize)
• Immutability seems to be better than Mutation (for the same reasons above)
• I don't have any preference of Objects (and Classes) over Closure, both seem fine, neither of these has a "10x" effect over the other
• Assignment syntax seems to be better for programmer understanding, assignment semantics seems to be better for performance

Types is a big topic, but I nowadays believe that you don't need strong types (Haskell, PureScript, etc), but you shouldn't also do zero types (plain JS). I did some Haskell hobby project once, firmly believing it would be awesome for my productivity, and honestly after the project was done I felt underwhelmed with Haskell. I still had to do "runtime debugging", which was one the things I thought Haskell would shield me from.

Types are good when they help you from shooting yourself on the foot, like to avoid typos, or avoid using an API the wrong way. But too much types can kill your productivity (you end up focusing on precisely categorizing everything, which is a tangent to getting things done), can lead to confusing code (Haskell docs are famous for describing functions with 3 words from Category Theory), or in general types can restrict how much freedom you have while experimenting with code and building proof of concepts. My experience with Rust has been more positive than with Haskell, but Rust still restricts you from building proof of concepts and experiments. FP programmers tend to overemphasize correctness and verifiability, and de-emphasize experimentation and playfulness, which is very important. Programming is a flexible activity. Sometimes it's hard engineering (like if you're implementing a well-specified algorithm), sometimes it's art (like when you're building something that you're not yet sure what it is, you're discovering the goal while you are building it). Some languages favor one kind, other languages favor others.

What I like about TypeScript (and I absolutely choose it over JavaScript almost every single time) is the any type, because it allows you to choose how strict types you want in your project. You can be light on types (using loose configurations in tsconfig.json) and use any whenever you want, or you can go strict (in tsconfig.json) and refrain from any as much as possible. Both of these approaches have their merits depending on what you're building (see paragraph above). I think it's a misconception that people have that TypeScript necessarily requires you to be very strict about all the types. But in reality, TypeScript is a gradient, you choose how strict it should be. And more often than not, even if you're building a creative proof-of-concept, you definitely want to shield yourself against silly mistakes such as typos, or using String functions on things like numbers. Who wants to lose time debugging those kinds of mistakes? So I would use TypeScript almost always, if the decision is up to me. This doesn't mean that I have to strictly type everything when I'm using it.

The one reason when to use JavaScript is when you want to avoid a build step, e.g. when you're writing inline JS inside HTML. But that's not so common nowadays.