Lompat ke konten utama
EP 33

Ngobrolin Google IO Lebih Dalam

Ringkasan Episode

Bantu Koreksi

Melanjutkan rangkuman umum minggu sebelumnya, episode ini memilih beberapa topik dari Google I/O untuk dibedah lebih dalam. Yang pertama soal masuk tanpa kata sandi. Titik berangkatnya keluhan yang semua orang kenali: setiap layanan meminta kata sandi, dan konsekuensinya kita memakai kata sandi yang sama di mana-mana. Web authentication API menawarkan jalan lain — memakai sidik jari, wajah, atau kunci fisik langsung dari browser, dengan kunci rahasianya tetap tinggal di perangkat dan hanya kunci publiknya yang dikirim ke server. Dua hal membuatnya menarik. Pertama, karena kredensialnya terikat pada domain tempat ia didaftarkan, situs tiruan yang dibuat semirip mungkin tidak akan mengenali akun kita — jadi ia sekaligus penangkal penipuan lewat situs palsu. Kedua, karena tidak ada kata sandi yang disimpan di server, tidak ada yang bisa ditebak paksa maupun bocor. Alurnya sendiri hanya dua fungsi: mendaftar dan mengambil. Karena bentuknya standar, perangkat keras jenis baru bisa langsung terpakai tanpa menulis kode berbeda. Topik kedua soal WebAssembly, yang sempat terasa senyap padahal adopsinya justru besar di produk-produk berat: perangkat desain, penyunting gambar, sampai permainan yang dulu mustahil hidup di browser. Nilainya bagi mereka adalah tidak perlu menulis ulang basis kode raksasa demi bisa jalan di web. Alasan perkembangannya sempat tersendat pun terjawab: versi awalnya belum mendukung bahasa yang punya pengelola memori otomatis, dan itulah yang dibuka di versi berikutnya. Dampaknya beruntun — basis data, pengolah video, sampai mesin permainan kini bisa berjalan langsung di sisi pengunjung tanpa perjalanan ke server.

Poin-poin Utama

  • Masuk tanpa kata sandi bekerja dengan menyimpan kunci rahasia di perangkat dan hanya mengirim kunci publik ke server — jadi tidak ada kata sandi yang bisa bocor atau ditebak paksa
  • Kredensialnya terikat pada domain tempat ia didaftarkan, sehingga situs tiruan semirip apa pun tidak akan mengenali akun kita — sekaligus jadi penangkal penipuan lewat situs palsu
  • Alurnya hanya dua fungsi, mendaftar dan mengambil, dan karena bentuknya standar, perangkat keras jenis baru langsung terpakai tanpa menulis kode berbeda
  • Ia bukan pengganti pengiriman data yang aman — untuk mengirim data ke server tetap perlu mekanismenya sendiri, karena lingkupnya hanya mengesahkan siapa penggunanya
  • WebAssembly terasa senyap tapi adopsinya justru besar di produk berat, karena nilainya adalah tidak perlu menulis ulang basis kode raksasa demi bisa jalan di web
  • Perkembangannya sempat tersendat karena versi awal belum mendukung bahasa yang punya pengelola memori otomatis — itulah yang dibuka di versi berikutnya
  • Dampaknya beruntun: basis data, pengolah video, sampai mesin permainan kini bisa berjalan langsung di sisi pengunjung tanpa perjalanan ke server

[menggantung]

Halo, halo, halo, selamat malam.

Halo, selamat malam, selamat hari selasa.

Selamat hari selasa, karena hari selasa waktunya...

Waktunya, ngobrolin web.

Ya.

Semuanya lagi, seperti biasa, dari grup yang tidak pernah kompak ini.

Triwebweb.

Triwebweb.

Triwebweb.

Selamat malam.

Kita butuh kayaknya biar asik.

Kan kalau kita punya meja itu,

kakinya nggak boleh tiga, harus empat, biar stabil.

Kita kan bukan meja.

Lipat kan tiga?

Oh iya.

Larutan, Cok, kaki tiga.

Oh iya juga ya.

Gak apa-apa, banyakin aja.

Empat boleh, berlima juga boleh, kan ada kaki lima.

Simpang lima ya ada.

Simpang lima.

Malam hari ini, kembali lagi bersama kita bertiga.

Ada saya Riza, ada Irfan, dan juga ada Eka.

Kita tiga dari sekian banyak GDE di Indonesia,

dan kita hanya tiga dari tiga GDE web ini.

Tiga gimana sih?

Masih tiga belum nambah.

Tahu yang di bidang lain banyak.

Lihat transkrip lengkap (2180 segmen lagi)

Ada yang cloud, ada yang Android, ada apa lagi ya Flutter?

Ada nggak sih?

Flutter ada, Firebase ada, Machine Learning.

Ada nggak sih, Machine Learning?

Ada ya?

Ada.

Machine Learning sempat ada, tapi udah pindah aja.

Masa nya nggak di Indonesia lagi.

Iya.

Flutter juga pindah.

Iya, Flutter.

Cloud juga pindah negara.

Ada yang pindah.

Nyindir Mas Imre.

Tapi nanti pulang lagi.

Terus tiba-tiba nongol tadi komennya.

Oh iya benar.

Bukan, Mas Danang yang ngabis.

Kalau kita nyengkut Mas Danang biasanya biar nonton.

Iya.

Siapa lagi ya?

Kita sambil nunggu sambil cek sound juga.

Takut terjadi hal-hal yang tidak dinginkan.

Jadi kalau misalkan ada masalah dengan visual ataupun dengan audio,

tolong kita di info.

Ada disini sudah hadir Audi.

Ada Mas Audi.

Rajin banget tuh komennya gini pas 8.00.

Ini dia pakai Kron.

Tepat sekali jam 8.

Tadi tadi telat ya.

Telat mencet live-nya.

Ada lagi tuh.

Ada Rahul.

Ada Abdul Malik.

Halo-halo semuanya.

Selamat malam.

Jadi hari ini kita lanjut lagi.

Kita kemarin sudah overview secara umum.

Dari sebesar di Google I/O kita ngomongin apa.

Yang adalah AI.

AI, AI, dan AI.

Iya, ada hari juga.

Dari depo, mantap.

Terus malam ini kita akan coba cari satu topik yang menarik.

Dari bidang web khususnya.

Kalau yang episode lalu kan yang general secara umum.

Tidak, web juga sih.

Ada web, ada cloud, ada AI.

Oh iya, sebagiannya.

Ada itu apa namanya? Tailwind.

Iya, project Tailwind.

Tailwind yang bukan CSS.

Tailwind yang bukan CSS.

Aduh, itu gimana ya kabarnya ya?

Sayang banget.

Tailwind, dia nggak trademark kali ya?

Kan kita pahas minggu lalu.

Jangan-jangan, mungkin yang di trademark Tailwind Labs

atau apa Tailwind CSS.

Nah Tailwindnya doang nggak dipatenin kali.

Bisa jadi.

Anyway, malam hari ini kita akan coba

dari kita bertiga coba pick satu topik

yang menurut kita menarik.

Terus kita akan bahas.

Teman-teman juga kalau ada topik-topik yang menurut teman-teman menarik

boleh ya di komen juga.

Siapa tahu kita bisa belajar bareng-bareng juga.

Oke, kita mulai dari mana nih?

Siapa duluan ayo.

Punya siapa?

Siapa duluan, betul.

Punya siapa.

Kalau gue juga bisa.

Karena simple.

Simple-simple gimana gitu.

Simple tapi penting ini.

Simple pasti semua web developer

pasti pernah kena.

Atau akan kena kebutuhan ini.

Jadi gue share screen aja kali ya.

Boleh.

Karena kalau kita disuruh bikin dari awal kan malas ya.

Jadi dari awal kan mendingan pakai yang udah ada aja.

Apalagi bisa pakai biometrik gitu.

Wah, itu

apa namanya.

Developer experience-nya meningkat sekali ya.

Jadi top pertama ini

tentang password

authentication ya.

Gue suka entire screen aja deh

biar gampang hidupnya.

Udah.

Udah bisa liat kan ya.

Masukin dulu.

Belum.

Masukin lagi.

Lebih kecil kemarin apa sekarang?

Kayaknya stream pertama juga

sentiment sama Mas Riz.

Lanjut lah.

Oke.

Sudah

masuk kan ya?

Oke, jadi

minggu lalu sempat ya kita

bahas mengenai apa itu

web authentication API

atau disingkatnya web

autent. Oh ya, dan sebelumnya

apa authentication kan dulu kita punya

episode khusus ya. Jadi kalau pengen

buat yang bingung kenapa banyak

kita sering nyebut-nyebut kata

authentication out itu apa?

Nah, bisa revisit episode itu tuh.

Ya, lanjut.

Oke, jadi

kebayang gak sih ya?

Sekarang dunia

sekarang itu apa-apa perlu password?

Apa-apa perlu password kan? Jadi misalnya

kita mau order pizza

aja atau mau

yang ada

aplikasi webnya gitu ya.

Jadi sebentar-sebentar kita disuruh bikin password.

Jadi passwordnya kalau dibikin

sama semua

salah juga ya, karena

1-2-3-4

kayak password saya

gitu ya, event 1-2-3-4 gitu ya.

Banyak di mana-mana gitu ya.

Di WordPress lah, di

PHD lah, di mana.

Jadi bahkan

kalau misalnya teman-teman cek

have I been pound gitu ya.

Have I been pound

password gitu.

Mungkin password teman-teman

yang paling sering teman-teman

pakai itu mungkin, saya coba ya

event 1-2-3-4.

Yes, sudah

dipakai 5200 kali.

Masihnya kebanyak gitu ya

event 1-2-3-4.

Nah,

terus kalau misalnya kita

pakai password yang

berbeda-beda, kita generate berbeda-beda

adalah yang bilang tipsnya

pakai

konsep, pakai konsep dulu

pattern gitu, kalau misalnya website-nya apa

passwordnya tinggal diubah dikit-dikit gitu.

Nggak fair ya rasanya

kalau mengingat semua, terus katanya

kenapa nggak pakai password manager aja?

Iya sih, password manager, tapi

password manager kayak

one password,

last pass,

apa tuh yang kalau BitGuardian

yang open source ya.

Bisa

jadi ya, namun

tetap aja kita harus extra effort

setiap website punya password.

Kebayang nggak sih

kalau misalnya dunia tanpa password.

Bisa nggak sih? Passwordless.

Passwordless, kalau mau login ya

login aja gitu, pakai biometris

kan sekarang sudah bisa biometris.

Akunku juga, akunmu,

akunku juga.

Jadi unik.

Bahkan bisa jadi

kita bikin passwordnya itu

passwordless itu per device, tetapi

bisa connect ke account kita yang sama.

Bisa, gitu ya. Nanti bisa

dihubungkan seperti itu contohnya.

Mungkin

bagi temen-temen yang masih kurang

merasa secure

kalau tanpa password, bisa jadi

passwordless ini adalah second authentication.

Misalnya

banyakan ya, kayak

di aplikasi mobile rata-rata ya,

kalau aplikasi bank itu, kita

diminta untuk, pertama

kitanya

login

atau create account, pakai email dan

username, endpoint kah,

OTP kah, dan

kemudian kita login

dan set up password, tetapi

login selanjutnya kita diminta, maukah

aktifkan biometrik, ya kan?

Hal yang sama sudah bisa kita

lakukan di web.

Juga sama seperti itu, jadi

setelah accountnya dibuat, kita

bisa aktifkan

biometrik

atau passwordless login itu

untuk account kita.

Jadi, si

user kita untuk login

selanjutnya, itu nggak perlu

ingat-ingat passwordnya lagi, tinggal pakai biometriknya

dia, antara face

detection, retina

detection, si fingerprint,

kalau di Mac itu

iOS dia ada fingerprint,

kalau di Android dia bisa fingerprint di

layar, kalau di

iPhone, apa,

not just iPhone, iOS lah ya,

itu bisa pakai

face, kalau punya

jantangan, keren-keren bisa

pakai, autentik bisa pakai jantangan,

kalau punya YubiKey,

juga bisa pakai YubiKey.

Jadi, bermacam-macam, dan itu

sudah bisa, ada layer yang

bisa diaktifkan melalui web

authentication API ini. Jadi

web authentication API ini sudah bisa menstandarisasi

semua authentication

yang menggunakan

either itu pakai

hardware, atau

OS-based.

Nah,

web authentication API ini

dibuat

sudah lama sebenarnya, dan sudah

standar, dan sudah

diadopsi, hampir semua.

Saya sebelum asal

ngomong, sudah semua

browser kecuali Android

yang WebView, ya.

Sudah,

jadi, sudah

yang public key kredensial

ini yang penting ya, jadi dia pakai

response dan public key, ya.

Sudah semua browser, support.

Ya, tentunya.

Apa, tanya, tanya

karena lagi browser support nih,

karena udah berbentuk standar nih ya,

jadi kan, ini apa,

bisa semacam future-proof

kan, kedepannya misalnya,

kan sekarang cuma device iOS nih,

yang punya face recognition misalnya.

Kalau besok Android, misalnya Samsung,

atau siapa lah, Google Pixel,

atau siapapun bikin face recognition,

langsung bisa

nyambung ke sini kan ya, jadi

nggak perlu, apa, karena

udah standar, nggak perlu

bikin kode beda lagi, buat pakai

face recognition khusus Android,

smartwatch, dan lain-lain,

keunggulannya standar itu ya.

Iya. Jadi,

dari aplikasi kita sendiri,

kita hanya cukup pakai web authentication API,

atau library yang

encapsulasi ini,

web auton ini,

jadi bisa pakai,

besok-besok ada UBI key yang jenis baru,

ada Google Titan key,

ada misalnya nanti Microsoft,

whatever, ya.

Tetap menggunakan

authentication standar yang sama.

Oke. Nah,

cara kerjanya dulu deh, sebelum

saya masuk ke metode-nya, karena simple banget.

Cara kerjanya dulu gimana sih?

Ini contohnya ya, ya bisa temen-temen

buka di webauton.io,

jadi, pertama kali,

misalnya saya,

saya sudah

ada tadi, coba EAA,

pakai touch ID, misalnya saya mau

bikin user baru,

ngobrolin web,

saya register,

saya register,

saya ditanya mau pakai

phone atau tablet, built-in sensor,

atau USB security kayak gini.

Saya,

karena nggak pasang, pakai

built-in sensor aja lah ya,

sudah ada di ini,

di laptop,

saya continue,

terus saya, sidik jari,

saya di Mac.

Dan, sudah

selesai, saya sudah

terregister sebagai account di sini.

Nah, saya mau authenticate,

saya tinggal klik, si

browser-nya sudah tahu, oh, lo

udah pernah login, pakai ngobrolin web,

user ini, continue.

Terus, saya

tinggal sidik jari lagi,

test, you are a login.

Jadi, semudah itu,

untuk bisa

register. Nah,

nanti credential-nya bentunya kayak gini, dan

bisa, tentunya, time to live-nya

berapa lama login, itu sudah terserah session

temen-temen ya, intinya,

dari si, dari si web

authent ini, dia

bisa create,

challenge-nya, bahasanya, hashing

challenge-nya itu, kirimkan ke server,

nanti server simpan

public key,

yang sudah di generate,

dan nanti,

ada challenge yang dikirimkan,

dan nanti event selanjutnya,

jelaskan.

Itu cara kerjanya. / Jadi, itu semacam public key ya,

yang credential yang dilayakkan?

Betul. / Private-nya yang

di device yang kita pakai buat?

Ini ID, public key-nya nggak kelihatan.

Private key-nya apa lagi?

Private key-nya udah di sini.

Private key yang di device kan?

Hasil hashing ini,

dan waktu. Nah,

keuntungan selanjutnya,

ini, ada protection

yang untuk phishing, ya,

phishing website.

Jadi, kalau misalnya, tentu,

teman-teman tahu ya,

bukan phishing, phishing.

Phishing. / Phishing.

Jadi,

kenapa bisa jadi pencegah

dari phishing? Karena, untuk bisa

generate, yang tadi, yang proses register

yang saya lakukan tadi, itu

terregistrasi hanya antara

saat generate

public key-nya tadi,

itu ada host-nya,

dan

user ID-nya,

dan biometrik-nya, dan private key-nya.

Bahasanya di hash, dan

dikirimkan ke server.

Oke?

Jadi, kalau misalnya, ada sengaja

yang bikin WebAuthn.EOX misalnya,

terus dikirim ke teman-teman.

Semuanya persis sama.

Terus, teman-teman mencoba login dengan

pakai WebAuthn yang sama,

nggak akan terregister.

Jadi, saat diauthenticate begini,

si browser nggak akan detect ini,

ada EAA dan ngobrolin web, nggak akan detect.

Ngerti ya? / Karena per domain dia?

Karena dia sudah terregister

per domain, betul.

Nggak bisa pindah ke domain lain.

Jadi, kalau misalnya sengaja domain-nya dibuat

mirip-mirip,

nggak akan bisa, karena si browser

tidak akan mendeteksi itu.

Jadi, oh,

saya mesennya teman-teman langsung,

"Oh, kok nggak ada ya akun gue to speaks-nya?"

Oh, ternyata bukan website yang sama.

Itu

keuntungannya

menggunakan WebAuthn.

Lalu,

ini juga,

tentunya karena kita,

password-nya sendiri

tidak ada disimpan di server.

Yang disimpan cuma user ID dan public key.

Untuk generate

challenge-nya nanti.

Jadi, nggak ada password, kan?

Apa yang mau di brute force,

nggak bisa di brute force, gitu.

Kecuali HP kita dijam red.

Eh nggak, tetap nggak bisa.

Kan fingerprint-nya, jari kita

nggak dijam red juga. / Yang bisa itu

zaman dulu itu adalah

si bapaknya tidur, si anaknya

pakai handphone-nya, terus dipempelin

jarinya. Kayak gitu tuh, biasanya.

Bisanya, gitu.

Itu pernah ceritanya seperti itu.

Nah, untuk

menggunakan WebAuthn ini, hanya ada

kedua fungsinya.

Pertama, create.

Dan kedua, get.

That's it. Jadi create itu

akan mengirimkan nanti public key.

Ininya

jangan merasa

terintimidasi

dengan hashing-hashing ini.

Jadi, hanya akan kirimkan

nanti ada challenge ini random.

Random number.

Terus kemudian relay party

ini ada nanti namanya.

Inilah domain-nya nanti yang temen-temen

gunakan. Jadi, ini yang tidak bisa direba.

Terus kemudian

ID ini adalah random.

Jadi, generate aja random ID.

Secara di lokal,

di JavaScript lokal.

Dan kasih tahu itu namanya siapa,

display namanya siapa. Mungkin kalau

nggak perlu bawa email ya. Nggak perlu hashing email,

nggak perlu. ID ini benar-benar

nggak ada berhubungan dengan

user identification.

Jadi, ID dari si

maksudnya

tidak ada hashing dari email,

nggak ada hashing dari password, nggak ada.

Jadi, benar-benar mau generate random juga boleh.

Lalu,

nanti akan kasih tahu jenis

credential-nya bentuknya

public key. Dan nanti ada

kalau untuk algoritmanya, saya

kurang begitu paham kenapa minus digit,

tetapi ini ada list-nya

bentuk algoritma apa yang mau digunakan.

Karena ini harus sesuai dengan apa yang

kita terapkan di server.

Terus,

setelah

ini di-invoke,

create begini, itu akan

menginvoke ini sebenarnya.

Menginvoke

si ini.

That's it. Dia akan menginvoke

ini. Dan begitu saya

masukin

apa namanya,

biometriknya, dia akan generate

yang namanya

hash itu

dan public key, akan

itu yang dikirimkan ke server.

Bisa

nanti

si passwordless.id ini yang bisa

menjelaskan lebih enak.

Jadi, pertama si user,

dia bilang saya mau register

sama si server. Send me

the public key, terus dia request biometrik.

Nanti akan request

yang create tadi,

di-invoke oleh JavaScript,

request biometrik,

terus, dia akan dibuat

key pairnya, private key

sama public key, private keynya

disimpan di browser, dan

send public keynya,

dan si server bilang kasih tahu

sudah terregister.

Seperti itu aja. Lalu,

saat authentication,

dia klik login,

nanti si server,

si server

akan kirimkan challenge, bentuknya

biasanya nonce. Nonce itu

bahasa ini, apa ya, nonce itu.

Nonce.

Apa? Ada artinya apa?

Terjemahannya apa?

Yang cuma bisa dipakai satu kali,

apa itu bahasanya?

Dicari beneran.

Nggak ada, salah.

Rapis.

Definisinya ekstrem.

And once, kan?

And once.

And once, kayaknya ya.

Jadi, cuma

bisa dipakai satu kali,

untuk dipakai,

dan nonce itu yang dipakai untuk challenge,

untuk create, untuk

menginvoke yang namanya

ini, get.

Ini. Nanti akan di,

karena tadi si

RP tadi, relay party-nya

sudah tahu, host-nya,

terus kemudian degenerate ulang,

si challenge-nya itu,

kembali lagi,

challenge-nya itu adalah random,

nanti akan menginvoke yang namanya

si

webaltern

screen tadi. Lalu,

hasil,

hasil challenge-nya itu,

yang desain pakai private key,

dikirim.

Nanti di-verify

signature, pakai public key yang

sudah kita kirimkan tadi saat register.

Ini.

Kalau match,

berarti, dia,

bentar ya.

Mau ikut live itu? Iya, mau ikut live dia.

Bentar ya.

Nah.

Iya. Jadi, si,

apa namanya?

Si,

setelah public key-nya di-verify,

tentu, si user-nya

tetap authenticate, dan,

selanjutnya,

proses selanjutnya, ya itu, session,

terus kemudian,

redirect,

itu sudah sama seperti tanpa password.

Ya, seperti pakai password, maksudnya.

Seperti pakai password. Ya.

Ada informasi yang disimpan di database nggak, atau di back-end?

Ada. Itu kan tadi yang

ada user ID. User ID, ya.

User ID yang di-generate tadi,

ini kan ada user ID, ya.

Yang unik, ya? Yang unik, ya. Betul.

Jadi, user ID itu yang benar-benar unik,

panjang, ya. Ini,

area 8,

bahkan, nggak berbentuk, ya.

Jadi, nggak berbentuk. Jadi, user ID ini,

kayak UUID gitu ya, modelnya, ya.

Iya, betul. UUID.

Nah, ini disimpan juga di,

sama, dia ada di

si browser juga.

Nah.

Setelah,

apa namanya?

Setelah,

jadi lupakan.

Oke.

Login, play direct, session,

seperti biasa.

Sudah bukan ranahnya WebAuthn lagi.

Nah.

Untuk guide-guide-nya,

ada banyak, ya.

Misalnya, WebAuthn.Guy juga, teman-teman.

Itu tadi yang saya ceritakan,

garis besarnya. Tentunya, masih ada

advanced settings-nya.

Seperti user verification.

Saya juga bahkan, nggak,

nggak paham semuanya. Ini,

bisa dieksplore satu-satu.

Dan,

untuk

menyesuaikan dengan

apa yang ada di server side.

Tentu, butuh ada juga server side.

Nah, untuk mempermudah,

saya, dari si WebAuthn.io-nya sendiri,

itu,

ada beberapa library

yang sudah siap digunakan.

Contohnya, dari

Python, Go, TypeScript,

Ruby, Java, segala macem, sudah ada.

Sayangnya, PHP belum ada, saya nggak tahu.

Jadi,

yang paling saya,

mudah saya mengerti,

saat menggunakannya itu, adalah si

Passwordless.id.

Nah.

Yang ini.

Sama tadi, kalau misalnya kita ke demo-nya tadi,

kalau saya register,

AAA,

Use Roaming Authenticator,

seperti,

phone, USB key, ada jadi

Roaming Authenticator, atau

OSR Authenticator.

Jadi, saya sudah ada AAA, continue,

saya create,

register, ini credential ID

saya, ini public key-nya,

algorithm untuk generate-nya ini.

Si,

nah.

Jadi, kalau saya Authenticator,

saya pakai

yang AAA tadi,

tadaa!

Signature saya ini.

Jadi, si

demo, apa, si library ini

sudah memudah,

sudah nge-wrapping si WebAuthent API

dengan

membuatnya lebih mudah lagi.

API-nya enak ya,

kayak user friendly,

tinggal plug and play.

Dan punya server-side-nya juga.

Kan, tadi kan,

kalau si WebID kan tidak punya server-side-nya,

hanya client-side-nya saja.

Ini bisa denote ya, dijalani denote server,

atau semacamnya.

Jadi, ini klien-nya,

sama,

si challenge-nya ini sama dengan WebAuthent.

Jadi, cuma kayak wrapper saja ya,

membungkus saja, yang dikirimkan

itu ini, ada ID, public key,

dan algorithm, dan

verify untuk server-side-nya, dia sudah siapin.

Jadi,

kalau mau

apa namanya,

kalau mau pakai,

saya lagi dalam,

lagi coba kulik-kulik ini,

saya berarti tinggal pakai.

Selanjutnya, untuk

memudahkan

teman-teman untuk lebih,

ini lagi, ada dari

Google Code Lab, silahkan.

Nanti tolong di-share aja ini.

Bisa untuk setup

satu-satu, untuk

benar-benar, go through one by one,

bagaimana setup WebAuthent

sendiri, pakai WebAuthent.

Sebenarnya, nanti, nanti kalau sudah pakai

apa tadi, passwordless.id kan,

udah nggak perlu, kita nggak perlu manual

bikin ini, tapi ya, seperti biasa

kita rekomendasiin, selalu

harus tahu cara kerjanya, abis itu

ya mau pakai library tambahan ya,

bebas.

Tapi ini client-side-only ya?

Iya, ini client-side-only

untuk sampai dia, ya

sampai dia generate, karena dia

pakai, dia pakai ini,

di, sudah

ada di, dia

sudah siapin live-side-nya, jadi tinggal

kita pakai yang pakai punya kita

gitu. Silahkan

coba, dan

kasih tahu bagaimana hasilnya.

Sebelum menggunakan

library lain, pakailah dulu.

Aslinya, basic-nya.

Kalau sudah mengerti, barulah

pakai library. Vanilla.

Vanilla.

Ini ada pertanyaan dari Robi nih,

apakah teknik ini sudah umum

digunakan seperti JWT?

Seperti apa? JWT.

JWT kan

format ya sebetulnya.

Iya, JWT itu kan format

format untuk

mengirimkan data aja kan sebenarnya.

Kalau flow-nya,

mungkin yang dimaksud flow

semacam oout gitu kali ya, yang

dimana kita menerima,

kita terima akses token

dalam format itu encoding-nya

JWT.

Nggak sih, dia nggak ada hubungan

sama JWT,

atau format seperti ini.

Kalau untuk

karena completely different thing ya,

karena JWT ini kan

mengirimkan data dan

dia tetap ada

yang namanya sign key ya,

yang di sign, ini kan sign flag-nya ya.

Ini mengencode

data apapun, tapi dengan

standar encoding yang sudah

disepakati, ada varian

algorithmanya, terus ada key

itu,

waktunya dan key-nya kan,

untuk dicocokin sama

yang menerima mengkonsumsi.

Kalau menurut

saya, JWT itu untuk

sending encrypted

data

ke server

dan memastikan data itu

valid

dari si pengirim yang

sah, ya udah pasti

valid lah ya, si pengirim yang

sah gitu ya, karena sudah

di sign. Pengirim dan penerima

dari pihak yang expected, karena

apa, sama-sama

tahu, ngecek, diverify

dengan key yang sama.

Public dan private key, jadi private key

nggak pernah, jadi bisa diverified

pakai private key yang ada di server.

Sedangkan kalau WebAutoN, apakah

itu dengan

saya merasa

mirip serupa tapi tak sama ya?

Kalau WebAutoN

semacam antara service dengan device

si user ya, apa

koneksinya lebih ke itu kan,

antara silayanan

dengan device

fisik yang diakses oleh user.

Bukan, karena dia bukan untuk

authentication data, dia

hanya untuk authenticate

user.

Dia tidak mengautenticate data

yang bukan data user.

Apa isi lah maksudnya ya.

Hanya untuk

authenticate login itu, login dan

identifikasi aja.

Untuk keamanan

selanjutnya untuk misalnya

kita buat sebuah web application

loginnya pakai WebAutoN

WebAutoN

tentunya

selanjutnya, temen-temen

kalau misalnya aplikasinya mau kirim

data ke server, tetap harus pakai

kalau memilihnya pakai JWT

formatnya, tetap harus pakai JWT.

Gak ada hubungannya.

Dan

banyak ya, Okta kayak

Outzero itu sudah support WebAutoN.

Sudah pakai.

Tapi belum umum kan,

karena memang masih baru juga kan.

Belum banyak yang pakai juga.

Ya, semoga habis

nonton ngobrolin web jadi

umum di Indonesia.

Karena semua pada nyoba.

Ya, ini

butuh banget. Apalagi

kalau misalkan temen-temen bikin aplikasi

baru, service baru,

bikin produk baru, terus butuh login.

Login yang paling gampang

apa sih sekarang? Kayaknya

kirim ini ya, kode

ada 4 angka lah, atau

pakai magic link.

Ya, jadi

harus buka email, terus

diklik, abis itu kita baru masuk.

Kalau misalkan kita buka di desktop, kita harus buka

emailnya di desktop. Kalau di mobile

kita harus buka email. Mahal lagi, maksudnya

makin banyak. Mungkin kalau untuk pertama

pas create pertama, ok lah,

itu nggak apa-apa. Tapi kalau setiap kali

login, kirim SMS,

tagehannya

lumayan.

Atau sebelum

era itu, mungkin ada

yang tadi oout, pakai

login with Github,

login with Facebook, login with

Google, gitu kan. Cuman

itu datanya ada di masing-masing provider

kan, gitu. Kita nggak pegang datanya.

Nah, kalau yang ini

lebih menyederhanakan

karena, ya

apa, di device kita sudah cukup

canggih, sudah ada alatnya, untuk

mengidentifikasi bahwa kita benar-benar

user itu. Betul user

yang enak sih.

Ya, mungkin di combine ya, bisa

tergantung kebutuhannya. Mungkin

oout buat create account,

terus habis itu bisa di combine web

outen pas login selanjutnya, kan.

Pas login, ya. Betul.

Kalau misalkan produknya

di web nih kan,

di web udah pakai web outen,

terus produknya berkembang,

ada aplikasi mobile, itu

gimana tuh?

Di native ada kan ya?

Di native kan sudah ada untuk

outen authentication ini sudah ada.

Kayak yang saya katakan tadi,

misalnya bisa juga kita buat

registration-nya itu

per device juga bisa, dan satu account.

Itu juga bisa.

Jadi, tinggal kita maininnya

di data, ibaratnya

relation antara user dan

outen ID nya tadi, kan bisa banyak.

Jadi, mau itu

danti dari device yang Android,

ya sama, bisa

pakai outennya si

jalur authenticationnya si Android

dan standardnya itu,

kalau di web,

juga punya standardnya itu, sama.

Jadi, tetap masukin satu account-nya sama.

Itu kan tinggal sisi server ya.

Tidak

tergantung sama web outen

rpi.

Jadi, scope-nya hanya

sampai generate public key dan ID,

waktu register, dia tinggal

katakan, ini public key-nya

saya, ini ID-nya saya. That's it.

Simpanlah.

Oke.

Untuk topik

web outen,

sudah cukup dulu.

Nanti kita bisa lanjut lagi diskusi, kalau

teman-teman punya pertanyaan, boleh

silakan langsung di kolom chat ya.

Berikutnya, kita akan bahas tentang

topik kedua, yaitu

WebAssembly.

WebAssembly ini kan,

kemarin kita sudah sempat bahas juga sedikit.

Yang menarik

adalah mereka menyebut bahwa, ini

WebAssembly versi berikutnya adalah versi 2.

Karena sebelumnya itu

sebutannya versi 1 ya. Kita juga nggak tahu nih.

Yang kita bahas minggu lalu ya.

Iya, hampir sama kayak

CSS3,

HTML5 itu kayaknya batasannya

seberapa sih, gitu. Kita kayak nggak,

agak ngeblur kan. Beda sama versi.

Tom 90-an kali itu.

Siapa yang pernah bikin,

pernah nulis CSS2, coba.

Ada yang pernah HTML3, HTML3?

Kan bingung kan. HTML3 itu

seberapa? HTML4 sih, kayak lupa-lupa

ingat. Itu jamannya Flash, kayaknya.

Masih.

Jadi,

ada beberapa hal yang baru, makanya

mereka menyebut ini versi yang

major version lah, gitu ya.

Kira-kira. Kan,

di WebAssembly ini agak-agak

tenggelam ya. Sempat nge-hype,

terus tiba-tiba hilang. Ini kabarnya

kok hilang, gitu.

Kayak nggak ada

kelanjutannya. Padahal,

adopsinya yang

nggak bisa dibilang banyak. Adopsinya major.

Major sih sebenarnya.

Nggak banyak, tapi

signifikan. Kayak misalnya, apalah Sigma,

gitu. Teknologi yang dipake banyak orang, terus

Adobe Cloud kan hampir semua

pakai Wasm ya, kalau nggak salah.

Terus, apa lagi ya? Nggak tahu pokoknya, apa,

itu breakthrough banget dalam

CS. Counter-Strike.

Counter-Strike yang ramai. Oh, ya ampun.

Counter-Strike

ada webnya, gitu.

Ada yang bukan yang CS2 ya. Webwrapper.

Yang lama.

Counter-Strike yang bukan yang pertama. Kayak, itu kan breakthrough

dalam hal teknologi web ya, tapi

dari, ya, otomatis dari kuantitas

nggak bisa terlalu banyak lah.

Seberapa banyak orang yang punya

produk sekompleks

itu? Ya, jadi

salah satu yang breakthrough juga, misalkan

contohnya tadi ya, Photoshop.

Tiba-tiba dia ada yang cloud.

Coba bayangin kalau teman-teman berada di perusahaan

itu harus bersaing dengan Sigma

yang akhirnya dibeli juga sih sama

Adobe kan. Tapi katakanlah

dia nggak beli, gitu. Dia nggak beli.

Dia mau bikin yang online seperti Sigma.

Harus rewrite. Harus tulis

ulang dengan JavaScript.

Kan susahnya setengah mati.

Auto-cat juga sama.

Ada codebase yang sudah cukup besar.

Yang legacy, yang udah nggak bisa diapa-apain.

Terus ini kita mau ke web, tapi

nggak bisa, gitu.

Web assembly-nya adalah salah satu jawabannya.

Jadi, salah satu contoh suksesnya ya.

Itu auto-cat.

Mereka sekarang udah bisa di web.

Photoshop juga sudah bisa di web.

Google Earth, kalau dulu

hanya ada desktop, sekarang sudah bisa diakses

di browser juga.

Jadi itu

breakthrough-nya lumayan, tapi

kabarnya memang tidak se-

wah, framework atau library

yang lagi

hype, gitu ya. Jadi

highlight-nya apa? Highlight-nya adalah

kalau versi satu

yang dulu, kenapa yang dulu itu

kayaknya perkembangannya gitu-gitu aja?

Ternyata, setelah saya

nonton videonya, saya baru tahu ternyata

versi satu itu, mereka

belum terlalu

mendukung bahasa-bahasa

yang garbage collected.

Yang ada garbage collected-nya.

Makanya, bahasa yang

harus digunakan adalah bahasa yang

tidak menggunakan garbage collected.

Intinya C, C++,

RAS, bahkan goleng aja itu

ada garbage collected-nya.

Di versi kedua ini,

mereka sudah mendukung namanya

web assembly GC.

Nah, gara-gara ada

si

garbage collector,

fitur garbage collector

ini. Jadi, ada membuka

peluang bahasa-bahasa lain

juga berkembang sama halnya

seperti RAS, C++, dan lain-lain

di ranah web assembly.

Ini ada contoh beberapa

library yang

jadi highlight-nya. Jadi, ada

SQLite yang sudah bisa dibawa ke ranah web assembly.

Baru tahu, SQLite atau pakai

web assembly ya? Web assembly-based?

Enggak. Sebelumnya kan dia

back-end kan. Ya,

executable biasalah pakai C atau C++.

Nah, ini ada port-nya.

Dan itu

apa namanya?

Official. Jadi, di website

SQLite itu mendukung web assembly.

Jadi, kita bisa punya

apa? Yang kayak waktu itu kita sempat

ngomong kan? Di browser kita ada

SQLite. Ada

WordPress juga. Benar.

WordPress dibuat Wasm dan jalannya

pakai SQLite instead of

MySQL.

Jadi, nggak perlu back-end.

Kita di klien aja

udah bisa

database yang

istilahnya

fiturnya udah cukup mumpuni

dibandingkan

database RDBMS

lain. SQLite, walaupun

kecil, tapi udah cukup mumpuni. Kemudian

ada FFmpeg. FFmpeg ini

adalah

ini tools

yang sangat powerful yang

hanya jalan di CLI.

Linux ya, terutama ya.

Jadi, ini adalah CLI tools.

Kalau misalkan kita mau convert

dari

apa? Dari format apapun ke format

apapun, dia bisa. Bahkan katanya

saya belum nyoba sih, kabarnya

dia bahkan bisa mendeteksi

kalau misalkan kita mau edit video nih.

Ada video yang ada

silent-nya. Itu bisa di

potongan.

Karena dia mengakses

low-level itu banget ya.

Mengakses dari low-level yang beneran stream

kalau misalnya

audio-video itu kan

ada format pieces-nya sendiri.

Ada stream-nya. Nah, dia beneran

bisa mengakses semua stream itu.

FFmpeg ini

kayak, tau gak sih,

tools yang serba bisa

untuk video. Betul.

Video, audio, dan

gambar juga. Karena saya

pernah terbantu sekali.

Tau gak saya yang pernah buat

coin detection untuk

pakai AI, machine learning.

Jadi, untuk

mengumpulkan data

coin itu,

saya kan gak bisa foto satu-satu, capek

banget ya, fotoin satu-satu.

Jadi, saya rekam pakai video

dari berbagai macam

angle, terus saya rekam juga

dari background-nya

beda, gitu ya. Nanti pakai

FFmpeg ini saya bisa minta

di-slicing gitu, jadi

jadi...

ya, eksport saya minta

per frame, dan

misalnya saya minta per

10 frame, skip per 10

atau 20 frame, dan dia

eksport jadi JPEG.

Nah, dari itu

saya tinggal kategorize dan

training machine learning saya.

Terbantu.

Terbantu. Jadi, FFmpeg ini

hanya berjalan di backend. Jadi, kalau

dulu kita bikin client-nya

mungkin upload, misalkan kita mau

bikin aplikasi untuk convert dari

MP4 ke GIF, misalkan, atau

ke AFIF, misalkan.

Kayaknya streaming pakai ini juga ya?

Ya, kayaknya. Streaming juga bisa. FFmpeg juga bisa

live streaming.

Ya, saya pakai

Plex, ya. Jadi,

di server-nya, kalau misalnya

ukuran video-nya

4K, tetapi device

saya mau nontonnya 1080,

dia...

untuk convert.

On the fly.

Kalau proses yang seperti itu,

biasanya ada client-server

sistemnya. Jadi, di client, mungkin kita bikin

upload file, misalkan file MP4

ke AFIF, gitu kan.

MP4-nya kita upload, kemudian data

MP4-nya itu dikirim ke server.

Di server, diproses, di konversi,

jadi AFIF, atau jadi GIF,

atau jadi apa, habis itu,

hasilnya, output-nya akan dikembalikan

ke client. Itu

proses yang dulu dilakukan dengan

FFmpeg yang ada di back-end.

Dengan ada nyawa

WebAssembly, FFmpeg-nya ada di browser.

Jadi, nggak perlu ke server lagi.

Langsung aja di...

di konversi di...

di saat itu juga, gitu. Jadi, itu

luar biasa

cepat dan efisien,

nggak perlu perjalanan

ke server atau ke mana, gitu.

Jadi, teman-teman bisa gunakan, ya.

Kalau teman-teman nggak ngerti, ini FFmpeg

nggak perlu compile dari

misalkan C atau C++.

Tinggal pakai.

Tinggal di-load dengan menggunakan

JavaScript. Bisa menggunakan FFmpeg.

Wasm ini.

Jadi, bisa langsung convert video

tanpa mengirimkan ke server, ya.

Atau slicing

sampling.

Kan, kemarin itu ada heboh

yang Prime Video, kan.

AWS Prime Video yang katanya

dia dari serverless

terus pindah ke monolitik gara-gara

apa? Gara-gara

tagihan bengkak itu, karena FFmpegnya jalan

di serverless dia taro. Server.

Itu nggak boleh.

Harusnya. Karena processnya panjang.

Jadi, dagihannya pasti

gede, gitu. Jadi,

dengan adanya ini, ya udah di client aja.

Nggak perlu pakai server. Kok AWS Prime Video

tetap perlu bayar bill ke AWS, ya?

Itu kan sama-sama.

Satu group. Eh, nggak tahu ya

belakang gimana.

Itu urusan mereka lah.

Berikutnya, TensorFlow.js.

Tadi Ivan juga udah sempat bahas, ya.

TensorFlow.js ini

sebelumnya berjalan di...

Ya...

Jalannya di mana ya?

Itu dulu pakai apa sih?

Ya, di browser. Pakai apa? Pakai thread.

Pakai browser, thread.

Ya, antara Node.js atau di browser, ya.

Salah satu, ya. Nah,

sekarang udah bisa di

WebAssembly aja. Jadi, bisa

mengakses GPU, apalagi udah ada

WebGPU kan.

Itu akan jadi lebih keren lagi.

OpenCV juga mirip, ya.

Ini tadinya hanya bisa di backend.

Harusnya sekarang hampir sama seperti

FFmpeg, sudah bisa

di frontend juga.

OpenCV ini adalah

salah satu library Python untuk

mendeteksi

sesuatu di video, ya.

Nombor objek, gitu ya.

Nah, yang

menurut saya menarik juga ini adalah

Cocos. Cocos ini adalah game engine

yang...

Ya, game library lah.

Kalau kita mau buat game, kalau kita bikin dari awal kan

itu susah ya. Jadi, ada framework-nya

gitu ya. Ini sekarang sudah bisa

dipublish ke web

melalui Wasm.

Tinggal nunggu Unity bikin Wasm.

Ya, Unity juga udah ada. Demo-demonya udah ada.

Unity, terus apa?

Yang satu lagi yang itu

yang...

Musuhnya? Unreal?

Unreal juga sudah mulai.

Sudah mulai.

Jadi, kita bikin game,

bisa di deploy, bisa dipublish

ke mobile mungkin

atau ke desktop, dan juga bisa

ke web. Jadi, hanya berbekal

web browser, dia bisa

langsung dijalankan.

Ya, tentunya...

Ini tuh ada hubungannya sama itu ya, yang kemarin kita

bahas web GPU.

Ada juga?

Terus bisa mengakses.

Itu kan yang kita bahas kemarin,

frame rate segala macem,

nggak kena limit yang standard

rendering dom dari browser thread.

Cuma, berarti bisa kayak gambarnya

animasinya lebih

canggih lagi.

Dia bisa mengakses hal-hal yang low-level.

Jadi, lebih powerful.

Ini

beberapa

library yang menarik.

Nah, yang tadi saya sebutkan

"Gairbase Collector".

Ini proposalnya.

Jadi, sekarang

web assembly ini sudah mencapai

versi MVP, ke level MVP.

Untuk "Gairbase Collector"

language.

Kalau dulu

bisa, tapi

tidak optimal. Sekarang

sudah lebih optimal. Jadi,

bahasa-bahasa yang baru, yang

"Gairbase Collector" itu

muncul. Contohnya, Swift. Sekarang

sudah bisa web assembly.

Oh, Swift bisa jalan di browser.

Baru tahu. Yes.

Sudah ada website-nya juga. Tools-nya

juga sudah lengkap. Jadi, teman-teman yang

punya kemampuan untuk bahasa

pembahaman Swift, sekarang bisa

di compile

ke web assembly. Salah satu

contohnya adalah tools yang

namanya "Good Notes". Ini awalnya

hanya tersedia di IOS.

Sekarang

sudah bisa di Windows, dan juga

sudah akan ada

di web juga. Ini

aplikasi klasik ini dari iPhone, iPad

awal. Ini "Good Notes" sudah ada. Gila.

Sudah belasan tahun. Pakai apa?

Pakai pensil gitu ya.

Pertama kali punya

iPad yang... iPad pertama yang

ada kameranya. iPad 2.

Ada "Good Notes".

Apa? Sampai beli "Good Notes".

Hmm, "Good Notes". Ya.

Ini mereka...

Jadi, mereka mau develop yang Windows, akhirnya mereka

memutuskan untuk pakai yang versi web saja.

Jadi, bisa lebih...

bisa tercapailah semua tujuan

mereka, baik di IOS, Android, ataupun

di desktop

atau di mana, semuanya bisa...

selama ada browser, aman.

Jadi, ini cukup promising ya.

Itu baru

di sisi Swift ya.

Ada dua lagi.

Yang pertama, Dart

juga bisa. Sekarang

mulai bisa ke WebAssembly

dan juga satu lagi, Kotlin.

Nah.

Jadi, bahasa-bahasa yang dynamic

dan garbage collected sudah mulai masuk

dan sudah mulai didukung secara penuh.

PHP.

PHP. PHP bisa.

Sudah bisa kan? Sebenarnya dari versi satu

sudah. Cuman garbage collectornya yang

belum kan. Ada itu PHP

Wasm? Ada, ada, ada. Benar.

Kotlin. Nah, yang Kotlin

saya tunjukin ini deh.

Infonya.

Nah, kalau sebelumnya kan

Kotlin itu

punya yang namanya KMM ya.

Kotlin Multi Platform

M-nya apa?

Modular. Modul.

KMP kali.

Ya, pokoknya Multi Platform

yang bisa ke IOS kan.

Sempat dibahas juga waktu kita

ngobrol sama timnya GDI

Android kan sama SIDIC dan

teman-teman. Jadi,

sekarang ini dibawa lagi

lebih lanjut ke ranah web.

Jadi, Kotlin sekarang sudah bisa

menggunakan

kita bisa menggunakan bahasa

pembangunan Kotlin untuk

dikompilasi ke WebAssembly

dan bisa dieksekusi di web.

Bahkan. Apa kabar?

Flutter dengan begini ceritanya.

Itu, Dart lagi

dibangun, lagi dibangun.

Jadi, kita bisa menggunakan UI

tools yang sama, yaitu

Jetpack Compose yang bisa digunakan di Android.

Oh, bisa pakai Jetpack Compose ya?

Jadi seru ya.

Jadi, mungkin codebase-nya bisa

bisa di-share lebih banyak lagi.

Bukan hanya dari

back-end, tapi dari UI-nya juga.

Jadi, bisa seamless.

Ujung-ujungnya

angle-nya bisa seamless

antara web atau native itu bisa

nggak kelihatan lagi kali ya.

Kayaknya besok-besok perlu featuring

timnya Sidik dan

temen-temen dia.

Kayaknya mesti kita ngobrol lagi nih.

Perkembangan terbaru.

Benar.

Kita bisa ngangkat

topik ini ya.

Ada contohnya demo-nya di videonya,

nanti temen-temen coba liat aja

di videonya, itu ada yang

dari JetBrains

mendemokan dengan

codebase-nya hampir 100%.

Ya, nggak sampai 100%. Mungkin

90 sekian persen sama

dia bisa deploy ke

browser yang tadinya

Android App.

Itu kata Mas Fordita, M-nya mobile.

Kodlin Multiplatform Mobile.

Maaf ya,

maklum kita bukan Android.

Jadi, kita nggak tahu.

M-nya maaf.

Kodlin Multiplatform.

Maaf, kita belum tahu. Kita baru tahu.

Iya,

kalau Jetpack

udah bisa dipakai di iOS, bisa.

Yang pakai KMM tadi, kalau nggak salah.

Benar nggak?

Di koreksi kalau salahnya.

Nah, sekarang udah bisa di web lagi.

Jadi, semakin

seru.

Kalau temen-temen yang tadinya

"Wah, pengen bikin web", tapi

bahasnya terbatas. Biasanya Java,

biasanya Kotlin. Sekarang mungkin sudah

bisa lah dengan menggunakan.

Tapi Java, Kotlin juga bisa

bikin web.

Back-end,

front-end-nya nggak bisa tetap.

Tetap harusnya fast-read.

Oke, topik

Wasm,

sampai di situ. Berikutnya yang

tidak kalah seru.

Baseline. Apa ini Baseline?

Baseline. Nah, ini nih.

Ini hal yang di-announce

pas I/O kemarin.

Nah, ini kalau menurut aku sih

ngelanjutin trend

atau kecenderungan menarik.

Di dua tahun I/O,

dua tahun terakhir.

Jadi, dua sampai tiga tahun terakhir.

Kayak tahun lalu.

Tahun lalu dan tahun sebelumnya

itu kan yang di-announce, yang major itu

Interop. Jadi,

ini hal-hal yang sebetulnya.

Kita pernah punya episode

tentang Interop juga. Jadi, kalau temen-temen

yang belum tahu, belum

hamiliar, ya cari sendiri.

Nah, ini hal-hal yang bukan

web API-nya sendiri. Jadi,

kalau tadi yang kita bahas tuh, ada Wasm,

ada web auto, itu kan

web API. Makin lama,

makin canggih. Oke lah.

Cuma, apa,

gimana biar

mudah diadopsi untuk semua. Karena

browser kan, walaupun I/O itu

hajatannya Google,

browser kan bukan cuma Google Chrome

doang. Realistis lah kita sebagai developer

kan, pengen

situs kita bisa diakses

orang sebanyak mungkin,

termasuk yang pakai browser lain.

Nah, ini kecenderungan menarik bahwa

2-3 tahun terakhir nih I/O

banyak nge-present

proyek-proyek yang merupakan

kerjasama multi-fender, multi-stakeholder.

Nah, kalau dulu sebelumnya kan

Interop, jadi intinya

kayak pada

men-survey developer,

apa sih, feature atau

API apa aja sih yang kalian

bermasalah, pengen

di-streamline dan pengen

di-fix untuk semua browser.

Nah, Interop tuh isinya proyek itu semua.

Kalau baseline, yang baru

di-announce ini, itu

mempermudah developer

untuk mengadopsi

web API yang

kita sering mikir,

ini web API baru atau nggak ya?

Supportnya udah bagus atau

belum ya? Nah kan, nggak semua

developer seseluruh itu

harus membuka kena-use dulu,

nge-check, nge-scrolling semua

browser-nya udah support atau

belum. Kalau misalnya

masih terlalu baru juga kan nggak semua

user kita rajin nge-update versi browser

kan? Nah, si baseline ini

intinya

merupakan

kayak penanda, feature

yang sudah diadopsi di

dua versi browser terakhir.

Kalau nggak salah, dua versi major.

Certifikasi.

Major ya, kalau nggak salah.

Dua versi major terakhir.

Oh nggak, minor, minor.

Minor version dari

eh, major

sorry, major.

Misalnya kalau Chrome ya

112

sama

112-113 misalnya.

Jadi, ini dengan

mudah, kita bisa lihat nih

di MDN misalnya, udah ada

logo baseline. Nah, kita

kan nggak harus nge-scroll. Biasanya kan

sampai bawah tuh, harus nge-scroll sampai

browser compatibility, kita

cek satu-satu udah support

sejakapan, dan yang terbaru

sekarang browser-nya apa, udah nggak perlu

gitu lagi. Jadi, kalau misalnya kita

lihat tanda ini, itu udah

support semua major browser di

dua versi terbaru.

Nah, ini

mempermudah banget buat kita

nge-adopsi

web API baru sih.

Kayak kalau contoh yang umum,

itu coba scroll ke paling bawah.

Ini bahasanya

WebDX, developer

experience. Developer experience.

So, baseline features you can use today.

Coba deh. Ini kan?

Bukan. Paling bawah. Nah,

iya, iya. Nah,

scroll ke bawah dikit.

Scroll ke bawah. Nah,

nah, ini dialog element. Coba deh

kalau misalnya kita tanya ke, kita

yang paling random web developer

kalian udah pakai element dialog

atau belum? Pasti sebagian besar

kemungkinan

entah baru tahu, atau udah tahu.

Cuma, ya maksudnya kan, kayak,

Mas siapa itu? Adam Erjeles.

Kan udah pernah bikin UI challenge

pakai dialog element ini, dan

hasilnya ren, bagus, dan kita nggak usah

install third-party library. Keunggulannya

banyak lah, udah jelas. Aksesibilitas

juga jauh lebih bagus, karena kita

nggak harus, karena itu built-in ya, udah

dikasih dari browser, kita nggak

harus mikir fokus-fokus

atau apa lah, karena itu udah jadi

feature browser. Tapi kan kita

mungkin in real life, kalau mau

pakai itu, alah, jangan-jangan

Safari belum support.

Suusun lah. Suusunnya pasti

sama iOS, sama Apple.

Nah, cuma, iya, itu

contoh aja, tapi... Nggak ada yang suusun sama

Opera Mini gitu?

Kalau Opera Mini mah, nggak bisa

buka apa-apa, udah.

Itu biar user-nya yang introspeksi

sendiri sih, kalau masih

pakai opera Mini.

Nah, ini dengan

waistline ini, kita bisa, oh,

kita bisa sadar, oh, ternyata support-nya udah

oke juga ya. Kita bisa

ya, lumayan pede buat pakai

tanpa terlalu banyak effort.

Terus, kayak misalnya ke bawah lagi dikit,

di CSS juga ada contohnya.

Yang aku pun baru tahu beneran

ini, gara-gara ini, ke bawah.

Transform.

Iya.

Kalau viewport unit sih sebetulnya

udah di-announce justru di I/O

tahun lalu. Cuma, ya itu

lagi-lagi kan kita belum tahu

support-nya udah bagus atau belum.

Yang CSS atas dikit?

Hah? Di atas?

Ini? Fokus?

Mana ya? Transform ada nggak sih?

Tadi transform di bawah.

Ini ini, individual CSS

transform property, bukan?

Nah, itu ini. Oh, iya.

Individual CSS transform.

Jadi, kalau

selama ini kan kita transform dulu.

Apa? Property-nya transform

titik 2, translate,

rotate, segala macem kan, harus

digabung dalam satu property ya.

Nah, ternyata

sekarang itu bisa dipisah.

Bisa translate sendiri,

rotate sendiri, scale sendiri.

Dan ini berguna banget contohnya misalnya

animasi ya.

Apa? Before dan after.

Kita kan cuma pengen ngeganti

translate-nya doang, misalnya. Cuma

mau naikin, misalnya mau apa?

Transition.

Terus, misalnya kita pakai CSS

in.js juga lebih gampang lagi

ngeganti value masing-masing.

Nah, dengan

baseline ini, kita jadi tahu bahwa

oh, ternyata support-nya udah lumayan juga.

Jadi udah cukup aman.

Ya, itu contoh-contohnya.

Baseline ini liatnya di MDN

aja atau kita bisa access

API-nya, atau gimana,

atau bisa di-connect ke IntelliSense,

atau gimana, gitu nggak sih?

Nah, ini kan masih baru nih. Jadi, emang

baseline ini kan project

kayak community, ada community-nya

sendiri. Apa tadi namanya?

WebDX community, atau apa-apanya?

Under W3.

Jadi, ini apa?

Biasalah kayak working group

di bawah W3.

Itu kan ada pihak Google,

Apple, dan lain-lain. Jadi,

kalau yang

konkretnya di web.dev,

misalnya bakal ada

artikel tentang API,

web API tertentu. Jadi, bakal

ada logo baseline-nya. Terus,

di MDN juga

akan ada atau udah ada? Gak tahu.

Coba deh cari aja artikel MDN grid.

Contohnya di MDN.

Tapi, si baseline ini

merupakan bagian dari

project lain yang lebih besar.

Oh, udah ada? Nah,

itu. Dia jadi kayak embed ya.

Jadi, yang penulisnya

gak perlu update manual nih.

Kalau udah support,

masuk-masuk lagi,

terus update ini kayaknya jadi

report juga ya, bisa outdated juga.

Kalau ini kan jadi embed.

Kalau itu aman sih.

Dan,

katanya sih bakal

dibuat widget-nya. Jadi, kayak

nanti ke depannya bakal ada,

di talk-nya ada tuh, di video yang

kita cari aja dari 50-an

video IO kemarin.

Videonya Mbak Mariko,

kalau gak salah. Itu yang mengubah baseline.

Ke depannya bakal ada

widget, literally widget

kalau kita pengen

menunjukkan atau

menggunakan ini.

Kita mau ngecek misalnya

suatu feature udah di support atau belum,

bakal ada widget-nya.

Gokil sih ini, kalau misalnya

nanti bisa connect ke

NPM

atau extension

kayak IntelliSense gitu ya.

Kayak, dulu kan kita

suka pakai browser list.

Jadi, kalau browser list itu

kan untuk mesin ya.

Nah, kalau ini untuk developer.

Jadi, menarik sih. Dan itu

emang ideally, ke depannya, gimana

caranya mungkin bisa di-connect ya.

Kalau browser list itu kan lebih ke

bundler, ke library.

Misalnya kita menspesifikasikan

browser yang masih hidup.

Bukan Opera Mini, maaf ya

Opera Mini.

Ini bisa juga

di-connectin kayak ke

stylelin atau

islin. Suatu saat nanti bisa

di-connectin atau IntelliSense.

Bisa ketahuan

kalau kita lagi typing, oke,

ternyata

API yang kita pakai

gak sesuai sama browser config-nya kita.

Bisa juga, kan?

Misalnya mungkin

kayak tadi tuh

ada JavaScript kan buat

deep copy. Dulu kita harus

men-stringify, kita copy

string-nya, kita parse balik.

Nah, sekarang udah gak perlu itu.

Karena tadi udah ada structured clone

kan, ada di artikel yang tadi.

Nah, jadi kalau kita

kita ngetik

stringify terus parse, mungkin bisa

jadi ada, apa tuh, garis merahnya,

squiggly line, islin. Kalau kita hover

misalnya, kamu bisa pakai

structured clone. Kedepannya mungkin gitu,

walaupun sekarang belum ada.

Nah,

itu kalau senang beneran, lho.

Lihat tuh komen.

Halo.

Nah, coba buka.

Ada gak tempat buat fitur baru, katanya.

Kata Dama ada.

Kalau fitur baru,

fitur baru mah itu.

Bukan kesini.

Masih-masih gak ada itu ya.

CSS ya, berarti. CSS

Working Group lah, itunya.

Bikin issue ya, kalau gak salah.

Kalau kita mau vote fitur baru.

Cuma kan, kalau ini

untuk men-certificasi fitur

yang udah ada, mana yang udah

di-support secara luas.

Ini bentuknya widget kayak di

Lighthouse gitu? Enggak ya kayaknya.

Lighthouse kan dia cuma kayak score doang, kan?

Kalau ini sih kayaknya

di developer client ya.

Kalau Lighthouse kan

udah dari perspektif user lah, ibaratnya.

Dari perspektif website

yang udah jadi apapun itu kodenya.

Kalau ini mungkin ya

untuk developer lebih ke

proses development-nya.

Coba buka feature set deh.

Linggang feature set.

Nah, ya itu.

Jadi si baseline ini

sebetulnya adalah bagian

dari project yang lebih besar.

Yaitu feature set ini.

Jadi, ya itu

penjelasannya. Baca sendiri.

Intinya sih,

dulu kan, ya dulu tuh maksudnya

mungkin 10 tahun terakhir lah ya.

Banyak feature web API

yang misalnya di-support di Chrome,

Chromium, di-support di

Musila,

Firefox,

di-support di WebKit.

Tapi mungkin behavior-nya suka

agak lain-lain.

Atau mungkin ada subset-nya.

Misalnya ada tambahan

misalnya grid.

Ada subgrid yang cuma ada di Firefox.

Nah, terus apa?

Makanya ada project interop

untuk men-streamline-kan itu semua.

Nah, kedepannya ini

kayak mau lebih dirapihin aja.

Lebih dibuat, lebih ter-organized.

Jadi, ada kesepakatan

bahwa feature ini, suatu

feature tertentu yang di-support

itu apa saja. Nah, coba

buka repo-nya deh tadi.

Wah, ini ada npm-nya ya berarti ya.

Kita bisa pakai di sisi

coding-nya ya. Jadi kita bisa import.

Terus kita lihat statusnya di situ ya.

Kita bisa check

datanya.

Wow, menarik sekali.

Ada contohnya

di repo-nya tuh.

Atas.

Atas.

Atas lagi.

Atas lagi.

Atas file-nya.

Feature,

kayaknya feature group definitions ya.

Nah, coba tuh.

Nah, tuh, misalnya

si sgrid tadi gak?

Sgrid deh.

Nah, itu juga misalnya

BigInt. Tadi kan

ada JavaScript, ada property-property-nya.

Nah, itu grid, coba.

Jadi, ini format-nya YAML.

Jadi, karena ini di RANA

standard dan spesifikasi,

ini belum masuk ke teknis.

Implementasi teknisnya sih

terserah masing-masing browser.

Cuma ini sekedar

dokumentasi kesepakatan

teknologi CSS Grid

itu

property-property-nya

property atau feature-nya apa aja

sudah dia nge-paceline atau bukan.

Nah, itu ada detail-nya.

Jadi, ini kayaknya

untuk si

developer-nya si browser juga sih.

Jadi, kayak, oke, kita udah

punya standard.

Dan ini adalah sertifikat.

Jadi, kalau kita udah lulus tes, akan dapat

sertifikat itu.

Sama ada

kesepakatan aja sih

kalau kita pengen bikin feature ini.

Maksudnya, para vendor browser

mengimplementasikan feature ini,

ekspektasinya tuh seperti ini.

Kayak gitu.

Terus spek-nya tuh kan, nih, kalau misalnya JavaScript,

spek-nya ya dari website

PC39 kan tuh.

Terus ada field can I use.

Jadi, apa, mungkin ini kan

buat CIC di pipeline-nya mereka ya

buat auto

update can I use.

Nah, terus feature-nya apa aja.

Tadi kan CSS, ada formatnya CSS

.properties.blabla.

Ini JavaScript, build-ins,

operator, statement.

Jadi, ini memudahkan

programatik apa ya, apapun lah

nanti kita mau bikin tools atau

apapun, tinggal konsum ini

aja. Bisa jadi, kalau

ini sih kebayangnya kayak linter ya.

Jadi, mungkin ada

team lead yang implementasi

ini, dia membatasi kalau

harus sesuai

dengan baseline. Kalau ada

library yang digunakan tapi tidak

atau ada feature yang

digunakan tapi belum

masih di bawah baseline, maka

linter-nya akan kasih

dong jangan pakai ini.

Atau ya warning lah, gimana

caranya cari polyfill

ya kan, tetap.

Kalau di web

developer lane, ya cari polyfill

atau tips buat progressive enhancement

misalnya kita harus apalah if

navigator.

Minimal if lah,

kondisional, kalau misalnya nggak support, jangan

dijalaniin.

Ada fallback-nya seperti PWA

dan lain-lain ya. Jadi, kalau misalkan

dia didukung, ya jalanin.

Kalau nggak didukung, ya cari solusi

alternatifnya.

Nah, kalau ini kayak border image kan,

border buat, apa sih, kayak

gradient sama background image apa ya?

Ya, biar ada gradasi ya.

Border-nya.

Bisa dilihat sendiri.

Nggak bisa abis ya.

Banyak ya.

Nah, cuma baseline ini,

browser list yang tadi kita bahaskan.

Kalau yang

pernah pakai Create React App pasti

pertama kali lihat ini deh.

Di package JSON-nya kan pasti ada

ini. Sama kalau misalnya

npm install, browser list-nya

outdated, minta update.

Iya.

Jadi, di

browser list ini dikasih tahu, saya pingin

mendukung IE

edge ke atas.

IE yang selain edge

nggak mau gitu.

Jadi, bisa kayak gitu ya.

Atau node versi 16

atau yang lebih baru.

Ternyata last two

versions itu hal yang

udah cukup umum karena default-nya

browser list pun itu

last two versions.

Di sini temen-temen ada yang tahu

versi browser-nya, versi berapa

sekarang? Kayaknya udah nggak up.

Nggak ngikutin versi berapa.

Satu, satu, tiga.

Cuma sekarang kan browser rata-rata

minimal kalau browser yang

di laptop ya, kalau dia

nggak up-to-date kan muncul itu sendiri

muncul button-nya buat

update. Bahkan

dia update sendiri, dan begitu kita

misalnya sat down,

biasanya sudah selesai, itu udah

automatis update.

Kalau gue matiin sih, gue matiin auto-update.

Cuma jadi muncul itu

tombol buat update.

Ada notifikasinya ya.

Karena kan by default,

otomatis kan.

Jadi kita nggak perlu update-update,

update-update gitu,

dia udah otomatis meng-update dirinya

sendiri. Kecuali kalau ada

error sesuatu terjadi

yang aneh-aneh ya, mungkin error.

Cuma kalau HP

nggak sih, nggak

auto-update kan, nggak ada.

Android, Android.

Android bisa dinyalain

otomatis juga. Bisa sih dinyalain.

Cuma males.

Tiba-tiba, kok

panas handphone ya, ternyata lagi download ya.

Download update maksudnya.

Oke.

Ada lagi? Yang menarik-menarik?

Hmm, gitu dulu.

Sudah ya? Udah.

Ada lagi kan?

DevTools tips.

Oh iya.

Oh itu cadangan sih, tapi boleh sih.

Nah, ini singkat aja sih.

Sebenarnya ini video

sesuai judulnya sih.

Ini kayak macem-macem

random tips and tricks untuk menggunakan

DevTools. Dan

ada hal-hal yang sebetulnya

udah lama ada. Cuma

nggak tahu, mungkin aku yang kurang

update atau jarang

lihat update-nya.

Biasanya update-nya mbak Jaslin tuh ya,

kalau DevTools kan. Jarang ngikutin.

Jadi, ternyata

ada beberapa feature yang di DevTools

yang berguna. Cuma

apa, mungkin belum banyak yang tahu.

Misalnya, kan

di DevTools ada tab source tuh.

Kita bisa lihat source code-nya.

Tapi biasanya kan, ya

bukan biasanya source code yang dimaksudkan

pasti yang udah di, apa?

Udah dibandling kan tuh, udah webpack, blablabla.

Udah di minify, dan lain-lain gitu ya.

Nah, ternyata

DevTools Chrome itu

tuh, ada feature

author view, yang dimaksud

author view itu, code

component source yang kita tulis.

Ini kalau di dev environment ya.

Jadi, lebih gampang kita lihat

per component-nya, beneran code

component yang kita tulis.

Itu kalau ada mapping-nya kali ya?

Ada mapping-nya. Iya, ada. Ada mapping-nya.

Itu kan baca source map sebetulnya.

Jadi, cuma secara view

helpful aja, otomatis udah dikelompokin.

Kita bisa, nah, itu tuh

kayak di layarnya, tinggal

tinggal toggle

author view aja.

Kita bisa lihat, kita bisa

ngebaca kode component-component kita.

Terus yang kedua, hal

menarik kedua, itu ada

ignore list untuk third party

scripts. Kan suka ada

analytics atau lainnya lah.

Nah, itu, nah, terus kan

banyak dan kita harus scrolling lama

tuh biasanya buat ngeliat source.

Itu ternyata bisa di auto ignore.

Dan setelah dilihat artikelnya,

itu udah dari tahun lalu ada.

Jadi, agustus

2022.

Ini ya? Iya.

Tuh, mbak Jislin.

Nah, intinya ya,

kalau misalnya, mungkin temen-temen

jarang liat update yang

update dev tools, bisa nonton video

itu karena ada beberapa ringkasan tools

yang cukup berguna.

Tau nggak ada

dev tools yang untuk

overlay core web vital?

Overlay?

Ya, core web vital. Nggak tahu.

Kayak pernah lihat deh.

Coba buka,

saya buka dev tool.

Masuk ke more tools.

More tools, ya, more tools.

Rendering.

Yep.

Scroll ke bawah, scroll, ya, scroll.

Tuh, centang core web vital.

Wow.

Kebanyakan feature.

Dev tools tuh kebanyakan feature.

Kita malah, kita malah jadinya up to date.

Jangan ditutup.

Oh iya, jangan ditutup ya.

Nah, itu berguna sekali

kalau saya pakai itu

nggak tahu LCP

sama, sama

apa tuh, layout shift.

Jadi, scroll, scroll, scroll.

Oh, kalau kita refresh,

dia akan update ya.

Wow, canggih ya.

Sebenarnya buat topik ini di depan, tapi ya.

Oh, iya kan kisi-kisi.

Ya, bisa, bisa.

Ini juga belum kita bahas kan

dev tools ini kan.

Belum.

Kadang, deket-deket lagi bahas yang lain

sambil buka dev tools.

Cuma belum pernah yang spesifik.

Iya, belum pernah spesifik.

Oke.

Ada lagi?

Oh iya, saya mau nunjukin ini nih, bentar.

saya mau nunjukin yang WSMB tadi.

WSMB tadi,

baru ketemu.

Nah, ini

udah kelihatan kan? Nah, ini adalah

contoh

aplikasi Android

yang dengan codebase hampir sama.

Dia bisa bikin yang versi webnya.

Ini dari Jetbrain orang. Nah, ini.

Tapi dia pakai canvas ini

disini, jadi canvas bentuknya.

Kelihatan kan kodenya ya?

Oh iya, jadi canvas?

Iya.

Pertanyaan saya adalah

aksesibility itu kan canvas?

Iya.

Kalau frame rate dan lain-lain

bagus ya, di atas 100 kan?

Aksesibilitynya gimana ya?

Aksesibilitynya gimana? Itu pertanyaan

juga sih. Karena dia

compilenya jadi canvas.

Kayaknya Flutter web

juga kayak gitu, kayaknya ya?

Enggak, Flutter kan jadi dom.

Flutter jadi dom ya?

Bukan canvas ya?

Kelihatanya jadi dom deh,

pernah lihat demo gitu.

Oh iya, berarti saya yang salah.

Oke.

Oh ini tadi ya? Sudah habis ya?

Tapi kita habis. Terakhir ini ya?

Oke.

Oke, kalau gitu.

Ada komen, kalau minifight,

jadi susah bacanya.

Kalau minifight jadi susah bacanya.

Kalau ada source map,

bisa kembali.

Jadi kayak di expand lagi.

Di Chrome DevTools-nya

kelihatannya yang

versi belum minifight.

Di sini ada nggak?

Bahkan bisa didibug.

Nanti kita harus belajar, kita harus

nanti kita harus demo itu.

Kepan-kepan deh episode.

How to debug ya.

Jangan pakai basalok aja.

Termasuk kalau lagi

development environment, misalnya kita

masih lagi localhost di development,

ya itu tadi, pakai kan

bisa pakai break points,

terus bisa ngeliat source yang

source yang tadi author

yang kode per komponen

yang kita tulis.

Betul.

Kan console lock nggak cuma lock doang loh.

Console tuh nggak cuma lock doang.

Console error, console

info, console

warn.

Banyak lah.

Tenang aja. Kita bahas satu-satu.

Oke.

Oke, kalau gitu,

kalau sudah, ada lagi mungkin

yang mau disampaikan.

Kalau nggak ada, mungkin kita tutup.

Oh iya, buat yang mau usul topik,

kan kita tuh, kita kalau lagi gini

suka dapet ide topik random ya.

Nah, mungkin teman-teman ada

ide topik lainnya

yang tiba-tiba kepikiran bisa dikirim

ke situ.

Ke bit.ly/ngobrolin web.

Kita kadang-kadang juga

suka keceplosan gitu kan

ide apa, tapi habis itu kita lupa.

Jadi harus tonton dulu videonya.

Oh iya, kita mau bahas ini.

Jadi bisa

di apa, ya

kita butuh bantuannya juga teman-teman

tertariknya ke, lagi tertarik ke

topik apa, siapa tahu kita juga punya

ketarikan yang sama, jadi kita bisa bahas dan

kita bisa belajar bareng-bareng.

Atau bisa saran bintang tamu siapa?

Bintang tamu?

Bintang tamu sekalian dikasih kontak persennya ya.

Mengajukan diri sendiri juga boleh?

Oh iya, tentu boleh.

Jadi

biar makin seru, biar makin rame

acaranya juga bisa bermanfaat buat

teman-teman semua untuk update-update

seputar dunia teknologi web.

Sekian dulu untuk malam

hari ini, terima kasih banyak

buat semuanya yang sudah mendampingi

dari awal sampai akhir.

Kita ketemu lagi

pada minggu depan hari Selasa jam

8.00 malam. Sampai jumpa

bye-bye

sebentar ini

closingnya belum?

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 Kunjungi https://ngobrol.in untuk catatan, tautan dan informasi topik lainnya.

Episode Terkait

Bagikan:

Suka episode ini?

Episode baru setiap Selasa malam. Dengarkan lewat YouTube, Spotify, atau feed podcast favoritmu.

Pilih Cara Langganan

Memuat komentar dari GitHub Discussions...

Jika komentar tidak muncul karena ekstensi privasi / adblocker, kamu bisa berdiskusi langsung di GitHub Discussions .