GN⁺: 10배 더 빠른 TypeScript
(devblogs.microsoft.com)- Microsoft가 컴파일러와 도구의 네이티브 포팅을 통해 Typescript 성능 10배 향상 발표
- 에디터 시작 시간 대폭 향상, 빌드 타임 10배 단축, 메모리 사용량을 대폭 줄임
- 2025년 중반까지
tsc미리 보기 버전을 출시하고, 2025년 말에 완전한 프로젝트 빌드 및 랭귀지 서비스 제공 예정
TypeScript 성능 개선 배경
- TypeScript의 핵심 가치는 뛰어난 개발자 경험임
- 코드베이스가 커질수록 TypeScript의 가치가 높아지지만, 대규모 프로젝트에서는 성능 문제 발생
- 긴 로드 및 검사 시간 문제 발생
- 빠른 에디터 시작 시간 vs 전체 코드베이스 분석 간의 균형 필요
- AI 기반 기능은 빠르고 정확한 의미 정보 제공 필요
- 명령줄 빌드를 통한 코드베이스 상태 검증 요구 증가
네이티브 포트 진행 계획
- TypeScript 컴파일러와 도구의 네이티브 포트 작업 시작
- 성능 개선 목표:
- 에디터 시작 시간 대폭 단축
- 빌드 시간 최대 10배 단축
- 메모리 사용량 감소
- 2025년 중반: 명령줄 타입 검사 가능한
tsc미리보기 버전 출시 예정 - 2025년 말: 완전한 프로젝트 빌드 및 언어 서비스 제공 예정
코드 실행 및 테스트
- TypeScript Go 코드 저장소에서 코드 빌드 및 실행 가능
- 저장소에서
tsc및 언어 서버 빌드 및 실행 지침 제공 - 새로운 기능에 대한 정기 업데이트 예정
얼마나 빨라졌나?
- 현재 TypeScript 프로젝트의 빌드 시간을 여러 인기 코드베이스에서 테스트한 결과 다음과 같은 성능 향상이 나타남:
- VS Code 프로젝트는 약 150만 줄의 코드에서 기존 77.8초에서 7.5초로 약 10.4배 빨라짐
- Playwright 프로젝트는 약 35만 줄의 코드에서 기존 11.1초에서 1.1초로 약 10.1배 개선
- TypeORM 프로젝트는 약 27만 줄의 코드에서 기존 17.5초에서 1.3초로 약 13.5배 개선
- date-fns 프로젝트는 약 10만 줄의 코드에서 기존 6.5초에서 0.7초로 약 9.5배 개선
- tRPC 프로젝트는 약 1만 8천 줄의 코드에서 기존 5.5초에서 0.6초로 약 9.1배 개선
- rxjs 프로젝트는 약 2천 줄의 코드에서 기존 1.1초에서 0.1초로 약 11배 개선
- 아직 기능이 완전하지 않지만, 대부분의 코드베이스에서 10배 이상의 성능 개선 예상
- 빠른 타입 검사와 코드 탐색 가능해짐
- AI 도구 통합 및 고급 리팩토링 지원 가능
에디터 성능 개선
- 에디터 로드 및 응답 속도 개선
- Visual Studio Code 코드베이스 기준 로드 시간:
- 현재: 9.6초 → 네이티브 버전: 1.2초 (약 8배 개선)
- 메모리 사용량도 약 50% 감소
- 언어 서비스 작업 (자동 완성, 빠른 정보 보기, 정의로 이동 등) 성능 향상 예상
- 언어 서버 프로토콜(LSP) 기반으로 이전 작업 진행 중
버전 로드맵
- TypeScript 5.8 출시 완료, TypeScript 5.9 곧 출시 예정
- JS 기반 TypeScript 코드베이스는 6.x 버전으로 계속 개발 진행
- 네이티브 코드베이스가 안정화되면 TypeScript 7.0으로 출시 예정
- TypeScript 6 → JS 기반 버전
- TypeScript 7 → 네이티브 기반 버전
- TypeScript 7 출시 후에도 6.x 버전은 일정 기간 유지 예정
다음 단계
- 성능, 컴파일러 API, LSP 등에 대한 추가 정보 공개 예정
- GitHub FAQ에서 자주 묻는 질문 확인 가능
- 2025년 3월 13일 TypeScript 커뮤니티 Discord에서 AMA 진행 예정 (PDT 오전 10시 | UTC 오후 5시)
반가운 소식입니다! 신기하게 MS의 타입스크립트 언어는 예상과 달리 정말 의외의(?) 선택들을 많이 하는 것 같습니다. MS 입장에서는 거의 첫번째 오픈소스 프로젝트인데다 JS를 대체하려고 했던 구글의 Dart와 달리 JS를 보완하려고 했던 선택도 참 현명하게 느껴졌고, 이번 네이티브 포팅 언어도 자사 언어도 많고 할텐데 구글의 Go를 선택한 점도 놀랍습니다.
왜 Go 인가란 논의 스레드 재미있네요.
https://github.com/microsoft/typescript-go/discussions/411
고민해야할 것들도 많고...
닷넷은 이해가 가는데 러스트는 go 와 같은 위치라고 생각돠네요 아무래도 기존 만들어진 js 관련 go 프로젝트와 라이브러리도 결정에 영향을 미쳤을것 같숩니다
개인적으로 ts 가 어떤 경우는 유형이 매우 복잡해저서... 거의 포기하다시피 하는 경우(그냥 any로 써버림)가 있는데, 언어에 대해 이해가 부족해서 이겠죠? 상황에 따라 진짜 빨간줄 없애려고 시간낭비 많이 합니다.
논란이 꽤 핫한지 Anders Hejlsberg가 직접 코멘트를 남겼네요
SWC는 바벨처럼 호환 가능한 자바스크립트 코드를 생성하고, 번들링하는 것 까지가 초점이고, 이건 타입스크립트 코드를 자바스크립트로 변환하거나 오류를 체크하는 게 초점입니다.
TypeScript 코드가 더 이상 TypeScript로 작성되지 않으면, 팀이 TypeScript를 직접 사용하지 않게 되어 장기적으로 개발 경험에 영향을 미칠 수 있음
개밥을 먹는다고 하죠. 자신이 만든 것을 직접사용하는. 그런데 언어의 경우는 조금 고민이 되는군요.
개인적인 생각으로 ts의 기반인 js의 runtime들이 (e.g. spidermonkey, v8) 대부분 c++로 짜여져있고 js로 구현한 런타임이 없으며,
js -> js 컴파일또한 pure js를 쓰면 너무 느려 esbuild니 뭐니 다 넘어가는걸 보면,
ts에서도 굳이 개밥먹기를 고집해야하나 싶긴 합니다
아, 글을 좀 더 읽어보니 에디터가 빨라지고 그런 이야기가 있어서 헷갈렸던 것 같네요.
- tsc 가 10배 빨라짐. 즉, ts -> js 트랜스파일링 시간이 매우 줄어듬.
- VSCode 같은 ts 로 개발된 큰 프로젝트를 로드할 때 속도가 매우 빨라짐. 즉, ts 의 구문 검사 등 tsc 의 기능을 공유하는 로직이 빨라졌다는 의미.
- VSCode 가 동작하는 속도가 빨라졌다는 것은 아님
이런 내용이었군요.
재귀로 구성된 제너릭 타입을 사용할 때, 느려져서 차선책을 사용한 경험이 있습니다. 10배라면 이런 부분도 개선할 수 있을지 기대되네요.
Hacker News 의견
- TypeScript 팀의 Daniel Rosenwasser가 발표 소식을 전하며, 팀 리더 Ryan Cavanaugh와 함께 질문에 답변할 준비가 되어 있음
- Discord AMA에서 더 많은 정보를 얻을 수 있음
- 빠른 개발 도구는 훌륭하며, TypeScript 팀이 항상 개발 경험에 깊이 고민하는 점이 기쁨
- TypeScript 코드가 더 이상 TypeScript로 작성되지 않으면, 팀이 TypeScript를 직접 사용하지 않게 되어 장기적으로 개발 경험에 영향을 미칠 수 있음
- Flow가 OCaml로 작성되어 실패한 사례를 언급하며, 팀의 생각이 궁금함
- 이전에 Rust로 빠른 tsc를 시도한 사례로 두 프로젝트를 언급함
- stc: 중단됨
- ezno: 활발히 개발 중이며, tsc와 1:1 대응을 목표로 하지 않음
- 프로젝트가 유연한 스크립팅 언어로 시작하지만, 결국 더 네이티브한 표현이 승리하는 경우가 많음
- 낮은 수준의 표현으로 시작하는 것이 더 나을 수도 있다고 생각함
- JS 런타임을 서버에서 사용하는 기본 가정을 재고하게 됨
- 스크립팅 언어의 장점이 점점 줄어들고 있음
- 잠시 만우절인 줄 알았음
- Go를 선택한 것이 좋음
- Rust 대신 Go를 선택한 것이 인상적임
- AOT 컴파일된 .NET을 선택하지 않은 것이 아쉬움
- 새로운 코드베이스를 기존과 최대한 호환되게 유지하는 것이 중요함
- Go의 문법이 TypeScript 코드베이스와 유사하여 포팅이 용이함
- Golang과 TypeScript의 문법적 유사성에 놀람
- Golang에서 sum types를 사용하기 어려웠던 경험을 공유함
- Daniel과 Anders가 네이티브 포트에 대해 심도 있는 논의를 한 팟캐스트를 소개함
- 대규모 TypeScript 파일을 리팩토링하는 과정에서 성능 문제가 발생함
- TypeScript로의 코드베이스 전환이 팀에 큰 도움이 되었지만, 성능 문제는 여전히 존재함
- PHP를 사용하다가 4년 전부터 TypeScript를 사용하기 시작함
- TypeScript의 타입 시스템이 유용하며, 컴파일 속도가 빠름
- Microsoft의 팬은 아니지만, TypeScript는 잘 만들어진 언어라고 생각함