- Một kỹ sư Google đã ներկայացրել lên ủy ban chuẩn hóa chính thức đề xuất tách JavaScript thành hai ngôn ngữ
- Đề xuất chia thành một phần lõi được triển khai trong runtime engine và một biến thể có nhiều tính năng hơn, phụ thuộc vào các công cụ biên dịch nó
- Bài trình bày đã được đưa ra tại cuộc họp Emca TC39 vào đầu tháng này
- TC39 là ủy ban của Ecma International phụ trách phát triển đặc tả JavaScript (tên chính thức là ECMAScript)
- Shu-yu Guo của Google là người trình bày, và đã soạn slide cùng các đồng tác giả từ Mozilla, Apple, Moddable và Sony
- Shu-yu là chuyên gia về JIT, VM, compiler và chuẩn hóa
- Lập luận của các tác giả
- Các tính năng mới của ngôn ngữ gần như luôn làm suy giảm bảo mật, đồng thời trung lập hoặc tác động tiêu cực tới hiệu năng
- Độ ổn định đôi khi cũng xấu đi, và chức năng ứng dụng chỉ được cải thiện khi nhà phát triển thực sự dùng các tính năng mới
- JavaScript VM (máy ảo) đã trở nên cực kỳ phức tạp do áp lực về tốc độ, điều này làm tổn hại đến bảo mật. Việc này còn trông tệ hơn khi các tính năng mới không được chấp nhận rộng rãi
- Các lỗ hổng bảo mật và “chi phí của độ phức tạp” ở runtime ảnh hưởng đến hàng tỷ lượt sử dụng, trong khi lợi ích thực tế chỉ giới hạn ở những nhà phát triển và ứng dụng thật sự tận dụng được sự phức tạp đó, nên công nghệ nền tảng của JavaScript cần phải đơn giản
- Dù có nhiều tổ chức tham gia, sáng kiến này ở một mức độ nào đó có vẻ do Google dẫn dắt
- Một slide có kèm tuyên bố miễn trừ rằng “giải pháp khả thi này là giải pháp Google ưu tiên và không nhất thiết là giải pháp của các bên triển khai khác”
- Giải pháp được đề xuất
- Không phải quay ngược các tính năng hiện có, mà là thay đổi cách tiếp cận trong tương lai để phần lớn tính năng mới được triển khai ở công cụ thay vì trong engine
- Ngôn ngữ được triển khai trong engine được gọi là "JS0", còn ngôn ngữ được triển khai trong công cụ được gọi là "JSSugar"
- Đây là ý tưởng đặc biệt phù hợp với JavaScript vì nhiều nhà phát triển thực tế đã viết bằng TypeScript và dựa vào các compiler như Babel, Webpack và TypeScript compiler
- Nếu được chấp nhận, các tính năng cú pháp trong tương lai sẽ đi vào JSSugar, còn API và các tính năng chức năng mới sẽ vào JS0
- Một engine tương thích chỉ cần hỗ trợ JS0
- Gánh nặng sẽ được chuyển sang phía các nhà phát triển công cụ để hỗ trợ JSSugar
- Tác dụng phụ là các bên làm công cụ sẽ phải tham gia nhiều hơn vào quy trình tiêu chuẩn hóa, và có thể cần hình thành một nhóm kỹ thuật mới
- Đề xuất này đã gây tranh cãi
- Có những nhà phát triển yêu cầu không trao địa vị chính thức cho các công cụ JavaScript, và nhiều nhà phát triển JavaScript muốn phụ thuộc ít hơn vào các công cụ này
- Dù có sự đồng thuận rộng rãi về việc ưu tiên bảo mật, hiệu năng và độ ổn định, khái niệm khiến JavaScript phụ thuộc vào công cụ trung gian lại không được ưa chuộng
- Một nhà phát triển thậm chí còn nói: "RIP Vanilla JS"
Ý kiến của GN⁺
- Đề xuất này có thể mang lại thay đổi lớn cho hệ sinh thái phát triển JavaScript. Có những lo ngại rằng nhà phát triển sẽ phải phụ thuộc nhiều hơn vào compiler để sử dụng các tính năng cú pháp mới
- Tuy nhiên, bản thân mục tiêu giảm độ phức tạp của runtime engine và cải thiện bảo mật cùng hiệu năng là tích cực. Về dài hạn, điều này có thể giúp ích cho sự phát triển của JavaScript
- Một ngôn ngữ khác áp dụng cách tiếp cận tương tự là Dart. Dart cung cấp cú pháp thân thiện với nhà phát triển nhưng được biên dịch sang JavaScript để chạy trong trình duyệt
- Khi cân nhắc chấp nhận đề xuất này, cần thận trọng xem xét nhiều yếu tố như khả năng tương thích với mã hiện có, trải nghiệm nhà phát triển và hỗ trợ công cụ. Đồng thời cũng cần có quá trình tiếp thu đầy đủ ý kiến từ cộng đồng
- Vì JavaScript là ngôn ngữ nền tảng của phát triển web, dự kiến các cuộc thảo luận và quá trình phát triển sôi động sẽ còn tiếp tục trong tương lai
4 bình luận
Có vẻ như họ định thêm một lớp nữa và bổ sung vào lớp đó những nội dung giúp ích cho DX.
Ngay cả chỉ riêng JSX thôi thì hệ sinh thái cũng đã được xây dựng theo cách cần phải transpile rồi, nên tôi nghĩ đây là một ý kiến thiếu thực tế. Có vẻ như họ đang nghĩ NodeJS là tất cả.
Tôi không chắc mình đã hiểu chính xác chưa, nhưng trong C++ có thứ gọi là BOOST, và nó cho cảm giác khá giống với cái đó. Nếu đề xuất của Google được chấp thuận và tích hợp các thư viện hiện có vào JSSugar, thì sẽ có những gì được đưa vào? Babel?
Ý kiến trên Hacker News
Hotspot VM của Java đã mang lại thành công lớn cho các ngôn ngữ khác. Với JavaScript cũng hợp lý khi nhắm đến một ngôn ngữ lõi theo cách tương tự và tiền biên dịch cú pháp đường thành phần đó
Tốt hơn nên tập trung vào WebAssembly. JavaScript nên dùng cho scripting, còn các ngôn ngữ khác nên dùng cho những ứng dụng lớn hơn
Với tư cách là người thích VanillaJS, có sự không hài lòng với các tính năng ngôn ngữ bị thay đổi một cách cưỡng ép. Cần tập trung cải thiện API để ứng dụng web đạt mức tương đương ứng dụng native
Phản đối nhận định rằng không có trường hợp sử dụng cho BigInt. Dù các lập trình viên frontend của Google không dùng, những nhà phát triển JS khác vẫn đang dùng. Cần tập trung vào sự phát triển của ngôn ngữ
Đáng lẽ nên tách JavaScript và Wasm. Thay vào đó, Wasm bị biến thành công dân hạng hai, không thể truy cập web API
Giải pháp được đề xuất không giải quyết vấn đề gốc rễ mà còn khiến mọi thứ phụ thuộc vào công cụ. JavaScript nên chuyển sang một ngôn ngữ mới để giảm chi phí hiệu năng và độ phức tạp
Các vấn đề phát sinh do sự tách rời giữa TC39 và cộng đồng nhà phát triển. Công cụ TypeScript chưa được chuẩn hóa và cũng không có kế hoạch port sang Rust
Các thay đổi JavaScript được đề xuất do vấn đề bảo trì engine V8 của Google. Các vấn đề bảo mật và chi phí do độ phức tạp gây ảnh hưởng đến người dùng. Nên thử một ngôn ngữ khác thay cho C++