Những điều mọi người hiểu sai về Electron
(felixrieseberg.com)- Tác giả Felix Rieseberg là đồng bảo trì viên đã tham gia phát triển Electron hơn 10 năm
- Electron cho phép xây dựng UI bằng công nghệ web và, nếu cần, có thể tự do kết hợp với mã native
- Nhiều ứng dụng (Visual Studio Code, Slack, Discord, Figma, ChatGPT, Claude, Notion, 1Password, Docker Desktop, v.v.) đang sử dụng Electron
- Tài liệu này chỉ ra những hiểu lầm chính về Electron và giải thích vì sao những lựa chọn đó được đưa ra
Electron đặt JavaScript và mã native vào thế đối lập
- Thường có ý kiến cho rằng “Electron chỉ dùng JavaScript nên kém hơn native”
- Thực tế, Electron cho phép dùng song song mã native như C++, Objective-C, Rust bên cạnh JavaScript
- Ví dụ, 1Password viết phần lớn mã bằng Rust và dùng Electron cho phần UI
- Điểm mạnh của Electron là tính linh hoạt: có thể trộn mã native ở mức cần thiết và tận dụng công nghệ web cho phần UI
- Cũng đã có các ví dụ demo cung cấp UI native một phần bằng SwiftUI, GTK, Win32, v.v.
Ứng dụng web là tệ
- Có quan điểm cho rằng “mọi ứng dụng native luôn tốt hơn”, nhưng thực tế thị trường không đơn giản như vậy
- NASA Mission Control, Bloomberg Terminal, kiosk của McDonald’s, SpaceX Dragon 2, v.v. cũng sử dụng công nghệ web dựa trên Chromium
- Công nghệ web hiện là công nghệ được sử dụng rộng rãi nhất trên toàn cầu, và một ứng dụng web được làm tốt có thể mang lại trải nghiệm người dùng xuất sắc
- Khẳng định rằng “ứng dụng web là thứ do người kém năng lực tạo ra” là một sự đơn giản hóa, bỏ qua yêu cầu của môi trường sử dụng và bối cảnh lựa chọn của nhà phát triển
WebView của hệ điều hành có hiệu năng tốt hơn
- Có người cho rằng WebView tích hợp sẵn trên macOS, Windows hoặc Linux thường tốt hơn
- Thực tế, Slack ban đầu dùng MacGap (dựa trên WebView), nhưng cuối cùng đã chuyển sang Electron (Chromium) vì vấn đề hiệu năng
- Engine Chromium mới nhất tuy tiêu tốn nhiều tài nguyên hơn, nhưng cũng là phần được tối ưu hóa tích cực nhất
- WebView tích hợp sẵn trong hệ điều hành đôi khi có thể cho thấy mức dùng bộ nhớ nhỏ hơn nhờ tài nguyên dùng chung, nhưng trên thực tế chúng thường bị cô lập vì lý do bảo mật và ổn định
- Với Electron, có thể trực tiếp quản lý phiên bản engine mới nhất, từ đó duy trì tính ổn định và bảo mật một cách độc lập
Kích thước gói cài đặt là quan trọng
- Thông thường, ứng dụng Electron có dung lượng khoảng 100~300MB, và đây là điểm thường bị chỉ trích
- Nhưng người dùng thường có xu hướng ưu tiên các yếu tố khác như tính năng, sự tiện lợi, độ ổn định hơn là dung lượng ứng dụng
- Ví dụ, xem Netflix chất lượng 4K có thể tiêu tốn vài GB mỗi giờ, còn một bản cập nhật Call of Duty đôi khi lên tới hàng trăm GB
- Cuối cùng, so với mức độ hài lòng thực tế của người dùng, kích thước ứng dụng trong nhiều trường hợp lại là yếu tố ít quan trọng hơn tương đối
Đánh bại Electron
- Electron khởi đầu từ nỗ lực mã nguồn mở của những người có mục tiêu “hãy cùng tạo ra các ứng dụng desktop tốt”
- Electron bắt đầu trong bối cảnh ít đối thủ cạnh tranh, và đến nay vẫn cung cấp đầy đủ tính năng cùng độ ổn định
- Muốn “đánh bại” Electron thì cần tạo ra một nền tảng có thể làm những gì Electron đang làm một cách tốt hơn
- Những người bảo trì Electron sẽ sẵn sàng chào đón một lựa chọn thay thế tốt hơn nếu nó xuất hiện
15 bình luận
Việc so sánh với Call of Duty có vẻ hơi lạc đề.
Cần xem xét Teams đã bỏ Electron và chuyển sang WebView,
https://techcommunity.microsoft.com/discussions/microsoftteams/…
Mong là Tauri sớm trưởng thành hơn. Dù vậy, tôi đã dùng nó khá ổn rồi.
Cứ ngỡ thời còn là Atom Shell mới như hôm qua... giờ đã phát triển rất nhiều rồi.
Dù có nhiều điểm bị chỉ trích, nhưng nhìn vào độ hoàn thiện của ứng dụng vscode mà chúng ta dùng hằng ngày thì chắc chắn phải thừa nhận công lao của Electron là không hề nhỏ.
Tôi cài gần 10 ứng dụng Electron trên PC rồi, đến mức này thì có cảm giác nó nên trở thành một framework được cài riêng biệt thì hơn.
Kích thước bundle đã vậy rồi, nhìn mấy tiến trình
~~ Helperngốn bộ nhớ mà chỉ biết thở dài.Tôi cũng đang nghĩ đến
taurinhư một phương án thay thế, nhưng lo rằng khi phát hành sẽ có những trường hợp lạ khiến nó không hoạt động bình thường. (Trước đây tôi từng rất vất vả khi phát hành một chương trình trong môi trường win32 có tham chiếu đến các DLL được đăng ký sẵn mặc định nhưmsxml.dll; cuối cùng phải nhúng kèm để phát hành... nên tôi lo không biết có phát sinh vấn đề tương tự hay không)Đúng như phía Electron nói, có lẽ cứ quên chuyện kích thước đi là hợp lý, nhưng kích thước gói bundle thực sự quá lớn.
Có vẻ vấn đề là ở chỗ đó với tauri..
Vì WebView theo từng nền tảng và chương trình được nhúng bên trong đều khác nhau, nên đó đúng là vấn đề lớn nhất. Sau khi phát hành rồi thì không biết chuyện gì sẽ xảy ra.
Nhưng nếu nhúng luôn chính WebView vào tauri thì kích thước bundle lại còn lớn hơn Electron..
Vì vậy, khi phát triển ứng dụng production đa nền tảng, tôi nghĩ tauri vẫn chưa đủ chín muồi.
Ki-ốt của McDonald’s thì... ừm....không biết có phải là một ví dụ hay hay không
Tôi cũng chợt nghĩ y như vậy. Ki-ốt McDonald's ở nước ngoài dù sao cũng hơi khác chăng? Thoáng chốc tôi đã tự hỏi như vậy haha
Haha, tôi cũng nghĩ y hệt như vậy.
Có vẻ như việc giảm mức sử dụng bộ nhớ sẽ là thách thức lớn nhất, nhưng thật đáng tiếc là dường như không có bên liên quan nào có đủ động lực để thực hiện điều đó.
Trong bài có gắn liên kết tới mã demo thực tế, nên tôi vào xem thử thì cảm giác không phải là kiểu dễ đến mức có thể dùng chung một cách rất đơn giản. Có lẽ trước hết nên xem đó như là mức "có thể làm được".
Có vẻ đúng là nhìn chung ứng dụng khá nặng..
Đúng vậy, kích thước bundle thì đành phải thừa nhận thôi.