Ngobrolin CSS
Ringkasan Episode
Bantu KoreksiEpisode ini berbenang merah CSS, dari sumber belajar sampai fitur yang baru saja tersedia. Dibuka dengan menjawab pertanyaan penonton soal Quicklink: prefetch tidak menambah jumlah pengunjung secara langsung, tetapi ada efek samping yang jarang disadari — setiap prefetch tetap menjadi page request di sisi back-end, sehingga pada situs bertrafik besar dengan tagihan berbasis jumlah request, biayanya bisa membengkak. Bagian terbesarnya membahas inline CSS versus file CSS terpisah. CSS bersifat render blocking: browser menunggu file-nya selesai diunduh dan diparsing sebelum melanjutkan render, sehingga LCP ikut tertahan. Solusinya menyisipkan CSS kritikal langsung di dalam tag style, tetapi trade-off-nya nyata — HTML jadi lebih besar dan tidak bisa di-cache browser. Patokan praktis yang dipakai adalah sekitar 5KB; kalau sudah mencapai puluhan kilobyte, sebaiknya dipisah. Pengalaman memecah CSS sampai per komponen justru membuat halaman lebih lambat karena tiap file punya delay sendiri. Topik berikutnya container query, fitur yang mulai diminta orang sejak 2013 dan baru stabil sembilan tahun kemudian. Bedanya dengan media query: media query hanya tahu ukuran viewport, sedangkan sebuah komponen bisa saja ditempatkan di sidebar sempit meski layarnya lebar. Dari sini muncul diskusi bagus soal kapan mengadopsi fitur yang belum merata dukungannya — jawabannya bukan menunggu semua browser, melainkan melihat data analytics pengguna sendiri, memakai polyfill, dan menerapkan progressive enhancement. Ditutup dengan cerita harus mendukung IE11 karena pegawai bank memakai laptop kantor yang browsernya dikunci dari pusat.
Poin-poin Utama
- •Prefetch tidak menambah pengunjung secara langsung, tetapi setiap prefetch tetap menjadi page request di back-end — pada trafik besar dengan tagihan berbasis jumlah request, biayanya bisa membengkak
- •CSS bersifat render blocking sehingga LCP ikut tertahan menunggu file-nya selesai diunduh dan diparsing — inilah alasan CSS kritikal disisipkan langsung di tag style
- •Trade-off inline CSS: HTML jadi lebih besar dan tidak bisa di-cache browser, jadi patokan praktisnya sekitar 5KB; memecah CSS sampai per komponen justru melambatkan karena tiap file punya delay sendiri
- •Optimasi Core Web Vitals itu untuk pengguna, bukan untuk mesin pencari — menyisipkan semua CSS memang membuat skor hijau, tetapi pengguna terus mengunduh isi yang sama berulang kali
- •Container query menjawab keterbatasan media query yang hanya tahu ukuran viewport, padahal satu komponen bisa ditempatkan di sidebar sempit meski layarnya lebar — fitur ini diminta sejak 2013 dan baru stabil sembilan tahun kemudian
- •Untuk memutuskan mengadopsi fitur yang belum merata dukungannya, kirim deteksi dukungan API ke analytics dan kumpulkan datanya beberapa minggu — jadi seperti caniuse khusus pengguna kita sendiri
- •Framework berganti tetapi fundamental bertahan: prinsip prefetch, render blocking, dan hidrasi tetap sama entah memakai React, Svelte, atau Angular
Halo-halo semuanya, selamat malam, selamat hari selasa dan hari selasa adalah waktunya ngobrolin web.
Sama kita bertiga, bersama saya Riza, ada Irvan, kita bertiga adalah tergabung ke dalam sebuah programnya itu Web GDI.
Enak banget ya openingnya ya.
Google Developer Expert for Web Technologies.
Ya, kita adalah tiga, hanya tiga ini orang yang ngurusin GDI web di Indonesia ya, di seluruh Indonesia ya.
Luar biasa.
Dan kita juga supaya bisa, karena mengikuti update-update teknologi di web itu susahnya, minta ampun.
Susahnya karena terlalu banyak update-nya.
Terlalu banyak kan terlalu cepat.
Jadinya, mending kita ngobrolin aja setiap minggu, setiap hari selasa.
Setiap minggu, setiap hari selasa.
Oke, nah kita malam hari ini topiknya ada topik, benang merahnya ada tentang CSS.
Jadi mulai yang basic banget, sampai yang lumayan baru ya, API baru dari CSS juga ya.
Ada performa juga seperti biasa dari Irvan.
Tapi sebelum itu kita masuk ke ini dulu, ada yang nanya. Senang banget nih, saya kalau ada yang nanya, jadi aktif kan.
Jadi dari video minggu lalu, ada dua pertanyaan.
Dari episode minggu lalu.
Ya, dari episode minggu lalu ada dua pertanyaan.
Yang pertama pertanyaan tentang quicklink.
Apakah quicklink akan mempengaruhi jumlah visitor menjadi lebih banyak?
Oke, ini ditujukan ke saya ya, karena saya yang sampaikan tentang quicklink minggu lalu.
Oke, jadi sebenarnya untuk mengulangi sedikit aja, quicklink itu semuanya hanya library kecil aja.
Saya coba paste aja di sini ya.
Quicklink, itu library kecil yang dibuat oleh Google Chrome Labs.
Untuk melakukan prefetch terhadap halaman-halaman selanjutnya yang didapat dari link-link yang ada muncul di viewport atau di tampilan layar user.
Jadi halaman tersebut di prefetch dari background.
Jadi sehingga saat user nge-click atau pencet link itu, serasa kecepatan situsnya jauh lebih cepat karena sudah di prefetch.
Sehingga hanya butuh kayak sekian millisecond halaman tersebut sudah belum.
Oke, aku kembali ke pertanyaannya.
Apakah quicklink mempengaruhi jumlah visitor menjadi lebih banyak?
Lihat transkrip lengkap (611 segmen lagi)
Jawabannya tidak. Tidak ada hubungannya.
Tetapi secara tidak langsung karena situsnya serasa lebih cepat, tentunya user makin senang dong untuk melihat,
membrosing situs kita untuk melakukan, ngecek-ngecek situs kita ya, karena cepat banget.
Kalau diimplementasinya dilakukan dengan benar, itu serasa headless, jadi serasa SPA.
Diklik langsung muncul, klik langsung muncul, jadi serasa SPA dia, single page application.
Jadi secara tidak langsung bisa mempengaruhi jumlah visitor lebih banyak karena user lebih engaged terhadap situsnya.
Yang tidak sempat saya kasih tahu minggu lalu, itu adalah pengaruhnya ke back-end sebenarnya.
Apa tuh pengaruhnya?
Back-end, jadi kan dia melakukan prefetch ya, request ya, request ke back-end setiap kali link-nya muncul.
Artinya di back-end itu jadi page view, jadi page request.
Kalau situsnya hanya skalanya masih kecil dan menengah, ya hostingnya tentu nggak pengaruh.
Tapi kalau situsnya sudah view-nya jutaan, itu dan hostingnya punya payment plan-nya itu by page request,
berapa jumlah page request itu bisa perlu hati-hati untuk kendalinya.
Sangat sengaja ke DDoS sendiri ya?
Serasa seperti ke DDoS sendiri, tetapi gini, bill-nya bisa bengkak karena contohnya apa ya page request?
Setahu saya banyak kan cloud product, kayak Google Cloud atau AWS ya, AWS atau yang manage-manage hosting itu,
mereka ada batasan limit untuk jumlah page request, by page request.
Jadi kalau misalnya pakai quick ring, perlu hati-hati untuk page request tersebut.
Oh, sudah ya? Baru mau diganti ininya.
Oke, pertanyaan kedua. Pertanyaan pertama jawabannya ya dan tidak.
Ya, karena website-nya lebih cepat, lebih banyak orang yang suka dan lebih banyak juga, secara otomatis lebih banyak user yang bisa di-serve-kan.
Yang kedua, apakah dengan kita belajar React, peruang mendapatkan pekerjaan akan lebih besar?
Ini juga jawabannya ya dan tidak.
Tergantung mau kerja dimana.
Ya, betul. Jadi, ada dua kubu ya, kayak dua sisi mata uang ya.
Ada yang mengikuti trend itu bukan sepenuhnya salah, tidak sepenuhnya salah.
Karena memang peluang besar di sana ya, peluang banyak di sana gitu, lewangan pekerjaan dan lain-lain.
Tapi di sisi yang lain, kembali lagi ke diri kita gitu.
Misalkan kita kurang menyukai React, misalkan kita lebih suka framework yang lain gitu.
Kenapa dipaksa untuk mengarah ke sana.
Atau juga kalau kita ngomongin membuat produk atau membangun sebuah aplikasi, itu kadang-kadang klien-nya nggak peduli kan.
Kita mau menulis pakai React kah, mau pakai JQuery kah, atau mau pakai vanilla Javascript gitu.
Yang penting hasil lahirnya.
Ada yang pakai Backbone nggak untuk Backbone?
Tapi Laravel sampai sekarang, gue masih pakai Laravel karena inherit codebase sama ya.
Jadi mungkin kalau kita sebagai developer lihat di sosmed atau apalah, kayaknya emang banyak banget framework baru ya.
Tapi di kenyataannya kalau di dunia kerja kan nggak semua organisasi atau perusahaan bisa serta-merta tiba-tiba tiap tahun ganti framework gitu.
Sesuai apa yang lagi nge-trend kan sebenarnya nggak gitu juga ya.
Jadi apa, kayak Rails juga yang pakai juga mungkin masih banyak ya pokoknya framework-framework yang lama.
Cuma mungkin yang penting banget, fundamental web-nya aja sih, kayak misalnya tentang performance kemarin tuh.
Bisa mengimplement, entah itu kita pakai React atau Swelt atau apapun kan sebenarnya kayak prinsip prefetch
atau segala macam yang kita bahas kemarin tuh kan prinsip dasarnya tetap sama ya.
Jadi kalau menguasain itu sih mau pindah-pindah, mau React, Swelt, Angular, dan lain-lain, nggak seberat itu.
Kalau misalnya emang suatu saat kita pengen cari kerjaan yang mengharuskan pakai stack tertentu
dan buat kita itu dream job, ya udah kita bisa dengan gampang mengejar itu.
Kuatkan fondasi fundamental JavaScript-nya. Atau web-nya, lebih tepatnya web. Web development-nya.
Jangan cuma JavaScript. Web itu banyak.
Ya, karena framework itu bisa berganti-ganti, yang bertahan itu ya fundamentalnya.
Ketika amit-amit nanti misalkan React, wah udah nggak ngetrend lagi, ya ngetrend yang lain gitu kan.
Kalau kita belajar spesifik ke React, begitu React-nya sudah jarang dipakai, kita harus belajar lagi dari awal.
Sementara kalau udah fundamental itu udah setengah jalannya.
Kita udah ngerti lah dalemannya framework itu seperti apa.
Dan ngomongin teknologi web, jadi bukan hanya JavaScript, dan malam ini kita akan membicarakan tentang CSS.
Banyakan CSS itu apa sih? Cascading?
Cascading style sheet.
Dan berhubung materi atau topik saya yang paling nyubi, jadi saya izin duluan ya.
Baiklah.
Ya, jadi beberapa minggu yang lalu sempat bersiluran di timeline, itu web dev itu mengeluarin sebuah media baru.
Seri ya, semacam serial, seri tutorial.
Betul, jadi dia bentuk dalam bentuk course, di sini ada banyak sekali di web.dev/learn.
Ada mulai dari accessibility, ada learn HTML, ada responsive design, ada form,
sampai ada PWA, dan ada CSS.
Jadi kalau temen-temen yang ilmu CSS-nya masih cupu seperti saya dan Ivan, kita bisa belajar bareng-bareng di sini.
Ya, fakta. Saya masih nyubi banget di CSS.
Baru belajar CSS.
Ya, sama. Dan kebetulan juga beberapa waktu yang lalu saya sempat diminta untuk isi salah satu workshop online.
Dan materinya basic, HTML dan CSS.
Dan berhubung waktunya itu terbatas dan khawatir nggak sampai selesai, akhirnya saya bikin dalam bentuk tulisan.
Jadi temen-temen kalau mau yang cari yang bahasa Indonesia, bisa ke...
HTMLcss.rizafahmi.com
Asyik. Ini pakai Google Translate? Enggak, ini bahasa Indonesia.
Google Translate tulis sendiri tuh, kan?
Ini tulis sendiri, dan tulisan ini, website-nya itu dibikin dengan kit docs-nya yang ditulis di atas spell kit.
Jadi ini adalah seperti dokumentasi, kita belajar HTML, basic banget gitu,
sampai akhirnya bisa bikin aplikasi sederhana seperti ini, kumpulan link-link gitu aja.
CSS-nya juga nggak terlalu banyak dibahas, terlalu mendalam, tapi ya lumayan lah, ada box model, hampir sama ya.
Gak spesifik terhadap framework tertentukan, ya?
Gak lah, dasarnya dulu.
Dasarnya dulu, betul.
Dasar banget. Ini memang ditujukan untuk yang belum pernah programming, jadi memang benar-benar dari dasar.
Oke, untuk materinya sudah sampai di sini.
Selanjutnya kita lanjut ke pembahasan tentang CSS inline dari Ivan. Silahkan.
Ya, sini semangat, sorry.
Ini masih berkaitan dengan performa, karena saya ahlinya di performa.
Saya nggak punya materi yang ini, jadi saya mau buka soal topic discussion aja, diskusi-diskusi topic.
Yang sering kita alami ya sebagai web developer itu CSS, saya langsung gambar aja pakai framework tertentu misalnya.
Tetapi penggunaannya salah misalnya, jadi contohnya pakai Bootstrap 5 misalnya.
Pake apa? Bootstrap.
Itu kan maksudnya kalau dipakai dengan cara yang salah ya, dipakai dengan cara yang salah itu ukurannya kan bisa gede banget ya.
Bisa sampai, I don't know.
Oh, 3 mega. Gak diminify ya?
100 sentikilo byte contohnya ya. Saya nggak tahu tepatnya, cuma begini.
Ada salah satu artikel, itu Optimize untuk LCP.
Itu disarankan Largest Content Full Pay untuk loading dari sebuah situs.
Saya coba cari linknya dulu ya, Optimize LCP.
Saya share screen aja tadi ya, biar enak.
Boleh, boleh.
Share screen.
Linknya saya kasih.
Optimize LCP.
Bentar saya kasih linknya dimana ya?
Gak di sini, private chat.
Jadi sedikit saja mengenai, karena saya mau nyangkutin ke bagian stylesetnya.
Kan kalau LCP kita bahas minggu lalu itu kan Largest Content Full Pay bagaimana kita bisa menampilkan bagian content full art.
Bagian yang terbesar dari above the fold.
Jadi kalau misalnya di sebuah situs, kita ingin dari header kemudian feature image itu secepat mungkin bisa muncul ya.
Kita udah bahas juga minggu-minggu lalu bagaimana strategi-strateginya untuk supaya bisa eliminate render blocking request and so on.
Silahkan nanti, kalau nggak salah itu di episode 0 kita bahas itu.
Nah, selanjutnya saya mau bahas sedikit mengenai inline CSS versus non-inline CSS.
Seperti yang kita tahu, CSS itu render blocking ASCEN.
Kalau kita link pakai style tag ya?
Ya, betul. Jadi kalau link style gitu, jadi saat web atau halaman kita di request kemudian di render,
browser akan menunggu CSS-nya didownload dulu, diparse baru bisa melanjutkan proses rendering.
Jadi itulah maksudnya render blocking ASCEN seperti yang kita lihat di sini.
Jadi, si browser itu menunggu style sit-nya kita, CSS-nya kita didownload supaya bisa dilanjutkan proses rendering.
Betul. Jadi HTML secara keseluruhan memang dia baris-perbaris ya.
Jadi dari sini ke header, dari header, ada muncul dia loading, berarti di sini loading font-nya.
Font lagi, kemudian loading image, kemudian dan lain-lain, baru dia masuk ke bagian body terus ke bawah.
Pokoknya salah satu yang disarankan adalah JavaScript kalau bisa ditaruh di bawah sebelum body tutup.
Di deeper execution.
Kalau kita pahami grafik ini pelan-pelan, saat HTML didownload, diparse, kemudian CSS-nya didownload.
Yang ungu itu CSS dan yang hijau itu image, biasanya feature image yang biasanya menjadi LCP.
Di layar siapa?
Oh, bukan layar saya ya? Sorry.
Sudah, sudah.
Ini dokumennya, ini CSS-nya, terus ini image-nya, dan image ini kan biasanya menjadi LCP ya.
Biasanya ya.
Tetapi proses LCP-nya ini ke block sampai menunggu si CSS file yang besar ini selesai didownload.
Ada, ada opsi, itu pertama yang kritikal CSS itu di inline.
Inline berarti dimasukin ke style?
Iya, betul, dimasukin ke style, jadi style tag di HTML.
Jadi rulesetnya apa, deklarasinya, stylingnya di dalam style-nya ya, maksudnya inline.
Jadi bukan styling, kalau styling itu kan dia ngambil dari file dari server external atau CDN didownload.
Kalau inline artinya di dalam head tag, jadi style itu di dalam head tag-nya HTML.
Jadi ini bukan display inline ya, maksudnya kebetulan aja namanya sama.
Iya, bukan.
Ada satu lagi kan?
Ada yang di dalam HTML style inline.
Oh, di dalam tag-nya.
H1 style sama dengan itu, bukan itu.
H1 style sama dengan itu, bukan juga.
Bukan itu.
Yang di head ya, oke, siap-siap.
Betul, jadi yang terjadi, pertanyaan yang saya mau bawa.
Kalau misalnya kita inline CSS-nya, tentu HTML kita ukurannya makin besar kan?
Dan nggak bisa di-cache ya?
Jadi nggak bisa di-cache, betul.
Jadi gimana caranya strategi kita untuk develop?
Sebenarnya yang above the fold, above the fold itu contohnya begini ya.
Kalau misalnya saya pakai begini, berarti yang above the fold itu kan antara icon ini, style yang ada di sini sama yang ini nggak penting ya.
Style yang ada di sini itu sebisa mungkin di inline.
Harus secepat mungkin ya munculnya.
Ada masalah yang terjadi kalau dengan inline dan non-inline.
Jadi kalau lihat kita inline, dia nggak bisa di-cache oleh browser.
Kalau misalnya kita lihat di network kan, itu biasanya ada CSS yang di-download tuh.
Kalau kita disable cache.
Nah, ini kan ada CSS-nya ya?
Nah, kalau CSS ini kan biasanya sudah di-size this case gitu ya.
Sudah di-case, jadinya nggak perlu di-request ulang.
Tetapi kalau di-inline, dia nggak bisa di-case karena dia termasuk di halaman, di markup HTML.
Ini maksudnya link ya.
Nah, apa sih strategi kalian untuk menetapkan, mana sih yang perlu di-inline, mana sih yang nggak perlu di-inline?
Karena kita perlu hati-hati di situ, kita tetap perlu menetapkan Leverage Browser Case karena itu penting.
Karena untuk hidup kita, nggak untuk mengoptimasi Core Web Vitals untuk search engine.
Salah, hidup kita, optimasi Core Web Vitals untuk user kita.
User experience ya.
Betul, bukan search engine experience.
Jadi, kalau memang mau bagus, biasanya untuk Service Core Web Vitals bagus, inline-kan aja semua seabrek-abrek, masukin aja ke HTML.
Pasti itu render blocking recourse-nya hilang.
Tetapi user kita nggak senang karena yang di-download-nya, file yang sama di-download itu-itu saja.
Jadi ya boros-boros kuota.
Nah, ada nggak sih cara supaya menentukan itu kalian sehari-hari?
Sehari-hari?
Gue dulu deh. Apa ya, pokoknya kayaknya segala cara dari yang aneh sampai aneh banget sampai nggak terlalu aneh.
Gue udah pernah pake semua deh, termasuk yang beneran di-inline semua di dalam style tech itu pun pernah.
Cuma kan sebetulnya kerjaan developer itu trade-off banyak hal ya.
Kayak tadi tuh, udah ada satu trade-off yang dibahas, trade-off antara bikin apa itu?
Bikin search engine, bikin lighthouse senang, sama bikin user beneran senang.
Dan kadang, ya itu punya satu propusi yang sama, sebetulnya halaman yang cepat, enak digunakan, blablabla.
Tapi kadang berada prakteknya, itu kan sebetulnya mencabang kayak branching kedua hal yang berbeda ya.
Kayak tadi, jadi kalau kita pengen utamain bikin lighthouse senang atau search engine senang, kita bakal di-inline semua.
Sedangkan kalau kita pengen bikin user senang, ya mesti kita nggak akan menggunakan cara itu.
Nah, selain itu kita juga kan sebetulnya di tim kita, kita ada mungkin product owner atau tim growth atau tim-tim lain
yang punya matrix yang ingin dicapa ya, termasuk salah satunya nyambung ke search engine score tadi.
Nah, terus di sisi lain, kan itu bergantung banget sama konten aplikasi kita ya.
Maksudnya inline style kita misalnya semua ditaruh, style CSS kita semua di-inline ke head, kalau misalnya sebetulnya nggak terlalu banyak,
nggak sampai bermega-mega gitu, dan mungkin kebetulan misalnya user kita pakai device yang nggak kuno-kuno amat
atau mungkin kemampuan download data-nya nggak terlalu rendah, itu nggak cukup mengganggu.
Maksudnya gangguan yang dirasakan user pun nggak cukup signifikan.
Bisa aja kadang ada kasus gitu di mana gue pernah inline style semua secara apa, payload yang di-download, payload ke user pun nggak sampai ekstrim.
Dan ya itu akhirnya pelan-pelan sambil dibetulin sih, jadi emang itu sebetulnya solusi sementara.
Jadi itu kalau udah di lapangan sih agak susah ya kalau untuk di prescribe harus begini atau begitu, jadi kita juggling aja sebetulnya sih.
Kayak art ya, kita nggak bisa semuanya satu titik gitu ya.
Kita tetap harus kayak, oke kita perlu critical, berarti waktu di CSS-nya, di SAS-nya, kita perlu pisahin gitu.
Oh, above default nih untuk mobile, masukin di, I don't know, mungkin kalau pakai Vue atau apa yang untuk transpile,
itu kan bisa pakai apa namanya, ini transpile bisa di grouping ya, ini critical CSS, non-critical.
Terus gini, kadang sih masih nyambung sama itu, kalau gue kadang sebenarnya nge-check dulu aja LCP-nya apa.
Ya udah, kan kita tahu, sebenarnya kan rata-rata ya, tergantung desainnya juga, kita punya shell ya, kita punya apa sih, header,
kita bisa tahu itu tingginya berapa, terus biasanya kita punya shell apa itu yang apa, container, kita tahu lebernya berapa, kita tahu tingginya header berapa,
terus kita afalin aja, maksudnya kita check aja dulu LCP-nya, text-nya apa, udah itu aja yang di-inline, sisanya ya di-diver.
Terus saya juga pernah, pernah juga dulu sampai, sampai extreme, di CSS-nya itu per block, sorry, per component.
Per component.
Jadi, iya per component, jadi kalau misalnya, oke kalau yang komponen-komponen umum, saya memang sudah block, sudah jadiin satu CSS file,
tetapi kalau misalnya kayak komponen-komponen tertentu, ini saya ambil kasusnya WordPress ya,
WordPress itu kan bisa dibangun pakai block-block, kan ada biasanya komponen-komponen itu contohnya apa ya,
komen, komen kan paling bawah ya, kan nggak perlu di-load, CSS-nya nggak perlu di-load di atas contohnya.
Terus, jadi saya biasanya grouping lagi per component, per component yang bawah-bawah yang nggak perlu gitu ya,
komen lah, author profile, contohnya, atau footer, footer, footer, yang paling bawah tuh, footer, bagian footer biasanya kan,
gede-gere juga ya, tentu nggak perlu di-load di awal, saya sampai pisah-pisahin tuh kecil-kecil,
tapi justru pisahin kecil-kecil malah jadi lambat.
Iya, karena semua harus ke-download, ke-download.
Ya betul, kalau dia, meskipun katanya sudah HTTP/2 yang ngedownload bisa parallel, tetap aja ada race condition delay.
Dan kalau misalnya satu file-nya ke delay, akhirnya yang terjadi adalah render blocking request.
Jadi jangan juga sampai ke extreme yang pisahin per component, nggak perlu juga.
Jadi kalau saya saat ini masih menganut above the fold, pisahin di grouping ke satu folder kah, atau satu endpoint, di inline.
Itu saya batasi ya, batasi biasanya up to sampai 5 kilobyte sampai, ya 5 kilobyte aja, itu CSS file.
Jadi kalau dia sampai 5 kilobyte hasil transparent-nya inline-kan aja,
karena ya 5 kilobyte ya nggak terlalu haru-haru ya, untuk HTML-nya terlalu besar ya, 10 kilobyte pun masih fine lah gitu ya.
Tetapi kalau sudah sampai kayak 40, jangan deh, mending coba prisahin lagi, masa 40 kilobyte above the fold.
Kita bicara mobile first ya, mobile first.
Jadi kalau desktop mah, nggak perlu mikir ginian kalau desktop, karena udah pasti kuat.
Jadi sisanya CSS-nya di preload supaya lebih cepat, itu tetap perlu jadi fine.
Pake library nggak sih? Sebenarnya udah ada banyak kan, ada beberapa library yang bisa otomatis nge-grab above the fold CSS.
Kalau masalah kayak Next.js itu sudah otomatis ya, Next.js ada.
Saya baru tahu Next.js, kayaknya library lain kayak Gatsby, maybe, I don't know.
Nggak, bahkan yang Pure Vanilla JavaScript, misalnya kita masih pakai server-side framework ya, kayak Laravel, Rails, atau apapun,
itu ada untuk sisi JavaScript-nya ada yang konon bisa nge-grab above the fold.
Cuma belum sempat nyobain, belum pernah nyobain, jujur.
Ada itu di artikel web dev?
Iya, Eka baru publish ini, baru kasih. Jadi artikel-nya cukup lama juga ya, nice.
Extract critical CSS.
Itu kan masalah yang dari dulu ada, cuman dulu, justru mungkin karena waktu artikel ini diposting tahun...
Oh ya, udah sih, orang udah banyak yang pakai Next.js pun udah banyak.
Cuma mungkin kan nggak semua orang bisa pakai framework itu kan.
Jadi kalau ini ada beberapa solusi yang masih JavaScript atau webpack lah, apapun yang berbasis webpack.
Cuma emang kalau framework modern, kelihatannya udah lebih segala ada ya, kayak Next.js.
Ya, kayaknya emang dia handle itu. Dan remix, waktu itu gue inget remix.
Terusnya itu cukup menarik, kita di setiap halaman atau di setiap layout, nested routes apapun itu,
ada tag khusus untuk nambahin CSS dan nggak tau lah, pokoknya library-nya remix itu secara otomatis nge-handle.
Jadi waktu kita buka satu halaman yang di-load adalah hanya CSS yang hanya style yang ada di halaman itu.
Nah, kalau misalnya kita pindah ke halaman lain, dan itu kan mereka udah intercept pakai client-side router mereka punya remix.
Nah, dia bisa meng-calculate sendiri style apa yang ada di halaman kedua itu, halaman baru itu, di-inject ke CSS-nya.
Jadi emang dia udah smartly nge-handle berdasarkan isi halaman, dan kelihatannya ya handle above default juga.
- Oke, wah ini seru ya. - Sedikit melenceng, CSS in JS masih in nggak sih?
- Masih, masih, masih. - Masih ya?
- Masih. - Walaupun lebih banyak yang loncat ke Tailwind ya sekarang, cuma kan ya gitu.
- Seru nih. Nah, maksudnya... - Tailwind versus...
Versus lainnya, versus the world.
Ya, jadi kayaknya kalau di-establish companies atau organizations kan ya itu nggak mungkin semua yang teranjur pakai style components atau emotion
tiba-tiba udah rewrite semua ke Tailwind, ya kan? Nggak mungkin kayak gitu.
Jadi sebetulnya di lapangan pasti masih banyak banget yang pakai emotion dan temen-temennya.
Dan meskipun nanti ke depannya banyak framework seperti Next.js atau remix dan lain-lain sudah meng-handle ini di belakang layar,
kita tetap harus tahu, karena suatu saat ya kita bisa ketemu masalah di sini dan kalau kita nggak tahu ini, ya.
- Bisa berabih juga. - Bingung.
- Loh, kok ini bisa di above default, bisa tiba-tiba muncul di atas gitu. Dari mana ini, ya kan?
- Dan framework, apa sih, automation bawaan dari framework kan nggak selamanya akurat ya, namanya mesin mah bisa-bisa aja salah.
- Iya, dia kan hanya mengantisipasi atau menebak, gitu kan. Kira-kira ini...
Tidak kan antara implementator, kalau saya menyebut yang hanya tahu pakai tertentu, itu implementator.
Dan web engineer yang oke, memang tahu, oh, cara terjadinya begitu, saya pakai framework ini, cocok nih, bisa, gitu.
Dan bisa mengimplementasikannya. Jadi kalau ada masalah, tahu tuh, oh, bisa di-debug ke mana harus di-debug.
Biasanya yang menentukan career-nya yang menelijik adalah yang tahu fundamental.
- Asik tips career ini. Yang tanya career tadi siapa tuh? Yang tanya Riknyas tuh tadi. Ini ada tips.
- Yaitu yang tahu cara kerjanya, ya. - Ada nggak yang tahu cara kerja bagaimana web vital itu dihitung?
- Di Lighthouse kan, open source kan. - Iya, tapi ada yang buka nggak?
- Enggak, ingat tuh dulu pernah ngebuka cuma pengen tahu device yang dipakai apa, bener nggak sih.
- Motorola G4 kan ya? - Oh iya, Motorola. Eh, Motorola G4.
Jadi dulu kayaknya ada masalah gara-gara belum update browser atau apalah, Lighthouse-nya jadi updated.
Ternyata hasilnya lain gitu. Terus akhirnya ngecek karena penasaran, ngecek ke source code-nya Lighthouse.
Cuma buat cari tahu device apa yang dipakai buat simulate.
- Yes. Oke, ada lagi dari Ivan? - Itu dulu, nanti kita lanjut ke yang performance observer setelah si Eka aja.
- Oke, berarti sekarang gilirannya Eka tentang container queries.
- Tentang container queries, masih CSS. - Itu baru tuh.
- Nah, ini nih. Waktu kita ketemu di Bali ya, waktu itu kita kayaknya bahas ini deh bentar. Apa?
- Yay, akhirnya launching. - Terus gue bingung, apa itu container queries?
- Nah jawaban dari apa itu, ya scroll aja sedikit ke bawah, kita lihat gambarnya aja.
Jadi buat temen-temen yang penasaran itu apa, baca sendiri aja ya artikelnya, kalau pengen detailnya.
Cuma kalau sekilas adalah intinya kan CSS kita selama ini punya media query ya.
Add media, terus diapit tanda kurung, parentesis, terus kita tulis deh kondisionalnya sesuai kebutuhan kita.
Misalnya add media dalam kurung main width 1024px, berarti apapun yang di dalam curly brackets itu,
tanda kurung-kurawal itu akan di aplikasikan, stylesheetnya akan di aplikasikan kalau kondisi itu terpenuhi.
Nah oke itu udah membantu banget, tapi masalahnya media queries itu kan cuma buat ukuran viewport.
Viewport itu besar ukuran layar yang muncul di device user.
Nah media queries itu kekurangannya apa, karena kalau misalnya kita bikin komponen UI,
itu kan bisa diletakkan, kita layoutnya tuh bisa macem-macem.
Misalnya product card nih, tampilan product bisa ditampilin di sidebar tuh, kayak digambar di contoh yang sebelah kiri warna ungu.
Itu kan ditampilin di sidebar, jadi walaupun viewportnya ukuran besar itu dibuka dari desktop,
tapi komponen itu sendiri ditampilkan di container atau di layout yang ukurannya kecil.
Nah selama ini CSS itu belum mampu menghandle, dan ini sebetulnya salah satu feature CSS yang paling banyak di request.
Jadi pas lagi baca-bacain ini, nemu talk CSS Conf dari tahun 2018.
Nah ini talknya, kocaknya, oleh mas Philip Walton yang tadi kayaknya sekilas ada di artikelnya Ivan juga deh.
Jadi beliau emang udah aktif per CSS-an dari kapan tau.
Jadi CSS Conf di 2018 itu beliau ngomong tentang container queries dan kocaknya lagi.
Itu ngebahas sejarahnya, latar belakangnya apa itu container queries CSS.
Ini tahun 2018 ya, dan dia bilang bahwa, wah ini feature yang dari dulu di request dan goes back to sekitar 2013.
Orang udah pada nge-request, udah pada menyuarakan tentang kebutuhan akan container queries, kenapa media queries tidak cukup, blablabla.
Itu 2013 doang bayangin, dan akhirnya sekarang 2022, 9 tahun kemudian, stable, ya lumayan lah.
Jadi itu historinya, dan saat itu sih di tahun 2018, conclusion-nya adalah belum bisa dicapai.
Tapi dia ngasih beberapa tips atau beberapa cara work around untuk mendapatkan hasil yang sama.
Cuma untungnya sekarang di tahun 2022 kita udah bisa dapet feature itu.
Jadi itu contoh penggunaannya bisa dilihat.
Kalau nggak salah pakai itu ya, resize observer sama mutation observer.
Iya betul sekali.
Jadi bisa diakali dengan JavaScript, ya cek aja kalau element itu direcise, berarti ngetrigger styling yang...
Ya bisa add class, add class, remove class mungkin.
Ya standard lah, akal-akal anwantir standard.
Nah, cuma karena sekarang sudah di-launch, sudah jadi bagian dari web API yang diimplementasikan oleh browser.
Browser support juga cukup bagus, jadi intinya hampir semua major browser kecuali Firefox.
Ini tuh semua nggak bisa kompak giliran Firefox implement, Safari nggak, Chrome Edge, Firefox kadang Safari nggak.
Nah sekarang nih Chrome Edge, Safari, Firefox nggak.
Tapi jangan sedih buat yang pengen pakai nih, udah ada Polyfill, Polyfill-nya bagus.
Polyfill-nya ya yang tadi dibahas itu.
Jadi Polyfill-nya adalah workaround yang di-propos oleh mas Philip Walton di tahun 2018 itu.
Yang tadi sekilas dibahas oleh Ivan.
Nah itu udah dibuat dalam bentuk package yang bisa di-install.
Jadi itu, mungkin pindah tab ke yang tadi lagi?
Boleh, ke mana kata?
Nah, scroll ke bawah.
Oh ini Polyfill-nya.
Nah itu dia, jadi kalau misalnya pengen pakai Polyfill itu, bisa langsung install.
Udah ada library yang tinggal plug and play aja dan support-nya cukup lumayan sih.
Firefox, Chrome, Edge, Safari.
Bisa langsung, bisa langsung ke CSS-nya nggak? Atau perlu...
Ya nggak, itu kan library JavaScript, ya di-install aja itu.
Oh, Edge Supports ya?
Oke.
Nah terus ini topik juga, ini masih terkait nih.
Sekarang giliran gue yang tanya, kalian atau temen-temen yang lagi ngedengerin juga bisa nge-reply di chat.
Apa yang kalian lakukan kalau nemu kayak gini nih, hal-hal feature-feature baru yang oke banget?
Ini kan relevan ya, maksudnya ini hal yang cukup, ini hal yang relevan banget.
Kalau kita bikin component UI, ini berguna. Ini oke lah, kita udah senang pengen pakai.
Tapi tadaa, belum bisa, browser support-nya belum merata.
Nah kalian gimana, nggak usah pakai sama sekali, udah ntar-ntar aja tunggu dulu.
Atau pakai Polyfill, Polyfill dengan konsekuensi ya sedikit, walaupun sekecil apapun kan,
menambah package yang harus di-install ya, menambah JavaScript runtime juga.
Atau mungkin hand roll, bikin pakai kan CSS, ada add support square itu.
Jadi kita manually bikin styling untuk CSS yang belum support, atau bagaimana? Coba.
Tergantung target audience-nya. Kalau target audience-nya cukup modern ya.
Browser-nya update terus, rasanya perlu. Dan tergantung juga dengan aplikasi yang mau dibuat.
Kalau misalkan nggak butuh-butuh banget, bukan critical, bukan sesuatu yang terlalu critical,
ya nggak usah dipakai. Tapi kalau misalkan, wah ini dinamis banget nih, kayak misalkan apa ya?
Pinterest misalkannya, card-nya ditambahin terus dia berubah posisi dan lain-lain gitu, ketika butuh itu ya
mungkin Polyfill bisa menjadi jalan tengah untuk sementara, sampai akhirnya di-support secara full.
Kalau saya, pengalamannya gini, lihat dulu nih, API yang saya senang itu sudah menjadi standard belum.
Jangan-jangan kalau masih draft atau trial, yang masih belum tahu nasibnya gimana, jangan dulu.
Contohnya yang kemarin minggu lalu, transition API, saya nggak mau implementasi, belum rani.
Iya itu ada warning-nya juga kan emang, di halamannya. Hati-hati kalau pakai ini pasti akan berubah.
Kalau ini, kalau ini? Kalau ini, saya baru saja woro-woro, saya hijau ke tim, yuk kita mulai implementasi CSS content.
Meskipun Firefox belum ada?
Saya mau relate ke itu, Polyfill. Kebetulan, kebetulan, project yang sedang saya pegang berdasarkan data analytics-nya,
Firefox itu menduduki top 8 yang cuma sekitar 3% traffic.
Jadi terbesarnya itu Chrome, Safari, dan Edge terbesarnya.
Jadi kayak top 5, top 6-nya itu Chrome, Safari, Edge. Bahkan Chrome Mobile, Safari Mobile, Chrome Desktop, Safari Mobile,
baru kemudian Edge, Edge Mobile, dan Edge Desktop. Baru kemudian Opera, baru Firefox.
Itu dari data hasil analytics ya. Jadi dengan demikian, sayang juga nggak mau pilih-pilih kalau kecil banget 3%, nggak boleh juga.
Harus di-serve semua kan? Harus di-serve semua. Jadi saya bisa mungkin, kalau ada Polyfill-nya, saya lanjut.
Contohnya yang ini, saya green light, implementasi. Nanti ujung-ujungnya pakai Polyfill. Harus.
Tetap harus ada notes nanti dibuat. Kalau nanti Firefox sudah support.
Jangan lupa remove Polyfill-nya. Kode yang ini di-remove.
Nah, itu cara kita catch up dengan, itu gimana? Nungguin Firefox-nya hijau. Gimana trick-nya?
Sekarang trick-nya saya kayak cuma ada mental aja ya. Remember aja, nanti gimana? Nunggu aja kayak 2 bulan.
Gak ada ditaro di sticky note gitu ya.
Di apa? Di JIRA.
Gimana sih?
Iya sih, so far implementasi aja dulu. Karena kalau Polyfill, meskipun dia sudah ada,
kalau Polyfill-nya pintar, kalau dia sudah ada, dia nggak bisa menjalani lagi kan?
Dia nge-check. Ya, cuma kan kalau mau itu banget, kalau mau irit banget performance budget-nya,
kan ya gimana pun dia runtime dikit.
Tetap loading.
Tetap loading buat nge-check support.
Nah, ini ada pendapat menarik nih dari Devi.
"You're missing the whole point of progressive enhancement. If you think you need to wait for wide browser support."
Nah, ini oke ya. Maksudnya mungkin karena web itu kan platform yang apa ya, dinamis banget dan diverse.
Kayak beda-beda banget kan? Nggak mungkin kita nunggu semua browser setuju buat mengadopsi suatu feature.
Semua user pakai browser yang sudah support, yaudah, kayaknya kita nggak bakal ada apa-apa-apa udah.
Bahkan saya kalau untuk decide untuk pakai atau tidak, yang penting API-nya secara web standard sudah approve bersama,
secara konsersium sudah approve. Tapi kalau yang masih baru diajukan, masih trial, no, nanti dulu deh, jangan dulu.
Kalau mau coba-coba, silahkan. Itu wajib untuk dicobakan di feedback.
Apalagi kita pada GDI yang diminta untuk mencoba-coba hal tersebut.
Dan membagikannya kepada teman-teman yang lain biar juga tahu.
Dan mungkin kadang kita mesti agak, apa ya, kan mungkin kalau desainer visual ya yang terbiasa dengan,
kita sebagai developer kan mindset-nya agak beda dengan desainer visual yang mungkin latar belakangnya dari cetak atau apalah yang harus pixel perfect banget.
Nah, mungkin mindset-nya kita harus bisa ngomunikasiin mindset juga ya.
Jadi misalnya kasus tadi tuh 97% sudah bisa, sudah bisa dapat full experience, full ideal experience.
Ya, anggap lah misalnya belum ada polyfill-nya. Mungkin kita bisa mengakalin pakai supersquare buat modifikasi sederhana.
Jadi tujuannya mungkin 1% atau 2% user kita nggak bisa dapat desain yang ideal, pixel perfect seperti yang diinginkan.
Tapi kita mestiin info yang mereka butuhkan bisa dibaca, bisa diakses.
Ya, kadang ada kalanya kita mesti ngakalin kayak gitu. Nah, sebagai developer mungkin kita harus bisa mengkomunikasikan itu dengan baik ke misalnya desainer di tim kita kali ya.
Karena kalau desain, cetak, ya kan kalau cetak pasti semua hasilnya gitu.
Kita tinggal pesan kertas, jenis kertas apa bisa dipastikan semua sama.
Tapi kalau web, device yang dipakai seluruh user kita buat mengakses kan nggak bisa di-streamline se-gampang itu kan.
Saya punya pengalaman harus support IE11.
Waduh.
IE11 dikarenakan jadi di sebuah bank, international bank saat itu. Kan biasanya kalau user-nya mereka, bukan sorry, user-nya pengguna sistem artinya pegawai bank ya.
Jadi bagian konten segala macam itu. Kan mereka menggunakan laptop yang dikasih dari kantor.
Ya, dan kalau sudah bank kan security-nya ketat ya. Nggak bisa install apa-apa. Itu dikontrol semua dari pusat.
Dan browser-nya masih IE11. Gak bisa install Chrome, nggak diperbolehkan.
Tetapi target user yang public itu top 3 browser semua.
Moderen semua. Jadi kita harus support IE11 supaya user yang pakai di internal bisa menggunakan sistem yang kita pakai.
Karena UAT-nya mereka. Mereka nggak bisa UAT pakai top 3 browser.
Gimana coba?
Dua versi. Kisah. Yang kalian pakai file CSS yang di-load berdasarkan user engine.
Itulah suka-dukanya jaman itu.
Wah jadi ingat jaman dulu tuh ada web pencari kerja, portal pencari kerja, yang hanya support IE sekian.
Oh iya, saya tahu itu.
Malah kebalik ya. Bukan IE yang tidak disupport, tapi harus IE. Nggak boleh yang lain.
Karena dia teknologi pakai .NET salah satunya.
Beberapa tahun lalu di sebuah urusan untuk SIM card gitu lho.
Saya lihat mereka untuk, itu lho kayak salah satu provider telekomunikasi.
Jadi bagian customer service-nya untuk melakukan back office sistemnya dia itu harus pakai IE karena masih menggunakan ActiveX.
Beberapa tahun lalu sih. Intinya back to ini, bagaimana bisa tetap memberikan support terbaik terhadap internal bank,
tetapi juga harus ikut modern ininya. Jadi di tooling-nya sistem kita juga harus kayak kan bisa pakai browser revise segala macam itu untuk,
eh sorry, apa namanya? Ada untuk...
Browser list ya?
Ya browser list, betul.
Dan waktu di compile, transpile kita harus tetap memasukkan IE 11 itu sebagai salah satu yang kita cek.
Linternya kita juga kita cek. Jadi tetap harus ada. Bahkan di stylesheet-nya kita itu satu folder khusus IE 11, support IE 11 support.
Tetap harus di support.
Kita lah, suka-dukanya web development.
Kita tetap ingin maju cepat, tetapi kita harus lihat ke belakang.
Tetap mau adopsi latest technology, tetapi nggak boleh meninggalkan yang...
Old technology, not so latest technology.
Tetapi tetap harus ada ini ya, harus ada baseline yang ditetapkan, perjanjian bersama.
Tetapi sekarang project-project baru, project baru kita langsung bilang, nope, IE 11 is no more.
Karena sudah mati, sudah nggak di support juga kan, sama Microsoft, pindah.
Jadi biasanya kan Windows 10 sama Windows 11, kalau sudah service pack kesekian, itu sudah IE 11-nya udah nggak ada kan, udah ganti edge kan.
Jadi sudah biasanya dipengaruhi itu.
Kalau laptop-laptop baru dari meskipun dia corporate, kalau dapatnya Windows 11, udah pasti edge kan dapatnya.
Jadi sekarang kita kasih baseline, yang di support adalah browser dan 3 versi terakhir.
3 versi terakhir, perjanjiannya kalau iOS, sorry, Safari 16 misalnya.
Berarti sampai 14 kita harus support, wajib.
Terus itu pentingnya kita collect analytics juga kali ya.
Contohnya analytics kan emang kalau nggak di handle dengan baik, bisa disalahgunain dan mungkin kita atau publik yang awam tuh lebih sering dengar tentang hal-hal negatif lah.
Hal-hal negatif dari analytics kan, jadi sering dianggap sebagai sesuatu yang buruk atau cuma bikin lambat aja.
Tapi di sini kita bisa lihat pentingnya analytics, kita tahu device apa aja yang dipakai oleh user kita.
Dan kita bisa optimize experience-nya dan itu bisa jadi bahan buat kita nentuin mau menggunakan suatu API atau nggak.
Jadi kepikiran kalau di analytics kita misalnya nih, misalnya, gue langsung kepikiran tidak nih.
Contohnya kita kan bisa ngedetek pakai JavaScript apakah suatu API tertentu ada atau tidak gitu ya.
-Navigator-nya aja semua. -Contohnya ada sebuah, kita mau lakukan field analysis.
Field analysis itu artinya kita mau ngetes di user kita itu datanya cukup mendukung atau tidak.
Contohnya kita mau apa sih API yang baru? Fugu, contoh file system misalnya, file system API.
Kita kan bisa ngedetek pakai JavaScript kalau si browser itu support file system API atau tidak.
Jadi kita juga bisa, sebelum menentukan kita harus pakai atau tidak, kita harus buka analytics.
Analytics ada data-nya ada atau tidak? Kan kita tidak bisa melihat langsung.
Kita kan cuma bisa lihat top 10 browser bisa kita lihat, tapi apakah browser itu support atau tidak kita belum tahu.
Jadi bisa kita juga lakukan send data pakai analytics atau GTM contohnya.
Kita ngedetek aja itu si API tersebut ada atau tidak. Kita send datanya ke GTM, kita collect data misalnya 2 minggu atau sebulan
dari data yang kita punya kita dapat user kita, berapa persen sih yang sudah support file system API?
Baru kita bisa implementasi. Jadi sebelum warung-warung kita pakai, justru kita pakai tidak, cek dulu.
Pakai aja analytics, kirim ada dari JavaScript, collecting data sebulan mungkin.
Mungkin data cukup sebulan atau 2 minggu terserah, dari situ berapa persen yang support API baru
yang kita ingin implementasi itu sudah ada atau belum.
Kayak can I use tapi khusus untuk user kita aja gitu ya?
User kita, betul.
Yang gue pernah malah itu sih semacam soft launching feature, itu kan bisa dipakai misalnya feature itu ada geolocation-nya.
Nah kan pertama sebelum munculin, ya sebelum ngerunning, cek dulu kan if geolocation in navigator.
Itu untuk ngecek kalau di support atau nggak, kalau di support ya munculin feature itu.
Kalau nggak, apa di else-nya kan kita bisa kirim event juga.
Ya udah, itu salah satu bentuk soft launching.
Kalau yang support dikit ya udah, berarti kan nggak terlalu worth it. Belum.
Jadi menarik tuh untuk dibahas nanti di sebuah DevFest. Gimana sih kita lakukan field report atau dari report dari user kita
sebelum kita menentukan, decide untuk menentukan adomsi teknologi terbaru.
Ya kalau yang caranya Eka itu kan udah di develop kan, udah di develop baru di cek kan apakah ini support atau nggak.
Udah tapi MVP-nya doang.
Sebelum kita decide untuk pakai, kita cek usernya dulu, apakah usernya udah support.
Terus abis itu dibikin model prediksinya, kira-kira dia akan support berapa bulan lagi, berapa tahun lagi.
Masin learning, over thinking, penyakit develop.
Ide-nya bagus tuh, ide-nya menarik.
Boleh gue berpikiran setelah ngobrol begini, asik ya.
Loh nggak, apa kalau mau iseng nih, ya udah pas lagi baru loading, cek aja di navigatornya misalnya bikin satu objek nih.
Apakah geolocation in navigator, apakah misalnya add to home screen ada, apakah web RTC ada, kumpulin jadi satu objek, stringify, kirim.
Ya hati-hati soal GDPR, belum.
Oh iya, gitu.
Kalau kita ambil data itu.
Ya kan itu asal anonymize.
Jadi kalau kan GDPR ada aturannya sendiri, terus California kan di Amerika khusus California juga ada.
Jadi ya pastiin kita tetap ngikutin aturan yang dilakukan.
Itu ngaruhnya ke personally identifiable information.
Nah apa, pastiin misalnya cookiesnya nggak ikut dikirim ya, cookiesnya nggak diinclude.
Atau misalnya kita pakai apa itu yang bawaannya AWS, Cognito.
Atau apalah ya service apapun yang buat ngacak dan menghilangkan personally identifiable information dari data yang kita kirim.
Karena maksudnya kalau yang kasus tadi kan tujuan kita pingin dapat gambaran besar tentang seluruh user base kita.
Bukan satu persatu tapi seluruh user base, berapa persen yang support geolocation, berapa persen yang support WebRTC atau apapun itu.
Jadi tetap, ya harus hati-hati, tetap hati-hati tapi bisa, bukannya nggak bisa juga.
Ini biasanya tugas kayak dari sisi high level kali ya, jadi kita pingin datanya.
Terus menentukan next feature yang akan kita launch itu berdasarkan adopsi user kira-kira ke depannya.
Ya kalau kita terlalu cepat adopsi sebuah feature tapi user yang belum bisa pada pakai ya percuma juga kan.
Mending sampai threshold tertentu baru di develop.
Jadi secara investasinya lebih tepat waktu dan tepat guna.
Walaupun memakan waktu lebih panjang ya.
Harus reset dulu.
Begitu resetnya selesai ternyata si user-user nya.
User nya pas udah update.
Oke, menarik, menarik.
Oke nextnya, ada yang mau di share lagi dari Eka mungkin?
Enggak, udah dulu.
Tentang TypeScript error?
Oh iya ini, ada bonus konten, sampai lupa.
Jadi kan kalau kita pakai TypeScript itu suka ada error yang agak kriptik ya, agak terlalu poetis.
Agak kurang praktikal, maksudnya kita nggak secara langsung tahu itu maksudnya apa.
Nah ini ada website yang mengumpulkan error itu dengan penjelasan yang lebih mudah di mengerti oleh pengungsinya.
Coba di klik.
Static modifier cannot be used with abstract modifier.
What? Kadang apaan coba itu maksudnya.
Tapi ini di sini dijelasin itu maksudnya apa.
Jadi mungkin kalau kita nemu error yang kita sulit pahamin, coba aja dicek di situ.
Oke, oke, mantap.
Tapi saya penasaran, soalnya beberapa waktu yang lalu waktu di acaranya, di meet up-nya Jakarta JS, itu sempat nanya,
ini kalian masih nulis JS apa udah ke TypeScript, udah ke TS?
Ternyata masih banyak juga yang menulis JavaScript ya.
Ya itu tadi. Itu tadi di dunia Jakarta nggak mungkin semua langsung error.
Sama mungkin kalau terutama kalau di tim besar, mungkin nggak segampang itu dapetin buy-in untuk meng-convert suatu codebase.
Ya, konversinya memang, walaupun TypeScript cenderung lebih mudah dibandingkan bahasa yang lain ya seperti rescript atau elm lebih parah.
Ini sebenarnya bisa pelan-pelan sih adopsinya maksudnya integrate ke TypeScript, pakai TS config.
Tapi kita ignore aja dulu JS-nya kan.
Kalau JS kan kayaknya by default nggak diproses oleh TypeScript ya, kecuali kita configure apa itu allow JavaScript.
Sebenarnya bisa, cuma ya itu kalau tim besar, mungkin birokrasi ribet atau apa lah nggak segampang itu langsung di...
untuk mengubah suatu codebase.
Oke, kemudian dari Ivan ada PWA Summit.
PWA Summit. Kapan ya caranya?
Besok ya?
Besok, tanggal 5.
Ya besok. Gua ada di kalender jadi nggak tau. Besok.
Ya, register aja for free.
Jam 4 sore ya?
Jam 4 sore.
Jam 8 malam.
Tumpen jamnya enak.
Iya, jam 9 pagi.
Karena Eropa kali ya, kalau Amerika kan jamnya lebih sulit.
Ini Eropa Eropa, jadi jam 9 pagi di sana.
Kalau jam 9 pagi mereka ya kita masih oke lah, masih sore.
Register aja free?
Free, online dan kira-kira ada materi yang ditunggu nggak, yang menarik?
Workshop mana? Kalau masih pengen mulai getting started ya untuk workshop, boleh.
Kalau Ivan sendiri tertariknya kemana?
Itu yang Modern PWA Winning Combo for Best Client Experience pengen menarik juga soal studi kasusnya.
GDI juga ya?
Betul.
GDI, dia kerjanya di Intel?
Oke.
Intel Indonesia atau Intel USD?
Kayaknya dia Eropa ya.
Kalau Intel Indonesia kan itu, katanya masak nasi goreng gitu ya.
Masak nasi goreng, oh iya.
Maksudnya sekalian gitu.
Katanya, katanya.
Oh iya, yang pakai HT gitu kan.
Winning combo, menarik.
Terus apa lagi ya, kira-kira menariknya?
Itu banyak loh getting started with PWA workshop itu banyak, itu diulang orangnya berbeda.
Jadi silahkan, silahkan ikuti yang mana mau gitu loh maksudnya.
Yang paling cocok.
Yang paling sesuai, betul.
Karena ini fokusnya kayaknya supaya membangkitkan lagi orang supaya awalnya kayaknya masuk PWA.
PWA terus nggak bisa masuk karena webnya makin lama, makin berat, makin banyak JavaScript.
Terus akhirnya call web fighter dulu, baru sekarang balik lagi PWA.
Progressive Enhancement.
Progressive Enhancement.
Itu tuh emang kalau misalnya terlalu banyak JavaScript.
Oh iya, nggak bisa ya, nggak muncul itu homescreennya ya.
Kalau misalnya suatu, jadi semua situs atau aplikasi web itu sebenarnya bisa jadi PWA.
Tapi dia harus memenuhi kriteria tertentu, berarti yang jadi barrier secara nggak langsung.
Yang jadi halangan adalah memenuhi kriteria-kriteria itu ya harus responsif.
Harus ada service worker minimal buat handle 404 kalau offline di halaman utama ya.
Iya, betul.
Oke, udah satu jam kita ngobrol.
Banyak ide berseliwaran, jangan lupa dicata.
Jangan sampai lupa.
Ada yang tanya nggak di Slido?
Ada yang tanya di Slido.
Tak ada.
Apakah mempelajari core web fighter meningkatkan apa itu?
Kesempat anda berkerjaan?
Ya bisa, coba iya dan tidak juga itu.
Bisa banget bisa jadi selling point.
Menaikan revenue ya.
Oke, kalau gitu mungkin untuk malam ini episode kedua kita sudahi dulu saja.
Sebelum udahan mungkin dari teman-teman ada yang mau share sosial medianya silahkan.
Kalau saya bisa share ke twitter.com/rizafahmi22
Kalau yang lain?
Ke twitter.com/ivanchris.com saja.
Ivanchris.com
D-O-T ya.
E-K-F-Y-I.
Gak pernah buka ya.
Oh, gak pernah.
Oke, kalau gitu silahkan di follow.
Minggu depan bahasa apa?
Ini ada pertanyaan nih. Minggu depan bahasa apa kita?
Minggu depan bahasa apa ya?
Ada ide nggak Mas Lucky?
Ada yang mau request bahasa apa?
Kita ada topik menarik tentang apa ya?
Ya itu best content PWA summit.
Itu ya summary ya?
Bisa bisa.
Oh ya, kalau teman-teman ada ide, silahkan langsung lempar ide nya.
Topik minggu depan mau bahasa apa?
Kita masih ada waktu sekitar 5-6 hari untuk berembuk, untuk bahas topiknya.
Jadi kalau ada suggestion, silahkan ke beat.ly/ngobrolinweb.
Nanti kalau sarannya menarik, kita akan angkat menjadi topik.
Oke, kalau gitu terima kasih buat semuanya.
Terima kasih.
Terima kasih buat teman-teman, terima kasih buat Eka dan Ivan yang sudah menemani juga.
Sama-sama Mas Riza.
Kita ketemu lagi minggu depan di jam yang sama, di hari dan jam yang sama.
Selamat malam, selamat istirahat.
Dadah.
Selamat malam, bye.
Bye.
Mari kita inburn kes.
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 CSS Container Queries (dan polyfill-nya) - https://caniuse.com/css-container-queries - https://developer.chrome.com/blog/cq-polyfill/ Format baru belajar teknologi web - https://web.dev/learn/ - https://web.dev/learn/css/ - Yang berbahasa Indonesia https://htmlcss.rizafahmi.com/ CSS inline vs Kunjungi https://ngobrol.in untuk catatan, tautan dan informasi topik lainnya.
Episode Terkait
1 Feb 2023
Ngobrolin Storage
Melanjutkan episode cookie minggu sebelumnya, pembahasan bergeser ke tempat penyimpanan lain di browser — bukan basis da...
8 Mar 2023
Ngobrolin Proyek Fugu
Proyek Fugu adalah nama panggilan yang lebih catchy untuk web capabilities project — upaya menutup jarak antara apa yang...
2 Agu 2023
Ngobrolin Privacy Sandbox
Privacy Sandbox dibahas bukan sebagai wacana melainkan sesuatu yang harus disiapkan dari sekarang, karena dampaknya bisa...
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 .