Ngobrolin Web Offline di DevFest Bogor
Ringkasan Episode
Bantu KoreksiEpisode ini direkam langsung dari panggung sebuah konferensi komunitas, dan sebagian besarnya sesi tanya jawab. Pertanyaan pertama soal ongkos performa View Transitions API — jawabannya jujur: ongkosnya tetap ada, tapi jauh lebih ringan daripada memakai pustaka animasi, karena sebagian besar ditangani browser. Sebagian properti animasi bahkan berjalan di luar main thread, meski yang menyangkut lebar dan tinggi masih membebaninya. Pertanyaan berikutnya membedakan bfcache dari cache biasa. Cache biasa menyimpan berkas sumbernya sehingga halaman tetap harus dirender ulang; back-forward cache menyimpan snapshot halaman yang sudah jadi lengkap dengan state terakhirnya. Analoginya bagus: seperti meninggalkan kamar lalu kembali dan menemukannya persis seperti saat ditinggalkan. Disebutkan pula dua penyebab paling umum ia tidak bekerja — memakai unload dan mengirim header no-store. Sisanya berisi saran untuk pertanyaan yang sangat membumi: membuat situs portofolio penuh gambar tapi tetap cepat. Jawabannya memakai srcset agar ukuran gambar menyesuaikan perangkat, membatasi ukuran maksimalnya, menyediakan gambar penuh hanya sebagai pilihan, memakai tag picture untuk art direction, mempertimbangkan format yang lebih modern daripada JPEG dan PNG, serta placeholder base64 yang di-blur — dengan catatan elemen LCP jangan pernah di-lazy load. Ketiga metrik Core Web Vitals dijelaskan mewakili tiga hal berbeda: LCP untuk kecepatan tampil, CLS untuk kestabilan, dan INP untuk responsivitas, dipantau lewat Google Search Console atau Lighthouse CI. Ditutup dengan tamu dari Kuala Lumpur soal kebangkitan Angular di versi 17.
Poin-poin Utama
- •View Transitions API tetap punya ongkos performa, tapi jauh lebih ringan daripada memakai pustaka animasi karena sebagian besar ditangani browser
- •Sebagian properti animasi berjalan di luar main thread, sementara yang menyangkut lebar dan tinggi masih membebaninya
- •Cache biasa menyimpan berkas sumbernya, sedangkan bfcache menyimpan snapshot halaman yang sudah jadi lengkap dengan state terakhirnya
- •Dua penyebab paling umum bfcache tidak bekerja: memakai unload dan mengirim header no-store
- •Ketiga metrik Core Web Vitals mewakili hal berbeda — LCP untuk kecepatan tampil, CLS untuk kestabilan, INP untuk responsivitas
- •Untuk situs penuh gambar: pakai srcset dan tag picture, batasi ukuran maksimal, sediakan gambar penuh hanya sebagai pilihan, dan jangan pernah lazy load elemen LCP
- •Angular versi 17 dibahas sebagai kebangkitan: lompatan kecepatan besar, sintaks control flow baru, dan signals yang kini diadopsi banyak framework lain
Halo, ketemu lagi kita.
Terima kasih teman-teman buat yang masih stay di sini.
Ini adalah sesi spesial yang dipersiapkan oleh GDG Booger khusus untuk kita.
Jadi buat teman-teman yang mungkin sudah benar atau yang belum.
Yang belum pasti.
Yang belum.
Kita bertiga biasanya suka ngomong di hari Selasa.
Selasa malam.
Waktunya ngomrolin gue.
Dan kita gak pernah kompak kalau buka acara.
Nah, khusus hari ini gak hari Selasa, tapi kita tetap bisa ngobrol dulu.
Karena ngobrol dulu bisa tiap hari.
Jadi ini pertama kalinya kita ada acara offline, in person, di acara GDG Booger.
Kepertangan dong buat teman-teman GDG Booger.
Terima kasih udah bikin acara kayak gini.
Ini adalah episode ke-60 kita.
Dari 0, jadi 61 sebenarnya.
Jadi episode ke-61 kurang lebih kita udah jalan 1 tahun lebih.
Kita awalnya ada janapet, kita ketemu dong acara ulang tahun yang ngobrolin gue, 1 tahun.
Ketemu dimana ya?
Akhirnya pas banget karena di Booger kita bertiga di udang.
Eh, boleh gak kita nembeng acara di sini bikin ngobrolin gue versi offline.
Jadi sore hari ini kita akan ngobrol tentang apa aja.
Teman-teman boleh nanya.
Ini ada suidonya ya.
Itu udah ada pertanyaan, ntar kita buat EKA ya.
Jadi kalau ada yang mau nanya langsung boleh.
Boleh kan ya?
Ada yang mau nanya langsung.
Atau nanya lihat sudu juga boleh.
Lihat transkrip lengkap (1101 segmen lagi)
Nanti rencananya kita akan, ini sesinya akan di depan.
Dan akan kita aktifkan juga di replay.
Di hari Selasa Malam tentunya.
Oke, kita gak perlu kenalin diri kan ya?
Udah perlu kenalin diri.
Udah kenal ya?
Oh iya tadi juga udah.
Pertanyaan langsung?
Bukan.
Ntar, ntar.
Dan bagi teman-teman yang belum pernah menonton acara kita.
Itu di setiap Selasa Malam pukul 8.00.
Di YouTube Live di channelnya Mas Riza.
Dengan topiknya ngobrolin web.
Cari aja ngobrolin web di YouTube setiap Selasa Malam pukul 8.00.
Dan kita selalu bahas mengenai all about web.
Pastinya.
Ya, ini pertanyaan pertama langsung aja ya. Kita jawab ya.
Mau bertanya apakah ada performance dulu?
Join us at Slido.
Terus untuk Eka, ada pertanyaan tentang performance cost dalam kebunan transisi API?
Ya, jadi kalau performance cost pasti ada ya.
Apapun yang kita lakukan pasti ada performance cost.
Tapi jauh lebih rendah dari kalau kita pakai animation library yang sekarang.
Alasannya itu tadi karena banyak hal yang sudah dihandle oleh built-in browser features.
Nah, kalau untuk melakukan animasi, itu kan sebagian property animasi itu
udah punya jalur sendiri, enggak jalan di main thread.
Cuma kalau untuk menganimasi size, width, dan height.
Teber dan panjang.
Itu ya baik pakai few transitions API atau bukan.
Itu sampai sekarang memang masih dijalankan di main thread.
Tapi kabar positifnya untuk few transitions yang menganimasi lebar,
punya ukuran, lebar dan panjang.
Karena itu umum banget kan.
Misalnya kita menclek thumbnail, jadi besar.
Itu kan pasti menganimasi lebar.
Sekarang masih jalan di main thread.
Ke depannya ada rencana untuk bisa memindahkan itu dari main thread.
Itu detailnya bisa dilihat di blog Chrome Developer yang tadi ada linknya.
Ini pertanyaannya enggak harus seputar materi kita tadi ya,
bebas ya, nanti tentang web, tentang apa aja boleh.
Tapi tentang web, jangan tanya ke alaman.
Nanti kita...
Oke, pertanyaan berikutnya untuk Ivan.
Berdasarkan tentang BFcache.
Apa bedanya BFcache dan cache biasa?
Bedanya BFcache dengan cache.
Kalau cache itu, yang di cache itu...
Back forward cache.
Jadi di back forward cache yang disimpan adalah snapshot dari halaman tersebut.
Snapshot ya, jadi sudah hasil yang ke render.
Kalau cache biasa, seperti...
Apa ya cache biasa ya?
Cache di browser itu...
Browser, browser...
Bukan.
Di web biasa kan ada cache biasa.
Cache interface, cache API.
Itu yang disimpan di source-nya.
Misalnya HTML-nya, tetapi bukan hasil render-nya.
Jadi CSS-nya disimpan di cache.
JS-nya di cache.
Jadi waktu di-load, cuma di-load dari memori.
Tapi tidak di-load dari origin.
Atau HTML tidak di-load lagi dari origin.
Cuma belum di-render.
Kalau back forward cache,
dia sudah hasil render-nya.
Jadi kayak snapshot.
Sudah tinggal ditampilkan.
Bahkan nggak perlu di-render.
Jadi tinggal ditampilkan saja.
Kayak snapshot virtual memory gitu ya.
Dengan state yang terbaru, terakhir di CSS juga?
Nggak, nggak.
Jadi state-nya seperti sama.
Simpan.
Waktu nanti ditinggal.
Terus waktu di-pack, balik.
Begitu lagi, gitu.
State terakhir.
Dan kalau teman-teman ada pertanyaan lanjutkan, silahkan ya.
Kalau menurutku, ini bagian dari user experience juga nggak sih?
Itu kan mirip yang view transition tadi.
Sebetulnya kalau kita ngomong
strictly cara kerja browser,
kan memang expected
kalau kita nge-update Elementum,
tiba-tiba ada.
Tapi kalau user secara bawah sadar,
expect-nya visual itu datang dari somewhere.
Terus back forward cache juga gitu.
Mungkin user kan expect-nya
ngisi form name.
Atau infinite scrolling,
load more, load more, sampai pos-nya banyak.
Terus ditinggal untuk membuka suatu pos.
Nah, pas dia pencek back,
kan kalau dari logika browser,
itu kan kayak sebetulnya load baru lagi,
harusnya dari atas lagi.
Cuma kalau dari UX, dari logika user,
tadi ditinggalin di situ,
pas balik kan harus kayak gitu lagi.
Jadi nganggepnya kayak fisik ya,
kayak analogik fisik.
Kita ninggalin kamar kita atau rumah kita,
semua bareng-barengnya kayak gini.
Nggak mungkin pas kita balik,
tapi udah rapi semua.
Kecuali kemalingan.
Sekarang saya lagi ya,
dari Mas Badruddin.
Bagaimana mengukur dan mengantar
performance Core Web Vitals secara berkelanjutan?
Dan apakah metric khusus yang menjadi fokus utama Anda?
Core Web Vitals sudah pasti ada 3.
Namanya juga Core,
LCP,
CLS,
dan INPEC yang baru,
menggantikan first input delay.
Kalau vital-vital yang lain sebenarnya ada.
FCP, first content full pain,
time to first byte,
terus kemudian time to interactive,
ada banyak.
Cuma kalau dari Core Web Vitals,
yang paling utama,
ini ya semuanya,
tiga-tiganya perlu dipantal.
Karena itu ketiga hal ini,
kalau secara generalnya dilihat,
kalau largest content full pain itu
adalah seperti kecepatan ngerender-nya,
kecepatan user melihat,
jadi speed,
LCP itu tentang speed,
CLS itu tentang stability,
dan INPEC itu mengenai responsive,
bukan responsive size ya,
tetapi responsiveness,
jadi secepat apa interaksi user
atau browser bisa menampilkan
atau mengeksekusi interaksi yang terjadi,
seperti touch, scroll, atau click.
Jadi ketiganya penting.
Dan untuk monitor-nya,
ada yang berbayar, ada yang free,
yang free ya pakai aja,
yang di Search Console dari Google,
Google Search Console,
yang berbayar ada banyak,
ada Matrix, segala macam,
itu bisa kayak continuous monitoring.
Ada CICD-nya juga ada?
CICD, jadi kalau dari Lighthouse,
ada Lighthouse CI juga.
Apakah semua browser mendukung bfcache,
dan apakah ada batasan atau situasi
di mana bfcache tidak berfungsi dengan baik?
Yes, semua browser sudah mendukung bfcache,
3 major browser sudah mendukung,
dan ada hal apa yang menyebabkan bfcache
tidak bekerja dengan baik,
itu tadi sudah saya sampaikan,
ada 2 yang paling umum,
kalian menggunakan Windows.unload,
atau Unload API,
kedua kalian menambahkan header no store,
no-store,
kalau ada header no store,
artinya browser tidak akan simpan
di browser cache, sorry bfcache.
Bahasa panggilan-panggilan yang bagus
untuk website,
website itu berarti kalau front-end
sudah pasti potential CSS Javascript,
atau kalau mau lebih modern,
mungkin TypeScript,
tapi untuk band-end, bebas,
teman-teman mau pakai PHP bisa,
pakai Go boleh, pakai Python, Ruby,
band-end itu bisa,
jadi kalau untuk front-end,
mau gak mau harus belajar Javascript,
atau turunannya,
TypeScript dan teman-teman,
juga dibina dengan CSS.
Mungkin itu ya.
Pertanyaan berikutnya,
saya ingin membuat website portfolio,
karena banyak media,
jadi yang misalnya harus memberikan ke saya
adalah loadingnya menjadi cepat.
Ini pertanyaan kenapa ternyata aneh?
Apa yang diberikan?
Pertanyaan aneh?
Oh sarang.
Oh gitu.
Jadi feature-nya jangan besar-besar.
Tapi desain grafik harus bagus,
jangan sampai...
Jadi feature itu,
kalau halaman banyak grafik ya,
feature itu kan bisa responsif,
atau source set,
sudah dengar source set,
src set.
Kalau misalnya browser hub,
webnya dibuka di mobile,
kan nggak perlu kecil-kecil amat.
Jadi bisa pakai source set,
yang menampilkan umurannya lebih kecil,
yang ditambil yang sedikit lebih besar,
yang di desktop yang paling besar.
Namun,
tetap butuh dilimit,
misalnya jangan sampai kasih yang full size,
karena yang full size itu,
mungkin bisa,
kalau 8-10 mega kan,
kegedean ya,
dan boros bandwidth.
Yaitu pakai source set ini,
dan kasih opsi ke user,
kalau melihat full size-nya,
bukan intact baru.
Jadi benar-benar,
atau benar-benar,
hanya menampilkan umur yang paling besar itu bisa,
untuk perang saja.
Jadi yang menghabiskan boros bandwidth bagi user,
dan hanya memberikan opsi itu,
jika user ingin melihat yang full size.
View source set ini,
bisa kita tweak,
detail banget,
jadi ukuran viewport.
Terus kadang kan,
misalnya kalau di HP mobile,
itu 100% besarnya.
Tapi kalau di desktop,
cuma tunel kecil.
Karena ini desain grafis ya,
jadi kualitas gambar kan,
itu penting.
Jadi bisa kita spesifikasi yang di situ.
Terus kalau misalnya retina,
bisa kita tentuin juga,
itu satu source set.
Terus jangan khawatir,
karena image source set itu,
kita tetap fallback ke src,
source atributnya.
Jadi kalau browser nggak support,
walaupun jadi lebih berat ya,
karena mungkin ukuran file-nya lebih besar,
tetap aman.
Lalu mungkin tips yang terakhir,
bisa lazy look,
pakai string base64.
Base64 itu misalnya bisa kayak di blur dulu,
selama masih loading,
di situ sambil nunggu gambarnya diambil,
baru setelah selesai ditampilkan.
Tapi jangan lupa,
yang paling atas, yang lcp,
jangan di lazy look.
Tabahan, satu lagi,
kalau media image,
itu nggak
mesti pakai image src.
Bisa pakai picture.
Ada yang tahu,
picture tag?
Picture tag,
nanti coba baca di MDM.
Art Direction,
nanti ada picture tag.
Jangan lupa juga ada
format-format baru ya,
dari image,
contohnya active,
dan lain-lain yang lebih optimized
untuk ditampilkan
di browser yang lebih modern.
Karena JPEG dan PEG itu udah cukup lama,
mungkin di browser yang modern,
cukup bagus, tapi kalau browser modern,
mungkin lebih cocok
untuk format-format yang modern.
Nah, berhubung kita punya
tanggau dari Kuala Lumpur,
dan web angular, kan,
jadi bisa kita tanya-tanya.
Jadi,
we would like to welcome
Mr. Jera.
We invite Mr. Jera
to come back to stage
with us
to give more insight
about web AI
and also angular.
Because Jera
is web GTE
for angular,
right? Am I correct?
Okay, welcome Jera.
And give applause for Jera.
So,
first question.
How's Indonesia?
Very hot.
Okay.
What about the food?
Hello?
Okay.
So, the weather is very hot.
And the food is very spicy.
That's another video.
And how about the people?
Okay, I haven't got
that much time to interact
with the people, but so far
I think the people is really nice
and they interact
with me
on my talks, and
I think they like my jokes.
I don't know.
So, my first question,
my second question is,
or third,
what's the meaning
of angular?
Alright, so there's, I don't know
how many of you are angular
developers?
I use angular1.
Okay, angular1, okay.
I use angularjs.
Angularjs, yeah, this is a long time.
I actually started
with angularjs.
And then when I saw
angular2,
or the new angular, this is when
I got more active in the community.
And at the time
I was at ng-comp
in Utah when they
released angular2.
It was really exciting.
So, just
few days ago,
angular released
a new version, which is now
version 17.
Wow!
So maybe you only know
about angular2, and then
it got a little bit out
of hand. But I think
since angular14,
we have seen like
really, really a big
change in angular.
And I think until this last
version, everything has
come together, and
actually, the angular
team, they
released a new logo.
So if you
look, if you go to the
website, which actually there's
a new documentation
website, it's angular.dev,
the whole
new look is way more
modern.
You will see a lot of pink,
you will see
kind of a modernized brand
for angular.
And yeah, it's really exciting.
What the angular
community mentions
most of the time is this
angular renaissance.
Like it's
coming back stronger
and
it's faster, it's really, really fast.
And some of the
initial tests on speed,
they have
put in the blame
all the other frameworks.
It's 90% faster
than the last version
of angular. And if you
go, there's a benchmark
website where all the frameworks,
web frameworks
are compared. And now
angular17,
it's faster than build, it's faster
than react, it's faster than
it's built, it's
super, super fast. So it's really,
really exciting times for angular.
Nice.
Well,
they released,
so what has happened is
in a few versions back,
they released a new build
engine, which is the rendering
behind angular.
And that allowed
a lot of new cool features.
And if I give you
like a list
of features, probably
the most important
one, I guess, is the performance.
I mean, this increase in
the performance is really, really
amazing. And
when you compare it to the other frameworks
that maybe you think that react will be faster
than angular, now
we have proof that
it's now behind. So that's
really cool. And then
one thing that has
made also a lot of
news in social media is
the new, what they call the new
control flow. And
the new control flow is a new way
to use ng-if,
ng-for, and ng-swift.
And now
we have a new syntax
to use in our templates for
angular. And this is also part
of the performance improvements.
Nice. What do you think
the key feature of Angular compared to
Angular? I see you
have to convince us
to use Angular. What's the meaning?
Well, I think now the shiny
the shiny
diamond in
Angular is
the signals,
angular signals. So
it has been
also everywhere for
front-end. And
signals have been implemented
now in React.
Everyone has
adopted signals.
Yes, yes.
So there's a few frameworks that
introduced the concept, the idea.
And then angular was one
of the first that released it.
And yeah, right
now it's part of the
new version. So it's completely
fully integrated. There
was a developer preview
for a few months.
And right now it's official. So if you
build a new Angular
application, it will incorporate
signals
just from the initial
build. So your application
will be really, really fast.
Thank you. So
this is like a curiosity
question for me about
the positioning of Angular
in this entire
ecosystem. Because we
know that like
well, this
the whole community is
divided between
React, Fue,
different spell, and so on.
This is like a framework
war somewhere
up there, right? New framework comes up.
Every second, new framework
comes up. So, but I'm curious
how this come up with it.
Where does the Angular
comes out in this
in the ecosystem?
What, what, what?
Like, how it
being used in the industry? Is it like
mostly enterprise, or
scale, or just like it in the
I don't know. So
to you, Angular.
So Angular has been focusing
in different areas.
And one of them was
always stability.
So that means
that when you introduce a new
version, you have
a way to automate
your code from
the last version to the new version.
So you can run a command.
This is a
migration of the code.
And they automated
the whole process. So when you
change version, you run
on your command line, you run
ngupdate. It's always
the same command. And
ngupdate will go
through all of the updates
on that version, will
look for the code changes,
and will automate that
for you. So that's really
really good. And maybe some
developers, they don't know about this.
Because this, this has been
improved and
developed maybe in the last two
years. So this is
something that Angular developers
enjoy. So if there is a new
version, you just go into your
CLI and run
ngupdate. And
you can do that for multiple versions.
So imagine you have an old, maybe
a project that you...
Yes, maybe it's a
three years old project.
ngupdate
will take you from
Angular, imagine Angular 8
to Angular 17.
And you don't have
to change anything.
Of course,
it just requires you to jump
one version. So you need to do
one version at a time.
I can relate to that because
mostly my time spent is
to update dependencies
of my project.
So sometimes if I like
to upgrade React 16
to React 17, and I get
compatibility issue
with certain libraries,
it doesn't allow me to update,
I have to fix here and there,
and it's all heading.
This is one of the main pains
in the frontend
or web.
The dependencies just keep
upgrading, they just keep upgrading.
Even if you just use TypeScript,
because TypeScript
is quite fast-paced,
there will be always some new release
of TypeScript.
And it's really good
that Angular offers this
automated
upgrade experience
for developers.
They have been improving the developer
experience a lot.
So that's what makes Angular
in another category, because
for other frameworks, do you have
this automation between versions?
It's interesting that
Angular has been doing this for
two years, because
Svelkit, not Svel, but Svelkit,
the meta framework, offered it, but
not only this year, when they
released a major
version, but it's nice to see
like many frameworks.
This was introduced with
Angular schematics,
so it's a way to automate
code changes.
Alright, thank you.
Shall we come back
to the questions
that we have here?
I can translate.
Question from Hanif.
Can we ask the tips and tricks
to improve process
time from API
if the user
if the user use like
there are a lot of
concurrent user
and database has
millions of records?
Okay, this is a good question.
Okay.
So that means like
the architecture is like
you have
millions of data
and then you have a lot of
concurrent user
that access the same time
and this is like I'm talking about
enterprise kind of
architecture.
There is no
one answer
to fix this.
There's no one answer.
There's no like silver bullet
to fix this.
It's always come back to trial
and error and of course
this is like whether your architecture
playing in place.
It doesn't help. You cannot help this
just using one framework and it will
fix for you.
And it doesn't also automate this.
Of course,
cache method here.
Cache method and also
asynchronous or queuing
queue
to handle the traffic
and also
yes, of course, database
replicas and
replicas from
many, so it's
like scaling your
architecture, not scaling
your framework.
So this is about architecture.
Maybe someone have
a better opinion.
You can also talk in Indonesia.
Maybe next question.
Apakah OSM dapat integrasikan dengan API
jika bisa bagaimana proses teknisnya?
Sebenarnya sama aja.
Seperti mengintegrasikan dengan
API tanpa memasuki.
Tapi yang lebih
memungkinkan lagi adalah
bahkan bisa ditaruh di World Assembly.
Ada yang namanya Skylight
database yang cuman satu file
dan itu bisa di load
atau bisa di compile
kompilasi ke World Assembly.
Sehingga database kita
berada di client.
Dan mungkin kesempatannya hanya syncing aja.
Itu mungkin lagi sekali.
Satu user, satu DB ya?
Jadi kayak
itu lah modelnya.
Jadi ketika ada koneksi ke server
hanya untuk syncing aja.
Itu juga mungkin.
Jadi maksudnya, kalau misalnya kita punya
Web Assembly,
kita bisa koneksi ke API dari Web Assembly?
Ya.
Cuma seperti
memasuki.
Tapi java Skylight bukan memasuki.
Ia memasuki dari
programming language yang digunakan
dari web assembly.
Oh.
Saya baru tahu.
Oh ya, saya melihat.
Ya, saya melihat kita bisa menggunakan
workplace dari Web Assembly.
Dan itu server web.
Ya.
Sebenarnya.
Oke. Pertanyaan selanjutnya.
Oke. Pertanyaan ini
adalah tentang tweet
untuk saya.
Untuk memperbaikkan LCP
dalam karusel,
tapi karusel itu
ada X.
Oke. Jadi
sekarang pertanyaannya
X nya di depan
atau di tengah atau di belakang?
Biasanya
setahu saya, X di karusel itu di tengah.
Ya.
Setahu di karusel itu di tengah.
Bukan di karusel pertama.
Biasanya.
Karena karusel itu seperti image.
Dan kamu ada X
ketika kamu scroll.
Ya. Jadi.
Kalau LCP nya untuk
image pertama, sama seperti yang saya katakan.
Tetapi jarang banget yang pakai
X di LCP.
Sebagai karusel dan itu sebagai LJP.
Dan biasanya
biasanya
LCP
ketika browser melihat LCP
ketika browser melihat LCP
dan itu adalah image yang di-lazy load.
Bisa jadi browser
menangkap LCP nya
di elemen yang lain.
Bukan berarti karusel itu.
Bisa jadi text yang ada besar
sebelum title
biasanya.
Dan
kalau kalian mengatakan
X kalian di karusel itu
semuanya X.
Kayaknya itu melanggar
ini deh.
It breaks the rule.
Karena X itu gak boleh
di dalam karusel semuanya.
Masih banyak-banyak karusel ya?
Hah?
Masih banyak-banyak karusel.
Ya.
Even though I don't
like karusel.
Tetapi yes.
Because still
kalau X nya di tengah-tengah
maka itu gak dianggap sebagai LCP.
Yang dianggap adalah image yang pertama
biasanya.
Tapi kalau itu kalian terpaksa harus
image yang pertama
yang usahakan ada text yang besar
sebelumnya.
Sehingga
LCP yang dipakai adalah
text yang besar itu.
Bukan X nya.
Itu load paling berakhir.
Jadi jangan sampai X nya yang
diutamakan.
Nah, ikut aja.
Speaker, tapi ikut aja.
Karena gak bisa ngepick di slide.
Jadi kan LCP
gak harus X nih.
Tapi gimana kalau gambar pertama
di karusel yang dianggap sebagai LCP
itu adalah konten dynamic.
Berarti itu bit praktis ya?
Misalnya
kita punya user generated
konten, latest post
dari user kita, kan itu bisa
berubah-ubah tuh. Tapi apasnya
yang dideteksi sebagai LCP itu.
Nah, berarti kan kita LCP-nya bakal
salah terus kan?
Bukan. Yang diambilkan elemennya
bukan kontennya.
Kontennya bebas. Jadi elemen
itu yang diambil sebagai LCP.
Dan kalau
page load itu LCP selalu
berubah-ubah loh. Jadi
when browser
start rendering
the LCP keep changing
when they see largest content
and the last largest
content that's the LCP.
The last largest content that render
that's the LCP.
So
it depends.
It also depends
on the view point.
LCP on desktop may be
different from LCP in mobile.
Berarti bisa diakalin pakai
placeholder asal kalau kita
tahu proporsinya.
Okay, next question.
Arsitektur komunikasi yang sering dilakukan
antara kalian dan software adalah REST.
Normally we use REST.
Can we use
GRTC? Of course.
Keto bisa.
Karena itu adalah
protokol komunikasi
networking. Jadi bisa pakai
REST, bisa pakai GraphQL,
bisa pakai SOAP,
pakai SNL,
pakai SOAP, bisa.
Dan bisa juga pakai GRTC
dan berbagai protokol lain.
Berikutnya,
kalau menggunakan WebAssembly,
if you use WebAssembly
consume by JavaScript,
which is better?
SSC, SSS
or SSSR?
Gak ada masalah sih. Mau pakai apa aja boleh.
Yang dijawabkan
di demo tadi, saya pakai
client side aja.
Ada server-nya. Jadi server side rendering
itu boleh.
Server-nya akan load
database static. Atau pakai SSC juga boleh.
Static side generator.
Jadi webnya static, kemudian
WebAssembly di load, kemudian
webnya jadi
keterlaluan di
sisi client aja.
Mudah-mudahan
menjawab.
Kemudian, pertanyaan
berikutnya.
Saya bukan pengguna.
Tapi ada
pengguna keluarga yang dipanggil
Gerard Sacks.
Sekarang saya berbicara bahasa Jepang.
Tapi mungkin.
Sebenarnya, banyak orang membuat
saya membuat pengguna keluarga
tersebut.
Saya juga
punya hobi ini.
Saya tidak tahu jika kalian sudah melihat talk saya.
Tapi di slide, ada sedikit
desain.
Jadi itu hobi saya.
Saya punya banyak fons.
Saya suka fons.
Dan saya mencoba
menggunakan fons yang bagus
untuk slides saya.
Mungkin saya menghabiskan
banyak waktu menemukan
fons yang bagus.
Yang terlihat lebih seperti desainer.
Bukan pengembara.
Dan itu sama.
Jadi ketika saya memilih fons untuk
environment saya,
untuk visual code misalnya,
saya bisa menunggu 2 hari.
Maksud saya, saya bisa menunggu 2 hari
karena itu tidak benar-benar apa yang saya suka.
Dan saya bisa
menjadi sedikit gila dengan fons.
Ya, ya.
Mungkin karena nama saya.
Oke.
Pertanyaan selanjutnya.
Apa yang terjadi dengan animasi
jika pengguna menggunakan browser
yang tidak mendukung view transition
API?
Nah, ini untungnya cukup mudah
karena semua yang di platform web
harus sebaiknya menggunakan
progressive enhancement.
Apa yang dimaksudkan progressive enhancement?
Kalau memang di support,
fitur yang baru
dan lebih bagus di support,
ya dijalankan.
Kalau enggak, jangan sampai mempengaruhi user.
Nah, kalau di sini, caranya
ya cukup detek saja.
If, tanda semu,
document.startViewTransition.
Jadi kalau metode itu tidak ada,
return. Ya udah.
Se-simple itu.
Jadi bagi user yang browser-nya enggak support,
ya langsung meng-update.dome
seperti biasa.
Sedangkan kalau user yang browser-nya support,
akan mendapat fitur view transition.
Itu yang paling simple.
Strategi yang paling
sederhana.
Tapi gimana kalau misalnya
animasi itu memang bagian yang
penting dari produk kita.
Misalnya kita portfolio designer
apapun yang perlu visual.
Kita bisa pakai strategi yang namanya
dynamic import.
Atau kita sering sebut lazy loading.
Itu udah jadi fitur standar
di JavaScript.
Di React juga bisa.
Jadi kita bisa pakai kondisional.
Misalnya if, document.startViewTransition.
Kalau metode-nya ada,
ya kita pakai metode itu.
Kalau enggak ada,
kita bisa await import.
Misalnya kita await import pakai library custom.
Kalau di React pakai framer motion.
Kalau di vanilla pakai
swap.js dan lain-lain.
Itu gini-gini.
Pertanyaan terakhir kali ya.
Kita udah mau dihujung acara.
Jadi pertanyaan terakhir.
Apakah web server ini hanya untuk C++
dan S9? Nggak. Tadi saya udah contohin ya.
Ada C++.
Ada bisa pakai Rust.
Bisa pakai Go.
Zip.
Ada Dart juga.
Ada Swint bahkan.
Dan Kotlin juga bisa.
Dan akan banyak bahasa-bahasa lain
yang dihormati.
Bukan. Ini untuk C++.
Program.
Oke.
Mungkin kita
belari.
Cukup ga usulnya.
Bagaimana menghubungkan kursi-kursi
kursi-kursi panjang yang di dapet dari belari
atau dibagi untuk mengadakan kursi-kursi web?
Oke. Ini untuk
camp long task
into
smaller task in
JavaScript execution.
So, ya.
Seperti yang contoh yang saya kasih tadi.
Banyak
kasus-kasus di mana kita
mengimplementasi
eksekusi JavaScript
yang panjang.
Jadi untuk di break,
usahakan kalau misalnya
dia, bisa kita pakai yield
juga ya. Yield.
Untuk bisa nge-pause
dan memberikan kesempatan
untuk hire
event untuk dieksekusi.
Dan bisa dilanjutkan lagi dengan
yield. Bisa juga dengan
yang tadi. Pakai
delay atau set timeout.
Jadi, dia masih dieksekusi di beda
thread. Bukan masih beda thread.
Di beda cycle.
Ya, karena begitu kalian tambahin set
timeout, dia akan masuk ke
apa ya, queue.
Event loop. Dekat queue selanjutnya
untuk dieksekusi kebelakangan.
Differ. Kita sudah pernah bahas
tentang event loop di
MauRollinWeb. Silahkan nanti pencungi
di youtube-nya.
Terakhir tadi saya ada ngasih
sebuah link ke ENP.
Nanti bisa diminta ke panitia juga slide
saya. Boleh dipake. Nanti ada
ENP atau di web dev ada untuk
optimize ENP. Disitu lebih
banyak informasi mengenai breakdown
task. Ya, bisa lebih banyak
dibajarin.
Dan yang terakhir, kita jawab
aja.
This one is
I said don't never use
event. Windows.unlock
don't do it because
it will disable the back-forward
cache.
So, how to implement
alert when document is not
safe. Okay, what are
the alternatives?
Ini maksudnya jika ada email
atau misalnya text box
kalian mau save.
Sorry, belum di save, tetapi sudah
di close dan kita harus kasih
notifikasi. Itu adalah
teknik yang lama.
Jangan pakai lagi.
Ya.
Don't use that.
Itu
satu
back-forward cache akan
berhenti berfungsi dan
tidak baik untuk
experience. Dan halur itu
kayak mengunci semua
apa? Mengunci semua
input, interaksi.
Jadi tidak baik untuk experience.
Alternatifnya adalah simpan
apapun yang diketikan
oleh user di local
storage.
Just stop.
Use local storage
or
only local storage, atau pakai
yang database apa? Index
dv. Use
local storage or index dv
store user
draft.
Jadi begitu paste itu
di load pulang, kontennya user
tidak hilang.
It's better that way.
Terus.
Ya. Kita sudah
di penghujung acara.
Terima kasih buat teman-teman semua yang masih
di sini. Dan genhan bracket dulu
kita mau selfie kali ya.
Mengabadikan moment ini.
Jadi kita selfie dulu.
Buat teman-teman mungkin
kalau yang di belakang boleh maju-maju ke depan
dan tekan-tekan kamera.
Ini moment yang luar biasa.
Sekarang kita baru sekali melakukan offline.
Dan mudah-mudahan teman-teman
di sini mendapatkan ilmu
pertama ilmunya.
Apa yang kita sampaikan berfakar buat teman-teman.
Kita ketemu lagi
di masa depan.
Dan terima kasih.
Dan semoga kita bisa diskusi
dengan teman-teman.
Dan kalau nanti masih ada
yang mau dapat pertanyaan, kita masih di sini.
Jadi silahkan datang ke kita
dan bertanya. Dan kita bisa diskusi
dengan lanjut.
Who's the longest hand?
Deskripsi asli dari YouTube
Edisi khusus sesi ngobrolin web pertama yang diadakan secara offline langsung dari DevFest @gdgbogor2666 beberapa hari yang lalu. Topiknya seputar Transition API, Performance, WebAssembly dan Angular. ----------------------------------------------------------------------------------- Bergabung menjadi anggota elit di kanal ini: https://www.youtube.com/channel/UCHhAlFGFCGgIusQkQIqJLYw/join Donasi dapat meningkatkan kualitas kanal ini: 💰 https://karyakarsa.com/rizafahmi/tip 💸 https://saweria. Kunjungi https://ngobrol.in untuk catatan, tautan dan informasi topik lainnya.
Episode Terkait
1 Apr 2025
Ngobrolin Lebaran
Episode ini adalah ucapan Selamat Idul Fitri dari tim Ngobrolin WEB. Eka, Ivan, dan Rizah memberikan salam Lebaran denga...
10 Jul 2024
Ngobrolin State of JavaScript
Episode ini membahas hasil State of JavaScript 2023 survey yang baru dirilis, memberikan gambaran komprehensif tentang l...
20 Mar 2024
Ngobrolin Ekosistem Vue
Episode Ngobrolin ini menghadirkan Warad Wong Maneki, seorang Google Developer Expert (GDE) untuk Web dari Thailand yang...
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 .