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
2. None
3. None
4. None

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
8. None

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
18. None
19. None

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

27. None
28. None
29. None
30. None

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?

36. None

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
48. None

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