Optimasi Performa JS
Ringkasan Episode
Bantu KoreksiEpisode ini membahas tentang tips dan trik optimasi performa JavaScript, khususnya penggunaan atribut async, defer, dan dynamic import. Diskusi dimulai dengan Core Web Vitals, terutama INP (Interaction to Next Paint) yang menggantikan FID (First Input Delay) sebagai metrik responsivitas halaman. Tim NgobrolinWEB menjelaskan perbedaan antara script synchronous (blocking), async (dieksekusi segera setelah selesai di-download), dan defer (dieksekusi setelah DOM Content Loaded). Episode ini juga membahas kasus nyata seperti penggunaan jQuery, header bidding untuk iklan, cookie consent, dan bagaimana menghindari race condition. Terdapat diskusi menarik tentang Partytown untuk offload third-party script ke web worker, TypeScript, dan sejarah browser serta JavaScript.
Poin-poin Utama
- •INP (Interaction to Next Paint) adalah Core Web Vital baru yang menggantikan FID sejak 31 Desember 2024, mengukur responsivitas halaman saat interaksi user
- •Script tanpa atribut akan bersifat render-blocking dan menghentikan parsing HTML hingga script selesai di-download dan dieksekusi
- •Atribut async memungkinkan script di-download secara paralel dan dieksekusi segera setelah selesai, cocok untuk analitik dan tracking
- •Atribut defer menunda eksekusi script hingga DOM Content Loaded, menjaga urutan eksekusi sesuai urutan dalam HTML, ideal untuk vendor dan main script
- •Race condition dapat terjadi ketika script dependency di-load secara async, seperti jQuery yang belum siap saat script lain dieksekusi
- •Partytown adalah library untuk offload third-party script ke web worker, mengurangi beban main thread untuk tracking, ads, dan analytics
- •Diskusi juga mencakup Progressive Web Apps, pentingnya progressive enhancement, dan perbedaan antara TypeScript sebagai developer experience tool bukan performance tool
Halo-halo-halo, selamat malam!
Selamat malam, wiii...
- Keren. - Kita bisa live lagi.
Eh, kemarin juga live ya.
Live, cuma gue banyak baru bisa live lagi.
Iya.
Gimana, gimana apa kabar? Gimana live minggu lalu?
- Saya belum sempat ini... - Minggu lalu, wah, lumayan seru.
- Lumayan seru kita banyak belajar... - Tentang daily motion ya?
Iya, bagaimana menampilkan video dan tips dan triknya.
Karena kan, apa, video itu ternyata banyak sekali ya, apa...
Hal-hal yang harus dipikirkan.
- Mulai dari... - Wah, menarik. Kayaknya gue harus nonton itu.
- Gue belum nonton ya? - Iya, karena...
Iya, kalau... Iya, kalau...
Pernah saya ketemu Mas Yudi, Mas Yudi itu...
Di World Cam Tegal.
Iya, World Cam Tegal kayaknya.
Iya, kita ngobrol-ngobrol banyak soal daily motion.
Oh, oke.
Padahal sebenarnya dulu ya, waktu kenal awal sama Mas Yudi itu...
Saya tuh kenal branding-nya dia adalah...
Apa, accessibility.
Video itu juga menyangkut sama accessibility juga.
Iya, ada accessibility juga, betul-betul.
- Kemarin juga dibahas sih gimana... - Nggak luput.
Gimana menampilkan video yang accessible gitu buat semua orang.
- Jadi harus ada... - Jadi sudah tahu?
Iya, sudah dijelaskan lah ya.
Oh, ada ini, Pertamax. Ini pasti anak faskus ini.
Lihat transkrip lengkap (1101 segmen lagi)
- Alin-alin. - Nah, anak Pertamina itu.
- Anak Pertamina. - Tapi naikin ke Pertamax udah 1200-900 sekarang.
- Loh. - Iya.
Kok jadi kesana ngomongnya.
Jadi ketemu lagi kita malam ini seperti biasa di hari Selasa Malam.
- Waktunya ngobrol-ngobrol. - Ngobrol-ngobrol.
- Btw nanti Eka nyusul ya. - Iya, Eka belum ada.
Nanti lagi meeting dia, lagi meeting.
- Hah, itu dia orangnya. - Nah, baru diomongin.
- Udah diomongin, udah datang. - Hadir.
- Hello. - Hello, hello, hello.
Sudah selesai meeting-nya?
- Aman. - Aman.
Bisa gak sih ngejok gue masuk secara iseng?
- Masuk di deeper. - Kita belum bahas.
Bisa-bisa.
Kita mau bikin Pertamax JS. Loh.
BPJS aja BPJS.
- BPJS. - BPJS.
Oke, jadi malam ini rencananya kita mau ngobrolin tentang bagaimana tips dan trik lah ya.
Tips dan trik melakukan optimasi performa JavaScript.
Jadi sebagian besar yang akan kita obrolin adalah seputar async, defer, sama dan import.
Yang lain-lainnya juga boleh silahkan.
Jadi kalau temen-temen juga punya pertanyaan seputar bagaimana mengoptimasi JavaScript,
- Bisa ditanyakan juga di kolom komentar. - Silahkan lah ya.
Nah, kita mau ambil topik ini kenapa sih kita perlu async JavaScript, kenapa kita perlu defer.
Nanti kita bahas bedanya sama satu lagi.
- Apa satu lagi? Async, defer dan... - Dynamic import.
- Apa? - Dynamic import.
Dynamic import sebenarnya chunking ya.
Ngemotong-motong dan hanya load saat dibutuhkan gitu ya.
Lebih lat lagi deh ya.
Kenapa sih? Ujung-ujungnya adalah core web vital.
Adalah performance dari page load, dari user experience, nggak cuma page load ya, user experience.
Karena sekarang kan ada itu ya, ada... apa namanya?
Web vital yang baru, core web vital yang baru, baru setahun ini diangkat, yaitu namanya ENP.
Interaction to Next Pain.
Interaction to Next Pain.
Menggantikan first input delay.
First input delay.
Jadi FID sekarang sudah resmi deprecated ya, tahun 2024 tanggal 31.
Tidak dipakai lagi FID.
Jadi penggantinya Interaction to Next Pain.
Jadi JavaScript ini sangat berpengaruh sekali untuk ENP.
Pernah nggak sih teman-teman menggunakan situs, kalau di scroll itu sulit gitu, kayak dia nge-patah-patah.
Itu artinya Interaction to Next Pain.
Bagi di load, tiba-tiba edge-nya berusaha, berusaha nge-load, akhirnya yang kita tadinya cuma scroll,
scroll nggak terjadi apa-apa, tiba-tiba nge-scrollnya udah panjang.
Itu Interaction to Next Pain.
Beda ya sama itu apa namanya, kayak layout shift ya, ini bukan layout shift.
Jadi kayak, ya ini nih contohnya nih kalau di-click turunnya lama, tuh itu kan, nge-stuck gitu yang sebelah kiri tuh.
Oh, jadi ke-pack-nya 2 kali akhirnya dia height lagi gitu ya?
Bukan, jadi di-click nggak terjadi apa-apa.
Kalau di-click, di-click, di-click 2 kali, kan di-click pertama nggak terjadi apa-apa.
Klik 2 kali, bingung kan.
Nah, jadi karena nggak responsif, inilah WebVital.
Ini terjadi semua karena JavaScript.
Enggak juga sih. CSS juga pengaruh, tapi penyebab utamanya JavaScript.
Bahasa awamnya berarti ini pokoknya lemok ya, lelep.
Jadi kalau misalnya kita dapet input dari user bahwa, "Wah, website-nya lemok nih."
Ya, bisa koneksi, network connectivity-nya bisa, tapi kan maksudnya bisa aja berarti lemok atau lelep
itu maksudnya nggak responsif waktu user berinteraksi di halaman itu, kan?
Betul.
Perlejian. Ya, lezi loading lah ya.
Tapi untuk, bukan hanya untuk image.
Kalau lezi loading itu kan lebih ke image gitu ya, tapi ini lebih ke script.
Terutama JavaScript yang kita akan bahas malam ini.
Jadi GNP itu adalah bagaimana menilai sebuah halaman, responsiveness sebuah halaman
ketika user ingin berinteraksi dengan halaman tersebut ya.
Baik untuk click, atau tap, atau tombol atas, tombol bawah, scroll, dll.
Ini ada detail-nya lagi ya, oke.
Jadi untuk, salah satu untuk meningkatkan GNP ini, kita bisa menggunakan tiga hal tadi.
Yang pertama adalah script asing, devr, dan juga nanti dynamic import juga ada hubungannya.
Tapi kita akan bahas tentang elemen script dulu kali ya.
Elemen script itu ternyata perkembangannya udah banyak kan.
Kalau dulu kan cuma script kemudian type-nya apa?
Ada dulu text JavaScript awalnya kan.
Terus sampai situ muncul modul sama, apa? Type sama dengan modul.
Yang buat modul ES6 itu?
Type sama dengan modul?
Type sama dengan modul.
Sama dengan modul. Jadi bisa kita pakai ES modul gitu kan.
Terus ternyata sekarang juga ada banyak atribut-atribut yang lain.
Nah yang kita mau bahas ini asing ini.
Jadi kalau kita, kita panggil atau kita load sebuah JavaScript dengan script element.
Terus kita tambahkan asing atribut.
Artinya script klasik, script klasik akan didownload secara paralel.
Dan akan diavolusi ketika sudah selesai didownload.
Jadi kalau misalkan bedanya adalah kalau misalkan kita tidak menggunakan atribut asing.
Maka paste-nya akan menunggu.
Dia nge-download dulu tapi nggak melanjutkan parsing sisa script-nya.
Kalau bahasa ini, kalau tanpa atribut asing atau differ, dia akan menjadi synchronous load yang akan menjadi render blocking.
Render blocking, iya.
Jadi sama seperti kita lagi nge-load CSS.
Jadi waktu saat page load, nanti kalian teman-teman mau baca namanya Critical Rendering Path itu dari Ilya Grigorik.
Critical Rendering Path ada di web.dev.
Saat page ngerender, nge-parsing dari dokument type itu dari paling atas.
Terus kemudian dari head, body, sampai terus seterusnya.
Saat nge-parsing script, terus kemudian link CSS.
Kalau CSS, dia sudah pasti render blocking.
Karena dia menunggu CSS-nya selesai didownload baru dia terusin rendering-nya.
Sama kalau script tanpa ada atribut asynchronous, asing ini atau differ.
Browser akan stop proses rendering-nya sampai script selesai didownload dan dipars.
Dan dieksekusi.
Karena HTML, tag HTML itu dia sifatnya serial kan.
Jadi dari atas ke bawah.
Ketika sampai ke body, di body ada script.
Nah script ini yang akan didownload dulu, kalau script dengan SRC.
Yang akan didownload dan dieksekusi.
Baru kemudian ke divid root, baru kemudian ke sini.
Dan dia tidak akan ke bawah sebelum proses tag-tag ini selesai.
Kalau kita tambahkan script asing, maka ini dia bisa secara paralel berlanjut dulu.
Ini juga di belakang layar, mungkin dia sambil download.
Begitu sudah selesai baru dieksekusi.
Jadi agak ditunda sedikit ya.
Ditunda apa? Bukan ditunda ya istilahnya ya?
Tidak ditunda sih, tapi...
Bukan.
Kalau as...
Bukan single-credits kan ya?
Cuma fetching-nya itu di background ya?
Berarti fetching-nya itu running di latar belakang.
Dia nge-fetch di belakang, maksudnya di background.
Di thread yang...
Tidak sih, tetap di thread yang sama, tetapi...
Cycle-nya, tau gak sih yang loop itu?
Event loop.
Event loop, tetap nge-jalanin.
Tetapi dia akan didownload dulu.
Setelah selesai didownload, langsung...
Immediately dieksekusi.
Kalau asingkronus.
Jadi kalau analogi lucu-lucuannya itu kayak pesan makanan, order makanan.
Jadi kita lagi mau kerja nih.
Kalau misalnya yang tanpa asing itu kan...
Kita harus pergi ke warung atau rumah makan.
Kita harus keluar, ambil kendaraan.
Kita pergi ke warung, beli makanan.
Dibungkus di sana atau dimakan di sana, nunggu.
Baru balik lagi, baru bisa kerja lagi.
Kalau ini kan berarti kalau asing, kayak kita order dari aplikasi...
Apa? Makanan dan semacamnya.
Kita order aplikasi, sambil nunggu...
Makanannya dibeliin, disiapin, kita sambil kerja.
Iya, betul-betul.
Jadi ketika makanan yang nyampe...
Ya kerja kita berhenti, kita makan dulu gitu ya.
Oke.
Ini ada kemiripan.
Kemiripan dengan Defer.
Juga masih di elemen script ya...
Ada atribut yang namanya asing...
Dan ada atribut yang namanya Defer.
Bedanya adalah...
Ada nggak di sini Defer?
Bedanya kalau Defer itu...
Dia sampai setelah DOM Content Loaded selesai di eksekusi...
Artinya si JavaScript-nya akan di-queue dulu nih.
Setelah selesai semuanya sampai...
Si browser ini selesai ngerender sampai DOM Content Loaded ke eksekut...
Which is...
Sudah sampai...
Footer lah ya bahasanya sih, sampai bawah di-close.
Sampai bawah di-close.
Selesai, semua aset-aset sudah selesai di-download.
Lalu JavaScript ini mulai di satu-satu...
Mulai di-download, di-parse, dan di-eksekusi.
Jadi udah di paling ujung setelah...
Sebenarnya teknisnya...
DOM Content Loaded, di-eksekusi, di-fire...
Lalu JavaScript-nya di-download.
Dan ini yang aneh, bukan aneh sih...
Ini kan dua atribut berbeda.
Bisa dipakai dua-duanya, kalau mau.
Hmm, oke.
Jadi, kalau dulu kan kita ngakalinnya...
Awalnya kan script itu adanya di-head.
Di-head setelah title atau meta gitu kan.
Di-tag-head gitu ya.
Terus abis itu...
Ada trend yang menyebutkan...
Trend harus dibawah sebelum body tag.
Sebelum body tag.
Iya.
Maksudnya itu kan dia sebetulnya biar render-nya.
Biar UI-nya, DOM-nya dipainting.
Proses painting-nya jalan dulu.
Minimal kan udah muncul sesuatu di layar.
Habis itu baru...
Fetchingnya pas script dan lain-lain.
Dan dengan property atau atribut ini...
Kita gak perlu di-header lagi.
Mau dimana aja tetap menggunakan devr atau asing.
Dia akan melakukan hal yang mirip.
Dan kalau buat asing sama devr ini...
Ada artikel yang bagus tuh penjelasannya.
Buka yang di Google Docs.
Ini ada perbandingannya.
Dan seperti biasa dulu...
Pertama kali kan penasaran banget sama asing devr.
Baca MDN, baca Docs, gak ngerti-ngerti.
Pas baca artikel itu langsung ngerti.
Hebat.
Tapi pas baca MDN tetap aja baca kalimat...
Kan bentuknya kalimat paragraf itu tadi penjelasan.
Yang manggut-manggut, soal tau, begitu selesai baca, apa lagi?
Soal tau.
Nah ini kan script yang tradisional.
Ini yang standar ya, tanpa ada tribut apa-apa.
Ini yang tadi kita bahas.
Terus...
Begitu HTML parser menemukan ini...
Maka akan nge-load scriptnya, scriptnya di-execusi.
Di-execusi.
Semua itu selesai baru mem-parsing...
Kebawahnya baru bisa dilanjutin.
Itu yang tadi kita bahas.
Ya, jadi ada impact terhadap loading time.
Kalau kita tunggu, scriptnya selesai di-execusi.
Kalau scriptnya memakan waktu yang lama...
Maka parsingnya juga akan jadi kayak blank page aja ya.
Alaman putih.
Sisa alamannya.
Nah, ini kalau kita menggunakan cara...
Tradisional seperti ini...
Posisi script akan mempengaruhi loading time.
Jadi kalau kita taro di head, berarti dia nungguin...
Kalau kita taro di head, baru dia ke body.
Kalau kita taro di bawah, penjelasannya di situ juga.
Artinya...
Posisi menentukan prestasi.
Prestasi. Nah, itu kan beneran position matters.
Itu tadi...
Yang baru sampe kita bahas.
Asing soalnya.
Itu kan di-divert tadi, di-divert.
Ya, posisi menentukan prestasi.
Kalau kita taro di head, dia akan...
Load ini dulu, baru dia ke body.
Yang mungkin menyebabkan alaman web kita...
Ada alaman putih dulu.
Kalau scriptnya, apalagi scriptnya gede gitu ya.
Atau melakukan pekerjaan yang berat.
Nah, kalau kita taro di bawah, mungkin itu akan jauh lebih baik ya.
Jadi setidaknya HTMLnya keliatan dulu.
Kecuali kalau...
Menggunakan metode client side rendering.
Gak ngaruh. Soalnya...
HTMLnya isinya div dengan id root kosong.
Sama aja. Gak keliatan juga.
Kan biasanya terjadi flash of unstyled.
Flash of unstyled content.
Jadi putih baru ke log.
System font semua.
Ya.
Nah, kemudian...
Nah, ini yang kita bahas tadi tuh.
Pada ke-2 common solution, script tag-nya ditaro di paling bawah.
Di sebelum closing body tag.
Nah, kalau kita seapus itu harus men-support browser yang...
Belum bisa asing divert.
Dan itu lama banget kayaknya, mungkin browser.
Lebih dari 5 tahun yang lalu kali ya.
Nah, itu ya...
Solusi lama, solusi old school.
Sebelum closing body tag itu ya bisa dipakai.
Nah, kalau solusi yang baru itu tadi.
Itu asing dan divert.
Asing dan divert.
Asing dan divert keduanya cara penggunaannya mirip.
Jadi tinggal tambahkan atribut asing.
Atau divert. Nah, bedanya yang tadi ya.
Dan itu dia akan melakukan...
Pekerjaan secara paralel atau...
Secara sincronus lah ya.
Soalnya nggak bilang paralel ya.
Soalnya kan single thread kan.
Jadi mungkin dia akan melakukan...
Menunda, bukan menunda ya.
Akan melakukan men-download fetching.
Fetching script dan juga eksekusi.
Ketika main thread-nya lagi...
Tingkat kesibukannya rendah.
Tidak terlalu sibuk, lagi udah...
Pekerjaannya udah berkurang.
Sedangkan Devar, Devar ini dia menunda.
Menunda proses download...
Atau fetch dan eksekusi script ini.
Setelah...
HTML-nya diparsing gitu ya.
Bukan.
Maksudnya Devar kan?
Devar, Devar, iya.
Script Devar ini artinya menunda...
Sampai dom-content loaded.
Oh, dom-content loaded, iya.
Beda event, beda trigger-nya.
Sampai dom-content loaded di event nggak faham.
Dom-content to dom-content loaded...
Artinya sampai...
Dom-nya semua selesai di-download.
Sampai di-download.
Bukan di-render ya, di-download.
Siap.
Nah, disini ada ininya ya.
Ada perbandingan secara ininya ya.
Oh ya, itu ada ketangannya yang menarik sih.
Tadi sebelumnya ini semua...
Itu ngaruh kalau kita masukin scriptnya di-head.
Kalau misalnya script tag-nya sebelum closing tadi...
Di-bawah nggak ngaruh?
Ya nggak ngaruh juga kan, terakhir. Udah keluar semua kan.
Jadi yang kadang saya bingung...
Dia sudah taruh di paling akhir JavaScript-nya...
Tapi dia Devar lagi, iya.
Nah, cuma ini tipe-tipe pertanyaan interview from N nggak sih?
Terus jelasin.
Oh iya, benar juga.
Ini sinis-sinis hal-hal trivia-trivia yang bisa mumpuli.
Mendasar, mendasar.
Apa fundamental ya? Bagian dari fundamental ini?
Anyway, ini nih, pas lihat grafik ini...
Langsung ngerti, langsung paham.
Apakah kalau kita terbiasa menggunakan framework...
Tetap ini, tetap relate?
Ya, kalau besok ganti framework...
Atau kalau harus handle...
Eh, kalau pakai framework...
Kalau kita pakai script external, GTM lah, apalah...
Itu kan kita harus nambahin script head sendiri juga.
Oh iya, benar juga.
Walaupun di next head, head component itu...
Yang head pakai hal besar itu...
Kita harus paham eksistensi atribut-atribut ini...
Dan kenapa pakai itu.
Benar, benar.
Jadi, kurang lebih kayak gini ya. Mulai parsing HTML...
Terus kalau ini tanpa ya...
Tanpa deferral atau parsing, dia akan fetch script...
Eksekusi, baru kembali parsing HTML lagi.
Nah, selama yang magenta biru itu tetap jadi...
Abu-abu itu kan weight...
Weight itu beneran kosong, putih, nggak apa-apa.
Ya, halaman kosong.
Kalau menggunakan, apa nih?
Masih pakai yang lama, tanpa deferral asing...
Tapi script tag-nya ditaruh di bawah.
Nah, jadi lebih oke karena kan...
Udah selesai parsingnya.
Kalau dengan asing...
Maka parsingnya tetap jalan...
Berbarengan dengan fetch script.
Download scriptnya.
Yang tadi kita pesan makanan...
Mas Gojek-nya pesan pergi ke warung...
Warungnya masak, kita sambil aktivitas juga kan.
Tetapi, begitu makanannya datang...
Kita makan dulu.
Ya, berhenti.
Oke, oke, ngerti, ngerti, ngerti.
Habis itu, baru balik kerja lagi kan?
Setelah selesai makan, kerja.
Kalau defer...
Skripnya, makanan kita pesan...
Tapi kita selesai makan dulu.
Tapi kita harus nyelesain kerja dulu.
Kita selesai, baru boleh makan.
Kalau analoginya pakai makan...
Gampang ya.
Baru nyambung ya.
Nah, gue dapet ide soal analogi makan itu...
Gara-gara baca artikel ini sih...
Mungkin ada laper juga ya pas baca itu.
Jadi pas ngerti-ngerti, ini kayak pesan makanan.
Pas baca MDN tadi...
Defer, atribut, blablabla.
Yang paling sering menjadi pertanyaan...
Kapan pakai sincronus...
Kapan pakai asinkronus...
Dan kapan pakai defer.
Gimana tuh?
Ada penjelasannya.
Dom interactive script smart defer...
Di eksekusi setelah...
Dom interactive event.
Berarti kan kalau butuh seluruh domnya udah selesai...
Ya pakai defer kan?
Nah...
Teman-teman coba ada yang...
Ini nggak punya kasus?
Contohnya kasus.
Kasus pertama.
Pernah relay nggak tiba-tiba?
Pace-nya kadang error...
Mengatakan jQuery-nya nggak exist.
JQuery non-exist sehingga dollarnya jadi nggak bisa.
Atau jQuery load apa ternyata nggak bisa.
Terus kadang bisa.
Tapi kenapa?
Padahal kodanya nggak berubah.
Itu karena kita akal-akalan...
"Ini jQuery kok gede banget ya?"
"Coba di asinkronuskan saja."
JQuery yang di asinkronuskan...
Script line...
Tidak di asinkronuskan.
Script line di asinkronus juga.
Akhirnya yang terjadi adalah balap-balapan.
Begitu balap-balapan terjadi race condition.
Script kalian jalan duluan...
Selesai di download dan di-execusi...
Tetapi jQuery-nya masih on the way.
Ibaratnya kalau soal makan...
Makanannya datang duluan...
Tetapi sendoknya belum datang.
Nggak bisa makan juga gitu ya?
Akhirnya yang mau makan error.
Kecuali pesan makanan padang nggak apa-apa ya.
"Akan pake tangan lah."
Atau tangannya datang belakangan.
"Luh kok ini jadi seram?"
Kan mau duluan ceritanya.
"Ayamnya ditunggu belakangan, nasinya ditunggu dulu."
Atau pesan makanan beda-beda.
Ada nasinya dimana, ayam penyeknya dimana...
Terus ST-nya dimana.
Di sini lah analognya makan nggak bisa dipakai lagi.
Race condition kan.
Mau makan ayamnya dulu datang, nasinya mana.
Benar, benar.
Gak bisa.
Kalau misalnya...
Apa namanya?
Asal pakai...
Tanpa mengerti fundamental bagaimana...
Cara bekerja, "Ah, mau biar cepet nih."
Katanya pakai asing atau pakai differ.
Ternyata semua dibikin asing atau semua dibikin differ.
Biar cepet gitu ya, tujuannya biar cepet.
Page load-nya cepet gitu.
Yang terjadi adalah error.
Nanti semua error bingung. Kenapa?
Terus, next-nya gimana dong?
Kalau jQuery kan atau React library-nya kegedean.
Gimana dong?
Atau biasanya vendor kan.
Vendor JS-nya kegedean.
Main JS-nya 2 MB.
Vendor JS 2 MB, main.js-nya 100 KB.
Contohnya.
Tetapi kan vendor harus duluan kan.
Supaya main.js-nya ada.
Karena dipakai kan.
Jadinya kalau dibikin asing pasti kacau.
Karena yang pasti duluan selesai di download pasti main.js.
Karena satunya 100 KB, satunya 2 MB.
Nah, disinilah perlu yang namanya...
menggunakan, misalnya kalau kasus yang vendor dan main,
ya pakainya differ.
Karena differ itu eksekusinya disesuaikan dengan...
waktu dia di queue.
Urutannya akan sama dengan urutan saat dia ditemukan.
Jadi kalau vendor duluan yang di-diver, baru main.
Nanti saat selesai di download, vendor duluan diparsing, baru main.
Pertanyaannya kapan asingkronos dibutuhkan?
Kalau perlu secepat mungkin diproses ya.
Analitik biasanya ya.
Kalau kita pengen ngitung, apalah time to first, blablabla.
Kalau kita perlu ngitung ada waktu loaded atau waktu...
Biasanya tracking.
Terus kemudian ads.
Pernah nggak sih tau kayak yang hot spot gitu.
Biasanya tau bagian mana yang paling sering di-click user.
Kan itu kan harus seger-sesgera mungkin di-load.
Lalu kemudian cookie, cookie, cookie, cookie konsen.
Cookie konsen itu juga harus mungkin di-load.
Supaya script-script yang lain nggak ke duluan menanam cookie-nya.
Harus nungguin si cookie konsen.
Dibolehin apa nggak gitu kan?
Iya, dibolehin apa nggak, di-stop.
Lalu ads tadi sudah ya.
Paling sering itu untuk di-ads itu ada yang disebut dengan header bidding.
Pernah dengar header bidding?
Enggak, belum.
Ini untuk sebuah ad slot.
Kan kalau kita buka site ada slot-slot ads-nya ya.
Kita itu supaya memaksimalkan revenue.
Kita tentunya nggak cuma hanya dari satu provider ads aja yang kita gunakan.
Kita maunya ads-slot kita terisi dengan ads yang paling banyak duitnya dong.
Paling banyak ngasih duit lah gitu ya.
Jadi biasanya ada disebut lelang.
Jadi slot-nya itu di lelang.
Siapa yang lebih paling tinggi untuk slot-nya di situs kita?
Itu urusannya si advertisement lah ya.
Advertisement itu ada multiple advertisement, slot-nya satu.
Jadi kita bisa nge-load header bidding script kita duluan.
Untuk ngasih tahu untuk menanyakan yang mana yang paling tinggi duitnya.
Itulah yang kita pasang.
Yang akan nge-load.
Memenangkan load ads-slot yang itu di saat page load.
Header bidding ini perlu dijalankan sesegera mungkin.
Karena kita nggak mau juga ads-nya ke delay.
Semakin ke delay ads-nya, semakin sedikit impressionnya.
Tentu yang kayak gini kita perlu ada kompromasi. Kalau kita load-nya secara sincronus, render blocking.
Kalau render blocking, sama sekali ads-nya nggak muncul.
Karena sudah ditinggal user karena kelamaan.
Tapi kalau kita load-nya belakangan sekali, user keburu nge-scroll ke tempat lain.
Kan biasanya kalau ads yang paling mahal itu yang paling atas ya. Top bar gitu ya.
Sudah nge-scroll ke tempat lain. Akhirnya nggak muncul juga, impressionnya nggak bagus.
Atau click-through rate-nya rendah. Akhirnya nggak mau lagi di bidding.
Jadi ada kompromasi. Disitulah kompromasi kita perlu load-nya secara asingkronus.
Gak apa-apa mengorbankan sedikit execution time untuk header bidding. Tetapi ads bisa muncul dan duitnya bisa dapet.
Disitu perlu yang namanya komunikasi dengan client, komunikasi dengan...
Jadi menghubungkan marketing dengan stakeholder dan dengan owner misalnya.
Karena biasanya kadang-kadang dari marketing pengen digenjut suruh banyak revenue, banyak ads.
Tapi dari sisi lain, dari tim lain, ini kok page yang lambat.
Mereka pakai biasanya nge-scan pakai page speed atau pakai web page test gitu.
Atau GT matrix. Ini score kita C. Kenapa? Suruh secepetin.
Satu sisi marketing, stakeholder yang lain bilang, kita butuh ads ini diperbanyak misalnya.
Karena kita perlu mengejar target. Dua hal yang berbeda bertolak-belakang, ads versus page speed.
Disitulah challenge-nya kalau sudah urusannya yang... kalau situs beritanya startup masih baru-baru mulai ada traction.
Masih trafficnya masih rendah, nggak masalah. Tapi kalau kita sudah sampai tahap 1 jam aja mungkin 20 juta request, beda cerita kan?
Itu penampak berapa jumlah ad slot itu harus ada yang namanya budgeting.
Ad slot-nya nggak boleh kebanyakan, tracking-nya nggak boleh kebanyakan.
Terus kemudian GTF-nya harus di-maintain dari sisi client.
Gak boleh kita udah capek-capek nge-optimize, eh ternyata si marketing team-nya semana-mana menanamkan sesuka hatinya tracking script yang mereka mau tambahkan.
Disitulah letak dunia permarketing dan digital marketing versus page load.
Ya, ada pertanyaan yang sangat menarik nih.
Tentang yang ini ya, execute script ini ya, berapa lama wait-nya itu tergantung seberapa complex script-nya betul dan hardware client-nya.
Jadi dari menulis script juga kan ada JavaScript itu by default kan dia, kalau secara load JavaScript itu asingkronus ya, nge-execusi script ya sekarang kan.
Eh nggak sih, tetap aja asal dia tidak berhubungan sama dom-manipulation.
Kalau dia dom-manipulation dia akan ke-block, dia menjadi asingkronus.
Kalau dia eksekusi function, eksekusi yang fetching misalnya kan dia by default sudah asingkronus.
Jadi kalau nulis script pun jangan juga nulisnya misalnya gini, begitu JavaScript-nya di-load, langsung eksekusi seabrek-abrek.
Pastikan yang mana yang mau dijalankan saat itu juga, setelah script selesai di-download dan di-execusi.
Mana script yang perlu di-diver mungkin saat page load, onload, saat onload baru di-execusi, itu juga perlu dipilah-pilah.
Kalau bahasa kerennya three-sacking, mana script yang perlu di-import, mana script yang perlu di-jalankan saat itu, mana script yang bisa di-jalankan belakangan.
Pertanyaan selanjutnya agak oh-oh tapi menarik juga, apakah kita perlu mengakomodasi user-user yang mematikan JavaScript di browser?
Tergantung user-nya.
Tergantung aplikasinya juga.
Bukan user-base kita, jadi ini tuh, gue dulu pernah punya pertanyaan yang mirip kayak gini sih, terutama karena kalau misalnya lihat di Twitter,
Circle, Frontend Twitter yang kadang idealis banget itu kan emang sering address itu ya, kayak harus bisa diakses.
Terutama harus bisa diakses itu juga kan banyak layer-nya ya, misalnya kalau user-nya mematikan JavaScript, apakah jadi satu halaman beneran kosong?
Karena misalnya kayak yang tadi dibahas Irfan tadi ya, yang cuma body, react-up-nya di-load ke body jadi cuma satu div placeholder doang.
Nah kalau itu kan jelas buruk ya, maksud saya itu jelas bukan praktis yang bagus.
Tapi kalau misalnya aplikasi kita interaktif, banyak UI interaction-nya, berapa waktu yang dibutuhin secara realistis buat kayak ngakal-ngakalin semua?
Berarti kalau misalnya semua pengen harus bisa tanpa JavaScript-nya, masing-masing interaksi, masing-masing dynamic UI-nya tuh harus dibikinin endpoint sendiri kan?
Kayak dibikin halaman atau halaman terpisah lah baratnya.
Atau semua dibikin form terus ngeload halaman baru dengan query parameter misalnya kalau banyak misalnya apa ya, misalnya search, searching yang banyak filter-filternya.
Nah itu kan kalau misalnya buat dekerjaan, kita gak punya waktu dan resource yang unlimited buat ngerjain itu semua.
Jadi sebetulnya pada akhirnya kalau misalnya buat aplikasi production, ya survey aja userbase kita, berapa banyak sih orang yang beneran nge-disable JavaScript dari userbase kita?
Tapi sebetulnya emang ada sih niche-nya orang kayak ada circle tertentu kayak orang yang conscious banget tentang privacy lah yang terutama biasanya orang negara maju ya kayaknya di Indonesia jarang yang segitunya.
Jadi emang ada dengan jumlah yang sangat sedikit orang yang emang by default matiin JavaScript.
Nah cuma kan balik ke kita masing-masing kan, dianggap worth it gak ngabisin waktu dan tenaga sebanyak itu buat apa?
Pasti satu persatu fitur kita bisa diaksesan pada JavaScript, nah kalau di seluruh project yang selama ini gue kerja di tempat kerja sih jawabannya adalah enggak.
Jadi ya di height aja kalau JavaScript-nya non-active ya paling di atas ada keterangannya "please enable JavaScript" udah gitu doang sih.
Kalau di tempat saya kerja enggak dipaksakan tetapi ada baseline-nya yang penting kalau JavaScript di-disable page-nya enggak rusak, enggak berantakan, masih bisa dibaca gitu.
- Yang main kontennya di-load lah minimal. - Walaupun interaksinya enggak bisa gitu ya.
Ya main kontennya masih bisa di-load, ya menu-nya karena biasanya kan sekarang kan menu, jadi pemilihan ini juga kan ya, jadi pemilihan arsitektur juga kan ya sistem arsitektur juga.
Kalau misalnya tadinya hamburger menu-nya harus dari awalnya pemilihan penggunaan JavaScript akhirnya kita memilih tanpa JavaScript jadi hanya permainan CSS aja.
Jadi hamburger menu bisa lo pakai CSS tanpa JavaScript atau Accordion, ya Accordion kan banyak yang pakai JavaScript.
- Udah ada HTML ya. - Oh, Accordion sekarang udah bisa pure CSS.
Iya, jadi kenapa pindah, jadi bisa pindah hanya tanpa menggunakan JavaScript.
Jadi karena bukan mandatori tetapi kan dijadikan sebuah salah satu test case preferable-nya itu kalau misalnya diusung juga atau dicoba juga produk yang di-develop tanpa JavaScript itu seperti apa.
Nah jadinya kita push boundary ya, jadi enggak, ah nyamannya kan gue pakai React Accordion aja lah gitu. Atau udah terbiasa sama satu library tentu itu aja dipakai dari project ke project, jadi enggak ada perubahan.
Padahal teknologi makin maju. CSS bisa banyak melakukan hal yang banyak.
Jadi tanpa banyak hal yang bisa dilakukan tanpa harus JavaScript jadi solusi.
Untungnya sekarang tuh framework-framework juga udah mulai mengakomodir ini ya, contohnya kayak Astro.
Kita kan sangat mau mengusahakan se-minimal mungkin. - By default tanpa client-side JavaScript. - Iya, by default tanpa client-side JavaScript pun sudah bisa berjalan.
Walaupun mungkin interaksinya nggak bisa gitu ya, nggak bisa di-click. - Tapi lagi-lagi itu tadi kalau ada client-side interaction ya harus mau nggak mau, maksudnya kita harus open JavaScript client-side.
Cuma mindset-nya mulai diubah bahwa kalau content yang nggak perlu client-side interactivity ya harus compatible buat semua.
- Compatible buat semua, iya. Jadi kelebihannya sekarang tools-nya sudah semakin banyak mendukung ke arah sana sih.
Jadi orang-orang juga sudah semakin, apa ya, semakin kritis gitu ya. Kenapa harus semuanya JavaScript gitu kan?
Padahal sebenarnya interaksinya mungkin di bagian bawah untuk komentar doang gitu kan. Yang mungkin bisa di...
- Atau bisa jadi juga, bisa jadi kritik. Ini kan JavaScript dipakai hanya saat dikomentar atau misalnya saat di below the full. Kenapa JavaScript ini harus di-load awal-awal banget?
Dia bisa menggunakan trik-trik kayak misalkan nungguin dia sampai mendekati di ke bawah aja baru di-load si JavaScript untuk komentarnya.
Dari awal karena belum tentu juga orang yang baca artikelnya mau menulis komentar kan.
Jadi ya mungkin secara, apa ya, secara kerjanya itu mirip-mirip kayak yang tadi ya, laziness, lazy loading-nya image kan.
Kalau kita bikin image gallery kan, nggak mungkin semuanya dulu di-load kan. Semua image di-load. Sampai 100-100-nya gitu kan.
Belum tentu juga dia sampai ke bawah gitu. Apa ini? Cortex? - Saya masih ingat.
- Nggak bisa. Nggak boleh, jangan-jangan. Cortex itu kompleks ya. Bukan masalah apa, banyak lah. Banyak faktor.
Cortex itu itu ya, framework baru ya. - Gua udah sempat bakal merusahangin joke, cuma gua nggak tahu itu apa.
Nggak tahu Cortex. Aplikasi pelaporan pajak yang baru. - Iya, baru launching, baru launching, kayak migrasi dari aplikasi yang lama.
- DGP Online ya, DGP Online. - Buat pembaruan, pembaruan.
Terus hubungannya sama Beyond BSI apa? Beyond BSI apa? Saya juga nggak tahu ada masalah apa dengan Beyond BSI.
- Nggak tahu dah. - BSI itu Bank Satia Indonesia kan.
Berarti ada aplikasi namanya Beyond BSI gitu ya. Saya nggak tahu, nggak ngikutin.
- Dan tidak ada hubungannya sama asing dan defer juga sih. Itu masalahnya di luar itu. Masalahnya di projects gitu ya.
Bukan di JavaScriptnya ya. Bukan hanya di JavaScriptnya. Kita nggak tahu ada masalah di JavaScriptnya ada apa nggak ya.
- Nah, ini ada pertanyaan lagi nih dari Krisna. - Good question.
- Bagi itu kalau kita offload ke web worker atau service worker, bisa mendingankan main thread. - Iya, kan ada tuh. Ada service kan? - Parti. Parti Town. Parti Town. Parti Town Builder I/O.
Coba baca ini ya. Coba baca. Saya belum pernah pakai. Coba tahu itu ada yang mencoba eksperimen untuk offload semua tracking-tracking nggak semua ya.
Jadi nanti kita bahas pelan-pelan. Parti Town ini mencoba membuat library. Bukan library, ya. Library ya. Kayak menjalankan third party itu ke web worker.
- Iya, ini dia. - Kayak offload gitu ya. Offload. Untuk ngirimin data yang ini. Mendelegasikan. Nah, lebih tepatnya itu.
Pekerjaan yang tadinya harus dikerjakan oleh main thread, thread utama, sehingga bisa dikerjakan oleh yang di background, yang di belakang layar.
- Tidak mengganggu loading-nya. - Dan baru tahu ternyata itu bagian dari Builder I/O ya. Builder I/O itu kan punya si siapa itu? Mas yang bikin Quick, ya?
- Ya, yang bikin angular 1. - Quick ke QWIKA ya. - QWIKA. - Iya, Quick. Builder. I/O.
- Quick, QWIC, beda lagi. - Beda lagi. - Itu HTTP 3. - Builder. I/O ya.
- Susah banget. Iya kan, ya. - Iya, ini Quick. Framework baru. Framework baru.
- Udah lama sih ini. - Yang bikin adalah... - Iya, itu si yang bikin angular 1.
- Misko, Misko. Pak Misko. - Iya. - Yang bikin angular dulu.
- Nah, tujuannya itu salah satunya. - Builded by performance nerds. Branding-nya aja kayak gitu. Builded by performance nerds.
Goal-nya adalah free up main thread resource to be used only for primary web app execution, sandbox third-party script, isolating long-running task,
reduce layout tracing, throttle third-party script, allow third-party script to run exactly how they're coded without any alterations, read and write main thread DOM operation synchronously.
Belum pernah coba, namun konsepnya menarik dan harusnya bisa meninggankan. Namun nggak tahu juga ya sampai sebatas apa.
Karena ada juga yang sebagian untuk... apa namanya? Sebagian tracking script kalau hanya sekedar page load atau scrolling dan dia nge-trigger dan hanya ngirimkan saja,
mungkin bisa gitu ya, bisa mempercepat. Tapi kan nggak semua ya, karena ada juga yang namanya on-click. Jadi kalau misalnya video di on-click, play, pause, play dan pause, terus mempercepat,
atau download button, atau submit form. Itu kan ada yang namanya DOM. DOM ini juga ya, DOM trigger gitu ya. Trigger by DOM event gitu.
By DOM ya. Itu saya nggak tahu sampai sebatas apa bisa mempercepat karena main thread-nya dibebaskan. Belum ada hasil analitiknya, komparasinya.
Nah itu selama ini agak penasaran aja sih sama perbandingannya. Maksudnya lebih cepat sekian persen itu kalau in the real world dengan operasi yang di-app pada umumnya itu
sesignifikan apa sih? Jangan-jangan cuma beda 0,001 millisecond misalnya. Lagian dari web worker ke main thread itu kan juga setiap harus kirim event kan, misalnya user nge-scroll atau nge-click, kirim event ke web worker-nya baru diproses.
Walaupun itu juga pasti 0,001 millisecond juga sih. Tetap ada ini kan, ada overhead-nya juga kan antara komunikasi antara web worker sama main thread akan jadi overhead.
Jadi tergantung kompleksitas yang kita kirimkan. Kalau cuma hanya kirimkan data, kayak kalau pakai GTM-nya cuman data layer push gitu aja sebenarnya.
Sebenarnya nggak banyak-banyak amat gitu. Nggak nge-blocking apa-apa gitu. Beda ceritanya mungkin kalau ada...
Rendering 3D atau apa kali ya?
Bukan, bukan rendering. Jadi data yang waktu kita mau kirimkan, kita masih melakukan proses komputasi.
Nah itu baru kerasa kali kalau kita lakukan proses komputasi yang berbeda. Ya apalah itu ya.
Ini ada use case-nya. Meskipun seluruh aplikasi web bisa jalan dengan party town, tapi lebih cocok menggunakan kode yang tidak berada di critical rendering part.
Maksudnya yang bukan berdaitan sama UI. Yang tadi itu kan tracking.
Contohnya ya ini ads atau analytics, GTM, mixpanel juga termasuk analytics, apalagi HubSpot ini?
Kayak plugin-plugin model, kayak ada chat yang di kanan bawah, itu termasuk nggak ya? Masuk ya?
Bisa, bisa. Live chat ya? CRM. HubSpot itu CRM.
HubSpot itu juga punya embed juga, form embed.
Oke, jadi tidak semua ya. Tergantung itu juga ya. Kalau misalkan yang berhubungan dengan UI, kalau di delegasikan malah jadi mungkin ada, tadi overhead cost-nya.
Betul, betul. Mending nunggu sampai WASM bisa akses DOM.
Ini komentar yang berhubungan dengan apa ya? Konteksnya apa ya? Yang ini ya, yang tadi, party town tadi.
Emang ada Whatchannel WASM bisa akses DOM? Gak tahu. Kayaknya enggak deh. Kayaknya peruntukannya beda deh.
Gak tahu ya bisa apa. Kalau bisa juga, jadi bingung nggak sih? Karena ada main thread. Sekarang ini kan DOM itu hanya bisa di akses oleh main thread.
Supaya tidak usah nulis JavaScript maksudnya. Seburuk itukah JavaScript?
Keras lah, pakai framework keras. Kan ada kan yang udah bisa ngerender jadi HTML ya?
Iya, coba cari framework-framework yang rendernya di server. Jadi nggak perlu ngerender di client.
Misalkan Laravel kan ada hotwire ya, ada Phoenix Live View, ada hotwire. Hotwire bukannya Rails ya?
Ya itulah pokoknya salah satu lah ya. Jadi server back-end juga berlomba-lomba untuk supaya mengurangi penggunaan JavaScript.
Tapi kalau kita balik ke lagi, kalau udah menggunakan TypeScript, apakah masih experience-nya masih buruk nggak sih?
Ya kalau ditanya kita sih enggak ya, karena kita udah sering menggunakan JavaScript.
Tapi buat temen-temen yang di back-end mungkin agak frustrasi ya menggunakan JavaScript ya. Apalagi yang sudah terbiasa dengan Type.
Terus tiba-tiba JavaScript dynamic type-nya.
Ini loh rocket.rs framework, web framework, pakai Rust.
Ini nggak perlu menulis JavaScript gitu ya? Iya, kayak Laravel cuma versi Rust-nya.
Aduh merah sekali. Kok sakit mata ya? Kayak error-nya React Native gitu ya?
Ini merah putih ya. Ternyata ngantuk, abis itu langsung mulai ya nih.
Ini accessibility-nya berapa sih? Coba klik kanan dulu lah.
Kontrasnya sih kontras, gue rasa kontras, cuma bikin sakit mata aja.
Enggak sih, itu dulu arah ke tulisannya web framework-nya, itu lah web framework.
Ini? Iya, nah, inspect. Terus? Terus ke...
Ya harusnya di situ sih. Udah sih, harusnya ada di sini.
No contrast information available.
Dimana sih?
Ya, coba.
Nggak ada, itu kan image.
Ini image bukan lah, ini text kan? Nggak, text.
Kok nggak ada ini?
Nggak, kelihatan ini kalau pakai... Coba di styles, tab styles.
Tab styles? Dimana styles?
Di bawah, tab styles di bawah.
Terus? Warnanya, cari warna.
Atribut color.
Nggak ada sih.
Color atau background?
Biasanya di hover, dia langsung kelihatan.
Ya kalau ada properties CSS color-nya.
Okay, anyway.
Gimana, kodenya gimana ini? Coba kita...
Itu tadi kan ada contohnya di halaman depan yang bikin sakit mata itu.
Oh di bawah, oh.
Macro use.
Oh ini route-nya, function hello, format.
Oh jadi begini ya.
Terus launch.
Okay, terus.
Ini kan back-end kan?
Oh form juga ada.
Nah itu ngerender, itu web framework kok.
Iya, web framework kan. Ini back-end kan?
Cuma ya nggak pakai client-site interactivity ya.
Oh ini back-end aja.
Full-stack tapi ya.
Menarik.
Websocket and stream.
Data plus support testing.
Kalau ada yang mau belajar RAS.
Itu pokoknya di hype-up-nya tuh semacam Laravel, tapi versi RAS.
Bagi yang nggak mau nulis javascript, tapi nggak mau nulis javascript juga.
Ini sebenarnya kayak pakai bubble aja.
Kayak pakai bubble itu aja ya, di-convert ke javascript ya.
Bubble?
Iya kayak transpile, jadi last code di transpile ke javascript.
Iya, timelapse javascript.
Sama kayak ada yang dulu pernah buat PHP kan.
Nulis PHP, di-convert jadi javascript.
Tapi emang sudah bisa semua gitu.
Semua maksudnya apa tuh?
Maksudnya ya nggak ada limitasi gitu.
Limitasi untuk?
Ya misalnya nggak, apakah semua yang dari RAS itu bisa di-convert ke javascript atau versi?
Ini kan ya framework request response tradisional kan ya?
Oh itu server-side?
Oh kirain jadi javascript.
Nggak, ini server-side kayak express lah.
Yang gue bilang PHP itu dia bisa, ya dia nulis PHP jadi javascript.
Javascript itu maksudnya berarti termasuk web API gitu.
Iya kayak JSX atau TSX.
Oh canggih juga.
Nah kalau itu lebih berbayang sih.
Ini contohnya nih ada Gleam.
Gleam ini selain bisa untuk backend, bisa di-convert ke javascript.
Ada tuh misalkan, ya kayak gini nih, nanti bisa di-convert jadi javascript.
Nah dia ada nggak disini ya itu namanya?
Docs, writing claim, install.
Gleam, javascript, nggak ada ya?
Gleam, javascript.
Itu, Gleam can additionally compile to javascript.
Enabling you to use your code in the browser or anywhere else javascript can run.
Mana javascriptnya?
Dari gini, jadi javascript.
Iya bener, javascript itu.
Nggak sih, ini belum javascript, tapi udah bisa document query.
Bisa nakses, bisa nakses web API kan.
Public, fn, digital, fn itu javascript kan.
Mana? Bukan lah, ini Gleam.
Itu apa?
Mana ada public function, javascript semua function kan public.
Public, public.
Kalau di, ya.
Public, public.
Ya berarti bikin compiler sendiri ya?
Iya, betul.
Javascript.
Kita udah kemana-mana nih.
Kita belum bahas chunking.
Perlu bahas chunking apa nanti aja?
Soalnya kayaknya agak nggak nyambung ya.
Dynamic import.
Cukup ya.
Kita pilih topik kita selanjutnya yuk.
Diskusi-diskusi ya.
Oh iya sebelum itu kita, ini saya mau komentar ini.
Kapan javascript bisa langsung di browser?
Kayaknya tunggu ini bisa dulu deh. Apa tuh namanya?
Flutter bisa di browser dulu baru bisa javascript.
Lama bener.
Cuma itu kayaknya macam udah dari dulu.
Cuma kelihatannya counts-nya kecil.
Kut, bener-bener terjadi.
Kenapa? Apa masalahnya?
Jangan salah loh.
Types itu tadinya mau diintroduce di ES4.
Tapi nggak jadi, 2003 loh.
Tahun berapa itu?
Jadi batal.
Makanya dari ES3 langsung ke ES5.
Nggak ada ES4.
Sama kayak PHP. PHP 7 nggak ada PHP 5, nggak ada PHP 6.
Udah ada types-nya nih.
Ada generic tuh, ada generic-nya.
Ada macem-macem.
Dari ES4. Kalo temen-temen mau, eh kok translate sih.
Kalo temen-temen mau, bisa ke sini nih.
Archive Mozilla. Atau ada paper-nya.
Yang javascript 20 years later.
Itu ada.
Jadi sebenarnya javascript itu mau ada types.
Tapi entah kenapa mungkin ditolak ya.
Karena namanya visi-misi awal dari javascript
adalah bahasanya harus dinamis dan mudah digunakan.
Karena ada script-nya.
Istilah script itu kan jadi gampang digunakan.
Nggak memudahkan end user atau orang yang baru belajar programming
untuk nulis script lah, kira-kira kayak gitu.
Paling mentok yang kayak di note itu sih.
Kalo yang di note sekarang kan.
Typescript definition itu nggak menyebabkan error.
Jadi akan di strip. Jadi kode yang ada typescript definitionnya
bisa otomatis dihapus typescript definitionnya.
Tapi ya nggak bisa ngejalanin kode typescript juga.
Cuma nggak bikin error aja kalo ada definitionnya.
Dan tidak butuh transpiler atau compiler.
Jadi bisa langsung native gitu ya.
Kalo browser pake TS apakah akan menjadi cepat? Tidak.
Belum tentu. Bisa jadi lebih cepat.
Tapi juga di sisi yang lain dengan menggunakan typescript
atau type language itu error yang dilakukan oleh developer lebih berkurang.
Jadi lebih dari sisi developer experience ya kalo type system itu ya.
- Oh karena typescript kan ya menge-enforce type checkingnya dia
kalo udah lagi run, time kan. Kalo udah running nih.
Mau kata kita nulis kode TS, misalnya argumennya harus number.
Kalo prakteknya yang diterima string, ya typescript nggak bisa ngapa-ngapain
kalo kodenya udah jalan.
Tapi misalnya waktu kita lagi coding error atau untuk compile error.
- Iya. Ini kan membantu juga karena semua yang dikirimkan oleh HTML
dalam bentuk form atau apa, semuanya adalah string.
- String. - Iya.
Itu yang kadang-kadang orang miss.
Berarti HTML-nya harus dikasih type.
Gak bisa juga. Dikirimnya kan pake text. Gak bisa.
Dikirimnya kan kalo request response itu kan pake text.
Jadi ya tetep aja harus text ya.
Jadi lebih ke developer experience betul.
- Nah itu DX. Itulah musimnya phone work.
- Iya. Jadi dari sisi kecepatan, performance tidak secara langsung berpengaruh.
- Soal runtime sih nggak ngaruh ya. - Lebih type safe aja.
- DX lebih type safe. - Karena type itu sangat ini lho.
Typing itu sangat signifikan lho untuk bukan bugs free ya.
Lebih ke arah. - DX maintainability.
- Less bugs. - Iya. Sama dokumentasi.
Kalau kita mau tahu cara kerja fungsi tanpa harus melihat isinya, kita bisa lihat types-nya kan.
Oh dia written integer. Oh parameternya ada 2, tipenya apa.
Berarti kalau browser dibundling pake compiler bun, harusnya jadi cepat.
Kan sudah di-compile. Gak nangkep sih.
Bun itu pake JavaScript engine-nya siapa ya?
Pake JavaScript engine kan? Yang punya... - Webkit ya?
- Webkit. Jadi sebenarnya sama.
Browser itu dan Webkit itu Safari bukan? Eh salah, JavaScript core.
Safari pake JavaScript core. - Iya, Safari.
- Webkit lebih tepatnya. Safari menggunakan Webkit. Bun juga menggunakan Webkit.
- Kalau si Mozilla pake apa kemarin? - Spider monkey.
- Spider monkey? - Oh iya.
Menurutnya kalau nama-nama hewan itu Mozilla deh. Mereka suka banget sama hewan.
- Sedangkan Chrome pake VA. Jadi Node itu pake VA. Bun itu pake...
- Yang pakai JavaScript core. Dino itu pake VA.
- Dino itu pake VA. Jadi sebenarnya sama engine-nya.
- Bikin sendiri dari awal apa ya? - Agak sedikit nangkep karena ada kata compile.
Atau compiler. Kayaknya sekarang compile-compiler itu udah agak rancu ya.
Kalau dulu kan compile lanjut itu pasti cepat kan dibandingkan interpreter kan.
JavaScript mau di-compile pake apapun larinya tetap interpreter.
Nggak ngaruh kemana-mana. Compiler itu dari TypeScript di-compile ke JavaScript.
Jadi istilah compile itu udah agak berbeda dibandingkan dulu ya.
Kalau dulu kan... - Kalau compiler itu jadinya execution.
- Eksekusi. Ya file-nya bisa di-eksekusi langsung secara native.
- Jadi yang setara sama VA-nya. VA itu adalah engine-nya, runtime-nya.
Mesin yang menjalankan kode kita. Binary.
Jadi nggak bisa dibaca sama mata manusia binary.
Kalau JavaScript bisa walaupun di aglify, di minify, tetap bisa kan dibacakan.
Walaupun nggak jelas variable-nya cuma satu karakter gitu.
Tapi tetap bisa dibaca. Kalau interpreter itu.
Jadi kodenya itu tidak hilang. Tidak di-compilasi.
Sedangkan compiler kalau bahasa yang compile ya dia jadi binary. Ego lah.
- Lebih tepatnya transpile sih ya sebenarnya transpile.
- Iya. Transpilasi. - Pilasi.
Kalau bahasa Inggrisnya apa sih? Di-converse sih bahasa Indonesia-nya.
- Di-converse. - Di-translate.
- Translate dari satu bahasa ke bahasa yang lain.
Dari TypeScript, Redscript, PureScript, dan script-script lainnya.
Ke JavaScript. Dari JavaScript baru dijalankan di browser.
Sebagai informasi juga, tadi kan TypeScript ya.
Jaman dulu, Google punya wacana untuk menanamkan Dart ke dalam browser Chrome.
Tapi tidak berhasil. - Gimana ya?
Kamu bayang di alternate universe dimana Dart beneran diterantik.
- Dart beneran diterantik. Mungkin flutter-nya nggak ada.
- Tapi bikin sendiri. Firefox bikin sendiri.
Semua bikin language sendiri di browser-nya masing-masing.
- Yes. Internet Explorer juga sempat. Microsoft sempat mencanangkan
mau bikin J++. Kalau nggak salah. - Namanya lucu-lucu.
- Jadi dia nggak setuju dengan yang dibuat oleh Netscape pada saat itu.
Mocha atau JavaScript. Mereka mau bikin sendiri namanya J++.
Untuk browser mereka sendiri. Jadi berantem browser war.
Itu yang kejadian browser war.
Sebelum kita udahan, kita mau ngajak teman-teman untuk diskusi
tentang materi minggu depan. Kira-kira kita mau bahas apa ya minggu depan?
Sekalian aja kita omongin sekarang. - Kayak kan kita edisi khusus minggu depan.
- Iya kan? - Nggak, minggu depannya lagi.
- Jadi, by the way, ya ini asil. - Kan udah pernah.
- Udah pernah. - Berarti nggak nonton episode berapa ya itu?
- Iya kan? Beda orang. Kita ada di episode lama banget.
- Saking banyak ya. Kita aja nggak inget episode berapa.
- Episode berapa ya? - Dan nggak inget kemernya apa.
- Dari awal kita sejara browser yang pernah. - Awal kan?
- Kila sejara browser. Oh, safari doang. - Nggak, pernah kita bahas sampai...
- Enggak, inget kok sampe buka Wikipedia-nya yang... - Timeline-nya itu loh ada timeline-nya.
- Oh iya iya iya. - Dan cuma itu kayak bahas tentang apa?
- Cuma inget banget pernah bahas evolusi browser engine. - Episode 14.
Episode 14, judulnya browser. - Oh, sangat nggak spesifik ya?
- Sangat tidak spesifik. - Teramban, teramban, teramban.
- Jadi, kita udah membahas. 14, 14 itu tahun berapa ya? 2022 ya? 2023 ya?
- Ya, 2 tahun lalu. - 2 tahun lalu.
- Ya, mungkin ada yang belum ngeh ya. Kita sudah mengundang dari 2 tahun yang lalu.
Kita sudah sempet bahas. - Udah tahun ke-2.
- Bahas NitroJS. Oh, menarik nih NitroJS.
- Buka GitHub-nya kita, Mas. - Oh iya, buka GitHub ya.
Bentar, bentar, mau diatur dulu nih. Kita punya GitHub Discussion.
Jadi, kalau teman-teman mau ikutan join diskusi, diskusinya nggak mesti...
apa namanya, nggak mesti dalam bentuk pertanyaan mungkin, atau mau bahas topik,
atau mau bahas masalah yang dihadapi, misalkan performa sini kok website saya lambat ya,
atau gimana, bisa langsung ke sini aja. Jadi, kita bisa sambil diskusi di luar.
- Dan di depan di situ juga udah ada yang dijadiin episode kan ya?
- Ada, ini sama Mas. - Kayak video kan udah nih bulan lalu.
- Ya, kita close aja nih, kita close. Yang belum, apa lagi?
Tadi ada bahas NitroJS, oke, kita close aja ya. Ini apa, idea?
- Ideas, ideas. - NitroJS.
Dan server engine yang dipakai berbagai framework besar, oke.
- Bukan, maksudnya NitroJS itu adalah server engine yang
dipakai beberapa framework besar.
- NitroJS, yang dipakai oleh beberapa framework besar.
- Framework besar, contohnya apa framework besar ini?
- Setaran dari Mas Alif Nuriana. - Oh iya, namanya juga perlu ya.
- Dari, ide dari Alif Nuriana, oke.
Protokol untuk transfer data, Tiatmoko. Protokol untuk transfer data,
ini apa nih? GRPC, RSI-PI, gitu ya? Atau apa nih, protokol?
- Http, websocket, gitu ya? - Http.
- Udah kita bahas ya. - Ftp, Ftp berarti, Ftp, SMTP, Pop3.
- Bisa, bisa, bisa. Kita pernah bahas email, tapi belum bahas SMTP.
Http kita pernah bahas, tapi Http doang, belum kita bahas.
Websocket udah pernah kita bahas ya, kalau nggak salah ya.
- Pernah, pernah. - Pernah sama Mas Ahlinya, Mas Johan.
- Genis-genisnya, oh bener ya? Yang ini, Ftp, SSH, gitu ya?
- Nggak, SSH nggak. Nggak itu SSH bukan protokol.
- Ftp kan ada SFTP. - Iya, yang belakangnya TPP.
- Transfer data. - Yang belakangnya TPP, transfer protokol.
Blablabla TPP, Http, Ftp.
- Iya, SMTP. - Ftp, Ftp.
- Ftp, SCTV. - Cukup, cukup, cukup.
- Protokol, web lain. Eh, protokol apa ya?
Itu termasuk protokol web nggak sih? Kayak SMTP gitu?
- Nggak, itu email. Bukan web. Webnya cuma Http.
Hypertext, transfer protokol.
Protokol seperti, protokol bahas, apa ini? Protokol, apa tadi?
Protokol untuk transfer data.
Misalkan SMTP, terus apa lagi tadi? Ftp, SMTP.
- Http. - Http, Https.
- Https ya kali ya. Https, websocket? Buat transfer data?
- Itu bukan protokol. - Oh iya.
- Eh, kalau mau protokolnya WSS. - RPC?
- Iya bener, kalau mau protokol. - Bisa transfer kan?
- Bukan, bukan. Maksudnya yang protokolnya itu WSS-nya.
WSS, protokol, adakan websocket, skir websocket.
- CTI. - CTI, oke.
- Dan lain-lain. Ide dari mas Triad Moko.
Triad Moko aja ya.
Apa lagi? Nux, analog sama solid-start. Analog itu apa?
- Oh, masih ada UDP, TCP. - Oh iya bener.
Nah, UDP, TCP aja kali ya. Kita bahas ya.
- Bluetooth belum bahas. Bluetooth misalnya.
- UDP. - Osi model.
- Osi model. Seven layer, seven layer.
- Gua gak ngerti ini semua, ini semua. - Swap, ada DHCP.
SSC, server send event. Itu bukan protokol tapi ya.
- Bukan protokol. - Itu cara mengirim data.
- Bukan. Itu kan lagi pernah di episode. - Pernah, pernah.
- FTP, NTP. Oh, NTP. - Oke, salah.
Yang buat update jam itu loh, jam. Yang buat update waktu, universal time.
Apa ya protokolnya itu ya, lupa ya. Bukan, NTP.
- NTP? - Iya, NTP. Network Time Protocol.
Ayo loh. Kalo misalnya handphone-nya naik pesawat, turun di Singapura, terus update jamnya.
Itu NTP.
- Ya, otomatis aja dari aplikasinya dan settingnya. - Iya.
- Ya, otomatis aja tapi kan ada mekanisme. - Bukan dari setting, itu dari...
- Dia konek ke NTP protokolnya si Sapala itu entah si Android, entah si iOS, tak tau.
Boleh tuh kan pada nggak tau kan, jadi kita bahas ya protokolnya.
- Iya, gue juga nggak tau. - Oh, boleh, boleh. NTP ya.
- NTP, iya. - NTP.
- Ini udah di luar web kayaknya ya. - Apa tuh?
Apakah boleh bertanya di luar konteks, boleh?
- Asal tidak menyangkut privasi. - Cuma maksudnya di jawab atau nggak tergantung.
- Oh, nanya-nya boleh. Nanya-nya boleh, boleh aja. - Boleh terjawab, kalau nggak kan tergantung.
- Asal di jawab atau nggak tergantung.
- Sama jawaban. Bahas Firebase Data Connect.
- Wah, ini boleh. Kita tampung dulu. - Harus nanya ahlinya ya.
- Tapi harus cari nanti. - SMA gede Firebase aja seru nih kayaknya.
- Ya, bahas Firebase Data Connect.
- Semua akan postgrip pada akhirnya. - Iya.
- Harus ajak GDE Firebase. - Ya nggak harus juga, cuma lebih seru.
- Siapa? Lim kaya, Lim. Lim Sang E.
- Oh iya, dia lucu. Seru ngelawak aja udah.
- Oke. Nah, kan. - Mas Dito, senyakos.
- Langsung ngomong sama Mas Dito. Salah Mas Dito.
- Saya titip Makassar. - Oh itu Mas Dito mau ya?
- Ayo X. - Nggak, saya mau ke Makassar.
- Oh. - Boleh nggak?
- Kita bahas Firebase sama Mas Dito aja gimana yang jadi narasubanya.
- Iya. Iya. - Mau nggak? Mau ya?
- Mau ya. Nanti sebagai gantinya kita ke Makassar.
- Iya. Bertiga, bertiga. - Bertiga.
- Tuhan minta ke Makassar cuma pengen makan ikan kudu-kudu sama apa itu?
- Kudu-kudu. Yang ngasih ide nggak hadir.
Coba apa, apakah boleh bertanya di luar Cortex?
Nggak boleh, ya. Nggak boleh bertanya di luar Cortex.
Di bahasnya Cortex. Apa dia pakai set hosting? Lemot banget. Nggak tahu.
- Waduh, nggak tahu. - Kalau lemot itu faktornya banyak ya.
Bukan hanya hosting ya. - Nah, kita harus dicek pakai Core Web Vitals juga.
- Eh, kalau misalnya kayak kita bahas, salah satu program yang kita...
Kita ada ide kemarin itu adalah bahas atau analisis sebuah situs yang kalian setuju.
- Iya. Kan kita dulu sempat ada bedah buku. Kita menambah lagi bedah web, bedah website.
Nah, teman-teman punya contoh atau ada website yang mau di bedah nggak?
Selain website pemerintah. - Dan website yang aman secara aturan.
- Yang tidak NSFW. Tidak menyebabkan...
YouTube yang tidak menyebabkan YouTube Mas Riza kena ban. - Yes, sampai ini masih...
Masih channel pribadi, mohon maaf ya. Jadi tolong dikondisikan ya.
Kalau website-website yang di pinggir jurang, tolong jangan ya.
- Kalau temen-temen mau... - Masukin aja dulu salah satu topik Mas Riza.
Bedah situs. - Bedah web.
- Bedah situs lah kalau... - Bedah situs.
- Ininya, teman-teman silahkan submit URL-nya.
Silahkan submit URL web yang ingin di bedah.
- Sekarang no government, no NSFW. Yang NSFW, yang non-NSFW.
Ya lebih baik sih situs kalian sendiri ya. - Ya kliennya atau pernah dibikin.
Cuma kalau misalnya punya set project atau start-up atau apalah yang emang teman-teman yang in charge.
Atau punya klien pun kalau kliennya bersedia, nggak keberatan ya.
- Kalau nggak website pribadi juga boleh. Tolong di bedah.
Kayak bedah rumah nanti kita ganti. Dirombak.
- Tuh kita nge-mentaring dong tapi... - Jangan kebalik dong.
Agak ngeri ya. Nggak lah, website-website yang ini aja, misalkan situs berita, misalkan bedah.
Situs berita apa ya? Kumparan gitu. Boleh nggak sih? Boleh aja kan?
- Ya boleh. Cuma misalnya lebih oke lagi, nggak apa-apa sih, nggak ada turun, nggak boleh kan?
Cuma lebih oke lagi sih kalau di-submit sama, ya misalnya pada nge-submit projectnya masing-masing aja.
Misalnya saya bikin aplikasi buat blablabla, buat tuker-tukeran bareng bekas atau apalah.
Pokoknya ada orang punya project atau start-up, terus pengen di analisa.
Terutama yang dipakai orang banyak ya. Kalau blog pribadi kan, maksudnya ya paling gitu-gitu aja.
Dan user-nya juga, pengguna-nya mungkin nggak terlalu banyak yang akses.
Tapi kalau misalnya ada production app yang dipakai banyak orang, mungkin pengen dicek.
- Ya portfolio atau baru habis bikin project apa? - Oh ya portfolio habis.
- Kalau showcase project sudah ini-nya mas... - Sudah ada Pak Dika ya? - Sandika, Pak Dika. Kita yang bedah situs aja.
Kita benar-benar bongkar kayak bedah rumah deh.
- Oh bedah rumah. Nanti bisa, kalau kodenya open source, nanti kita pull request. Wih, gila.
- Betul-betul. - Karena pull request-nya nggak sesuai.
- Kalau open source, kita pull request. Tapi kalau tidak open source ya, kita cuma liat dari sisi luarnya aja, nggak bisa di-edit kan.
- Kayak boom request jaman Hector Burfes gitu. Asal ngedit satu baris.
- Nah itu dari Mas Alif tuh. Semfer dan workflow.
- Semantic versioning. - Boleh itu. Kita belum pernah. Good idea.
- Good idea. Semantic versioning bagus ya.
Bahas tentang semantic versioning.
Ini bisa di-copy nggak ya? Teksnya tulis aja.
Semfer untuk aplikasi web.
- Dan serangkaian workflownya. - Dan serangkaian workflownya.
Idea dari Mas Alif Nur Liana.
- Oke. Cukup untuk sekarang. "Saya terbiasa react, apakah sulit untuk migrasi ke spread?"
Tidak. Gampang-gampang. - Sebetulnya UI framework mah semua prinsipnya.
Asal fundamentalnya udah kuat, mirip-mirip. Tapi masing-masing kan punya perspektif sendiri.
- Bahasa fundamentalnya kuat itu susah. Itu relatif.
- Ya, mungkin itu jam terbang sih. Tapi kalau susah sih enggak ya.
Cuma kan masing-masing punya paradigma sendiri. Kalau susah, enggak.
Cuma harus switch. Jangan maksain mikir dengan mindset react pas lagi ngoding swell.
- AHA itu termasuk salah satu yang autodidact kan. Dan nggak punya background programming kan.
Dulu belajarnya dari HTML, CSS, JavaScript, atau langsung framework?
- HTML, HTML, CSS. - Jadi fundamental itu syarat sebenarnya.
Cuman kalau belum terlalu kuat fundamentalnya, mungkin langsung dihadapkan dengan framework.
Begitu belajar framework yang lain mungkin agak sedikit gamang ya, bingung gitu.
Tapi kalau sudah dapat konsep bagaimana cara front-end framework bekerja,
itu tinggal masalah berganti sintaks aja ya, kurang lebih ya.
- Iya, beda sintaks ya. Gugling ngetahukan AI assistant sintaksnya gimana.
- Apalagi sekarang sudah ada AI kan, jadi bisa nanya-nanya ya.
Convert aplikasi react saya menjadi swell. Terus AI-nya tinggal bilang pakai Astro aja.
Nggak perlu di-convert. - Bisa dicampur ya, dalam satu aplikasi.
Kode existing yang udah terlanjur dibikin pakai react, ya udah tetap react aja.
Terus nanti kalau mau nambah-nambahin, bisa pakai swell.
Bisa Astro, sebagai Astro fangirl. Jadi bisa ya, promo Astro.
- Saya malah senang pakai swell, belajar react kayak skill issue.
Banyak yang bilang swell itu memang secara sintaks itu lebih sederhana,
tapi swell yang baru juga sudah mulai cukup kompleks juga ya, mirip-mirip juga sama.
- Kan udah ada rune, rune, rune. - Iya udah runes, runes.
Nah, selanjutnya setelah kita kumpulin ide, kita mau bahas yang mana buat minggu depan?
- Teman-teman tolong vote ya. - Tolong vote ya, bisa ke sini.
ATTPS, kesana.in/ngobrolinweb. Silahkan di-vote. Sekarang juga, kita tunggu.
- Kalau menurut saya, yang paling connect apa nih, yang paling bisa cepat kita...
- Protokol. Ini di TCP. - Protokol menarik.
- Boleh, protokol... - Ini yang paling seru tadi ya, kita nggak tahu.
- Ya, boleh deh. - Ya, maksud saya karena
something different aja kan, beda dari yang dibahas kemarin-kemarin.
- Semantic versioning. Kalau beda situs kan harus ada website-nya ya.
Kita belum ada website-nya, jadi belum di salah.
- Beda situs, nunggu submission aja dulu. - Nunggu teman-teman dulu.
- Udah protokol aja. - Protokol atau NitroJS menarik nggak?
- Boleh, protokol atau Nitro ya. NitroJS. Bentar. Googling dulu.
- Semfer tuh. Semfer juga menarik sebenarnya, tapi mungkin untuk 2 minggu atau 3 minggu lagi ya.
Wah, nggak ada yang nge-vote. Gimana dong? Oh, kita vote di YouTube aja apa ya?
- Vote di YouTube, berarti ada dua kegiatannya ya. - Emang bisa dibikin.
- Bisa, bisa, bisa. Bentar ya. - Ada maksimal items-nya nggak?
- Enggak. Eh, ada 4 atau berapa gitu. Mana dia?
- Start polling, bahas apa minggu depan? - Nitro. - Tadi apa? Protokol.
- Protokol, Nitro. - Protokol, UDP, TCP, dan lain-lain. Yang kedua tadi apa?
- Nitro ya? - Ya, NitroJS.
- Yang ke-3, Semfer. Apa lagi? Yang ke-4? - Yang ke-4.
- Cukup lah. - Udah ya, tiga aja ya. Start polling.
- Bisa ya dibikin polling ya? - Bisa, bisa. Start poll.
Dah, silahkan teman-teman polling di YouTube atau di... Oh ini udah ada yang 2-2-2 nih.
Udah situs 2. Siapa yang ini? Bisa kelihatan nggak orangnya? - Enggak. - Enggak kelihatan?
Protokol UDP, TCP masih menang sekarang. Kita lihat aja. Langsung.
Live vote, live vote, ayo. Dipaksa loh. Oh CI/CD juga menarik loh.
- Bukannya udah ya? Lo mau apa? - Continue integration.
Boleh lah, kita catat dulu aja ya. Catat dulu aja. Kalau udah ya berarti kita tinggal close ya.
Bahas CI dan CD. Ini 2 hal yang berbeda, bisa jadi 2 topik sih ya.
Ide dari Mas Efraim. Udah sampai mana? 60%? Kita tunggu sampai 2-1-3-5 ya. 1 menit lagi ya.
- Ngasih waktu 1 menit dong. - Mau 5 menit, samaan. Kan udah dari tadi.
Kayaknya kalau jumlah penonton kita ada berapa nih jumlah penonton?
- Ada 24. Yang aktif berapa? Yang aktif setengahnya mungkin 12. 60%-nya udah milih yang atas tuh nggak nambah-nambah lagi.
- Udah, belum. 2-1-3-5 ya. 1 menit lagi. Satuin sama Semfer. CI/CD sama Semfer disatuin.
- Emang nyambung ya? - Jangan lah.
- Bisa, bisa. - Iya bisa, cuma jangan.
- Jangan, CI itu penting dan cukup panjang juga. Tuh, naik lagi malah. 6-4.
Sudah ya, berarti deal ya. Kita end ya, polling-nya ya. Berarti minggu depan kita akan bahas tentang protokol.
Oke, terima kasih buat yang sudah ikutan polling. Kita akan bahas tentang versiening.
Sip, kalau begitu. Oke. Untuk malam ini, udah dulu. Kita ketemu lagi minggu depan.
- Saya di different kota. Kota yang berbeda. - Oh, di Manila ya?
- Iya. - Jalan-jalan terus, mantap.
- Amin. - Asik.
- Workcamp ya? - Iya.
- Workcamp, oke. Jadi kita akan bahas tentang protokol ya. UDP, TCP, oscilator.
- Boleh, nginggul-nginggul. - Terima kasih buat semuanya. Yang udah ikutan vote juga terima kasih.
Yang udah ikutan komentar juga terima kasih. Kita akan kembali lagi.
Yang udah kasih saran, terima kasih banyak. Kita ketemu lagi minggu depan. Selamat malam, selamat istirahat. Bye bye.
Bye bye.
Terima kasih telah menonton!
Deskripsi asli dari YouTube
Yuk mari kita diskusi dan ngobrol ngalor-ngidul tentang dunia web. Agar tetap up-to-date dengan teknologi web terkini. Topik, tautan dan pertanyaan menarik bisa dilayangkan ke https://ksana.in/ngobrolinweb Kunjungi https://ngobrol.in untuk catatan, tautan dan informasi topik lainnya.
Episode Terkait
14 Mei 2024
Ngobrolin Web API Baru
Episode ini membahas berbagai Web API baru yang sedang trending atau akan menjadi tren di tahun 2024. Diskusi dimulai de...
24 Des 2024
Ngobrolin WEB edisi Offline Surabaya
Episode ini adalah sesi tanya jawab Ngobrolin Web versi offline yang diadakan di Surabaya. Pembahasan mencakup berbagai ...
10 Jul 2024
Ngobrolin State of JavaScript
Episode ini membahas hasil State of JavaScript 2023 survey yang baru dirilis, memberikan gambaran komprehensif tentang l...
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 .