How Does the TypeScript Team Try to Avoid Negative Effects on the JS Ecosystem

Transcript

1. How Does the TypeScript Team Try to Avoid Negative Effects on the JS Ecosystem By @Orta at devX SAP
5. Goals Why would a TypeScript dev even give a talk like this?
6. Big Title Why is TypeScript good for individuals or teams. Most talks
7. This talk TypeScript is big enough to affect the whole JS ecosystem What constraints does the team put on TypeScript to avoid harming JavaScript
9. • 8-ish on the compiler • 20 folks altogether What is the TypeScript Team?
10. How does the team work?
11. Operating Principles Open Source and Open Development Closely track ECMAScript standard Innovate in type system Best of breed tooling Continually Lower barrier to entry Community, community, community
12. Design Goals Statically identify constructs that are likely to be errors. Provide a structuring mechanism for larger pieces of code. Impose no runtime overhead on emitted programs. Emit clean, idiomatic, recognizable JavaScript code. Produce a language that is composable and easy to reason about. Align with current and future ECMAScript proposals. Preserve runtime behavior of all JavaScript code. Avoid adding expression-level syntax. Use a consistent, fully erasable, structural type system. Be a cross-platform development tool. Do not cause substantial breaking changes from TypeScript 1.0. https://github.com/microsoft/TypeScript-wiki/blob/master/TypeScript-Design-Goals.md#goals
13. Design Goals - For JavaScript Impose no runtime overhead on emitted programs. Align with current and future ECMAScript proposals. Preserve runtime behavior of all JavaScript code. Avoid adding expression-level syntax. Use a consistent, fully erasable, structural type system. https://github.com/microsoft/TypeScript-wiki/blob/master/TypeScript-Design-Goals.md#goals
14. Design Goals - For Types Statically identify constructs that are likely to be errors. Provide a structuring mechanism for larger pieces of code. Produce a language that is composable and easy to reason about. Use a consistent, fully erasable, structural type system. https://github.com/microsoft/TypeScript-wiki/blob/master/TypeScript-Design-Goals.md#goals
15. Why make TypeScript, and what defines “Big enough”?
16. https://insights.stackoverflow.com/survey/2020
17. TypeScript solves 
 real problems in Microsoft TypeScript is incredible PR for Microsoft
20. JS JS + JSDoc JS+TS Mixed TypeScript TypeScript - Strict TypeScript Userbase
21. IDE Features on every desk
22. Big Title There’s a constant set of new learners to the language Lots of people are learning TypeScript as their first language Big enough
23. A bet on TypeScript, is a bet on JavaScript?
24. Erasable, Gradual, Structural, Generic, Inferable, Expressive, Object-oriented & Functional “ TypeScript is a … Type system “
25. Types only
26. Types mostly
31. TC-39 and TypeScript are best friends
32. https://medium.com/braintree-product-technology/a-year-plus-a-little-on-tc39-a1acb87eb862
33. TC-39 has to represent many voices JS Engines Browsers Node Dev Tools Web Devs Language Enthusiasts Beginners to JavaScript
34. TypeScript is a welcome contributor
35. How could that popularity be abused?
37. MalevolenTypeScript
38. Can’t charge money Can’t go closed source Have to embrace, extend & extinguish JavaScript MalevolenTypeScript
39. E-E-Eing JavaScript First two are done
40. Extinguishing JavaScript Make TypeScript a native browser language Tricky, Microsoft doesn’t “own” a browser or engine Could try pitch a pre-parse types removal like babel plugin Web not like deno, no one time cost for TS
41. Extinguishing JavaScript Make TypeScript differ from JavaScript TC-39 would get annoyed Users would get annoyed Someone would start a typescriptium fork
42. Extinguishing JavaScript Make TypeScript differ from JavaScript TC-39 would get annoyed Users would get annoyed Someone would start a typescriptium fork
43. Extinguishing JavaScript Make TypeScript differ from JavaScript TC-39 would get annoyed Users would get annoyed Someone would start a typescriptium fork
44. Probably not happening
45. One of TypeScript’s primary jobs is to help you migrate from TypeScript source code to plain JavaScript. Turn it to ESNext, run the compiler, delete your ts files and you’re done.
46. Babel will always retain some source compatibility via plugins if everyone wants to leave
47. Flow isn’t going anywhere (to my knowledge) so you can keep JS + types. People will write TypeScript to Flow tools. Hegel has TypeScript d.ts compatibility today
49. TypeScript leans into the JavaScript ecosystem
50. Embrace Extend Enhance
51. Deisolation of tooling Keeping JS Semantics Pushing JS forwards
52. ESTooling
53. ESEmbrace
54. “Types as Comments” in JS?
55. Keeping JS Semantics Keeping the difference between JS and TS negligible is important
56. Loosing JS Semantics Want to make it easy to keep supporting JavaScript users The further the distance between a compile to JS language and JS, the more additional work happens at runtime
57. Expression level regrets
58. Pushing JS forwards
59. ?.
60. Needs to: - add to AST - emit correct JS 125 lines of code in a plugin Anyone can do it Optional chaining in Babel
61. Needs to handle: - New Syntax in AST - New Emitter - Specialized error messages - Code flow analysis - Type narrowing support - Editor integration - Quick Fixes Many follow on PRs Thousands of lines of code Many many test files Not everyone can do it Optional chaining in TypeScript
62. So Design Constraints Prefer working with TC39 Little incentive to break JS Can use TS to remove TS De-isolated tooling
63. Big Title @orta