Ngobrolin Konsep JS: Event Loop
Ringkasan Episode
Bantu KoreksiEpisode ini membahas event loop, konsep fundamental yang menjelaskan kenapa JavaScript sering terasa tidak bisa ditebak. Keluhan klasiknya nyata: kode berjalan sesuai urutan saat dicoba, lalu berubah urutannya saat dipresentasikan ke klien. Akar masalahnya bukan bahasanya yang aneh melainkan model konkurensinya yang belum dipahami. Dijelaskan lebih dulu bedanya asynchronous dan paralel lewat analogi tujuh anak membungkus kado: pada asynchronous tiap anak mengerjakan satu tahap untuk semua kado, sehingga satu anak yang berhenti membuat seluruh proses terhenti; pada paralel tiap anak menyelesaikan satu kado utuh sendiri, sehingga satu yang gagal masih menyisakan enam kado jadi. JavaScript memakai jalur asynchronous dan berjalan di satu thread. Demo setTimeout dengan delay nol menunjukkan intinya: meski tanpa penundaan, callback-nya tetap masuk antrean dan baru dieksekusi setelah call stack kosong. Dari sini dibahas kenapa while(true) membekukan halaman sementara versi rekursif dengan setTimeout tidak, kenapa JavaScript yang terlalu berat membuat scroll terasa patah-patah karena proses render kalah cepat, dan kenapa alert adalah satu-satunya hal yang benar-benar memblokir. Ditutup dengan Web API — implementasi khusus browser di luar JavaScript engine seperti fetch, Intersection Observer, History, dan Intl — serta pesan praktis: pahami callback dulu, lalu promise, baru async/await, dan jangan menumpuk await berurutan untuk dua permintaan yang sebenarnya tidak saling bergantung.
Poin-poin Utama
- •Perbedaan asynchronous dan paralel: pada asynchronous satu tahap yang gagal menghentikan seluruh rangkaian, sedangkan pada paralel satu yang gagal hanya menghilangkan bagiannya sendiri — JavaScript memakai jalur asynchronous di satu thread
- •setTimeout dengan delay nol tetap tidak dieksekusi langsung: callback-nya masuk antrean dan baru dijalankan setelah call stack kosong
- •while(true) membekukan halaman karena task-nya tidak pernah keluar dari antrean, sedangkan rekursi yang sama di dalam setTimeout tetap membiarkan event loop berputar sehingga halaman masih bisa di-scroll
- •JavaScript yang terlalu berat membuat scroll terasa patah-patah karena proses render kalah cepat dengan eksekusi task — dan alert adalah satu-satunya hal yang benar-benar memblokir semuanya
- •Web API adalah implementasi khusus browser di luar JavaScript engine — fetch, Intersection Observer, History, Intl — dan banyak library populer sebenarnya hanya membungkusnya
- •Urutan belajarnya callback dulu, lalu promise, baru async/await — melompat langsung ke async/await tanpa paham promise justru membingungkan
- •Dua await berurutan untuk permintaan yang tidak saling bergantung membuat JavaScript berperilaku seperti bahasa sinkron; gunakan Promise.all atau Promise.allSettled, dan selalu tangani error karena satu promise yang gagal bisa menjatuhkan sisanya
[Pintu teater dua dibuka]
Perhatian-perhatian, pintu teater dua belum dibuka.
Halo Selamat Malam, selamat hari Selasa.
Hari Selasa adalah waktunya ngobrolin web dan masih bersama kita bertiga di sini.
Ada saya Riza, co-foundernya Hektifate, terus juga ada teman saya namanya Ivan.
- Halo Ivan. - Hai, nama saya Ivan.
- GDI web. - GDI web dan ada Eka tentunya.
- Halo. - Halo, Eka GDI web juga.
Gimana, gimana, gimana.
Oh iya, untuk episode ini disponsori oleh, belum ada sponsor kita ya.
- Belum ada sponsor. - Kalau ada yang mau sponsor bisa email ke Ivan @Ivan.
- istianto.com - istianto.com
Ya bisa jadi short ke saya Eka atau Mas Riza, silahkan.
Enggak, enggak, enggak, enggak. Kita belum mencari sponsor dan belum butuh.
Jadi, jadi malam hari ini kita akan ngobrolin tentang konsep fundamental dari JavaScript,
- yaitu event look. - Event look.
Ya, ini adalah salah satu konsep yang, apa ya, yang cukup penting karena
kalau kita tidak mengerti konsep ini, bisa-bisa kita, ya enggak.
Alur perjalanan JavaScript itu gimana, stres, terus enggak suka, benci, gitu ya.
Dan kita mengalami sendiri ketika kita bekerja, terus dapat JavaScript, dan ketemu res kondisi,
kok ini muncul duluan, kok ini muncul belakangan, padahal ini udah di-print duluan, gitu-gitu.
Itu semuanya adalah event look.
- Berkaitan sama event look. - Berkaitan dengan event look.
Dulu waktu saya bekerja, tim saya sangat-sangat tidak seduka dengan JavaScript.
Katanya, ini programming language yang tidak pasti.
- Oh iya, susah diprediksi, ya. - Gak benar-benar pasti.
- Susah diprediksi. - Ya, outcome-outcome itu enggak pasti.
Itu apa sih, gini. Masa kita mau manggil baca, contohnya baca local stories aja,
atau manggil API, hasilnya kok enggak ada sih.
Hasilnya kok enggak ada sih, gimana hasilnya, kok hasilnya malah fungsi.
Lihat transkrip lengkap (635 segmen lagi)
- Promising, gitu ya. - Atau kadang bisa, kadang enggak pasti jalanin,
kadang kalau kita menghitung dengan tanda kutip, bener, urutannya normal sesuai ekspektasi,
giliran di pitching ke client atau di hand over, langsung berubah semua.
- Nah, itu kan repot ya. - Nah, mungkin teman-teman yang nonton
mungkin punya pengalaman juga, boleh di-share juga ya ke kita,
pengalaman berkaitan dengan JavaScript.
- Terus ada dulu itu istilahnya callback hell, gitu ya.
- Callback hell. - Karena saking enggak ngerti nya JavaScript,
semuanya di dalam callback, kayak sampai nested, callback kemana-mana.
- Terus sampai dia bingung sendiri, aduh, callback-nya banyak banget.
- Jadinya malah ini ya, sekonsial ya, jadi enggak guna itu si asingkronusnya ya.
- Iya, betul sekali. - Mungkin dulu juga,
karena belum terlalu stabil ya, API yang memudahkan, web API yang memudahkan kita
jalanin asing, kayak promise all, sama promise all settled, mungkin belum ada asing-wait, belum ada semua ditaruh.
Masih pakai XHR itu loh. - X-H-R ya, X-H-R.
- X-H-R Amsterdam, pakai X-H-R. Jadi apa boleh buat karena emang dulu
belum terlalu mendukung ya, jadi kayak semua ada callback.
Nah, callback-nya nested sudah banyak, kita nge-handle yang di tengah ini bingung,
jadi kan skip ya. - Iya. Nah, konsep si event loop asingkronus ini sendiri sebenarnya
bahasa dasarnya kalau di platform atau di bahasa pemorgana itu adalah konkurrensi.
Konkurensi itu adalah mengakukan sebuah task atau pekerjaan, baik itu secara paralel atau secara asingkronus.
Dan kebetulan si Javascript pakai cara asingkronus. Kalau misalkan kayak bahasa seperti Golang,
terus Erlang Alixir, terus apa lagi yang paralel ya, dan beberapa yang lain lah ya, itu ada yang paralel.
Nah, sebelum kita masuk ke bahas tentang event loop, saya mungkin bahas sedikit aja tentang perbedaan antara asingkronus
dan juga paralel, biar agak jelas sedikit ya. Dan ini adalah salah satu materi yang diajarkan di bootcamp,
jadi saya memperlihatkan sedikit slide-nya. Nah, ini analogian cukup bisa ditangkap lah sama student-student
karena ada gambar dan lain-lain. Jadi konsepnya si asingkronus ini, dia mengerjakan misalkan si worker-worker ini
atau tujuh anak ini, diminta untuk menyelesaikan tujuh kado sampai selesai. Jadi mulai dari dimasukin hadiahnya,
ditutup, dibungkus, kemudian diikat dan lain-lain. Jadi mereka melakukan satu pekerjaan masing-masing.
Misalkan ini dia mengerjakan tujuh, tapi dia mengerjakan pekerjaannya adalah membuat kotaknya,
kemudian anak kedua misalkan masukin mainannya, anak ketiga menutup kotaknya, anak keempat membungkus,
kelima dan seterusnya sampai selesai. Setiap anak akan mengerjakan tujuh kotak atau tujuh hadiah, gitu.
Ini konsep asingkronus. Jadi dia melakukan pekerjaan yang berbeda untuk setiap worker atau setiap anak disini dalam hal ini.
Kalau paralel itu dia seperti delegasi, dia dikasih tugas, satu anak dikasih tugas untuk menyelesaikan satu mainan saja
atau satu hadiah saja, gitu. Tapi dia mengerjakan banyak tas, tasnya banyak. Mulai dari bikin kotaknya,
masukin kado-nya, terus ditutup, diikat dan lain-lain. Masing-masing ada plus minus.
Kalau minus yang paling besar dari asingkronus adalah, besar kemungkinan terjadinya kegagalan di satu anak,
maka semua proyeknya atau semua tasnya akan hancur. Misalkan di tengah-tengah ini lemot, atau dia nggak bisa.
Anak keempat ngambek, anak kelima nggak bisa ngelanjutin berarti.
Ya, itu jadi single point of failure istilahnya ya. Sementara kalau misalkan anak keempat yang disini dia ngambek,
ya udah, kado-nya tetap ada walaupun tidak lengkap.
- 6 lagi, kado-nya 6. - 6 lagi masih bisa diselamatkan.
Nah, itu plus minusnya. Jadi JavaScript meskipun tidak bisa berjalan paralel, artinya dia hanya bisa berjalan di satu core ya.
Paralel ini bisa dijalankan di banyak core-nya CPU. Jadi masing-masing CPU bisa menjalankan, kalau misalkan disini ada 7,
dia bisa menggunakan 7 atau 8 core untuk masing-masing mengerjakan pekerjaan yang secara, apa ya, terisolasi.
Masing-masing nggak peduli, nggak bergantung kepada pekerjaan temennya yang lain.
Sementara kalau asingkronus, dia bisa berjalan di satu core saja.
- Multi-trading. - Multi-trading dan single-trap.
Itulah perbedaan yang apa ya, yang signifikan antara asingkronus dan paralel.
Dan hal ini yang harus kita pahami dulu sebelum kita berkutat dengan JavaScript atau bahasa pemrograman yang paralel.
Kalau JavaScript kita optimasinya nggak bisa seperti yang paralel gitu.
Kita harus menggunakan kluster dan lain-lain untuk memanfaatkan si core yang banyak ini kan.
Karena sekarang jumlah core-nya semakin banyak. Speed-nya tidak tambah banyak.
Kalau ininya seperti mungkin banyak teman-teman dari background PHP, Python, itu di mana nih, antara asingkronus atau paralel?
PHP dan Python itu masih di asingkronus ya, masih disingkronus.
Kalau Python sekarang sudah ada asingkronus juga kan. Jadi mereka pakai ininya asingkronus juga sama.
- Betul-betul. Ya, biar tahu teman-teman di mana posisinya. - Betul sekali.
Nah, berikutnya adalah kita akan bahas tentang ini, apa namanya, cara si, ini bekerja ya, si apa namanya?
- Si javascript... - Event loop. Oh, javascript di browser.
- Javascript event loop bagaimana... - Event loop-nya bekerja.
- Nah, di sini... - Arti kata lain, artinya javascript engine ya.
- Javascript engine. - Javascript engine itu yang paling terkenal itu yang paling mainstream.
- Itu dari V8. - V8.
Ya, V8 dari Google. Meskipun ada javascript engine yang lain.
Ya, jadi karena terkenalnya si javascript engine-nya Chrome, makanya Node menggunakan V8 juga.
Jadi secara konsep di back-end ataupun di front-end, event loop ini dua-duanya mirip ya, bukan sama, mirip.
Yang membedakan adalah API-nya. Kalau di browser kita tidak bisa, kita bisa menggunakan web API.
Misalkan kayak baca file atau notifikasi dan lain-lain gitu, ya window dot something gitu ya.
Yes, dom manipulation, semuanya bisa kita lakukan.
Tapi kalau di Node.js tidak ada objek yang namanya window gitu.
Tidak ada web API, dia bisa baca file, dia bisa stream data dan lain-lain.
Makanya jebakan Batman yang sering terkenal itu adalah kalau sudah bikin react ssr,
tapi baca window objek pasti tidak ada di server silent tree. Itu jebakannya.
Ya, ini juga benar nih, Deka. Saya time out ya.
Mungkin saya demoin dikit ya, demoin dikit yang disebutkan Deka tadi.
Jadi kalau misalkan kita punya, sederhana saja, konsolok ya, ini kan.
Ini adalah, akan di eksekusi pertama kan, kemudian misalkan konsolok kedua.
Terus konsolok ketiga. Ini kita udah bisa tebakan karena ini adalah sinkronus kan.
Jadi pasti akan baris per baris, satu, dua, tiga.
Nah, lain halnya, kalau ini kita bungkus ke set time out. Set time out ini adalah sebuah fungsi asingkronus.
Ini bisa disamakan dengan fetch dengan fungsi-fungsi lain yang sifatnya asingkronus
yang dia butuh waktu untuk menyelesaikan suatu pekerjaan.
Ini adalah simulasi, misalkan simulasi fetch atau apapun ya, tapi kita pakai set time out saja biar sederhana.
Ada banyak kan. Yang penting isilahnya itu menggunakan callback kalau sudah selesai apa yang akan di eksekusi.
Set time out ini ada juga set interval dan lain-lain ya.
Jadi set time out ini adalah sebuah fungsi yang menerima dua parameter.
Parameter pertama adalah fungsi callback-nya. Apa yang akan dilakukan setelah beberapa waktu?
Dan ini adalah berapa lama waktunya? Kita ingin misalkan delay-nya misalkan satu detik.
- Ini adalah mili second ya? - Iya, mili second. Jadi 1000 mili detik.
Dan ini tentu teman-teman sudah bisa nebak ya, ini hasilnya adalah one, three, dan two.
One, three, dan satu detik kemudian baru keluar two.
Begitu juga dengan kalau kita kasih misalkan 10 mili detik, ya tetap saja sama.
Gitu ya. One, three, and two.
Nah pertanyaannya seperti yang ada di cat.
Kalau time out-nya 0, ada yang bisa nebak gak hasilnya seperti apa?
Hasilnya juga tetap sama ternyata. Walaupun dia 0 detik, tidak ada delay.
Tapi karena dia ini sudah di set kembali asingkronus, dia akan dikirimkan ke event loop.
Jadi dari sini kalau lihat gambar ini, setiap ada sesuatu yang sifatnya asingkronus
seperti set time out atau patch atau yang lain, dia tidak langsung dieksekusi.
Mereka akan masuk ke call stack dulu, kemudian dieksekusi di belakang layar.
Ketika sudah selesai, dia akan masuk ke queue atau amtrian.
Dan ketika main thread-nya atau bagian utama dari java sudah selesai, call stack-nya kosong, betul.
Baru dia... - Baru dia eksekusi.
Ini yang tugasnya manggil dari queue ke dalam call stack.
Betul. Meskipun dia berhasil menyelesaikan pekerjaannya dalam 0 detik, dia tetap masuk ke dalam amtrian dulu.
Karena set time out itu adalah mengirimkan atau mendelegasikan tugas ke bagian yang lain dari JavaScript.
Jadi tidak langsung dieksekusi meskipun hasilnya bisa langsung dinikmati, bisa langsung ada hasilnya.
Kira-kira penjelasan sederhananya seperti itu.
Mau menambahkan kalau di sisi backend.
Ini perbandingan engine-nya JavaScript dengan apa yang bisa kita capai di sisi backend
dengan menggunakan PHP atau Python dan sejenisnya.
Yang asynchronous juga, yang single thread, maksudnya.
Itu dengan menggunakan bantuan yang namanya message queue.
Kalau ada teman-teman tahu, message queue atau kalau paling sering itu kita menggunakan Chrome.
Chrome dari Unix Chrome. Pilihan Linux, Chrome job.
Jadi kalau di message queue, misalnya contoh, paling sering itu kalau menggunakan message queue.
Ada yang check out di sebuah toko online, check out.
Tentu kita harus kayak insert to database segala-gala itu proses kan panjang.
Sedangkan user harus redirect, harus kirim notifikasi, harus kirim notifikasi gimana.
Kalau misalnya kita itu kita lakukan satu per satu, tentu proses check out kita akan lama banget.
User akan marah-marah.
Kalau kita mau bikin itu menjadi sebuah sesuatu yang pasti dengan prosesnya
yang bisa kita bagi ke berbagai macam komputasi server.
Kayak server kita udah besar dan kita mau memanfaatkan server.
Kita menggunakan yang namanya message queue.
Jadi kayak kirim email, kirim SMS, kirim insert ke notifikasi kemana gitu ya.
Itu masukin ke queue, nanti queue-nya yang akan jalankan satu per satu.
JavaScript sudah punya queue itu, stack itu by default, sudah di dalam core engine-nya gitu.
Banyak juga hal-hal yang kayak kita lakukan secara paralel di program yang lain
yang kita memanfaatkan, Chrome dari si... Chrome jawab si Linux gitu ya.
Yang mana setiap waktu tertentu jalankan tugas-tugas yang sudah ada di queue.
Sama JavaScript engine-nya by design core-nya seperti itu.
Oke. Nah, terus kita lanjut ke pembahasan berikutnya tentang, masih tentang event loop.
Ini ada video yang menarik tentang event loop.
Kalau teman-teman tertarik mau belajar lebih lanjut bagaimana cara kerjanya.
Di sini video di tahun 2018 ya, sudah cukup lama.
Tapi penjelasan, yes, penjelasan yang sangat luar biasa bagus.
Dan satu lagi sebenarnya ada ini nih, ini juga keren juga nih.
Sering apa, beberapa kali saya jadikan referensi juga.
Nanti akan dibahas, eh kak, setelah ini.
Dan ada yang mau dijelaskan dari video ini, Ivan?
Ya, bisa-bisa. Jadi di video ini ya, kalau kita lihat dari sisi tengah itu, itu yang looping-nya.
Dan di sebelah kiri itu adalah worker-nya, worker queue yang sedang menjalankan.
Queue-nya paling kiri kan yang urutan T itu.
Itu queue-nya. Sedangkan yang kuning yang di tengah itu, itu adalah proses worker-nya untuk mengeksekusi queue itu.
Sedangkan yang sisi sebelah kanan itu adalah proses rendering.
Ya, jadi proses rendering dari si browser itu.
Jadi apa istilahnya? Paint, proses paint untuk si DOM.
DOM yang sudah dieksekusi, hasilnya dipaint ke browser.
UI bahasa simpelnya.
Ya, sama sih ngomongnya.
Nah, yang terjadi adalah begini.
Pertama video ini membuka mata saya, bagaimana proses JavaScript itu bekerja.
Karena background saya itu banyak berkutat dengan PHP, semuanya semuanya synkronus.
Dan saya udah tahu nih kalau saya bikin kode di line 1, line 2, line 3, line 4.
Saya tahu tuh 1, 2, 3, 4 pasti akan dieksekusi secara berurut gitu ya.
Sedangkan di JavaScript itu berbeda.
Ternyata pakai yang istilahnya banyak hal yang disebut callback lah.
Atau kalau misalnya saya fetching sesuatu dari API,
kalau di PHP, saya fetch API, dia nunggu respon dulu baru selesai.
Responnya mau error atau mau success, saya bisa langsung baca tuh hasilnya.
Sedangkan kalau di JavaScript, responnya itu belakangan.
Responnya pending doang kalau dipanggil di line selanjutnya.
Iya, nah.
Jadi, yang terjadi adalah si worker kalau nggak ada kerjaan, dia akan muter.
Akan looping bahasanya, bahkan looping aja.
Begitu ada task, dia akan jalankan satu per satu.
Di JavaScript Engine, di core-nya itu, itu pasti single-track.
Saat ini masih single-track, artinya hanya menggunakan satu proses trading di CPU aja.
- Jadi tidak bisa... - Hanya bisa mengedikan satu kerjaan dalam satu waktu ya.
Betul sekali, jadi nggak bisa multi-trading.
JavaScript setau saya sampai saat ini belum bisa multi-trading.
Jadi, kalau misalnya dia muter dan melakukan sesuatu,
dia akan menunggu ada hasil dan begitu ada tugas, dia akan kerjakan.
Dan kalau misalnya tugas itu butuh ada pain, nanti dia akan update di DOM
dan akan pindah ke proses untuk pain.
- Ke loop yang sebelah kanan ya? - Iya, betul.
Nah, ini...
Ini tadi karena kode-nya tadi kan yang dicoba itu adalah wild loop.
- Ini pakai se-timeout. - Nah, itu dia.
- Jadi nggak nge-blocking. - Definit.
Nah, jadi dia...
Jadi makanya si JavaScript ini itu unblocking process.
Oh, mungkin bisa dimunurin sedikit videonya ke kiri sedikit.
Jadi pertama kali dia nyontohin yang pakai wild loop yang always true.
Jadi itu kalau dampaknya di UI kan, kadang mungkin kita pernah kena error yang freeze.
Nggak bisa diapapain atau nggak bisa di-select.
Po-nya beneran freeze, pas dilihat di console log-nya ada maximum call stack exceeded.
Nah, contoh pertama tuh tentang itu.
Karena si task-nya itu beneran nggak pernah selesai, nggak pernah pergi dari queue.
Nah, itu di contoh pertama yang pas wild true.
- Itu kayaknya kiri lagi deh. - Kiri lagi.
- Terus... - Mana?
Contoh gambar kucing juga, cuma po-nya contoh pertama yang tadi ada gambar animasi gif kucing.
- Oh, gif kucing tadi di mana ya? - Tapi yang pertama.
Yang pertama? Wah, lupa. Ini bukan.
Nah, itu kayaknya coba deh.
Tapi intinya sebenarnya JavaScript itu dia ini ya, bahasa yang selalu sangat mudah untuk move on.
Jadi ketika ada task dan task-nya belum selesai, dia langsung berjalan aja.
- Ya udah tinggal aja dulu. - Karena memang dia naturalnya seperti itu.
Kalau di web, misalkan kita butuh apa ya, butuh webcam, permission untuk webcam.
Kalau usernya belum klik allow atau block, ya webnya tetap bisa loading kan, tetap bisa...
webnya tetap terbuka walaupun ya webcamnya adama-adama nggak ada gitu kan.
- Ya, karena unblocking. - Ya, dia tinggal, dia anggap berarti nggak mau.
Berarti kalau dia punya internal algoritm, internal logic, kalau misalnya usernya tetap nge-scroll
dan mengabaikan permintaan enable webcam, ya udah berarti dia nggak mau.
- Oke, move on. - Move on.
Satu-satunya yang nge-block adalah alert. Makanya alert jalan dipakai kan, untuk UX kurang bagus.
Karena ketika kita jalankan alert, itu di belakang itu udah berhenti.
- Emang dengan sengaja di-freeze semua. - Iya.
- Nah ini juga berhenti sih. - Iya, kita buka Facebook atau buka Tokopedia gitu ya.
Meskipun datanya belum nyampe, tapi sudah ada skeleten-skeletennya kan kelihatan.
Itu adalah salah satunya dimungkinkan karena asingkronus ini.
- Ya. - Lanjut, lanjut.
Yang ini tadi, when while loop itu makanya dia bisa nge-hang.
Jadi kalau mau kerjain, kalau mau kerjain, kok malah nggak jarin yang ngejelek sih.
Nah kalau ini kan contoh yang contrive, ya maksudnya apa, di JavaScript jarang banget sih bisa blocking
kecuali beneran bikin function yang kayak gini nih, while true.
While true ya akan selalu true maksudnya. Jadi kan si tugasnya itu, si task yang warna kuningnya itu
nggak pernah selesai, jadi si event loop-nya yang kotak putih itu ya nggak pernah bisa keluar, nggak bisa lanjut.
- Nggak bisa ke arah sebelah kanan ya. - Nggak bisa muter, emang ditahan terus.
Dan biasa itu bakal ada error, apa, maximum call stack exhibit kan.
Artinya apa juga di sini, kalau dari sisi ini, kalau misalnya kita punya JavaScript-nya kegedean
atau berat bahasa istilahnya, berat, itu bisa membuat scrolling kita kerasa jengky kayaknya.
- Oh iya. - Kayak dia nggak smooth gitu.
Itu karena JavaScript kita banyak banget eksekusi atau, jadi proses loop-nya itu terus ngerjain tugas
dan untuk proses rendering-nya dia jadi telat.
- Dia nggak ngerender dengan benar ya, nggak bisa ngerender dengan benar karena dia tinggal-tinggal kerjaan yang lain.
- Iya, karena proses waktu dia ngerjain task-nya itu kelamaan.
Yang menjadi target kan untuk kita kasih pengalaman experience terbaik untuk ke user itu kan,
rata-rata mobile phone yang sekarang itu kan screen-nya sudah 120Hz ya,
atau 90Hz atau 60Hz lah minimal gitu ya, refresh rate-nya gitu ya.
Maka pane yang bagus itu ya minimal di 30 gitu ya, supaya terasa scroll-nya itu terasa apa istilahnya, smooth gitu.
- 30 fps ya berarti ya. - 30 fps.
Nah ini contoh selanjutnya nih, apa sorry, yang tadi kan while sebenarnya coding-nya sama,
tapi dipindahin ke set timeout dengan delay-nya 0ms ya, sama kayak yang tadi dicontohin.
- Coding-nya mana? Ini ya? Mana tadi? Ini ya? Eh susah ya.
- Nah while true kan yang blocking ya? - Ini yang pertama.
Yang kedua dipindahin ke set timeout aja, cuma di set timeout dulu.
Nah jadi dia bisa muter karena tadi kan yang set timeout itu dipindahin dulu,
itu kan sebenarnya recursive loop juga kan, di argument apa callback function-nya itu loop kan,
itu kan recursive function tapi dia nge-blocking, karena ya itu tadi yang dijelasin di paling awal.
Kan dia pindah dulu ke web API, pindah ke queue, antrian, dimasukin satu persatu.
Jadi walaupun recursive tetap bisa melakukan semua task itu tadi.
- Dia ngambil task-nya tetap. - Jelasnya kayak gini nih.
Nah muncul lagi kan, si event loop-nya, mekanisme event loop itu memanggil task-nya satu persatu dari antrian, dari queue.
Jadi walaupun recursive, emang recursive, gak ada abisnya kan tuh muncul lagi, muncul lagi.
Tapi dia bisa muter, bisa jalan, jadi tetap bisa styling, layout, paint, give-nya bisa muter.
Give-nya bisa muter, dia bisa select text dan lain-lain. Itu tadi ilustrasi.
Yang bikin aku paham event loop itu apa.
Nah gimana tadi soal request animation frame, nyambung juga sama ini sih ya, apa?
Video ini kayaknya ada tentang animation frame juga ya.
- Dia di belakang, soal request animation frame, request adjunct callback. - Ini bukan.
Wah iklan dulu.
Sambil iklan. Nah berarti kalau frame rate-nya 60 Hz, berarti bagusnya tadi animation-nya justru 30 ya separohnya.
Iklan lagi, aduh banyak sekali iklannya. Lanjut, lanjut, lanjut.
Itu gak ada, itu bukan sebuah teori atau hard and fast rule. Jadi sebenarnya jangan sampai di bawah itu.
- Jangan sampai di bawah 30? - Iya, kalau di bawah 30 frames per second artinya
sudah mulai terasa jengky, mata kita sudah bisa lihat kalau itu terasa patah-patah.
Gimana cara ngecek sebuah web itu 30 fps atau belum?
Ada kayaknya ini ya, ada API-nya, gue lupa, ada tulisan, gue lupa.
- Ntar gue cari deh, gue lupa, ada API-nya kok. - Oke lanjut.
Ini apa? Oh ini yang soal animation callback.
Ini artinya maksudnya gini, kalau kita punya JavaScript code, jangan sampai kelamaan ya memanggil
atau melakukan sebuah tugas, kalau bisa dilakukan kecil-kecil maksudnya.
Jadi biasanya kalau kita menggunakan untuk yang banyak melakukan pain atau melakukan manipulation.
Contoh paling gampang slider ya, slider itu supaya bisa smooth gitu kan harus ada
kalkulasi perubahan X dan Y position ya, itu kan bisa terjadi sliding.
Yang itu sebisa mungkin saat kita melakukan itu jangan sampai proses sliding-nya itu
memberatkan, membutuhkan lebih dari, kita bisa bikin kalkulasi supaya dia
dipecah-pecah 30 fps, bisa dihitung lah istilahnya.
Oke, kita lanjut ke pembahasan dari Eka tentang web API.
Tadi kan sempat ada ya, sempat ini ya, ini kan ada call stack, kemudian ada queue,
kemudian ada heap, dari JavaScript engine-nya, dari fungsi kode yang kita tulis masuk ke
call stack, kalau dia butuh di delegasikan misalkan membaca file, nampilin notifikasi
dan lain-lain itu dia kan memanggil atau menyerahkan kepada API, web API dalam hal ini.
Web API itu sendiri adalah sebuah API. - API yang ada di browser.
Jadi cerita aja sih ini, kebetulan kali ini aku nggak punya materi yang teknikal banget,
jadi lebih kecerita soalnya apa, kan Papiknya ngebahas event loop nih, jadi inget dulu
pertama kali banget belajar JavaScript, mungkin agak beda dengan teman-teman yang
lainnya, aku belajar JavaScript itu nggak dari backend sama sekali, dan bahkan
bukan dari dunia pemrograman, jadi kayak cuma iseng-iseng aja, terus jadi belajarnya dengan
cara yang salah, pokoknya kalau ada alur belajar yang salah, itu kayaknya semua
kesalahan dalam belajar coding, itu kayaknya gue udah ngelakuin semua.
Jadi pertama kali mulainya cuma di HTML, CSS, cuma ya udah, udah rada basah
dikit nyemplung sekalian kan JavaScript, cuma ya mungkin karena approach-nya kurang
tepat, cuma apa sih, Googling aja cari, terus kopas-kopas, terus dulu jamannya
jQuery, jadi mungkin, apa, jQuery-nya sih nggak apa-apa, cuma mungkin
pemahamanya kurang kuat juga, jadi apa, suka banyak kesandung dikit lah.
Nah, dulu tuh aku belum paham tentang web API, karena kan ini bukan di level
yang praktikal ya, semua kalau misalnya orang yang murni awam dan baru belajar
dan nggak ngikutin kurikulum yang baik dan benar ya, mungkin ngerti-nya semua itu
JavaScript, udah gitu doang. Nah, padahal sebetulnya kan browser punya
JavaScript Engine yang tadi udah dibahas kayak Chrome punya V8, yang jalan di
Node dan Dino juga, Firefox punya Spider Monkey, nah JavaScript Engine itu
bisa menjalankan atau memproses JavaScript berdasarkan standarnya
ECMAScript, ya udah itu, cuma kan itu stand alone, nah browser sendiri kan
sebetulnya punya yang namanya itu web API, yaitu implementasi JavaScript
dengan menggunakan standar ECMAScript juga, yang dibuat khusus untuk browser
dan otomatis hanya berjalan di browser, nah makanya dia kenapa ada API itu,
dia kan buat ngejawab kebutuhan-kebutuhan yang unik atau yang khas,
cuma buat ada di browser, makanya tadi kita punya apa itu, ada animation,
ada rendering, ada apa, layout, styling, painting, ya kalau di server-side kan
dibutuh ngelakuin hal-hal itu ya, walaupun prinsip, apa, prinsip queue-nya
bahwa ada task yang harus queue, yang harus di queue, ada pekerjaan yang
harus diantri, ya emang sama, cuma kan kebutuhan-kebutuhannya unik di web,
jadi ini hal yang menarik sih, jadi mungkin kalau temen-temen ada yang
masih di level baru nyoba-nyoba ngulik kodingan di web, khususnya front-end,
nah mungkin ini bisa dibaca sendiri, di cek, paling enggak dimengerti bahwa
browser itu bukan murni hanya berisi JavaScript engine aja,
tapi ada implementasi khusus untuk media web untuk browser yang namanya web API,
itu akan nyambung banget sama apapun yang kita pelajarin, kayak tadi ada asynchronous,
ada call stack, ada event loop, ada queue, ini semua berkaitan kayak si set time out aja,
jadi set time out itu kan bagian dari browser API, walaupun dia juga ada di node,
nah di environment node-nya itu, implementasi set time out-nya itu sedikit berbeda,
minimal dulu sih kayaknya, di awal agak berbeda dengan punya browser,
karena masing-masing dia punya cara integrate sendiri,
jadi minimal kita tahu tentang adanya perbedaan, apa sih,
dimana suatu JavaScript runtime di eksekusi, itu web API, itu apa segala tentang web API.
- Mungkin ini ya, kita sudah sangat terbiasa untuk apa-apa pakai terpatri library,
kalau dulu kita mau request, kita harus pakai XHR, something-something gitu kan,
terus dimudahkan dengan adanya jquery.ajax aja atau .get atau .post gitu kan,
gampang gitu kan, padahal sebenarnya di JavaScript, di browser sudah ada,
walaupun agak tricky ya, pakainya agak susah gitu kan, akhirnya muncul face API,
bukan face API ini, di browser kita nggak perlu install kan, nggak perlu npm install,
nggak perlu pakai CDN dan lain-lain, kita udah bisa pakai by default,
ketika kita buka konsol gini aja, face aja udah ada gitu kan, kita bisa jelankan,
di sini sudah disediakan face, itu jadi kayak built-in-nya ya.
- Iya, bahwa unbuilt-in di browser.
- Iya, sudah built-in. Nah, bahkan node.js sendiri pun belum ada,
sampai baru beberapa bulan... - Barusan banget ini kan.
- Baru bisa. - Node 16 baru ada tuh ya.
- Iya, yang benar-benar fetch ya, kalau dulu ada fetch-fetch dibuat.
- Oh dulu node fetch, dulu kan polyfill ya, semacam polyfill.
- Ada isomorphic fetch lah apa namanya gitu ya, berbeda-beda gitu, jadi tidak built-in,
itu third party. Dan dari sana mungkin karena juga dulu JavaScript sejarahnya ya,
mereka tidak modular kan, tidak terlalu modular, jadi apa-apa ya bergantung kepada
script yang lain gitu. Sampai akhirnya si browser ini semakin apa ya,
semakin merasa, wah ini kayaknya butuh nih, akhirnya ditambahkan lah banyak-banyak apa,
berbagai API, ya tadi seperti fetch, kemudian bisa baca file, bisa banyak sekali nih.
Kalau teman-teman buka what-web can-do.today, bisa kita lihat nih,
kita bisa ada offline mode, ada background sync, kalau misalkan datanya apa,
kalau kita bikin aplikasi terus datanya mungkin agak banyak, kita bisa syncing data
di background untuk safe dan untuk baca, bahkan bisa payment ya, menggunakan Google itu ya.
- Bisa detect sensor juga sensor. - Detect sensor, NFC, Bluetooth,
USB, macem-macem, ada banyak. - NFC belum bisa Mas.
- Oh belum, belum, belum. - Bakal bisa, bakal bisa.
- Nah jadi si web API itu memenuhi kebutuhan khusus ya user yang menggunakan browser kan ya,
ya itu kalau kita pakai browser mungkin kita akan butuh apalah kamera lah, sensor segala macem
yang tadi ada. Nah salah satu hal yang ternyata setelah dikulik lebih jauh
bergantung sama browser kan network request tuh, jadi kayak caranya sebuah server,
node server misalnya menghendal network request, ternyata beda dengan cara browser
menghendal network request, makanya itu alasannya ya itu perkara fetch aja,
ternyata belum seragam apa, nggak seragam sampai baru-baru ini kan.
Jadi itu berguna banget buat tahu tentang mana yang bagian dari web API,
mana yang bukan. - Iya, bahkan kalau teman-teman butuh
apa ya, library untuk bikin sebuah, bikin kode untuk aplikasi web itu yang modular
atau yang dipecah per komponen, si browser juga udah ada API-nya kan custom komponen,
web komponen lah, itu sudah ada, nggak perlu kita install react, nggak perlu install view,
nggak perlu install macem-macem udah ada, walaupun bisa diakui cara penggunaan
ini memang agak... - Rada susah ya bikinnya rada susah.
- Rada susah, tapi bisa memungkinkan. - Biasanya kan pakai library
yang penengah lah, yang mudahkan kan ya. - Iya, untuk memudahkan aja.
Ada yang baru apa ya, shoelace ya. - Shoelace.
Gimana Ivan? - Iya, salah satu yang paling simpel.
Localization, bukan lokalizasi. - Internalization.
- Internalization, kalau misalnya kita bahas buat bahasa ya,
misalnya dari currency, dari yang USD, Indonesia rupee,
ada koma, ada titik gitu ya gimana. - Rupee, ada koma, ada titik.
Itu bayangkan kalau misalnya punya toko online lagi, kita harus,
kalau dia situsnya di berbagai negara, gimana kita satu codebase,
maksudnya kita mau parsing satu-satu untuk atau pakai JavaScript model mana
yang harus bisa untuk memisahkan, membedakan titik koma misalnya.
Di web sudah ada international... - INTL.
- INTL API, kayaknya ada di sini. Jadi tinggal pakai API itu, internationalization
sudah bisa terjadi, mau currency, mau tanggal, sudah ada, sudah bisa dipakai.
- Kalau dulu, kalau untuk tanggal, jam, waktu gitu,
biasanya pakai momen JS yang gedenya segede gaban ya.
- Betul. - Sekarang sudah bisa digantikan.
Contoh yang lain yang dulu sempat kita bahas, intersection observer.
Dulu kita harus mendetek di mana posisi tertentu sudah digantikan
sama observer yang ada di API. - Nah, observer juga maksudnya
mungkin ternyata sama si event loop, observer itu kan, makanya dia jalannya
di web API karena itu kebutuhan yang cuma ada di browser ya, itu unik.
Mustahil server kan nggak butuh observer yang untuk UI ya. Nah, ini kan observer-nya
macem-macem kan ya, kalau ada resize, ada visible,
kalau misalnya ketrigger, baru diantri in, task di callback-nya diantri in
buat dipungut, buat dicomot, dan dikerjain sama event loop yang tadi itu kan.
Nah, ini juga misalnya ini, apa, history. Kalau teman-teman ikutin kayak router,
react router atau yang lain, ya dalamannya ini, history API,
untuk go to routes tertentu, backward, forward. - Sampai kayak apa, yang buat
parameter juga kan itu sebenarnya ada interface ya kan, URL sama URL search params.
- Iya, ada push dan lain-lain. - Jadi library yang kita pakai under the hood mereka juga pakai itu.
- Sebenarnya, iya. Jadi kalau apa informasi-informasi web API kayak gini,
biar up-to-date gitu, ngeceknya dimana ya? Oh, ini ada API baru.
- Channel ini lah, biar up-to-date, subscribe channel ini.
- Subscribe channel ini dong. - Iya. Jadi kadang-kadang kita, ya itu, karena tadinya
si JavaScript ini kan secara natural dulu, menggunakan terparti itu udah kayak
no-brainer gitu kan, apa-apa, NPM apa-apa, CDN yang dicari yang pertama kan.
Tapi semakin kesini ya. - Mungkin kita perlu customize, pusing,
atau mungkin giliran ada bug atau isu atau apa yang nggak sesuai kebutuhan kita, baru deh pusing.
- Iya, itu dia. Makanya semakin kesini kita semakin butuh atau semakin apa ya, biar aware gitu
bahwa sebelum kita kesana, kita bisa gunakan dulu API yang sudah disediakan oleh browser.
Browser kan ukurannya tidak kecil gitu kan, dan sudah ada di install di masing-masing komputer.
Jadi itu yang kita manfaatkan dulu gitu. - Manfaatkan native-nya dulu.
Contohnya Parkour Detection API itu keren tuh. Kalau kita mau bikin sendiri kan sulit ya,
masa mau kirip data ke server, server-side deteknya, atau pakai apa tuh misalnya,
kalau kita mau pakai machine learning, blablabla, kan nggak bisa sulit.
- OSI-R, OSI-R. - Sudah ada. Sudah ada, tinggal dipakai.
Cuman belum semua browser ya, masih. - Chromium.
- Chromium. - Chromia Base.
- Iya. - Oke, lanjut ke pembahasan berikutnya.
- Lanjut, nah ini selanjutnya malah lebih ke pertanyaan sih.
- Apa tuh? - Gak, nyambung sama yang tadi tuh,
kan topiknya soal event loop nih. Terus kalau di sini sebetulnya
pertanyaan awalnya adalah kenapa kita perlu mempelajari hal-hal yang kelihatan pun nggak,
maksudnya kelihatan secara langsung pun nggak, seperti event loop, call stack, queue.
Tapi kan sebetulnya secara nggak langsung udah kejawab ya tadi.
Itu penting banget karena itu mempengaruhi behavior dan codingan kita yang kita jalankan.
Misalnya tadi tuh sama-sama sebuah function yang recursive, yang muter.
Tapi yang satu, blocking. Beneran ngefreeze, nggak bisa terjadi apa-apa.
Yang satu, nggak. Karena pakai set timeout kan kita perlu buat memahami hal-hal kayak gitu.
Nah, terus ya selain itu juga tadi sempat dibahas juga soal animasi.
Kita jadi paham apa, gimana caranya, kenapa kita harus apa,
nge-set animation frame dengan value tertentu,
karena itu berkaitan dengan cara kerja sih event loop itu.
Jadi kalau soal kenapa sih mungkin udah kejawab karena itu mempengaruhi codingan kita,
gimana kita merancang resitektur kode kita ya.
Nah, terus pertanyaan selanjutnya adalah apakah ini sebenarnya diajarin nggak sih ya di kurikulum?
Kalau orang yang, misalnya mungkin kuliah, kalau kuliah malah mungkin nggak ya.
Kalau bootcamp, ini diajarin nggak sih? Sebenarnya secara proper?
Eh, nggak tahu ya. Saya menyebutnya bootcamp saya, tapi bootcamp yang lain nggak tahu ya.
Ya, pengetahuan bootcamp ternama di Indonesia salah satu.
Mudah-mudahan diajarin ya.
Menurut saya, ini harus diajarin atau at least ada pembahasan ini.
Karena event loop ini dasarnya banget ya untuk event-driven di Java Sea itu dasar banget.
Salah satunya baru hari ini saya menyelesaikan sebuah tiket dikerjaan saya.
Itu requirementnya begini, situsnya ingin memberikan ads free.
Jadi ads itu tidak boleh muncul untuk member yang sudah plus member, sudah upgrade.
Premium member itu nggak bisa.
Karena dibayar buat ngeremov ads.
Ya.
Dia bakal marah kalau ads-nya muncul.
Betul. Tetapi situsnya itu nggak bisa menggunakan server set rendering karena dalam satu waktu,
karena konferensinya besar jadi cache, jadi ada cache ya. Jadi kalau login user itu kita tetap cache seperti biasa.
Dan semuanya harus sebuah JavaScript.
Kita nggak detect dia premium member atau tidak sebelum dia ngelon ads, contoh.
Apa yang harus saya lakukan supaya ads bisa tidak muncul?
Tetapi untuk proses premium membernya, beda thread, beda running-nya beda.
Ads-nya rendering sendiri, event-nya sendiri, ngecek premium membernya sendiri.
Akhirnya harus saya buat delay bagaimana supaya ini jalannya belakangan.
Ya. Saya nggak menggunakan callback. Tetapi saya menggunakan event-driven pakai dispatch.
Jadi kalau misalnya dia proses untuk nge-detect dia panggil API dulu, apakah dia premium member atau tidak.
Kalau dia premium, dispatch event.
Jadi bahasa yang sering dipakai Windows onload event, ada DOM content loaded event atau event-event lain.
Jadi saya dispatch custom event yang ads-nya ini menunggu.
Dia tetap bisa initialize dulu, dia menunggu kalau ada event ini nggak.
Kalau ada event ini terjadi baru dia ngerender ads atau tidak ngerender ads.
Jadi tanpa pemahaman event look, solusi itu tidak bisa saya buat.
Itu pentingnya bagaimana kita mau memahami event look, call stack dan web API.
Ya.
Tapi sebenarnya secara umum, ya kalau misalkan teman-teman belajar sebuah platform atau sebuah bahasa gitu ya.
JavaScript, Node.js atau bahasa-bahasa yang lain, PHP dan lain-lain.
Bukan hanya karena ada artikel yang bilang bagus, ada video yang bilang bagus.
Tapi basic curiosity-nya aja lah.
Ada yang bilang, "Wah Node.js lebih cepat dari PHP."
Kenapa? Karena sincronus.
Tapi kita sendiri nggak tahu sincronus itu maksudnya apa. Apa bedanya sama eksekusi yang ada di PHP.
Kenapa? Kok Node.js bisa cepat?
Padahal dia sama-sama, misalnya sama-sama high-level language kan.
Sama-sama scripting language, berangkat dari scripting language kan awalnya.
- Interpreter. - Interpreter.
Kemudian sama-sama kalau tidak dioptimasi, cuman bisa menggunakan satu core dari CPU.
- CPU. - Ya.
Terus kenapa yang satu kalah cepat dibandingkan yang lain?
Jadi dari curiosity itu kita harusnya bisa menggali lebih jauh, "Oh, si JavaScript ini unblocking."
Maksudnya unblocking itu apa? Kalau ada request, dia terima-terima aja walaupun dikerjainnya belakangan.
Sementara kalau PSP kan begitu ada satu request, dia tunggu dulu, "Eh, sabar. Saya masih ngerjain yang ini, tunggu ya."
Sampai selesai. Sedangkan di JavaScript proses menunggu itu ada di belakang layar.
Jadi kita kayak nggak dikasih tahu bahwa kita sedang menunggu, padahal tas kita juga belum dikerjain.
- Siap kos, yang penting sedang. Siap kos. - Iya, gitu lah.
Jadi dari situ juga kita bisa jangan sampai, "Wah, ini apa ya?"
Kalau kita belajar sebuah bahasa atau belajar apapun ya, belajar suatu yang baru, ada istilahnya itu apa ya? Unlearn.
Jadi hilangkan mindset. Misalkan tadinya PHP, kita taunya PHP.
Terus abis itu kita cobain JavaScript atau Node.js. Di PHP kayak gini, di Node.js kayak gimana ya?
Mungkin di awal begitu belajarnya, tapi makin ke sini kita juga harus tahu sejarahnya, filosofinya kenapa si Node.js ini dibuat.
Alasannya kenapa? Dulu banget si Node.js ini kan awalnya, kita itu kan jaman dulu susah ya, kalau kita mau upload file,
kita mau kasih progress bar, gimana caranya? Susah, setengah mati itu sebelum ada Node.js.
Karena blocking kan, pada saat upload, nunggu uploadnya selesai, baru bisa kita kasih tahu ke klien bahwa ini uploadnya selesai.
Jadi sebenarnya dulu progress bar itu hanya kira-kira aja. Ya, form upload dia kan waktu dia ngirim data itu kayak cuman muter,
browser muter aja gitu ya, nggak apa-apa. Kalau sekarang kan klik di background dia ngirimnya.
Betul. Pertama kali si Node.js muncul, yang bikin Node.js itu demo-innya adalah nunjukin progress bar pada saat upload.
Karena pada saat upload data, upload file di Node.js, itu sistemnya bisa dibuat asingkronus.
Jadi ketika file-nya udah dikirim, berapa persen, dia bisa ngirimin balik ke klien, memberi tahu bahwa ini 5 persen, 10 persen dan lain-lain.
Jadi dari situ aja kita bisa tahu kayak filosofinya, oh ini kenapa sebuah bahasa atau sebuah platform itu dibuat untuk menyelesaikan satu masalah.
Masalah utamanya dari situ nanti akhirnya berkembang, dipakai di mana-mana.
Itu perkembangannya pasti semua pasti ingin bahasanya dipakai di mana-mana gitu kan.
Tapi awalnya dulu filosofinya itu juga tidak kalah penting.
Dari situ baru kita bisa memahami lah, lebih memahami si bahasa ini.
Jangan sampai, karena JavaScript salah satu bahasa yang cukup salah dimengerti.
Tidak sulit di prediksi hasilnya, kok ini yang keluar duluan yang ini, padahal kita harapannya yang ini gitu kan.
Karena kita belum mengerti konsepnya.
- Betul-betul.
- Nah itu manfaat lainnya sih menguasain tentang event loop, karena sering banget,
ya aku pribadi dulu pas baru belajar cara yang salah tadi yang kopas sana sini, tapi gak mengahamin sebenarnya dibalik itu ada apa.
Ya itu kan kesul kan, kadang dicoba bener, urutannya udah sesuai ekspektasi.
A, B, C. A dari A kita dapat data untuk B, dari B kita dapat data buat C.
Terus ditinggal makan bentar, pas balik, tiba-tiba urutannya C, A, B. Pusing kan.
Nah itu kalau misalnya kita gak menguasain tentang asingkronos sama urutan gimana task di eksekusi, itu kan sulit dibaginya.
Jadi hal-hal tadi yang mungkin terkesan, maksudnya low level ya, browser engine banget,
mungkin kita gak lihat secara langsung sehari-hari itu sebenarnya berguna banget karena kita bisa pakai itu untuk itu tadi dibaging in the real world,
sama mungkin bisa ngebantu kita bikin keputusan-keputusan kali ya, misalnya keputusan untuk optimize performance ya kan tadi itu
yang soal animasi atau misalnya kita pakai react nih atau library sejenisnya yang punya algoritma virtual DOM,
ada yang berubah satu, bing, dirender ulang semua.
Nah kalau misalnya kita ada yang salah dikit tuh, use effectnya salah, itu bisa muter-muter kan, itu bisa kena itu juga tadi,
maksimum call stack gitu karena infinite free render ya, ngefreeze. Nah kalau misalnya kita gak menguasain tentang bagaimana browser, web API,
javascript engine, bekerja sama buat bikin siklus rendering, kita bingung kan kenapa tiba-tiba ngefreeze aja gak bisa di scroll.
Nah padahal itu berasal dari suatu logic atau alur di kode kita yang ngetrigger free render,
jadi itu kayak ngebantu kita buat ngefix apa yang salah atau optimize performance kode kita sih.
Yes. Dan kalau dilihat di sini, di selido, di bit.ly/ngobrolinweb, itu ada pertanyaan menarik yang berkaitan nih,
penggunaan promise itu biasanya buat apa? - Janji, celek.
- Janji. - Janji palsu gak? Ini bukan janji palsu. - Penggunaan promise itu buat apa? Buat asingkronus. Bener gak?
- Buat menjalankan operasi asingkronus dan kita bisa mengkustomise responnya ya. Promise itu kan bisa pending, resolve, reject.
- Recheck, ya. Kalau yang asingkronus-asingkronus, apa aja tuh tadi? Baca file, itu bisa asingkronus.
Karena hasilnya tidak instant ya. - Fetch, API, network request.
- Rata-rata yang baca itu read-write itu semua asingkronus, index.tv, local storage, system storage.
Baca file system. - Tapi kalau di Node.js itu beberapa API-nya ada 2 biasanya.
Dulu ya, jadi ada kaya read file sync. Read file-nya aja asingkronus, tapi read file sync itu yang asingkronus.
Mungkin sekarang akan dihilangkan semenjak ada sync wait, mungkin lebih sederhana kan jadinya.
- Ya, mungkin suatu hari dipercake. - Iya, mungkin. - Mau ngasih tau,
teman-teman kalau yang mau pakai promise, asingkronus, segala macam. Atau promise dan segala macam,
always catch error. Try catch, harus di dalam try catch. - Jangan terlalu otimis jadi orang berarti ya.
- Iya. Karena promise itu bisa throw error loh. Jadi kalau nggak di catch, semuanya bisa berantakan.
Jadi kalau eksekusinya file, tadi yang anak itu ngurusin kado, kalau satunya fail,
itu semuanya bisa nggak jalan. - Semuanya akan fail, iya.
- Nah, kayaknya besok-besok perlu ada mini topic promise juga ini soalnya lumayan banyak.
Jadi itu kan tadi jangan terlalu otimis bahwa error, jangan lupa untuk nge-catch error.
Tapi ada kasus yang semacam bisa dibilang ekspektasi awam kita tuh sebaliknya.
Jadi gini, kalau kita nge-fetch, kita nge-fetch melakukan request kan, response code bisa macem-macem kan ya,
kalau kepala 2 berarti sukses, kalau kepala 3 redirect, kepala 4 error.
Nah, kalau fetch-nya sukses, jadi kita berhasil memanggil melakukan suatu request,
di-return dengan response kepala 4, misalnya 401, unauthorized.
Nah, dibalikinya itu adalah itu nggak masuk di error, kecuali kita handle custom ya manual,
kita cek response code-nya apa. Nah, itu sempat...
- Salah API. Salah bikin API itu.
- Nggak, cuma ternyata wajibnya adalah fetch-nya sukses, lah kan berhasil.
Jadi network-nya ada, maksudnya gampangnya kita online, berhasil melakukan itu,
resource-nya pun yang dipanggil ada, cuma hasilnya, isinya user Anda, misalnya kita lagi nggak login,
atau mungkin user kita nggak punya privilege untuk ngelakuin sesuatu, ya otomatis response-nya 401.
Cuma fetch-nya sendiri kan sukses. Nah, itu kadang nyebelin di situ sih.
Ya, itu bisa diakalin dengan kita ngecek status code-nya, ya kita throw error sendiri.
Nah, itu seru sih. Belom ada itu tadi kalau promise all, yang tadi 7 anak ngurus kado,
begitu satu ngambek, langsung dibalikin semua, nggak nunggu sisanya kan.
Nah, kecuali kita pakai promise all settled, promise all settled nunggu sampai ketujuan anak itu selesai.
Di situ kita bisa ngelup mana yang sukses, mana yang jalan dengan baik, mana yang error, masalah.
- Untuk bisa ngerti promosi ini, harus nonton video yang tadi, event loop,
harus ngerti sampai sepaham-pahamnya dulu cara kerja event loop.
- Baru bisa dapet, oh, promise tuh begini tau.
- Ya, jangan lupa juga kalau mau belajar promise atau bahkan asing await,
belajar dulu dari callback, abis itu belajar promise, baru asing await.
Jadi jangan loncat langsung ke asing await, bingung entar.
- Iya, bingung. - Karena asing await itu adalah,
yang dipakai adalah objeknya promise. Kalau kita nggak ngerti promise, asing await pasti pusing.
- Atau mungkin kalau kita cuma kopas-kopas, asing await tanpa paham soal promise atau cara kerja asingkronos JavaScript sendiri,
mungkin bisa cuma jadi kayak apa ya, misalnya kita punya dua request,
kalau kita nggak memahami secara benar, secara mendalam, jadi kita bikin dua baris await,
padahal itu kan jadi kurang performa, karena kan sama aja jadi kayak PHP juga.
Maksudnya dia nunggu baris pertama selesai, abis itu nunggu baris kedua selesai,
padahal itu bisa pakai promise all atau promise all settled kan sebetulnya.
- Iya, kalau dua baris kode itu tidak saling berhubungan, misalkan dia tidak perlu menunggu sebelumnya misalkan
get ID, misalkan get ID gitu ya, dan ID ini dipakai di blognya.
- Nggak perlu responsnya. - Iya, nunggu respons dulu,
abis itu dia mau mungkin get address gitu, nah kalau itu perlu menunggu kan, jadi di await.
- Coba kalau misalnya satu get user, satu lagi get latest post gitu yang nggak ada hubungan ya sama data user itu.
Masa yang waktunya kan kalau dipaksa disuruh. - Jangan saling menunggu, karena buat apa gitu.
Kalau misalnya ditampilkan, ya berbarengan aja dua-duanya.
Jadi disitulah sebenarnya kelebihannya si Node.js dan JavaScript.
Dan disitu juga kekurangannya karena kita kurang mengerti cara penggunaannya.
Jadi itu bisa pisau bermata dua.
- Justru kalau ada kaya multiple await itu sudah salah ya, karena meskipun kita menunggu,
at least kita harus ada render sesuatu gitu di browser.
Kita nggak perlu menunggu itu hasilnya apa untuk bisa melanjutkan, sebisa mungkin ya.
- Sebisa mungkin. - Ya atau berarti itu hal yang beda dipisah lah,
harus kita bikin modular apa, fungsin yang lebih modular kan, kita ngakalin kode kita.
- Iya betul, jadi tetap ada yang dirender di UI, misalnya contoh,
oke kita butuh respons dari API baru bisa melakukan sesuatu,
tetapi kan proses rendering nggak perlu nunggu itu kan.
- Bisa kasih loading screen, spinner, atau apapun gitu ya?
- Iya, jadi biarin aja setelah call fix selesai baru kita lakukan proses selanjutnya.
Jadi nggak perlu nunggu, oh user name-nya apa, kita harus nunggu.
Jadi proses rendering ke stop karena kita menunggu hasil API,
baru bisa kita ambil user name-nya atau paling gampang avatar-nya,
baru avatar-nya bisa dirender gitu.
Nggak perlu gitu, kita bisa merender avatar loading screen, skeleton dulu,
kalau itu udah selesai di belakang, nanti sudah selesai baru call back, nge-replace.
- Nah itu kan si event loop tuh yang tadi yang apa, ngehendal dia ngerjain tasnya,
abis itu dia muter lagi ke bagian layout, styling, painting,
jadi sudah ada mekanismenya di browser yang mengoptimize itu kan ya?
- Iya, itu juga yang membuat si JavaScript ini berbeda dengan platform yang lain.
Karena platform yang lain belum tentu bisa melakukan itu kan.
Yang tadinya placeholder, terus tiba-tiba berubah jadi avatar gitu kan.
Nah itu mungkin di platform lain ya prosesnya akan berbeda.
Kalau di JavaScript ya nggak apa-apa, aman kita melakukan seperti itu,
karena dia akan update secara otomatis dalam tanda kutip gitu kan.
Itu yang juga penting untuk dipelajari ya.
Oke, kita sudah satu jam, ada lagi yang mau disampaikan?
- Enggak dulu. - Enggak, sudah cukup.
- Hal basic aja bisa, kita sejam ya. Menarik ya.
- Menarik. Dan buat teman-teman gimana?
- Meskipun basic tetapi butuh penting-penting-penting banget.
Kalau ingin jadi web engineer, penting banget untuk menguasai.
- Nah ini kan pendapat kita kan, pendapat kita fundamental, konsep dasar itu penting.
Menurut teman-teman gimana? Apakah episode ngobrol di web perlu membahas tentang fundamental
atau bisa kita selingi dengan hal-hal yang lain?
Boleh kasih komentar lah, kasih komentar mau di chat atau mau di selido,
di bit.ly/ngobrolinweb kita butuh masukannya supaya ada feedback loop ya.
Kita butuh feedback loop. Kalau JavaScript ada event loop, kita butuh feedback loop.
Supaya acara kita semakin keren, semakin diminati oleh teman-teman semua
dan semakin berwanfaat lah buat teman-teman gitu.
Jadi ditunggu pendapatnya, ditunggu masukannya.
Untuk hari ini kita mungkin udahan dulu. Terima kasih banyak buat teman-teman yang sudah hadir.
Kita ketemu lagi selasa depan insya Allah dengan tema yang berbeda juga.
Kita belum tahu apa, silahkan diberikan ide-ide menarik, nanti kita akan bahas.
Keren materinya sayang, saya telat.
Wah makanya itu ada lonceng, subscribe.
Nah itu adalah sistem notifikasi.
Jadi kalau misalkan ketika kita live nanti akan dikasih tahu gitu.
Itu callback juga namanya.
Jadi ketika kita live nanti akan di callback.
Kalau notifikasinya nyalah.
Teman-teman nggak usah ngeliatin HP terus ya kan, nggak apa kita live, ntar muncul sendiri notifikasinya.
Kalau nggak pakai yang standar aja pakai alarm setiap selasa jam 8 waktu Indonesia Barat.
Lihat web dev Indonesia, oke?
Terima kasih semuanya, kita ketemu lagi minggu depan.
Selamat malam, selamat istirahat, bye-bye.
Deskripsi asli dari YouTube
Konsep concurrency: async & paralel - https://blog.avenuecode.com/understanding-the-javascript-concurrency-model - https://dev.to/lydiahallie/javascript-visualized-event-loop-3dif Callback: - https://www.youtube.com/watch?v=cCOL7MC4Pl0 - https://developer.mozilla.org/en-US/docs/Web/API — konsep Web API, API yang hanya ada di browser, tidak ada di JS runtime lain - Kenapa perlu mempelajari event loop, call stack, dsb? Apakah diajarkan di kurikulum web development? Apa manfaat konkritnya, khususn Kunjungi https://ngobrol.in untuk catatan, tautan dan informasi topik lainnya.
Episode Terkait
2 Agu 2023
Ngobrolin Privacy Sandbox
Privacy Sandbox dibahas bukan sebagai wacana melainkan sesuatu yang harus disiapkan dari sekarang, karena dampaknya bisa...
19 Apr 2023
Ngobrolin CMS
Content management system dibahas sebagai kelanjutan alami dari episode-episode sebelumnya soal cara halaman dirender. C...
22 Apr 2026
Scam dan Penipuan
Episode ini membahas scam dan penipuan digital yang makin marak, dengan penekanan bahwa celah utamanya hampir selalu soc...
Suka episode ini?
Episode baru setiap Selasa malam. Dengarkan lewat YouTube, Spotify, atau feed podcast favoritmu.
Memuat komentar dari GitHub Discussions...
Jika komentar tidak muncul karena ekstensi privasi / adblocker, kamu bisa berdiskusi langsung di GitHub Discussions .