How Does the
TypeScript Team Try to
Avoid Negative Effects
on the JS Ecosystem
By @Orta at devX SAP
Slide 2
Slide 2 text
No content
Slide 3
Slide 3 text
No content
Slide 4
Slide 4 text
No content
Slide 5
Slide 5 text
Goals
Why would a TypeScript dev even
give a talk like this?
Slide 6
Slide 6 text
Big
Title
Why is TypeScript
good for individuals
or teams.
Most
talks
Slide 7
Slide 7 text
This
talk
TypeScript is big enough
to affect the whole JS
ecosystem
What constraints does the
team put on TypeScript to
avoid harming JavaScript
Slide 8
Slide 8 text
No content
Slide 9
Slide 9 text
• 8-ish on the compiler
• 20 folks altogether
What is the TypeScript Team?
Slide 10
Slide 10 text
How does the team work?
Slide 11
Slide 11 text
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
Slide 12
Slide 12 text
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
Slide 13
Slide 13 text
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
Slide 14
Slide 14 text
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
Slide 15
Slide 15 text
Why make TypeScript, and
what defines “Big enough”?
Slide 16
Slide 16 text
https://insights.stackoverflow.com/survey/2020
Slide 17
Slide 17 text
TypeScript solves
real problems in Microsoft
TypeScript is incredible PR
for Microsoft
TC-39 has
to represent
many voices
JS Engines
Browsers
Node
Dev Tools
Web Devs
Language Enthusiasts
Beginners to JavaScript
Slide 34
Slide 34 text
TypeScript is
a welcome
contributor
Slide 35
Slide 35 text
How could that
popularity be abused?
Slide 36
Slide 36 text
No content
Slide 37
Slide 37 text
MalevolenTypeScript
Slide 38
Slide 38 text
Can’t charge money
Can’t go closed source
Have to embrace, extend
& extinguish JavaScript
MalevolenTypeScript
Slide 39
Slide 39 text
E-E-Eing JavaScript
First two
are done
Slide 40
Slide 40 text
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
Slide 41
Slide 41 text
Extinguishing JavaScript
Make TypeScript differ from JavaScript
TC-39 would get annoyed
Users would get annoyed
Someone would start a typescriptium fork
Slide 42
Slide 42 text
Extinguishing JavaScript
Make TypeScript differ from JavaScript
TC-39 would get annoyed
Users would get annoyed
Someone would start a typescriptium fork
Slide 43
Slide 43 text
Extinguishing JavaScript
Make TypeScript differ from JavaScript
TC-39 would get annoyed
Users would get annoyed
Someone would start a typescriptium fork
Slide 44
Slide 44 text
Probably not happening
Slide 45
Slide 45 text
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.
Slide 46
Slide 46 text
Babel will always retain some source
compatibility via plugins if everyone
wants to leave
Slide 47
Slide 47 text
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
Slide 48
Slide 48 text
No content
Slide 49
Slide 49 text
TypeScript leans into
the JavaScript ecosystem
Slide 50
Slide 50 text
Embrace
Extend
Enhance
Slide 51
Slide 51 text
Deisolation of tooling
Keeping JS Semantics
Pushing JS forwards
Slide 52
Slide 52 text
ESTooling
Slide 53
Slide 53 text
ESEmbrace
Slide 54
Slide 54 text
“Types as Comments” in JS?
Slide 55
Slide 55 text
Keeping JS Semantics
Keeping the difference between JS and TS negligible is important
Slide 56
Slide 56 text
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
Slide 57
Slide 57 text
Expression level regrets
Slide 58
Slide 58 text
Pushing JS forwards
Slide 59
Slide 59 text
?.
Slide 60
Slide 60 text
Needs to:
- add to AST
- emit correct JS
125 lines of code in a plugin
Anyone can do it
Optional chaining in Babel
Slide 61
Slide 61 text
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
Slide 62
Slide 62 text
So Design Constraints
Prefer working with TC39
Little incentive to break JS
Can use TS to remove TS
De-isolated tooling