8 poin oleh GN⁺ 2026-04-06 | 2 komentar | Bagikan ke WhatsApp
  • Hingga akhir 1980-an, pengembangan aplikasi Windows jelas berpusat pada satu model, Win16/Win32 API, tetapi setelah itu selama beberapa dekade terjadi peralihan platform yang tidak konsisten secara berulang
  • Runtuhnya strategi GUI Windows bukan disebabkan kegagalan teknologi tertentu, melainkan tiga penyebab organisasional: politik antar tim, budaya pengumuman yang berpusat pada konferensi pengembang, dan perubahan strategi tanpa pemberitahuan terlebih dahulu
  • Pada 1988, Programming Windows karya Charles Petzold memberikan jawaban yang jelas tentang “bagaimana membuat aplikasi Windows” dengan satu API tunggal, satu mental model tunggal bernama Win32, tetapi selama 30 tahun setelahnya Microsoft tak pernah berhasil memulihkan kejelasan itu
  • Dari MFC, OLE, COM, ActiveX, WPF, Silverlight, WinRT, UWP, WinUI 3, hingga MAUI, puluhan tahun kekacauan framework GUI terus berlanjut, dan pada tiap inisiatif yang gagal, penyebab utamanya lebih terletak pada kegagalan pengambilan keputusan di dalam organisasi ketimbang cacat teknis
  • Saat ini ada lebih dari 17 teknologi GUI yang benar-benar digunakan di Windows, dan di antaranya, Electron—teknologi GUI desktop yang paling luas didistribusikan—dibuat pihak luar, bukan Microsoft
  • Diagnosis kuncinya adalah: “Jika sebuah platform tidak bisa menjawab pertanyaan 'bagaimana saya harus membuat UI' dalam 10 detik, maka platform itu telah mengecewakan pengembangnya”, dan pada 2026 penilaian ini masih tetap berlaku untuk Microsoft

Microsoft setelah hilangnya strategi GUI yang koheren

  • Selama lebih dari 30 tahun, kekacauan strategi GUI Windows terus berlanjut, sehingga tidak ada jawaban yang jelas untuk pertanyaan, “framework apa yang harus dipakai untuk membuat aplikasi desktop Windows baru?”
  • Pada 1988, ada satu model tunggal yaitu Win16/Win32 API, sehingga pengembang dapat menulis aplikasi dengan satu pendekatan yang sama
  • Dalam beberapa dekade berikutnya, Microsoft gagal mempertahankan platform yang konsisten akibat politik internal, pengambilan keputusan yang berpusat pada demo, dan perubahan strategi bisnis
  • Hasilnya, dari Win32 hingga MAUI, 17 teknologi GUI hidup berdampingan, dan para pengembang harus menghadapi kebingungan di dalam platform yang tidak punya strategi
  • Akar masalahnya bukan kegagalan teknis, melainkan kegagalan organisasional

Era Petzold: masa terakhir ketika semuanya jelas

  • Pada 1988, Programming Windows karya Charles Petzold (852 halaman) adalah satu-satunya jawaban otoritatif untuk Win16 API dalam C, dan itulah yang menjadi strategi pengembangan Windows saat itu
  • Win32 kemudian berkembang lebih besar, tetapi tetap mempertahankan satu mental model berupa message loop, window procedure, dan GDI; Petzold menjelaskannya dan para pengembang bisa mempelajarinya lalu langsung memakainya
  • “Satu OS, satu API, satu bahasa, satu buku” — kejelasan ini adalah sinyal bahwa platform tersebut layak dipercaya

Demam object-oriented (1992–2000): awal dari kompleksitas

  • Pada 1992, MFC membungkus Win32 dengan C++, tetapi kemudian OLE, COM, dan ActiveX muncul, dan arsitektur komponen ini menguasai pengembangan Windows secara luas alih-alih menjadi framework GUI yang koheren
  • Alih-alih menawarkan cerita yang konsisten, Microsoft hanya menyediakan primitif teknologi dan membiarkan pengembang merangkainya sendiri; ini terjadi karena budaya pengumuman yang berpusat pada keynote konferensi lebih memprioritaskan kesan bagi eksekutif daripada keberhasilan pengembang

PDC 2003 Longhorn: visi yang menelan dirinya sendiri

  • Longhorn yang diperkenalkan di PDC 2003 menghadirkan visi yang meyakinkan dengan tiga pilar: WinFS (sistem file relasional), Indigo (komunikasi terpadu), Avalon (UI berbasis XAML dengan akselerasi GPU)
  • Pada Januari 2004, memo internal Jim Allchin menyebutnya sebagai “seekor babi”, dan pada Agustus tahun yang sama diumumkan reset pengembangan total — kembali ke basis kode Server 2003
  • Setelah reset, kepemimpinan menetapkan arahan “managed code dilarang di dalam Windows, semua kode baru harus C++”; WPF memang dirilis bersama Vista, tetapi shell itu sendiri tidak memakai WPF
  • Keputusan ini memicu perang saudara organisasi selama 13 tahun antara tim Windows dan tim .NET, yang akhirnya berujung pada WPF menjadi yatim, Silverlight dihentikan, dan UWP gagal
Iklan

Silverlight: pola yang kemudian terus terulang (2007–2010)

  • WPF dirilis pada akhir 2006, tetapi pada 2007 Silverlight muncul sebagai plugin browser untuk melawan Flash, sehingga investasi pengembangan terpecah
  • Di konferensi MIX 2010, seorang eksekutif Microsoft mengatakan dalam sesi tanya jawab bahwa “Silverlight bukan strategi lintas platform, melainkan strategi Windows Phone” — tim Silverlight sendiri tidak diberi tahu sebelumnya, dan para pengembang yang telah berinvestasi pada aplikasi LOB dengan Silverlight juga baru mengetahuinya lewat sesi Q&A konferensi
  • Akhir Silverlight bukan hasil kegagalan teknis, melainkan pergeseran strategi bisnis, dan pola bahwa pengembang selalu menjadi pihak terakhir yang diberi tahu mulai mengeras pada saat ini

Metro dan perang dua tim (2012)

  • Untuk merespons penjualan iPhone Apple yang mencapai 200 juta unit dan iPad yang mulai menggerus PC, Microsoft meluncurkan Windows 8 dan Metro, tetapi WinRT sengaja dirancang bukan sebagai runtime berbasis .NET melainkan runtime C++ native — hasil langsung dari antipati tim Windows terhadap .NET
  • Di //Build 2012, pengembang secara bersamaan menerima pesan yang saling bertentangan: “masa depan adalah WinRT, HTML+JS adalah warga kelas satu, .NET tetap berjalan, C++ kembali, aplikasi Metro juga bisa dibuat, dan kode WPF lama tetap bisa dijalankan”
  • Pengembang enterprise segera mundur setelah melihat sandboxing UWP, persyaratan distribusi lewat Store, dan tidak adanya banyak API Win32 — “app store tablet itu pada akhirnya tidak pernah terwujud”

Kebingungan UWP dan WinUI (2015–sekarang)

  • UWP (Universal Windows Platform) di Windows 10 membawa visi “tulis sekali, jalankan di mana-mana” untuk PC, ponsel, Xbox, dan HoloLens, tetapi ketika Windows Phone meredup dan aplikasi utama Microsoft sendiri (Office, Visual Studio, shell) tidak memakai UWP, sinyalnya menjadi jelas
  • Jawaban resmi merosot menjadi “it depends”; UWP tetap ada, WPF dipertahankan, XAML Islands muncul, WinUI 3 ditunggu, WinUI 2 hidup berdampingan, Project Reunion dirilis, lalu namanya diganti menjadi Windows App SDK — semua ini makin menambah kebingungan
  • Project Reunion / WinUI 3 memang kemajuan teknis, tetapi keberadaannya sendiri adalah hasil dari masalah organisasional: kontrol UWP terikat pada OS dan tidak dimiliki oleh tim .NET maupun tim alat pengembang
  • Retrospektif seorang pengembang pada 2024: “UAP, UWP, penggantian C++/CX dengan C++/WinRT (tanpa dukungan tool), XAML Islands, XAML Direct, restart Project Reunion, restart WinAppSDK, transisi membingungkan antara WinUI 2.0 dan 3.0… 14 tahun, 14 kali pivot

Kebun binatang tanpa penjaga: daftar teknologi GUI Windows saat ini

Framework native Microsoft:

  • Win32 (1985) — masih dipakai, buku Petzold masih relevan
  • MFC (1992) — mode maintenance, masih tersisa di enterprise dan CAD
  • WinForms (2002) — “bisa dipakai tapi tidak direkomendasikan”, namun masih yang tercepat untuk form input data
  • WPF (2006) — XAML, rendering DirectX, open source, tanpa investasi baru dari Microsoft
  • WinUI 3 / Windows App SDK (2021) — jawaban resmi yang “modern”, tetapi roadmap-nya tidak pasti
  • MAUI (2022) — penerus lintas platform dari Xamarin.Forms, taruhan Microsoft saat ini dari tim .NET

Web hybrid Microsoft:

Iklan
  • Blazor Hybrid — komponen Razor .NET di dalam WebView native
  • WebView2 — menyematkan Chromium ke aplikasi Win32/WinForms/WPF

Pihak ketiga:

  • Electron — Chromium + Node.js, dipakai VS Code, Slack, Discord, dan saat ini merupakan teknologi GUI desktop yang paling luas didistribusikan di Windows, tetapi tidak terkait dengan Microsoft
  • Flutter (Google), Tauri (berbasis Rust), Qt (C++/Python/JS), React Native for Windows (disponsori Microsoft tetapi berbasis teknologi Facebook)
  • Avalonia — penerus spiritual open source dari WPF, diadopsi oleh pengembang yang tidak menunggu Microsoft seperti JetBrains, GitHub, dan Unity
  • Uno Platform — lebih berdedikasi pada WinUI daripada Microsoft sendiri
  • Delphi/RAD Studio, Java Swing/JavaFX — masih bertahan di pasar vertikal dan enterprise

17 pendekatan, 5 bahasa pemrograman, 3 filosofi rendering — ini bukan “platform”

Diagnosis inti

  • Semua inisiatif GUI yang gagal bermuara pada salah satu dari tiga penyebab: politik antar tim (Windows vs. .NET), taruhan platform terlalu dini yang didorong pengumuman konferensi (Metro, UWP), atau perubahan strategi bisnis tanpa pemberitahuan kepada pengembang lebih dulu (Silverlight)
  • Teknologinya sendiri sering kali bagus — WPF bagus, Silverlight bagus, XAML bagus — kegagalan organisasi pada akhirnya menjadi kegagalan produk
  • Tanpa Plausible Theory of Success yang mencakup seluruh siklus hidup “adopsi-investasi-maintenance-migrasi”, yang ada bukan strategi melainkan sekadar keynote konferensi
  • Charles Petzold merevisi Programming Windows hingga edisi ke-6 demi mengikuti hal-hal baru yang diumumkan Microsoft, tetapi setelah edisi ke-6 yang membahas WinRT (Windows 8), ia berhenti menulis

2 komentar

 
iolothebard 2026-04-07

Ujung-ujungnya Win32?!!

 
GN⁺ 2026-04-06
Komentar Hacker News
  • Masalah mendasarnya adalah Microsoft hanya mencoba menyelesaikan konsistensi GUI di lapisan framework
    Mereka terus merilis framework baru seperti WinForms, WPF, UWP, WinUI, lalu pada akhirnya meninggalkannya
    Apple menganggap sistem desain itu sendiri sebagai produk, dan membuat framework tidak terlihat, sementara Microsoft setiap kali mengambil pendekatan sebaliknya

    • Sebagai orang kelahiran tahun 70-an yang sudah menggunakan komputer sejak tahun 80-an, saya hampir menumpahkan kopi saat membaca ini
      Boleh dengar contoh dari sisi Apple juga?
    • Mustahil menerapkan desain Metro, layar sentuh, dan mode gelap sekaligus ke aplikasi Win32 berusia 40 tahun
      Belakangan ini WPF meniru skin WinUI, jadi setidaknya Microsoft memang berusaha
    • Setuju. Namun WinForms masih didukung
      Bahkan di stack .NET terbaru, itu tetap menjadi salah satu jalur resmi
    • Pernyataan “Apple sudah menyelesaikannya” terdengar seperti komentar yang ditulis sebelum Tahoe
    • Komentar yang sangat tajam
  • WinForms masih tetap menarik
    Berkat WebView2, pengembangan aplikasi hybrid jadi lebih mudah, dan meski bisa saja beralih ke web murni, sensasi native chrome terasa lebih baik
    Semua pelanggan menggunakan Windows, jadi tidak ada alasan untuk melawan arus
    Akhir-akhir ini saya membuat asisten AI dengan kombinasi .NET10 + WinForms + WebView2
    Saya bahkan tidak mau membayangkan harus berulang kali mengutak-atik UI riwayat percakapan dengan WinForms murni

  • Saya tidak setuju dengan pernyataan “WPF itu bagus”
    Pada perangkat keras umum di akhir 2000-an, aplikasi WPF itu lambat
    Misalnya Logos Bible Software adalah aplikasi teks sederhana, tetapi tetap menuntut performa grafis, sehingga tersendat di laptop lama
    Belakangan saya tahu Logos 4 berbasis WPF, dan di postingan forum juga ada banyak keluhan serupa

    • Sekitar 2010~2011 saya membuat aplikasi WPF yang kompleks, dan performanya jauh lebih buruk daripada HTML/JS/Blink
      Akhirnya sebagian besar kode kami implementasikan ulang dengan Direct3D/Direct2D
      Arsitektur WPF itulah masalahnya
    • Sekitar 2010 ada kasus Evernote meninggalkan WPF
      Alasannya disebut-sebut karena teks yang buram dan masalah performa
      Tulisan terkait: edandersen.com / Reddit
    • Masalahnya bukan WPF, melainkan Microsoft yang menganggap hardware Intel berperforma rendah itu “cukup memadai”
      Artikel terkait: Ars Technica
    • Ini mirip kasus seperti Tahoe/iOS 26 milik Apple, ketika terlalu banyak menambahkan efek hingga hasilnya berlebihan
    • Dulu WinForms disebut lambat, sekarang posisi itu ditempati Electron
      Pada akhirnya perdebatan soal performa selalu berulang di setiap era
      Apple juga mengalami masalah serupa saat beralih dari AppKit/UIKit ke SwiftUI
  • Saat ChatGPT pertama kali meledak, Bing yang mengintegrasikan versi dengan akses web adalah ide yang jenius
    Namun Microsoft tidak mengerjakan detail implementasi seperti kompresi konteks, sehingga percakapan cepat dibatasi
    Sebaliknya OpenAI, Perplexity, dan lainnya menjalankannya dengan baik, dan sekarang itu sudah menjadi standar
    Seandainya Microsoft melakukannya dengan benar saat itu, mereka mungkin bisa menggantikan Google
    Pada akhirnya masalahnya adalah kurangnya penyelesaian UI/UX, dan saya rasa itu berasal dari tidaknya konsistensi budaya organisasi
    Dulu saya merasa kesal Apple melarang bundling library UI, tetapi memang benar bahwa hal itu ikut menjaga konsistensi UI

    • Meski Apple memblokir library UI, kita tetap bisa merender lewat canvas seperti Flutter atau KMP
      Sebagian besar pengguna tidak peduli
  • Ada pengguna yang terus menyalin-tempel cerita makan malam dengan eksekutif Microsoft, dan intinya adalah “Microsoft all-in ke enterprise
    Namun pada kenyataannya, menurunnya kualitas Windows dan Azure justru membuat perusahaan-perusahaan pergi
    Perusahaan kami juga dirugikan oleh masalah SLA Azure, dan tidak mendapat kompensasi apa pun
    Karena itu kami sedang mengurangi ketergantungan pada Active Directory dan Windows

    • Masalahnya adalah Microsoft terlalu fokus pada perusahaan dan melupakan pengalaman pengguna individu
      Pada akhirnya, pasar enterprise tanpa pengguna itu tidak ada
  • Sejak Win32, Microsoft tidak pernah mendorong satu arah yang sama lebih dari dua tahun
    WinRT sebenarnya lumayan, tetapi setelah Nadella datang dan beralih ke Azure, platform Windows ditinggalkan

    • Sekarang bahkan muncul pertanyaan apakah Microsoft masih perusahaan platform
      Identitasnya mengabur saat berubah dari Windows → Office → Azure
      Office ada di web dan desktop, mereka juga punya hardware dan store
      Visi Satya Nadella tidak tersampaikan dengan jelas
    • WinRT juga kurang bagus secara teknis, dan faktor kegagalan yang lebih besar adalah kebijakan pemaksaan Microsoft Store
      Store itu buruk, dan tidak lebih dari proyek untuk promosi internal
  • Masalahnya memang Microsoft terus merilis framework GUI baru, tetapi aplikasi Win32 masih bisa ditulis
    Microsoft sudah lama mengarahkan strategi ke web, dan juga berkontribusi pada perkembangan teknologi seperti AJAX, Flexbox, Grid
    Saya terutama mengembangkan sistem lintas platform berbasis web·Java·Python
    Tidak ada alasan khusus untuk membuat GUI khusus Windows
    Aplikasi web lebih fleksibel dan lebih mudah diakses

    • Saya mempertanyakan kenapa harus membuat aplikasi khusus Windows
      Web berjalan di mana saja, dan dengan PWABuilder distribusi ke app store juga dimungkinkan
      Saya ikut berkontribusi pada proyek ini, dan kita bisa membuat aplikasi cepat dan ringan tanpa Electron
    • Windows mendukung aplikasi HTML hingga sebelum 24H2
      Kalau melihat dokumentasi Active Desktop, pada masa itu pendekatannya cukup eksperimental
    • Namun UX aplikasi web masih lebih buruk daripada aplikasi native
      Web hanyalah solusi sementara; pengalaman yang benar-benar bagus datang dari native
  • Sekitar 2007 saya pindah dari Delphi ke WPF, tetapi pada 2010 saya sepenuhnya meninggalkan Windows
    Politik internal Microsoft dan seringnya teknologi dibuang sudah keterlaluan
    Saat itu Rails sedang naik daun, jadi cukup mudah untuk beralih

    • Kalau sekarang masih memakai GUI Windows, saya akan tetap bertahan dengan WPF
      Mungkin ini Stockholm syndrome, tetapi Visual Studio juga masih berbasis WPF, jadi saya tidak terlalu khawatir
    • Microsoft punya banyak talenta hebat, tetapi hancur karena kurangnya kepemimpinan dan visi
      Bisa dibilang itu lebih dulu memperlihatkan masalah yang kini terlihat di big tech
    • Meski begitu, VB masih tetap berjalan, jadi tidak sepenuhnya ditinggalkan
  • Steven Sinofsky baru-baru ini menulis tentang topik yang sama
    tautan x.com

    • Lucu melihat Sinofsky mengkritik .NET
      Saat era WinRT dia ada di DevDiv, tetapi tim Windows tidak memahami kebutuhan developer
      Bahkan pernah ada prototipe Python/WinRT, tetapi dibuang dengan alasan “developer hanya menginginkan JS”
      Mereka juga memaksakan gaya Metro sampai menu Visual Studio diubah semua menjadi huruf kapital
      Windows RT bahkan memutus kompatibilitas sehingga hampir tidak ada aplikasinya, dan akhirnya gagal
      Bahkan beberapa klaim teknis Sinofsky juga salah (.NET 3.0 memang sudah disertakan di Vista)
    • Tulisan itu adalah tanggapan terhadap artikel ini, jadi akan ditambahkan tautannya di bagian atas
    • Ada juga yang bertanya apakah ada cara membacanya tanpa lewat x.com
      xcancel.com masih belum mendukung fitur itu
  • Jawabannya jelas — Qt
    Ini bukan lelucon, kalau tidak memakai Electron maka Qt benar-benar alternatif yang nyata
    Bagi Qt, ini adalah bisnis inti, jadi mereka tidak sering mengubah arah