Menggali Tentang React dan JavaScript Di Start Menu Windows 11

Banyak yang bilang kalau penyebab Start Menu Windows itu lambat adalah ⚛️ React, sebuah framework pembuatan web yang terkenal. Bahkan di beberapa cuitan dari mutual saya sendiri mengira kalau Start Menu memang pakai React dan WebView. Tapi apa benar seperti itu?

Dari hasil tracing saya langsung menggunakan laptop Windows. Ternyata Start Menu tidak dibuat dengan menggunakan WebView, tetapi menggunakan React Native untuk Windows. Buktinya ada di screenshot dari Process Explorer yang bisa diunduh sendiri dari situs Microsoft. Pastikan dijalankan dengan privilege Administrator.

Ketika dibuka, cari proses yang bernama StartMenuExperienceHost.exe di filter. Kemudian cari DLL¹ dan urutkan berdasarkan nama. Kalian akan mendapatkan beberapa DLL yang merupakan dependensi dari proses tersebut. Dan ini indikator utama dari framework apa yang dipakai oleh Microsoft di Start Menu Windows 11.

Ternyata React Native. Jadi Start Menu-nya bukan Electron. Bukan WebView2. Tetapi React Native.

Get-Process StartMenuExperienceHost |
 Select-Object -ExpandProperty Modules |
 Where-Object { $_.ModuleName -match 'react|hermes|jsi|v8' } |
 Format-Table ModuleName, FileVersion -AutoSize

React dan React Native

Sebelum kita mulai lebih jauh, kita bahas dulu apa itu React dan React Native. React adalah pustaka JavaScript untuk membangun antarmuka di dalam browser. Anda menulis komponen, state, dan hook, lalu React mengubahnya menjadi HTML dan CSS yang dirender oleh peramban.

React Native memakai cara berpikir yang persis sama (komponen, state, hook) tetapi targetnya bukan halaman web; ia menerjemahkan komponen Anda menjadi widget asli sistem operasi — UIView di iOS, View di Android, atau bahkan XAML di Windows. Singkatnya: React menghasilkan halaman web, React Native menghasilkan aplikasi yang berjalan langsung di atas tombol, label, dan kontrol asli platform meskipun kode yang Anda tulis untuk keduanya terasa nyaris identik.

Keberadaan React Native memudahkan pembuatan aplikasi lintasplatform. Janjinya adalah, satu kode untuk semua. Artinya tidak perlu membuat kode untuk masing-masing platform. Cukup satu kode untuk semuanya. Dan kode tersebut adalah kode JavaScript.

Arsitektur dari React Native kurang lebih seperti di bawah ini:

Ada dua "dunia" dari React Native. Satu dunia "React" dan satunya lagi dunia "Native". Bagian yang "React" ini sama sekali tidak native, dan bagian yang native sama sekali tidak ada React-nya. Keduanya direkatkan dengan layer yang disebut JSI alias JavaScript Interface.

JSI inilah jembatan antara React/JavaScript dan dunia native. Berbeda dengan arsitektur sebelumnya, RN sekarang tidak lagi menggunakan marshalling untuk berkomunikasi dengan 'dunia native'. Sekarang JSI langsung memegang referensi native di memori dari widget-widget yang ada di OS tersebut. Jadi React Native tidak berurusan dengan DOM, tetapi dengan komponen native platform yang bersangkutan yang dibungkus dalam komponen React seperti yang saya tulis sebelumnya.

"Jadi masalahnya di mana? Kan tetap native atuh. Artinya tetap kencang, tapi kok dibilang lambat?"

Yes, benar. Tetapi masalahnya bukan di widget. Widget-nya memang native. Masalahnya ada di layer atasnya — yang di diagram itu saya tulis sebagai "JavaScript World".

React Native Bukan Browser, Tetapi Tidak Berarti Tidak Ada Cost Performa

Pertanyaan di atas secara teknis benar, tetapi kurang tepat. Cost performanya bukan di runtime Chromium, tetapi di Event Loop JavaScript. Dari gambar arsitektur React di atas, ada dua bagian: JavaScript World dan Native World.

JavaScript World dan Native World

Di JavaScript World ada tiga komponen:

1. Komponen TypeScript/JavaScript seperti tombol yang biasa ditulis dengan JSX, misalnya <Button>.
2. React. Framework ini tetap melakukan rekonsiliasi view, walaupun tidak berhubungan dengan DOM. React akan melakukan tree-diffing untuk melakukan mutasi di native view.
3. Perubahan/mutasi tadi dikirim ke "Native World" untuk di-render.

Di JavaScript World yang dibangun adalah "React tree". Di sini semuanya dijalankan oleh bytecode interpreter dan garbage collector dalam satu event loop yang dijalankan oleh Hermes.

Setelah itu barulah dikirim melalui JSI ke Native World. Di sini ada layer 'native di atas native' yang ditulis dengan C++ berupa:

1. Yoga Layout, sebuah layout engine buatan Meta yang akan menerima layout dari JSI yang berupa layout 'serupa web' dan akan membangun layout yang cocok untuk platform native-nya.
2. Fabric Renderer yang dokumentasi teknisnya bisa dilihat di sini sebagai petunjuk implementasi dan juga bridge-nya di sini.

Keduanya ditulis dengan C++, yang berarti memang native di platform tersebut. Tetapi ini tetap komponen pihak ketiga karena keduanya ditulis oleh Meta. Jika melihat dari dokumentasi codegen, ternyata masih ada komponen tersembunyi yang ketiga yaitu Turbo Native Modules.

Sekilas Tentang Turbo Native Modules

Ini adalah modul yang jadi lem yang mengintegrasikan JSI sebagai bagian dari arsitektur baru React Native. Awalnya siklusnya dipaksa asinkronus seperti client-server padahal ada dalam satu mesin, seperti ini:

Berubah menjadi proses sebagai berikut yang tidak melalui serialisasi apapun, langsung membaca tipe in-memory, tanpa ada komunikasi melalui JSON.

Di sini sudah bisa kita lihat kalau ada kompleksitas yang terjadi antara React/JavaScript dan Native World. Setelah melewati itu semua barulah diserahkan ke platform untuk kemudian merender widget-widget-nya.

Implementasi React Native di Windows

Setelah melewati itu semua, barulah implementasi yang spesifik platform akan mengambil alih. Di Windows, implementasinya dibuat sendiri oleh Microsoft yang kodenya bisa dilihat di repositori GitHub mereka. Secara umum berikut arsitektur RNW:

Bagian ini sangat menarik karena ada dua renderer. Satunya Fabric (baru) dan satunya lagi Paper (lama). Semuanya ditulis dengan menggunakan C++/WinRT — sebuah projection C++ untuk abstraksi Windows API baru yang berdasarkan COM² dan bukan C ABI.

Karena nampaknya Start Menu dibuat dengan XAML, sebenarnya yang ada di sini adalah compatibility layer sehingga memerlukan DLL lain untuk menghandle XAML. Perjalanan dari <Button title="OK" onClick={fn}> kurang lebih sebagai berikut:

Jadi perjalanannya kurang lebih dari JS → React → JSI → Fabric Shadow Tree → XAML root → XAML composition → native drawing. Panjang sekali. Tetapi ini bukan masalah utamanya — bagian rendering ini sebenarnya cukup cepat walaupun panjang dan tebal sekali pemanggilan fungsinya.

Apa yang Diatasi Hermes/JSI dan Apa yang Tidak

Seperti yang sudah ditulis di atas tentang Turbo Native Modules, JSI menghilangkan beban serialisasi. Tetapi ingat, runtime JavaScript itu single-threaded dan punya garbage collector, sehingga Hermes/JSI tidak bisa menghilangkan semua masalah:

1. JS Runtime itu single-thread. Jadi tidak bisa nambah thread JS baru.
2. Tidak menghilangkan GC.
3. Mengubah interpreter menjadi AOT bytecode (Hermes) dan menjalankan kode native.
4. Mengompilasi komponen React secara AOT.

JS masih jadi bottleneck. Setiap kali Start Menu dibuka, satu core akan sibuk melakukan semuanya — dari membaca deskripsi komponen, mengirim ke runtime, sampai menggambar.

JavaScript di Tombol yang Paling Sering Diklik adalah Kesalahan Besar

Lihat apa yang terjadi ketika kita melakukan klik ke sebuah tombol:

Satu klik harus melewati semua langkah tersebut. Dari user sampai ke JS lalu balik lagi ke native, semuanya harus melewati itu. Belum kalau pas kebetulan Garbage Collector jalan — pasti jadi lebih lambat lagi. Bandingkan jika kita membuat langsung dengan XAML tanpa React:

Sembilan vs lima aktor — dan itu belum termasuk overhead JSI. Di 60Hz, kita punya 16,6ms per frame. C++/WinRT mungkin hanya membutuhkan 2–5ms untuk memulai render, sementara RN mungkin perlu 7ms ketika GC tidak jalan. Jadi ada empat cost tersembunyi di balik kemudahan JavaScript yang seharusnya tidak pernah ada di OS shell seperti Start Menu:

1. Rekonsiliasi single-thread. Shadow tree diff dijalankan di JS engine yang single-threaded.
2. Interpreter overhead. Bytecode dispatch, type-check dinamis, dynamic dispatch di setiap object class.
3. Garbage Collection. Sesebentar apapun, GC akan menjadikan CPU naik dan menimbulkan jank.
4. Cold Start. Di awal startup, harus inisialisasi VM JavaScript, mmap bundle JS-nya, menjalankan kode startup-nya, dan mount React tree. Dengan langsung pakai XAML, semuanya bisa di-skip.

Tetapi Microsoft memilih untuk memakai React Native. Inilah yang sebenarnya membuat marah pengguna. Karena Microsoft dan pengembangnya tidak pernah membayar cost ini. Yang membayar semua cost performa itu adalah penggunanya — yang harus beli CPU lebih baik, GPU lebih gahar, dan RAM yang lebih besar di tengah krisis RAM. Karena itulah mengapa banyak keluhan keluar dari forum pengguna dan tech influencer yang sangat kritis dengan kualitas Windows yang makin menurun. Seperti yang dibahas oleh Linus di LTT berikut ini:

Mengapa Microsoft Memilih React Native

Alasan Microsoft sebenarnya pragmatis. Menurut saya ada beberapa hal yang membuat Microsoft memilih menggunakan RN walaupun terasa lambat.

Pertama, berbagi kode dengan web. Halaman login Microsoft Account dan Settings berbagi logic dengan accounts.microsoft.com.

Kedua, hot reload. Perubahan JS bisa tampil dengan cepat karena interpreted, sementara untuk membangun aplikasi C++/WinRT perlu beberapa menit. Pengembang bisa merilis lebih cepat — tetapi pengguna yang membayar runtime cost ini selamanya.

Dan yang terpenting, hiring. Jumlah pengembang React Native, ditambah pengembang React yang bisa di-cross-train ke React Native, tentu saja jauh lebih banyak daripada pengembang C++. Menurut developer survey tahun 2025, JavaScript dan TypeScript masih merupakan tool yang sangat populer.

Loading image...

Masalahnya, profil software seperti OS shell berbeda dengan website maupun aplikasi pada umumnya. Demand untuk menghasilkan feedback instan sangat tinggi.

Masalah UI Framework Microsoft: Framework Graveyard

Selain hal seperti hiring, sebenarnya ada hal-hal lain yang bisa dibilang lebih ke kultural. Microsoft sudah berkali-kali membuat framework baru di 25 tahun terakhir. Dan setiap kali framework baru ada, ternyata tidak mereka kembangkan dan pakai sendiri.

Loading image...

Lihat sendiri timeline-nya. Framework datang dan pergi begitu cepat. Yang paling stabil dan paling jarang berubah mungkin adalah Win32 dan GDI. Sampai detik ini saya masih bisa membuat aplikasi dengan keduanya, tetapi tentunya kompleks.

Dari 11 framework di atas, selama 41 tahun, dari perusahaan yang sama, dengan SDK yang berbeda-beda — Win32, UWP yang mirip tapi lain, WinForms, WPF, WinUI — fragmentasi UI framework Microsoft benar-benar tidak terkontrol. Sebuah sistem operasi yang memperkenalkan GUI untuk masyarakat luas, malah struggling dengan UI framework-nya sendiri.

Sampai pada tahun 2020, Microsoft membuat Project Reunion yang menyatukan Windows App SDK dengan menggabungkan UWP dan Win32, beserta WinUI 3 yang akan jadi XAML framework, dan berhenti memfragmentasi platform.

Tetapi WinUI 3 yang sudah ada di GitHub dengan 7000+ bintang tidak banyak yang pakai. Tidak heran kalau kemudian malah memilih untuk memakai React Native, yang mungkin sudah dikenal di kalangan yang lebih luas. Saking seringnya Microsoft mengkacaukan ekosistem UI framework-nya, pakai React Native saja jadi terasa lebih mudah.

Domenic Denicola, yang sebelumnya mengerjakan Microsoft Edge, menulis di blog-nya tanggal 22 Maret 2026 yang berjudul Windows Native App Development Is a Mess. Yang saya kutip verbatim:

This is probably why large parts of the community have decided to go their own way, investing in third-party UI frameworks like Avalonia and Uno Platform. From what I can tell browsing their landing pages and GitHub repositories, these are better-maintained, and written by people who loved WPF and wished WinUI were as capable. They also embrace cross-platform development, which certainly is important for some use cases.

But at that point: why not Electron? Seriously. C# and XAML are not that amazing, compared to, say, TypeScript/React/CSS. As we saw from my list above, to do most anything beyond the basics, you're going to need to reach down into Win32 interop anyway. If you use something like Tauri, you don't even need to bundle a whole Chromium binary: you can use the system webview. Ironically, the system webview receives updates every 4 weeks (soon to be 2?), whereas the system .NET is perpetually stuck at .NET Framework version 4.8.1!

It's still possible for Microsoft to turn this around. The Windows App SDK approach does seem like an improvement over the long digression into WinRT and UWP. I've identified some low-hanging fruit around packaging and deployment above, which I'd love for them to act on. And their recent announcement of a focus on Windows quality includes a line about using WinUI 3 more throughout the OS, which could in theory trickle back into improving WinUI itself.

Terasa betul frustrasinya. Dan satu lagi punchline-nya — kali ini dari Apple. Ketika Apple memilih framework apa yang dipakai untuk aplikasi Apple Music-nya di Windows, mereka memilih native. Daripada memakai Electron seperti Spotify atau React Native, mereka memilih memakai UWP. Bayangkan: Apple Music lebih native daripada Start Menu Windows.

Loading image...

Jika Anda mencoba memakai Apple Music di Windows, aplikasinya terasa lebih kencang dan snappy.

Setelah kita paham soal framework graveyard, pemilihan React Native jadi masuk akal — dan mungkin jadi masalah yang inevitable karena kelakuan Microsoft sendiri. Bayangkan kita adalah hiring manager di tahun 2020. Pilihannya adalah:

1. Hire WinUI 3 engineers. Tidak ada orang yang pakai WinUI 3. Tooling masih terfragmentasi. Microsoft harus menghabiskan waktu setidaknya satu tahun untuk onboarding ke stack yang bahkan Microsoft sendiri tidak memakai secara konsisten.
2. Hire WPF engineers. Ada, tapi menua. Framework-nya juga maintenance mode. Dan memilih legacy code untuk hari ini tentu saja bukan pilihan yang benar.
3. Hire C++, XAML, WinUI, Win32 specialists. Keputusan teknis yang paling benar. Tetapi hiring pool-nya paling kecil. Team-nya akan sangat kecil dan susah sekali untuk di-hire.
4. Hire React engineers. Hiring pool paling besar. Sudah ada React Native for Windows yang Microsoft sendiri implementasi, dan sudah ada di Settings app. Bisa hot-reload. Bisa langsung rilis besok.

Pemenangnya adalah pilihan keempat. Bukan karena technically correct, tetapi karena pilihan utama sebuah organisasi yang tidak punya kepercayaan diri dengan stack-nya sendiri untuk merekrut staff: Saking parahnya Microsoft memfragmentasi platform-nya, ketika dihadapkan pada pilihan untuk merilis tombol yang paling sering diklik, malah pakai React Native — framework yang bahkan tidak diproduksi Microsoft sendiri.

Akhirnya Microsoft Sadar

Di bulan April 2026, Satya Nadella bilang kalau Microsoft sedang melakukan foundational work untuk "merayu kembali" pelanggan lama supaya kembali ke brand Microsoft: Windows, Xbox, Bing, dan Edge. Yang artinya mungkin Microsoft akan fokus dalam membuat Windows lebih kencang, seperti yang mereka janjikan di blog post mereka. Semoga era framework pihak ketiga di OS dan web-wrapper apps mulai berakhir.

Dikombinasikan dengan kabar bahwa Start Menu akan memakai WinUI, messaging-nya jadi lebih jelas: Microsoft akan memakai framework UI-nya sendiri. Apakah akan sukses dan konsisten? Ya kita lihat saja nanti. Jangan sampai setelah tiga tahun ada yang bikin "Next Generation UI Framework" lagi.

Loading image...

Kuburan UI framework Microsoft masih penuh. Orang belum lupa apa yang Microsoft lakukan terhadap UI framework mereka sendiri. Sampai Microsoft membuktikan sendiri, kita cuma bisa melihat apakah WinUI 3 cuma menunggu masuk lubang kuburan baru yang disiapkan oleh Microsoft.