Mengapa pengembangan aplikasi native Windows berantakan

 (domenic.me)
14 poin oleh GN⁺ 29 hari lalu | 3 komentar | Bagikan ke WhatsApp
  • Ekosistem pengembangan aplikasi native Windows, akibat diskontinuitas framework dan redesign berulang selama puluhan tahun, hingga 2025 masih belum mampu memberikan produktivitas pengembangan yang benar-benar memadai
  • Dari Win32, MFC, WinForms, WPF, WinRT, UWP hingga WinUI 3, meski sudah melewati 7 tahap evolusi framework UI, masih banyak kasus di mana bahkan fungsi dasar pun tidak bisa diimplementasikan hanya dengan API terbaru
  • Fitur sehari-hari seperti ikon tray dan intersepsi shortcut global masih harus bergantung pada pemanggilan Win32 melalui P/Invoke, yang pada akhirnya mengaburkan makna adopsi framework modern
  • Bahkan jika membangun aplikasi utilitas sederhana dengan kompilasi .NET AOT, biner yang dihasilkan tetap melebihi 9 MiB, dan sertifikat penandatanganan kode untuk distribusi MSIX menjadi hambatan praktis dengan biaya tahunan sekitar $200–300
  • Fakta bahwa aplikasi utama Microsoft sendiri seperti VS Code, Outlook, dan menu Start dibuat dengan teknologi web menunjukkan bahwa pengembangan native Windows bukan lagi prioritas, bahkan di internal Microsoft

Latar belakang: apa yang dibuat

  • Dalam proses mengembangkan aplikasi utilitas khusus Windows “Display Blackout”, berbagai masalah lingkungan pengembangan aplikasi native saat ini menjadi terlihat
    • Aplikasi ini menyediakan fungsi mematikan layar samping kiri dan kanan dengan overlay hitam saat bermain game di lingkungan multi-monitor
    • Fitur yang dibutuhkan mencakup enumerasi display, perhitungan batas, penanganan shortcut global, menampilkan ikon tray, auto-run saat startup, dan penyimpanan pengaturan
  • Sudah ada skrip AutoHotkey maupun aplikasi Microsoft Store, tetapi pengembangan dilakukan sendiri untuk tujuan belajar dan peningkatan UI
  • Hasilnya, terkonfirmasi bahwa lingkungan pengembangan aplikasi native Windows sangat kompleks dan tidak efisien

Sejarah pemrograman Windows

  • Pada awalnya, satu-satunya pilihan adalah Win32 API berbasis C, dan API ini masih tetap relevan sampai sekarang
  • MFC berbasis C++ menambahkan abstraksi berorientasi objek seperti class dan template di atas Win32
  • Dengan hadirnya .NET 1.0 (2002), muncul bahasa C#, VM bytecode JIT, manajemen memori otomatis, dan Windows Forms berfungsi sebagai wrapper untuk API jendela dan kontrol Win32
  • WPF di .NET 3.0 (2006) memperkenalkan bahasa markup XAML dan menjadi upaya pertama untuk keluar dari ketergantungan Win32 lewat rendering kontrol berbasis GPU
  • WinRT pada Windows 8 (2012) memperkenalkan model aplikasi sandbox dengan tujuan menyatukan desktop, tablet, dan ponsel, tetapi struktur XAML-nya sedikit berbeda dari WPF sehingga menimbulkan kebingungan
  • UWP pada Windows 10 (2015) sedikit melonggarkan batasan sandbox, tetapi tetap tidak mencapai hak desktop setingkat WPF, dan beberapa fitur OS tertentu seperti push notification, live tile, dan distribusi Microsoft Store dibatasi hanya untuk WinRT/UWP
    • Ini yang menyebabkan aplikasi lama seperti Chrome dan Microsoft Office mengadopsi arsitektur canggung yang menghubungkan aplikasi bridge WinRT/UWP melalui IPC
  • Windows App SDK pada Windows 11 (2021) membuka fitur eksklusif WinRT/UWP untuk aplikasi C++ standar maupun .NET, dan menyertakan library kontrol berbasis XAML baru bernama WinUI 3
  • Ringkasan evolusi framework UI:
    > Win32 C APIs → MFC → WinForms → WPF → WinRT XAML → UWP XAML → WinUI 3

Dilema dalam memilih pendekatan pengembangan

  • Ada tiga jalur untuk mengembangkan aplikasi WinUI 3:
    • C++: biner ramping, interoperabilitas mudah dengan Win32 C API — tetapi tanpa keamanan memori
    • C#/XAML + distribusi bergantung framework: bahkan di Windows 11 terbaru, yang terpasang sebelumnya hanya .NET 4.8.1, sehingga pada instalasi pertama muncul dialog pengunduhan library .NET yang memberi pengalaman pengguna buruk
    • C#/XAML + .NET AOT: seluruh runtime .NET (VM, GC, standard library) dimasukkan ke dalam biner — bahkan aplikasi sederhana menghasilkan biner lebih dari 9 MiB
  • Upaya mempertahankan binding Rust (windows-app-rs) telah diarsipkan
  • Metode distribusi juga sama menyakitkannya untuk dipilih:
    • Format MSIX memerlukan sertifikat penandatanganan kode, yang bagi orang yang tinggal di luar AS menelan biaya tahunan sekitar $200–300
    • Sideload tanpa tanda tangan memerlukan perintah PowerShell rumit yang hanya bisa digunakan dari terminal administrator
    • Pendaftaran ke Microsoft Store ditolak dengan alasan tidak memberikan “nilai yang orisinal dan berkelanjutan”

Fitur yang tetap tidak bisa dilakukan bahkan dengan SDK terbaru

Fitur Dukungan Windows App SDK
Enumerasi display Sebagian bisa (foreach loop tidak bisa, deteksi perubahan perlu P/Invoke)
Menempatkan jendela hitam nonaktif Sebagian bisa (non-activating perlu P/Invoke)
Intersepsi shortcut keyboard global Tidak bisa — perlu P/Invoke
Auto-run saat startup Bisa (tersedia API integrasi pengaturan sistem)
Penyimpanan pengaturan persisten Bisa
Ikon tray + menu Tidak bisa — perlu P/Invoke, gaya menu tidak distandardisasi
  • Gaya menu ikon tray berbeda-beda di tiap aplikasi, dan tidak ada standar yang konsisten di seluruh OS
  • Dalam peralihan dari WPF ke WinUI 3, bahkan fungsi dasar seperti penyesuaian ukuran jendela otomatis justru hilang

Keterbatasan struktural C# dan interop Win32

  • Alat P/Invoke modern CsWin32 memiliki bug yang gagal membungkus string di dalam struct dengan benar
  • Dokumentasi CsWin32 menyatakan bahwa karena C# tidak punya cara idiomatis untuk merepresentasikan tipe parameter dasar Win32 API yaitu [optional, out], metode yang sama dihasilkan dalam dua versi berbeda
  • Kini, 20 tahun setelah rilis WPF (2006), boilerplate untuk menulis class binding UI hampir tidak membaik
    • Semua properti masih harus diubah menjadi pasangan getter/setter, guard nilai yang sama, pemanggilan event trigger, dan kode berulang serupa
    • Solusi di level bahasa yang setara dengan decorator/proxy di JavaScript tidak juga ditambahkan ke C# selama 20 tahun
  • Changelog CsWin32 miskin isi dan masih berada di bawah versi 1.0, sehingga terlihat ada kemungkinan proyek ini ditinggalkan dalam beberapa tahun ke depan

Kesimpulan: mengapa Electron adalah jawabannya

  • Saat ini Microsoft tidak memprioritaskan pengembangan aplikasi native
    • Issue tracker terkait penuh dengan bug dan laporan, tetapi hampir tidak ada respons dari engineer Microsoft
    • Changelog Windows App SDK berfokus pada penambahan API machine learning
  • Fakta bahwa aplikasi utama Microsoft sendiri seperti VS Code, Outlook, dan menu Start dibangun dengan teknologi web memperkuat hal ini
  • Komunitas sedang bergerak ke framework UI pihak ketiga seperti Avalonia dan Uno Platform
    • Keduanya mewarisi filosofi WPF dan memperkuat dukungan lintas platform
  • Untuk saat ini, framework berbasis web seperti Electron atau Tauri adalah pilihan yang lebih realistis
    • Kombinasi TypeScript/React/CSS lebih produktif daripada C#/XAML
    • Akses ke Win32 API juga tetap memungkinkan

    • Taurimemanfaatkan WebView sistem** sehingga** bundel Chromium tidak diperlukan

      • Runtime WebView2 diperbarui setiap 4 minggu, sedangkan .NET sistem tetap terpaku di 4.8.1
      • Peluang pemulihan memang masih ada jika Microsoft mendorong peningkatan Windows App SDK dan penyederhanaan sistem distribusi
      • Namun untuk saat ini, kebanyakan developer tidak menaruh harapan
      • Pada akhirnya, keputusan ditutup dengan kalimat “saya akan memilih web stack”
  • Pengumuman terbaru Microsoft tentang komitmen pada kualitas Windows memang mencakup rencana untuk memakai WinUI 3 lebih luas di seluruh OS, tetapi belum jelas apakah itu akan menghasilkan perbaikan nyata

Bacaan terkait

3 komentar

 
vndk2234 28 hari lalu

Syukurlah sudah dinormalkan dengan Electron...
 
carnoxen 29 hari lalu

Semoga WYSIWYG WinUI 3 segera keluar.
 
GN⁺ 29 hari lalu
Komentar Hacker News

  • Saya juga termasuk yang berpikir bahwa tetap memakai Win32 adalah pilihan yang benar
    Dari sudut pandang orang yang sudah lama mengembangkan dengan Win32, fitur yang dibutuhkan bisa dengan mudah diimplementasikan dalam berkas executable mandiri berukuran di bawah 8KB
    Enumerasi display, pembuatan window, hooking shortcut, pendaftaran startup, penyimpanan pengaturan, menampilkan ikon tray, semuanya bisa dilakukan dengan pemanggilan API yang hanya beberapa ratus byte
    Tetapi menulis proyek baru pada 2026 dengan bahasa yang tidak aman terhadap memori (C++) terasa ketinggalan zaman
    Namun, jika aplikasinya nyaris tidak menerima input yang tidak tepercaya, tidak perlu ikut terpengaruh propaganda semacam itu

    • Jika ingin menghindari masalah keamanan memori dan _UNICODE, Anda bisa membuat hal yang sama dalam setengah waktu dengan .NET Framework
    • Dulu layer tipis seperti Delphi atau MFC menyelesaikan masalah ini, tetapi sekarang masanya sudah lewat dan tidak ada pengganti yang memadai
      Saya rasa gerakan “NoFramework” perlu muncul lagi agar kita kembali ke era RAD
    • Win32 masih punya dokumentasi dan tooling yang kaya, dan akan bertahan lama ke depan
      Tetapi memilih C++ untuk proyek baru tetap harus dipikirkan matang-matang
      Win32 juga bisa dipakai dari bahasa yang aman memori — misalnya windows-rs
    • Saya penasaran bagaimana caranya membuat aplikasi Win32 terlihat bagus di mata pengguna umum
    • Saya juga penasaran bagaimana para pengembang Winamp bisa membuat aplikasi Win32 yang sedemikian bagus
      Pada masa itu Borland Delphi adalah alat yang paling populer

  • Jika bukan aplikasi WinRT, UAP, atau UWP lama, sebaiknya hindari WinUI 3.0 maupun WinAppSDK
    Lebih baik tetap memakai teknologi yang sudah terbukti seperti Win32, MFC, WinForms, dan WPF,
    dan di luar ekosistem Microsoft, Qt, VCL, Firemonkey, Avalonia, Uno, ImGUI layak dipertimbangkan
    WinUI 3.0 kacau sekali sampai-sampai Microsoft sendiri sedang berusaha menyerahkannya ke komunitas sebagai open source

    • Dulu saya pernah membuat aplikasi Windows 8 dengan WinJS lalu menerbitkannya ke Windows Store
      Setelah WinJS berubah menjadi framework web open source, dukungan resminya terputus
    • Baru-baru ini ada pengumuman di blog bahwa mereka akan “memindahkan pengalaman inti Windows ke WinUI3”, katanya untuk peningkatan kualitas, tetapi tetap terasa mengkhawatirkan
      Tulisan blog terkait

  • Saya seorang pengembang embedded, dan membuat program GUI Win32 yang berkomunikasi dengan perangkat masih tetap mudah
    Kode dari era XP tetap berjalan apa adanya di Windows 11, dan proyek VC6 pun bisa dibuka di Visual Studio 2022 lalu dibangun tanpa masalah
    Kompatibilitas mundur seperti ini sulit ditemukan di platform lain

    • Saya justru merasa lebih baik terus memakai kode Win32 yang kasar seperti ini
      Cocoa milik Apple memang tampak “elegan” secara struktur, tetapi pada praktiknya rumit dan dokumentasinya juga kurang ramah
    • Pengembang zaman sekarang sudah terbiasa dengan ekosistem yang berubah setiap minggu, sehingga cenderung menganggap hal lama sebagai sesuatu yang “tidak dirawat”
    • Namun masalah seperti DPI resolusi tinggi atau penanganan input memang masih rumit
    • Tantangan terbesar bagi saya adalah migrasi penuh dari 32-bit ke 64-bit
    • Cara mendefinisikan string terlalu banyak sehingga membingungkan

  • Win32 API murni masih merupakan pilihan yang praktis
    Jika Anda membuat sendiri wrapper mirip MFC di C++, itu bisa selesai dalam 2~3 minggu, dan setelah itu Anda akan punya kendali penuh
    Berkat kompatibilitas mundur yang kuat dari Microsoft, aplikasi berbasis Win32 stabil dalam jangka panjang
    Contoh yang telah diperbarui lebih dari 10 tahun bisa dilihat di sini

    • Dukungan mode gelap adalah masalah terbesar
      Warna sistem dan kontrol di-hardcode sehingga berbenturan dengan tema gelap
      Hanya sebagian UI seperti menu, message box, dan dialog file yang mendukung dark mode, sehingga konsistensinya rusak
    • Pendekatan ini tidak bisa menghasilkan UI bergaya Windows 11
      Diskusi terkait bisa dilihat di artikel ini
    • Dulu saya memakai WTL 3.0, yang jauh lebih ringan daripada MFC dan tetap memberi akses ke seluruh fitur Win32
      Sekarang masih dipelihara sebagai open source, dan bahkan sudah sampai versi 10
    • Jika desain API wrapper bergaya MFC dilakukan dengan baik, AI mungkin bisa menulis implementasinya
    • Ada juga pendapat bahwa lebih baik pakai C++ Builder atau Delphi saja

  • Dari pengalaman membuat beberapa aplikasi Windows,
    (1) Win32 API itu tua tetapi sangat stabil, dan
    (2) toolkit UI milik Microsoft sebaiknya dihindari — pada akhirnya Anda akan tetap membutuhkan kontrol di level Win32

    • Namun WPF dan WinForms adalah pengecualian yang relatif stabil
      Selama 20 tahun terakhir, sebagian besar teknologi UI buatan Microsoft hanyalah variasi dari WPF
      Kalau Microsoft terus mengembangkan WPF, sekarang mungkin itu sudah menjadi standar pengembangan UI

  • Dari sisi pengguna, aplikasi native memang cepat dan bagus, tetapi pengembangannya benar-benar kacau dan rumit
    Ini juga alasan aplikasi seperti Outlook dan Teams makin memburuk

    • Ironisnya, Outlook dan Teams justru mengalami masalah itu karena berbasis webapp (Electron)
      Sulit meniru nuansa native dalam hal fokus, navigasi keyboard, dan sebagainya
    • Saat membuat alat pribadi, saya juga memakai kombinasi TypeScript + Bun + Electrobun
      Lihat proyek Electrobun
    • Bahkan Microsoft sendiri membuat aplikasi dengan Electron, jadi apa lagi yang bisa diharapkan dari pengembang lain

  • Saya tidak setuju dengan pernyataan bahwa “membuat proyek baru dengan C++ adalah kejahatan”
    Untuk GUI, performa dan kontrol lebih penting daripada keamanan, dan C++ tetap bahasa yang sudah teruji
    Qt masih merupakan salah satu framework GUI terbaik pada 2026, dan memiliki fitur keamanan memori bawaan

    • Tetapi Qt hanya benar-benar native pada sebagian distro Linux
    • Aplikasi Qt membutuhkan runtime, jadi sulit disebut native sepenuhnya
    • Tentu saja ini kurang nyaman dibanding lingkungan managed, tetapi di lingkungan embedded tetap berguna

  • Saya heran kenapa runtime .NET modern tidak disertakan secara default di Windows 11
    Ini tampak seperti contoh lain Microsoft telah menyerah pada pengalaman pengguna yang konsisten

    • Karena versi .NET terlalu banyak dan tidak sepenuhnya kompatibel ke belakang,
      mendistribusikan semuanya lewat Windows Update tidak realistis
      Sebagai gantinya, aplikasi bisa didistribusikan sebagai executable mandiri hasil kompilasi AOT (sekitar 9MiB)
      Jauh lebih kecil dan efisien daripada Electron
    • Dulu memang pernah didistribusikan lewat Windows Update, tetapi update kadang merusak aplikasi atau ukurannya terlalu besar sehingga tidak efisien
      Sekarang lebih baik mengemas DLL bersama aplikasinya
    • Setelah .NET 5, model keamanan dan namespace berubah besar-besaran
      Jadi makin sulit untuk membenamkannya ke dalam OS
      Tujuannya agar siklus rilis cepat tetap terjaga dengan memisahkannya dari update OS
    • Saat ini .NET Framework lama disertakan dalam OS,
      sedangkan .NET Core harus dipasang terpisah

  • Setelah lama tidak menyentuhnya, saya baru-baru ini membuat aplikasi untuk Windows dan Mac dengan Tauri
    Pengembangan dan build-nya mudah, tetapi rekan-rekan saya tidak bisa memasangnya karena masalah code signing
    Di Mac bisa disiasati dengan perintah terminal, tetapi di Windows saya harus mematikan Smart App Control
    dan fitur ini tidak bisa diaktifkan lagi tanpa instal ulang
    Saya paham tujuannya untuk keamanan, tetapi saya tidak menyangka proses pemasangannya akan sesulit ini

  • Jawaban untuk pertanyaan “kenapa tidak pakai Electron saja” itu sederhana —
    Aplikasi Electron memberi pengalaman pengguna yang buruk
    Pengembangannya memang mudah, tetapi mengorbankan performa dan kualitas
    Jika ingin membuat produk yang bagus, meski sulit tetap harus memilih native
    Secara pribadi saya merasa C# jauh lebih baik daripada TypeScript