FlowingDev

C# Playground, dijelaskan: memboyong seluruh .NET runtime ke browsermu

Cari tahu gimana WebAssembly membawa compiler Roslyn dan .NET runtime betulan ke browsermu, menyulap web jadi C# playground native.

Coba tool-nya: C# Playground

Dalam satu kalimat

Ini adalah kekuatan penuh dari bahasa pemrograman C#, compiler Roslyn, dan .NET runtime, yang diteleportasi seutuhnya ke web browser-mu menggunakan WebAssembly—bikin kamu bisa nulis, ngejalanin, dan ngompilasi code jadi DLL betulan tanpa perlu nginstall IDE bergiga-giga.

Masalah yang diselesaikan

Secara historis, nge-dev C# itu definisinya "berat banget". Lahir di awal 2000-an sebagai jawaban elegan Microsoft buat Java, C# tuh terikat erat sama ekosistem Windows. Kalau kamu mau bikin script C# singkat atau ngetes gimana behavior suatu query LINQ, kamu nggak bisa sekadar buka terminal. Kamu harus buka Visual Studio (bisa ditinggal ngopi dulu pas splash screen di-load), bikin project baru, ngasih nama ngasal yang bakal disesali kayak ConsoleApp42, nunggu package NuGet selesai ke-restore, nulis code lima baris, jalanin, dan pada akhirnya ngehapus folder itu lagi.

Microsoft merevolusi hal ini dengan meng-open-source-kan .NET, bikin dia jadi cross-platform, dan ngenalin .NET CLI. Tapi tetep aja, kamu masih harus download dan nginstall SDK yang segede gaban cuma buat nge-compile "Hello, World" doang.

Sebagai developer, kita haus akan feedback loop yang instan. Kita pengen bikin prototype algoritma, ngecek sintaks, dan nge-reproduce bug tanpa ribet. Kita butuh sebuah sandbox. Tapi buat bahasa statically typed dan di-compile kayak C#, bikin sandbox betulan di web biasanya berarti kita ngirim code-nya ke remote backend server, di-compile di sana, dijalanin di dalam container Docker, lalu ngirim output teksnya balik ke browser. Pendekatan kayak gitu lelet, mahal buat di-host, dan butuh koneksi internet terus-terusan.

C# playground nyelesaiin ini dengan mengeliminasi server sepenuhnya. Dia ngebawa compiler dan runtime langsung ke client, menyulap browser-mu jadi development environment super ngebut yang ephemeral (sementara).

Gimana cara kerjanya di balik layar

Ngejalanin C# secara native di web browser emang kedengarannya kayak ilmu hitam, tapi ini sebenernya adalah kombinasi elegan dari dua pencapaian engineering yang masif: WebAssembly dan Roslyn Compiler.

WebAssembly Runtime

WebAssembly (Wasm) adalah format instruksi binary yang didesain sebagai target kompilasi portable buat web. Ini bikin bahasa kayak C, C++, dan Rust bisa jalan di browser dengan kecepatan near-native (nyaris secepat aslinya).

Buat bikin C# jalan di browser, Microsoft nggak nulis ulang C# pakai JavaScript. Alih-alih gitu, mereka ngambil .NET Runtime (secara historis pake runtime Mono, sekarang disatukan di bawah .NET Wasm) dan nge-compile core C/C++ nya ke WebAssembly. Pas kamu nge-load C# playground, browser-mu men-download dotnet.wasm. Ini adalah .NET Virtual Machine yang berfungsi penuh dan jalan langsung di dalam engine V8 (atau SpiderMonkey, atau JavaScriptCore) milik browser-mu.

Roslyn: Compiler as a Service

Sebelum .NET runtime bisa ngeksekusi code-mu, code itu harus di-compile dari C# yang bisa dibaca manusia menjadi Microsoft Intermediate Language (MSIL, atau disingkat IL).

Masuklah Roslyn. Nggak kayak compiler zaman dulu yang bertindak kayak black box (source code masuk, executable keluar), Roslyn dibangun dari nol pakai C# dengan sekumpulan API yang kaya. Dia adalah "Compiler as a Service." Karena Roslyn ditulis pakai C#, dan kita punya .NET runtime yang dieksekusi di browser lewat Wasm, kita beneran bisa jalanin compiler Roslyn di dalam browser.

Pipeline Eksekusi

Pas kamu ngetik code di playground dan mencet run, inilah yang terjadi seutuhnya di dalam memori mesinmu:

  1. Parsing: Compiler Roslyn yang ada di dalam browser mem-parsing teks mentahmu jadi Syntax Tree.
  2. Compilation: Roslyn nge-compile Syntax Tree tersebut jadi in-memory assembly (IL bytecode).
  3. Execution: .NET Wasm runtime di browser me-load in-memory assembly ini dan mengeksekusi instruksi-instruksi IL. Standard output (kayak Console.WriteLine) bakal di-intercept dan disalurkan ke layarmu.

Mengekspor DLL

Karena Roslyn melakukan kompilasi standar yang riil, in-memory assembly yang dihasilkan itu secara fungsi identik dengan file .dll yang ada di desktop-mu. Playground bisa dengan mudah ngambil byte array dari memori itu dan nge-trigger download di browser. Kamu nggak dapet DLL "jadi-jadian"; kamu dapet .NET library standar yang di-compile oleh engine resminya, siap buat ditaruh ke server, game Unity, atau aplikasi desktop.

Cerita dari dunia nyata

Perdebatan "Bakal ke-compile nggak nih?"

Dua developer lagi asik-asiknya review pull request. Satu orang bersikeras kalau pakai kombinasi spesifik antara pattern matching C# 12 dan switch expression bakal ngeluarin compiler error gara-gara unreachable code; yang satu lagi sumpah-sumpahan kalau itu sintaks yang valid. Dua-duanya nggak mau kena context-switch, nge-stash local git changes mereka, lalu bikin branch tes yang baru. Alih-alih gitu, mereka nge-paste snippet tersebut ke C# playground di browser. Dalam tiga detik, code-nya sukses ke-compile, ngeluarin output yang bener, dan menyelesaikan taruhan itu secara instan. Pelajaran yang diambil: Cara paling cepet buat mengakhiri perdebatan tentang semantik bahasa adalah pakai feedback loop yang instan dan tanpa halangan.

Builder DLL jalur sat-set

Seorang konsultan lagi kerja pakai laptop klien yang di-lock dan nggak punya akses administrator buat nginstall .NET SDK. Dia butuh banget nulis fungsi utility kecil buat mem-parsing format log internal, yang nantinya bakal dipakai sama aplikasi utama mereka (yang kebetulan support drag-and-drop plugin DLL). Daripada nunggu tiga hari buat tiket helpdesk IT masangin Visual Studio, konsultan ini buka C# playground, nulis logika parsing-nya, ngekspor DLL yang udah di-compile, lalu naruh filenya langsung ke folder plugin aplikasi tersebut. Pelajaran yang diambil: Pas browser punya compiler betulan, dia bisa jadi build server yang sangat mumpuni buat ngelewatin batasan-batasan mesin lokal.

Interview via sandbox

Seorang tech lead lagi ngejalanin technical interview jarak jauh. Alih-alih maksa si kandidat buat screen-share setup IDE yang lelet atau berhadapan sama latency remote desktop, mereka berdua masuk ke sesi C# playground bareng. Si kandidat bisa nyusun query LINQ yang kompleks dan ngetes struktur data object-oriented dengan feedback real-time, ngebuktiin skill mereka tanpa perlu stres mikirin konfigurasi environment. Pelajaran yang diambil: Sandbox murni yang terbebas dari setup environment memisahkan kemampuan coding murni developer dari skill system administration mereka.

Kesalahan umum dan jebakannya

  • Ngira kalau kamu punya file system betulan: Kamu bisa pakai kelas-kelas System.IO, tapi kamu lagi berinteraksi sama file system virtual nan ephemeral yang disediain oleh environment WebAssembly. Kalau kamu nulis file ke C:\temp\log.txt, filenya hidup di memori browser dan langsung lenyap begitu kamu nge-refresh halaman.
  • Manggil library native OS: Nyoba pakai Platform Invocation Services (P/Invoke) buat manggil Windows API native kayak [DllImport("user32.dll")] bakal gagal dengan konyol. Sistem operasimu sekarang adalah web browser; library desktop native nggak eksis di sini.
  • Pikir ini high-performance cluster: WebAssembly itu cepet, tapi dibatasi secara ketat dalam sandbox browser dan sering kali limitasi memorinya kecil serta kapabilitas threading-nya terbatas. Playground itu luar biasa keren buat ngetes logika, tapi payah banget buat ngejalanin proses paralel Parallel.ForEach ke dataset sebesar dua gigabyte.
  • Jebakan async void: Pas nulis script singkat, kita gampang banget lupa kalau Main harus me-return async Task kalau kamu lagi nge-await sebuah operasi. Pakai async void di dalam sandbox bisa bikin runtime matiin execution context sebelum task asynchronous-mu beneran kelar, ujung-ujungnya bikin silent failure (gagal tapi nggak ada error yang keliatan).
  • Lupa assembly reference: Kalau kamu nyoba ngekspor DLL, inget kalau code-mu di-compile pakai base class library yang disediain di dalam sandbox. Kalau kamu ngandelin package NuGet third-party yang belum di-load ke dalam konteks Roslyn si playground, code-mu nggak bakal mau di-compile.

Kenapa ini wajib masuk radarmu

Kamu mending buka C# playground tiap kali beban mental atau fisik ngebuka full IDE itu jauh lebih gede ketimbang tugas yang pengen kamu kerjain. Ini tool yang paling perfect buat nyoba-nyoba fitur bahasa baru (kayak ngeksplor primary constructor atau collection expression di rilis C# terbaru) tanpa perlu nge-upgrade local toolchain-mu.

Ini juga aset yang sangat berharga buat nge-share contoh code yang bisa di-reproduce. Kalau kamu nemu bug di open-source library atau mau nanya di StackOverflow, ngasih link ke playground yang nunjukin persis behavior-nya dan bisa langsung dites itu bakal jauh lebih ngebantu ketimbang nge-paste teks sejibun terus berharap orang lain nge-setup environment-nya dengan bener. Terakhir, kemampuan buat ngekspor .dll betulan dengan mudah bikin ini jadi tool kompilasi zero-install yang powerful banget buat nge-generate plugin ringan dan helper library secara on the fly.

Gali lebih dalam

Teori beres. Saatnya praktik — 100% di browser kamu.

Coba tool-nya: C# Playground