Why don’t more developers “use the platform”?

Halo Semeton Koding dan para pejuang DOM! Ketemu lagi sama sang Wong Edan di jagat maya perkopian error dan tumpukan node_modules yang beratnya melebihi beban hidup kalian. Hari ini kita bakal ngebahas sebuah fenomena mistis di dunia perkodingan modern yang bikin para senior ngelus dada, arsitek software garuk-garuk kepala, dan junior kebingungan harus ngikutin mazhab yang mana.

Pernah dengar petuah suci dari para sepuh web: “Use the platform!” alias “Gunakanlah platform aslinya!”? Nasihat ini sering banget digaungkan oleh para pemuka mazhab Web Standar. Intinya sederhana: browser modern itu sudah canggih, kaya fitur, punya API bawaan yang dewa-dewa, jadi ngapain kalian masih pakai framework segede gaban cuma buat nampilin teks doang? Kenapa harus install 50 paket npm kalau JavaScript murni (Vanilla JS) dan CSS modern sudah sanggup melibasnya?

Tapi faktanya apa, Cok? Berdasarkan esai reflektif dari Nolan Lawson dalam artikelnya yang berjudul “Why don’t more developers use the platform?”, fenomena menghindari platform ini bukanlah hal baru, dan ternyata tidak cuma terjadi di dunia web doang (daily.dev). Di dunia DevOps, internal platform, bahkan database, developer sering banget milih bikin alat sendiri atau pakai tool pihak ketiga yang sudah mereka pahami ketimbang pakai sistem bawaan yang disediakan (Medium). Mari kita bedah dosa-dosa teknis ini satu per satu dengan gaya Wong Edan!

1. Trauma Masa Lalu: Fragmentasi Browser yang Bikin Rambut Rontok

Kalau kalian nanya ke developer angkatan jadul—yang rambutnya sekarang udah pada botak di tengah—kenapa mereka cinta mati sama jQuery atau library eksternal, jawabannya satu: TRAUMA.

Dulu, sekitar era akhir 90-an sampai 2010-an awal, yang namanya “the platform” (dalam hal ini: Internet Explorer, Netscape, versi awal Firefox dan Chrome) itu ibarat mantan yang toxic parah. Standarisasi W3C cuma jadi angan-angan di atas kertas. Setiap vendor browser punya interpretasi sendiri terhadap DOM API, CSS box model, dan event handling.

Contoh nyata penderitaan masa lalu saat mau manggil elemen DOM:

// Mau ambil elemen berdasarkan class aja rasanya kayak nyari jarum di tumpukan jerami
// Dulu gak ada document.querySelector yang seragam!
var element = document.getElementsByClassName ? document.getElementsByClassName('my-class') : document.querySelectorAll('.my-class');

Karena browser fragmentasi parah dan API bawaan aslinya jelek, ribet, serta tidak konsisten, hadirlah penyelamat seperti jQuery. Library ini membungkus ketidakwarasan browser di balik satu fungsi simpel: $('.my-class'). Dari sinilah mentalitas “jangan percaya platform, percaya library” mendarah daging di kalangan developer. Walaupun browser zaman sekarang sudah sangat patuh standar (W3C/WHATWG), memori otot (muscle memory) dari trauma masa lalu itu susah banget dihapus.

2. Ekosistem NPM dan Efek IKEA: “Gue yang Bikin, Gue yang Bangga!”

Alasan kedua kenapa developer ogah “use the platform” adalah kenyamanan ekosistem npm dan apa yang psikolog sebut sebagai Efek IKEA (IKEA Effect). Efek IKEA adalah sebuah bias kognitif di mana manusia jadi punya rasa memiliki yang tinggi terhadap sesuatu kalau mereka ikut merakitnya sendiri dari nol.

Banyak developer ngerasa kalau pakai Web Components murni atau API bawaan browser itu kayak kurang greget, kurang keren, dan gak ada seninya. Diskusi hangat di platform seperti Hacker News dan Stacker News sering banget memperdebatkan hal ini. Sebagai contoh, banyak developer berpendapat bahwa standar Web Components (seperti Custom Elements dan Shadow DOM) punya desain API yang canggung, kaku, dan sulit dipakai tanpa bantuan library pembungkus seperti Lit (Stacker News).

Ketimbang pakai Web Components murni yang sintaksnya bikin jidat berkerut:

class MyElement extends HTMLElement {
constructor() {
super();
this.attachShadow({ mode: 'open' });
this.shadowRoot.innerHTML = `Halo, ini web component!`;
}
}
customElements.define('my-element', MyElement);

Developer lebih memilih framework seperti React, Vue, atau Svelte karena manajemen state-nya, sistem reaktivitasnya, dan cara pengoperasiannya terasa jauh lebih masuk akal di otak mereka. Mereka lebih suka merakit stack kompleks dari puluhan paket npm ketimbang menggunakan fitur modular bawaan browser yang dianggap setengah matang.

3. Dokumentasi Platform Kalah Telak Dibandingkan Dokumentasi Library Komersial

Coba kalian bandingkan kualitas dokumentasi resmi untuk Web APIs di MDN (Mozilla Developer Network)—yang sebenarnya sudah sangat bagus—dengan dokumentasi dari framework populer seperti React, Tailwind CSS, atau Stripe. Jauh kan?

Dokumentasi platform web (seperti spesifikasi W3C atau WHATWG) ditulis oleh para insinyur tingkat dewa dengan bahasa hukum spesifikasi yang tingkat kebacaannya setara sama kitab undang-undang pidana. Isinya penuh dengan syarat, pengecualian, dan istilah-istilah spek teknis murni yang bikin ngantuk.

Sebaliknya, library komersial atau open-source besar berlomba-lomba bikin dokumentasi yang ramah pengguna:

Ada tutorial interaktif langsung jalan di browser (CodeSandbox/StackBlitz).
Punya video penjelasan di YouTube dari influencer tech terkenal.
Contoh kodenya langsung copy-paste bisa dipakai buat bikin landing page dalam 5 menit.

Gimana developer bisa disuruh “use the platform” kalau nyari cara pakai fitur baru browser (misalnya Web Audio API atau Payment Request API) harus baca dokumen spesifikasi setebal 500 halaman, sementara pakai library tinggal instal npm i super-payment langsung beres?

4. Masalah Internal Platform Engineering: Ketika Perusahaan Bikin “Platform” yang Malah Dibenci Dev Sendiri

Fenomena tidak mau pakai platform ini ternyata bukan cuma soal JavaScript front-end doang, Cok! Masalah ini juga menjalar ke tingkat infrastruktur dan DevOps perusahaan.

Berdasarkan data riset industri, sekitar 64% developer terang-terangan sengaja membangkang dan mem-bypass internal developer platform (IDP) yang dibuat oleh tim DevOps kantor mereka sendiri (Medium). Ironis banget kan? Perusahaan keluar duit banyak buat bikin platform internal supaya developer bisa kerja cepat, tapi yang terjadi malah dev-nya males pakai.

Kenapa bisa begitu? Seperti yang dibahas oleh Sam Newman dalam artikel tajamnya, “Don’t Call It A Platform”, banyak perusahaan terjebak membuat “platform” palsu yang isinya cuma membungkus Kubernetes mentah-mentah dengan aturan birokrasi yang bikin sesak napas (Sam Newman). Platform itu harusnya mempermudah hidup, bukan nambahin lapisan kerumitan baru yang gak transparan.

Keluhan klasik para developer di forum diskusi seperti Reddit r/devops juga mengonfirmasi hal serupa: tim platform menghabiskan waktu berbulan-bulan bikin sistem internal, tapi pas jadi, developer ogah pakai karena platform tersebut tidak fleksibel, tidak portabel, dan memaksa mereka belajar cara kerja non-standar yang gak bakal terpakai di tempat kerja lain (Reddit).

5. Gaps di CSS dan Batasan Asli Platform Web

Alasan teknis murni lainnya kenapa developer lari dari platform adalah karena “The Platform” itu sendiri terkadang lambat beradaptasi dengan kebutuhan zaman. Contoh paling nyata ada di dunia CSS.

Butuh waktu bertahun-tahun lamanya bagi CSS murni untuk memiliki variabel (CSS Custom Properties), sistem layout modern (Flexbox dan Grid), hingga fitur nesting native yang baru-baru ini distandarisasi. Selama bertahun-tahun penantian itu, developer web terpaksa bergantung pada preprocessor seperti Sass/SCSS atau PostCSS.

Ketika fitur itu akhirnya resmi masuk ke platform web, kebiasaan lama sudah telanjur berakar. Developer sudah terbiasa nulis kode pakai tools build pihak ketiga (Vite, Webpack, esbuild) yang otomatis ngurusin minifikasi, bundling, dan prefixing. Jadi, meskipun platform sekarang sudah menyediakan fitur tersebut secara native, transisi psikologisnya males dilakukan karena “Ah, toh build tool gua udah ngurusin ini semua secara otomatis.”

6. Analogi Dunia Nyata: Kenapa Pakai ClickHouse Kalau Bisa Pakai Excel? (Eh, Jangan Deng!)

Seperti yang disorot dalam catatan Nolan Lawson, fenomena menghindar dari platform dasar ini sebenarnya tidak eksklusif di web. Ini adalah masalah psikologi universal dalam rekayasa perangkat lunak: Orang cenderung menghindari platform atau teknologi yang tidak sepenuhnya mereka pahami (Nolan Lawson).

Misalnya di tempat kerja Nolan, mereka menggunakan ClickHouse untuk menyimpan berbagai macam data analitik skala besar (Nolan Lawson). Apakah semua orang langsung paham cara optimal pakai ClickHouse? Tentu tidak! Banyak yang akhirnya membungkus query mentahnya dengan ORM atau script kustom buatan sendiri karena mereka lebih nyaman dengan abstraksi yang sudah mereka kenal sehari-hari.

Manusia itu makhluk pemalas yang efisien. Kalau ada cara untuk menghindari kurva belajar yang curam dengan menggunakan alat familiar yang kita kuasai, kita pasti bakal ambil jalan itu—bahkan kalau secara arsitektur itu dianggap “overkill” atau “anti-pola”.

Kesimpulan Ahli: Harus Jembatani Kesenjangan, Bukan Cuma Nyuruh!

Jadi, apakah salah kalau developer ogah “use the platform”? Jawabannya: Gak 100% salah, tapi ada ruginya.

Keuntungan pakai platform asli itu nyata banget:

Ukuran bundle file jauh lebih kecil (gak ada bloatware dari npm node_modules raksasa).
Umur panjang (platform web dijamin tidak akan “deprecated” atau ditinggal maintainer-nya dalam 2 tahun ke depan).
Performa eksekusi browser langsung di level native tanpa lapisan abstraksi tambahan.

Tapi di sisi lain, komunitas pembuat standar platform web (W3C, WHATWG, browser vendor) juga harus instrospeksi diri. Jangan cuma nyuruh developer buat “use the platform”, sementara API yang mereka sediakan masih berasa seperti peninggalan purbakala yang susah dipakai. Dokumentasi harus diperbaiki, kemudahan developer experience (DX) harus ditingkatkan, dan desain API native harus lebih ramah manusia modern.

Intinya, keseimbangan itu penting. Jangan anti sama platform asli, tapi juga jangan sok-sokan pakai Vanilla JS murni buat bikin aplikasi enterprise skala raksasa kalau akhirnya bikin tim kalian gila semua. Gunakan alat yang tepat untuk pekerjaan yang tepat, dan yang paling penting: jangan lupa ngopi biar gak gampang stroke ngadepin error kodingan!

Sekian ceramah teknis dari sang Wong Edan hari ini. Sampai jumpa di artikel berikutnya dengan tumpukan bug yang lebih menantang!