- ScriptSharp was an attempt to bypass JavaScript's tooling limitations by using C# as the primary development language.
- The 'instruction language' approach treats JavaScript as a compilation target rather than a language written by humans.
- Attempting to win an ecosystem by asking developers to abandon its native language is rarely a sustainable competitive strategy.
- The C# team viewed the improvement of JavaScript as a superior long-term investment compared to cross-compilation.
Channel: The Pragmatic Engineer
Anders Hejlsberg: How TypeScript was created
This discussion examines the tension between using cross-compilers like ScriptSharp to bring C# tooling to the browser and the alternative strategy of improving native JavaScript development.
Key Takeaways
- The Outlook.com team sought to replace native JavaScript development by productizing ScriptSharp, a cross-compiler that translates C# code to JavaScript.
- The primary motivation was to leverage mature 'grown-up' tooling like Visual Studio, which the team felt was superior to existing JavaScript developer environments.
- The C# team rejected the premise, arguing that true leadership in the JavaScript ecosystem requires improving JavaScript itself rather than bypassing it with language substitution.
Talking Points
Analysis
Strategic Significance: This highlights a fundamental tension between developer convenience and ecosystem loyalty. It illustrates why language-transpilation strategies often fail to achieve dominant positions in open ecosystems.
Who Should Care: Engineering managers, platform architects, and developers who are tempted to introduce proprietary or secondary languages to bypass native platform limitations.
Contrarian Takeaway: Often, the effort required to 'fix' a platform's tooling is lower than the long-term technical and social debt incurred by abstracting that entire platform away behind a cross-compiler.
Channel: The Pragmatic Engineer