Apa Itu Framework Frontend?

Penjelasan ramah untuk pemula tentang apa itu framework frontend, kenapa mereka ada, masalah apa yang mereka selesaikan dibanding JavaScript biasa, dan kapan kamu memang sebaiknya memakainya.

Diterbitkan 20 September 20268 menit bacaOleh ACY Partner Indonesia
Apa Itu Framework Frontend? — chip kode dengan tag komponen
300 × 250Slot Iklan TersediaPasang iklan Anda di sini

Kalau kamu pernah berada di sekitar dunia pengembangan web, pasti pernah dengar nama-namanya: React, Vue, Angular, Svelte. Orang membicarakannya terus-menerus, dan pada titik tertentu kamu mulai penasaran sebenarnya benda-benda ini apa. Bahasa pemrograman? Pustaka? Semacam sihir? Jawaban jujurnya jauh lebih sederhana daripada kesan yang ramai itu, dan begitu kamu paham, banyak hal di web modern tiba-tiba terasa masuk akal.

Artikel ini membahas konsep framework frontend, bukan salah satunya secara khusus. Kita tidak akan mengajari React atau Vue di sini. Tujuannya adalah supaya kamu pulang dengan paham kenapa alat-alat ini ada, rasa sakit apa yang mereka hilangkan, dan bagaimana mengenali momen ketika memakai salah satunya memang keputusan yang tepat. Pondasi itulah yang nanti membuat framework apa pun jadi jauh lebih mudah dipelajari.

Dulu, apa sih arti “frontend”?

Frontend adalah bagian situs yang berjalan di browser pengguna: tombol, formulir, menu, animasi, dan segala sesuatu yang benar-benar dilihat dan diklik orang. Bagian ini dibangun dari tiga teknologi inti. HTML menyediakan struktur (judul, paragraf, dan kolom isian). CSS mengurus tampilan (warna, jarak, tata letak). Dan JavaScript menambahkan perilaku (apa yang terjadi saat kamu mengeklik, mengetik, atau menggulir layar).

Untuk halaman sederhana, ketiganya sudah lebih dari cukup. Sebuah artikel pendek dengan formulir kontak tidak butuh apa-apa yang rumit. Masalah baru muncul saat halamannya berhenti menjadi sederhana.

Masalahnya: membangun UI interaktif dengan JavaScript biasa

Bayangkan kamu membangun sebuah dasbor untuk perusahaan bernama ACY Partner Indonesia. Dasbor itu menampilkan daftar pengguna, kotak pencarian, penghitung berapa banyak yang sedang online, dan tombol untuk menambah pengguna baru. Setiap kali ada yang berubah, layar harus ikut diperbarui supaya cocok.

Dengan JavaScript biasa, kamu yang bertanggung jawab atas setiap pembaruan itu, satu per satu, secara manual. Kamu cari elemennya di halaman, kamu ganti teksnya, kamu tambah atau hapus item dari daftar, kamu nyalakan kelas tertentu untuk menyorot sesuatu. Tindakan menjangkau langsung ke halaman lalu menulis ulang sebagiannya ini disebut manipulasi DOM (DOM, atau Document Object Model, adalah representasi hidup halamanmu di dalam browser).

Berikut sedikit gambaran seperti apa rasanya, untuk sebuah penghitung saja:

let count = 0;
const label = document.getElementById('count');
const button = document.getElementById('add');

button.addEventListener('click', () => {
  count = count + 1;
  label.textContent = `Online: ${count}`;
});

Itu masih bisa ditangani. Tapi sekarang bayangkan aplikasi sungguhan, di mana angka online tadi muncul di tiga tempat, di mana menambah pengguna juga harus memperbarui lencana “total”, di mana kotak pencarian harus menyaring daftar yang tampil, dan di mana setiap baris punya tombol edit dan hapusnya sendiri. Tiba-tiba kamu menulis lusinan pembaruan manual seperti itu, dan semuanya harus saling cocok. Lupa satu saja, layar akan menampilkan angka yang salah. Di sinilah JavaScript biasa mulai kewalahan.

Akar masalah yang lebih dalam adalah sesuatu yang disebut state (keadaan). State sederhananya adalah “data yang sedang ditampilkan layarmu saat ini”: berapa pengguna yang online, apa yang diketik orang di kotak pencarian, baris mana yang sedang dipilih. Pada pendekatan manual, datamu dan layarmu adalah dua hal terpisah yang harus selalu kamu jaga agar tetap selaras, dengan tanganmu sendiri. Makin besar aplikasinya, makin sulit penyelarasan itu, dan makin banyak bug yang menyusup.

Inti rasa sakitnya dalam satu kalimat

JavaScript biasa memaksamu menjelaskan setiap langkah untuk memperbarui layar, dan menjaga data serta layar tetap selaras dengan tangan sendiri adalah titik di mana aplikasi rumit mulai berantakan.

Ide besarnya: jelaskan apa, bukan bagaimana

Sebuah framework frontend membalik hubungan ini. Alih-alih kamu menulis instruksi seperti “cari label, ganti teksnya”, kamu cukup menggambarkan seperti apa seharusnya tampilan layar untuk data tertentu, lalu framework yang memikirkan cara membuat halaman aslinya cocok.

Inilah perbedaan antara kode imperatif (daftar langkah yang kamu kerjakan) dan kode deklaratif (gambaran hasil yang kamu inginkan). Dengan framework, kamu menulis sesuatu yang lebih mirip: “label-nya harus berbunyi Online: {count}.” Ketika count berubah, framework yang memperbarui label-nya untukmu. Kamu tidak pernah menyentuh DOM secara langsung.

JavaScript biasa (imperatif):
  1. count = count + 1
  2. cari elemen label-nya
  3. setel teksnya jadi "Online: " + count
  4. ...dan ingat untuk melakukannya di setiap tempat count muncul

Framework (deklaratif):
  1. count = count + 1
  2. (layar memperbarui dirinya sendiri di mana pun count dipakai)

Perilaku otomatis “saat data berubah, layar ikut menyusul” ini disebut reaktivitas. Inilah, bisa dibilang, alasan tunggal terbesar kenapa framework ada. Kamu cukup mengelola datamu, dan tampilannya tetap selaras dengan sendirinya.

Komponen: satuan yang menjadi bahan segalanya

Ide raksasa kedua adalah komponen. Komponen adalah potongan antarmuka yang berdiri sendiri dan bisa dipakai ulang, yang membungkus struktur, tampilan, dan perilakunya jadi satu di satu tempat. Bayangkan seperti satu balok LEGO. Sebuah tombol bisa jadi komponen. Sebuah kartu pengguna bisa jadi komponen. Seluruh bilah pencarian bisa jadi komponen. Kamu membuat balok-balok kecil, lalu menyatukannya menjadi halaman.

Kenapa ini sebegitu pentingnya? Karena antarmuka sungguhan terus-menerus mengulang dirinya sendiri. Daftar pengguna di dasbor tadi mungkin menampilkan lima puluh baris yang tampak dan berperilaku sama. Tanpa komponen, kamu harus menyalin-tempel markup yang sama lima puluh kali, dan memperbaiki satu bug berarti memperbaikinya lima puluh kali pula. Dengan komponen, kamu cukup mendefinisikan UserCard sekali lalu memakainya ulang di mana saja:

Halaman
 ├─ SearchBar
 ├─ OnlineCounter
 └─ UserList
     ├─ UserCard  (Jane Doe)
     ├─ UserCard  (John Doe)
     └─ UserCard  (...)

Setiap UserCard menerima datanya sendiri (sebuah nama, email, status) lalu menggambar dirinya sesuai data itu. Ubah desain kartu di satu tempat, dan semua kartu di seluruh aplikasi ikut berubah. Komponen juga membuatmu bisa memikirkan aplikasi besar dalam potongan-potongan kecil, dan itu kelegaan besar buat kepalamu. Kamu bisa memandang SearchBar sendirian tanpa harus menahan seluruh aplikasi di benakmu.

Komponen bisa disusun bertingkat

Komponen bisa bersarang di dalam komponen lain. Sebuah halaman adalah komponen yang tersusun dari komponen-komponen lebih kecil, yang tersusun lagi dari yang lebih kecil. “Pohon” komponen inilah cara framework membuatmu bisa membangun sesuatu yang sangat besar tanpa berubah jadi kekacauan.

Jadi, apa sebenarnya framework itu?

Satukan semua kepingnya, dan framework frontend adalah perangkat alat yang tertata yang memberimu tiga hal: cara membangun UI dari komponen, sistem reaktivitas supaya layar memperbarui diri secara otomatis saat datamu berubah, dan sekumpulan konvensi untuk menata aplikasi yang terus tumbuh agar tidak ambruk oleh beratnya sendiri.

Kamu mungkin juga mendengar kata “pustaka” (library) disebut-sebut di dekatnya, dan garis pemisah antara keduanya memang kabur. Secara longgar, pustaka adalah kotak alat yang kamu panggil saat butuh, sedangkan framework lebih seperti kerangka tempat kamu membangun di dalamnya, di mana ia yang memanggil kodemu pada saat yang tepat. Sebagian alat populer menyebut dirinya pustaka, sebagian menyebut dirinya framework. Bagi pemula, perbedaan istilah ini jauh kurang penting dibanding memahami ide-ide bersama di atas. Komponen dan reaktivitas muncul di semuanya.

Nama-nama besar, secara netral

Kamu tidak perlu memilih favorit hari ini, dan jelas kamu tidak perlu belajar salah satunya untuk memahami artikel ini. Tapi mengenal petanya tetap membantu:

Alat Sifatnya dalam satu baris
React Sangat populer, berbasis komponen, fokus dan luwes; kamu merakit potongan tambahan di sekitarnya.
Vue Ramah dan mudah dimulai, dengan banyak struktur yang sudah disiapkan untuk membantu.
Angular Framework lengkap dan berpendirian kuat, sudah membawakan sebagian besar keputusan untukmu.
Svelte Mengompilasi komponenmu lebih dulu, demi mengirim sesedikit mungkin kode ke browser.

Setiap alat ini adalah pilihan yang masuk akal dan profesional, dipakai oleh tim-tim serius. Mereka berbeda dalam gaya, dalam seberapa banyak yang mereka putuskan untukmu, dan dalam komunitasnya, tapi semuanya berdiri di atas pondasi yang sama: komponen dan pembaruan yang reaktif. Belajar konsepnya lebih dulu membuatmu nanti bisa memilih salah satunya dan langsung merasa nyaman dengan cepat.

Jangan asal pakai framework

Framework itu alat, bukan tanda keseriusan. Memaksakannya pada proyek mungil justru bisa menambah persiapan, menambah berkas, dan menambah hal yang harus dipelajari, melebihi yang sebenarnya dibutuhkan proyek itu.

Kapan kamu sebaiknya benar-benar memakainya?

Framework baru terasa sepadan ketika antarmukanya memang interaktif dan jumlah state-nya bertambah. Berikut patokan kasarnya.

Kamu mungkin tidak butuh framework saat:

  • Halamannya kebanyakan berisi konten: artikel, halaman pendarat, situs profil sederhana.
  • Interaksinya sedikit, tidak lebih dari tautan, satu formulir, atau satu sakelar kecil.
  • Kamu masih belajar dan ingin paham HTML, CSS, dan JavaScript lebih dulu.

Kamu mungkin memang ingin framework saat:

  • UI-nya terus berubah merespons aksi pengguna (pikirkan dasbor, aplikasi obrolan, atau editor).
  • Potongan antarmuka yang sama berulang banyak kali dan harus tetap konsisten.
  • Beberapa bagian layar bergantung pada data bersama yang sama dan harus tetap selaras.
  • Proyeknya besar, akan hidup bertahun-tahun, dan dikerjakan beberapa orang bersama-sama.

Ada kebijaksanaan nyata dalam memulai dari yang kecil. Membangun beberapa halaman hanya dengan JavaScript biasa adalah salah satu cara terbaik untuk benar-benar merasakan masalah yang diselesaikan framework. Ketika kamu sendiri pernah kehilangan satu sore gara-gara layar yang ngotot menampilkan angka yang salah, nilai dari reaktivitas berhenti menjadi sesuatu yang abstrak. Penghargaan yang didapat dengan susah payah itu membuatmu jadi pengguna framework yang jauh lebih baik nantinya.

Rangkuman

Framework frontend, pada intinya, adalah cara yang lebih cerdas untuk membangun bagian situs yang diajak berinteraksi oleh orang. HTML, CSS, dan JavaScript polos sudah sempurna untuk halaman sederhana, tapi mereka meninggalkanmu dengan tugas menjaga data dan layar tetap selaras secara manual, yang berubah menyakitkan begitu aplikasi membesar.

Framework menghilangkan rasa sakit itu dengan dua ide utama. Reaktivitas membuatmu cukup menggambarkan apa yang harus ditampilkan layar untuk data tertentu, lalu menjaga halaman aslinya tetap selaras secara otomatis saat data itu berubah. Komponen membuatmu bisa membangun antarmuka dari balok-balok kecil yang berdiri sendiri dan bisa dipakai ulang, yang tersusun menjadi aplikasi besar tanpa berubah jadi kekacauan.

Alat-alat yang terkenal (React, Vue, Angular, Svelte) sama-sama berdiri di atas pondasi ini dan kebanyakan hanya berbeda dalam gaya serta filosofi. Pakailah salah satunya saat antarmukamu memang interaktif, berulang, atau besar; lewati saja kalau halaman sederhana sudah cukup. Kuasai konsep di sini, dan framework mana pun yang nanti kamu pelajari akan terasa seperti langkah lanjutan yang wajar, bukan tembok penghalang.

Tag:frontendframeworkkomponenjavascriptdasarweb
728 × 90Slot Iklan TersediaPasang iklan Anda di sini

Artikel Terkait

Lihat Semua Artikel

Artikel yang Mungkin Kamu Suka

Sampul Anotasi Tipe dengan cuplikan kode name: string
Frontend / TypeScript

Anotasi Tipe di TypeScript: Memberi Tahu TS Apa yang Kamu Maksud

Pelajari cara memakai sintaks : Tipe untuk memberi anotasi pada variabel, parameter fungsi, dan nilai kembalian di TypeScript, plus kapan anotasi benar-benar dibutuhkan dan kapan TS bisa menebaknya sendiri.

20 Sep 20268 menit baca
Sampul Apa Itu TypeScript dengan chip kode let x: string
Frontend / TypeScript

Apa Itu TypeScript? JavaScript yang Dilengkapi Sistem Tipe

Panduan ramah pemula tentang TypeScript: apa itu, kenapa ada, bagaimana ia menambahkan tipe statis opsional di atas JavaScript, dan bagaimana tipe itu menangkap bug sebelum kode dijalankan.

20 Sep 20268 menit baca
Sampul Array dan Tuple di TypeScript
Frontend / TypeScript

Array dan Tuple di TypeScript: Cara Tepat Memberi Tipe pada Daftar

Pelajari cara memberi tipe pada array dan tuple di TypeScript. Pahami beda string[] dan Array<number>, kapan tuple dengan panjang tetap adalah pilihan tepat, serta peran readonly menjaga data tetap aman.

20 Sep 20268 menit baca
Sampul Class di TypeScript dengan potongan kode class bertipe
Frontend / TypeScript

Class di TypeScript: Field Bertipe, Access Modifier, dan Lainnya

Pelajari bagaimana TypeScript menyempurnakan class JavaScript dengan field bertipe, access modifier, readonly, parameter property, interface, dan abstract class — dijelaskan dengan bahasa yang mudah dipahami pemula.

20 Sep 20268 menit baca
Sampul Decorator di TypeScript dengan code chip @Component
Frontend / TypeScript

Decorator di TypeScript

Pengenalan ramah pemula tentang decorator di TypeScript: apa arti sintaks @sesuatu, di mana kamu menemuinya, contoh sederhana, dan kenapa fiturnya terus berkembang.

20 Sep 20267 menit baca
Ilustrasi sampul Enum di TypeScript
Frontend / TypeScript

Enum di TypeScript: Panduan Santai soal Kumpulan Konstanta Bernama

Pahami cara enum di TypeScript mengelompokkan konstanta terkait dengan nama yang mudah dibaca. Kita bahas enum angka vs string, kapan berguna, dan alternatif union literal.

20 Sep 20268 menit baca