Ngobrolin i18n
Ringkasan Episode
Bantu KoreksiEpisode ini membahas Intl, Web API untuk internationalization yang membuat pemformatan tanggal, angka, dan mata uang sesuai kebiasaan tiap negara jadi urusan satu baris kode. Masalah yang diselesaikannya nyata: desimal di Indonesia memakai koma sementara di Amerika memakai titik, urutan tanggal berbeda-beda, dan bentuk jamak berbeda di tiap bahasa. Dulu semua itu dikerjakan dengan membuat array nama bulan sendiri untuk tiap bahasa, atau mengganti titik dan koma secara manual — pendekatan yang berbahaya ketika menyangkut uang. Intl juga sudah punya RelativeTimeFormat untuk menampilkan "satu hari yang lalu", kebutuhan yang hampir selalu muncul di produk yang menghadap pengguna dan dulu menjadi alasan memasang moment.js yang berukuran ratusan kilobyte. Bagian terbaiknya adalah diskusi tentang kapan memakai library. Urutannya: pakai Web API yang sudah ada dulu, baru cari library sekecil mungkin kalau memang belum ada. Pertimbangan lain yang jarang dibicarakan adalah biaya perawatan — library pihak ketiga bisa punya celah keamanan, bisa berhenti dirawat, dan kalau kita tidak paham kodenya kita tidak bisa mem-fork dan menyesuaikannya saat darurat. Ada juga temuan menarik dari benchmark: library pihak ketiga ternyata bisa lebih cepat daripada Web API, tetapi itu tidak sebanding dengan biaya mengunduh ratusan kilobyte lebih dulu.
Poin-poin Utama
- •Intl menangani perbedaan format desimal, urutan tanggal, nama bulan, dan mata uang tanpa perlu memasang library — cukup panggil langsung karena sudah ada di browser
- •Argumen locale bisa berupa array sebagai fallback berjenjang: kalau bahasa daerah tidak didukung browser, ia jatuh ke bahasa yang lebih umum
- •Jangan pernah mengganti titik dan koma secara manual untuk memformat uang — satu kesalahan koma bisa mengubah nominal seribu kali lipat
- •Urutan memilih tooling: pakai Web API yang sudah ada dulu, baru cari library sekecil mungkin — dan kalau yang dibutuhkan hanya satu fungsi kecil, membuka kodenya dan menyalin bagian itu dengan kredit sering lebih masuk akal daripada memasang seluruh library
- •Biaya library pihak ketiga bukan hanya ukurannya tetapi perawatannya: bisa muncul celah keamanan, bisa berhenti dirawat, dan kalau kita tidak paham kodenya kita tidak bisa mem-fork saat darurat
- •Benchmark menunjukkan library pihak ketiga bisa lebih cepat daripada Web API karena mereka bebas mengambil trade-off yang tidak boleh diambil browser — tetapi kecepatan itu tidak sebanding dengan biaya mengunduhnya lebih dulu
- •Uji ketahanan dengan memblokir request di DevTools: kalau CDN atau script analytics diblokir ad blocker, pastikan aplikasi tidak ikut rusak
(musik)
Halo-halo selamat datang di Ngobrol Ngidwet setiap hari Selasa jam 8 malam
waktu Indonesia bagian barat masih bersama saya Riza
dan juga dua teman saya yang baik hati
yaitu Ivan. Halo Ivan.
Halo-halo Mas Dita dan selamat datang di Ngobrol in Web.
Ya, kabar baik-kabar baik.
Lagi sibuk apa, lagi sibuk apa? Mungkin bisa disesar sedikit kesibukannya.
Sibuk apa ya, nyangkul kali ya, nyangkul di ibot.
Jadi kuli koding.
Kuli koding, mantap, mantap, mantap.
Terus, ya satu lagi ya, ada Eka. Halo Eka.
Halo, halo Riza, Ivan.
Halo teman-teman semua yang lagi nonton.
Ya, Eka kesibukannya apa sekarang?
Sama kayak Ivan, maco, kuli digital ya, kuli pixel.
Kuli digital, kuli pixel.
Sama nyampein materi buat DeVest dong, apa buat?
Oh iya, boleh, boleh, boleh di ini dong, di SPIL.
Mau ngisi kota mana, kota mana?
Ada di Bali, sama di Jogja, di kota sendiri.
Oh di kota sendiri, Jogja.
Malah belum pernah bawain di kota sendiri.
Kalo Ivan dimana, kalo Ivan?
Udah ada convert?
Sudah, sudah.
Sudah confirm ya?
Wait, kenapa ya?
Bentar, kok kayaknya kamera saya mati?
Nggak, sudah apa?
Lihat transkrip lengkap (666 segmen lagi)
Oh nggak, sudah.
Saya confirm di dua tempat, Depok dan Bogor.
Wah, deket-deket ya.
Driving distance ya.
Mas Rissa dimana nih?
Kalo saya yang udah confirm itu Surabaya, Semarang.
Seru.
Dengar-dengar isi medan juga kan?
Kabarnya gitu, tapi belum ada kabar dari mereka.
Sama Makassar satu lagi, jadi ada empat.
Uset, ada empat.
Ada empat.
Mulanya berapa sih?
Mulainya November.
Ini udah November?
Iya, week 3.
Sampai Desember.
Jadi setiap Sabtu itu keluar kota terus setiap minggu, jadinya empat kali.
Belum siapin materi.
Mudah-mudahan materinya bisa sama semua ya.
Reusable.
Oke, sebelum kita ngelantur kemana-mana.
Kita akan bahas malam ini tentang international.
Oh bukan ya, kita tentang internationalization.
Internationalization.
1810 ya.
Dan apa itu, tapi sebelum itu saya mau sapa-sapa dulu temen-temen kita yang sudah hadir, yang sudah menunggu.
Ini katanya Mas Muhammad Abdul Mubarak, yang menunggu kita setiap hari Selasa.
Halo-halo, selamat kenal.
Gokil dari selamatan, mantap.
Ada Andra, dan ada juga RS Production.
Ini kayak, production apa nih?
Production House.
RS berarti, ini ya, Ras Production.
Aku pikirannya rumah sahaja.
Ya, jangan lupa kalau teman-teman yang hadir live punya topik diskusi,
atau ada yang mau ditanyakan, ada yang mau dibahas, boleh langsung dicat aja.
Tapi kalau teman-teman yang nonton ini nanti, setelah acaranya selesai, tidak live,
teman-teman bisa juga bertanya di bit.ly/ngobroinward.
Oke, kita akan bahas tentang internalization.
Siapa yang mau membahas apa itu internalization?
Mungkin Ivan kali ya.
Enak ya, jadi host ya, bisa nembaknya.
-Iya. -Nenyok-nenyok.
Intel, kalau saya sih bahasnya panggilannya Intel.
E18N Internationalization.
Jadi sebenarnya ini web API.
Jadi baru-baru ini aja.
Aku nggak salah, ini launch-nya, saya nggak tahu kapan launch-nya ya.
Tapi ini sempat disinggung waktu kita di Chrome Dev Summit yang...
-Kapan itu? -Oh, you're extended.
-2019? 2018? -2018 kayaknya.
Pernah disinggung waktu itu.
Intel API itu udah rilis gitu.
Seperti yang teman-teman tahu, kalau misalnya teman-teman itu mau bangun web aplikasi
yang multi-language dan multi-currency.
Multi-language itu artinya multi-currency, terus kemudian date format, number format.
-Language sensitive. -Language sensitive bahasanya.
Yes, formatting itu.
Jadi misalnya decimal aja kadang ada beberapa negara seperti Indonesia.
Decimal pakenya koma, ribuan pakenya titik.
Kalau di US, decimal pakenya kebalik.
December pakenya titik, ribuannya pakenya koma.
Dan kalau jangan, kemudian tanggal.
-Tanggal gimana lagi? -Ya, ada yang bulan duluan,
ada yang tanggal duluan, ada yang tahun duluan.
-Oh, pusing dah pokoknya. -Selain nama bulannya sendiri juga ya.
Tergantung bahasa, selain nama bulannya, format angkanya sama format urutannya juga ya.
-Betul. Terus ada juga yang concatenation ya.
Misalnya N, misalnya ayah, ibu, dan anak. Kalau di bahasa Inggrisnya, father, mother, and children.
-Koma N. -Ya kan.
-Plural, plural juga sesuatu. -Plural.
Ada yang S belakangnya kalau plural, ada yang S aja.
-Kalau Indonesia jamak plural. -Gak ada.
Kalau Indonesia itu lebih ke arah diulang anak-anak, bukan "kids".
Cuma kalau web UI di bahasa Indonesia itu bisa di omit.
Misalnya "Halo Eka, kamu punya 10 pesan baru, kita nggak harus pesan-pesan baru."
Jadi lebih santai kali ya.
Nah, kalau teman-teman saya itu aslinya dulu adalah back-end development, jadi PHP misalnya.
Kalau saya mau translate, saya udah bikin tuh 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12.
Januari, Februari, Marat, April, May. Itu untuk bahasa Indonesia.
Untuk bahasa Inggris bikin lagi beda. Untuk bahasa Jerman bikin lagi beda.
Kalau misalnya saya detek AP-nya dari mana, baru pilih bahasa yang mana.
Saya pakai sesuai array. Itu cara saya dulu.
Nah, itu saya nggak mau lakukan lagi dengan Intel API.
Jadi kalau misalnya datetime, saya hanya cukup format 1 hal aja.
Jadi formatnya apa? Misalnya datetime itu dipersing dari string atau pakai API-nya si web.
Ini si last pakai new date. Apa? Instansi?
Ya, new date ya function dari si browser.
Tinggal pakai, tinggal di format, mau jadi, ya seperti ini.
Datenya mau di format jadi format US bisa.
Format jadi BN itu apa sih? BN? B-A-N? Saya nggak tahu.
- B-A-N apa ya? - Nggak tahu.
Oh, ini contohnya Balinese. Ini buat, jadi kalau misalnya.
- Indonesia. Indonesia nih ya? - Iya.
Iya, jadi misalnya ini kasusnya kita bisa pas argumennya bisa single string kayak di atas itu NUS.
Bisa pakai ray of strings. Ray of strings itu kegunaannya kalau yang pertama ada.
Misalnya di browsernya support apa, format ke bahasa daerah.
Yaitu di sini bahasa Bali, dia bakal display itu.
Cuma kalau misalnya nggak ada, apa, orang bisa berbahasa Bali kan kemungkinan besar pasti bisa berbahasa Indonesia.
Jadi fallback-nya yang lebih aman yang ada di browser.
Ini ya, ini US bulan duluan ya, baru tanggal kan.
Kalau Indonesia, tanggal dulu baru bulan.
Tunggal dulu.
Bisa juga ngasih tahu itu di timezone mana. GMT+11 otomatis.
Ini sangat penting sekali kalau yang date sensitive untuk situs yang time sensitive.
Contohnya situs lelang.
Ngasih tahu countdown datenya itu harus sesuai dengan di mana si user itu berada.
Kalau kita ngasih tahu jam 12 malam di tutup, jam 12 malam mana.
Jadi harus pas gitu.
Kalau kita pake Intel API, itu sudah disolve. Nggak cuma date ya, ada number, ada plural, ada macem-macem.
Kalau dulu sebelum ada INTL ini biasanya kita pake third party ya kan?
Iya, pake JavaScript.
- Buat angka sendiri ya kan? - Buat number format sendiri.
Number format itu biasanya jadi satu sama library buat handle translation ya.
Biasanya kalau common practice-nya.
Atau kita harus hand roll sendiri, customize.
Ya, biasanya itu dulu sebelum ada library ini bikin sendiri. Jadi di parse, kalau 0-nya 3 ya dikasih titik,
terus ujungnya dikasih koma, terus misalkan tambahkan RP, gitu-gitu ya, sendiri semuanya.
Nah, itu yang bikin Parno banget apalagi kalau dealing sama uang ya currency.
Sangin nggak sih kalau misalnya kita ngehandle banking atau e-commerce, terus salah gitu, salah saldo orang 10.000
gara-gara salah titik sama koma, ilang jadi 10, kita suruh ganti sisanya, gimana?
Iya, cuma salah koma doang ya. Misalkan ini 0,79 gitu kan, itu satu kan.
Kalau ada 1.000, berarti 0,79 kali 1.000, berapa tuh? Lumayan kan?
Maksudnya kalau di rupiah, kalau misalnya di-ponser link kayak di contohnya.
Euro, ya misalnya bisa transaksi pakai euro, pakai rupiah, nah kita salah tuh pas convert.
Terus apa, user-nya kecar 10.000 euro, wah.
Waduh, ngeri ya.
Jadi intinya jangan, maksudnya jangan handling yang, jangan main kasar yang gitu lah.
Jangan yang apa, nge-replace-replace titik atau koma sendiri.
Iya, apalagi kan JavaScript sangat sensitif ya.
Maksudnya kan kalau awalnya number, terus kita, mungkin kita salah atau kita keliru,
number-nya kita convert jadi string, abis itu string ditambah dengan angka jadinya kan,
100.000 ditambah 1, jadi 1 juta 1 kan.
Apalagi kalau nggak, ini skenario ngaco banget sih, misalnya nggak pakai strict mode, kan apa,
itu tambah operasi penjumlahan kan, kalau nggak di strict mode itu, itu ada quirk aneh dari JavaScript.
Jadi kan string ditambah number, itu jadi string semua.
Jadi kayak bisa 10, misalnya kita mau nambah 10 tambah variable B,
tapi variable B ini karena salah parsing jadi not a number, n-a-n.
Nah pusing kan kalau tiba-tiba saldo user kita jadi 10 n-a-n.
Jadi ingat beberapa tahun yang lalu anak saya pernah nanya, 1 ditambah 1 berapa?
Saya jawabnya 2, dia jawabnya 11, jadi dia cocok jadi JavaScript developer ya.
- Bukan, dia cocok jadi JavaScript engine. - JavaScript engine.
Compiler ya, dia compil kode ya.
Terus saya argumen, kenapa kok nggak dikasih string gitu kan satunya.
Ya, begitulah. Jadi apa namanya, sebelumnya kita biasanya menggunakan library tambahan
yang paling populer adalah momen JS, itu yang paling lengkap, di satu sisi paling lengkap,
di sisi yang lain paling berat atau paling besar ukurannya.
Karena dia legacy ya, salah satu dari dulu ada, yang paling established.
Yang paling established dan itu yang membuatnya terlalu besar adalah dia punya
koleksi di kineri kan, jadi bahasa-bahasa di seluruh dunia itu dikumpulin semua.
Dan kayaknya belakangnya bisa di tri-shaking, tapi awalnya belum bisa ya.
Awalnya belum bisa jadi satu, maka dari itu dia besar sekali.
Dan salah satu fitur yang menarik dari library seperti momen JS, ada date JS sekarang ya,
ada date FNS dulu, itu adalah yang sering saya pakai adalah relative time format.
Ini juga menarik. - Iya, ini dia.
Ternyata sudah ada juga di INTL. - Ternyata ada, mantep.
One day ago. - Ini permintaan product owner atau product lead ini
kalau kita bikin product yang user facing, customer atau client facing,
ini hampir pasti ada. - Ada chat app lah, atau email, atau apa.
Kalau kita ganti di sini dan kita run, dia akan menjadi itu.
Dalam 3/4 satu hari yang lalu, bahasa Indonesia kan, padahal dia tulis -1 day,
tapi sudah di-convert ke Indonesia. Jadi ini membantu sekali.
Tidak perlu ada library tambahan, tidak perlu memberatkan user untuk men-download
terpantir library, kita sudah bisa menggunakan INTL ini di browser-browser modern ya.
Ada ininya nggak? Can I use? Ini dia. - Ada.
Kayaknya sudah relatif stabil. - Sudah ada semua ya.
Cuma belum semua metode-nya support kelihatannya ya.
Relative time format, katakanlah. Ini sudah 7/1 sudah cukup lama kan.
Ini sudah 100 kan, versi 100 ya. - Ini sudah cukup stabil kok.
Sudah cukup stabil. Jadi aman ya. - Aman.
Oh iya, ijo semua. Oke ya. - Ijo semua.
Dan itu apa namanya, sedikit promosi.
Saya pernah punya online course untuk progressive web apps,
ini dia contoh aplikasinya. Aplikasi e-commerce
yang jualan produknya yang diidam-idamkan Ivan.
Herman Miller. - Course ke-52 juta.
Ini saya bikinnya pakai INTL, itu tahun 2021.
Ini kode sumbernya seperti ini. Jadi sederhana, kita tinggal panggil INTL,
nggak perlu import, nggak perlu apa. - Tanpa harus import atau install?
Iya. Terus kita kasih, kita mau destinasinya, tujuannya adalah number dari negara mana.
Style-nya currency. Kita bisa pakai style yang lain juga.
Ada beberapa style selain currency. Terus kita tambahkan,
ini adalah currency-nya IDR. Sehingga hasilnya yang tadinya 52 juta
dalam bentuk number, dia di format ke dalam bentuk RP, spasi, 52.00.
- Sudah ada separator titiknya juga ya? - Iya, itu sudah otomatis.
- RP-nya juga sudah dari INTL-nya? - RP-nya juga sudah dari INTL-nya, begitu.
Dan tadi kita sebutkan momen JS. Momen JS itu adalah salah satu yang paling populer
dan juga paling berat karena ukurannya yang cukup berat.
Dan salah satu cara untuk mengetahui seberapa besar sebuah library.
Teman-teman bisa menggunakan bundle phobia. Ini web yang bisa digunakan
untuk ngecek seberapa besar sebuah library. Katakanlah tadi momen ya.
Kita lihat di sini ada... Nah, momen ini sudah dipisah sekarang.
Ada momen, ada timezone, ada lokal, dan lain-lain.
Kalau dulu jadi satu semuanya, makanya dia besar sekali.
Tapi kita lihat sekarang, ukurannya masih cukup besar, 300 kilobytes ya,
290 kilobytes yang sudah diminifit. Kalau kita lihat download time-nya,
bayangkan 1,5 detik hanya untuk men-download si library momen.
Sedangkan di INTL kita tinggal pakai, nggak perlu download.
- Kalau yang lebih kecil apa? DIGS ya? - DIGS coba.
DIGS ini jauh lebih kecil. 6,5 kilobytes.
Nggak tahu download time-nya kalau yang di slow 3G ya, atau di 4G itu 3 mili detik.
Tetap ada delay time-nya sedikit.
Nah, pertanyaan sekarang, ini yang ditulis ya kelihatannya, pertanyaan sekarang,
kapan kita memutuskan untuk menggunakan library, kapan kita memutuskan untuk
tidak menggunakan library? Atau mungkin ada kalanya kita harus bikin sendiri?
- Kalau saya, by default, jangan pakai library apapun. - Bikin sendiri dulu?
- Tidak, by default pakai API dari web yang ada dulu. Susahakan pakai yang ada.
Kalau sampai nggak. Misalnya dalam development ya, kita butuh sesuatu gitu.
Pikirkan dulu misalnya apa yang ada dari web. Contohnya Intel ini.
Banyak loh web API. Minggu lalu pernah kita bahas web API itu di MDN tuh ada banyak sekali.
Apa aja yang sudah ada gitu. Jangan develop, jangan reinventing the wheel dulu gitu ya.
Pakai apa yang ada. Kalau misalnya nggak ada, baru kita coba pikirkan
library apa yang kecil, yang kira-kira makes sense gitu.
Contohnya yang paling terkenal adalah LODAS ya. LODAS sebelum dipisah itu kan
gede banget ya. Masa cuma mau pakai buat LODAS itu yang hanya LODAS.
- Compare object ya misalnya. - Antara compare object, filter.
- Filter atau yang gini loh. Misalnya kalau kita get sesuatu object, kalau nggak ada
returnnya, defaultnya apa gitu. Tau nggak itu? Kalau nggak salah LODAS get deh.
Jadi hanya untuk pakai get doang, di import seluruh LODAS aja.
Nah itu saya kalau misalnya ketemu developer yang bikin gitu, "Aduh, jangan deh pakai ginian."
Kalau cuma mau pakai getnya doang, jangan pakai LODAS, ya udah bikin aja sendiri lah.
Nah itulah maksudnya komparasi nggak gitu. Kalau sampai kayak butuh-butuh banget,
misalnya kayak contohnya memikirkan antara fetch API atau pakai Axios misalnya.
Kalau memang butuh sampai lebih mendalem karena harus pakai asingkronus plus dia ada
authentication atau ada blablabla yang perlu kita customize di header, ya pakai Axios misalnya.
Kalau nggak ya, pakai fetch API aja gitu. Itu dari saya. Eka gimana Eka?
- Sebetulnya ya sama, kalau misalnya start small dulu kan ya.
Kalau misalnya masih bisa pakai web API yang udah ada ya pakai aja.
Tapi kan pertimbangannya mungkin browser support, kita harus support browser apa aja.
Ini kan tergantung sama analytics user base kita ya.
- Target user kita. - Cuma kalau dalam kasus Intel ini kan
sebenarnya supportnya udah merata jadi ya nggak masalah sama sekali.
Ada kasus lagi, kemungkinan kedua, terlanjur misalnya kan nggak semua kodil kita tulis dari awal ya.
Kalau legacy code, dan terlanjur pakai library, terus dipakai di banyak tempat.
Jadi kalau kita ganti satu, ini takutnya ngerusak yang lain.
Dan belum ada waktu yang cukup buat apa, totally nge-replace semua.
Ya sementara pakai itu dulu, cuma biasanya kalau strategi aku sih minta waktu untuk
pelan-pelan diganti aja. Dan kayak misalnya tadi disebut Ivan soal Lodes,
itu cuma sebetulnya yang diperluin, yang dipakai itu cuma get, kan bisa juga bisa curang-curang dikit lah.
Sebagian besar kan bukan curang ya, maksudnya berakal lah, akal-akalan megaever ya.
Apa? Lodes atau library sejenis kan open source.
Kadang tuh hal yang pengen kita pakai tuh segitu kecilnya sampai ya udah kita buka aja
di bagian metode yang kita pengen, kopas aja.
Kopas dengan kredit kalau misalnya kode kita juga publik, ya gak apa-apa kita tetap mention kredit.
Cuma kan maksudnya ini untuk keperluan performance,
selain performance juga mengurangi dependensi ke library kan.
Nah itu yang pertimbangan kedua.
Ada pertimbangan ketiga nih, tadi udah masuk di list itu sih.
Pertimbangan ketiga adalah kadang kita butuh isomorphic yaitu re-usable function Javascript
yang jalan di server, jalan di client, client atau browser maksudnya.
Nah Intel itu kan web API ya, browser API, jadi bukan.
Eh, atau udah di nulung sih?
Sudah ada, ada.
Nah itu pertimbangan juga, tapi kalau ternyata udah support ya udah, berarti aman bisa dipakai.
Yang gak ada itu yang pakai window object misalnya apapun itu.
Intersection Observer, Resize Observer.
Loh gak semua, dulu fetch aja sampai lama gak ada kan.
Jadi mesti check itu dulu, kalau udah aman di kedua environment jalan ya udah oke itu.
Nih, sudah ada di Deno dan Deno.js.
Uy Deno aja ada, iyalah satu engine ya sama Note. Mantap.
Ada yang Note.
Ada yang bintang, bintang ini apa?
Note, apa ini?
Itu cuma apa?
Oh, beberapa metode yang aneh-aneh.
Yes, gitu. Benar-benar.
Ya, jadi tadi yang perlu di highlight adalah kalau misalkan kita pakai sebuah satu fungsi aja
baik itu dari Lodash kah, atau dari Moment kah, atau dari GQuery kah.
Itu kan open source ya, coba aja ditelusuri, dibuka source-nya kita lihat.
Misalkan, kalau dulu tuh beberapa kali saya sering nemuin kalau misalkan kita udah pakai React.
Kan React ada tuh, react-dom.render kan, react-dom.render.
Yang render adalah app-nya, kemudian tujuan div_id sekian, div_id_app gitu kan.
Nah, div_id_app-nya pakai jQuery selektor.
Ya.
Hanya untuk select div dengan id_app, itu beberapa kali saya pernah lihat.
Padahal kalau nggak ngerti cala selection-nya, mungkin karena sudah terbiasa, kadung terbiasa dengan jQuery.
Sebelum itu kan jQuery udah no-brainer ya, kita install gitu kan.
Sebelumnya dia kayaknya udah ada jQuery kan.
Iya, bahkan kadang-kadang satu web itu bisa lebih dari satu versi jQuery, ada versi jQuery.
Terus WordPress itu tiap plugin bawa jQuery sendiri, pusing-pusing.
Iya, karena nggak kompatibel kan, gitu kan.
Jadi ada plugin yang tidak kompatibel dengan versi 2 atau sebaliknya.
Jadi karena sudah terbiasa, ya jadi pakai dollar dalam kurung, petik satu, pager, app gitu kan, selektor.
Kalau misalkan kita aware bahwa kalau kita bawa jQuery itu ukurannya sekian,
ya mungkin kita harus melihat ini selektor ini kayak gimana cara jalan-jalan.
Mungkin karena nggak aware kalau itu jQuery, mungkin karena itu JavaScript, kiranya.
Bisa jadi.
JQuery itu bagian dari JavaScript gitu ya. Terlalu terkenalnya JavaScript,
jadi semua apa-apa semua pakai jQuery.
Jadinya kirain kalau dollar apa itu adalah bagian dari JavaScript.
Sama kayak Lodas ya, Under School itu udah ini ya.
Dan itu juga karena perkembangan web API kali ya, kalau dulu emang belum bisa.
Maksudnya misalnya beberapa dari Lodas kayak contoh yang paling itu sort sih yang kebayang.
Dulu kan sort belum di, masih banyak yang belum support ya, sort, merge.
Lama-lama sekarang udah ada di stable release semua browser, ya udah itu jadi obsolete.
Dulu justified, cuma sekarang jadi nggak perlu lagi.
- Iya bahkan selektor jQuery, sorry, selektor JavaScript tidak seudah sekarang.
Kalau sekarang kan tinggal query selektor atau query sector all, udah bisa pakai class,
pakai yang hitik, atau pakai pager gitu kan.
Kalau zaman dulu kan harus sell apa, get element by ID, get element by class name gitu kan.
Jadi mungkin agak males gitu ya buat kita develop.
- Trendnya vanilla first development. Semua-semuanya harus vanilla dulu, diutamakan vanilla dulu.
Pakai apa yang ada.
- Iya, ada yang cinta mati sama jQuery ya.
- Cinta pertama nggak perlu lupa ya.
- Satu lagi soal kenapa saya mengurangi memakai library third party.
Itu maintenance-nya, kalau misalnya memikirkan maintainability-nya skala panjang gitu ya dalam waktu yang panjang.
Library third party itu sebetulnya bisa ada vulnerability juga.
Bisa terjadi vulnerability dan mereka buku di update.
- Kayak waktu itu kalau JS ya, ada kasus, ada kasus apa sih, ya vulnerability entah karena sengaja atau nggak sengaja.
Kalau kasus yang ekstrim kan, itu yang kelar JS kemarin.
Yang karena dengan sengaja, ya si creator-nya lagi ada masalah sendiri.
Terus apa, si library-nya di break, atau bisa juga vulnerability yang nggak disengaja, atau karena dari dependensinya ya.
- Dependensi, iya.
- Intinya, kita kan tetap harus aware untuk update itu ya.
Jadi, apa namanya, untuk keep update itu kan ada waktu yang harus diinvestasikan di masa depan kalau kita pakai third party.
Biasanya kalau di GitHub itu kan sudah ada, apa namanya, ada bot-nya ya kalau kita pakai.
- Depend the bot.
- Jadi itu yang bisa bantuin kita untuk update update, keep update library kita yang ada di repository.
Jadi pakai third party bukan berarti plug and play ya sudah ditinggalin, tetap harus dimaintain juga.
Apalagi namanya dependensi hell terjadi.
- Itu sih, satu depend react 14, satu depend react 16.
Padahal kadang itu nggak kritikal, maksudnya itu bahkan mungkin nggak breaking ya,
cuma kan waktu kita npm install ya tetap jadi error ya.
Apalagi lebih parah kalau misalkan tiba-tiba project-nya berhenti.
Terpaksa, kita yang harus maintain kan, misalkan ada bugs dan bugs-nya kritikal,
terus kita send issue, issue-nya nggak dijawab, nggak di bales, terus mungkin dia bilang silahkan PR.
Ya mau nggak mau harus saya pendong tangan kan.
Jadi anggaplah kalau kita pakai sebuah library itu anggap aja seperti kita outsource ke orang.
Kecuali kalau misalkan kita lempar tangan jawab, setelah aplikasinya jadi, sudah oke,
tanda tangan, ACC, duit dapat, udah bye-bye gitu. Kalau itu si aman ya.
- Hand over jalan ya udah. Ya kan emang maintenance sama...
- Maintenance-nya beda lagi.
- Iya, dengan client yang sama tiba-tiba dia bilang,
ya udah kita tanda tangan maintenance dengan harga project yang tinggi,
terus tiba-tiba kita harus maintain banyak terpati library juga capek juga sih ya.
Harus dipikirin benar-benar.
Kalaupun terpaksa harus menggunakan terpati library, ada konsiderasi khusus nggak?
Project seperti apa yang aman, project seperti apa yang sebaiknya dihindari?
- Project yang komunitasnya sedikit itu harus dihindari.
- Dihindari ya? - Iya, karena maintenance-nya,
misalnya kalau contohnya kita lihat sebuah project yang kita pengen pakai,
ternyata library tersebut, bisa lihat ya di NPMJS itu kan,
kapan sih terakhir kali di maintain, terakhir kali di update,
terus kemudian requirement-nya note berapa, misalnya kalau mau di install pakai note ya.
Terus untuk dependensinya apa aja, kan misalnya kita bongkar gitu dependensi apa-apa aja.
Kalau misalnya itu obsolete ya jangan dipakai.
Tapi kalau misalnya yang maintain juga sedikit ya jangan dipakai juga
karena yang ngerjain open source itu nggak bisa dipaksa juga kan dia untuk update.
- Nah itu ada komentar gue bisa ngomong-ngomong open source kan, donate lah biar open source sancaran.
Nah itu cocok tuh komentarnya.
- Kalau nggak bisa donate uang, donate tenaga, jadi kontributor, iya kan?
- Iya kalau, maksudnya itu fair sih kalau kita emang pakai.
Nah itu contoh kasus yang justified justru itu sih misalnya entah gimana suatu library itu,
ya contoh lah DJS atau semacamnya kita emang udah pakai itu dan sesuai kebutuhan kita,
ya nggak ada salahnya kalau emang kita punya waktu kita invest juga ke situ.
Kan sebenarnya apa ya, kayak simbiosis mutualisme berarti kan ya dengan gabung di komunitasnya,
ikut kontribusi kan kita jadi lebih tahu, jadi bisa lebih menjamin lah kayak performa tahu keamanan
karena kita terlibat di situ.
- Terus ada pertimbangan lain sih kalau dari aku, jadi kayak aku kalau buat tanggal nih, buat formatting,
walaupun udah ada Intel, sebenarnya ada satu project yang sampai sekarang masih pakai DJS.
Sebetulnya alesannya lebih karena teranjur sih, itu dulu banget dan butuh cepet dan emang ya udah pakai DJS aja.
Cuma emang pernah ngecek, pertama kan yang dicek itu kayak yang tadi udah dibilang Ivan juga aktif di update,
ya terus supportnya emang udah ya dari pertimbangan awal juga browser dan environment support udah masuk.
Nah ada nih ketiga, coba aja iseng kita baca-baca source code-nya, kita paham nggak maksudnya
kalau itu sesuatu yang mungkin dari style kurang cocok sama kita atau bahkan kita sulit paham.
Kita nggak tahu nih apa yang, kan membaca kode orang lain itu sebenarnya kayak seni tersendiri ya.
Kadang kita nggak tahu ini apa-apaan sih, ini kenapa gini, ini munculnya dari mana.
Nah maksudnya kalau kita lihat sekilas dan kita kurang bisa pahamin kode itu entah beneran karena kurang paham
atau karena emang, karena kita nggak cocok aja sama style-nya atau sama dependensi mereka,
ya udah sebaiknya jangan dipake, kenapa?
Karena kalau misalnya suatu saat ada emergency yang kayak tadi tuh, ada yang apalah ada masalah isu dependensinya,
versinya clash atau ada vulnerability issue, kita nggak bisa dengan gampang nge-fork dan adjust sesuai kebutuhan kita.
Nah kalau misalnya kita paham dan kita cocok, kita cukup paham sama cara kerjanya,
ya udah kalau suatu hari kita butuh entah karena ada masalah atau karena kita perlu optimize aja,
ya udah kita tinggal pinjam bagian-bagian yang perlu aja kan.
Betul, betul, betul.
Oke. Dan kalau pun seandainya akhirnya kita memutuskan untuk bikin sendiri in-house,
ya alangkah baiknya juga itu di-share juga di open source aja gitu,
biar yang lain juga kalau misalkan kayak tadi misalkan momen JS gitu.
- Open source first development sih, bahasa kerennya.
- Mungkin di awal ya nggak di open dulu kan, maksudnya oh kita butuh nih momen JS kayak one day go misalkan yang tadi.
Hanya itu aja misalkan kita butuhnya, ya udah kita lihat kodenya si momen JS,
mungkin kita buat versi kita sendiri dengan bahasa Indonesia misalkan,
abis itu ya bisa kita share ke open source sehingga teman-teman atau perusahaan-perusahaan lain
yang butuh hal yang sama tapi nggak mau install momen JS,
bisa pakai versi kita gitu dan itu juga bagus buat perusahaan gitu kan.
Iya atau default juga bisa.
Ada juga satu hal yang perlu diketahui kalau kita mau open source kan,
itu nggak cuma kayak kita buat open source kan, that's it.
Kita juga harus maintain. - Maintain.
Maintain yang paling berat.
- Investment jangka panjang itu, dan itu harus ada kayak bagiin waktu.
Banyak kan maintainer-maintener open source itu sensian orangnya.
- Iya, karena itu istilahnya bukan job desk-nya dia kan.
- Iya, beda ya kalau jangan disandingkan dengan kayak FNU yang khusus main jobnya adalah maintainer dan open source.
- Tapi kan mulanya dari awal ya dia iseng-iseng bikin produk sampai suatu saat dia bisa full time kan,
sebenarnya ya itu Pat, itu jalur yang valid kalau emang... - Valid juga.
- Jalur yang sangat ideal sebenarnya, jarang terjadi.
- Jarang. - Kalau kita rilis sebuah plugin dan kita masih punya main job,
atau suatu saat misalnya kita rilis plugin sekarang, kita rajin, maintain.
Tapi 2-3 tahun lagi mungkin saja kita sudah beda job description atau sudah pindah company
yang kita nggak pakai produk yang kita buat itu, open source project yang kita buat itu lagi.
Jadi gimana mau maintain kita udah nggak pakai lagi gitu.
Dan itulah saatnya kalau ada yang mau ngambil alih di default, ambil alih silahkan.
Maksudnya ya rilis open source, yes, recommended, tapi juga butuh investasi waktu untuk main job.
- Dan sebenarnya itu seleksi alam juga kali ya, maksudnya dari kebutuhannya apakah banyak orang yang pakai,
apakah banyak orang yang butuh, dari segi si developer, creaturnya juga apakah dia bisa kayak gain traction.
Jadi kayak banyak maintainer yang tertarik bantu dan suatu saat kalau dia udah nggak bisa, si creaturnya sendiri
udah nggak bisa maintain lagi, apa ada yang nerusin, apa ada yang bisa jadi penerus,
itu kan faktornya banyak ya, sebetulnya rumit.
Cuma ada justru sebaliknya ada kasus idealnya sih, kayak Rich Harris kan ya.
Dia kan sebetulnya dulu punya, dia creator swell, tapi sebetulnya dia dulu punya kerja full time ya kan,
dia di New York Times ya. - Dia designer kan aslinya kan.
- Designer, tapi designer, kalau di sana kelihatannya kan banyak designer yang dia design tapi sekaligus coding.
- Nah dia kan di bagian data visualisasi kayak apa sih, artikel berita yang ada interaktifnya kan, data visualisation,
ya infographic yang interaktif lah. Nah dia bikin swell kan buat menuhin kebutuhannya,
kebutuhan kerjaannya pas itu kan, nah ternyata swell bisa sepopular itu dan gaining traction sebesar itu
dan akhirnya sekarang dia di hire full time, ditarik Fairsell buat kerjain ya si swell itu sih produk open source-nya.
- Oh gitu ya, bukan buat dimatikan nggak kalah SES ya.
- Swell kit nggak, biar orang yang pakai swell kit ikut ketergantungan sama Fairsell juga.
- Iya itu juga menjadi alasan kenapa perusahaan-perusahaan besar teknologi terutama di Indonesia ya,
mereka tuh jarang mengeluarkan kayak framework-framework seperti Next.js gitu,
padahal setau saya dulu sempat ada beberapa, ada satu yang saya tahu, tapi akhirnya nggak di-maintain karena ya tentutan pekerjaan.
Jadi ini kan kayak proyek hobi sama pekerjaan sehari-hari. Proyek hobi kita awal-awal mungkin kita berapi-api.
- Excited ya penasaran? - Iya.
Begitu ditumpuk sama kerjaan, deadline dan lain-lain, udah bye-bye gitu kan.
Makanya beberapa dev tools yang cukup menarik atau framework yang cukup menarik biasanya itu dikembangkan
sama perusahaan yang memang memonetisasi dari situ. Kayak Fairsell misalkan, dia bikin framework walaupun tidak ada hubungan
langsung dengan produknya dia yang adalah hosting dan lain-lain, cloud gitu kan.
Tapi banyak orang yang akhirnya pengguna Next.js akhirnya pakai Fairsell. Begitu juga sebaliknya,
pengguna Fairsell juga menggunakan Next.js karena sedikit-sedikit mereka integrasikan kan.
- Kayak function apa? - Itu sebagai funnel sih.
Karena integrasinya gampang kan. Bahkan front-end developer pun nggak usah ngerti infra,
bisa langsung deploy serverless semua. Udah itu kan sebetulnya kayak apa? Bisnis strateginya mereka lah.
- Yes, gitu. Dan akhirnya yang terkenal-terkenal ya semacam itu kan. Next.js, kemudian Remix.
Remix juga dikembangkan oleh beberapa orang gitu. Dan barusan dibeli oleh Shopify.
- Barusan dibeli Shopify ya. - Gatsby kemana ya Gatsby?
Gatsby. Udah bikin perusahaan sendiri, sudah difunding, kemudian turun. Dulu naiknya luar biasa cepat.
Dulu naiknya luar biasa cepat. Ada yang menggaung-gaungkan bahwa ini adalah WordPress killer gitu kan.
Karena kan Node.js JavaScript itu belum punya killer app seperti PSP kalau WordPress gitu kan.
Jadi itu digaung-gaungkan digadang-gadang kan, "Iya, sekarang melempam ya." Nggak tahu ini nasibnya gimana.
- Iya. Gatsby. Karena barusan teringatnya Gatsby, karena barusan selesai masalah Gatsby di hari ini tadi.
- Masih pakai Gatsby. - Karena legacy code kan.
- Oh, legacy code. - Gatsby aja udah legacy ya. Luar biasa ya. Game stack ya.
- Umur library di dunia front-end web itu kayaknya pendek. - Kayaknya kalau setahun itu udah lama banget ya gitu ya.
- Udah usur. Kalau nggak bisa bikin inovasi baru kayaknya cepat itunya ilang.
- Tahu nggak masalahnya apa? Double rendering. Aduh, riak lagi double rendering lagi.
- Astro dong. - Paling males berusaha sama application itu double rendering.
- Di performance ya kenanya. - Iya. Sudah nge-load, nge-load lagi.
- Nah, itu kalau buat temen-temen yang nonton yang tertarik sama itu, kita ada episode yang tentang apa sih waktu dulu?
- Itu island ya. Masalah itu kan mulai dibecain sama island architecture.
- Episode berapa? Episode 2 CSS. Episode 1. - Episode 1 ya. Island architecture.
- Iya, episode 2 kan kita mulainya dari 0. - Kita kan ini JavaScript.
- Jelas script banget orangnya. - Iya, sekarang kan lagi apa, itu kan, framework-framework baru lagi bermunculan kan.
Ada Quick, ada Astro, ada apa lagi itu? Banyak. - Fresh punya nya Denoo.
- Iya, fresh Denoo. Ada macem-macem, ada banyak. Bahkan itu di front-end.
Di backend juga mulai banyak kan rantai-rantai yang baru kan. Ada Boon.js, ada Denoo sebelumnya.
Terus juga kemarin itu, sembari di launching-nya Next.js versi 13 juga mereka bikin banding sendiri kan, Turbo.
- Bo-pack. - Ini Turbo-pack.
- Belum pakai gue. Bagus ya sih? - Iya.
- Udah pakai belum? - Yang bikin adalah yang bikin webpack juga.
Jadi sampai gitu ya polanya. - Serius ya, yang bikin webpack ya?
- Iya, karena sekarang dia juga di-hire sama Versel. Si yang bikin webpack itu. Yang bikin atau maintainer utama atau apa lah semacamnya.
Itu di-hire oleh Versel. Kerja di Versel.
- Dia pakai SWC yang adalah Rust. - Rust-based.
- Iya, terus ada yang menggadang-gadangkan kalau Turbo-pack ini lebih cepat 10 kali dibandingkan VT.
Habis itu FNU nyobain. Ternyata enggak 10 kali lebih cepat. Beda sedikit aja.
- Iya, nafasnya. - HMR-nya yang lebih cepat.
- Hot module reloaded. - Iya.
Itu kan VT kan kayaknya baru setahun belakangan ya populer gitu kan. Terus tiba-tiba muncul Turbo-pack.
Orang udah sibuk, "Ini VT gimana? Ini kok ketimbangan?"
Gitu kan. Udah sibuk. Padahal biasa-biasa aja santai aja kali.
- Iya, dan itu sebenarnya bahasa marketing banget ya sih. Oh iya. - Bener ya, Tobias Copper tuh.
Wah, Vandika ngikutin banget. Mantap. Kita aja nggak tahu namanya.
- Jadi gini, kadang itu bahasa marketing juga sih. Misalnya hot module reloadingnya itu kan fit udah cepet banget ya.
0,1 millisecond. Terus katakan lah, terus si Turbo-pack itu emang betul 10 kali lebih cepat.
Tadi berapa? 0,1 millisecond terus jadi 0,01 millisecond.
- Enggak. - Itu signifikan nggak sih buat kita? Kita ngerasa nggak?
- Si fit itu 0,9 dan si Turbo-pack 0,1. - Itu beda 0,8.
- 0,9. Dibuletin ke atas. - Dibuletin gitu ya?
- Kan dia keren. - 10x gitu. 10x engineer.
- Jadi sebenarnya masih di bawah 1 second gitu. Masih instant.
- Iya. - Cuma ya kalau kita ngelihat apa kita switching.
- Realistically. Maksudnya mata manusia itu sadar nggak sih?
Jadi kan sebenarnya itu bukan poin yang kuah banget. Cuma kalau pakai bahasa marketing kan 10 kali lebih cepat.
- Wow. - Wah, langsung heboh ya. Ini kita harus upgrade nih.
- Harus migrate nih. - Itu blazingly fast.
- Blazingly fast. - Hype driven development.
- Iya. Begitulah. Itu memang naturalnya di dunia JavaScript seperti itu ya.
Mungkin di back-end tidak se-wah itu ya. - Oh, nggak juga. Justru kayak PHP kan update terus nih.
Bagi teman-teman nih, sekalian sedikit ngasih tau. PHP 74 bulan depan udah...
- Dipikir-pikir. - Oh, cepet banget. Kayaknya belum terlalu lama ya.
- Nggak. Maksudnya kalau back-end. - PHP 74 itu. Oh, framework ya framework.
- Iya, kalau framework back-end kayak PHP, Laravel udah berapa lama sih berjaya gitu. Belum ada...
- Laravel tuh update terus loh. Tapi bit pakai bit sekarang yang baru.
Nah, kayaknya yang baru itu yang khusus buat PHP 8 ya, kalau nggak salah. Laravel yang baru.
- Iya. Terus juga Node.js lah yang masih JavaScript. Express yang masih banyak.
Ya walaupun ada yang lain ya, tapi yang istilahnya yang masih di top of money itu kan masih express.
Apa lagi? Ruby on Rails, Python, Django, gitu. Jadi kayak nggak secepat yang di front-end gitu.
Front-end bahkan nggak usah nyebut framework gitu kan. Nggak usah nyebut framework.
Nyebut apa bundler-nya aja tuh udah berubah berapa kali, gitu kan. Dari Gulp, habis itu ada webpack, habis itu ada feed.
Sekarang ada tubuh pack. - Web API. Web API aja cepet banget rilisnya, Mas.
- Nah, itu. - Makanya kita ada ngobrolin web.
- Setiap minggu ya. - Ada konten terus aman ini.
- Yang benar aman. - Web API aja banyak.
- Dan nanyain, kita mau bahas apa nih? - Lo kan udah deh, udah banyak ya.
Apa lagi yang mau dibahas nih? Kita sudah berapa jam? Oh, belum jam 9, masih panjang.
- Tadi belum, apa benchmark competition-nya. - Belum habisin sih.
- Oh iya. Jumatnya tadi dimana? Ivan, Ivan, coba. - Iya, iya, iya.
- Bagaimana caranya kita bisa tahu, bisa ngetes salah satu yang perlu kita bandingkan
atau yang perlu kita konsiderasi adalah kecepatannya, kan.
- Kecepatan memproses. - Kecepatan memproses sebuah...
- Jadi, saya mencoba membandingkan antara momen JS menggunakan JSBenz.me.
- Zoom in dikit, tidak kelihatan. - Boleh zoom in dong, zoom in.
- Momen JS dan Intel. Jadi, coba round. Dan ternyata, yang mana lebih cepat?
- Float twist. - Kayaknya momen ya.
- Nah, momen lebih cepat. Kenapa? - Kok bisa?
- Kok bisa, gitu. - Kok bisa?
- Kita coba yang lain. Luxon dengan Intel. Eh, mana Intel?
- Luxon ini library untuk datetime juga ya, sama ya?
- Iya, salah. Saya belum copy paste. Ini hasilnya sama ya. Intel format hasilnya sama.
- Oke. - Luxon dan...
- Kok bisa lebih cepat terparti ya? - Loh.
- Itulah. - Cuma... Oh, running-nya emang satu persatu ya. JSBenz-nya.
- Ya, lebih lambat. - 97% slower, 98% slower. Jauh banget.
- DGS dengan Intel untuk format parsing.
Lama hasilnya ya. Jadi, meskipun menggunakan web API, bukan berarti lebih cepat.
Tapi ada trade-off di sini ya. Ada trade-off yang perlu diketahui.
Kalau misalnya kita load library, pertama ada overhead yang perlu dilakukan, yang di download ya.
Ini saya nggak tahu berapa kilobyte, tetapi tadi dari momen JS ya, Banelphobia tadi mengatakan sekitar 200 kilobyte.
Sedangkan ini 0 kilobyte. Terus pertanyaan apakah di website teman-teman
menggunakan 743 kali operation per second untuk parsing dead format.
- Dalam satu komponen, mungkin nggak ada 70 ribu tanggal sekaligus.
Nah, kan tergantung aplikasinya.
- Iya. Sedangkan loading untuk ngedownload 200 kilobyte tadi di 3G itu butuh 1,5 second.
1,5 detik, jadi itu trade-off.
Nah, jadi kalau nggak butuh-butuh amat, ya ini kan yang paling sering membuat lambat bukan operation-nya kan sebenarnya.
Gitu. Jadi, meskipun di berdasarkan hasil tes ini, saya nggak tahu bagaimana dia melakukan tes ya.
Masalah hasil tes ini, mungkin dia nggak pakai browser atau gimana, saya nggak tahu.
Dia lebih lambat, tetapi menurut saya kalau di-compare dengan trade-off harus download 200 kilobyte
atau paling kecil tadi si DGS ya, 2 kilobyte.
Mungkin saya lebih konsiderasi kalau harus memilih library, saya lebih memilih yang paling kecil
untuk mencapai kebutuhan saya kalau harus memilih, daripada memilih library yang berat untuk didownload oleh user.
Oke.
Teruntungan bisa ngetes array juga bisa parsing string, parsing yang lain bisa coba ditest di sini juga.
- Baru tahu nih ada JSBench.me, baru tahu ada tools kayak gini, seru juga.
Ya, sekadar buat mengetahui bagaimana sih performa code yang kita tulis di-compare A dengan B yang Apple to Apple ya.
- Tapi ada benang merahnya juga, beberapa waktu yang lalu saya sempat nonton video dari yang bikin GunJS database gitu ya.
Itu dia sempat compare beberapa library untuk parsing JSON, yang sebenarnya sudah ada.
JSON.parse itu ada kan.
Tapi ternyata, library-library yang lain yang terparti itu beberapa ada yang jauh lebih cepat daripada JSON.parse.
Karena mungkin mereka sudah lebih advance aja ininya, codingnya atau algoritmanya dibandingkan yang standar.
- Atau ada trade-off. - Iya, trade-off tadi. Kita harus download dulu.
- Bukan, maksudnya mungkin si algoritma yang dipakai di Web API, ingat yang di Web API itu kan java skip engine, si developer-nya beda kan menulis code-nya.
Kan speknya mungkin sama.
- Speknya sama, implementasinya bisa beda, dan pertimbangan backwards compatibility-nya itu tinggi banget kan.
Pertimbangannya banyak lah, nggak bisa tiba-tiba diubah di optimize maksimal.
- Yang nge-develop third party library atau library javascript itu ada trade-off yang dilakukan.
Mungkin nggak support dengan Unicode, dia nggak peduliin.
- Atau tidak optimize untuk engine-nya Firefox mungkin gitu ya.
Bisa jadi atau nggak support UTF-16, UTF-64, dia cuma UTF-8, mungkin ya, dia cuma support ASCII karakter.
Bisa jadi, trade-off yang dilakukan banyak kan. Jadi bisa lebih cepat.
- Contohnya, saya sering membandingkan antara looping di javascript, antara forage atau map, itu mana sih yang lebih cepat?
Coba aja teman-teman PR di rumah, apa sih yang lebih cepat antara map, forage atau for, untuk looping di javascript?
- Kayaknya kalau boleh nebak, for yang paling cepat. - Yang paling lama biasanya punya yang paling cepat ya.
- Yang paling lambat itu yang paling lambat, forage. - Tapi banyak banget yang pakai forage.
- Yang pakai forage. - Masa banyak yang suka pakai forage, saya lihat beberapa, maksudnya di dunia saya ya.
Nggak tahu kalau di dunia teman-teman, di dunia saya melihat developer-nya, kok pakai forage sih?
- Kita udah pakai map sekarang, semenjak react mah udah map semua.
- Apa-apa di map, apa-apa di filter. - Yang tahu nya map filter reduce udah itu.
- Map filter reduce. - Funksional programming adalah map filter reduce.
- Oke, Eka, ada yang mau disampaikan? Apa nih, fitur CSS? Atau mau jawab pertanyaan dari Slido?
Ada pertanyaan bagus nih dari Slido. Ini, front-end logging, yang benar dan baik gimana?
Soalnya kalau build production kan kodenya udah di minify, dan sulit kalau mau cari tau error-nya kenapa.
- Tergantung error dimana gak sih? - Tergantung error dimana? Bukannya bisa pakai map ya?
- Css.map? - Css.map. Chrome terbaru, Chrome terbaru, 108, ntar gue cari itu.
Kita kasih map, map file, kita bahkan bisa kasih breakpoint, dan di tracing-nya itu bisa lebih jelas, bisa kita filter out tracing-nya.
Jadi bisa pakai developer console. - Langsung pakai developer console bisa ya?
- Iya. - Oke, oke. Terus ada teknik logging yang lain gak?
Bisa pakai ini kan kalau gak salah ya? Kayak semacam, ini nama product sih ya.
Jadi kayak ada terparti yang kalau ada error dia akan kirimin ke sebuah service, kemudian kita bisa lihat di dashboard-nya.
- Aku punya dashboard-nya. Itu nama product-nya apa sih? Error logging service ya?
- Error logging service, kayak Regan, Centri, dan lain-lain itu ada banyak.
Itu menjawab gak sih pertanyaannya? Logging itu logging error kan bener ya?
- Bisa macam-macam ya, logging performance juga bisa.
Sebetulnya kalau yang paling simpel, paling basic, tetap console log atau warn atau error ya, sesuai kebutuhannya kan.
Dan emang di kode kita handling-nya aja. Maksudnya kadang kita lupa try catch ya, try catch atau semacamnya.
Jadi kalau itu kan ngaruh juga, kadang ada suatu kesalahan, error-nya karena gak di-catch atau gak di-handle dengan baik, error-nya gak jelas apa.
Nah itu kan investigate-nya agak susah juga, cuma kalau kita catch kan lebih jelas karena pas kita nulis kodenya kita tahu tuh konteksnya apa.
Apa yang gak ada atau apa yang hilang, missing atau invalid.
Tapi yang tricky-nya adalah ketika istilahnya mungkin di kita gak kebaca atau gak kelihatan.
Tapi yang tricky-nya adalah di user, bukan di laptop kita atau di komputer kita.
Jadi makanya butuh tools-tools seperti Centri, tujuannya adalah setiap ada error dia akan kirimin.
Oh, di user ini, browser-nya ini, versi OS-nya apa, error ini nih.
- Terus di round apa dan apa, request shader-nya apa. - Iya.
Tapi jangan lupa kalau misalnya produk kita beroperasi di area yang kena GDPR 100 jenisnya, itu ya harus ada disclosure-nya kan.
Harus ada disclosure-nya dan kita harus, itu kan bisa ada personally identifiable data ya.
Karena itu kan ngirim juga apakah user dalam keadaan login atau gak.
Kan bisa aja misalnya error-nya waktu user yang login, ngeakses route yang mungkin untuk guess atau apa.
Itu punya status login user kekirim, cookies kekirim, request shader dan mungkin referrer segala macam kekirim.
Nah itu kalau kita punya kebutuhan legal compliance, kita harus punya mekanisme buat handling itu.
Cuma kalau soal topic error logging ya yang paling manjur, paling oke ya kayak gitu sih pakai layanan yang buat logging ya.
Ya, itu kalau untuk sudah di sisi klien. Tapi kalau dari sisi kita developer, ya itu tadi.
- Jangan lupa di handle dengan try catch kah atau dengan apa? - Sama satu lagi dependensi, kembali ke dependensi.
Pakailah tools yang ada di browser namanya Network Request Blocking.
Coba blocking-blocking misalnya contoh, ada kita memakai jQuery contohnya.
- JQuery lagi. - Tetapi, pakai jQuery. Terus ternyata saat jQuery kita download dari CDN, ternyata CDN-nya lagi down.
- CDN-nya diblock. Apa yang terjadi? - Apa yang terjadi dengan situs kita.
Masa jadi blank white space atau jadi berantakan, usahakan.
Coba tes-tes aja pakai Network Request Blocking, klik dari JavaScript kita, URL-URL mana yang jadi dependensi.
Jangan sampai kayak contohnya, contoh misalnya kita paling sering nih kejadian adalah dia script third party atau vendor di load dari tech manager.
Tetapi untuk ngerunning script itu, dia nge-load third party vendor ternyata diblock oleh si ad blocker.
Tetapi tech managernya enggak. Akhirnya JavaScript jadi error. Runtime jadi error kan.
Coba gitu, kalau misalnya ada misalnya Google Analytics, misalnya ada analytics-analytics lainnya sering diblock oleh ad blocker karena dia tracking.
Coba tracking-tracking itu atau script-script tertentu diblock, maksudnya diblock dan cek apakah kode kita masih aman enggak.
Jadi kita harus seolah-olah berada di sisi klien. Kode klien berarti, oh jangan-jangan pakai VPN nih. Bisa jalan nggak kode kita pakai VPN?
Jangan-jangan ada ad blocker. Tahu-tahu ad kita pada nggak jalan tuh gara-gara ad blocker.
By default rata-rata semua browser sudah pakai ad blocker. Jadi kita harus aware juga kalau kita pasang analytics dan kita ada di kode kita
ngedependensi ke analytics tersebut, masa kode kita error gara-gara analytics-nya nggak ke-load?
- Harus ada itu ya, callback-nya gitu ya? - Iya, kita harus tahu.
Nah itu bisa applicable juga sebetulnya yang soal third party itu bisa ke first party komponen kita sendiri kan.
Misalnya gini, kadang ada kasus yang umum kita fetch menjalankan network request ya.
Cek user ini punya pos atau nggak. Kalau usernya punya pos, mungkin kita punya pos komponen.
Tapi kan itu lazy loaded kan, karena satu belum tentu user sedang di dalam keadaan login, dua belum tentu user punya pos, jadi komponen pos kita juga lazy loaded.
Itu kan sebenarnya point of failure-nya banyak ya. Bisa nge-fetch-nya yang gagal, network request-nya ini yang gagal entah kenapa.
Ya bisa aja service kita kan sekian detik down bisa. Jadi emang pos-nya nggak muncul.
Bisa juga mungkin aja ada kasus kita import lazy loaded komponennya yang gagal.
Nah itu kalau misalnya berkaitan sama perkara logging error tadi, itu kan tergantung level kita handling-nya gimana pas kita bikin kodenya ya.
Jadi kalau itu hal-hal yang bisa di expect, bisa di handle dari awal itu sebetulnya.
Nah ini juga sering nih kejadian ya, lupa handling data null atau undefined.
Itu salah satu kekurangannya JavaScript ya.
Selalu cek response tipe data sebelum eksekusi.
Response tipe datanya seperti apa. Atau bisa pakai, terus ini kalau di ESLint gitu bisa ditangkap nggak sih? Nggak bisa ya?
- Karena ini runtime. - Kalo kasusnya data bisa null, ya tergantung type definition kita kan.
Kalau kita punya type definition yang bener.
- Maksudnya kalau ngarapin response dari network request gitu. - Dari RCPI gitu-gitu ya.
- Kan kita nggak bisa. - Harus cek lagi ya. Kecuali GraphQL mungkin ya lebih strict kan.
Iya, GraphQL ada types-nya soalnya.
Eh yang membantu banget itu tuh, apa namanya? Tandatanya itu loh, optional change.
- Optional change. - Itu namanya susah.
Ya optional, apa, kalau dulu kan kita harus cek kan, if data dot status,
ya data dot length sama lebih besar dari 0, maka kita tampilin data dot name gitu kan.
- Tapi sekarang kita bisa dengan data dot name. - Data dot datanya dot map.
Lumayan bantu lah. Apasih itu namanya? Penasaran.
Ya, atau yang kalau mau lebih advanced lagi yang berhubungan dengan null atau undefined
untuk menangani supaya nggak kejadian yang aneh, ya bisa pakai yang type language
yang dikompilasi ke JavaScript. Contohnya ada typescript, ada rescript,
script-script yang lainnya, itu mereka udah. - Flow gak sih? - Flow, kayaknya udah nggak deh.
Ya, kalau bahasa-bahasa seperti yang ada type-nya itu dia tidak bisa menerima null.
Sebenarnya bisa, cuma harus di handle kan, harus di handle.
Kalau null itu maka harus apa gitu.
Jadi lebih aman dari sisi user, meskipun dari sisi engineer ya capek.
Tapi jauh lebih capek kalau dapat error dari user.
Itu lebih capek lagi, mendingan capeknya di awal.
Tapi begitu udah di production, udah aman.
Oke, ada lagi yang mau dibahas? Eka atau Ivan?
Apa ya? Gak ada sih. - Gak ada ya. - Cukup kayaknya ya.
Cukup ya, udah satu jam kita ngobrol panjang lebar sampai ngelantur kemana-mana.
Menarik juga. - Seru ya.
Jadi mungkin untuk malam ini kita udahan dulu ngobrol-ngobrolnya.
Kita ketemu lagi minggu depan, insyaallah.
Kalau gitu kita pamit, kita bertiga pamit.
Saya Riza, ada Ivan dan juga ada Eka, sampai ketemu lagi minggu depan.
Selamat malam. - Hai, malam.
Deskripsi asli dari YouTube
- Contoh penggunaan Intl di https://bwa-luxspace-pwa-git-main-riza.vercel.app/, kode sumbernya: https://github.com/rizafahmi/bwa-luxspace-pwa/blob/8de386e0b4224691b41661472aabe2d96a96a26f/src/utils.js - Relative Time Format: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/RelativeTimeFormat/RelativeTimeFormat - Intl di mdn: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl - https://bundlephobia.com/ - Number Format: https Kunjungi https://ngobrol.in untuk catatan, tautan dan informasi topik lainnya.
Episode Terkait
9 Agu 2023
Ngobrolin URL
Episode ini bagian dari niat baru mereka: menyelipkan topik yang benar-benar mendasar setidaknya sebulan sekali, alih-al...
14 Feb 2023
Ngobrolin Otentikasi
Otentikasi dibedakan tegas dari otorisasi lewat analogi bandara: mencocokkan wajah dengan paspor dan tiket itu otentikas...
26 Agu 2026
Modern Web UI
Episode ini berangkat dari satu keluhan yang sangat spesifik: web UI jadi berantakan begitu fitur LLM ditempelkan ke apl...
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 .