Web Plain Vanilla

 (plainvanillaweb.com)
2 poin oleh GN⁺ 2025-05-12 | 1 komentar | Bagikan ke WhatsApp
  • Penjelasan tentang teknik dasar pengembangan web yang hanya menggunakan HTML, CSS, dan JavaScript
  • Memperkenalkan cara membangun situs dan aplikasi hanya dengan teknologi web standar tanpa build tool dan framework
  • Membahas cara menyusun struktur dan styling dengan memanfaatkan Web Components serta fitur CSS modern
  • Mengejar lingkungan pengembangan yang sederhana dan manfaat jangka panjang tanpa kompleksitas framework dan beban pemeliharaan
  • Tutorial ini terutama ditujukan bagi developer yang sudah mempelajari teknologi standar web

Gambaran Umum Web Plain Vanilla

Ikhtisar teknik utama untuk membuat situs dan aplikasi hanya dengan teknologi web standar tanpa build tool dan framework dalam pengembangan web

  • Menjelaskan lingkungan yang hanya memanfaatkan editor, browser, dan standar web
  • Memperkenalkan struktur yang memungkinkan deployment ke lingkungan produksi tanpa konfigurasi awal dan tanpa logika sisi server

Topik yang Dibahas

1. Komponen (Components)

  • Menjelaskan cara menyusun elemen tingkat tinggi hanya dengan HTML, JavaScript, dan CSS menggunakan Web Components
  • Menunjukkan cara menggantikan pendekatan komponen framework seperti React atau Vue

2. Styling

  • Menjelaskan cara memanfaatkan kekuatan CSS modern untuk menggantikan kemudahan yang disediakan CSS Modules, PostCSS, dan SASS
  • Menawarkan konsep penyusunan style yang terstruktur dan modular, melampaui CSS klasik

3. Situs (Sites)

  • Menjelaskan cara menyusun proyek web berbasis Web Components dan melakukan deployment tanpa build tool atau sisi server
  • Menyajikan workflow deployment yang praktis dan sederhana

4. Aplikasi (Applications)

  • Menjelaskan cara membuat aplikasi web single-page hanya dengan teknik vanilla
  • Menjelaskan metode routing dan manajemen state

Rekomendasi Target Pembaca

Ditujukan untuk developer yang sudah cukup mampu menggunakan HTML, CSS, dan JavaScript

  • Bagi orang yang baru mulai belajar pengembangan web, direkomendasikan jalur pembelajaran dasar seperti Odin Project atau MDN

Mengapa Pendekatan Vanilla

Framework modern memang cepat menyediakan struktur dan fitur yang kuat, tetapi juga disertai peningkatan kompleksitas tool dan framework serta beban pemeliharaan yang berkelanjutan

  • Pendekatan plain vanilla mengorbankan sebagian kenyamanan jangka pendek, tetapi sebagai gantinya menawarkan kesederhanaan dan manfaat jangka panjang berupa nyaris tanpa pemeliharaan
  • Browser masa kini memungkinkan pendekatan ini benar-benar diterapkan berkat dukungan standar web yang sangat baik

Bacaan terkait

1 komentar

 
GN⁺ 2025-05-12
Komentar Hacker News

  • Saya sekarang sudah keluar dari perdebatan "vanila atau framework" dan melihatnya dari sudut pandang, 'apakah ini benar-benar perlu website?'
    Kalau mulai merasa ragu apakah aplikasi web, terutama di ranah B2B SaaS, benar-benar membutuhkan web seperti itu, kita akan menemukan bahwa bisnis bisa berjalan cukup jauh tanpa harus menyentuh browser
    Sebagian besar waktu yang saya habiskan membuat website dan aplikasi sebenarnya terfokus pada UI/UX administratif, yaitu bagian di mana admin mengubah field database agar aplikasi bekerja sesuai ekspektasi pelanggan
    Dalam banyak situasi, jauh lebih cepat, mudah, dan minim pekerjaan sia-sia bila bisnis cukup diberi template konfigurasi (misalnya file Excel), lalu hasilnya langsung dimasukkan atau digabungkan ke tabel SQL
    Web hanya menawarkan satu jenis UI/UX. Email atau file teks biasa justru lebih fleksibel

    • Saya sering melihat perusahaan konsultan digital-first di ranah B2B kehilangan kelincahan karena sibuk membuat web app yang keren tapi tidak perlu
      Terutama ada masalah pembeli seperti instansi pemerintah yang tidak benar-benar paham lalu sering membayar terlalu mahal
      Para pengambil keputusan pembelian perlu lebih diedukasi soal apa yang benar-benar mereka butuhkan
    • Saya menjual guci abu jenazah secara online. Di situs saya hanya ada tautan email. Tidak ada keranjang belanja
      Toko guci abu fisik juga tidak punya keranjang, jadi kenapa toko virtual harus punya
      Saat membeli alat pertukangan kayu khusus secara online pun, saya cukup mengisi formulir lalu menerima komponennya bersama invoice, dan kalau mau saya bahkan tidak perlu membayar lebih dulu
      Baik online maupun offline, ada banyak bentuk perdagangan, dan kalau kita memperhatikan orang-orang yang hidup dengan cara menarik, itu bisa ditemukan di mana-mana
    • Untuk tools internal yang pada dasarnya nyaris tidak lebih dari CRUD, web paling berguna saat dibuat sekali oleh konsultan eksternal atau saat tim internal tidak akan sanggup merawatnya selamanya
      Kalau ada sedikit saja kemampuan maintenance, pendekatan template Excel + skrip kustom sederhana jauh lebih fleksibel.
      Sangat efektif bila pengguna akhirnya memang tipe pengguna yang nyaman berurusan dengan data mentah
    • Sebelum era SaaS, dunia B2B 100% berjalan seperti ini
      Dan sampai sekarang 99% B2B masih mengikuti cara ini

  • Saya bukan anti-framework. Hanya saja, dalam banyak kasus saya merasa itu tidak perlu
    Saya selalu heran kenapa harus menambahkan JS 100KB bahkan sebelum menulis satu baris kode pun
    Bersama tim saya, kami membangun https://restofworld.org tanpa framework apa pun
    Survei, outreach, dan umpan balik email semuanya sangat positif dari sisi kegunaan dan pengalaman membaca
    Mungkin nanti kami bisa memakai framework juga, tetapi sejauh ini vanilla JS masih sangat cocok

    • Komentar ini contoh bagus dari kesenjangan yang selalu muncul dalam diskusi seperti ini
      Di satu sisi ada orang-orang yang membangun web app besar dengan tim 30 orang lebih, dan ketika mendengar "dibuat tanpa framework", mereka langsung mempertanyakan bagaimana fitur-fitur penting skala besar ditangani
      Tetapi jawabannya adalah fitur itu memang tidak dibutuhkan, karena ini penggunaan seperti blog, jadi dari awal memang tidak memerlukan framework
      Sebaliknya, orang yang tidak punya pengalaman dengan web app berskala besar akan berpikir, "kenapa orang memakai framework"
      Web benar-benar kumpulan perangkat lunak yang sangat beragam.
      Jadi menurut saya, saat membahas framework kita harus menjelaskan dengan jelas jenis perangkat lunak apa yang sedang dibicarakan
      Dalam kasus ini, ini adalah blog WordPress
    • Halamannya bagus dan loading-nya juga baik, tetapi ini tidak ada hubungannya dengan pendekatan yang dijelaskan TFA
      Mereka memakai WordPress, sebuah framework besar, dan hanya merendernya secara statis
      TFA membahas pendekatan tanpa build tool sama sekali, hanya memakai standar web modern. Hanya editor, browser, dan standar web
    • "Kenapa harus menambahkan JS 100KB bahkan tanpa menulis satu baris kode"
      Di aplikasi enterprise tempat saya bekerja, kekhawatiran soal 100KB sama sekali tidak relevan
      Kebanyakan adalah aplikasi besar buatan banyak tim, memakai React dan sejenisnya.
      Di Lob/B2B, tidak ada yang peduli pada initial page load
      Pengguna memakai aplikasinya setiap hari, dan sebagian besar aset statis langsung tersedia dari cache browser
      Kalau memakai framework pintar seperti Next.js, konten dipisah per route menjadi chunk immutable
      Render awal adalah HTML statis, jadi dari sudut pandang pengguna, hydrasi pun hampir tidak terlihat
    • Situsnya keren. Saya juga menemukan artikel-artikel bagus
      Tetapi dalam debat vanila vs framework, contoh seperti ini selalu berupa situs berita/artikel, jadi saya merasa "saya memang dari awal tidak akan pakai framework" karena itu bukan aplikasi kompleks
      Pada akhirnya, contoh penggunaan nyata yang dibutuhkan adalah aplikasi yang lebih interaktif
      Akhir-akhir ini saya lebih suka memakai framework dan pola yang konsisten, sambil meminimalkan dependensi lain
    • Salah satu kelebihan struktur ini adalah navigasi mundur/maju di riwayat browser sangat cepat
      Di iPhone, saya sudah terlalu terbiasa melihat saat kembali ke halaman sebelumnya seluruh halaman dimuat ulang
    • Selamat! Menurut saya, memastikan kegunaan adalah yang nomor satu
      Namun para developer sering terobsesi pada loading screen, komponen yang di-hydrate, animasi berlebihan, dan modal yang menjengkelkan hanya demi seru-seruan
    • Saya tidak tahu apakah ini karena tidak memakai framework, tetapi saat navigasi mundur/maju URL berubah seketika namun halamannya tidak ikut diperbarui sehingga tetap berada di artikel yang sama
      Selain itu, infinite scroll membuat saya sulit melacak posisi saya lewat scrollbar, jadi sangat buruk untuk kegunaan
    • Rest of World berjalan sangat cepat bahkan di Australia, dan ini situs berita fantastis yang baru pertama kali saya lihat.
      Pujian karena ikut membangunnya
    • Ini estetika dari WordPress yang menghasilkan halaman statis
    • Sebagian besar framework tidak membutuhkan JS 100KB
      Mithril misalnya bisa memberikan semua itu hanya dalam 10KB gzip
    • Masalah dengan contoh-contoh vanila adalah halaman-halamannya terlalu sederhana dan UX-nya hanya berisi hal-hal dasar
      Kalau membayangkan harus mengimplementasikan sendiri tabel reaktif dengan pencarian, form dengan label, validasi, dan error yang rapi, padahal saya bisa memakai library UI Svelte dan produk tervalidasi yang bagus dengan overhead 25KB, kenapa harus membuat semuanya sendiri
    • Gambar utamanya lebih dari 200KB, jadi debat 100KB tidak berarti
      Dan WordPress juga adalah framework
      Memakai framework juga tidak membuatnya lambat. WordPress atau apa pun
    • Ini contoh bagus dari kegemukan web modern
      Terlalu cepat
    • Benar-benar cepat!
    • Saya sangat suka Rest of World
    • "Kenapa harus menambahkan JS 100KB"
      Untuk produktivitas developer, setidaknya secara teori.
      Dalam praktiknya, sering kali tidak terlalu membantu
    • Situsnya benar-benar cepat. Saya pernah melihat jurnalisme seperti ini sebelumnya
      Saya penasaran apakah pendekatan ini punya kelemahan tajam tertentu
    • Apa? Itu tidak mungkin
    • Tidak ada yang peduli pada 100KB

  • Saya sedang mengembangkan sistem untuk sekitar 2.000 pengguna, dan mereka sama sekali tidak peduli dengan UI reaktif
    Pendekatan terbaik adalah membuat monolit, tidak usah memikirkan page refresh, dan fokus saja pada penyelesaian pekerjaan

    • Sebagai bantahan, banyak aplikasi desktop lama pada akhirnya pindah ke web
      Motivasinya sebagian besar bukan teknis, melainkan karena distribusi aplikasi native terlalu mahal
      Web menyediakan standar distribusi aplikasi dengan murah, tetapi teknologinya untuk UI masih buruk
      Dulu ada berbagai upaya setengah matang seperti X11, Java, Flash, dan saya berharap suatu hari ada cara yang lebih nyaman untuk mengembangkan web app
    • Hanya dengan CSS @view-transition pun transisi halus sudah bisa dilakukan
      https://developer.mozilla.org/en-US/docs/Web/CSS/@view-transition
    • Di zaman sekarang, ini pendapat yang terlaaalu tidak peka
      Sebagian besar perangkat lunak jauh lebih lambat dan kurang responsif daripada perangkat mekanis 120 tahun lalu
    • Hanya dengan CSS dan JS biasa pun kita bisa dengan mudah membuat dinamika refresh yang sangat sederhana
      Tidak perlu memanggil paket npm
    • Pemisahan antara React dan server juga berantakan
      Backend-nya express/node, seluruh kode bercampur, lalu di lingkungan dev server dijalankan lewat server bawaan React, sedangkan saat deployment dijalankan berbeda, sehingga pada akhirnya butuh pola build dan operasi yang aneh dan kenyamanan dev server seperti hot reload jadi terasa sia-sia
    • Saya jauh lebih sering mengalami SPA lebih rusak daripada MPA
      Bahkan SPA perusahaan besar seperti Reddit dan X(Twitter) terlalu tidak stabil di mobile
      Kalau bukan setingkat Twitter, atau bukan platform berbasis API, menurut saya tidak perlu memaksakan SPA
      Kalau bahkan perusahaan bernilai puluhan miliar pun belum berhasil membangunnya dengan benar, jangan terlalu percaya diri bahwa saya bisa melakukannya lebih baik
    • Kelebihan pendekatan vanila adalah situs SSR yang sudah ada juga bisa diperluas
      Tidak perlu membongkar semuanya dan menggantinya dengan React
      Fitur-fitur canggih mirip SPA yang disebut penulis asli bersifat opsional
    • Pengguna pragmatis mungkin tidak peduli, tetapi pengguna yang asal klik akan menekan tombol kembali alih-alih menunggu untuk kembali ke feed utama, dan waktunya lebih cepat daripada waktu yang dibutuhkan untuk mengambil framework terbaru dari CDN
    • Kalau page refresh benar-benar sangat cepat, saya setuju dengan pendapat itu
    • Saya ingin tahu bagaimana Anda bisa yakin bahwa pengguna benar-benar sama sekali tidak peduli pada page refresh itu sendiri
      Apakah Anda juga meneliti orang-orang yang sudah pergi

  • Saya ingin hidup di dunia seperti ini
    Saya berasal dari masa sebelum framework, dan saat itu segalanya memang belum matang, bahkan orang yang hanya tahu jQuery pun sangat umum
    Sekarang saya merasa manfaat framework pasca-query selector tidak sebanding dengan biayanya, meski framework testing adalah pengecualian yang sangat bagus
    Kita terjebak dalam penjara framework bernama React, dan semua kegagalan adalah hasil dari kompleksitas yang berubah menjadi spaghetti
    State machine jadi kusut karena hardcoding, dan hasil terjemahan, kompresi, serta transpile sulit dibaca
    Source map juga menjadi lapisan kompleksitas tambahan untuk maintenance
    Saya paham kenapa framework dibuat, tetapi sulit membayangkan bahwa bagi engineer baru, terus belajar framework lebih mudah daripada vanilla JS

    • Saya juga mengalami masa lama itu, dan masalah terbesarnya adalah kita memutuskan membangun ekosistem aplikasi di atas format dokumen
      HTML hanyalah markup yang dibuat untuk mempermudah rendering teks, dan HTTP juga serupa
      Dulu rasio text-to-markup harus tinggi, tetapi sekarang itu benar-benar terbalik
      Tetapi kita percaya bahwa menumpangkan seluruh pengembangan aplikasi di atasnya adalah masa depan, dan kalau melihat bagian dalam React pun, isinya adalah puluhan tahun akal-akalan dan trik
      Dulu itu seperti membuat aplikasi dengan Excel+VB, atau kombinasi PDF+PostScript, sebuah upaya yang terdengar absurd
      Karena kita menempuh jalan itu, konsumsi JS beberapa MB terasa berlebihan
    • Bagi saya, killer app masa kini adalah reaktivitas
      Yakni saat UI langsung bereaksi terhadap perubahan data; kalau ini harus dilakukan dengan membuat listener manual, update diff, bahkan melepas event satu per satu, rasanya seperti manajemen memori manual
      Begitulah masa jQuery, dan kesalahan sangat sering terjadi
      Kalau nanti sudah mungkin memodularisasi view secara deklaratif berbasis komponen dengan vanilla JS, barulah saya akan kembali, tetapi saat ini menurut saya masih mustahil
      Ada elemen penentu yang masih kurang
    • Saya juga kadang bingung apakah ini cuma nostalgia pada prinsip KISS dan semacamnya
      React dan Angular jelas masuk akal sebelum ES2015
      Setelah itu saya lelah dengan perubahan framework frontend
      Bahkan di dalam React sendiri, pendekatan komponen dan cara mengelola state terus berubah
    • Kalau saya mengelola layanan dengan ratusan juta view, saya membayangkan strukturnya pada praktiknya akan jauh lebih dekat ke situs statis

  • Saya masih belum setuju dengan Web Components
    Bahkan dengan fitur terbaru seperti @scoped, import {type:css}, saya tetap merasa jauh lebih masuk akal merender elemen secara statis lalu memperbaruinya secara dinamis dengan JS modern
    Saya skeptis pada sebagian besar pendekatan Web Components, dan percaya kita harus terus berinovasi di luar framework seperti React/Svelte
    Saya tidak pernah merasa Web Components berguna untuk beberapa situs yang saya kelola

    • Web Components tidak menyelesaikan masalah saya, justru menambahkan masalah baru
      Hal-hal terkait Shadow DOM disebut berkali-kali di tiap halaman, dan kebanyakan justru adalah masalah yang muncul karena memilih memakainya
      Karena komponennya khusus untuk aplikasi saya, saya juga tidak punya masalah Shadow DOM
    • "Render elemen statis + pembaruan dinamis dengan JS modern"
      Saya penasaran bagaimana Web Components menangani ini di backend
    • Web Components memberikan batas abstraksi yang jelas
      Anda bisa menambahkan metode sendiri ke tag Anda, dan logika pembaruan juga bisa dienkapsulasi di dalam komponen
    • Saya rasa kita perlu kembali ke Unobtrusive JS
      Kita butuh praktik yang berfokus pada library ringan atau hal-hal yang bisa ditulis sendiri
      HTMX ada bagusnya, tetapi tetap bertindak seperti tag script, dan menurut saya URL/metode cukup diletakkan jelas di HTML, sementara hal seperti hx-target cukup ditentukan sebagai data- attribute dari JS
      Saya tidak ingin membawa semua fitur HTMX yang tidak dipakai

  • Saya tidak menganggap Web Components sebagai pengganti untuk apa yang oleh framework lain disebut komponen
    Tidak bisa memasukkan nilai majemuk (Object, Array, dll.) ke atribut, boilerplate-nya terlalu banyak, dan tidak ada reaktivitas
    Saya menulis kode gaya vanilla JS dengan pendekatan signals[1]
    Tidak semua standar W3C adalah jawaban yang benar, dan kita harus melihat contoh kegagalan XHTML
    [1] https://wrnrlr.github.io/prelude/

  • http://youmightnotneedjs.com

  • Ini tampaknya pendekatan yang cocok bagi orang yang membuat halaman web sebagai hobi
    Framework bertujuan untuk standarisasi, desain yang menanamkan praktik terbaik, dan memulai pengembangan dengan cepat
    Website itu sendiri tidak punya nilai intrinsik; yang penting adalah bagaimana menampilkan isinya secara efisien dan mengembangkannya dengan benar tepat waktu
    Dalam hal ini, framework menurunkan biaya saat ini dan biaya masa depan

    • Itulah 'narasi resmi', tetapi pada kenyataannya tidak selalu benar
      Di perusahaan besar nyata, pengambilan keputusan sering ditentukan oleh tren, kebiasaan, dan sikap defensif terhadap framework populer; penurunan produktivitas akibat peningkatan kompleksitas tidak dilacak, dan justru keputusan buruk sering selaras dengan insentif pribadi atau tim
      Artinya, kita tidak bisa membenarkan pemilihan framework dengan logika "ini pasti pilihan yang rasional"
    • Saya juga sering melihat proyek yang dibangun dengan React dan framework terkait tidak dikelola dengan baik
      Dari awal, memakai framework tidak otomatis berarti praktik terbaik akan dijalankan, dan justru bisa menghasilkan sistem yang lebih gemuk dan lambat

  • Ini materi yang benar-benar luar biasa
    Kalau membangun web, menurut saya kita harus memahami prinsip teknologi dasarnya dan memanfaatkan platform web semaksimal mungkin
    Di atas itu, memakai build system/framework atau tidak adalah pilihan bebas selama kita paham trade-off-nya
    Secara pribadi saya suka Remix(/React-router v7+) karena selaras dengan filosofi standar web
    Artinya, kita bisa mencapai lebih banyak dengan lebih sedikit pengembangan, misalnya perubahan data server bisa dilakukan hanya dengan HTML form
    Saya juga merekomendasikan https://every-layout.dev karena di sana kita bisa mempelajari berbagai teknik layout berkinerja tinggi, aksesibel, dan fleksibel yang dibuat hanya dengan CSS native browser
    Saya sendiri bekerja secara profesional di pengembangan web sejak 1998

  • Minggu lalu saya membuat proyek kecil sepenuhnya dengan vanila dan hasilnya berjalan sangat baik
    Ini alat web untuk menulis thread panjang Mastodon
    Sepanjang proses membuatnya, saya terus berpikir, "apakah saya melakukan sesuatu yang salah karena tidak memakai framework?"
    Suasananya seperti semua orang lain mengharapkan framework
    Splinter, splinter.almonit.club, silakan lihat bagi yang tertarik