TypeScript nhanh hơn gấp 10 lần
(devblogs.microsoft.com)- Microsoft công bố TypeScript cải thiện hiệu năng gấp 10 lần thông qua việc port compiler và công cụ sang bản native
- Thời gian khởi động editor được cải thiện đáng kể, thời gian build rút ngắn 10 lần, và mức sử dụng bộ nhớ giảm mạnh
- Dự kiến phát hành bản xem trước
tscvào giữa năm 2025, và cung cấp đầy đủ khả năng build dự án cùng dịch vụ ngôn ngữ vào cuối năm 2025
Bối cảnh cải thiện hiệu năng TypeScript
- Giá trị cốt lõi của TypeScript là trải nghiệm lập trình viên xuất sắc
- Giá trị của TypeScript tăng lên khi codebase lớn hơn, nhưng ở các dự án quy mô lớn thì phát sinh vấn đề về hiệu năng
- Xuất hiện vấn đề thời gian tải và kiểm tra kéo dài
- Cần cân bằng giữa thời gian khởi động editor nhanh và việc phân tích toàn bộ codebase
- Các tính năng dựa trên AI cần cung cấp thông tin ngữ nghĩa nhanh và chính xác
- Nhu cầu xác minh trạng thái codebase thông qua build dòng lệnh đang gia tăng
Kế hoạch triển khai bản port native
- Bắt đầu công việc port native cho compiler và công cụ của TypeScript
- Mục tiêu cải thiện hiệu năng:
- Rút ngắn mạnh thời gian khởi động editor
- Giảm thời gian build tối đa 10 lần
- Giảm mức sử dụng bộ nhớ
- Giữa năm 2025: dự kiến phát hành bản preview
tsccó thể kiểm tra kiểu từ dòng lệnh - Cuối năm 2025: dự kiến cung cấp đầy đủ khả năng build dự án và dịch vụ ngôn ngữ
Chạy mã và kiểm thử
- Có thể build và chạy mã tại kho lưu trữ mã TypeScript Go
- Kho lưu trữ cung cấp hướng dẫn build và chạy
tsccùng language server - Sẽ có cập nhật định kỳ về các tính năng mới
Nhanh hơn đến mức nào?
- Kết quả thử nghiệm thời gian build của các dự án TypeScript hiện tại trên nhiều codebase phổ biến cho thấy các cải thiện hiệu năng như sau:
- Dự án VS Code với khoảng 1,5 triệu dòng mã: từ 77,8 giây xuống 7,5 giây, tức nhanh hơn khoảng 10,4 lần
- Dự án Playwright với khoảng 350 nghìn dòng mã: từ 11,1 giây xuống 1,1 giây, tức cải thiện khoảng 10,1 lần
- Dự án TypeORM với khoảng 270 nghìn dòng mã: từ 17,5 giây xuống 1,3 giây, tức cải thiện khoảng 13,5 lần
- Dự án date-fns với khoảng 100 nghìn dòng mã: từ 6,5 giây xuống 0,7 giây, tức cải thiện khoảng 9,5 lần
- Dự án tRPC với khoảng 18 nghìn dòng mã: từ 5,5 giây xuống 0,6 giây, tức cải thiện khoảng 9,1 lần
- Dự án rxjs với khoảng 2 nghìn dòng mã: từ 1,1 giây xuống 0,1 giây, tức cải thiện khoảng 11 lần
- Dù chức năng vẫn chưa hoàn thiện đầy đủ, hiệu năng được kỳ vọng sẽ cải thiện hơn 10 lần trên phần lớn codebase
- Giờ đây có thể kiểm tra kiểu và điều hướng mã nhanh hơn
- Có thể hỗ trợ tích hợp công cụ AI và refactor nâng cao
Cải thiện hiệu năng editor
- Cải thiện tốc độ tải và phản hồi của editor
- Thời gian tải dựa trên codebase của Visual Studio Code:
- Hiện tại: 9,6 giây → bản native: 1,2 giây (cải thiện khoảng 8 lần)
- Mức sử dụng bộ nhớ cũng giảm khoảng 50%
- Dự kiến hiệu năng của các tác vụ dịch vụ ngôn ngữ (tự động hoàn thành, xem nhanh thông tin, đi tới định nghĩa, v.v.) cũng sẽ được cải thiện
- Việc chuyển đổi đang được tiến hành dựa trên Language Server Protocol (LSP)
Lộ trình phiên bản
- TypeScript 5.8 đã phát hành, TypeScript 5.9 sẽ sớm ra mắt
- Codebase TypeScript dựa trên JS sẽ tiếp tục được phát triển trong dòng phiên bản 6.x
- Khi codebase native ổn định, dự kiến sẽ phát hành dưới tên TypeScript 7.0
- TypeScript 6 → phiên bản dựa trên JS
- TypeScript 7 → phiên bản dựa trên native
- Sau khi TypeScript 7 phát hành, dòng 6.x vẫn sẽ được duy trì trong một khoảng thời gian
Bước tiếp theo
- Dự kiến sẽ công bố thêm thông tin về hiệu năng, Compiler API, LSP, v.v.
- Có thể xem các câu hỏi thường gặp tại GitHub FAQ
- Dự kiến tổ chức AMA trên Discord của cộng đồng TypeScript vào ngày 13 tháng 3 năm 2025 (10:00 sáng PDT | 5:00 chiều UTC)
24 bình luận
Tôi có cảm giác mọi người đang ném ra nhận định mà không thực sự nghĩ đến
structural typing.Nếu muốn viết lại bằng ngôn ngữ dùng nominal typing như C# hay Rust thì sẽ phải thay đổi quá nhiều cấu trúc nền tảng của dự án, nên chắc hẳn không dễ.
Trong số các ngôn ngữ áp dụng structural typing, nếu muốn đạt hiệu năng cao hơn nền tảng JS hiện có thì có lẽ chỉ còn C++ hoặc Golang, mà nếu tính cả năng suất phát triển thì gần như không có phương án thay thế.
Từ lúc nào đó tôi đã bắt đầu ít đụng đến TS hơn, nhưng thấy tin như thế này lại thấy khá hứng thú nhỉ?
Nếu trong
tsmà lạm dụngany, trừ những trường hợp thực sự bất khả kháng, thì cũng chẳng khác gì dùng vanilla thôi... haCó vẻ tranh luận đang khá nóng nên chính Anders Hejlsberg đã để lại bình luận trực tiếp.
https://github.com/microsoft/typescript-go/…
Một người mong muốn TypeScript được biên dịch để cho ra kết quả là tệp nhị phân ngay lập tức
Mình không rành phần front-end lắm.. vậy cái này khác gì so với swc?
SWC tập trung vào việc tạo ra mã JavaScript tương thích như Babel và cả bundling, còn cái này tập trung vào việc chuyển mã TypeScript sang JavaScript hoặc kiểm tra lỗi.
Người ta hay nói đến việc “ăn thức ăn cho chó của chính mình”, tức là tự trực tiếp dùng thứ mình tạo ra. Nhưng với ngôn ngữ thì đúng là có chút đáng để suy nghĩ.
Theo ý kiến cá nhân tôi, các runtime của JS làm nền tảng cho TS (ví dụ: spidermonkey, v8) phần lớn đều được viết bằng C++, và cũng không có runtime nào được triển khai bằng JS.
Nhìn vào chuyện ngay cả biên dịch
js -> jsmà nếu dùng pure JS thì quá chậm nên ai cũng chuyển sang esbuild với các công cụ tương tự,thì tôi cũng thấy băn khoăn liệu trong TS có nhất thiết phải cố chấp với chuyện tự ăn thức ăn cho chó của mình hay không.
Tôi lo rằng về sau việc quản lý codebase TypeScript hiện có sẽ bị sao nhãng.
Tin vui đây! Thật thú vị là ngôn ngữ TypeScript của MS dường như, trái với dự đoán, đã đưa ra khá nhiều lựa chọn thật sự bất ngờ. Xét từ phía MS, đây gần như là dự án mã nguồn mở đầu tiên của họ, và khác với Dart của Google từng nhắm tới việc thay thế JS, lựa chọn bổ sung cho JS này cũng khiến tôi thấy rất sáng suốt; ngoài ra, dù hẳn họ cũng có không ít ngôn ngữ nội bộ để dùng cho lần port native này, việc họ chọn Go của Google cũng rất đáng ngạc nhiên.
Ơ, hình như bên deno đã có một toolchain dựa trên Rust rồi mà... sao đột nhiên lại là Go vậy?
Có vẻ như bạn đang nói đến runtime như Node, còn điều đang được nhắc tới ở đây là trình biên dịch của chính ngôn ngữ TS.
À, đọc kỹ thêm một chút thì có vẻ tôi đã bị nhầm vì có đoạn nói editor trở nên nhanh hơn.
tscnhanh hơn gấp 10 lần. Tức là thời gian transpile từts->jsgiảm đi rất nhiều.tsnhư VSCode, tốc độ sẽ nhanh hơn rất nhiều. Tức là logic dùng chung các chức năng củatscnhư kiểm tra cú pháp củatsđã nhanh hơn.Hóa ra là nội dung như vậy.
Khi dùng generic type được cấu thành bằng đệ quy, tôi từng gặp tình trạng chậm nên phải dùng phương án thay thế. Nếu nhanh hơn 10 lần thì cũng khá đáng mong đợi vì có thể những chỗ như thế này sẽ được cải thiện.
Chuỗi thảo luận về việc tại sao lại là Go khá thú vị nhé.
https://github.com/microsoft/typescript-go/discussions/411
Cũng có khá nhiều điều cần phải cân nhắc...
Đúng vậy, nhưng tôi cũng hiểu được tâm trạng của các lập trình viên .NET...
Các lập trình viên .NET và Rust có vẻ đang rất tức giận.
Tôi hiểu .NET, nhưng tôi nghĩ Rust ở vị trí tương tự như Go. Có lẽ các dự án và thư viện liên quan đến JS được xây dựng sẵn bằng Go trước đây cũng đã ảnh hưởng đến quyết định này.
Việc phát triển cho ngôn ngữ C# không hẳn đã dừng lại, nhưng mình có cảm giác có quá nhiều framework dùng C# đang bị bỏ mặc.
Viết bằng Go~
Rất đáng mong đợi.
Ý kiến Hacker News
tscnhanh bằng Rust trước đâystc: đã ngừngezno: đang được phát triển tích cực và không nhắm tới việc tương ứng 1:1 vớitsc