Systemic TypeScript
The constraining type-system paradoxically inspires courage for programmers to brave the complex; but it is also the very trap leading to the unfixable sins of JavaScript---a language not built for systems.
Systemic TypeScript aims to find TypeScript's aspects that scale well with complexity shift by avoiding features that cause complication and preferring certain design patterns.
This series benefits those who have realized the exponential rise of difficulty of maintaining a growing TypeScript codebase. But, it is aimed at everyone. I hope, by reading this, you can anticipate the challenges and form the best pathway to using TypeScript for a codebase that potentially scales.
Prelude
Complications
These sources of complications are TypeScript features that don't work well with other features or by itself. Some complications will be dealt in the main section, "Systemic TypeScript", but some others are just meant to be avoided, or at least for people to be aware of.
- Throw
- Class/Prototype vs Serialization/Deserialization
- Class Unbound Method
- Class vs Layered Lifetime
- Type Definitions Stripped At Runtime
- No Destructor
- Cyclic Dependencies
- Non Bijective JSON Module
- String scales easily
Systemic TypeScript
A reliable, durable, easily maintainable system nees more than what is needed to write a script. Here are the collections of my finding from building and maintaing big projects.
I was tempted to title this as "Writing TypeScript like you write Rust" or something along that line. But these guides are not Rust as much as it is not FP, OOP, agent-oriented, or any other inspiration.
- Known vs Unknown Errors, The Throwless Pact
- Closure over Class
- Runtime Type Validation
- Agency and Systemic Agents
- [Under Construction]
- [Under Construction]