|
|
| Ảnh minh họa |
Tại sao họ phải làm như vậy? Bài phân tích dưới đây của trang HowToGeek sẽ giúp chúng ta hiểu rõ hơn nguyên nhân của sự việc này.
Các phần mở rộng truyền thống hoạt động như thế nào?
Các phần mở rộng (extention) truyền thống thường được viết bằng ngôn ngữ XML User Interface Language (XUL) - chính là ngôn ngữ lập trình mà Mozilla sử dụng để tạo nên giao diện của Firefox cũ. Do đó, các phần mở rộng truyền thống dựa trên XUL nêu trên có khả năng thay đổi giao diện của trình duyệt một cách trực tiếp, có quyền truy cập gần như tuyệt đối tới XPCOM - thành phần COM được sử dụng trên Firefox.
Nói một cách dễ hiểu, các phần mở rộng truyền thống sẽ có khả năng thay đổi hoàn toàn trình duyệt của bạn, và các thay đổi này được thực hiện một cách trực tiếp. Chính đặc điểm này khiến chúng vô cùng mạnh mẽ: không có một giới hạn cụ thể nào về những thứ mà phần mở rộng có thể hoặc không thể thực hiện. Tuy nhiên đây cũng là nguyên nhân khiến chúng đôi khi không tương thích sau mỗi lần nâng cấp Firefox.
Các phần mở rộng trên Chrome hay Safari thì lại khác. Hai trình duyệt này chỉ cho phép các lập trình viên sử dụng một số hàm API cụ thể, tức là chúng quy định rõ ràng phần mở rộng có thể và không thể làm gì. Trong hai năm trở lại đây, Firefox cũng đã tung ra một cơ chế tương tự gọi là WebExtensions, và khuyến khích các nhà phát triển chuyển sang sử dụng cơ chế này.
Các phần mở rộng truyền thống khiến việc nâng cấp Firefox gặp khó khăn
Như đã nói ở trên, Firefox Quantum mới ra mắt không phải là phiên bản Firefox đầu tiên gây ra lỗi không tương thích ở phần mở rộng; lỗi này đã là một vấn đề thường trực trên Firefox từ rất lâu rồi.
Bởi các phần mở rộng của Firefox có khả năng tác động trực tiếp lên trình duyệt, nên thậm chí chỉ những thay đổi rất nhỏ của Firefox cũng sẽ khiến chúng "tê liệt" hoàn toàn, hoặc gây ra những lỗi làm ảnh hưởng hiệu suất trình duyệt. Tất nhiên, người dùng thông thường không nghĩ rằng đây là lỗi của phần mở rộng, họ khẳng định "chắc như đinh đóng cột" rằng bản Firefox mới cập nhật bị lỗi, và ở khía cạnh của người dùng thì họ lúc nào cũng đúng. Nhóm phát triển Firefox đã luôn phải cố gắng kiểm tra để đảm bảo các phần mở rộng phổ biến hoạt động tốt mỗi lần định tung ra một bản Firefox mới, và việc này vô tình khiến quá trình phát triển chậm đi đáng kể.
Các hàm API WebExtensions giúp mọi việc "dễ thở" hơn bằng cách giới hạn những điều mà phần mở rộng có thể làm và làm như thế nào. Điều này có nghĩa là các lập trình viên Firefox chỉ cần quan tâm đến việc hàm API có hoạt động tốt hay không mà không phải lo về việc những thay đổi liên quan hiệu suất và giao diện có thể làm "tê liệt" một phần mở rộng nào đó. Nhờ vậy ngày càng có ít phần mở rộng bị dính lỗi không tương thích hơn, nhưng cũng đồng nghĩa với việc Mozilla phải "chia tay" với hệ sinh thái phần mở rộng trước đây.
Những thay đổi này còn giúp Mozilla có thể mang lại những tính năng tốt nhất trên Firefox Quantum. Ví dụ khả năng chạy đa luồng vốn đóng một vai trò quan trọng trong sự tăng tốc "thần sầu" của Firefox Quantum. 4 tiến trình riêng biệt sẽ đảm nhiệm việc xử lý giao diện và các tab trên trình duyệt, tức là Firefox có thể sử dụng cả 4 lõi của chip xử lý thay vì chỉ 1. Các phần mở rộng truyền thống không hỗ trợ tính năng này, và chúng sẽ không hoạt động trừ khi được thêm vào hàng tá dòng lệnh mới có khả năng sẽ làm mọi thứ chậm lại.
Từ trước đến nay, Firefox luôn bị chê bai là chậm giới thiệu các tính năng mới, nguyên nhân là vì trình duyệt này bị các phần mở rộng truyền thống "níu chân". Muốn Firefox tiến hoá, hệ sinh thái cũ phải thay đổi trước.
Vấn đề tương thích đa nền tảng
Trước đây, phần mở rộng chính là yếu tố then chốt khiến người dùng chọn Firefox thay vì Chrome. Ngày nay, Chrome đã trở thành kẻ đi đầu về mảng phần mở rộng, còn Firefox giống như một nghĩa địa của các phần mở rộng đã bị quên lãng.
Tất nhiên một số phần mở rộng của Firefox không thể được mang sang Chrome, nhưng rõ ràng Chrome có một hệ sinh thái lớn hơn nhiều. Với việc chuyển sang sử dụng API WebExtensions, các lập trình viên có thể dễ dàng mang kho phần mở rộng khổng lồ từ Chrome...sang Firefox, dù sẽ mất một chút thời gian. Đối với hầu hết các trường hợp thì một phần mở rộng của Chrome sẽ có thể chạy trên Firefox mà chỉ cần một vài chỉnh sửa nho nhỏ, tức là nếu người dùng đề xuất, các lập trình viên chẳng có lý do gì để từ chối việc mang phần mở rộng họ viết cho Chrome sang Firefox cả. Nhờ đó, Firefox sẽ sớm được hưởng lợi với hàng tá phần mở rộng mới gia nhập hệ sinh thái của họ.
Firefox đã và đang mất dần người dùng
Một số người sẽ nói rằng Firefox Quantum "chia tay" với các phần mở rộng truyền thống sẽ khiến người dùng chuyển nhà sang các trình duyệt khác, nhưng sự thực là từ nhiều năm qua, Firefox đã mất đi một lượng đáng kể người dùng về tay đối thủ Chrome. Firefox Quantum được cho là sẽ giải quyết các vấn đề liên quan đến tốc độ và sự thiếu vắng phần mở rộng, kéo người dùng quay lại với mình.
Liệu việc Mozilla làm đối với Firefox Quantum có vô tình phản tác dụng không? Có thể. Một số người dùng sẽ tiếp tục chuyển sang Chrome, một số khác sẽ chuyển sang các trình duyệt "rẽ nhánh" từ Firefox cũ, vốn vẫn hỗ trợ phần mở rộng truyền thống. Firefox sẽ phải tiến hoá để đứng vững, và Mozilla đã quyết định đi đến cùng với những thay đổi này.
Các lập trình viên sẽ cần thời gian để chuyển qua hàm API mới
Có thể người dùng không để ý, nhưng một số phần mở rộng đã chuyển sang sử dụng hàm API WebExtensions từ lâu.
Đối với các phần mở rộng chưa chuyển, nhiều khả năng chúng đã bị các lập trình viên "bỏ quên" từ trước, hoặc đơn giản là không muốn viết lại chúng để dùng hàm API mới. Một lý do khác có thể là họ phát hiện ra hàm API này không cung cấp đủ khả năng để tái tạo lại các phần mở rộng truyền thống nên đã quyết định huỷ dự án. Hoặc nếu lạc quan, bạn có thể nghĩ rằng các lập trình viên chưa kịp chuyển đổi chúng mà thôi.
Được biết, Mozilla đã thông báo về API WebExtensions từ hai năm trước, và cũng đã thông báo về việc sẽ ngừng hỗ trợ phần mở rộng truyền thống từ 1 năm trước.