Ngobrolin Island Architecture
Ringkasan Episode
Bantu KoreksiEpisode ini membahas Island Architecture beserta dua topik yang saling menyambung: Quicklink dan Astro. Dimulai dari Quicklink, library mungil buatan tim Google yang mengubah semua tautan internal di halaman menjadi prefetch otomatis. Kuncinya bukan sekadar prefetch — itu sudah lama ada di web — melainkan kapan prefetch dijalankan: hanya saat browser sedang menganggur lewat requestIdleCallback, dan hanya untuk tautan yang benar-benar masuk viewport lewat Intersection Observer. Hasilnya aplikasi multi-halaman biasa terasa seperti single page application, tanpa harus memakai meta framework. Island Architecture sendiri adalah cara menata arsitektur front-end dengan analogi kepulauan: seluruh halaman adalah wilayah statis (laut), sementara bagian-bagian yang butuh interaktivitas JavaScript adalah pulau-pulaunya. Pendekatan ini memadukan keunggulan client-side rendering dan server-side rendering — kita bisa memilih komponen mana yang perlu dihidrasi, dan menentukan prioritasnya: yang di atas lipatan segera, yang di bawah menunggu browser menganggur. Kelemahannya lebih pada faktor manusia: keputusan itu sangat bergantung pada aplikasi masing-masing, dan tidak cocok untuk aplikasi yang memang seluruhnya dinamis seperti game atau aplikasi peta. Astro menerapkan filosofi ini dengan menjual zero JavaScript by default, dan direktif client:idle serta client:visible-nya sebenarnya membungkus dua Web API yang sama. Dibahas juga Qwik yang mengklaim tidak butuh hidrasi sama sekali karena ia resumable. Ditutup dengan demo View Transition yang masih di balik flag, plus catatan bahwa keunggulan pendekatan berbasis Web API adalah fallback-nya tetap berfungsi sebagai tautan biasa.
Poin-poin Utama
- •Kunci Quicklink bukan prefetch itu sendiri tetapi kapan ia dijalankan — hanya saat browser menganggur lewat requestIdleCallback dan hanya untuk tautan yang masuk viewport lewat Intersection Observer
- •Prefetch harus dibatasi hanya domain sendiri dan di-throttle; halaman berita dengan seratus tautan internal yang di-prefetch semuanya sama saja dengan menyerang server sendiri
- •Island Architecture memakai analogi kepulauan: halaman adalah wilayah statis dan hanya bagian yang butuh interaktivitas yang jadi pulau — memadukan keunggulan CSR dan SSR
- •Kekurangannya bersifat human factor: keputusan mana yang perlu dihidrasi sangat bergantung pada aplikasi masing-masing, dan tidak cocok untuk aplikasi yang seluruhnya dinamis seperti game atau peta
- •Direktif client:idle dan client:visible di Astro sebenarnya membungkus requestIdleCallback dan Intersection Observer — pola yang makin umum seiring meta framework memilih Web API ketimbang membuat mekanisme sendiri
- •Qwik mengklaim tidak butuh hidrasi sama sekali karena ia resumable — konsep yang di episode ini pun diakui belum sepenuhnya jelas cara kerjanya
- •Keunggulan pendekatan berbasis Web API adalah fallback-nya: kalau View Transition belum didukung, tautannya tetap berfungsi sebagai anchor biasa — berbeda dari router yang sepenuhnya bergantung JavaScript
Halo, selamat malam semuanya.
Ketemu lagi kita di Ngobrolin Web malam hari ini.
Masih bersama saya, Riza, dan 2 teman saya, Ivan dan Eka.
Acara ini masih kita ngobrol-ngobrol santai aja seputar web, walaupun kita punya agenda.
Tapi kalau teman-teman punya topik-topik yang menarik, bisa juga langsung dikomentar aja.
Nanti kita diskusikan bareng-bareng.
Oke, kenalan dulu, saya Riza, co-founder-nya Hektivate.
Lanjut, Eka.
Saya Eka, web developer di NGO yang namanya Atma Connect. Lanjut.
Saya Ivan, senior web engineer di agensi namanya Humanmade.
Dan kita semua ini adalah Google Developer Expert di bidang web.
Makanya ngobrolin web.
Makanya ngomongin web.
Karena kita butuh update ya, untuk materi-materi yang diisi di berbagai acara.
Kita butuh asupan ini ya, asupan topik-topik menarik.
Jadi acara ini sebenarnya kita saling berbagi di antara kita, untuk belajar masing-masing.
Untuk update masing-masing.
Jadi kenapa nggak sekalian di-share aja.
Kalau teman-teman mau share juga, boleh.
Siapa teman-teman lebih tahu ya, kita belajar dari teman-teman.
Di komentar, mungkin ada yang nanya atau mungkin ada yang punya pendapat.
Karena web itu cakupannya luas sekali. Dan kalau kita ngikutin update itu nggak bakal bisa benar-benar dapet semuanya.
Dan cepet banget kayaknya kita kedik bikin.
Ada berita baru atau framework baru, atau library baru, dan lain-lain.
Oke, jadi malam ini...
Kedik mata gitu udah ada JavaScript framework baru ya.
Setiap berapa detik gitu.
Oke, jadi malam ini kita akan ngobrolin tentang apa.
Mulai dari Ivan dulu kali ya.
Baiklah.
Lihat transkrip lengkap (583 segmen lagi)
Oke, saya sharing dulu nih.
Kalau saya kan fokusnya di web performance.
Jadi memang sering menggali apa sih yang bisa kita bikin lebih cepet lagi di soal web.
Minggu lalu saya bahas mengenai apa itu namanya?
Pakai tools performance insight supaya kita bisa improve core web vital.
Yaitu largest content full pain, cumulative layout shift, sama first input delay.
Terus, minggu ini saya mau lanjut.
Selanjutnya apa sih yang bisa kita lakukan untuk mempercepat performance?
Jadi kayaknya coba share screen.
Kalau teman-teman punya web yang mau di-audit, boleh ya.
Oh, kali ini bukan di-audit.
Jadi saya cuma share informasi.
Kalau minggu lalu kan kita itu ya.
Langsung demo-audit web ya.
Iya.
Oke, coba dimasukin ke stream.
Oke, so kali ini saya mau share sedikit mengenai quick link.
Apa tuh quick link?
Ini sebenarnya gawainnya kayak teman-teman di Google, Adi Osmani dan segala macemnya.
Jadi mereka bikin library yang super kecil bagaimana bisa memanfaatkan prefetch.
Jadi ada prefetch API ya.
Jadi web itu kan bisa prefetch, preload.
Apa sih prefetch itu?
Jadi prefetch itu bagaimana si browser bisa melakukan request content saat kita berada di page tertentu.
Jadi kalau kita load halaman homepage kita misalnya.
Terus kita prefetch, artinya memberi sinyal kepada si browser, kita butuh assets ini loh.
Atau kita bisa bilang, kita butuh halaman ini loh selanjutnya, tolong di prefetch.
Jadi begitu si user kita lagi membaca halaman yang sekarang, browser sudah mengambil halaman yang selanjutnya.
Contohnya mungkin teman-teman kalau di homepage bisa, kayak kita punya ada CTA button yang besar,
di halaman utama yang 80% itu si user akan klik itu.
Jadi kalau kita prefetch halaman yang dituju sebelum si user melakukan action terhadap link itu,
artinya mempercepat page load kan, karena sudah di load sebelumnya.
Nah, prefetch sudah lama sebenarnya ada di web,
jadi semua web sudah mendukung prefetch, semua browser maksudnya.
Apa sih quick link itu? Quick link ini cuma library kecil yang merubah semua html,
semua ahref-ahref itu di prefetch, otomatis.
Di saat browser sudah tidak sibuk.
Nah, bingung kan apa yang saya bilang kan?
Jadi ketika page load, ya kalau misalnya kita lihat sebuah halaman ini.
Ketika page load, yang minggu lalu ingat nggak kita mendemokan performance insight,
jadi saya coba pakai regular 4G, ini artinya page load ya.
Saat page load, apa yang terjadi?
Browser request, terus kemudian request halamannya, html-nya,
terus kemudian request asset-assetnya, terus request image-nya, style-nya, font-nya, dan segala macam.
Baru kemudian melakukan render terhadap halaman ini.
Kita lihat yang di bawah ini ya. Saya gedein dulu deh.
Saya lihat yang itu dulu, lihat yang ini dulu.
Browser request, terus kemudian html-nya muncul, terus kemudian image-nya muncul.
Itu artinya proses rendering.
Dan di saat proses rendering, tentunya si browser itu kan pakai CPU main thread namanya.
Jadi ada thread-nya, main thread-nya itu sibuk. Artinya jangan sampai kita mengganggu
proses main thread itu melakukan dengan rendering dan kita lakukan prefetch.
Jangan sampai seperti itu juga.
Jadi quick link ini membantu untuk melakukan prefetch ke halaman yang lain
yang ada ahref-nya, artinya URL-nya, link-nya, dan di prefetch di background saat browser tidak sibuk.
Apa sih tanda browser tidak sibuk?
Itu ada API namanya request idle callback.
Request idle callback API.
API ini memberi sinyal kayak sebuah event, kayak resize observer API, kayak apa lagi API?
Yang kemarin, yang minggu lalu, si Mbak Eka Sher itu adalah sanitizer API.
Request idle callback itu events.
Events yang akan dipanggil saat si CPU sudah idle.
Pertama kali idle, maka CPU akan memanggil idle callback.
Hanya itu yang dilakukan API ini.
Support-nya saat ini di Chrome pasti karena itu dari timnya Chrome.
Terus kemudian Safari belum, masih behind flag.
Firefox sudah support.
Jadi Chrome-based browser semua sudah support.
Hanya tinggal Safari yang behind flag.
Jadi, teman-teman sudah bisa memakai ini.
Dan untuk si Quicklink sudah include quality fill.
Jadi kalau nggak ada akan ada quality fill-nya.
Nah, apa sih? Kita lihat dia gimana cara kerjanya.
Saya ada 2 demo.
Yang pertama, saya hapus dulu case-nya biar...
Yang kiri dan yang kanan.
Jadi mini-ecom sama mini-ecom Quicklink.
Saya refresh.
Untuk reload pertamanya, nggak ada bedanya.
Tapi kita lihat kecepatannya.
Kalau saya klik ini sekali, ada waktu tunggu ya.
Dan kalau saya klik ini, cepat ya.
Kalau saya balik, saya klik yang lain.
Cepat banget ya.
Lihat?
Kalau yang ini, saya balik.
Saya klik yang lain, tunggu.
Oke.
Dan percaya sama saya,
kalau ini yang satu bukan SP ya.
Bukan single page application.
Sama, kodnya sama.
Dan dia hanya melakukan prefetch.
Kita bisa lihat prefetch itu di tab other.
Sorry.
Di network, other.
Jadi kalau saya refresh halaman ini,
begitu sudah selesai,
maka dia melakukan prefetch ke semua link yang ada di sini.
Product details.
Sedangkan halaman ini,
dia tidak lakukan prefetch terhadap apapun.
Jadi,
library ini bisa membantu
page speed kita untuk halaman selanjutnya.
Jadi kita klik, sudah selesai. Langsung nge-load.
Jadi canggih ya.
Berasa SPA ya?
Berasa SPA.
Nanti saya share lagi,
bagaimana cara supaya kelihatan lebih SPA.
Tapi saya lanjut dulu soal quick link ini.
Untuk konfigurasinya,
tentunya tidak semana-mana,
begitu install langsung jadi.
Meskipun bisa.
Tapi saya tidak menyarankannya,
jangan sampai semua link.
Kita perlu membatasi hanya domain kita saja.
Contohnya kita tidak perlu prefetch external URL, external domain.
Atau kita hanya perlu prefetch yang halaman
di dalam body container kita tertentu saja.
Terus kita harus limit juga.
Jangan sampai kalau misalnya kita buka sebuah halaman news portal
yang satu halaman itu saja sudah ada 100 internal linking.
Tentu kita tidak mau 100-nya kita prefetch.
Karena jadinya nanti kita ngedidose server kita sendiri.
Jangan sampai seperti itu juga.
Tentu kita perlu throttle.
Jangan sampai kebanyakan.
Ini perlu konfigurasi.
Dan konfigurasi itu harus disesuaikan
dengan kebutuhan masing-masing web, teman-teman.
Oh, satu lagi.
Kalau saya misalnya pakai tampilan mobile,
dia menggunakan intersection observer juga.
Jadi kalau misalnya hanya above default-nya ada 4 link,
dia hanya nge-load 4 saja.
Jadi semakin saya scroll, baru dia nge-load yang lain.
Jadi dia pakai intersection observer.
Kalau teman-teman pengen tahu apa itu intersection observer,
bisa baca nanti intersection observer API.
Artinya hanya intersection observer API ini
adalah API yang membuat elemen tertentu
jika intersect dengan muncul di dalam viewport seperti itu.
Jadi kalau kita bisa setting, elemen url-link ini
muncul di dalam viewport baru dia dilakukan callback tertentu.
Jadi bisa menggunakan namanya intersection observer API.
Dan dia bisa, karena dia cuma library kecil,
mau pakai di React, mau pakai di HTML biasa terserah.
Cara kerjanya seperti ini.
Visit page, saat idle time, dan saat user scroll dan intersect dengan viewport,
hanya saat itu dia melakukan prefix.
Dan kalau user klik link tersebut, maka kecepatannya jadi lebih cepat,
karena aset yang dibutuhkan untuk halaman tersebut seperti HTML
dan segala macam sudah di prefix di background oleh browser.
Untuk dukungannya sudah berbagai macam,
bahkan sudah ada dukungan langsung WordPress pluginnya,
tinggal plug, setting, and play, tinggal dipakai.
Dan untuk React, Angular, dan Vue sudah ada supportnya juga.
Seperti yang saya janjikan, supaya terlihat lagi seperti SPA,
itu bisa menggunakan yang namanya transition API.
Pernah tahu transition API? Ini masih behind flag.
- Masih flag sayangnya ya. - Iya, masih behind flag.
Tetapi kalau itu kita gabung prefix dan transition API,
maka kita bisa niscah ya.
Suatu saat kalau ini sudah rilis, akan kelihatan seperti SPA beneran.
Saya bisa contohin bagaimana saya reload.
Kalau ini masih SPA ya, jadi belum menggunakan prefix segala macam.
Tetapi bisa seperti ini transition API-nya.
Jadi kalau ini kita gabung antara prefix dan transition API,
maka alaman yang sudah kita download di background
bisa kita munculin secara transition dengan menggunakan transition API.
Silahkan nanti baca.
Namun ini masih behind flag, hanya ada di Chrome dan perlu diaktifkan secara manual.
Jadi saya perlu enable manual.
Itu saja paling dari saya.
Jadi prefix bisa segera digunakan jika kalian ingin mencoba di web page kalian
untuk meningkatkan kecepatan loading halaman selanjutnya.
Ini mirip-mirip sama ini.
Waktu dulu sempat ada application frameworknya Svelte juga melakukan reload.
Jadi bedanya adalah ketika linknya kita hover, itu dia melakukan reload.
Hover baru pre-fetch.
Keliatannya memang meta framework apapun built-in routernya pakai strategi yang ini ya.
Kayak di Next.js juga kan ada next link itu pakai link komponennya Next.
Dia kayak gitu.
Mungkin si quick link ini memungkinkan, ya kan nggak semua orang pakai Svelte kita atau Next.js.
Jadi mau yang pakai WordPress atau Drupal atau create track app biasa,
pokoknya kalau di luar meta framework itu bisa dapatin behavior yang kayak gini.
Tanpa harus pakai remix.
Framework anostic.
Jadi sekiranya seperti itu.
Cuman kalau hover nggak enaknya di mobile kan nggak bisa hover.
Iya juga ya. Benar juga ya.
Kayaknya itu emang responsif deh kalau yang punya Next.js sama Svelte.
Ya kalau di mobile sama kayak gitu kalau masuk viewport di revenge.
Betul, betul, betul.
Konceptnya mirip ya.
Konceptnya mirip.
Tapi ini stand alone.
Stand alone.
Ini stand alone kecil dan single purpose ya.
Maksudnya nggak nempel sama framework apapun.
Oke, ini ada load ke scriptnya berarti ini bukan menjadi API-nya si Chrome atau browser kan ya.
Jadi tetap third party jatuhnya ya.
Coba ulang pertanyaan yang gimana.
Ini kan ada load quicklink.umd.js kan.
Berarti ini bukan nggak akan disupport oleh browser kan.
Bukan hanya browser dalam artian API browser.
Dia hanya meng-enable API browser yang ada.
Jadi API yang dipakai di sini ada dua.
Intersection Observer.
Terus kemudian Request Idle Callback dan Prefetch API.
Oh Prefetch API-nya itu bawaan dari browser.
Bawaan browser.
Tapi untuk melakukan enable itu kita butuh import kan.
Ini kayak rapper aja berarti ya? Kayak memudahkan aja?
Rapper aja.
Iya betul-betul.
Hanya kayak listen, terus nanti dia akan jalanin event-nya.
Sesuai dengan mendeteksi high-time email-nya itu aja.
Sesuai dengan di intersection Observer.
Kalau dia mendetek di intersection ada aharef.
Bakal dia ambil aharef-nya.
Dia prefetch.
Semudah itu dia cara kerjanya.
Seperti itu.
Ada lagi yang mau ditambahkan?
Itu aja. Sudah cukup.
Tidak usah banyak-banyak dulu.
Farid nih ada yang nanya sedang bahas apa.
Tadi bahas Prefetch API ya.
Jadi gimana caranya kita bisa menyulap aplikasi web kita yang multi-page application menjadi seperti single-page application.
Seperti.
Dia bisa mempercepat.
Berikutnya Eka, silahkan.
Nah ini mirip-mirip nih.
Performance juga ngambil area-nya Ivan.
Jadi ini ada artikel bagus.
Ini menarik dan ini bikinannya Googler juga.
Eddie Osmani dan ilustrator Libya Heli, kalau nggak salah.
Ini patterns.dev ini website yang membahas pendekatan atau pattern-pattern yang ada di arsitektur round-end web.
Nah salah satunya yang sering mungkin belakangan ini kita sering banget denger nih.
Ini namanya Islands Architecture.
Ini artiklenya panjang ya, lumayan.
Ntar kalau temen-temen penasaran mau baca sendiri aja.
Cuma intinya Islands Architecture ini adalah suatu filosofi atau pendekatan.
Approach baru dalam menyosun arsitektur front-end web.
Jadi ini yang di layar nih ada encourage small focus chunks of interactivity within server-rendered web pages.
Nah maksudnya itu apa?
Nah kita bayangin deh, ini pakai analoginya kan kepulauan.
Nah kebetulan negara kita negara kepulauan juga kan.
Jadi kita terbiasa nih, liat di peta nih, peta Indonesia bayangin lah.
Ada laut kan ya, ada Samudra India, terus ada pulau-pulaunya.
Nah dengan analogi ini, kalau diterapkan di aplikasi web front-end,
seluruh wilayah Indonesia dalam hal ini, maksudnya seluruh wilayah geografis itu baik laut maupun darat, itu aplikasi web kita.
Nah yang diibaratkan dengan pulau itu adalah bagian-bagian tertentu yang membutuhkan interaktifitas JavaScript.
Jadi diibaratkan yang bagian laut-lautnya itu yang statik.
Sementara ada pulau-pulau komponen user interface yang membutuhkan JavaScript.
Nah kalau kita bayangin pulau ini kan, pulau ada yang besar, ada yang kecil.
Terus mungkin masing-masing pulau ada iklimnya sendiri, ada kondisinya sendiri.
Nah itu diibaratkan dengan komponen user interface.
Terus kenapa bisa sampai ada teknik atau pendekatan seperti ini?
Kita lihat tuh ada point 1 dan point 2.
Nah dengan island architecture ini bisa menyeimbangkan 2 perspektif.
Yaitu pertama ada CSR, client-side render, dan kedua ada SSR.
Nah 2 approach ini sebetulnya punya keuntungan masing-masing.
Jadi kalau CSR itu contohnya yang dulu banget ya, yang paling pertama muncul maksudnya misalnya kita pakai create-react-app atau semacamnya.
Kan kita cuma punya shell HTML tuh, file index HTML-nya biasanya sangat sederhana.
Cuma head, body, dalamnya 1 div kosong yang lalu nanti dehydrate.
Kita harus nge-load sebuah file JavaScript entry point.
Nah semuanya seisi halaman web kita itu seluruhnya dirender oleh JavaScript ke dalam div kosong itu.
Nah itu tuh kan pasti punya beberapa kekurangan ya.
Pertama pasti file JavaScript yang di-download ukurannya sangat besar karena semua-semua kodenya itu untuk merender seisi halaman web itu ada di situ.
Nah yang kedua juga kan seperti tadi udah dibahas kan browser tuh punya satu main thread.
Kalau harus ngerender DOM element dari awal semua nih dari tadi halaman kosong, 1 div kosong doang, sampai banyak, sampai ada isinya semua.
Bahkan browser kerjanya jadi sangat banyak, itu main thread-nya juga harus bekerja keras dalam waktu lama itu kurang bagus untuk performance.
Nah terus yang kedua nih tadi di, apa, setelah orang sadar kekurangan client-side rendering, ada approach lain yang namanya SSR, server-side rendering.
Jadi semua DOM element-nya, HTML-nya dirender oleh server. Tapi ada masalah lagi nih kan dari server dikirim ke client.
Nah terus ada bagian-bagian yang perlu dehydrate karena butuh interaktifitas atau mungkin ada konten yang harus berubah secara real-time.
Nah sering nih yang terjadi adalah jadi harus kerja dua kali. Pertama apa, dirender oleh server, server render.
Lalu tetap aja misalnya kita pakai yang paling sering misalnya Next.js atau Remix, kan tetap harus merender ulang.
Kalau Next.js biasanya dia manggil JSON berisi isi halaman tersebut, lalu dihydrate ulang, dan komponennya direplace dengan hasil kalkulasi react runtime.
Nah kadang itu juga menghasilkan atau menyebabkan masalah performance.
Nah sementara kalau kita lihat nih isi suatu aplikasi seperti yang di layar itu, itu kan karakternya macam-macam ya, ada header, ada static menu, ada image carousel, product detail, dan lain-lain.
Sebetulnya kalau kita lihat, tidak semua komponen UI itu perlu dihydrate dengan JavaScript.
Nah dengan island architecture ini, kita memiliki kontrol yang lebih, kita bisa lebih fine-tune atau customized.
Pertama, bagian-bagian mana saja atau ibaratnya pulau mana saja yang ingin kita hydrate dengan JavaScript, itu pertama.
Lalu kedua, tingkat prioritas, kayak misalnya konten yang above default, pasti harus segera kita hydrate kan, karena itu sudah tampak muncul, udah dilihat oleh user.
Ini mirip sama yang API-nya masih berhubungan dengan yang dibahas Ivan tadi.
Sebetulnya kalau konten yang below default, kita bisa loading-nya belakangan saja, nunggu callback dari, apa tadi, request idle callback muncul.
Kita bisa fine-tune sesuai kebutuhan aplikasi kita. Intinya dari island architecture itu seperti itu.
Lalu sebetulnya island architecture sendiri itu kan tadi semacam filosofi atau pendekatan saja, tapi dia bukan belum masuk ke implementation detail.
Nah detail implementasi atau penerapannya seperti apa sih? Itu kayak dikembalikan ke masing-masing framework.
Jadi kalau yang kasus paling extreme, misalnya kita pengen manually hand roll semua, misalnya kita pasang saja, kita bikin web komponennya, kita bikin modul-modul,
terus kita pasang intersection observer, terus kita juga observe request idle callback, terus kita menghydrate seluruh komponen kita secara manual berdasarkan behavior yang kita inginkan.
Itu ya bisa, cuma mungkin sebagian besar developer nggak punya waktu dan tenaga sebanyak itu. Jadi pada umumnya sih orang menggunakan implementasi dalam bentuk framework yang sudah ada.
Nah beberapa contoh framework yang menerapkan prinsip atau filosofi island architecture itu, dicontohnya ada Marko, terus yang paling baruni dan mungkin teman-teman sering dengar belakangan ini tuh ada Astro,
lalu ada juga yang bikin integrasi, jadi kalau eleventy sendiri kan pure static, tapi ini ada yang bikin integrasi eleventy dan react untuk memperoleh behavior yang si island architecture seperti tadi.
Kira-kira gitu. Kalau di artikel itu ada contohnya, contoh penerapan atau implementasi yang sederhana di Astro, itu sih sekedar contoh saja.
Jadi misalnya kalau kita punya artikel atau blog post, artikelnya itu kan sendiri bisa dirender dari server site ya, dirender sebagai konten static HTML biasa aja, jadi yang dikirim dari server di awal mulai dari zero JavaScript.
Karena isi artikelnya kan mark up seperti itu, tapi contohnya di artikel itu ada komponen atau pulau kecil yang butuh interaktifitas JavaScript, ya itu dalam bentuk kita bisa like atau dislike.
Jadi ya udah, kita nge-load JavaScriptnya itu setelah dia muncul atau setelah browser main thread sudah tidak sibuk. Jadi intinya sih kita bisa dapetin the best of both worlds.
Kita bisa dapet halaman yang SEO friendly, performennya bagus, dan lain-lain dengan konten HTML static, tapi kita juga bisa dapetin interaktifitas yang menggunakan JavaScript client-side.
Apa yang terjadi ketika kita loading seperti ini, si JavaScriptnya kadang-kadang agak lambat, itu dia akan loading spinner dulu ya, berarti ya?
Nah itu kita bisa, kita bisa customize sih, biasanya kan kita pakai placeholder ya spinner, atau malah kosong sama sekali.
Cuma kalau above default itu nggak recommended ya, karena kan nanti jadi CLS-nya begitu dia loading kan jadiin dorong yang lain tuh, geser ke bawah semua.
Jadi kalau above default, kita harus pastiin pakai placeholder yang ukuran atau dimensinya sama kayak kontennya.
Tapi kalau di bawah sih ya, bebas. Geser gitu ya. Geser, ntar CLS kayak kemarin.
Apa CLS? Kepanjangannya? Cumulative Playout Shift. Playout Shift, CLS, oke.
Pro dan cons, performen sudah pasti kan? Oh iya, pro jelas, performen sih ya.
Jadi sebenarnya sih kalau yang aku lihat nih, pro-nya ya standar lah. Maksudnya sesuai ekspektasi kita. Kan sebenarnya kita udah punya CSR, punya SSR.
Nah, kita kayak memadukan keunggulan dari dua approach terhebut.
Jadi benefit-nya ya apa, tetap bisa interaktif tapi cepat, dan kita bisa memprioritaskan konten yang kita butuhkan.
Nah, cuma pastinya ada kekurangannya. Cuma yang aku lihat sini, kekurangannya lebih ke human factor-nya ya apa,
factor penggunaan. Jadi kayak misalnya apa, kalau kita mau pakai ya, yang tadi itu, kita harus,
ini kan karena customized banget ya, yang bisa mengontrol apa, yang bisa mengontrol mana yang harus dihydrate duluan,
mana yang harus perlu dihydrate atau enggak, itu kan sangat subjektif tergantung aplikasi kita.
Jadi ya kita harus pakai framework atau itu tadi kita hand roll semua sendiri dari awal.
Lalu apa sih, mungkin karena relatif baru ya, jadi belum terlalu banyak nekonon,
belum terlalu banyak diskusi tentang pendekatan ini. Terus kalau poin keempat sih ya, itu gimana kita lihat apa,
gimana kita memahami produk kita kan. Misalnya nih kalau aplikasi kita semuanya,
literally semuanya butuh client-side JavaScript, misalnya kita punya web-based game, kita punya game,
atau aplikasi map, atau aplikasi apa... - Figma? - Sosial media.
Pakai kanvas, ya Figma, pokoknya kalau emang dominan JavaScript ya, ini bukan solusi yang tepat
buat aplikasi kita. Jadi itu lebih ke human factor ya, apa? Usage factor.
- Oke. - Alaman memang rehydration itu adalah
proses paling mahal untuk aplikasi JavaScript. - Mungkin bisa dijelaskan rehydration itu apa sih?
- Oh ya, rehydration. - Oke, silahkan cek. - Kita punya markup HTML yang kalau berupa HTML
pastinya masih statik kan ya. Nah, rehydrate itu ibaratnya disiram atau digelontor oleh JavaScript client-side
yang ada event listener-nya mungkin, atau mungkin ada fungsionalitas misalnya nge-fetch konten,
ya kayak misalnya like button, biasanya like button itu kan seringnya nampilin jumlah like yang sudah ada,
atau mungkin ada avatar atau foto orang user sebelumnya yang sudah like. Nah, itu kalau pas awal kan
mungkin hanya berupa button biasa dari apa, yang dikirim oleh server. Setelah dihydrate, setelah digelontor
dengan JavaScript atau setelah apa, JavaScript dari konten itu, dari komponen itu berjalan,
itu dia akan mereplace atau memodifikasi DOM yang sudah ada, yang tadi dikirim, yang sebelumnya dikirim dari server.
- Oke. Jadi kayak dilanjutin ya, kerjaannya dilanjutin ya? - Iya, diberi interaktifitas.
- Hmm, oke. Jadi dikasih layer tambahan untuk interaktifitasnya ya? - Iya, client-side JavaScript.
- Oke. Kalau link yang kedua ini apa nih? Awesome. - Nah, link yang kedua itu masih berhubungan
sama yang tadi. Itu kan tadi artikelnya masih di level apa ya, semi teori ya, penjelasan island itu apa,
bla-bla-bla. Nah, cuma kalau kita ingin lihat penerapannya, itu ada beberapa contoh dari berupa framework,
terus ada yang sebenarnya bukan framework, tapi misalnya berbasis react to, fresh itu bikinannya apa?
Deno. Itu integrate sama Deno. Jadi ini lebih ke contoh bahwa si island architecture ini sekedar filosofi,
penerapannya nggak terpaku pada salah satu language atau library atau framework apapun.
Jadi misalnya bukan perkara react atau weld atau apapun, tapi lebih ke cara menyusun suatu aplikasi,
lebih ke architecture. Itu ada yang berupa full meta framework, ada yang berupa library tambahan,
bisa dipakai sama react, solid dan lain-lain. - Ada weld juga, kalau mau pakai weld,
gampangnya pakai elder JS gitu ya, kalau nggak mau manual gitu ya. - Enak loh pakai elder JS,
malah promosi framework. Pernah, pernah. - Oke. Mantap, mantap. Nah, berhubungan sama,
masih berhubungan sama pembahasannya tentang EKA, nyambung nih. Saya mau membahas tentang Astro.
- Yay, lanjut. - Yay, lanjut.
- Astro baru ini kan? Baru apa? Baru launching. - Baru 1.0.
- 1.0. Jadi sebenarnya awalnya Astro ini kalau gue lihat adalah dia seperti server-side,
static-side generator SSG kan awalnya. Tapi ternyata lebih dari itu ya, ternyata ya.
Jadi kurang lebih hampir sama, jadi si Astro ini menggunakan konsep si island,
walaupun ya, dia sudah menggunakan kata-kata island di sini ya. Jadi kan kalau menurut EKA tadi
dan menurut si Astro ini, website kita itu atau aplikasi web kita itu tidak 100% dinamis,
kecuali ya tadi game atau Figma atau apa. Ada hal-hal yang tetap static kan,
contohnya ini. Menu. Menu jarang sekali dinamis kan. Pasti bisa dibikin statis
walaupun akan ada kemungkinan perubahan kan, tapi jarang sekali. Dan hal-hal seperti ini
mungkin masih ada hubungannya juga dengan App Shell gitu ya. App Shell itu kan
sudah static kan. Yang dinamis itu yang di dalamnya kan. Jadi mungkin perkembangan dari sana.
Dan si Astro ini ingin menerapkan konsep island tadi ke framework-nya.
Salah satunya yang dijual adalah ketika di load pertama kali by default itu
JavaScript-nya zero atau kosong. Karena seperti yang sudah kita tahu sama-sama,
kalau di web itu ada beberapa aset yang paling besar dan bikin loading-nya lama.
Yang paling lama adalah image. Yang pertama image. Kedua itu font mungkin ya.
Font yang ketiga itu JavaScript gitu. Jadi belum-belum baru landing page tiba-tiba
sudah ada JavaScript yang segedegaban gitu kan. Padahal sebenarnya yang butuh interaksi
sebenarnya mungkin di halaman lain gitu. Di halaman kontekah atau di halaman yang
ada form-nya, ada button-nya dan lain-lain. Pada saat landing page sebenarnya belum
perlu di load JavaScript. Jadi JavaScript-nya bukan benar-benar kita buat
aplikasi web tanpa JavaScript. Tidak begitu. Tapi lebih ke di awal JavaScript-nya
nol dulu. Tidak ada dulu. Ketika butuh interaksi, ketika kita sudah sampai
scroll ke sini, nah itu dia baru load. Seperti preload tadi ya, kurang lebih ya.
Konsepnya juga masih mirip-mirip ya. Kurang lebih seperti itu.
Lebih tepatnya lazy load sih. Kalau preload itu artinya saat page load,
bukan, sebelum page load, dia mengambil duluan. - Font biasanya itu.
- Preload itu paling pertama. Ya preload itu paling highest priority itu preload.
- Oke. Nah disini fitur utamanya ya inilah, sudah kelihatan ya. Component Island,
yang tadi sudah kita bahas. Kemudian ada ngomongin hydration juga.
Zero J is by default. Edge ready ini mungkin bisa jadi topik berikutnya ya
tentang edge function gitu ya. - Nah bahas tuh.
Gue nggak ngerti-ngerti soalnya. - Jadi intinya kita mau bawa
fungsi-fungsi yang di belakang layar, kayak back-end gitu ya, itu dekat dengan,
sedekat mungkin dengan pengguna. Jadi bisa nempel ke CDN lah, kira-kira kayak gitu.
Ada Cloudflare Worker, ada banyak lagi yang lain. Si Versal juga punya,
ada Deno juga, dan lain-lain. Kita bahas nanti di episode-episode berikutnya.
Jadi tungguin aja. Subscribe, subscribe. - Oke.
- Oke. Tadi juga sudah sempat dibahas di Island Architecture. Salah dua-duanya adalah
namanya Quick. Ini juga cukup baru ya. Ini malah lebih unik lagi dalam artian,
kita tadi ngomongin hydration, sementara Quick ini katanya tidak ada hydration.
- Oh. - Gimana caranya?
Nah itu, saya juga belum tahu, tapi ini menarik gitu ya. Dia sudah support
otomatis lazy loading, jadi kita nggak perlu install apa-apa, ada image kah,
ada apa dia bikinin lazy loading-nya, dan ada Edge Optimized juga,
masih mirip dengan Astro juga. Dan yang menarik adalah yang bikin,
mana dia? Oh nggak usah, ntar dulu. Ya ini ya, zero loading, katanya nggak perlu
hydration, karena it is resumable, saya belum tahu ini resumable-nya kayak gimana,
konsepnya ya. Jadi lazy loading-nya sudah by default, dan lain-lain bisa dibaca sendiri.
Nah, yang saya mau highlight adalah yang bikin. Yang bikin ini.
- Yang bikin angular ya? - Dispoiler pre ini adalah yang bikin angular.js.
Saya nggak tahu, kayaknya dia bikin juga angular 2 ya, angular yang versi
berikutnya ya. Dia bekerja di Google, mungkin sekarang sudah nggak ya.
Terus, si ini, Manu, dia bikin, yang bikin Gin, framework-nya Goleng ya,
kalau nggak salah. Terus juga stencil ini adalah framework untuk Web Component.
- Web Component ya? - Ya. Dan yang ketiga, Adam itu dari Ionic.
Jadi mereka kayaknya pecahannya angular ya. Ionic kan cukup populer di, apa?
Ionic awalnya kan hanya support angular kan, walaupun sekarang sudah bisa semua kan.
Jadi ini menarik, dan dengar-dengar juga, si Google itu sebenarnya punya
framework internal yang tidak dipublish keluar, yang konsepnya adalah seperti ini.
Seperti Island, seperti Astral, dan seperti Quake. Tapi tidak di open source dan
tidak dipublish. Mereka pakai untuk web mereka sendiri. Begitu.
Jadi cara kerjanya Quake ini, sedikit, yang saya tahu ya, karena saya baru baca-baca.
- Siap. - Dia Hardtml, maksudnya yang JavaScript yang sudah di-hydrate itu,
kan katanya no-hydration. Ya, memang betul. Jadi bisa scroll up,
saya lupa namanya. Nanti saya salah ngomong, jadi ini lagi.
- Semua si Huax. - Atas sedikit, atas sedikit.
Oke, dia bilang that's summable. Jadi sebenarnya dia sudah secara HTML,
di bagian server-side, dia sudah ngerender HTML-nya. Terus yang bagian JavaScript,
yang event yang perlu di-handle itu, dia sudah simpan di data attribute,
di attribute HTML-nya. Jadi dia tinggal replace.
Oh, jadi bukan hydration kayak ekspektasi. Kita kan tadi si JavaScript-nya
bikin atau mengkalkulasi DOM di-replace. Kita kan bayangin Hydrate gitu.
Asil kalkulasinya sudah disimpan sebagai data attribute, sehingga data attribute-nya
itu gede, tetapi karena data attribute itu tidak perlu dirender oleh browser, ya.
- Iya, si browser-nya nggak kejauh lagi. - Jadi dia tinggal replace.
- Oh, oke. Galaxy Brain approach-nya ini. - Ini yang lucunya, ya bukan lucu ya,
agak sedikit menyedihkan mungkinnya buat saya. Maksudnya, saya tuh baru tau
island stikler ya sekarang-sekarang ini. Tahu astrol memang sudah cukup lama,
baru-baru tau ternyata astrol itu pakai island, kan. Dan hydration dan lain-lain
juga baru-baru belajar, gitu kan. Eh, ternyata udah ada framework yang sudah
menyelesaikan masalah di hydration. Hydration ini katanya lumayan kompleks,
ya kan. Terus take several seconds juga, ada loading time-nya juga, kan.
- Banyak banget. - Iya, dan lain-lain gitu kan.
Yang menyebabkan performa-nya agak kurang, gitu. Dan sudah ada solusinya di Quick.
Jadi memang itu tadi yang kita sempat ngomong di belakang layar framework JavaScript itu
luar biasa ya perkembangannya, ya. - Jadi pengalaman saya dulu waktu kerja
di sebuah project itu headless dan full pakai React application.
Yang terjadi adalah dia news site, news portal, cukup gede. Dan tentunya
kalau dibuild pertama itu kan kecil ya. Tapi makin lama-makin lama komponen
makin banyak, terus kemudian feature makin banyak, tambah sini, tambah sana.
Terus itu ininya apa namanya itu? High order komponen terus kayak sudah berlapis-lapis tuh.
Hoc-nya itu bisa kayak berlapis-lapis, lapis-lapis. Dan akhirnya... - Oh pusingnya tuh.
- Kan terus dia ada server-side karena butuh SEO, server-side rendering.
Saya sampai pusing kepala gimana caranya apa tuh namanya, tree-shaking supaya
di halaman home page ini dong. Belum ada, jaman itu belum ada Next.js teman-teman.
Waktu itu jaman tahun 2000. - Jaman jangil liat ya.
- Awal-awal liat lah ya, 2000. Saya bukan awal-awal banget.
Tapi jaman itu Next.js belum se-mampu sekarang, secanggi sekarang.
Jaman itu masih belum. 2017, 2018 lah. Nah, jadi belum ada Gatsby.
Masih baru kayak pure application gitu. Nah kita bikin itu supaya,
saya setengah waktu itu mahir main dengan webpack 4 atau webpack 4 gimana
supaya optimization terus kemudian chunk-nya itu dipisah-pisah.
Tapi at the end, pusingnya adalah saat dehydration dia itu butuh
download semua chunk yang dibutuhkan itu supaya bisa melakukan hydration.
Untuk download chunk itu segitu banyak. Mau pakai preload kan tetap aja preload.
Kalau preload 1,4 megabyte ya tetap aja gede. - Iya, jadi memperlambat juga ya.
- Ke Parsing 1.1 juga browser-nya kerja kan kalau chunk-nya terlalu banyak. - Iya, targetnya 600 kilobytes.
Sudah sama image ya kan. Ini JavaScript doang, 1.4 megabyte coba.
- Satu floppy disk itu. - Pusingnya adalah,
belum ada yang namanya isiannya partial rehydration. Kan ada tuh ya.
Kemudian React nggak bisa hydration mahal, terus kemudian Vue muncul,
Vue mengeluarkan partial rehydration, akhirnya React support sedikit baru-baru ini partial rehydration.
- Server component sekarang juga udah bisa. - Jadi...
- React server component ya?
- Jadi, sekarang saya lihat arah framework itu kaya island pattern ini.
Kalau bisa first page load, no JavaScript. Itu yang betul.
First page load, jadi gunakan environment atau gunakan sistem yang sudah ada dari browser.
Banyak loh API-API browser, mungkin kita bahas minggu depan atau selanjutnya ya.
Banyak banget API-API browser yang sudah menarik. Contohnya, intersection observer.
Dulu kan kalau kita mau scroll, kita harus kaya, apa itu istilahnya? Get bound rectangle.
Untuk tau intersection sekarang, intersection observer. Resize observer.
Kalau screen-nya di resize, bisa otomatis. Container view, di CSS juga sudah ada container.
Kemarin kita bahasa. - Container query.
- Container query, udah canggih. - Ada back-forward cache juga.
- Oh ya, cache. - Itu juga, gue belum belajar tuh back-forward cache.
Ada nggak sih framework yang wrapping di atas API-API ini? Yang murni dari wrapper-nya untuk ini aja.
Karena kan kalau kita pakai satu-satu, capek juga kan? Harus setup satu-satu kan?
- Harus digantung kebutuhan atas. - Sebenarnya sih, makin kesini kayaknya
makin banyak metaframework yang pakai native web API, ya. Jadi kayak misalnya, remix, ya.
Astro juga. Jadi Astro itu kan, kalau kita pakai UI, pakai swell, triac, atau pakai JavaScript-based component,
kita tuh bisa pakai direktif namanya client, client idle, client visible, sama kalau yang default sih langsung di-hydrate.
Nah, kalau di Astro nih, si client idle dan client side idle dan client side visible ini juga sebetulnya itu nge-wrap web API.
Jadi idle itu tadi, request idle callback, visi dari intersection observer.
Jadi kayaknya sih, dengan makin bagusnya browser interoperability, jadi apa, web API udah mulai banyak diadopsi di browser-browser,
kayaknya trend framework dan metaframework dengan sendirinya makin streamline mungkin ya.
Daripada dia bikin sendiri baru, dia pakai spesifikasi yang udah ada, karena user pun udah familiar.
- Yes. Tapi kadang-kadang kebalik. Jadi ide muncul awal ide-nya itu adalah dari framework biasanya.
- Oh. - Preload misalkan. Oh ini, apa namanya, oh JSX kan. Dulu sempat ada wacana katanya JSX masukin dong ke Chrome atau ke browser gitu kan.
Jadi kita nggak preloading kan ada gitu kan. - Eh nggak jadi ya tuh ya.
- Jadi sebenarnya yang ngedrive si web API yang ada di browser, salah satunya juga framework kan.
- Ya juga. - Web itu komunitas, Mas.
Komunitas web. Web itu komunitas yang ada di seluruh dunia dan kita itu tergabung dalam sebuah ekosistem yang namanya web.
Dan sebenarnya web itu adalah hanya halaman yang disimpan di mesin yang lain yang terhubung dengan network.
Ya kan? Bener ya? - Betul.
- Komunitas terbesar di dunia adalah komunitas web. Pengguna web.
- Iya. Walaupun kalau dari sisi bisnis, kadang-kadang orang tuh cukup sering berpendapat, berasumsi kalau sebenarnya lebih apa ya, prioritasnya tuh lebih ke mobile. - Tergantung bisnisnya juga sih.
- Atau familiaritas dari user, kalau yang user awam kan terbiasa nginstall dari Play Store, App Store ya. Tapi itu kan udah mulai bisa diadres dengan TWA.
- Ya.
- Belum lama yang gak kedengeran tuh TWA. Gimana nasibnya tuh? Udah mature ya? Yang penting kalau buat web jadi Play Store. - Yang pake sih tetap ada gitu, maksudnya udah gak diomongin lagi, pake-pake aja gitu.
- TWA, sekarang ada Trusted Web App, itu jadi kayak apa? Ya sebenarnya kayak Android Web View tapi yang lebih powerful lah. Jadi kita tetap nge-deploy web biasa, udah bisa diinstall dari Play Store.
Kalau secara performa dan secara apa ya, API-API yang kan kadang-kadang Android ataupun iOS itu kan ada butuh akses kamera lah atau apa gitu. Itu aman semua.
- Ya, tetap pake permission sih. Permissionnya web. Jadi ya flow-nya sih sama aja. Kita yang handle aplikasinya yang handle UI untuk munculin dialog permission.
- Hmm, oke. Nah ini ada yang menarik juga nih, tambahin dikit ya.
- Apa tuh?
- Ini Astro, dia bahas tentang MPA versus SPA. Ini bisa jadi topik kita.
- Nah nyambung dong, asik ya nyambung. Topik kita semua nyambung.
- Banyak sekali ya topik kita ya. Kita harus catat nih. Topiknya banyak sekali yang akan kita bahas. Karena lucu ya, jadi tren itu berputar kan dari awalnya memang MPA, awalnya kan multi-page application gitu kan.
- Server-side MPA, jadi kayak Laravel, Rubion Rails ya kan. - Terus abis itu bergeser kan trennya ke SPA. Semua server SPA kan.
- SPA dan Pure Client, client render kan dulu pas awal-awal react.
- Oh bahasa kerennya, headless, headless, headless gitu ya. Semua headless, tiba-tiba trennya headless.
- Terus abis itu setelah SPA-nya dirasa performanya kurang bagus, balik lagi ke MPA lagi. Walaupun MPA-nya udah plus-plus ya, udah beda dengan MPA jaman dulu ya.
- Udah banyak API-API, salah satunya yang tadi, salah duanya yang dibahas Ivan di awal tadi, bisa menyulap dalam tanda kutip multi-page application menjadi seperti, seolah-olah seperti SPA. Secara performa juga jauh lebih cepat, sehingga user itu paling sulit untuk disuruh menunggu kan.
Kalau nggak ada respon selama beberapa detik udah di-close aja tuh tab-nya, segampang itu. Makanya kita harus baik-baikin tuh si user gimana caranya supaya dia tidak kabur.
- Gantung kontennya, Mas. - Gantung kontennya. Kalau kontennya apa? Clickbait gitu ya.
- Kalau kontennya manis. - Kalau kontennya jelek ya nabur.
- Kalau kontennya banyak gulanya, loh kok gula lagi. - Nanti bisa nggak sih, awas.
- Kalau si multi-page app ini, Astro itu kan multi-page app, dia belum punya single client-side router kayak Next dan lain-lain.
Tapi Astro ini kan point of view-nya emang pengen pakai web standar. Jadi dia pakai, bukan si Astro-nya sendiri, cuma ada orang yang pengguna Astro yang bikin eksperimen.
Itu tadi pakai Shared Element Transition API yang tadi dibahas Ivan Skilas, dikombinasikan sama pre-fetch halaman, dikombinasikan dengan Astro.
Jadi intinya dia bikin MPA rasa SPA. Jadi emang Astro itu emang sangat perspektifnya itu tadi menggunakan web API yang sudah ada untuk improve performance.
Jadi mengurangi kerja si JavaScript yang kayak di React Router atau Library Router tradisional, jadi dia lebih ke web API untuk optimasi performance.
- Kalau bisa, saya lihat trendingnya ke depan, sebisa mungkin pakai environment atau native-nya dari browser itu sendiri.
Jadi native-browser-nya yang development-nya makin kencang. Saya lihat banyak banget API baru muncul.
- Remix-nya ini sama seperti remix juga kayaknya ya si Astro ini juga.
- Emang belum pernah pakai remix tuh? - Iya. Kalau Astro ini kan sudut pandangannya sedikit berbeda. Kalau Astro ini dia lebih dari HTML CSS.
Kalau butuh JavaScript, baru ditambahkan. - Dan itu islands per komponen. Kalau remix di level aplikasi ya dia?
- Di level aplikasi JavaScript. - Optimasinya. - Iya, optimasinya. Terus kemudian menggunakan API web yang ada.
- Kalau remix itu menariknya di form-nya justru yang gue lihat. Dia punya itu komponen form sendiri kan.
Dia punya komponen form dengan perspektifnya sama. Kayak itu kalau kita pengen hydrate dengan JavaScript, kita opt-in.
Tapi by default, komponen form bawaan remix itu menggunakan web API untuk form. Jadi itu bisa dibikin full server side.
Jadi dia malah jadi kayak Laravel atau Ruby on Rails atau semacamnya. Jadi by default itu HTML, HTML only menggunakan web API yang udah ada.
Tapi kalau mau kita bisa opt-in untuk hydrate dengan JavaScript. - Terus kalau yang gambar-gambar gitar ini apa?
- Itu contoh transisinya. Coba diklik. Cuma flag shared element transisinya udah di-enable atau belum tuh?
- Belum. - Kalau belum ya nggak bisa. - Ini masih loading ya? - Ini nih. - Ya, nggak bisa.
- Bentar, ini flag-nya nih. Lokasi di private chat. Tapi harus reload browser ya. - Oh reload ya, mana? - Iya.
- Namanya adalah document transition. - Dokumen transition. - Belum ada ini. - Maksudnya pakai edge. - Edge berapa Chrome? Oh belum ada, dia harus Chrome 104. Chrome 104.
- Belum, belum masuk. - Ada kanari ya kanari? - Nggak usah kenari. Chrome biasa asal pakai flag.
- Ini flag-nya aja belum ada. 105 versi 105 belum ya? - Iya, udah kok. - Udah harusnya. - Dokumen transition nggak ada. - Chrome 104 adanya. - 105, nggak ada.
- I use. - Defect. Defect tuh John John versinya. - Coba di masukin stream saya. - Oh ya, sorry. - Oke. Tadi Astro Music ya.
- Tuh, bisa gitu tuh. Wih keren. Terus dia lazy load juga nih. Cuyung. Wih. Serasa SPI ya. - Ini SPI ya? Oh wow. - Iya, MPA, pure MPA. Cuma pakai web API itu tadi shared document transition.
Kita lihat ininya. Kita lihat load-nya biar sah gitu ya. Kita kan web. Tuh. Bener nggak ini? Tuh, bener tuh. Dia nge-request tuh. - Oke. - Kita coba yang lain.
- Itu ada countdown di atas itu buat apa ya? - Supaya ngasih tahu kalau ini nggak pindah halaman. - Oh, nggak pindah halaman. - Bukan, bukan. Supaya ngasih tahu kita nggak pindah halaman.
Karena kalau di-reload kan jadi nol lagi. - Nol. Jadi behavior-nya beneran kayak client-side routing padahal dia pakai, ya, apa? Ah, ref, anchor, eh, elemen biasa ya. Cakep. - Ini, ini. - Oh, nice.
- Ya, they load, they load fragment nih. Oh, menarik ini untuk di kulik lagi, ya. - Nah, cuma ngomong-ngomong flag nih, apa, ada nggak sih yang bisa kita kerjain, kita lakuin sebagai developer biar mempercepat si flag ini, apa, feature ini diadopsi oleh browser lainnya.
Kayak misalnya kita file, kita mungkin ada apa gitu, isu atau apa di browser lain, +1. - Ikut di web konsorsi, pasti ada.
- Ya, maksudnya kita ramai-ramai bilang, please dong browser lain, please adopt, apa, shared element transition ini secepatnya. Pengen nggak sih bisa pakai itu tadi semua, apa, kalau ini kan sebenarnya cuma demo untuk nunjukin API ini bisa dipakai buat apa sih.
Tapi kan realistically, masih bakal lama banget kan sampai kita bisa beneran pakai ini, dapetin behavior kayak gini tanpa install library tambahan yang berat.
- Kayaknya bisa. Kalau nggak salah kan kita di invite, ada di GDE meeting tuh soon. Kan pasti bakal ada, kalau nggak salah di bagian Fugu, Fugu kali ya, Fugu API ya.
- Oh iya, kita +1 yang banyak gitu. Nah, kalau ini kan sebenarnya dia udah beyond RFC ya, maksudnya ini kan udah masuk di Chrome, terus standarnya juga udah ada di Chromium,
tapi kan terserah untuk masing-masing browser untuk mau mengadopsi atau nggak. Nah, berarti kita tuh kayak harus nge-spam, apakah kita harus nge-spam browser-browser lain, please, please dong masukin API ini, kita pengen pakai, ini berguna, ini bagus, dan lain-lain.
- Kalau untuk khususnya untuk yang dokumen transition ini, nggak tahu ya secara web consort SIM, dia sudah, kan masih draft ya, spesifikasinya ya. Kalau khusus transition ini, dia masih draft spesifikasinya.
Jadi, masih butuh waktu yang panjang. Masih di diskusi nih bahasannya. - Ah, oke. Ya, sedih. - Tunggu-tunggu. Kalau lo pengennya ini bisa, apa namanya, pengen ini jadi kenyataan, ya kan?
Bisa nih ikut di specification, dan developer feedback is really important. - Oh, important. - Kita bisa bantu, kita bantu tes. Kita bantu tes dan kita bantu bikin isu.
Itu satu. Kedua, coba-coba kita ikut ke consort SIM ini. - Tapi kan ini mostly Chrome, kan? - Nggak, ini W3 standard. No, no, no.
- Dia kan, pertama kan, memang ini lahirnya dari Chrome, dari CJ Archibald sih. Kan sudah dibikin spesifikasi, dibikin, no, no, no.
Kalau sudah di-approved dulu di web standard, tuh, draft-nya aja baru update, 2022. Jadi, kalau ini sudah, udah clear semua dan jadi web standard, sudah di-approved nih, masuk nih,
jadi web standard, baru web browser lain, adopsi, jadi masih lama nih ceritanya. - Sedih.
- Tapi bisa bantu untuk ngetes kalau memang kita pengen banget, gitu.
- Kalau salah satu caranya ini, kan, buat kontribusi ke GitHub-nya atau ke draft-nya atau ke request for comment, kan.
Kontribusi lain adalah bikin itu, bikin use case yang akhirnya mereka mempercepat, ya itu tadi bikin framework.
Loh, katanya. - Loh, found. - Sebegitu, absolutely replace. Loh.
- Ayo, udah nggak ada. - Pindah kali, paling pindah. Apa, ganti URL?
- Tapi ya, sebenarnya bagusnya, walaupun ini bakal masih lama, sampai kita bisa pakai yang demo, kayak yang demo kita lihat tadi, bagusnya kan web itu selalu backwards compatible by default.
Jadi, walaupun si shared element transition API itu belum supported pun tadi, ya kita klik, kita tetap bisa navigasi ke halaman satunya, kan, karena itu fallback-nya adalah, apa, encore a-ref, elemen a-ref biasa, jadi nggak masalah.
Sementara kalau misalnya kita bergantung PureJS, misalnya kita pakai React Router atau semacamnya, kalau belum supported, ya udah nggak bisa pindah halaman, runyem, kan.
- Ini minimal bisa pindah halaman meskipun counter-nya ke reset, ya maksudnya. - Ke reset dan nggak secakep, nggak se-WOW yang versi shared element API-nya.
- MPA. Semi-MPA. - MPA rasa S-P-A.
- Wah, kita udah sejam lebih loh. - Iya, nggak terasa.
- Mau main? - Oh iya, buat teman-teman yang mau kasih bantuan untuk topic diskusi atau link-link menarik atau pertanyaan-pertanyaan seputar web, bisa langsung aja di-submit.
Di-submit di komentar, kalau lagi live, di-komentar, tapi kalau misalkan lagi tidak live, misalkan teman-teman nonton yang recording, yang rekamannya, bisa ke bit.ly/ngobrolinweb, ya.
Bisa di-submit aja di situ, topik-topik yang mau dibahas. Tadi kita udah banyak banget bahas tentang, apa, tentang...
- Yes, quickly. - Iya, private sama tadi, apa, request idle. - Idle callback. - Ya, beberapa web API. - Request idle callback. - Yes. Terus juga bahas tentang island architecture dan beberapa framework yang berkaitan dengan island architecture.
Tadi juga udah sempet muncul beberapa idle, bahas tentang MPA versus SPA, terus juga ada bahasan tentang edge function, ada apa lagi tadi ya. Itu harus kita catat dan harus kita jadikan topik-topik berikutnya.
Kritik dan saran juga bisa ya, kirimin ke sini aja. Siapa tahu teman-teman punya apa ya, "Wah, ini kayaknya formatnya ini lebih bagus kalau ditambahin segmen ini, segmen ini." Kita akan terima sekali karena ini baru 2 episode ya, baru 2 episode.
Dan kita sendiri juga masih belum tahu formatnya yang bagus kayak gimana, jadi kita cuman ya udah ngobrol aja, ngobrol santai. Kalau ada apa, ada yang mau demo-demo dikit, boleh. Kalau nggak, ya kita ngobrol aja, gitu. Karena kembali lagi, tujuan kita adalah untuk up to date, supaya tetap up to date.
- Kami kita sendiri juga update. - Belajar satu sama lain. - Betul, karena di pekerjaan kita masing-masing sudah mulai menggunakan web API atau framework atau apapun, library, yang itu-itu saja.
Belum ada, misalkan yang baru-baru kayak apa, tadi query, CSS query apa, ya itulah banyak ya. Container query dan lain-lain. Nah itu kita belum sempat pake, gitu.
Dan kalau kita mau bahas itu di sini, sekalian belajar, gitu. Kalau nggak, kita nggak ada kesempatan belajar. Jadi, terima kasih buat temen-temen yang sudah hadir, yang sudah nonton, ditunggu juga.
- Ada yang mau jadi apa, mau ngobrol sama kita juga boleh. - Bintang tamu. Featuring. Collab. - Benar. Mungkin ada yang mau ditanyakan langsung atau ada yang mau kasih pendapat tentang satu topik, silahkan.
Dan untuk malam ini, kita sudahi dulu, karena sudah jam, sudah satu jam kita ngobrol. Mudah-mudahan kita ketemu lagi di lain kesempatan. - Minggu depan. - Mudah-mudahan minggu depan kita usahakan.
- Itu aja untuk malam hari ini. Terima kasih dan selamat malam. - Terima kasih semua. - Bye bye.
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://bit.ly/ngobrolinweb Topik obrolan - Fenomena “islands architecture” dan “partial hydration” - https://www.patterns.dev/posts/islands-architecture/ - https://github.com/lxsmnsyc/awesome-islands - Fenomena frontend framework dengan JavaScript yang minimal seperti astro.build, ada qwik.builder.io juga. Lainn Kunjungi https://ngobrol.in untuk catatan, tautan dan informasi topik lainnya.
Episode Terkait
2 Jan 2024
Yang Seru di 2024
Episode ini membahas tentang hal-hal seru yang dinantikan di dunia web development pada tahun 2024. Para host membahas p...
25 Feb 2025
Ngobrolin Fitur Terbaru CSS bersama @AdamArgyleInk dan Bramus @ChromeDevs
Episode ini membahas CSS Wrap 2024 bersama Adam Argyle dan Bramus, dua Developer Relations Engineer dari tim Chrome yang...
28 Jan 2025
Ngobrolin CSS Wrapped 2024
Episode ini membahas CSS Wrapped 2024, sebuah showcase interaktif yang menampilkan 17 fitur CSS baru yang dirilis sepanj...
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 .