Tất cả chúng ta đều biết và yêu thích [?] JavaScript và tất cả chúng ta chỉ làm việc với nó bằng cách viết mã và sau đó thực thi nó trong thời gian chạy yêu thích của mình [cụ thể là trình duyệt, nút. js và Deno]. Nhưng bạn đã bao giờ biên dịch nó chưa?
Đợi đã, hãy sao lưu trong giây lát, JavaScript là một ngôn ngữ động, tất cả chúng ta đều biết điều đó. Nó cũng được giải thích [tốt, hầu hết] và nằm ngoài thời gian chạy thông thường, tất cả chúng đều sử dụng trình biên dịch JIT để tối ưu hóa nó trong quá trình thực thi
Đó là sự thật
Nhưng nó có thể được biên dịch? . Có thể biên dịch trước một ngôn ngữ động [cái còn được gọi là biên dịch AOT hoặc Ahead-Of-Time], vâng, nhưng nó có đáng không?
AOT so với JIT
Hãy để tôi nhanh chóng đi vào chi tiết hơn một chút về AOT và JIT, bởi vì nếu không, bài viết này sẽ quá ngắn [và tốt, đây là những chủ đề có liên quan mà bạn cũng có thể thấy hữu ích]
Sự khác biệt chính giữa AOT và JIT rõ ràng là ở thời điểm chúng diễn ra. Mặc dù AOT được thực hiện trước khi thực thi mã của bạn, nhưng JIT lại xảy ra trong quá trình thực thi đó. Những gì khác là khác nhau?
Hầu hết mọi thứ khác thực sự
AOT thường dành cho các ngôn ngữ được nhập tĩnh vì đối với chúng, không có hành vi động nào cần được kiểm tra và xác định trong quá trình thực thi. Tất cả các quy tắc được trình bày ngay trong mã, vì vậy trình biên dịch có thể đọc nó, hiểu cách dữ liệu chảy bên trong và tối ưu hóa cho phù hợp, đồng thời, dịch mã thành cách diễn giải gốc [còn được gọi là mã máy]
Mặt khác, trình biên dịch JIT được sử dụng với các ngôn ngữ được nhập động, bởi vì nó đảm nhiệm việc giám sát quá trình thực thi mã của bạn và dựa trên loại dữ liệu mà nó xử lý, nó sẽ tối ưu hóa và tạo mã máy tốt hơn
Nếu bạn nghĩ về cả hai trường hợp về Thời gian để tối ưu hóa mã đã biên dịch, cách AOT sẽ cung cấp cho bạn phiên bản mã được tối ưu hóa ngay từ đầu. Bạn sẽ bắt đầu thực hiện với một phiên bản tối ưu của nó. Mặt khác, mã JIT'ed của bạn sẽ mất một khoảng thời gian để tăng tốc, nhưng nó có khả năng tiến xa hơn và tốt hơn vì như bạn có thể đọc ở đây, có nhiều khía cạnh khác cần được tối ưu hóa trong thời gian chạy hơn là chỉ định nghĩa kiểu [
Chắc chắn có những ưu và nhược điểm đối với mỗi cái, nhưng nếu tôi phải tóm tắt và quyết định cái nào tốt hơn, tôi sẽ nói
- Sử dụng giải pháp thay thế AOT nếu mã của bạn chỉ chạy trong một thời gian ngắn
- Sử dụng phiên bản JIT trong các trường hợp khi mã của bạn chạy trong thời gian dài hơn, do đó cho phép tối ưu hóa tiềm năng tốt hơn sau khi thực hiện một số phân tích thời gian chạy
Nhưng còn việc biên dịch mã JavaScript của bạn thì sao?
Một lần nữa, có một lý do tại sao JavaScript được giải thích và JIT'ed và không được biên dịch trực tiếp thành mã gốc. bản chất năng động của ngôn ngữ phù hợp hơn với chiến lược biên dịch Just-In-Time
Mặc dù vậy, hãy cẩn thận, tôi không đề cập đến WebAssugging ở đây. Trong trường hợp đó, WASM đang biên dịch bất kỳ mã nào [C, C++ hoặc bất kỳ mã nào khác] thành mã gốc tương thích với thời gian chạy Javascript. Điều đó không giống như biên dịch JavaScript
Thành thật mà nói, không có nhiều dự án cố gắng biên dịch JavaScript thành mã máy gốc, bởi vì tôi chắc chắn rằng nó có thể chứng tỏ là một nhiệm vụ khá khó khăn, ý tôi là, chỉ cần xem xét việc biên dịch đoạn mã sau
Bạn thực sự có thể biết trước loại biến result không? . Tuy nhiên, bạn giải quyết nó như thế nào, bạn sẽ thêm rất nhiều logic vào đầu quá trình thực thi, chỉ để có thể thực thi nó. Điều đó nghe có vẻ không hiệu quả lắm
Tuy nhiên, có một dự án đang cố gắng đạt được điều này, mặc dù không phải là lý tưởng [ít nhất là trên giấy tờ]. mật hoaJS
Biên dịch với NectarJS
Dự án này nhằm mục đích biên dịch JavaScript thành mã gốc để bạn có thể chạy nó trên bất kỳ nền tảng tương thích nào. Ngay bây giờ, danh sách đó bao gồm Windows, Linux, Arduino, STM32 Nucleo, Android, Web [WASM], macOS và SunOS
Mặc dù đúng là hầu hết các nền tảng này đều đã có trình thông dịch mà bạn có thể chạy JavaScript của mình, nhưng mục đích là để làm cho đầu ra được biên dịch cuối cùng hoạt động hiệu quả hơn các tùy chọn hiện có
Theo kết quả của họ, họ đã thực hiện một số cải tiến trên Windows bằng Node. js [v12]. Không nhất thiết phải cải thiện tốc độ trong một số trường hợp, mà là dung lượng bộ nhớ và thậm chí cả kích thước tệp đầu ra
Bảng được lấy từ trang web của NectarJS
Đúng là dự án vẫn có những hạn chế, đặc biệt là hiện tại, nó chỉ hỗ trợ khoảng 80% ES3, điều đó có nghĩa là JS bạn có thể viết rất hạn chế và không theo tiêu chuẩn ngày nay
Nhưng một lần nữa, bạn có thể không bắt buộc phải viết mã tương thích với ES6 cho dự án cụ thể của mình và khả năng biên dịch và chạy nó nguyên bản trên bo mạch Arduino của bạn có thể rất hữu ích
Cài đặt và thử nghiệm NectarJS
Dự án có thể được cài đặt trực tiếp dưới dạng mô-đun NPM, vì vậy tất cả những gì bạn phải làm là chạy dòng sau [tất nhiên là giả sử bạn đã cài đặt Node]
$ npm install nectarjs -gSau khi cài đặt, miễn là bạn có tệp , bạn có thể viết một ví dụ HelloWorld cơ bản và biên dịch nó
Để biên dịch nó, chỉ cần sử dụng lệnh sau
$ nectar your-file.jsĐây là kết quả tôi nhận được khi chạy nó trên OSX của mình
Lưu ý tệp được tạo không có phần mở rộng, đó là tệp nhị phân. Nếu bạn cấp cho nó quyền thực thi, bạn đã sẵn sàng để thực thi nó. Điều đó đơn giản, và nó hoạt động
Đây có phải là tương lai của JavaScript?
Cá nhân, tôi sẽ không đặt cược vào nó. Bản thân dự án dường như vẫn còn ở giai đoạn đầu, chưa hoàn thành tài liệu và chỉ hỗ trợ một phần cho phiên bản ngôn ngữ cũ hơn. Tuy nhiên, nó đang được phát triển tích cực và những điều này có thể thay đổi rất sớm
Đối với việc thực hành biên dịch JavaScript của bạn, tôi không nghĩ rằng nó sẽ trở thành một xu hướng lớn, xét cho cùng, thời gian chạy hiện tại đã được chứng minh là đủ tốt cho các trường hợp sử dụng phổ biến nhất của chúng. Nó có thể hữu ích cho đối tượng thích hợp đang muốn có hiệu suất gốc và không sẵn sàng chuyển sang công nghệ khác không?
Bạn có cân nhắc việc biên dịch mã JS của mình không?
Xây dựng mọi thứ từ các thành phần độc lập
Nói lời tạm biệt với các ứng dụng nguyên khối và để lại cho bạn những giọt nước mắt trong quá trình phát triển của chúng
Tương lai là các thành phần; . Các công cụ OSS như Bit cung cấp trải nghiệm tuyệt vời cho nhà phát triển để xây dựng các thành phần độc lập và soạn ứng dụng. Nhiều nhóm bắt đầu bằng cách xây dựng Hệ thống thiết kế hoặc Giao diện vi mô của họ, thông qua các thành phần được chia sẻ. Hãy thử nó →