Dành đủ thời gian trên Hacker News hoặc Reddit, rồi bạn cũng sẽ thấy cùng một lời chỉ trích: Electron cồng kềnh, Electron dùng quá nhiều bộ nhớ, và các ứng dụng desktop nghiêm túc nên được phát triển theo hướng native.
Lời chỉ trích đó có phần đúng. Các ứng dụng Electron thường tiêu tốn nhiều tài nguyên hơn ngay từ mức cơ bản vì chúng đóng gói kèm Chromium và Node.js. Một ứng dụng native được xây dựng kỹ lưỡng có thể dùng ít bộ nhớ hơn, khởi động nhanh hơn và tích hợp sâu hơn với hệ điều hành.
Nhưng cuộc tranh luận này tập trung quá nhiều vào máy tính mà chưa đủ vào công ty xây dựng phần mềm.
Với phần lớn người dùng, công nghệ đứng sau một ứng dụng hầu như không quan trọng. Họ quan tâm đến việc ứng dụng có hoạt động hay không, có phản hồi nhanh hay không, lỗi có được sửa hay không và các tính năng hữu ích có tiếp tục xuất hiện hay không. Vì vậy, đối với một công ty phần mềm, một trong những đặc tính quan trọng nhất của bộ công nghệ lại là điều hiếm khi xuất hiện trong các bảng đo hiệu năng: đội ngũ có thể xây dựng, phát hành, học hỏi và cải thiện sản phẩm nhanh đến mức nào?
Với nhiều ứng dụng desktop hiện đại, Electron làm điều đó đặc biệt tốt.
Nguồn lực khan hiếm là thời gian của kỹ sư
Một công ty phát triển ứng dụng desktop native trong hình dung lý tưởng sẽ có một đội ngũ macOS xuất sắc, một đội ngũ khác xây dựng ứng dụng Windows, và có lẽ thêm một đội ngũ hỗ trợ Linux. Mỗi ứng dụng đều được tối ưu kỹ lưỡng cho nền tảng của mình, và mỗi kỹ sư đều hiểu sâu về hệ điều hành mà họ làm việc cùng.
Phần lớn công ty không có điều kiện như vậy.
Một sản phẩm desktop có thể chỉ có năm kỹ sư. Cũng có thể chỉ có hai. Chính những kỹ sư đó phải xây dựng tính năng, sửa lỗi, cải thiện hiệu năng, phản hồi khách hàng, duy trì hạ tầng, xử lý những thay đổi của hệ điều hành và tiếp tục đưa sản phẩm tiến lên.
Phát triển native khiến việc này khó hơn vì macOS, Windows và Linux thực sự là những nền tảng khác nhau. Chúng có các framework giao diện, API, hệ thống cấp quyền, cách vận hành vòng đời ứng dụng, trình cài đặt, cơ chế cập nhật, hệ thống thông báo, cơ chế quản lý cửa sổ, API hỗ trợ tiếp cận khác nhau, cùng vô số đặc thù riêng của từng nền tảng tích lũy qua nhiều năm.
Electron thay đổi bài toán đó. Nó kết hợp Chromium, Node.js và các API desktop thành một mô hình ứng dụng chung trên macOS, Windows và Linux. Cùng một kỹ sư TypeScript thường có thể xây dựng một tính năng từ giao diện đến logic ứng dụng rồi phát hành trên mọi nền tảng desktop. Mã native vẫn có thể được sử dụng khi thực sự cần, nhưng trở thành ngoại lệ thay vì nền tảng của sản phẩm. Chính Electron cũng mô tả đây là một trong những lợi thế cốt lõi của mình: một cơ sở mã JavaScript dùng chung cho cả ba nền tảng desktop lớn.
Sự khác biệt đó tích lũy qua nhiều năm. Nếu mỗi tính năng đáng kể đều cần những bản triển khai riêng cho Mac và Windows, công ty phải trả khoản chi phí bổ sung do khác biệt nền tảng hết lần này đến lần khác: với mọi tính năng, lần thiết kế lại, thử nghiệm, bản sửa lỗi, cải tiến khả năng tiếp cận và tối ưu hiệu năng.
Với Electron, phần lớn công việc đó chỉ cần làm một lần.
Electron tối ưu cho tốc độ cải tiến qua từng vòng lặp
Sản phẩm hiếm khi trở nên xuất sắc vì bản triển khai đầu tiên đã hoàn hảo. Chúng trở nên xuất sắc nhờ liên tục cải tiến.
Đội ngũ phát hành một thứ gì đó. Khách hàng sử dụng nó. Đội ngũ rút ra bài học. Họ thay đổi tính năng. Nhiều người sử dụng hơn. Một vấn đề khác lộ ra. Đội ngũ lại cải thiện nó.
Vòng lặp từ ý tưởng, triển khai, phản hồi đến cải tiến càng ngắn, sản phẩm càng tiến bộ nhanh.
Electron đặc biệt giỏi trong việc rút ngắn vòng lặp đó vì nó được xây dựng quanh những công nghệ mà các công ty phần mềm vốn đã sử dụng ở khắp nơi: JavaScript, TypeScript, HTML, CSS, React, Chromium, Node.js và npm.
Điều đó có nghĩa là các công ty có thể dùng chung nhiều thứ hơn hẳn chỉ mã nguồn. Họ có thể chia sẻ kỹ sư, thành phần giao diện, công cụ, thư viện, hạ tầng, phương pháp kiểm thử và kiến thức tích lũy trong tổ chức giữa sản phẩm web và desktop.
Một kỹ sư frontend không đột nhiên trở nên không phù hợp chỉ vì công ty cần hỗ trợ cho ứng dụng Windows. Một kỹ sư desktop có thể đóng góp cho ứng dụng web. Một kỹ sư full-stack TypeScript có thể chuyển giữa các sản phẩm khi thứ tự ưu tiên thay đổi.
Với một công ty nhỏ hoặc vừa, sự linh hoạt đó có thể đáng giá hơn rất nhiều so với việc tiết kiệm 100 MB RAM.
Hãy nhìn vào những ai thực sự đang sử dụng Electron
Electron đôi khi được mô tả là một lối tắt dành cho những công ty không muốn đầu tư vào một ứng dụng desktop “đúng nghĩa”. Những sản phẩm được xây dựng bằng nó khiến lập luận đó ngày càng khó đứng vững.
Dự án Electron giới thiệu những sản phẩm như Slack, Discord, Signal, ChatGPT, Claude, Visual Studio Code, Notion, Docker, Loom và Canva. Đây không phải những tiện ích đơn giản. Nhiều sản phẩm trong số đó thuộc nhóm ứng dụng hỗ trợ công việc tinh vi nhất và được sử dụng rộng rãi nhất trên thế giới.
Visual Studio Code là một ví dụ đặc biệt hữu ích. Microsoft có thể xây dựng trình soạn thảo mã chủ lực của mình bằng gần như bất kỳ công nghệ Windows nào họ muốn, nhưng VS Code lại dùng Electron trên Windows, macOS và Linux. Nó bao gồm terminal, chức năng gỡ lỗi, máy chủ ngôn ngữ, tích hợp Git, phát triển từ xa, notebook, tiện ích mở rộng và các trình soạn thảo được tùy biến sâu.
Câu hỏi đáng chú ý không phải là liệu Microsoft có thể tiết kiệm bộ nhớ bằng cách xây dựng ba phiên bản native riêng biệt hay không. Tất nhiên là có.
Câu hỏi hay hơn là liệu VS Code có thể phát triển nhanh như vậy, duy trì tính nhất quán giữa các nền tảng như vậy và xây dựng được một hệ sinh thái lớn đến thế nếu mỗi khả năng quan trọng đều đòi hỏi nhiều bản triển khai riêng biệt hay không.
ChatGPT và Claude cho thấy sự khác biệt trong cách tiếp cận
Sự tương phản giữa ChatGPT và Claude cũng rất đáng để học hỏi.
Ban đầu, OpenAI xây dựng một ứng dụng native riêng cho ChatGPT trên macOS. Ngược lại, Anthropic xây dựng Claude Desktop bằng Electron và ngay từ đầu đã có một nền tảng desktop chung cho nhiều hệ điều hành.
Sự khác biệt đó trở nên quan trọng hơn khi các sản phẩm mở rộng. Claude Desktop có thể tiếp tục bổ sung những khả năng như tích hợp MCP, tiện ích mở rộng và Claude Code vào cùng một ứng dụng đa nền tảng. Hiện Anthropic hỗ trợ Claude Code trực tiếp trong trải nghiệm desktop của mình, bao gồm nhiều phiên làm việc cục bộ và từ xa.
Sau đó, OpenAI cũng chuyển định hướng phát triển ứng dụng desktop đa nền tảng mới hơn sang Electron, và hiện Electron liệt kê cả ChatGPT lẫn Claude trong số những ứng dụng Electron nổi bật.
Sẽ là quá lời nếu khẳng định rằng chỉ riêng Electron giải thích được sự khác biệt về tốc độ phát triển sản phẩm. Quy mô đội ngũ, các ưu tiên, chiến lược sản phẩm và cách tổ chức nội bộ đều có vai trò. Nhưng lợi thế về kiến trúc rất rõ ràng: một nền tảng đa hệ điều hành dùng chung giúp việc phát hành tính năng trên nhiều hệ điều hành dễ dàng hơn mà không phải duy trì các bản triển khai riêng biệt.
Đó chính là kiểu lợi thế càng trở nên có giá trị khi một sản phẩm desktop phát triển.
Evernote đã thấm thía chi phí duy trì các ứng dụng riêng biệt
Evernote là một trong những ví dụ rõ ràng nhất trong lịch sử về vấn đề này.
Trong nhiều năm, Evernote duy trì các ứng dụng khác nhau trên Mac, Windows, thiết bị di động và web. Theo thời gian, những sản phẩm đó tích lũy các khác biệt về hành vi, cách hiển thị, những giả định từ thiết kế cũ và các vấn đề đồng bộ hóa.
Năm 2020, Evernote xây dựng lại các ứng dụng Windows và Mac trên một cơ sở mã dùng chung. Công ty cho biết nền tảng mới sẽ giúp các ứng dụng ổn định hơn, cho phép sửa lỗi nhanh hơn, phát hành tính năng thường xuyên hơn và cải thiện việc đồng bộ hóa giữa các nền tảng.
Quá trình chuyển đổi đó không hề suôn sẻ, và một số người dùng lâu năm không hài lòng khi ban đầu mất đi các tính năng đặc thù của từng nền tảng. Nhưng lý do Evernote thực hiện một cuộc viết lại tốn kém như vậy còn đáng chú ý hơn chính những vấn đề trong quá trình chuyển đổi.
Khi một sản phẩm đã có trình soạn thảo phong phú, lưu trữ ngoại tuyến, tìm kiếm, tệp đính kèm, cộng tác, tác vụ, lịch và cơ chế đồng bộ phức tạp, việc duy trì nhiều bản triển khai độc lập ngày càng tốn kém. Lỗi biểu hiện khác nhau. Cách hiển thị khác nhau. Logic đồng bộ tương tác với các kiến trúc cục bộ khác nhau. Mọi thay đổi đáng kể của sản phẩm đều phải được đưa vào nhiều ứng dụng.
Kiến trúc dùng chung không làm những vấn đề khó biến mất. Nó cho phép công ty giải quyết nhiều vấn đề hơn chỉ một lần.
Linux có thể là lợi thế bị đánh giá thấp nhất của Electron
Linux khiến lập luận ủng hộ Electron càng thuyết phục hơn.
Hỗ trợ Linux một cách bài bản là việc khó. Không giống macOS hay Windows, “Linux desktop” không phải một nền tảng duy nhất được kiểm soát chặt chẽ. Nhà phát triển phải xử lý các bản phân phối, định dạng gói, môi trường desktop, ngăn xếp đồ họa, thư viện hệ thống và giao thức hiển thị khác nhau.
Với nhiều công ty phần mềm, quyết định kinh doanh hợp lý đơn giản là không hỗ trợ Linux.
Electron thay đổi bài toán kinh tế đó.
Vì Electron cung cấp một môi trường chạy chung trên macOS, Windows và Linux, việc bổ sung hỗ trợ Linux có thể dễ hơn rất nhiều so với duy trì một bản triển khai native riêng cho Linux. Đây là một lý do khiến người dùng Linux ngày nay có thể sử dụng nhiều ứng dụng desktop lớn mà trước đây có lẽ sẽ chẳng bao giờ có phiên bản Linux chính thức.
Visual Studio Code, Slack, Discord, Signal, 1Password, Postman, Obsidian và nhiều công cụ khác có thể hỗ trợ Linux mà không cần duy trì một ứng dụng GTK hoặc Qt hoàn toàn riêng biệt.
Electron cũng thay các nhà phát triển ứng dụng xử lý rất nhiều sự phức tạp đặc thù của Linux. Một ví dụ điển hình là quá trình chuyển từ X11 sang Wayland. Những người bảo trì Electron đã mô tả cách quá trình chuyển sang Wayland của Chromium trên thực tế kéo theo cả các ứng dụng Electron, qua đó giảm khối lượng công việc liên quan đến ngăn xếp hiển thị mà mỗi đội ngũ ứng dụng phải tự thực hiện.
Nếu không có các framework như Electron, nhiều công ty sẽ không xây dựng ứng dụng native cho Linux. Họ sẽ chỉ hỗ trợ macOS và Windows, để người dùng Linux dùng sản phẩm qua một tab trình duyệt.
Electron có lẽ đã đóng góp cho phần mềm desktop thương mại trên Linux nhiều hơn mức người ta thường ghi nhận.
Ngay cả Microsoft cũng ngày càng chọn công nghệ web
Microsoft có lẽ là phản ví dụ mạnh nhất cho quan điểm rằng phần mềm Windows nghiêm túc luôn phải dùng các framework giao diện native của Windows.
Microsoft kiểm soát Windows. Họ kiểm soát Win32, .NET, WinUI, WebView2 và phần lớn nền tảng mà các nhà phát triển xây dựng trên đó. Nếu phát triển hoàn toàn native trên Windows luôn là lựa chọn hiển nhiên, Microsoft sẽ ở vị thế thuận lợi nhất để áp dụng nó ở mọi nơi.
Nhưng họ không làm vậy.
Visual Studio Code dùng Electron. Teams vẫn được xây dựng quanh React, TypeScript và Chromium ngay cả sau khi Microsoft thay Electron bằng một môi trường chứa WebView2 được tối ưu hơn. Outlook mới cho Windows cũng phụ thuộc nhiều vào công nghệ web, và Microsoft mô tả rõ kiến trúc đó là một cách để tăng tính linh hoạt, đưa tính năng đến người dùng nhanh hơn và tạo ra trải nghiệm nhất quán hơn.
Teams là trường hợp đặc biệt đáng học hỏi. Microsoft muốn cải thiện hiệu năng và giảm tiêu thụ tài nguyên, nên họ thay đổi kiến trúc. Nhưng họ không viết lại giao diện thành một ứng dụng native Windows truyền thống.
Họ giữ lại bộ công nghệ web và tối ưu xung quanh nó.
Sự phân biệt đó rất quan trọng. Microsoft quyết định rằng những lợi thế về mặt tổ chức của React, TypeScript và Chromium đáng được giữ lại, ngay cả khi họ đang quyết liệt cải thiện hiệu năng.
Ở đây còn có một bài học khác. Chính Microsoft đã giới thiệu nhiều thế hệ công nghệ ứng dụng Windows qua các năm: Win32, WPF, UWP, WinUI và những công nghệ khác. Một công ty chọn “native Windows” không nhất thiết đang chọn một nền tảng tồn tại bền vững qua thời gian. Thường thì họ đang đặt cược vào một thế hệ framework được Microsoft ưu tiên.
Có phần trớ trêu là nền tảng web đã trở thành một trong những đích phát triển ứng dụng ổn định hơn cả.
Tuyển dụng là một phần của kiến trúc
Lựa chọn framework cũng quyết định bạn có thể tuyển dụng ai.
Các nhà phát triển JavaScript và TypeScript tạo thành một trong những nguồn nhân lực kỹ thuật lớn nhất trong ngành. Một công ty xây dựng bằng Electron có thể tuyển dụng từ nguồn đó, thay vì cần các đội ngũ chuyên gia giàu kinh nghiệm riêng cho macOS, Windows và Linux.
Các chuyên gia native vẫn có giá trị. Những sản phẩm desktop nghiêm túc vẫn cần kỹ sư hiểu sâu về hệ điều hành. Nhưng Electron thay đổi số lượng chuyên gia mà bạn cần.
Thay vì yêu cầu phần lớn ứng dụng phải do các chuyên gia nền tảng xây dựng, bạn có thể giữ một lượng mã tích hợp native tương đối nhỏ và để phần lớn đội ngũ làm việc trên sản phẩm dùng chung.
Điều này càng quan trọng hơn khi công ty đã có ứng dụng web. Đôi khi các thành phần React có thể được dùng chung. Các thư viện TypeScript có thể được tái sử dụng. Logic sản phẩm có thể được chuyển giữa web và desktop. Kỹ sư có thể chuyển đội ngũ mà không phải học một hệ sinh thái hoàn toàn khác.
Việc tuyển dụng cũng bớt dễ rơi vào thế bị động. Nếu kỹ sư duy nhất hiểu sâu về ứng dụng native Windows của bạn nghỉ việc, việc tìm người thay thế chuyên môn đó có thể rất khó. Với Electron, phần lớn hơn của cơ sở mã sử dụng các công nghệ quen thuộc với những người còn lại trong tổ chức.
Vì vậy, một framework không chỉ quyết định giao diện được hiển thị như thế nào. Nó còn ảnh hưởng đến cách tổ chức chính đội ngũ kỹ thuật.
Native không tự động đồng nghĩa với phần mềm tốt hơn
Các nhà phát triển thường dùng từ “native” gần như đồng nghĩa với “nhanh”.
Nhưng không phải vậy.
Các API native cho nhà phát triển cơ hội tạo ra một ứng dụng rất hiệu quả. Sản phẩm cuối cùng có thực sự đạt được điều đó hay không phụ thuộc vào kiến trúc, đội ngũ, ngân sách và khối lượng công việc tối ưu mà công ty có thể đầu tư.
Một ứng dụng native vẫn có thể chậm, nhiều lỗi, ngốn bộ nhớ, thiếu nhất quán hoặc được bảo trì kém.
Quan trọng hơn, chia một đội ngũ có nguồn lực hạn chế cho nhiều bản triển khai native đồng nghĩa với việc mỗi bản triển khai nhận được ít giờ làm việc của kỹ sư hơn.
Hãy tưởng tượng một công ty có sáu kỹ sư dành cho sản phẩm desktop. Một lựa chọn là chia họ giữa Mac và Windows, có lẽ để Linux không được hỗ trợ. Một lựa chọn khác là để gần như cả sáu kỹ sư làm việc trên một ứng dụng Electron dùng chung cho cả ba nền tảng.
Cách tiếp cận nào cho công ty nhiều năng lực kỹ thuật hơn để cải thiện thời gian khởi động, sửa rò rỉ bộ nhớ, trau chuốt các tương tác, cải thiện khả năng tiếp cận, giảm sự cố và phản hồi người dùng?
Không thể mặc nhiên cho rằng các ứng dụng native sẽ tạo ra sản phẩm tốt hơn.
Điều này tạo ra một nghịch lý thú vị: một framework tiêu tốn nhiều tài nguyên máy hơn đôi chút có thể giúp công ty xây dựng một sản phẩm được tối ưu tốt hơn, vì nó tiêu tốn ít nguồn lực kỹ thuật hơn rất nhiều.
Electron cho bạn một nền tảng có thể kiểm soát
Electron còn có một lợi thế khác rất dễ bị bỏ qua: nó đóng gói kèm chính môi trường chạy Chromium mà ứng dụng đã được xây dựng và kiểm thử trên đó.
Điều đó loại bỏ một biến số lớn khỏi quá trình phát triển đa nền tảng.
Các framework dựa trên webview của hệ điều hành có thể tạo ra ứng dụng nhỏ hơn, nhưng sự đánh đổi là cùng một frontend có thể chạy trên WebView2 ở Windows, WKWebView ở macOS và WebKitGTK ở Linux. Những bộ máy này có các khả năng, lỗi, lịch phát hành và hành vi hiển thị khác nhau.
Electron chọn một sự đánh đổi khác: đóng gói môi trường chạy và biến nó thành một phần của ứng dụng.
Đúng là điều đó tốn dung lượng ổ đĩa.
Nhưng nó mang lại cho nhà phát triển một nền tảng đích nhất quán hơn rất nhiều trên ba hệ điều hành rất khác nhau.
Sự nhất quán có giá trị kỹ thuật rất lớn.
Khi Electron không đủ, bạn vẫn có thể dùng native
Chọn Electron không có nghĩa là từ bỏ khả năng tiếp cận các chức năng native.
Ứng dụng Electron có thể sử dụng các mô-đun native và mã đặc thù của từng nền tảng khi cần. Điều đó có nghĩa là lựa chọn kiến trúc thực ra không phải:
100% native hoặc 100% JavaScript.
Với nhiều sản phẩm, mô hình tốt hơn là:
phần lớn ứng dụng được dùng chung, với một lượng nhỏ mã native ở những nơi hệ điều hành thực sự đòi hỏi.
Mã native trở thành phương án xử lý ngoại lệ thay vì nền tảng của toàn bộ sản phẩm.
Với nhiều công ty, đó là cách phân bổ công sức kỹ thuật tốt hơn rất nhiều.
Người dùng quan tâm đến sản phẩm, không phải framework
Có một nhóm nhỏ người dùng am hiểu kỹ thuật mở Activity Monitor, thấy vài tiến trình Chromium và lập tức phàn nàn rằng ứng dụng dùng Electron.
Phần lớn người dùng không làm vậy.
Họ không quan tâm Slack dùng Electron. Họ không quan tâm VS Code được xây dựng bằng công nghệ web. Họ không biết Claude dùng framework nào. Họ quan tâm phần mềm có giúp họ hoàn thành công việc hay không.
Nếu một ứng dụng khởi động đủ nhanh, phản hồi mượt mà, hiếm khi gặp sự cố và giải quyết được vấn đề của người dùng, thì công nghệ triển khai gần như vô hình.
Điều ngược lại cũng đúng. Một ứng dụng native không tự động trở thành sản phẩm tốt chỉ vì nó dùng Swift hay WinUI.
Phần mềm cạnh tranh ở cấp độ sản phẩm, không phải cấp độ framework.
Tối ưu công ty, không chỉ tệp nhị phân
Electron có những chi phí thực sự. Nó dùng nhiều dung lượng ổ đĩa hơn. Mức sử dụng bộ nhớ cơ bản thường cao hơn một ứng dụng native nhỏ. Chắc chắn có những sản phẩm mà các chi phí đó khiến Electron trở thành lựa chọn không phù hợp.
Một tiện ích nhỏ trên thanh menu có lẽ không cần Chromium. Trình điều khiển thiết bị thì chắc chắn không cần. Trò chơi, phần mềm âm thanh chuyên nghiệp và các ứng dụng cực kỳ nhạy cảm với độ trễ có những yêu cầu khác. Và nếu sản phẩm của bạn chỉ chạy trên một hệ điều hành duy nhất, việc chọn phát triển native sẽ dễ biện minh hơn nhiều.
Nhưng một tỷ lệ rất lớn phần mềm desktop hiện đại không thuộc những nhóm đó.
Chúng có giao diện phức tạp kết nối với các dịch vụ đám mây. Chúng cần chạy trên Windows và macOS, và ngày càng nhiều người dùng mong đợi cả hỗ trợ Linux. Chúng cần phát triển liên tục. Chúng cạnh tranh với những sản phẩm phát hành thay đổi hằng tuần. Và chúng thường được xây dựng bởi một công ty có số lượng kỹ sư hữu hạn.
Với những sản phẩm đó, năng suất của nhà phát triển là một phần của hiệu năng ứng dụng.
Electron cho phép một công ty tuyển dụng từ nguồn nhân lực lớn hơn nhiều, chia sẻ kỹ sư giữa web và desktop, duy trì một ứng dụng chính thay vì nhiều ứng dụng, tái sử dụng hệ sinh thái JavaScript, phát hành tính năng nhất quán hơn trên các hệ điều hành, hỗ trợ Linux với mức chi phí mà nếu không có Electron thường sẽ khó biện minh, và dành nhiều thời gian kỹ thuật hơn để cải thiện sản phẩm thay vì duy trì các bản triển khai song song.
Bạn có thể dễ dàng đo chi phí của Electron bằng megabyte.
Chi phí của phương án thay thế khó nhìn thấy hơn. Chúng thể hiện dưới dạng cần thêm kỹ sư, các bản triển khai trùng lặp, chu kỳ phát hành dài hơn, lỗi riêng của từng nền tảng, khó khăn trong tuyển dụng, các bộ phận hoạt động tách biệt, người dùng Linux không được hỗ trợ và những tính năng mất thêm nhiều tháng mới đến được với tất cả mọi người.
Những chi phí đó không xuất hiện trong Activity Monitor.
Nhưng với công ty xây dựng phần mềm, chúng có thể lớn hơn đáng kể.
Mục tiêu của phát triển phần mềm không phải là tạo ra tệp nhị phân nhỏ nhất.
Mà là xây dựng sản phẩm tốt nhất mà tổ chức của bạn có thể phát hành, bảo trì và liên tục cải thiện.
Với một nhóm ứng dụng desktop rộng lớn đến đáng ngạc nhiên, Electron vẫn là một trong những cách hiệu quả nhất để làm đúng điều đó.