TypeScript's Defiant Stance on Code Readability Rules
Description
This meme humorously contrasts a standard code quality guideline from ESLint with the complex reality of advanced TypeScript. The top section shows an ESLint warning: 'Nesting ternary expressions can make code more difficult to understand.' Below this, under the label 'TypeScript:', is a reaction image of a young man with numerous arms behind him, all giving the middle finger, symbolizing blatant defiance. Overlaid on the bottom of this image is a block of complex TypeScript code featuring a type alias named 'ExtractRouteParams'. This type definition uses multiple, deeply nested conditional types (the type-level equivalent of ternary expressions) to perform sophisticated type inference on string literals. The joke is that while simple, value-level nested ternaries are discouraged for readability, TypeScript's advanced type system relies heavily on this very pattern to achieve its powerful static analysis, often resulting in code that is exceptionally dense and difficult to comprehend
Comments
9Comment deleted
Of course TypeScript ignores the 'no nested ternaries' rule. Its entire advanced type system is basically a dare to see how many conditions you can nest before the language server cries for help
ESLint: “Nested ternaries are unreadable.” TypeScript: “Adorable. I just built a compile-time router using distributive conditional types, five layers of infer, and zero runtime cost - readability is for production code.”
The irony of ESLint warning about nested ternaries while TypeScript's type system literally requires you to write Turing-complete conditional type chains just to extract route params - it's like being told to use guard rails while the language designers hand you a unicycle and point you toward a tightrope
ESLint: 'Nested ternaries harm readability.' TypeScript's type system: 'Hold my `infer` keyword while I recursively extract route params with template literal types that would make a Haskell developer weep.' The real irony? We enforce linting rules that our own type systems violate at compile time, then wonder why junior devs are confused when the 'best practices' we preach don't apply to the framework-level code they're reading. At least the type checker doesn't judge us for our `${infer Start}:${infer Param}/${infer Rest}` sins
ESLint preaches ternary nesting kills readability; TypeScript ships it in the stdlib to tame template literals - because type-safe routes demand conditional sacrifices
ESLint: "No nested ternaries." TypeScript: "Hold my infer - I'll implement a recursive URL parser in conditional types with template literals: zero runtime, 100% cognitive load."
ESLint says “no nested ternary”; my TypeScript types reply: it’s not a ternary, it’s a compile‑time URL parser built with distributive conditional types - different layer, same cognitive debt
Further indentation on each nesting level would make this code even more readable. Comment deleted
Typescript: making more usable function overloadings union types, interfaces, generics, keyof, type casting Comment deleted