Apa yang Dikerjakan Frontend Developer: Panduan untuk Pemula

Pernah kamu klik sebuah tombol di website lalu sebuah menu meluncur terbuka? Atau scroll halaman produk lewat HP, lalu mengisi formulir dan muncul tanda centang kecil yang menyenangkan? Tanpa sadar, kamu sudah melihat hasil kerja seorang frontend developer. Merekalah orang yang membangun bagian aplikasi yang bisa kamu lihat dan kamu sentuh. Semua yang muncul di layarmu pernah lewat tangan mereka.

Tapi kalimat “mereka membangun bagian yang terlihat” itu terlalu pendek, dan menyembunyikan banyak pekerjaan menarik yang butuh ketelitian. Lewat panduan ini kita akan menelusuri apa yang benar-benar dikerjakan seorang frontend developer dalam satu hari biasa, keterampilan apa yang dipakai, dan pola pikir yang membedakan orang yang sekadar bikin tampilan terlihat rapi dengan orang yang bikin tampilan benar-benar berfungsi dengan baik. Kamu tidak perlu sudah bisa coding untuk mengikutinya. Di akhir tulisan, kamu akan punya gambaran utuh soal peran ini, sekaligus bisa menimbang apakah ini terdengar menyenangkan buatmu.

Mengubah desain menjadi antarmuka yang berfungsi

Sebagian besar pekerjaan frontend dimulai dari sebuah desain. Seorang desainer memberikan gambar tentang bagaimana sebuah layar seharusnya tampil, biasanya dibuat di aplikasi seperti Figma. Gambar itu menunjukkan tata letak, warna, jarak antarelemen, jenis huruf, dan susunan semuanya. Anggap saja itu seperti cetak biru.

Tugas pertama frontend developer adalah menerjemahkan cetak biru tadi menjadi sesuatu yang benar-benar bisa dijalankan browser. Gambar tombol bukanlah tombol sungguhan. Developer harus membangunnya ulang memakai tiga bahasa inti web:

• HTML mengatur struktur: ini judul, ini paragraf, ini tombol, ini gambar.
• CSS mengatur tampilan: judul ini berwarna biru tua, tombol ini sudutnya membulat, ada jarak 16 piksel di bawah paragraf ini.
• JavaScript mengatur perilaku: saat tombol ini diklik, buka menunya; saat formulir ini dikirim, periksa apakah formatnya benar.

Bayangkan seperti membangun rumah. HTML adalah rangka dan temboknya, CSS adalah cat dan perabotannya, dan JavaScript adalah listrik yang membuat lampu menyala dan pintu bisa dibuka. Seorang frontend developer bekerja di ketiganya.

Ini contoh kecil yang lengkap. Misalnya desainer minta tombol “Langganan” yang menampilkan pesan singkat saat diklik. Dalam kode, kira-kira begini:

<button id="subscribe">Langganan</button>
<p id="status"></p>

<script>
  const button = document.getElementById("subscribe");
  const status = document.getElementById("status");

  button.addEventListener("click", () => {
    status.textContent = "Terima kasih! Kamu sudah terdaftar.";
  });
</script>

Kecil memang, tapi sudah memuat seluruh idenya: ada struktur (tombol dan paragraf) dan ada perilaku (sesuatu terjadi saat diklik). Satu layar sungguhan bisa berisi ratusan potongan seperti ini yang bekerja bersama, tapi tiap potongnya adalah jenis penerjemahan yang sama, dari gambar menjadi kode yang hidup.

Membangun UI yang bisa dipakai ulang, bukan layar sekali pakai

Saat masih baru, godaannya adalah membangun tiap layar sebagai sesuatu yang berdiri sendiri dari atas sampai bawah. Frontend developer berpengalaman berpikir lain. Mereka melihat sebuah desain lalu menyadari polanya: kartu ini mirip kartu itu, tombol ini sama dengan semua tombol lain, bilah navigasi yang sama muncul di dua belas halaman berbeda.

Jadi alih-alih membangun kartu yang sama dua belas kali, mereka membangunnya sekali sebagai potongan yang bisa dipakai ulang, sering disebut komponen, lalu menempatkannya di mana pun dibutuhkan. Kalau nanti desain kartu itu berubah, mereka cukup memperbarui satu berkas dan semua halaman yang memakainya ikut berubah otomatis.

Ini salah satu pergeseran cara berpikir terbesar dalam kerja frontend. Kamu berhenti berpikir “aku sedang membangun satu halaman” dan mulai berpikir “aku sedang membangun sekumpulan bagian yang bisa kurakit menjadi banyak halaman.” Perbedaannya kira-kira begini:

Sebuah komponen sederhana, ditulis dengan gaya yang umum dipakai, bisa menggambarkan kartu produk yang menerima nama dan harga lalu menampilkannya. Yang penting bukan sintaks persisnya, melainkan idenya: definisikan bagiannya sekali, beri data berbeda, lalu biarkan ia muncul di banyak tempat dengan tampilan yang seragam setiap kali.

type Product = {
  name: string;
  price: number;
};

function ProductCard(product: Product) {
  return `
    <div class="card">
      <h3>${product.name}</h3>
      <p>Rp ${product.price.toLocaleString("id-ID")}</p>
    </div>
  `;
}

UI yang bisa dipakai ulang juga yang membuat tim besar bisa bekerja. Satu developer membangun komponen tombol, yang lain membangun formulir, dan yang ketiga merakit keduanya menjadi halaman pembayaran, tanpa saling berbenturan.

Bikin jalan di mana saja: responsif

Sebuah desain biasanya datang sebagai satu gambar, sering kali berukuran untuk layar laptop. Padahal orang membuka website lewat HP, tablet, laptop kecil, monitor raksasa, dan segala ukuran di antaranya. Tugas frontend developer adalah membuat antarmuka yang sama terasa pas di semuanya. Ini disebut desain responsif.

Responsif bukan berarti membangun website terpisah khusus HP. Intinya membangun satu tata letak yang lentur dan menata ulang dirinya sendiri sesuai ruang yang tersedia. Di layar lebar, tiga kartu produk bisa berjajar bersebelahan. Di HP, tiga kartu yang sama menumpuk jadi satu kolom supaya tidak ada yang terhimpit atau terpotong.

Layar lebar (laptop)          Layar sempit (HP)
+--------+--------+--------+   +----------+
| Kartu1 | Kartu2 | Kartu3 |   |  Kartu 1 |
+--------+--------+--------+   +----------+
                              |  Kartu 2 |
                              +----------+
                              |  Kartu 3 |
                              +----------+

Frontend developer yang baik menguji hasil kerjanya di banyak ukuran layar, bukan cuma di layar yang ada di mejanya. Tata letak yang terlihat sempurna di monitor besar bisa berantakan total di HP: teks meluber dari kotaknya, atau tombol jadi terlalu kecil untuk disentuh. Menangkap masalah seperti ini adalah bagian dari rutinitas harian.

Memikirkan aksesibilitas

Aksesibilitas berarti memastikan antarmukamu bisa dipakai oleh siapa saja, termasuk orang yang menjelajahi web dengan cara berbeda. Sebagian pengguna tidak bisa melihat layar dan mengandalkan screen reader, yaitu perangkat lunak yang membacakan halaman dengan suara. Sebagian tidak bisa memakai tetikus dan berpindah antarbagian sepenuhnya lewat keyboard. Sebagian lagi punya penglihatan terbatas dan butuh teks besar atau kontras warna yang kuat.

Ini bukan urusan kecil yang bisa diabaikan, dan bukan sekadar soal kebaikan hati; di banyak tempat ini juga kewajiban hukum. Kabar baiknya, banyak aspek aksesibilitas sudah ikut beres dengan sendirinya kalau kamu membangun dengan cara yang benar:

• Pakai <button> sungguhan untuk tombol, bukan <div> yang didandani agar mirip tombol. Tombol asli otomatis bisa dioperasikan lewat keyboard dan dikenali dengan benar oleh screen reader.
• Beri tiap gambar yang penting deskripsi teks singkat, supaya orang yang tidak bisa melihatnya tetap tahu isinya.
• Pastikan kontras teks dengan latarnya cukup agar tetap terbaca.
• Pastikan tiap elemen yang bisa diklik juga bisa dijangkau dan diaktifkan hanya dengan keyboard.

Memikirkan performa

Antarmuka yang cantik tapi butuh sepuluh detik untuk muncul tetaplah antarmuka yang bikin jengkel. Performa, yaitu seberapa cepat halaman dimuat dan seberapa mulus ia merespons, adalah bagian nyata dari kerja frontend.

Kamu tidak harus jadi ahli performa sejak hari pertama, tapi lama-lama kamu akan belajar kebiasaan yang menjaga semuanya tetap gesit: tidak mengirim gambar berukuran raksasa kalau yang lebih kecil sudah cukup, tidak memuat kode dalam jumlah besar yang belum dibutuhkan pengguna, dan teliti soal seberapa sering layar harus digambar ulang. Halaman yang lambat membuat pengunjung kabur, jadi pekerjaan ini punya nilai yang langsung terasa dan bisa diukur. Banyak tim memantau angka konkret, misalnya berapa lama konten utama muncul, dan memperlakukan perlambatan sebagai bug yang harus diperbaiki.

Bekerja bersama orang lain

Frontend developer tidak bekerja di ruang tertutup. Peran ini berada tepat di antara desain dan tim teknik lainnya, sehingga komunikasi jadi bagian nyata dari pekerjaan harian.

Dengan desainer, kamu mendiskusikan bagaimana sebuah tata letak harus berperilaku dalam situasi yang tidak terlihat di gambar diam. Apa yang terjadi kalau nama produknya sangat panjang? Seperti apa layarnya saat data masih dimuat? Bagaimana kalau terjadi kesalahan? Desain jarang mencakup semua kemungkinan, jadi kamu bertanya, lalu bersama-sama menambal celahnya.

Dengan backend developer, kamu menyepakati data. Backend adalah bagian sistem yang tidak kamu lihat: ia menyimpan informasi dan mengirimkannya ke frontend saat diminta. Kamu dan backend developer menyepakati bentuk data itu, misalnya field apa saja yang ada di sebuah objek pengguna, supaya antarmukamu tahu persis apa yang harus diharapkan.

// "Bentuk" yang kamu dan backend sepakati akan dikirim oleh API
type User = {
  id: string;
  name: string;
  email: string;
  isPremium: boolean;
};

Begitu kalian sepakat soal bentuk ini, kamu sudah bisa membangun antarmuka yang menampilkan seorang pengguna bahkan sebelum data aslinya ada, yaitu dengan memakai data contoh buatan. Inilah kenapa kesepakatan yang jelas begitu penting: ia memungkinkan kedua pihak bekerja paralel, bukan saling menunggu.

Keterampilan dan pola pikir

Mari kita rangkum. Pondasi teknisnya adalah HTML, CSS, dan JavaScript, lalu ditambah TypeScript (versi JavaScript yang lebih ketat dan lebih aman) serta sebuah framework seiring kamu berkembang. Tapi keterampilan teknis cuma separuh ceritanya.

Separuh lainnya adalah cara berpikir:

• Teliti pada detail. Tombol yang melenceng empat piksel, atau efek hover yang terasa lamban, justru hal-hal seperti itu yang diperhatikan dan diperbaiki seorang frontend developer.
• Empati pada pengguna. Kamu terus bertanya “apakah ini jelas? apakah ini mudah? apa yang terjadi kalau seseorang melakukan hal yang tak terduga?”
• Nyaman dengan iterasi. Versi pertamamu jarang jadi versi terakhir. Kamu membangun, menguji, menyesuaikan, lalu menguji lagi.
• Rasa ingin tahu. Web terus berubah, dan orang yang menikmati pekerjaan ini biasanya juga menikmati proses belajar yang berjalan terus.

Rangkuman

Seorang frontend developer membangun bagian aplikasi yang bisa kamu lihat dan pakai, dan pekerjaannya jauh lebih kaya daripada kesan awalnya. Dalam satu hari biasa, mereka mengubah gambar dari desainer menjadi antarmuka nyata yang berfungsi memakai HTML, CSS, dan JavaScript. Mereka membangun komponen yang bisa dipakai ulang alih-alih layar sekali pakai, supaya produknya tetap seragam dan mudah diubah. Mereka membuat antarmuka menyesuaikan diri ke setiap ukuran layar, bisa dipakai siapa saja termasuk orang yang menjelajah dengan cara berbeda, dan cukup cepat agar pengunjung betah.

Di sekeliling semua itu, mereka bekerja erat dengan desainer untuk menangani kasus yang luput dari desain diam, dan dengan backend developer untuk menyepakati data yang akan ditampilkan antarmukanya. Pekerjaan ini menghargai ketelitian, empati pada orang di seberang layar, dan kemauan yang konsisten untuk terus belajar. Kalau membentuk sesuatu yang langsung disentuh orang terdengar memuaskan buatmu, frontend adalah tempat yang benar-benar bagus untuk mengarahkan rasa ingin tahumu, dan kamu bisa memulainya cukup dengan sebuah browser dan keberanian untuk bereksperimen.