The dangers of premature optimization are well understood among software engineers who’ve been frustrated by the secondary effects of code that end up compounding maintenance cost. (Does this principle play out in other milieu?).

Nonetheless, there are times when optimizations are demonstrably beneficial but are difficult to implement because of system-wide or social dynamics that can’t or won’t accept the optimizations. Here I’m thinking with Dan Vanderkam’s post from back in September: The Saga of the Closure Compiler, and Why TypeScript Won.

Skipping gingerly back through through recent web and computing history, Dan discusses the now obvious demise of Google’s Closure compiler, which at the time enjoyed merits of technical achievements in optimization. During it’s development in the early aughts, the hardware of the time demanded Closure’s designers focus on minification. Dan argues that contemporary typed projects, like Typescript, won’t succeed beyond the range of Closure’s niche usage on advancements in performance. Typescript must be built with consideration ever-increasingly diversifying ecosystem of tool chains and environments within which it can and will be run. Such as right alongside plain ole dynamically-typed JS in mixed types/non-typed codebases. Despite the heroic campaigns of developers to slap types on everything – see the DefinitelyTyped repo – the JavaScript multi-verse offers no real guarantees that imports will be typed or not. TypeScripts declared horizon of

Be a cross-platform development tool

must be joined by

Emit clean, idiomatic, recognizable JavaScript code

and further qualified by the non-goal of

Aggressively optimize the runtime performance of programs. Instead, emit idiomatic JavaScript code that plays well with the performance characteristics of runtime platforms.

I wonder how many TypeScript developers have looked at the TypeScript Design Goals? Not to call out/in, just curious.

I wonder, the Midnight’s 2016 Endless Summer. Saxophone crying out from the other room.