Semua orang menyuruh kami memakai Electron. Tulis sekali, jalan di mana-mana. Bergerak cepat. Kami melakukan sebaliknya — SwiftUI di Apple, Jetpack Compose di Android, C++/WinRT di Windows, Metal dan Vulkan mentah di tempat kami butuh piksel tepat waktu. Inilah yang kami pelajari dari membangun empat klien native untuk satu produk.
Jalan mudah vs jalan yang benar
Ketika Anda bilang sedang membangun aplikasi remote desktop dari nol pada 2024, pertanyaan pertama selalu: “Kenapa tidak pakai Electron saja?”
Pertanyaan yang wajar. Electron menenagai beberapa aplikasi tersukses di planet ini — VS Code, Slack, Discord, pembungkus desktop Figma. Ia memungkinkan Anda menulis sekali dan merilis di mana-mana. Developer web Anda menjadi developer desktop dalam semalam. Keunggulan time-to-market-nya nyata.
Kami melihat angkanya, menimbang kompromi, dan memilih jalan tersulit yang mungkin: sepenuhnya native di setiap platform. SwiftUI di iOS dan macOS. Jetpack Compose di Android. C++/WinRT di Windows. Metal untuk rendering di Apple. Vulkan di semua yang lain. Server Go kustom di intinya.
Bukan karena kami menikmati penderitaan, meski beberapa hari terasa begitu. Tetapi karena untuk aplikasi jenis ini, native bukan kemewahan. Ia adalah syarat.
Pajak Electron itu nyata
Mari mulai dari apa sebenarnya Electron: jendela browser Chromium yang berpura-pura menjadi aplikasi desktop. Itu bukan kritik — itu arsitektur. Dan untuk banyak aplikasi, itu sepenuhnya baik-baik saja.
Tetapi untuk remote desktop? Anda menyiarkan piksel dari komputer lain dan merendernya secara real time sambil menangkap setiap event input dan mengirimnya kembali. Latensi bukan pelengkap. Latensi adalah seluruh produknya.
Inilah yang kami ukur ketika membuat prototipe kedua pendekatan:
- Memori — Klien native dalam keadaan stabil: ~45 MB. Prototipe Electron: ~380 MB. Selisih 8,4× saat idle, sebelum salah satu aplikasi men-decode satu frame pun.
- Cold start — Aplikasi macOS native cold-start di bawah 200 ms. Prototipe Electron butuh 2 sampai 3 detik. Untuk alat yang Anda buka dua puluh kali sehari, itu menumpuk menjadi gesekan sungguhan.
- Baterai — Pada Mac yang berjalan dengan baterai, build Electron menarik daya sekitar 3× lipat saat koneksi idle. Chromium tidak tidur dengan murah.
380 MB itu bukan Electron yang bengkak. Itu Chromium yang menjalankan tugasnya — V8, proses GPU, proses utilitas, seluruh mesin browser. Itu engineering yang mengesankan. Hanya saja engineering yang dirancang untuk masalah yang berbeda.
Frame lebih penting daripada fitur
Remote desktop adalah salah satu dari sedikit kategori aplikasi di mana setiap frame penting. Hilangkan satu frame dan pengguna merasakannya. Tambah 16 ms latensi input dan desainer tidak bisa menggambar kurva yang mulus. Tambah 32 ms dan gamer tidak bisa bermain.
Dengan rendering native, kami berbicara langsung ke GPU. Di platform Apple, VideoToolbox memberi kami akses langsung ke decoding video perangkat keras. Kami mengambil frame H.265 dari jaringan, men-decode-nya di perangkat keras, dan menampilkannya — tanpa frame itu pernah menyentuh memori utama. Pipeline decode-ke-tampil berjalan di bawah 4 ms pada Mac modern.
Di Electron, frame yang sama berjalan lewat compositor Chromium, lewat jembatan IPC, dilukis oleh Skia, lalu dikomposisi lagi oleh OS. Setiap hop menambah latensi. Setiap hop menambah jitter. Dan jitter — waktu frame yang tidak konsisten — itulah yang membuat remote desktop terasa janggal bahkan ketika rata-rata FPS tampak baik.
Kami tidak memilih native karena puritan. Kami memilihnya karena fisika masalah kami menuntutnya — sekitar 8 ms pemrosesan di LAN (sisanya adalah ritme refresh 60 Hz layar Anda sendiri), tidak menyisakan ruang untuk browser di tengah.
Buku besar kemampuan native vs web
Perdebatan Electron-vs-native sering terjebak pada firasat. Jadi kami menuliskan tujuh kemampuan OS yang diandalkan Remio setiap detik di setiap sesi dan bertanya dengan lugas: bagaimana nasib masing-masing di setiap runtime?
| Kemampuan | Native | Web / Electron |
|---|---|---|
| Decode perangkat keras 60 fps | ● VideoToolbox / D3D11VA langsung | ○ Lewat WebCodecs, ada jitter |
| Audio USB latensi rendah | ● CoreAudio / WASAPI | — Ter-sandbox, 40 ms+ |
| Pemantauan input keyboard | ● CGEvent / SendInput | — Diblokir di luar fokus |
| Akses GPU Metal / D3D11 | ● Tekstur zero-copy | ○ WebGPU, hop penyalinan |
| Sistem file lokal | ● Penuh, dibatasi oleh OS | ○ Hanya pemilih, ada prompt |
| Multi-jendela, multi-layar | ● Windowing native OS | ○ Shim BrowserWindow |
| Persistensi latar belakang | ● LaunchAgent / layanan | — Ditangguhkan saat disembunyikan |
Setiap baris adalah fitur yang kami rilis hari ini. Setiap — di kolom web adalah solusi darurat yang harus kami ciptakan, dokumentasikan, dan mintakan maaf. Go native berarti kami memperlakukan kemampuan itu sebagai primitif, bukan polyfill.
Kewargaan platform
Ada hal yang jarang dibicarakan kelompok tulis-sekali-jalan-di-mana-mana: pengguna bisa merasakannya.
Mereka bisa merasakan ketika aplikasi tidak menghormati transisi mode gelap sistem. Ketika fisika gulirnya terasa sedikit salah. Ketika aplikasi tidak muncul di Spotlight atau tidak menangani manajemen jendela macOS dengan benar. Ketika menu konteks tampak seperti halaman web alih-alih menu native.
Ini bukan pelengkap. Ini beda antara aplikasi yang ditoleransi orang dan aplikasi yang dicintai orang. Di iOS ini sangat krusial — review App Store akan menolak aplikasi yang terasa tidak native, dan memang sepatutnya.
Dengan SwiftUI, kami mendapat semua ini gratis. Dynamic Type, aksesibilitas VoiceOver, haptik sistem, multitasking di iPad, pintasan keyboard di Mac. Kami tidak mengimplementasi ulang fitur platform. Kami memakainya.
Biayanya juga nyata
Mari jujur tentang sisi buruknya: go native itu mahal. Bukan dalam dolar — dalam waktu dan kompleksitas.
Kami memelihara empat basis kode UI. Lapisan jaringan dan codec kami dipakai bersama (Go untuk signaling, C++ untuk protokol streaming), tetapi setiap piksel yang Anda lihat di layar adalah kode khusus platform. Fitur yang butuh satu hari di Electron membutuhkan tiga sampai lima hari bagi kami, karena kami membangunnya empat kali, disetel untuk tiap platform.
Kami pernah mengalami minggu di mana satu animasi berjalan indah di iOS, rusak di Android, dan tersendat di Windows. Matriks debugging-nya brutal.
Tetapi inilah yang kami pelajari: jalan tersulit dan jalan yang benar sering kali jalan yang sama. Pengguna kami tidak tahu atau peduli soal arsitektur kami. Mereka tahu bahwa Remio terasa cepat, terasa tepat, dan tidak menghabiskan baterai mereka untuk sarapan.
Apakah kami akan melakukannya lagi
Tanpa ragu.
Pendekatan native memberi kami performa yang secara mendasar tidak bisa disamai Electron untuk kasus penggunaan ini. Ia memberi kami aplikasi yang terasa seperti milik tiap platform. Ia memberi kami jejak memori di bawah 45 MB alih-alih 380 MB. Ia memberi kami sekitar 8 ms pemrosesan di LAN (sisanya adalah ritme refresh 60 Hz layar Anda sendiri), sementara pesaing yang dibungkus browser berada di atas 60 ms.
Yang terpenting, ia memberi kami parit teknis. Membangun native di empat platform cukup sulit sehingga sebagian besar pesaing tidak akan melakukannya. Kesulitan itu adalah keunggulan kami.
Kategori remote desktop didominasi aplikasi web berbungkus Electron dan aplikasi native warisan yang tidak diperbarui secara berarti selama bertahun-tahun. Ada ruang untuk sesuatu yang modern sekaligus native — sesuatu yang dibangun dari nol dengan perangkat keras masa kini dalam benak.
Itulah Remio. Dibangun dengan cara yang sulit, karena sebagian hal layak dikerjakan dengan benar.
