Luangkan masa yang cukup di Hacker News atau Reddit dan akhirnya anda akan melihat kritikan yang sama: Electron terlalu sarat, Electron menggunakan terlalu banyak memori, dan aplikasi desktop yang serius sepatutnya dibina secara natif.
Kritikan itu ada benarnya. Aplikasi Electron secara umumnya mempunyai penggunaan sumber asas yang lebih besar kerana ia disertakan dengan Chromium dan Node.js. Aplikasi natif yang dibangunkan dengan teliti boleh menggunakan kurang memori, dilancarkan dengan lebih pantas, dan berintegrasi dengan lebih mendalam dengan sistem pengendaliannya.
Namun, perdebatan ini terlalu tertumpu pada komputer dan kurang memberikan perhatian kepada syarikat yang membina perisian itu.
Bagi kebanyakan pengguna, teknologi di sebalik sesuatu aplikasi hampir tidak penting. Mereka peduli sama ada aplikasi itu berfungsi, terasa responsif, pepijatnya diperbaiki, dan ciri berguna terus ditambah. Oleh itu, bagi syarikat perisian, salah satu sifat terpenting bagi sesuatu susunan teknologi ialah sesuatu yang jarang muncul dalam jadual penanda aras: seberapa pantaskah pasukan itu boleh membina, mengeluarkan, belajar, dan menambah baik produk?
Bagi banyak aplikasi desktop moden, Electron sangat berkesan dalam hal ini.
Sumber yang terhad ialah masa kejuruteraan
Dalam gambaran ideal, syarikat yang membangunkan aplikasi desktop natif mempunyai pasukan macOS yang cemerlang, satu lagi pasukan yang membina aplikasi Windows, dan mungkin pasukan lain yang menyokong Linux. Setiap aplikasi dioptimumkan dengan teliti untuk platformnya dan setiap jurutera memahami secara mendalam sistem pengendalian yang mereka gunakan.
Kebanyakan syarikat tidak mempunyai kemewahan itu.
Sesebuah produk desktop mungkin mempunyai lima orang jurutera. Mungkin hanya dua. Jurutera yang sama ini perlu membina ciri, membaiki pepijat, meningkatkan prestasi, memberikan respons kepada pelanggan, menyelenggara infrastruktur, menangani perubahan sistem pengendalian, dan memastikan produk terus berkembang.
Pembangunan natif menjadikan perkara ini lebih sukar kerana macOS, Windows, dan Linux sememangnya platform yang berbeza. Ketiga-tiganya mempunyai rangka kerja antara muka pengguna, API, sistem kebenaran, tingkah laku kitar hayat, pemasang, mekanisme kemas kini, sistem pemberitahuan, pengurusan tetingkap, API kebolehcapaian, serta pelbagai keunikan khusus platform yang terkumpul selama bertahun-tahun.
Electron mengubah keadaan itu. Ia menggabungkan Chromium, Node.js, dan API desktop menjadi model aplikasi bersama merentas macOS, Windows, dan Linux. Jurutera TypeScript yang sama selalunya boleh membina sesuatu ciri daripada antara muka hingga logik aplikasi dan mengeluarkannya pada setiap platform desktop. Kod natif masih boleh digunakan apabila benar-benar diperlukan, tetapi ia menjadi pengecualian dan bukannya asas produk. Electron sendiri menyifatkan perkara ini sebagai salah satu kelebihan utamanya: satu pangkalan kod JavaScript untuk ketiga-tiga platform desktop utama.
Perbezaan itu memberi kesan yang semakin besar dari tahun ke tahun. Jika setiap ciri penting memerlukan pelaksanaan Mac dan Windows yang berasingan, syarikat perlu menanggung kos tambahan platform itu berulang kali: bagi setiap ciri, reka bentuk semula, eksperimen, pembaikan pepijat, penambahbaikan kebolehcapaian, dan pengoptimuman prestasi.
Dengan Electron, sebahagian besar kerja itu hanya perlu dilakukan sekali.
Electron mengutamakan kelajuan iterasi
Produk jarang menjadi hebat kerana pelaksanaan pertamanya sempurna. Produk menjadi hebat melalui iterasi.
Pasukan mengeluarkan sesuatu. Pelanggan menggunakannya. Pasukan belajar. Mereka mengubah ciri itu. Lebih ramai orang menggunakannya. Masalah lain mula kelihatan. Pasukan menambah baiknya lagi.
Semakin pendek kitaran antara idea, pelaksanaan, maklum balas, dan penambahbaikan, semakin cepat sesuatu produk menjadi lebih baik.
Electron sangat berkesan dalam memendekkan kitaran itu kerana ia dibina berasaskan teknologi yang sudah digunakan secara meluas oleh syarikat perisian: JavaScript, TypeScript, HTML, CSS, React, Chromium, Node.js, dan npm.
Ini bermakna syarikat boleh berkongsi lebih banyak perkara daripada sekadar kod sumber. Mereka boleh berkongsi jurutera, komponen antara muka pengguna, alat pembangunan, pustaka, infrastruktur, pendekatan pengujian, dan pengetahuan organisasi antara produk web dan desktop mereka.
Jurutera bahagian hadapan tidak tiba-tiba menjadi tidak relevan hanya kerana syarikat memerlukan bantuan dengan aplikasi klien Windows. Jurutera desktop boleh menyumbang kepada aplikasi web. Jurutera TypeScript tindanan penuh boleh beralih antara produk apabila keutamaan berubah.
Bagi syarikat kecil atau sederhana, fleksibiliti itu boleh jauh lebih bernilai daripada menjimatkan 100 MB RAM.
Lihat siapa yang sebenarnya menggunakan Electron
Electron kadangkala digambarkan sebagai jalan pintas untuk syarikat yang enggan melabur dalam aplikasi desktop yang “sepatutnya”. Produk yang dibina dengannya menjadikan hujah itu semakin sukar dipertahankan.
Projek Electron sendiri mengetengahkan produk seperti Slack, Discord, Signal, ChatGPT, Claude, Visual Studio Code, Notion, Docker, Loom, dan Canva. Ini bukan utiliti ringkas. Banyak daripadanya merupakan antara aplikasi produktiviti paling canggih dan paling meluas digunakan di dunia.
Visual Studio Code ialah contoh yang amat berguna. Microsoft boleh membina penyunting kod utamanya menggunakan hampir mana-mana teknologi Windows yang dikehendakinya, namun VS Code menggunakan Electron merentas Windows, macOS, dan Linux. Ia merangkumi terminal, penyahpepijatan, pelayan bahasa, integrasi Git, pembangunan jarak jauh, buku nota, sambungan, dan penyunting yang sangat tersuai.
Persoalan yang menarik bukanlah sama ada Microsoft boleh menjimatkan memori dengan membina tiga versi natif yang berasingan. Sudah tentu boleh.
Persoalan yang lebih baik ialah sama ada VS Code akan berkembang sepantas itu, kekal sekonsisten itu merentas platform, dan membangunkan ekosistem sebesar itu jika setiap keupayaan utama memerlukan beberapa pelaksanaan berasingan.
ChatGPT dan Claude menunjukkan perbezaan pendekatan
Perbezaan antara ChatGPT dan Claude juga memberikan pengajaran.
Pada mulanya, OpenAI membina aplikasi macOS natif khusus untuk ChatGPT. Sebaliknya, Anthropic membina Claude Desktop menggunakan Electron dan mempunyai asas desktop bersama merentas platform sejak awal lagi.
Perbezaan itu menjadi semakin penting apabila produk tersebut berkembang. Claude Desktop boleh terus menambah keupayaan seperti integrasi MCP, sambungan, dan Claude Code ke dalam aplikasi merentas platform yang sama. Anthropic kini menyokong Claude Code secara langsung dalam pengalaman desktopnya, termasuk berbilang sesi setempat dan jarak jauh.
Kemudian, OpenAI turut mengalihkan hala tuju desktop merentas platformnya yang lebih baharu ke arah Electron, dan Electron kini menyenaraikan kedua-dua ChatGPT dan Claude antara aplikasi Electron yang terkenal.
Adalah keterlaluan untuk mendakwa bahawa Electron sahaja menjelaskan perbezaan kelajuan pembangunan produk. Saiz pasukan, keutamaan, strategi produk, dan organisasi dalaman semuanya penting. Namun, kelebihan seni binanya jelas: asas bersama merentas platform memudahkan ciri dikeluarkan merentas sistem pengendalian tanpa perlu menyelenggara pelaksanaan yang berasingan.
Itulah jenis kelebihan yang menjadi semakin bernilai apabila sesuatu produk desktop berkembang.
Evernote mempelajari kos menyelenggara klien berasingan
Evernote ialah salah satu contoh sejarah yang paling jelas tentang masalah ini.
Selama bertahun-tahun, Evernote menyelenggara aplikasi yang berbeza untuk Mac, Windows, peranti mudah alih, dan web. Lama-kelamaan, produk tersebut mengumpulkan tingkah laku yang berbeza, perbezaan pemaparan, andaian lama, dan masalah penyegerakan.
Pada 2020, Evernote membina semula aplikasi Windows dan Macnya berasaskan pangkalan kod bersama. Syarikat itu menyatakan bahawa asas baharu tersebut akan menjadikan aplikasi lebih stabil, membolehkan pepijat diperbaiki dengan lebih pantas, membolehkan ciri dikeluarkan dengan lebih kerap, dan meningkatkan penyegerakan merentas platform.
Peralihan itu bukan tanpa kesukaran, dan sesetengah pengguna lama tidak menyukai kehilangan awal ciri khusus platform. Namun, sebab Evernote melakukan penulisan semula yang begitu mahal lebih menarik daripada masalah peralihan itu sendiri.
Apabila sesuatu produk mempunyai penyunting yang kaya dengan fungsi, storan luar talian, carian, lampiran, kerjasama, tugasan, kalendar, dan penyegerakan yang kompleks, menyelenggara beberapa pelaksanaan bebas menjadi semakin mahal. Pepijat berkelakuan secara berbeza. Pemaparan berbeza. Logik penyegerakan berinteraksi dengan seni bina setempat yang berbeza. Setiap perubahan produk yang penting perlu diterapkan pada beberapa klien.
Seni bina bersama tidak menghilangkan masalah yang sukar. Ia membolehkan syarikat menyelesaikan lebih banyak masalah itu sekali sahaja.
Linux mungkin kelebihan Electron yang paling kurang dihargai
Linux menjadikan alasan untuk menggunakan Electron lebih kukuh lagi.
Memberikan sokongan Linux dengan baik adalah sukar. Tidak seperti macOS atau Windows, “desktop Linux” bukan satu platform yang dikawal dengan ketat. Pembangun perlu menangani pelbagai pengedaran, format pakej, persekitaran desktop, tindanan grafik, pustaka sistem, dan protokol paparan.
Bagi banyak syarikat perisian, keputusan perniagaan yang rasional mungkin sekadar tidak menyokong Linux.
Electron mengubah pertimbangan ekonominya.
Oleh sebab Electron menyediakan persekitaran masa jalan yang sama merentas macOS, Windows, dan Linux, menambah sokongan Linux boleh menjadi jauh lebih mudah daripada menyelenggara pelaksanaan Linux natif yang berasingan. Inilah salah satu sebab pengguna Linux hari ini mempunyai akses kepada banyak aplikasi desktop utama yang pada masa lalu mungkin tidak akan pernah mendapat klien Linux rasmi.
Visual Studio Code, Slack, Discord, Signal, 1Password, Postman, Obsidian, dan banyak alat lain boleh menyokong Linux tanpa perlu menyelenggara aplikasi GTK atau Qt yang sepenuhnya berasingan.
Electron juga menangani banyak kerumitan khusus Linux bagi pihak pembangun aplikasi. Contoh yang baik ialah peralihan daripada X11 kepada Wayland. Penyelenggara Electron telah menerangkan bagaimana peralihan Chromium kepada Wayland pada asasnya membawa aplikasi Electron bersama-sama, sekali gus mengurangkan kerja berkaitan tindanan paparan yang perlu dilakukan secara berasingan oleh setiap pasukan aplikasi.
Tanpa rangka kerja seperti Electron, banyak syarikat tidak akan membina klien Linux natif. Mereka hanya akan menyokong macOS dan Windows serta membiarkan pengguna Linux bergantung pada tab pelayar.
Electron mungkin telah menyumbang lebih banyak kepada perisian desktop Linux komersial daripada yang diiktiraf.
Malah Microsoft semakin memilih teknologi web
Microsoft mungkin contoh paling kukuh yang menentang idea bahawa perisian Windows yang serius patut sentiasa menggunakan rangka kerja antara muka pengguna Windows natif.
Microsoft mengawal Windows. Ia mengawal Win32, .NET, WinUI, WebView2, dan sebahagian besar platform yang digunakan oleh pembangun. Jika pembangunan Windows yang sepenuhnya natif sentiasa menjadi jawapan yang jelas, Microsoft berada pada kedudukan terbaik untuk menggunakannya di mana-mana.
Namun, itu bukan yang dilakukannya.
Visual Studio Code menggunakan Electron. Teams masih dibina berasaskan React, TypeScript, dan Chromium walaupun selepas Microsoft menggantikan Electron dengan hos WebView2 yang lebih dioptimumkan. Outlook baharu untuk Windows juga sangat bergantung pada teknologi web, dan Microsoft secara jelas menyifatkan seni bina itu sebagai cara untuk meningkatkan ketangkasan, membolehkan ciri disampaikan dengan lebih pantas, dan mewujudkan pengalaman yang lebih konsisten.
Teams amat memberikan pengajaran. Microsoft mahu meningkatkan prestasi dan mengurangkan penggunaan sumber, jadi ia mengubah seni binanya. Namun, ia tidak menulis semula antara muka pengguna itu sebagai aplikasi Windows natif tradisional.
Ia mengekalkan tindanan web dan melakukan pengoptimuman di sekelilingnya.
Perbezaan itu penting. Microsoft memutuskan bahawa kelebihan React, TypeScript, dan Chromium dari sudut organisasi wajar dikekalkan walaupun sambil meningkatkan prestasi secara agresif.
Ada satu lagi pengajaran di sini. Microsoft sendiri telah memperkenalkan banyak generasi teknologi aplikasi Windows selama bertahun-tahun: Win32, WPF, UWP, WinUI, dan lain-lain. Syarikat yang memilih “Windows natif” tidak semestinya memilih platform yang akan kekal relevan sepanjang zaman. Sering kali, ia bertaruh pada satu generasi rangka kerja pilihan Microsoft.
Secara agak ironis, platform web telah menjadi salah satu sasaran pembangunan aplikasi yang lebih stabil.
Pengambilan pekerja ialah sebahagian daripada seni bina
Pilihan rangka kerja juga menentukan siapa yang boleh anda ambil bekerja.
Pembangun JavaScript dan TypeScript merupakan antara kelompok bakat kejuruteraan terbesar dalam industri. Syarikat yang membina menggunakan Electron boleh merekrut daripada kelompok itu dan bukannya memerlukan pasukan berasingan yang terdiri daripada pakar macOS, Windows, dan Linux berpengalaman.
Pakar natif tetap bernilai. Produk desktop yang serius masih memerlukan jurutera yang memahami sistem pengendalian secara mendalam. Namun, Electron mengubah bilangan pakar yang anda perlukan.
Daripada menghendaki sebahagian besar aplikasi dibina oleh pakar platform, anda boleh mengekalkan jumlah kod integrasi natif yang agak kecil dan membiarkan majoriti pasukan mengusahakan produk bersama.
Ini menjadi lebih penting apabila sesebuah syarikat sudah mempunyai aplikasi web. Komponen React kadangkala boleh dikongsi. Pustaka TypeScript boleh digunakan semula. Logik produk boleh dipindahkan antara web dan desktop. Jurutera boleh bertukar pasukan tanpa perlu mempelajari ekosistem yang sama sekali berbeza.
Pengambilan pekerja juga menjadi kurang terdedah kepada risiko. Jika satu-satunya jurutera yang memahami klien Windows natif anda secara mendalam meninggalkan syarikat, menggantikan kepakaran itu mungkin sukar. Dengan Electron, bahagian pangkalan kod yang jauh lebih besar menggunakan teknologi yang sudah dikenali oleh anggota organisasi yang lain.
Oleh itu, rangka kerja bukan sekadar menentukan cara antara muka dipaparkan. Ia mempengaruhi cara organisasi kejuruteraan itu sendiri boleh distrukturkan.
Natif tidak secara automatik bermaksud perisian yang lebih baik
Pembangun sering menggunakan perkataan “natif” seolah-olah hampir sama maknanya dengan “pantas”.
Sebenarnya tidak.
API natif memberi peluang kepada pembangun untuk mencipta aplikasi yang sangat cekap. Sama ada produk akhir benar-benar mencapai tahap itu bergantung pada seni bina, pasukan, belanjawan, dan jumlah kerja pengoptimuman yang mampu ditanggung oleh syarikat.
Aplikasi natif masih boleh menjadi perlahan, penuh pepijat, menggunakan banyak memori, tidak konsisten, atau tidak diselenggara dengan baik.
Lebih penting lagi, membahagikan pasukan yang terhad kepada beberapa pelaksanaan natif bermakna setiap pelaksanaan menerima lebih sedikit jam kejuruteraan.
Bayangkan sebuah syarikat mempunyai enam orang jurutera untuk produk desktopnya. Satu pilihan ialah membahagikan mereka antara Mac dan Windows, mungkin dengan membiarkan Linux tidak disokong. Pilihan lain ialah menugaskan hampir kesemua enam orang jurutera itu pada satu aplikasi Electron bersama yang menyokong ketiga-tiga platform.
Pendekatan manakah yang memberikan syarikat lebih banyak kapasiti kejuruteraan untuk mempercepat masa permulaan, membaiki kebocoran memori, memperkemas interaksi, meningkatkan kebolehcapaian, mengurangkan ranap, dan memberikan respons kepada pengguna?
Tidak semestinya aplikasi natif menghasilkan produk yang lebih baik.
Ini mewujudkan paradoks yang menarik: rangka kerja yang menggunakan sedikit lebih banyak sumber mesin boleh membolehkan syarikat membina produk yang lebih dioptimumkan kerana ia menggunakan jauh lebih sedikit sumber kejuruteraan.
Electron memberikan anda platform yang terkawal
Electron juga mempunyai satu lagi kelebihan yang mudah terlepas pandang: ia disertakan dengan persekitaran masa jalan Chromium yang digunakan untuk membina dan menguji aplikasi itu.
Ini menyingkirkan satu pemboleh ubah utama daripada pembangunan merentas platform.
Rangka kerja berasaskan paparan web sistem pengendalian boleh menghasilkan aplikasi yang lebih kecil, tetapi sebagai pertukaran, bahagian hadapan yang sama mungkin berjalan pada WebView2 di Windows, WKWebView di macOS, dan WebKitGTK di Linux. Enjin tersebut mempunyai keupayaan, pepijat, jadual keluaran, dan tingkah laku pemaparan yang berbeza.
Electron mengambil pendekatan pertukaran yang berbeza: sertakan persekitaran masa jalan dan jadikannya sebahagian daripada aplikasi.
Ya, itu memerlukan ruang cakera.
Namun, ia memberikan pembangun sasaran yang jauh lebih konsisten merentas tiga sistem pengendalian yang sangat berbeza.
Konsistensi mempunyai nilai kejuruteraan yang amat besar.
Apabila Electron tidak mencukupi, anda masih boleh menggunakan kod natif
Memilih Electron tidak bermakna melepaskan akses kepada keupayaan natif.
Aplikasi Electron boleh menggunakan modul natif dan kod khusus platform apabila perlu. Ini bermakna pilihan seni bina sebenarnya bukanlah:
100% natif atau 100% JavaScript.
Bagi banyak produk, model yang lebih baik ialah:
sebahagian besar aplikasi dikongsi, dengan sedikit kod natif apabila sistem pengendalian benar-benar memerlukannya.
Kod natif menjadi jalan keluar apabila perlu, bukannya asas keseluruhan produk.
Bagi banyak syarikat, itu merupakan pembahagian usaha kejuruteraan yang jauh lebih baik.
Pengguna peduli tentang produk, bukan rangka kerja
Terdapat sekumpulan kecil pengguna yang mahir dari segi teknikal yang membuka Activity Monitor, melihat beberapa proses Chromium, dan terus mengadu bahawa sesuatu aplikasi menggunakan Electron.
Kebanyakan pengguna tidak berbuat demikian.
Mereka tidak peduli bahawa Slack menggunakan Electron. Mereka tidak peduli bahawa VS Code dibina dengan teknologi web. Mereka tidak tahu rangka kerja yang digunakan oleh Claude. Mereka peduli sama ada perisian itu membantu mereka menyiapkan kerja.
Jika sesuatu aplikasi dilancarkan dengan cukup pantas, terasa responsif, jarang ranap, dan menyelesaikan masalah pengguna, teknologi pelaksanaannya hampir tidak disedari.
Perkara sebaliknya juga benar. Aplikasi natif tidak secara automatik menjadi produk yang baik hanya kerana ia menggunakan Swift atau WinUI.
Perisian bersaing pada peringkat produk, bukan pada peringkat rangka kerja.
Optimumkan syarikat, bukan sekadar binari
Electron mempunyai kos yang nyata. Ia menggunakan lebih banyak ruang cakera. Penggunaan memori asasnya biasanya lebih tinggi daripada aplikasi natif yang kecil. Memang ada produk yang menjadikan Electron pilihan yang salah disebabkan kos tersebut.
Utiliti bar menu yang kecil mungkin tidak memerlukan Chromium. Pemacu peranti sudah tentu tidak memerlukannya. Permainan, perisian audio profesional, dan aplikasi yang sangat sensitif terhadap kependaman mempunyai keperluan yang berbeza. Jika produk anda hanya akan berjalan pada satu sistem pengendalian, pembangunan natif menjadi lebih mudah untuk diwajarkan.
Namun, sebahagian besar perisian desktop moden tidak termasuk dalam kategori tersebut.
Perisian itu terdiri daripada antara muka kompleks yang disambungkan kepada perkhidmatan awan. Ia perlu berjalan pada Windows dan macOS, dan pengguna semakin mengharapkan sokongan Linux juga. Ia perlu berkembang secara berterusan. Ia bersaing dengan produk yang mengeluarkan perubahan setiap minggu. Dan biasanya, ia dibina oleh syarikat dengan bilangan jurutera yang terhad.
Bagi produk tersebut, produktiviti pembangun ialah sebahagian daripada prestasi aplikasi.
Electron membolehkan syarikat mengambil pekerja daripada kelompok bakat yang jauh lebih besar, berkongsi jurutera antara web dan desktop, menyelenggara satu aplikasi utama dan bukannya beberapa aplikasi, menggunakan semula ekosistem JavaScript, mengeluarkan ciri merentas sistem pengendalian dengan lebih konsisten, menyokong Linux pada kos yang tanpa Electron selalunya sukar diwajarkan, dan meluangkan lebih banyak masa kejuruteraan untuk menambah baik produk dan bukannya menyelenggara pelaksanaan selari.
Anda boleh mengukur kos Electron dalam megabait dengan mudah.
Kos pilihan alternatif lebih sukar dilihat. Ia muncul dalam bentuk jurutera tambahan, pelaksanaan bertindih, kitaran keluaran yang lebih panjang, pepijat khusus platform, kesukaran mengambil pekerja, pengasingan antara bahagian organisasi, pengguna Linux yang tidak disokong, dan ciri yang mengambil masa berbulan-bulan lebih lama untuk sampai kepada semua pengguna.
Kos tersebut tidak muncul dalam Activity Monitor.
Namun, bagi syarikat yang membina perisian itu, kos tersebut mungkin jauh lebih besar.
Matlamat pembangunan perisian bukanlah menghasilkan binari yang paling kecil.
Matlamatnya ialah membina produk terbaik yang mampu dikeluarkan, diselenggara, dan ditambah baik secara berterusan oleh organisasi anda.
Bagi kelompok aplikasi desktop yang ternyata sangat besar, Electron kekal sebagai salah satu cara paling cekap untuk melakukan perkara itu.