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
   

   View Slide

2. View Slide

3. View Slide

4. View Slide

5. Goals
   Why would a TypeScript dev even
   give a talk like this?
   

   View Slide

6. Big
   Title
   Why is TypeScript
   good for individuals
   or teams.
   Most
   talks
   

   View Slide

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
   

   View Slide

8. View Slide

9. • 8-ish on the compiler
   • 20 folks altogether
   What is the TypeScript Team?
   

   View Slide

10. How does the team work?
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

15. Why make TypeScript, and
    what defines “Big enough”?
    

    View Slide

16. https://insights.stackoverflow.com/survey/2020
    

    View Slide

17. TypeScript solves 

    real problems in Microsoft
    TypeScript is incredible PR
    for Microsoft
    

    View Slide

18. View Slide

19. View Slide

20. JS
    JS + JSDoc
    JS+TS Mixed
    TypeScript
    TypeScript - Strict
    TypeScript Userbase
    

    View Slide

21. IDE Features on every desk
    

    View Slide

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
    

    View Slide

23. A bet on TypeScript,
    is a bet on JavaScript?
    

    View Slide

24. Erasable, Gradual, Structural, Generic, Inferable,
    Expressive, Object-oriented & Functional
    “
    TypeScript is a …
    Type system “
    

    View Slide

25. Types only
    

    View Slide

26. Types mostly
    

    View Slide

27. View Slide

28. View Slide

29. View Slide

30. View Slide

31. TC-39 and TypeScript
    are best friends
    

    View Slide

32. https://medium.com/braintree-product-technology/a-year-plus-a-little-on-tc39-a1acb87eb862
    

    View Slide

33. TC-39 has
    to represent
    many voices
    JS Engines
    Browsers
    Node
    Dev Tools
    Web Devs
    Language Enthusiasts
    Beginners to JavaScript
    

    View Slide

34. TypeScript is
    a welcome
    contributor
    

    View Slide

35. How could that
    popularity be abused?
    

    View Slide

36. View Slide

37. MalevolenTypeScript
    

    View Slide

38. Can’t charge money
    Can’t go closed source
    Have to embrace, extend
    & extinguish JavaScript
    MalevolenTypeScript
    

    View Slide

39. E-E-Eing JavaScript
    First two
    are done
    

    View Slide

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
    

    View Slide

41. Extinguishing JavaScript
    Make TypeScript differ from JavaScript
    TC-39 would get annoyed
    Users would get annoyed
    Someone would start a typescriptium fork
    

    View Slide

42. Extinguishing JavaScript
    Make TypeScript differ from JavaScript
    TC-39 would get annoyed
    Users would get annoyed
    Someone would start a typescriptium fork
    

    View Slide

43. Extinguishing JavaScript
    Make TypeScript differ from JavaScript
    TC-39 would get annoyed
    Users would get annoyed
    Someone would start a typescriptium fork
    

    View Slide

44. Probably not happening
    

    View Slide

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.
    

    View Slide

46. Babel will always retain some source
    compatibility via plugins if everyone
    wants to leave
    

    View Slide

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
    

    View Slide

48. View Slide

49. TypeScript leans into
    the JavaScript ecosystem
    

    View Slide

50. Embrace
    Extend
    Enhance
    

    View Slide

51. Deisolation of tooling
    Keeping JS Semantics
    Pushing JS forwards
    

    View Slide

52. ESTooling
    

    View Slide

53. ESEmbrace
    

    View Slide

54. “Types as Comments” in JS?
    

    View Slide

55. Keeping JS Semantics
    Keeping the difference between JS and TS negligible is important
    

    View Slide

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
    

    View Slide

57. Expression level regrets
    

    View Slide

58. Pushing JS forwards
    

    View Slide

59. ?.
    

    View Slide

60. Needs to:
    - add to AST
    - emit correct JS
    125 lines of code in a plugin
    Anyone can do it
    Optional chaining in Babel
    

    View Slide

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
    

    View Slide

62. So Design Constraints
    Prefer working with TC39
    Little incentive to break JS
    Can use TS to remove TS
    De-isolated tooling
    

    View Slide

63. Big
    Title
    @orta
    

    View Slide