Jika Anda cukup lama menghabiskan waktu di Hacker News atau Reddit, pada akhirnya Anda akan melihat kritik yang sama: Electron terlalu tambun, Electron menggunakan terlalu banyak memori, dan aplikasi desktop yang serius seharusnya dibuat secara native.
Ada benarnya kritik tersebut. Aplikasi Electron umumnya memiliki kebutuhan sumber daya dasar yang lebih besar karena menyertakan Chromium dan Node.js. Aplikasi native yang dirancang dengan cermat dapat menggunakan lebih sedikit memori, terbuka lebih cepat, dan terintegrasi lebih erat dengan sistem operasinya.
Namun, perdebatan ini terlalu berfokus pada komputer dan kurang memperhatikan perusahaan yang membangun perangkat lunaknya.
Bagi sebagian besar pengguna, teknologi di balik sebuah aplikasi nyaris tidak penting. Mereka peduli apakah aplikasi itu berfungsi, terasa responsif, bug diperbaiki, dan fitur berguna terus ditambahkan. Karena itu, bagi perusahaan perangkat lunak, salah satu karakteristik terpenting dari sebuah tumpukan teknologi adalah sesuatu yang jarang muncul dalam tabel tolok ukur: seberapa cepat tim dapat membangun, merilis, belajar, dan menyempurnakan produk?
Untuk banyak aplikasi desktop modern, Electron sangat unggul dalam hal itu.
Sumber daya yang langka adalah waktu pengembang
Dalam gambaran ideal, perusahaan aplikasi desktop native memiliki tim macOS yang hebat, tim lain yang membangun aplikasi Windows, dan mungkin tim lain yang mendukung Linux. Setiap aplikasi dioptimalkan dengan cermat untuk platformnya, dan setiap pengembang memahami secara mendalam sistem operasi yang mereka tangani.
Sebagian besar perusahaan tidak memiliki kemewahan itu.
Sebuah produk desktop mungkin hanya memiliki lima pengembang. Mungkin dua. Pengembang yang sama harus membangun fitur, memperbaiki bug, meningkatkan kinerja, merespons pelanggan, memelihara infrastruktur, menghadapi perubahan sistem operasi, dan terus mengembangkan produk.
Pengembangan native membuat hal ini lebih sulit karena macOS, Windows, dan Linux memang merupakan platform yang berbeda. Ketiganya memiliki kerangka kerja antarmuka pengguna, API, sistem izin, perilaku siklus hidup aplikasi, penginstal, mekanisme pembaruan, sistem notifikasi, pengelolaan jendela, API aksesibilitas, serta berbagai keunikan spesifik platform yang terakumulasi selama bertahun-tahun.
Electron mengubah perhitungan itu. Electron menggabungkan Chromium, Node.js, dan API desktop menjadi model aplikasi bersama untuk macOS, Windows, dan Linux. Satu pengembang TypeScript sering kali dapat membangun fitur mulai dari antarmuka hingga logika aplikasi, lalu merilisnya di setiap platform desktop. Kode native tetap dapat digunakan ketika benar-benar dibutuhkan, tetapi menjadi pengecualian, bukan fondasi produk. Electron sendiri menyebut hal ini sebagai salah satu keunggulan utamanya: satu basis kode JavaScript untuk ketiga platform desktop utama.
Perbedaan itu terakumulasi selama bertahun-tahun. Jika setiap fitur penting membutuhkan implementasi Mac dan Windows yang terpisah, perusahaan harus berulang kali menanggung beban tambahan akibat perbedaan platform: untuk setiap fitur, desain ulang, eksperimen, perbaikan bug, peningkatan aksesibilitas, dan optimasi kinerja.
Dengan Electron, sebagian besar pekerjaan itu cukup dilakukan sekali.
Electron mengoptimalkan kecepatan iterasi
Produk jarang menjadi hebat karena implementasi pertamanya sempurna. Produk menjadi hebat melalui iterasi.
Tim merilis sesuatu. Pelanggan menggunakannya. Tim belajar. Tim mengubah fitur tersebut. Lebih banyak orang menggunakannya. Masalah lain mulai terlihat. Tim menyempurnakannya lagi.
Semakin pendek siklus antara ide, implementasi, umpan balik, dan penyempurnaan, semakin cepat produk menjadi lebih baik.
Electron sangat unggul dalam memperpendek siklus tersebut karena dibangun di atas teknologi yang sudah digunakan perusahaan perangkat lunak di mana-mana: JavaScript, TypeScript, HTML, CSS, React, Chromium, Node.js, dan npm.
Artinya, perusahaan dapat berbagi jauh lebih banyak daripada sekadar kode sumber. Mereka dapat berbagi pengembang, komponen antarmuka pengguna, perangkat bantu, pustaka, infrastruktur, pendekatan pengujian, dan pengetahuan organisasi antara produk web dan desktop mereka.
Seorang pengembang frontend tidak tiba-tiba menjadi tidak relevan hanya karena perusahaan membutuhkan bantuan untuk aplikasi klien Windows. Pengembang desktop dapat berkontribusi pada aplikasi web. Pengembang full-stack TypeScript dapat berpindah antarproduk seiring perubahan prioritas.
Bagi perusahaan kecil atau menengah, fleksibilitas itu bisa jauh lebih berharga daripada menghemat RAM sebesar 100 MB.
Lihat siapa yang benar-benar menggunakan Electron
Electron terkadang digambarkan sebagai jalan pintas bagi perusahaan yang enggan berinvestasi dalam aplikasi desktop yang “layak”. Produk-produk yang dibangun dengannya membuat argumen itu semakin sulit dipertahankan.
Proyek Electron sendiri menyoroti produk seperti Slack, Discord, Signal, ChatGPT, Claude, Visual Studio Code, Notion, Docker, Loom, dan Canva. Ini bukan utilitas sederhana. Banyak di antaranya merupakan aplikasi produktivitas paling canggih dan paling banyak digunakan di dunia.
Visual Studio Code adalah contoh yang sangat berguna. Microsoft dapat membangun editor kode andalannya menggunakan hampir semua teknologi Windows yang diinginkannya, tetapi VS Code menggunakan Electron di Windows, macOS, dan Linux. Aplikasi ini mencakup terminal, debugging, server bahasa, integrasi Git, pengembangan jarak jauh, notebook, ekstensi, dan editor yang sangat terkustomisasi.
Pertanyaan yang menarik bukanlah apakah Microsoft dapat menghemat memori dengan membangun tiga versi native yang terpisah. Tentu saja bisa.
Pertanyaan yang lebih tepat adalah apakah VS Code akan berkembang secepat itu, tetap sekonsisten itu di berbagai platform, dan membangun ekosistem sebesar itu jika setiap kemampuan utama membutuhkan beberapa implementasi terpisah.
ChatGPT dan Claude menunjukkan perbedaan pendekatan
Perbedaan antara ChatGPT dan Claude juga memberikan pelajaran.
OpenAI awalnya membangun aplikasi macOS native khusus untuk ChatGPT. Sebaliknya, Anthropic membangun Claude Desktop dengan Electron dan sejak awal memiliki fondasi desktop bersama untuk berbagai platform.
Perbedaan itu menjadi semakin penting ketika produk-produk tersebut berkembang. Claude Desktop dapat terus menambahkan kemampuan seperti integrasi MCP, ekstensi, dan Claude Code ke dalam aplikasi lintas platform yang sama. Anthropic kini mendukung Claude Code langsung di dalam pengalaman desktopnya, termasuk beberapa sesi lokal dan jarak jauh.
Belakangan, OpenAI juga mengarahkan pengembangan desktop lintas platform terbarunya ke Electron, dan Electron kini mencantumkan ChatGPT maupun Claude sebagai aplikasi Electron terkemuka.
Terlalu berlebihan jika menyatakan bahwa Electron saja menjelaskan perbedaan kecepatan pengembangan produk. Ukuran tim, prioritas, strategi produk, dan organisasi internal semuanya berpengaruh. Namun, keunggulan arsitekturnya jelas: fondasi lintas platform bersama memudahkan perilisan fitur di berbagai sistem operasi tanpa harus memelihara implementasi terpisah.
Itulah jenis keunggulan yang semakin bernilai seiring berkembangnya sebuah produk desktop.
Evernote mempelajari besarnya biaya memelihara aplikasi klien terpisah
Evernote adalah salah satu contoh historis paling jelas dari masalah ini.
Selama bertahun-tahun, Evernote memelihara aplikasi yang berbeda untuk Mac, Windows, perangkat seluler, dan web. Seiring waktu, produk-produk tersebut mengakumulasi perbedaan perilaku, perbedaan rendering, asumsi lama, dan masalah sinkronisasi.
Pada 2020, Evernote membangun ulang aplikasi Windows dan Mac-nya menggunakan basis kode bersama. Perusahaan itu mengatakan bahwa fondasi baru tersebut akan membuat aplikasi lebih stabil, memungkinkan bug diperbaiki lebih cepat, memungkinkan fitur dirilis lebih sering, dan meningkatkan sinkronisasi lintas platform.
Migrasi itu tidak berjalan tanpa kendala, dan sebagian pengguna lama tidak menyukai hilangnya fitur-fitur spesifik platform pada tahap awal. Namun, alasan Evernote melakukan penulisan ulang yang begitu mahal lebih menarik daripada masalah migrasinya sendiri.
Begitu sebuah produk memiliki editor dengan banyak fitur, penyimpanan offline, pencarian, lampiran, kolaborasi, tugas, kalender, dan sinkronisasi yang kompleks, memelihara beberapa implementasi independen menjadi semakin mahal. Bug berperilaku berbeda. Rendering berbeda. Logika sinkronisasi berinteraksi dengan arsitektur lokal yang berbeda. Setiap perubahan produk yang berarti harus diterapkan ke beberapa aplikasi klien.
Arsitektur bersama tidak membuat masalah sulit menghilang. Arsitektur itu memungkinkan perusahaan menyelesaikan lebih banyak masalah cukup sekali.
Linux mungkin merupakan keunggulan Electron yang paling kurang dihargai
Linux membuat alasan untuk menggunakan Electron semakin kuat.
Mendukung Linux dengan baik itu sulit. Tidak seperti macOS atau Windows, “desktop Linux” bukanlah satu platform yang dikendalikan secara ketat. Pengembang harus menghadapi berbagai distribusi, format paket, lingkungan desktop, tumpukan grafis, pustaka sistem, dan protokol tampilan.
Bagi banyak perusahaan perangkat lunak, keputusan bisnis yang rasional adalah tidak mendukung Linux sama sekali.
Electron mengubah perhitungan ekonominya.
Karena Electron menyediakan runtime yang sama untuk macOS, Windows, dan Linux, menambahkan dukungan Linux bisa jauh lebih mudah daripada memelihara implementasi Linux native yang terpisah. Inilah salah satu alasan pengguna Linux saat ini dapat mengakses banyak aplikasi desktop utama yang sebelumnya mungkin tidak akan pernah mendapatkan aplikasi klien Linux resmi.
Visual Studio Code, Slack, Discord, Signal, 1Password, Postman, Obsidian, dan banyak alat lainnya dapat mendukung Linux tanpa harus memelihara aplikasi GTK atau Qt yang sepenuhnya terpisah.
Electron juga menangani banyak kerumitan khusus Linux untuk para pengembang aplikasi. Contoh yang bagus adalah peralihan dari X11 ke Wayland. Para pengelola Electron telah menjelaskan bagaimana transisi Chromium ke Wayland secara efektif membawa aplikasi Electron ikut beralih, sehingga mengurangi pekerjaan terkait tumpukan tampilan yang harus dilakukan secara mandiri oleh setiap tim aplikasi.
Tanpa kerangka kerja seperti Electron, banyak perusahaan tidak akan membangun aplikasi klien Linux native. Mereka hanya akan mendukung macOS dan Windows, lalu membiarkan pengguna Linux mengandalkan tab browser.
Electron mungkin telah berkontribusi lebih besar terhadap perangkat lunak desktop komersial di Linux daripada yang diakui banyak orang.
Bahkan Microsoft semakin memilih teknologi web
Microsoft mungkin merupakan contoh tandingan terkuat terhadap gagasan bahwa perangkat lunak Windows yang serius harus selalu menggunakan kerangka kerja antarmuka pengguna Windows native.
Microsoft mengendalikan Windows. Microsoft mengendalikan Win32, .NET, WinUI, WebView2, dan sebagian besar platform yang menjadi landasan pengembangan aplikasi. Jika pengembangan Windows yang sepenuhnya native selalu merupakan jawaban yang jelas, Microsoft berada dalam posisi terbaik untuk menggunakannya di mana-mana.
Namun, Microsoft tidak melakukannya.
Visual Studio Code menggunakan Electron. Teams tetap dibangun di atas React, TypeScript, dan Chromium, bahkan setelah Microsoft mengganti Electron dengan host WebView2 yang lebih optimal. Outlook baru untuk Windows juga sangat mengandalkan teknologi web, dan Microsoft secara eksplisit menggambarkan arsitektur itu sebagai cara untuk meningkatkan kelincahan, mempercepat penyampaian fitur, dan menciptakan pengalaman yang lebih konsisten.
Teams sangat memberikan pelajaran. Microsoft ingin meningkatkan kinerja dan mengurangi konsumsi sumber daya, sehingga mengubah arsitekturnya. Namun, Microsoft tidak menulis ulang antarmukanya sebagai aplikasi Windows native tradisional.
Microsoft mempertahankan tumpukan teknologi web dan melakukan optimasi di sekelilingnya.
Perbedaan itu penting. Microsoft memutuskan bahwa keunggulan organisasional dari React, TypeScript, dan Chromium layak dipertahankan, bahkan sambil meningkatkan kinerja secara agresif.
Ada pelajaran lain di sini. Microsoft sendiri telah memperkenalkan banyak generasi teknologi aplikasi Windows selama bertahun-tahun: Win32, WPF, UWP, WinUI, dan lainnya. Perusahaan yang memilih “Windows native” belum tentu memilih platform yang abadi. Sering kali, perusahaan itu sedang bertaruh pada salah satu generasi kerangka kerja pilihan Microsoft.
Agak ironisnya, platform web telah menjadi salah satu target pengembangan aplikasi yang lebih stabil.
Perekrutan adalah bagian dari arsitektur
Pilihan kerangka kerja juga menentukan siapa yang dapat Anda rekrut.
Pengembang JavaScript dan TypeScript merupakan salah satu kelompok talenta pengembang terbesar di industri ini. Perusahaan yang membangun dengan Electron dapat merekrut dari kelompok tersebut, alih-alih harus memiliki tim terpisah berisi spesialis macOS, Windows, dan Linux yang berpengalaman.
Spesialis native tetap bernilai. Produk desktop yang serius masih membutuhkan pengembang yang memahami sistem operasi secara mendalam. Namun, Electron mengubah jumlah spesialis yang Anda butuhkan.
Alih-alih mengharuskan sebagian besar aplikasi dibangun oleh para ahli platform, Anda dapat mempertahankan kode integrasi native dalam jumlah yang relatif kecil dan membiarkan sebagian besar tim mengerjakan produk bersama.
Hal ini semakin penting ketika perusahaan sudah memiliki aplikasi web. Komponen React terkadang dapat digunakan bersama. Pustaka TypeScript dapat digunakan kembali. Logika produk dapat dipindahkan antara web dan desktop. Pengembang dapat berpindah tim tanpa harus mempelajari ekosistem yang sama sekali berbeda.
Perekrutan juga menjadi lebih tahan terhadap gangguan. Jika satu-satunya pengembang yang memahami aplikasi klien Windows native Anda secara mendalam keluar, menggantikan keahlian itu bisa sulit. Dengan Electron, jauh lebih banyak bagian basis kode menggunakan teknologi yang sudah dikenal oleh anggota organisasi lainnya.
Dengan demikian, kerangka kerja tidak sekadar menentukan bagaimana antarmuka dirender. Kerangka kerja juga memengaruhi bagaimana organisasi pengembangan itu sendiri dapat disusun.
Native tidak otomatis berarti perangkat lunak yang lebih baik
Pengembang sering menggunakan kata “native” seolah-olah sinonim dari “cepat”.
Padahal tidak.
API native memberi pengembang peluang untuk menciptakan aplikasi yang sangat efisien. Apakah produk akhirnya benar-benar mencapai hal itu bergantung pada arsitektur, tim, anggaran, dan seberapa banyak pekerjaan optimasi yang mampu dibiayai perusahaan.
Aplikasi native tetap bisa lambat, penuh bug, boros memori, tidak konsisten, atau kurang terpelihara.
Yang lebih penting, membagi tim yang terbatas untuk menangani beberapa implementasi native berarti setiap implementasi mendapatkan lebih sedikit jam kerja pengembang.
Bayangkan sebuah perusahaan memiliki enam pengembang untuk produk desktopnya. Salah satu pilihannya adalah membagi mereka antara Mac dan Windows, mungkin tanpa mendukung Linux. Pilihan lainnya adalah menempatkan hampir keenam pengembang itu pada satu aplikasi Electron bersama yang melayani ketiga platform.
Pendekatan mana yang memberi perusahaan lebih banyak kapasitas pengembangan untuk mempercepat waktu startup, memperbaiki kebocoran memori, menyempurnakan interaksi, meningkatkan aksesibilitas, mengurangi crash, dan merespons pengguna?
Tidak ada jaminan bahwa aplikasi native akan menghasilkan produk yang lebih baik.
Ini menciptakan paradoks yang menarik: kerangka kerja yang mengonsumsi sedikit lebih banyak sumber daya mesin dapat memungkinkan perusahaan membangun produk yang lebih optimal karena mengonsumsi jauh lebih sedikit sumber daya pengembangan.
Electron memberi Anda platform yang terkendali
Electron juga memiliki keunggulan lain yang mudah terlewatkan: Electron menyertakan runtime Chromium yang digunakan saat aplikasi dibangun dan diuji.
Hal ini menghilangkan satu variabel besar dari pengembangan lintas platform.
Kerangka kerja yang berbasis webview sistem operasi dapat menghasilkan aplikasi yang lebih kecil, tetapi konsekuensinya adalah frontend yang sama mungkin berjalan di WebView2 pada Windows, WKWebView pada macOS, dan WebKitGTK pada Linux. Mesin-mesin tersebut memiliki kemampuan, bug, jadwal rilis, dan perilaku rendering yang berbeda.
Electron mengambil kompromi yang berbeda: menyertakan runtime dan menjadikannya bagian dari aplikasi.
Ya, itu membutuhkan ruang penyimpanan.
Namun, hal itu memberi pengembang target yang jauh lebih konsisten di tiga sistem operasi yang sangat berbeda.
Konsistensi memiliki nilai yang sangat besar dalam pengembangan perangkat lunak.
Ketika Electron tidak cukup, Anda tetap dapat menggunakan kode native
Memilih Electron bukan berarti melepaskan akses ke kemampuan native.
Aplikasi Electron dapat menggunakan modul native dan kode spesifik platform jika diperlukan. Artinya, pilihan arsitekturnya sebenarnya bukan:
100% native atau 100% JavaScript.
Untuk banyak produk, model yang lebih baik adalah:
sebagian besar aplikasi menggunakan kode bersama, dengan sedikit kode native di bagian yang benar-benar membutuhkannya karena tuntutan sistem operasi.
Kode native menjadi jalan keluar untuk kebutuhan khusus, bukan fondasi seluruh produk.
Bagi banyak perusahaan, ini merupakan alokasi upaya pengembangan yang jauh lebih baik.
Pengguna peduli pada produk, bukan kerangka kerja
Ada sekelompok kecil pengguna yang paham teknologi yang membuka Activity Monitor, melihat beberapa proses Chromium, dan langsung mengeluh bahwa sebuah aplikasi menggunakan Electron.
Sebagian besar pengguna tidak begitu.
Mereka tidak peduli bahwa Slack menggunakan Electron. Mereka tidak peduli bahwa VS Code dibangun dengan teknologi web. Mereka tidak tahu kerangka kerja apa yang digunakan Claude. Mereka peduli apakah perangkat lunak itu membantu mereka menyelesaikan pekerjaan.
Jika aplikasi terbuka cukup cepat, terasa responsif, jarang crash, dan menyelesaikan masalah pengguna, teknologi implementasinya nyaris tidak terlihat.
Hal sebaliknya juga berlaku. Aplikasi native tidak otomatis menjadi produk yang bagus hanya karena menggunakan Swift atau WinUI.
Perangkat lunak bersaing pada tingkat produk, bukan pada tingkat kerangka kerja.
Optimalkan perusahaan, bukan hanya berkas binernya
Electron memiliki biaya yang nyata. Electron menggunakan lebih banyak ruang penyimpanan. Kebutuhan memori dasarnya biasanya lebih tinggi daripada aplikasi native kecil. Tentu ada produk yang membuat biaya-biaya tersebut menjadikan Electron pilihan yang salah.
Utilitas kecil di bilah menu mungkin tidak membutuhkan Chromium. Driver perangkat jelas tidak membutuhkannya. Game, perangkat lunak audio profesional, dan aplikasi yang sangat sensitif terhadap latensi memiliki kebutuhan yang berbeda. Dan jika produk Anda hanya akan berjalan di satu sistem operasi, pengembangan native menjadi jauh lebih mudah dibenarkan.
Namun, sebagian besar perangkat lunak desktop modern tidak termasuk dalam kategori-kategori tersebut.
Perangkat lunak itu terdiri dari antarmuka kompleks yang terhubung ke layanan cloud. Perangkat lunak itu harus berjalan di Windows dan macOS, dan semakin banyak pengguna juga mengharapkan dukungan Linux. Perangkat lunak itu harus terus berkembang. Perangkat lunak itu bersaing dengan produk yang merilis perubahan setiap minggu. Dan biasanya, perangkat lunak itu dibangun oleh perusahaan dengan jumlah pengembang yang terbatas.
Untuk produk-produk tersebut, produktivitas pengembang merupakan bagian dari kinerja aplikasi.
Electron memungkinkan perusahaan merekrut dari kelompok talenta yang jauh lebih besar, berbagi pengembang antara web dan desktop, memelihara satu aplikasi utama alih-alih beberapa aplikasi, memanfaatkan kembali ekosistem JavaScript, merilis fitur secara lebih konsisten di berbagai sistem operasi, mendukung Linux dengan biaya yang tanpa Electron sering kali sulit dibenarkan, serta meluangkan lebih banyak waktu pengembangan untuk menyempurnakan produk alih-alih memelihara implementasi paralel.
Anda dapat dengan mudah mengukur biaya Electron dalam megabita.
Biaya pilihan alternatif lebih sulit terlihat. Biaya-biaya itu muncul dalam bentuk pengembang tambahan, implementasi yang diduplikasi, siklus rilis yang lebih panjang, bug spesifik platform, kesulitan perekrutan, sekat-sekat organisasi, pengguna Linux yang tidak didukung, dan fitur yang membutuhkan waktu berbulan-bulan lebih lama untuk tersedia bagi semua orang.
Biaya-biaya itu tidak muncul di Activity Monitor.
Namun, bagi perusahaan yang membangun perangkat lunak, biaya-biaya tersebut bisa jauh lebih besar.
Tujuan pengembangan perangkat lunak bukanlah menghasilkan berkas biner terkecil.
Tujuannya adalah membangun produk terbaik yang dapat dirilis, dipelihara, dan terus disempurnakan oleh organisasi Anda.
Untuk kategori aplikasi desktop yang ternyata sangat luas, Electron tetap menjadi salah satu cara paling efisien untuk mencapai tujuan tersebut.