Các hướng dẫn phổ biến như YouMightNotNeedJQuery.com và You Don’t Need Lodash/Underscore đã thách thức các thông lệ phổ biến trong ngành.
Bài đăng này không hoang dã như YouMightNotNeedJS.com, nhưng nó giải thích chi tiết về việc dịch mã và giải thích lý do tại sao nó có thể không cần thiết trong tương lai gần.
StatCounter thu thập dữ liệu về hơn 15 tỷ lượt xem trang mỗi tháng từ 2,5 triệu trang web trên toàn cầu. Kể từ tháng 5 năm 2017, đây là hiện trạng:
Điều làm cho biểu đồ này trở nên thú vị là 3 trình duyệt hàng đầu (Chrome, Safari và FireFox) là thường xanh, có nghĩa là 74% người dùng tự động nhận được phiên bản trình duyệt mới nhất của họ.
Hãy xem liệu giả định này có đúng không.
Dưới đây là các phiên bản trình duyệt hàng đầu trên thị trường:
Chrome 58 được phát hành cách đây chưa đầy một tháng và phiên bản dành cho máy tính để bàn của nó chiếm 12,77% thị phần trình duyệt toàn cầu. Chrome 57 được phát hành chỉ 42 ngày trước đó và phiên bản dành cho máy tính để bàn của nó chiếm 9,96% thị trường trình duyệt toàn cầu. Thật không may, StatCounter không phân biệt giữa các phiên bản chrome trên nền tảng di động nhưng giả sử tỷ lệ giống như máy tính để bàn, chúng tôi kết thúc với:
Nó có ý nghĩa gì đối với mã của tôi?
Theo ES Compatibility Table, phiên bản mới nhất của tất cả các trình duyệt chính đều hỗ trợ rất tốt cho các tính năng của ES6:
Nói cách khác, nếu bạn đang chuyển mã JavaScript của mình sang ES5, thì bạn đang làm cho mã của mình lớn và chậm một cách không cần thiết để hỗ trợ một số ít người dùng, những người có thể sẽ nâng cấp hệ thống của họ vào thời điểm bạn quản lý để định cấu hình Webpack và Babel của mình! ?
Tại sao bạn vẫn dịch mã?
Bạn vẫn có thể muốn dịch mã của mình nhưng hy vọng sau khi cân nhắc nhược điểm và ưu điểm hoặc các giải pháp thay thế khả thi:
- Bạn đang sử dụng React JSX (hiện tại khá phổ biến nên tôi cho rằng có rất nhiều nhà phát triển phù hợp với danh mục này). JSX cốt lõi của nó là một chuyển đổi của mã XHTML sang mã JS và không cần bộ chuyển mã đầy đủ như Babel. Ngoài ra, nếu tất cả những gì bạn cần là VirtualDom, hãy sử dụng nó để thay thế.
- Bạn muốn thử các tính năng mới nhất của ngôn ngữ. Trừ khi bạn là một phần của TC39 hoặc có mong muốn cháy bỏng là đưa các tính năng ngôn ngữ không ổn định vào mã sản xuất của mình, nếu không thì có thể bạn sẽ ổn với ES6. Ngày nay, chúng ta có một ngôn ngữ tốt chiếm phần lớn các trình duyệt và nhu cầu dịch mã đang giảm dần.
- Bạn đang sử dụng TypeScript và hy vọng đã cân nhắc những nhược điểm và ưu điểm. Trình biên dịch TypeScript, khi nhắm mục tiêu phiên bản ES6 hiện đại, chủ yếu loại bỏ thông tin loại thay vì chuyển đổi cú pháp.
- Bạn muốn giảm kích thước mã bằng cách sử dụng tính năng lắc cây (đây là cách thực hiện trong webpack và rollup). Bạn muốn làm xáo trộn mã của mình hoặc giảm kích thước của mã bằng cách thu nhỏ. Bạn muốn loại trừ có điều kiện một phần mã. Điều này yêu cầu phân tích mã tĩnh. Bạn có thể sử dụng gói thông minh cho các dịch vụ sản xuất có kích thước nhạy cảm như Thiết bị di động, nhưng chúng ta sẽ thấy các đánh giá chi phí cẩn thận hơn khi tạo các triển khai thay thế như vậy. Các loại phân tích mã tĩnh này sẽ tiếp tục hữu ích như “kỹ thuật tối ưu hóa nâng cao” cho mã sản xuất. bạn không phải thu nhỏ các tập tin của bạn. UglifyJS không thể thu nhỏ ES6 vào lúc này (mặc dù có một nhánh harmoney tồn tại) nhưng Babili có thể giải quyết vấn đề đó. Các thuật toán nén thực hiện công việc khá tốt (không phải khi các tệp quá ít) và trừ khi bạn vận chuyển một hệ điều hành trong mỗi lần tải trang, nó sẽ hoạt động tốt mà không cần nén. Ngày nay, hình ảnh và nội dung đa phương tiện chiếm nhiều băng thông hơn mã.
- Bạn muốn con voi trong phòng:
NPM là trình quản lý gói lớn nhất trên hành tinh. Hầu hết các ứng dụng web không tầm thường sử dụng một số mã từ NPM và điều đó có nghĩa là sử dụng gói mô-đun. Điều đó sẽ sớm thay đổi! Chrome đã hỗ trợ các mô-đun ES6 trong Canary (Chrome 60 sẽ chính thức cung cấp tính năng này vào tháng 8 này) và Safari cũng sắp cung cấp tính năng này trong khi Firefox và Edge đang phát triển tính năng này.
Bên cạnh đó HTTP/2 cho phép đẩy tài nguyên lên trình duyệt một cách tự nguyện. Điều đó có nghĩa là nếu a.js đang nhập khẩu b.js và c.jsmáy chủ có thể đẩy b.js và c.js mỗi lần a.js được tìm nạp giúp giảm thiểu thời gian giữa các yêu cầu. Tất nhiên đây là một cái nhìn đơn giản vì trong thực tế, trình duyệt có thể đã có b.js và c.js trong bộ đệm của nó. HTTP/2 được hỗ trợ trong phần lớn các trình duyệt.
Tương lai không có dịch thuật
Xem xét các số liệu thống kê ở trên, điều này có nghĩa là năm 2018 sẽ là năm mà phần lớn các ứng dụng web có thể loại bỏ các gói hoặc bộ chuyển đổi mô-đun.
Biên dịch là một cách giải quyết. Có thể chúng ta đã làm điều đó quá lâu nên đã quen với nó, nhưng hãy nghĩ về điều đó. Chúng tôi đang “biên dịch” một ngôn ngữ “được giải thích” thành một ngôn ngữ “được giải thích”! Ngoài ra:
- Định cấu hình Webpack/Browserify là một loại thuế không cần thiết trong nhiều trường hợp
- Gỡ lỗi bằng bản đồ nguồn luôn khó hơn gỡ lỗi tập lệnh thực tế đang được chạy (bất kỳ ai cũng vui vẻ khi thử gỡ lỗi
thishoặc các biến khi bản đồ nguồn không hoạt động bình thường?) - Nó giết chết DX khi bạn phải đợi vài giây (đôi khi nửa phút) sau mỗi lần chỉnh sửa để xem mã mới nhất. Tải lại mô-đun nóng (HMR) là một câu trả lời cho vấn đề đó nhưng không phải lúc nào việc cấu hình cũng diễn ra suôn sẻ và nhanh chóng. Không cần dịch mã, tất cả những gì bạn phải làm là làm mới trang và trong vòng chưa đầy một giây, trang mới nhất của bạn sẽ ở đó!
Tháng 8 này khi các mô-đun ES6 được xuất xưởng, một số loại ứng dụng sẽ hoàn toàn không sử dụng tính năng dịch mã:
- Tiện ích mở rộng của Chrome
- Ứng dụng máy tính để bàn điện tử
- Các ứng dụng web B2B được tạo ra để điều hành bởi người dùng doanh nghiệp đã có các công cụ tốt do công ty cung cấp
Khi việc dịch mã trở thành dĩ vãng, các thư viện với cú pháp Hyperscript sẽ đưa các ý tưởng của React vào POJS (JavaScript cũ đơn giản không được dịch mã và dễ dàng sửa lỗi trên bảng điều khiển).
Đừng dịch mã, mà hãy biên dịch thực sự!
WASM là đứa trẻ mới trong thị trấn và nó là mục tiêu biên dịch chính thức hứa hẹn tốc độ thực thi nhanh hơn và kích thước mã nhỏ hơn. Hiện tại Chrome và Firefox hỗ trợ WASM nhưng có sự đồng thuận tốt giữa các nhà cung cấp trình duyệt lớn rằng WASM sẽ là thời gian chạy phổ biến trong tương lai. Nếu bạn có Chrome, bạn có thể dùng thử.
Nếu bạn là kiểu nhà phát triển khao khát điều gì đó mới mẻ, hãy xem Rust. Nó biên dịch thành WASM nhưng không giới hạn ở web. Mọi người thực sự sử dụng nó để viết hệ điều hành hoặc công cụ trình duyệt. Bên cạnh đó, các nhà phát triển C/C++ thời xưa chấp thuận và thích nó và nó có một cộng đồng rất thân thiện.
Một vài lưu ý
- Theo cựu CTO của Mozilla, Chrome đã thắng và không có khả năng xảy ra một cuộc chiến trình duyệt nào khác. Điều thú vị là Chrome đã giành được nó nhờ chế độ nhân tài. Đó là nguồn mở và Google đã xác định rõ ràng thông tin nào sẽ được thu thập từ người dùng. Chrome giành được ngay cả những người dùng doanh nghiệp thường sử dụng Windows. Tuy nhiên, trong khi người dùng cuối chọn Chrome vì tốc độ, tính bảo mật và tính đơn giản, thì các lập trình viên lại yêu thích các công cụ dành cho nhà phát triển của Chrome. Google có vai trò tích cực trong TC39, thúc đẩy tương lai của JavaScript và nói chung là người ủng hộ mạnh mẽ nhất nền tảng web mặc dù nền tảng này có thể cạnh tranh với hệ điều hành di động của riêng mình. Không chỉ vậy, Google còn giúp đỡ các đối thủ cạnh tranh của mình. Google là một trong những nhà hỗ trợ tài chính lớn nhất của Mozilla và công cụ kết xuất của nó được sử dụng bởi Opera.
- Microsoft đã chính thức ngừng hỗ trợ cho IE khoảng 17 tháng trước. IE 11 sẽ tiếp tục nhận được các bản cập nhật bảo mật cho đến năm 2025, nhưng bạn có quyết định chi nhiều tài nguyên đáng kể để hỗ trợ trình duyệt mà chỉ 3,24% thị trường sử dụng hay không là tùy thuộc vào bạn. Ngoài ra, hãy nhớ rằng Edge là trình duyệt mặc định trong Windows 10. Nếu bất kỳ ai không muốn nâng cấp Windows của mình lên phiên bản mới nhất, cuộc tấn công WannaCrypt gần đây có thể khiến họ có lý do để xem xét lại! Cá nhân tôi quan tâm đến bất kỳ nghiên cứu thị trường nào về doanh thu đến từ phân khúc khách hàng cụ thể này.
- Apple đưa ra một loạt các hạn chế không công bằng để ngăn các nhà cung cấp trình duyệt khác sử dụng nền tảng iOS của họ. Vì vậy, ví dụ Chrome trên iOS bị giới hạn về mặt kỹ thuật đối với các phần của công cụ Safari! Safari từng là IE mới, cho đến năm 2016 họ đã làm rất tốt và trở thành trình duyệt hỗ trợ ES6 tốt nhất:
Nhìn chung, thị phần toàn cầu của iOS/Safari ít hơn Android/Chrome. Nó thay đổi theo quốc gia, ví dụ ở các quốc gia giàu có hơn, iOS có tỷ lệ thâm nhập cao hơn một chút trong khi ở các nước đang phát triển, Android là người chiến thắng tuyệt đối nhưng trên toàn cầu, đây là số liệu thống kê:
Kêu gọi hành động!
Nếu bạn đủ lớn, có thể bạn sẽ nhớ những ngày khó chịu khi một số trang web buộc (hoặc gợi ý một cách lịch sự) trình duyệt họ chọn (chủ yếu là IE):
Chúng tôi không muốn làm điều đó! Cho dù chúng tôi hào hứng thế nào về Chrome, chúng tôi không muốn bỏ qua 46% lưu lượng truy cập web không được Chrome hiển thị.
Chỉ vì chúng tôi có thể sớm hỗ trợ các mô-đun ES6 trong trình duyệt, điều đó không có nghĩa là chúng tôi có thể loại bỏ quy trình xây dựng và một “chiến lược gói” phù hợp. — Stefan Judis
Chúng tôi sẽ luôn có những người mắc kẹt với một trình duyệt cũ trong chương trình cơ sở TV hoặc hệ thống thông tin giải trí trên ô tô của họ. Chúng ta sẽ luôn có ông nội bướng bỉnh không thấy cần phải đầu tư nâng cấp chiếc máy của mình chỉ để lại nó như một di sản. Trẻ em sẽ tiếp tục sử dụng iPhone hoặc máy tính bảng cũ của cha mẹ và 1 máy tính xách tay cho mỗi đứa trẻ sẽ không phát triển sức mạnh xử lý qua đêm. Chúng tôi không muốn khóa bất cứ ai.
Đây không phải là một vấn đề mới mặc dù. Mặc dù ES6 là một trong những thay đổi lớn nhất trên web, sự xuống cấp nhanh chóng vẫn có thể cung cấp một số công dụng cho thiểu số trong khi vẫn giữ chi phí phát triển trong tầm kiểm soát cho đa số.
Trong một bài đăng trong tương lai, tôi sẽ thảo luận về khía cạnh thực tế của cách vận chuyển mã hiện đại trong khi có kế hoạch dự phòng cho sự xuống cấp nhẹ nhàng. Bạn có thể theo dõi tôi trên Twitter hoặc Medium để theo dõi.
THƯỞNG: Hãy xem JS Codeshift. Nó là một CLI để chuyển đổi mã javascript cũ thành mã javascript mới cập nhật ngay cả các lệnh gọi thư viện javascript cũ sang API mới nhất của họ. Nó cố gắng bảo tồn càng nhiều kiểu dáng ban đầu càng tốt. Quy trình làm việc: sau khi thực hiện các thay đổi của bạn đối với kiểm soát phiên bản, hãy chạy quy trình này và thực hiện so sánh kỹ lưỡng cũng như chạy thử nghiệm tự động & thủ công. Xong!
Cập nhật 1 (2017–09–8): Chrome 61 đã cập bến vài ngày trước với hỗ trợ mô-đun ES6 đầy đủ. Nó có 54% thị trường trình duyệt toàn cầu. Safari (14% thị trường toàn cầu) đã hỗ trợ các mô-đun ES6 được một thời gian.
Cập nhật 2 (2017–09–10): bạn vẫn có thể hỗ trợ các trình duyệt không hỗ trợ mô-đun ES6 nhờ thủ thuật này
Cập nhật 3 (2017–09–12): Các mô-đun ES6 hỗ trợ các vùng đất trong trình duyệt: đã đến lúc suy nghĩ lại về gói?
Cập nhật 4 (2017–09–12): mô-đun là hoãn lạimàu đỏ theo mặc định. Nếu bạn muốn bỏ qua điều đó, hãy thêm một không đồng bộ thuộc tính cho thẻ tập lệnh để ngăn một điểm lỗi (SPOF).
Cập nhật 5 (2017–09–13): Nút LTS 8.5 hỗ trợ Mô-đun ES6 (được gọi là ESM) phía sau cờ khi tệp có *.msj gia hạn. Đây là một đoạn giới thiệu hay về cách chúng được sử dụng.
Cập nhật 6 (2017-09–22): đây là một số lời khuyên thiết thực tuyệt vời để hỗ trợ cả trình duyệt mới và cũ. Việc tiết kiệm băng thông để tránh chuyển mã là rất tốt!
Cập nhật 7 (2018–01–15): Lebab (ngược lại với Babel) có CLI để hiện đại hóa Javascript kiểu cũ. Điều này hơi giống với CodeShift của Facebook vì cả hai đều hiện đại hóa mã cũ.
Lỗi được triển khai rộng rãi nhất trong lịch sử máy tính đã mở ra một cơ hội tuyệt vời cho chúng tôi! Đọc Tại sao chúng ta nên thuyết phục người dùng cập nhật trình duyệt của họ?
