Table of Contents
▼Setiap developer JavaScript pasti pernah mendengar peringatan ini. "Jangan pernah block main thread." Kalau Anda block, aplikasi akan freeze. User akan marah. Bisnis akan rugi. Tapi apakah dogma ini selalu benar tanpa terkecuali?
Seperti banyak hal dalam software engineering, jawabannya adalah "itu tergantung." Ada nuansa yang sering terlewat ketika kita membahas main thread dan blocking. Memahami nuansa ini bisa menghemat waktu development dan mencegah premature optimization.
Asal Usul Dogma Never Block Main Thread
JavaScript adalah single-threaded language. Semua kode JavaScript Anda berjalan di satu thread yang sama dengan rendering dan user interaction. Ketika kode JavaScript sedang dieksekusi, browser tidak bisa melakukan hal lain.
Ini berbeda dengan bahasa seperti Java atau Go yang punya multithreading native. Di JavaScript, satu operasi yang lambat bisa menghentikan seluruh aplikasi. User tidak bisa klik tombol. Animasi berhenti. Halaman terasa "hang."
Para ahli lalu memberi saran: jangan blokir main thread lebih dari 50ms. Di atas angka itu, user akan mulai merasa aplikasi lambat. Google bahkan memasukkan Total Blocking Time sebagai metrik dalam Core Web Vitals.
Namun saran ini sering disalahartikan. Banyak developer mengira semua operasi synchronous itu jahat. Padahal konteks sangat menentukan apakah suatu blocking itu problematis atau tidak.
Mengapa Blocking Terkadang Acceptable
Blocking bukan masalah kalau durasinya singkat. Operasi yang selesai dalam 5-10ms sama sekali tidak terasa oleh user. Browser punya waktu 16.67ms untuk setiap frame (60fps), jadi ada ruang yang cukup.
Yang menjadi masalah adalah blocking yang durasinya panjang dan terjadi saat user sedang aktif berinteraksi. Kalau blocking terjadi di background atau saat aplikasi sedang idle, dampaknya minimal.
Ada juga situasi dimana blocking adalah pilihan yang sadar dan disengaja. Loading screen, misalnya. User sudah expect bahwa aplikasi akan "sibuk" sebentar. Tidak ada salahnya melakukan inisialisasi synchronous.
Konteks Yang Menentukan Acceptability
Pertama, timing. Blocking saat halaman pertama kali load berbeda dengan blocking saat user sedang scroll. Saat initial load, user masih bersabar. Saat interaksi, setiap milidetik terasa.
Kedua, durasi. Blocking 10ms tidak akan terasa. Blocking 100ms mungkin masih acceptable untuk operasi penting. Blocking 500ms ke atas baru mulai problematis.
Ketiga, frekuensi. Blocking sekali saat startup berbeda dengan blocking yang terjadi berulang kali. Frekuensi tinggi akan membuat aplikasi terasa sluggish secara kumulatif.
Trade Off Simplicity vs Performance
Async code lebih kompleks. Anda harus handle promise, callback, atau async/await. Error handling jadi lebih rumit. Debugging jadi lebih sulit. Testing jadi lebih challenging.
Untuk operasi yang cepat, kompleksitas tambahan ini mungkin tidak sebanding. Mengapa harus memakai Web Worker untuk operasi yang selesai dalam 5ms? Itu over-engineering.
// Synchronous version - simple and clear
function validateEmail(email) {
const regex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
return regex.test(email);
}
// Async version - unnecessary complexity
async function validateEmailAsync(email) {
return new Promise(resolve => {
const regex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
resolve(regex.test(email));
});
}
Kode synchronous di atas lebih mudah dibaca dan di-debug. Untuk validasi email yang instan, tidak ada alasan untuk membuatnya async. Keep it simple.
Premature optimization adalah akar dari banyak kejahatan dalam programming. Jangan optimasi sesuatu yang belum tentu masalah. Ukur dulu, baru optimasi jika perlu.
Kasus Nyata Blocking Yang Acceptable
Initial Setup dan Configuration
Saat aplikasi pertama kali load, ada banyak inisialisasi yang harus dilakukan. Parsing config, setting up state, registering service worker. Ini bisa dilakukan secara synchronous tanpa masalah.
User sudah expect loading time di awal. Selama Anda menampilkan loading indicator, blocking beberapa milidetik untuk setup tidak akan terasa.
Calculations Yang Cepat
Operasi matematika sederhana, string manipulation, atau array operations yang kecil tidak perlu di-async-kan. Filter array 100 item akan selesai dalam hitungan milidetik.
// This is perfectly fine - completes in milliseconds
const activeUsers = users.filter(u => u.isActive);
const sortedUsers = activeUsers.sort((a, b) => b.score - a.score);
const top10 = sortedUsers.slice(0, 10);
Array methods modern di JavaScript sudah sangat optimized. V8 engine melakukan banyak optimisasi di balik layar. Jangan asumsikan semua operasi array itu lambat.
Small Data Processing
Memproses data yang ukurannya kecil dan predictable bisa dilakukan synchronous. Format tanggal untuk 50 item, sanitize input pendek, atau encode/decode string kecil.
Yang menjadi masalah adalah data yang besar atau ukurannya tidak predictable. Kalau Anda tidak tahu apakah data akan 10 item atau 10.000 item, baru pertimbangkan pendekatan async.
Critical Path Operations
Beberapa operasi memang harus synchronous karena alasan bisnis. Validasi form sebelum submit, authentication check, atau permission verification. User tidak bisa melanjutkan kalau operasi ini belum selesai.
Dalam kasus ini, blocking justru desired behavior. Anda ingin user menunggu sampai validasi selesai. Tidak ada gunanya membuatnya async kalau hasilnya memblokir flow user juga.
Kapan Blocking Harus Dihindari
Setelah membahas kapan blocking acceptable, penting juga untuk tahu kapan blocking harus dihindari. User interaction adalah konteks utama.
Saat user sedang scroll, klik tombol, atau navigasi, main thread harus responsif. Blocking di momen ini akan terasa jelas. Animasi jadi patah-patah. Click handler jadi delay.
Operasi yang durasinya unpredictable juga berbahaya. Network request, large data processing, atau complex calculations harus di-async-kan.
Loop yang iterasinya banyak atau tidak known upfront harus diwaspadai. Nested loop O(n²) atau recursive function tanpa batas bisa jadi bottleneck.
// Dangerous - could block indefinitely
function processLargeDataset(data) {
const results = [];
for (let i = 0; i
Untuk kasus seperti ini, pertimbangkan chunking. Pecah operasi besar jadi potongan-potongan kecil. Beri jeda di antara potongan agar main thread bisa mengerjakan hal lain.
Strategi Menangani Heavy Operations
Web Workers
Web Workers memungkinkan Anda menjalankan JavaScript di thread terpisah. Main thread tetap responsif sementara worker mengerjakan heavy lifting.
Cocok untuk image processing, large data transformation, atau complex calculations. Komunikasi dengan main thread melalui postMessage.
// main.js
const worker = new Worker('processor.js');
worker.postMessage({ data: largeDataset });
worker.onmessage = function(e) {
const results = e.data;
updateUI(results);
};
// processor.js
self.onmessage = function(e) {
const results = heavyProcessing(e.data);
self.postMessage(results);
};
Request Idle Callback
API ini memungkinkan Anda menjadwalkan task saat browser sedang idle. Cocok untuk operasi yang tidak urgent dan bisa ditunda.
Misalnya analytics, prefetching, atau background sync. User tidak perlu menunggu operasi ini selesai. Browser akan menjalankannya saat ada waktu luang.
Chunking dengan setTimeout
Teknik klasik untuk memecah operasi besar. Setiap chunk dijalankan sebagai task terpisah. Browser bisa mengerjakan hal lain di antara chunk.
function processInChunks(items, chunkSize = 100) {
let index = 0;
function processChunk() {
const end = Math.min(index + chunkSize, items.length);
while (index
Guidelines Praktis untuk Decision Making
Pertama, ukur sebelum optimasi. Gunakan Chrome DevTools untuk mengetahui actual execution time. Jangan mengira-mengira tanpa data.
Kedua, pertimbangkan konteks. Blocking saat initial load berbeda dengan blocking saat interaksi. Timing sangat menentukan.
Ketiga, hitung trade-off. Apakah kompleksitas async worth the benefit? Untuk operasi cepat, synchronous mungkin lebih baik.
Keempat, test di device yang lebih lambat. High-end laptop Anda mungkin tidak merepresentasikan user sebenarnya. Test di low-end device untuk gambaran lebih akurat.
Kelima, prioritaskan user experience. Metrik performance adalah proxy untuk UX. Jangan optimasi untuk metrik tapi mengorbankan UX.
Terakhir, dokumentasikan keputusan Anda. Kalau Anda sengaja memilih synchronous approach, jelaskan alasannya. Ini membantu developer lain memahami konteks.
Menyeimbangkan Idealism dan Pragmatism
Dalam software development, sering kali ada gap antara teori ideal dan praktik nyata. Never block main thread adalah ideal. Tapi implementasi harus mempertimbangkan realitas.
Codebase yang ada, timeline project, skill tim, dan kebutuhan bisnis semua mempengaruhi keputusan. Tidak ada jawaban yang benar untuk semua situasi.
Yang penting adalah memahami konsekuensi dari setiap pilihan. Kalau Anda pilih synchronous, tahu risikonya. Kalau pilih async, tahu kompleksitasnya.
Dengan pemahaman yang nuanced, Anda bisa membuat keputusan yang tepat untuk konteks spesifik Anda. Bukan sekadar mengikuti dogma tanpa pertanyaan.
Kesulitan dengan tugas programming atau butuh bantuan coding? KerjaKode siap membantu menyelesaikan tugas IT dan teknik informatika Anda. Dapatkan bantuan profesional di jasa tugas IT KerjaKode.
Blocking main thread bukan dosa. Itu adalah tool dalam toolbox Anda. Gunakan dengan bijak, di konteks yang tepat, dengan pemahaman penuh tentang konsekuensinya.
