Các nhà phát triển nêu lo ngại về hiệu suất của công cụ TypeScript mới trên trình duyệt sử dụng Synchronous XHR

Nhóm Cộng đồng BigGo
Các nhà phát triển nêu lo ngại về hiệu suất của công cụ TypeScript mới trên trình duyệt sử dụng Synchronous XHR

Một công cụ mới có tên tsbro hứa hẹn chạy TypeScript trực tiếp trên trình duyệt mà không cần các bước build, nhưng các nhà phát triển đang đặt câu hỏi về cách tiếp cận kỹ thuật và tác động đến hiệu suất của nó. Công cụ này nhằm giải quyết vấn đề TypeScript là công dân hạng hai trong trình duyệt bằng cách bỏ qua các hệ thống import truyền thống.

Thông số kỹ thuật:

  • Sử dụng SWC WebAssembly để biên dịch TypeScript (kích thước tải xuống hơn 5MB)
  • Sử dụng XHR đồng bộ để tải file
  • Chuyển đổi ES modules sang định dạng CommonJS
  • Hỗ trợ JSX với pragma có thể cấu hình
  • Yêu cầu importmap để quản lý package

Vấn đề hiệu suất với cách tiếp cận Synchronous XHR

Tranh cãi chính tập trung vào việc tsbro sử dụng XMLHttpRequest (XHR) đồng bộ để tải và biên dịch các file TypeScript. Cách tiếp cận này đã thu hút sự chỉ trích từ các nhà phát triển có kinh nghiệm, những người cảnh báo về các vấn đề hiệu suất nghiêm trọng. Bản chất đồng bộ có nghĩa là trình duyệt phải đợi từng file tải xuống và biên dịch trước khi chuyển sang file tiếp theo, tạo ra một nút thắt cổ chai có thể khiến các dự án lớn hơn trở nên không thể sử dụng được.

Công cụ hoạt động bằng cách tải code TypeScript một cách đồng bộ, chuyển đổi nó bằng SWC WebAssembly, chuyển đổi ES modules sang định dạng CommonJS, và sau đó đánh giá kết quả. Mặc dù điều này tạo ra trải nghiệm phát triển liền mạch, nhưng nó đi kèm với những đánh đổi đáng kể.

Lưu ý: Synchronous XHR chặn main thread của trình duyệt, ngăn cản các hoạt động khác chạy cho đến khi request hoàn thành.

Các vấn đề về hiệu suất:

  • XHR đồng bộ chặn luồng chính của trình duyệt
  • Hiệu suất kém với các biểu đồ module lớn
  • Tải xuống WebAssembly ban đầu 5MB+
  • Stack traces trở nên khó đọc do quá trình transpilation
  • Hiện tại chưa có hỗ trợ source map

Các giải pháp thay thế và thách thức kỹ thuật

Các cuộc thảo luận trong cộng đồng tiết lộ một số cách tiếp cận thay thế có thể giải quyết những lo ngại về hiệu suất này. Một số nhà phát triển đề xuất sử dụng service workers để chặn các request TypeScript và biên dịch chúng một cách bất đồng bộ trong nền. Phương pháp này sẽ tránh chặn main thread của trình duyệt trong khi vẫn cung cấp chức năng mong muốn.

Một giải pháp được đề xuất khác liên quan đến việc duyệt import graph một cách bất đồng bộ để thu thập tất cả các file trước, sau đó chuyển chúng qua compiler theo batch. Cách tiếp cận này đã được sử dụng thành công bởi dự án Playground Elements của Google cho các mẫu code tương tác.

Tuy nhiên, những giải pháp thay thế này đối mặt với những thách thức riêng. Gói SWC WebAssembly mà tsbro sử dụng có trọng lượng hơn 5MB, phải được tải xuống trước khi bất kỳ quá trình biên dịch nào có thể bắt đầu. Điều này tạo ra một penalty tải ban đầu đáng kể ảnh hưởng đến trải nghiệm người dùng.

Các Phương Pháp Thay Thế:

  • Biên dịch dựa trên service worker (được sử dụng bởi sucrase-build-iife)
  • Duyệt đồ thị import bất đồng bộ ( Google Playground Elements )
  • Biên dịch phía server với các endpoint chuyên dụng
  • Các giải pháp tập trung vào WebAssembly để hỗ trợ đa ngôn ngữ

Tác động rộng hơn đối với phát triển web

Cuộc thảo luận xung quanh tsbro phản ánh các cuộc tranh luận lớn hơn về độ phức tạp của trình duyệt và quy trình phát triển. Một số nhà phát triển cho rằng việc thêm nhiều tính năng vào trình duyệt làm tăng độ phức tạp và tạo ra gánh nặng bảo trì lâu dài do yêu cầu tương thích ngược. Họ đề xuất tập trung vào việc cải thiện hỗ trợ WebAssembly thay vào đó, điều này sẽ cho phép các nhà phát triển sử dụng bất kỳ ngôn ngữ nào trong khi giữ các API trình duyệt đơn giản.

Những người khác chỉ ra rằng các nhà phát triển muốn truy cập hạng nhất vào các API trình duyệt như DOM mà không có penalty hiệu suất, khiến các công cụ như tsbro trở nên có giá trị bất chấp những hạn chế của chúng. Thách thức nằm ở việc cân bằng sự tiện lợi cho nhà phát triển với hiệu suất kỹ thuật và tính bền vững lâu dài.

Kết luận

Mặc dù tsbro giải quyết một nhu cầu thực sự cho quy trình phát triển TypeScript đơn giản hơn, việc triển khai hiện tại của nó nêu ra những lo ngại hợp lý về hiệu suất và khả năng mở rộng. Cuộc thảo luận trong cộng đồng làm nổi bật sự căng thẳng liên tục giữa trải nghiệm nhà phát triển và tối ưu hóa kỹ thuật trong các công cụ phát triển web. Khi dự án phát triển, việc giải quyết những lo ngại về hiệu suất này thông qua các kiến trúc thay thế như service workers hoặc biên dịch bất đồng bộ có thể giúp thực hiện tiềm năng của nó trong khi tránh những cạm bẫy của các hoạt động đồng bộ.

Tham khảo: tsbro