Blazor dari Nol: Bab 1 — Apa itu Blazor?

· 6 menit baca
Blazor .NET Web Development Series
Available in: Bahasa Indonesia · English · Español · Français · Deutsch · Português · 한국어 · 日本語 · Русский · 中文 · العربية · हिन्दी · Polski · Türkçe · Nederlands

Selamat datang di Bab 1 dari Blazor dari Nol. Jika Anda melewatkan posting pengantar di mana saya menjelaskan tujuan seri ini dan untuk siapa ditujukan, mulailah dari sana — singkat.

Dalam bab ini kita akan menjawab pertanyaan mendasar: apa itu Blazor? Terdengar sederhana, namun jawabannya memiliki beberapa lapisan — terutama karena “Blazor” telah memiliki makna yang sedikit berbeda selama bertahun-tahun. Di akhir posting ini Anda akan tahu apa itu Blazor, bagaimana ia masuk ke ekosistem .NET, apa saja model rendering yang berbeda, dan mengapa Anda mungkin — atau mungkin tidak — memilihnya daripada framework JavaScript.

Sejarah singkat

Blazor dimulai sebagai proyek eksperimental Steve Sanderson di Microsoft sekitar tahun 2017. Idenya provokatif: menjalankan C# di browser menggunakan WebAssembly, sepenuhnya menghilangkan kebutuhan akan JavaScript. Ini adalah bukti konsep, dan namanya merupakan penggabungan yang disengaja antara Blazer dan Razor — mesin templating yang akhirnya akan menjadi fondasi Blazor.

Eksperimen tersebut menghasilkan antusiasme yang cukup sehingga Microsoft menganggapnya serius. Blazor dirilis sebagai bagian dari ASP.NET Core 3.0 pada September 2019 — pertama sebagai Blazor Server: model yang menjalankan kode C# Anda di server dan menggunakan koneksi SignalR real-time untuk mendorong pembaruan UI ke browser. Blazor WebAssembly menyusul pada Mei 2020 sebagai bagian dari ASP.NET Core 3.1, membawa eksekusi sisi klien yang sebenarnya ke framework.

.NET 6 dan 7 menyempurnakan pengalaman developer. Kemudian .NET 8, dirilis pada November 2023, secara mendasar memikirkan ulang model rendering dengan apa yang Microsoft sebut full-stack web UI. Rendering sisi server statis, streaming rendering, server interaktif, WebAssembly interaktif, dan mode Auto baru semuanya hidup di bawah satu atap dalam satu proyek. .NET 9 membangun di atas fondasi ini dan memperhalus bagian-bagian kasar.

Itulah posisi kita hari ini.

Apa sebenarnya Blazor itu

Pada intinya, Blazor adalah framework UI berbasis komponen untuk .NET. Anda membangun UI dari komponen — bagian-bagian mandiri dari C# dan markup HTML yang dapat menyimpan state, merespons event, dan disusun menjadi struktur yang lebih besar. Jika Anda pernah bekerja dengan React atau Vue, model mental tersebut akan terasa familiar. Perbedaan utamanya adalah Anda menulis C# alih-alih JavaScript.

Komponen dalam Blazor ditulis dalam file .razor. File .razor memadukan markup HTML dengan kode C# menggunakan sintaks Razor yang mungkin sudah Anda kenal dari view ASP.NET MVC. Begini tampilan komponen sederhana:

@page "/counter"

<h1>Penghitung</h1>
<p>Hitungan saat ini: @currentCount</p>
<button @onclick="IncrementCount">Klik saya</button>

@code {
    private int currentCount = 0;

    private void IncrementCount()
    {
        currentCount++;
    }
}

Tidak ada JavaScript yang terlihat. Direktif @onclick menghubungkan klik tombol ke metode C#. Ekspresi @currentCount merender nilai saat ini. Ketika state berubah, Blazor menentukan apa yang perlu diperbarui di DOM.

Itulah intinya. Semua yang lain — routing, dependency injection, form, panggilan HTTP — dibangun di atas model komponen ini.

Model rendering

Di sinilah banyak kebingungan berada, jadi mari kita tepat. “Blazor” hari ini mengacu pada keluarga mode rendering, bukan model deployment tunggal. Memahami perbedaannya penting karena mempengaruhi performa, kebutuhan infrastruktur, dan apa yang dapat dan tidak dapat dilakukan komponen Anda.

SSR Statis

Mode paling sederhana. Komponen Razor Anda dirender di server menjadi HTML dan HTML tersebut dikirim ke browser. Tidak ada koneksi persisten, tidak ada WebAssembly, dan secara default tidak ada interaktivitas sisi klien. Ini pada dasarnya sama dengan yang dilakukan Razor Pages, tetapi menggunakan model komponen.

Gunakan untuk halaman yang kaya konten, landing page, apa pun yang tidak memerlukan interaktivitas langsung.

Server Interaktif

Kode komponen Anda berjalan di server. Koneksi WebSocket SignalR dibuat antara browser dan server. Ketika Anda mengklik tombol atau mengetik di input, event berjalan melalui WebSocket ke server, C# Anda berjalan, diff dihitung, dan pembaruan DOM dikirim kembali ke browser.

Keuntungan: Akses penuh ke sumber daya server (database, file system, rahasia). Pemuatan awal yang cepat. Ukuran unduhan kecil. Bekerja di browser tanpa dukungan WebAssembly.

Kerugian: Setiap interaksi pengguna memerlukan perjalanan bolak-balik ke server, yang menambah latensi. Sumber daya server berkembang dengan jumlah koneksi aktif. Aplikasi terdegradasi jika koneksi terputus.

Gunakan untuk aplikasi lini bisnis, alat internal, aplikasi di mana akses data sisi server lebih penting daripada kemampuan offline.

WebAssembly Interaktif

Runtime .NET diunduh ke browser dan aplikasi Anda berjalan sepenuhnya di klien. Setelah unduhan awal, aplikasi bekerja sepenuhnya offline dan setiap interaksi instan — tidak ada perjalanan bolak-balik ke server untuk logika UI.

Keuntungan: Eksekusi sisi klien yang sebenarnya. Bekerja offline. Beban server berkurang setelah aplikasi dimuat.

Kerugian: Unduhan awal yang lebih besar (runtime .NET + aplikasi Anda). Pemuatan pertama yang lebih lambat. Anda memerlukan API untuk mengakses data sisi server.

Gunakan untuk aplikasi yang mampu bekerja offline, alat yang memerlukan responsivitas segera, skenario di mana pemrosesan server tidak diperlukan untuk UI.

Mode Auto

Diperkenalkan di .NET 8. Aplikasi dimulai dalam mode Server Interaktif (pemuatan awal cepat, tidak menunggu WebAssembly diunduh). Setelah file WebAssembly diunduh di latar belakang, kunjungan selanjutnya beralih secara otomatis ke mode WebAssembly.

Ini memberi Anda pemuatan pertama yang cepat dari mode Server dan pada akhirnya eksekusi sisi klien penuh dari WebAssembly. Ini adalah model yang paling kompleks untuk dipahami, tetapi merupakan default yang praktis untuk banyak aplikasi.

Mencampur mode dalam aplikasi yang sama

Di .NET 8 ke atas, Anda tidak terkunci pada satu mode rendering untuk seluruh aplikasi. Landing page pemasaran bisa berupa SSR Statis; dasbor yang terautentikasi bisa berupa Server Interaktif; widget visualisasi data bisa berupa WebAssembly Interaktif. Framework menangani transisi.

Dalam seri ini kita akan mulai dengan Server Interaktif karena paling mudah untuk dijalankan dan memiliki model mental yang paling sederhana. Kita akan mengeksplorasi mode lain seiring berjalannya waktu.

Bagaimana Blazor dibandingkan dengan framework JavaScript

Jika Anda telah membangun dengan React, Angular, atau Vue, ini mungkin perbandingan yang Anda ingin ketahui.

Persamaannya nyata. Model komponen Blazor secara sengaja mirip dengan React. Anda memiliki props (Parameter dalam Blazor), state lokal (field dalam blok @code), lifecycle hook, dan pola komunikasi yang sama: data ke bawah / event ke atas. Jika Anda mengenal React, Anda akan merasa familiar dalam beberapa jam.

Perbedaan utamanya adalah bahasa. Dalam Blazor Anda menulis C#. Logika bisnis, aturan validasi, dan model data Anda semuanya dapat dibagikan antara frontend Blazor dan backend ASP.NET Core Anda. Tidak perlu menduplikasi kelas User dalam TypeScript ketika Anda sudah memilikinya di C#.

Kesenjangan ekosistem nyata tetapi menyempit. Ekosistem npm sangat besar. Ekosistem NuGet untuk komponen UI lebih kecil, meski sudah tumbuh secara substansial. Jika Anda memerlukan library charting tertentu atau widget drag-and-drop, JavaScript masih memiliki lebih banyak pilihan. Namun untuk sebagian besar aplikasi lini bisnis, apa yang tersedia di dunia .NET lebih dari cukup.

Interop JavaScript ada ketika Anda membutuhkannya. Blazor memungkinkan Anda memanggil JavaScript dari C# dan C# dari JavaScript. Untuk API browser yang belum memiliki wrapper .NET, atau ketika Anda ingin menggunakan library JS yang sudah ada, interop tersedia. Ini menambah lapisan tetapi tidak menyakitkan.

Jawaban jujurnya: Jika tim Anda seluruhnya terdiri dari developer JavaScript yang membangun produk publik di mana SEO, performa, dan ekosistem npm sangat penting, tetaplah gunakan JavaScript. Jika tim Anda adalah developer .NET, jika Anda membangun aplikasi internal atau lini bisnis, atau jika berbagi kode antara frontend dan backend penting bagi Anda, Blazor adalah pilihan yang meyakinkan.

Yang Anda butuhkan untuk mengikuti

Untuk sisa seri ini Anda memerlukan:

  • .NET 9 SDK — unduh dari dot.net
  • IDE — Visual Studio 2022 (edisi Community gratis), VS Code dengan ekstensi C# Dev Kit, atau JetBrains Rider
  • Kemampuan dasar C# — class, property, interface, async/await

Itu saja. Tidak ada Node, tidak ada npm, tidak ada webpack.

Selanjutnya

Di Bab 2 kita akan membuat aplikasi Blazor pertama Anda, menelusuri struktur proyek, dan memastikan Anda dapat menjalankannya secara lokal. Di akhir Anda akan memiliki aplikasi yang berjalan dan gambaran jelas tentang apa yang dilakukan setiap file.

Sampai jumpa di sana.