Ngobrolin WEB edisi Offline Surabaya
Ringkasan Episode
Bantu KoreksiEpisode ini adalah sesi tanya jawab Ngobrolin Web versi offline yang diadakan di Surabaya. Pembahasan mencakup berbagai topik teknis seputar pengembangan web, mulai dari perbedaan penggunaan RUM (Real User Monitoring) dan Google Analytics, tantangan menggunakan AI untuk front-end development, keunggulan Tailwind CSS untuk developer yang tidak terlalu mahir CSS, optimasi performa web dengan banyak third-party libraries, hingga perdebatan tentang penggunaan ORM seperti Prisma dan Sequelize dibandingkan SQL raw. Episode ini juga membahas tentang browser automation, web scraping, dan cara kerja spesifikasi teknis web antar browser modern.
Poin-poin Utama
- •RUM (Real User Monitoring) seperti New Relic digunakan untuk memantau error dan performance metrics termasuk Core Web Vitals, sedangkan Google Analytics lebih fokus pada user behavior, device usage, dan traffic analysis
- •AI tools seperti v0.dev dapat membantu generate komponen front-end, namun developer tetap perlu memahami prinsip-prinsip front-end seperti validasi form, state management, dan event handler untuk prompting yang efektif
- •Tailwind CSS sangat membantu back-end developer yang kurang mahir CSS karena menyediakan utility classes yang konsisten, dengan custom config untuk design tokens yang bisa digunakan lintas project
- •Untuk mengoptimalkan performa dengan banyak third-party scripts, gunakan konsep critical rendering path dan defer loading script yang tidak diperlukan di awal (below the fold) menggunakan intersection observer
- •ORM seperti Prisma dan Sequelize menawarkan developer experience yang baik dengan TypeScript definitions, namun dapat menghasilkan query yang kurang optimal untuk use case kompleks, sehingga perlu trade-off antara kemudahan dan performa
- •Browser automation tidak hanya untuk testing, tetapi juga dapat digunakan untuk scraping data dan otomasi tugas-tugas repetitif, selama dilakukan dengan etika dan menghormati rate limit dari website
- •Spesifikasi teknis web (HTML, CSS, JavaScript API) dibuat oleh konsorsium yang terdiri dari perusahaan browser dan komunitas, dengan Web Platform Tests (webpt.fyi) digunakan untuk memastikan konsistensi implementasi antar browser
Oke, halo teman-teman semuanya, ketemu lagi di tan, meskipun hari ini, bukan selasa malam, tapi kita sempatkan untuk ngobrolin lagi.
Di sini ada yang suka nonton gak sih, penasaran, berapa orang suka nonton?
Banyak loh, terima kasih ya.
Jadi, buat teman-teman yang mungkin belum familiar, kita tuh biasanya live setiap selasa malam, jam 8 waktu misio badan, kita ngobrolin segala hal tentang web, alasannya kenapa?
Karena salah satunya adalah, kita sering bingung kalau diminta untuk jadi pemijara seperti ini, mau ngobrolin nombor apa?
Karena web itu kan besarnya, ada tadi web UI, CSS, ada ML, ada JavaScript dengan berbagai framework-nya, ada back-end juga, ada apa lagi ya?
Ada accessibility, ada performance, banyak sekali, security, jadi karena kita bingung akhirnya kita bilang, akhirnya ada AI.
Web AI ya, dan karena kita bingung akhirnya kita coba ngobrolin aja seminggu sekali, akhirnya yaudah kita live.
Jadi kalau teman-teman yang belum join, bisa selasa depan join di youtube saya, youtube.blogspot.com/zapahni, silahkan subscribe aja biar ada notifikasinya.
Oke, jadi ini adalah edisi kedua dari ngobrolin web versi offline, yang biasanya kita live streaming, sekarang kita offline khusus untuk menghadiri teman-teman di Surabaya.
Sebelumnya kita edisi pertama itu di Bogor ya, sekarang di Surabaya, jadi kita akan mencoba menjawab pertanyaan-pertanyaan yang sudah teman-teman sampaikan melalui slibro.
Dan kalau sudah ada pertanyaan yang sama, tinggal di input aja biar main nampas.
Oke, kita mulai, oh nggak kelihatan disini, kita mau jauh ke mana dulu?
Kapan kita menggunakan ROM atau Real User Monitoring/Google Analytics?
Ini saya sering menggunakan ROM, kalau di projek-projek saya banyak menggunakan dari New Relic, saya menggunakan ROM ini untuk mendeteksi adanya portal error,
error-error yang lain dari Sunpage Load, dan juga dari World Performance atau Core Web Vitals, bisa di-setting juga di New Relic.
Sedangkan kalau dari sisi Google Analytics, biasanya saya mendeteksi device apa yang digunakan kebanyakan oleh user, juga bounce rate, dan kemudian page apa yang paling sering di-visit,
dan juga part-nya mereka, user joining-nya mereka, kadang bisa dideteksi dari, kalau misalnya web-nya ada transasional, di-detek dari, minta jaringnya si itu ya Aida?
Minta jaring, minta jaringnya.
Terus kemudian kalau dari Google Analytics biasa mengecek traffic, base, atau user behavior lah.
Kalau dari New Relic lebih ke arah technical data yang perlu saya dapatkan, seperti yang saya sudah sebut tadi, performance.
Saya ingin bertanya tentang web-pre, mohon maaf kalau web-pre kita belum ada yang mampu menjawab, tapi ini ide yang bagus,
balik banget. Ini kita ambil dulu, nanti kita bisa cari nara sumber yang lebih kompeten ya, untuk topic web-pre, nanti mudah-mudahan bisa dibahas di Google,
nanti ada kemudian yang sesi hari Selasa malamnya. Nanti lagi port aja, nanti kita dapat nanti ya.
Saya ingin berbicara dengan N, cari port N, apa-apa, tidak ada lagi.
Kalau vzroot, kita kasih portnya kata-kata ya, coba aja vzroot, misalnya kita minta buat login port,
vzroot bisa tuh langsung buatin semua. Tapi ya itu tadi, ada hal-hal yang perlu diperhatikan, tetap perlu front-end atau full-stack sih.
Jadi secara komponen, emang akan di generate input, button, jadi kalau dari segi, mungkin lebih ke visual desainnya, kita males,
bahkan aku punya yang front-end-nya, males pikir sisi visualnya, tapi fungsionalitas front-end itu kan bukan cuma tampilan visual, tapi banyak faktor fungsionalitas.
Misalnya input, ada validasinya required atau enggak, terus misalnya validasinya formatnya harus seperti apa, terus kalau misalnya input itu error,
Lihat transkrip lengkap (397 segmen lagi)
itu kan berkaitan dengan state form-nya sendiri, misalnya biar di-submit aja, terus nanti dibalikin error, atau jangan biarkan user men-submit form itu,
misalnya button-nya tetap disable sampai semua validasinya sudah betul. Kan sebetulnya banyak faktor-faktor non-visual dari suatu UI front-end,
jadi walaupun, ya bisa prompting, itu kan bisa ditambah dengan prompting tadi, misalnya pakai code chat, misalnya pakai Gemini di IDX atau Popilot dan lain-lain,
tapi kita tetap harus tahu prompting hal-hal apa yang perlu diperhatikan dari suatu UI.
Jadi kalau males lurusin front-end itu, ya tetap minimal enggak males prompting dengan teknik-teknik atau prinsip-prinsip front-end yang ada.
Vigma sudah bisa AI, tinggal prompting, ya potila AI.
Alternatif lain mungkin kalau nanti front-end bisa hire developer yang males suka front-end, ya? Ini dia negasi, ya?
Saya back-end, murni, saya nggak suka front-end.
- Panggilin Haider. - Haider, jangan jadi lagu.
- Solution lain, saya suka Terwin. - Oh.
- Siapa sinyalah Terwin? - Lu.
Mantap, kita sahabat.
Ya, saya pakai Terwin dan saya suka pakai Terwin dan saya support Terwin karena dari sisi build tools-nya,
kalau pakai Terwin itu saya build utility-utility atau CSS yang tak terbatai.
- Bagaimana bisa muncul? - Oh gitu, mantap.
Utility-utility yang nggak dibutuhkan juga bisa di-remove dari Terwin-nya.
Jadi saya back-end dan saya pakai full dengan Terwin.
Jadi terpantung, oh iya, dari sisi Figma atau kalau dari Figma saya generate code-out V0 juga,
dia bisa generate-nya pakai Terwin, ya?
- Bisa. Terwin, ya. - Ya, Terwin, ya.
- Dan Next. - Atau React.
Jadi, ya, ke depannya, sebagainya. Mempermudahin saya, ya.
Jadi front-end itu bukan cuma visual, cara pedingat, emang kalau Terwin sih, ya, Terwin itu sangat mempermudah.
Tapi ya itu fungsionalitas, kapan suatu komponen perlu di-load, kapan nggak.
Terus action-action-nya, misalnya event listener-nya, on-input gimana, on-click gimana, event handler-nya apa.
Terus biasanya ada state-state-nya, UI-state-nya gimana.
Nah, itu perlu dipikirin atau prompting atau delegasi ke developer lain.
Seperti informasi juga, saya juga back-end dan pada saat itu saya disusah jepaskrim.
Tapi waktu itu jamannya diquery ya, jepaskrim vanilla diquery.
Terus sekarang kerjaannya jepaskrim.
Gimana dong? Jadi karma, ya.
Jadi kalau gak susah, ya itu, satu delegasi, kedua, kenapa?
Kalo gak suka dia, mungkin ada sesuatu yang problem.
Ya, karena jepaskrimnya saya suka.
Tapi kalau CSS-nya itu, iya, mungkin bukan.
Skin issue, ya.
Yang itu.
Apalagi menurut saya, terumahnya adalah dapet desainernya itu bukan desainer web.
Jadi dapet desainernya itu desainer yang khusus untuk grafik banner yang di...
Grafik desainer ya?
Ya, grafik desainer.
Kasihnya PNG gitu ya?
Kalo foto Shopeye.
Tapi ya itu motot gitu, maunya lengkungannya itu seperti itu.
Oh iya, bahkan ini harus absolu gitu ya?
Iya.
Jadi hidup saya tuh habis aja, geser-geser satu mixer, satu mixer.
Akhirnya ya, akhirnya position absolu semua saya.
Itu important?
Important.
Itu akhirnya, karena saya udah terlalu cekin, ini gimana sih momen kita bisa persis disitu?
Itu balik lagi, antara grafik desainernya yang salah, apasanya yang skill issue saya tak tahu.
Makanya jadi terlalu banget dengan CSS-nya, sudah lah saya tinggalkan saja.
Dan saya berali ke back-end dan jawab masing-masing.
Jadi sekarang coba kita jadi pelan-pelan, kita tahu semakin lama semakin cinta, nanti kita jadi front-end melayang.
Kalo saya sekarang, justru kalo di Tailwind gak bisa, mati setengah desainernya.
Desainernya yang selalu belajar Tailwind.
Desainernya belajar Tailwind, ini loh, ini loh, positioning dan layout itu seperti yang ada di Tailwind.
Dan ikutin itu.
Kalo buat anak non-end juga bisa manfaatin Tailwind buat menginakan temen-temen ke back-end dan full stack kalian.
Caranya, Tailwind kan bisa custom config to custom token, custom config.
Gimana caranya, tag token sama desainer grafisnya, token.
Paksain harus pake yang namanya desain token sekalian mengidotasi biar gak kayak desainernya yang tadi.
Terus kalau misalnya kalo di halaman A fontnya kurang 14, di halaman B tiba-tiba item yang harusnya sama tiba-tiba beda dikit.
Kita ngomong edukasi aja, mungkin lalu mungkin gak, cuma biasanya kalo timnya gak toksiksian, kan lebih kebaikan juga.
Jadi kita enforce yang namanya desain token, desain token itu bisa dimasukkan ke custom Tailwind config.
Custom Tailwind config itu bisa dipakai dari berbagai project apapun, Vanilla JavaScript, Power React.
Itu kan mempermudah teman stream kita untuk menggunakan yang gak bisa CSS.
Ya udah gak usah banyak mikir, pake yang udah ada.
Terus kan udah terbantu juga dengan di Viscode juga ada perang Intel Wind-nya ya.
Jadi udah ada auto-fill dengan semua settingan token yang sudah kita bukut.
Pertanyaan berikutnya, bagaimana cara memoptimalkan performa aplikasi web modern dengan banyak perparti libraries?
Ini perhubunganan corporate portal.
Biasanya begini ceritanya, webnya sudah saya atau sudah kita develop dengan sangat indah, cepat dan bagus.
Tetapi dirusak oleh tim marketing dengan GTA.
Ada yang pernah relate, GTN kita tambahin.
Terus tim marketing semana-mana menambahkan koden dari mana pun yang mereka mau.
Ceplokin, terus deploy, terus akhirnya website jadi rusak.
Itu paling selim.
Yang biasa yang disalahin, kita.
Terus kita dianakan sana.
Ini kalau kita matikan GTN cepat kok.
Tapi kita kembali.
Memoptimalkan performa aplikasi web modern dengan banyak perparti di perangkat dan spesifikasi rendah.
Oke.
Yang pertama kita harus saat kalian bisa baca yang namanya critical rendering path.
Ada satu bacaan, nanti kalian bisa cari di Google.
Udah lama banget, itu dari Google, dari web.dev.
Critical rendering path.
Jadi kalian mau ngerti bagaimana saat browser melakukan initial page load dan melakukan rendering.
Ada random blocker, ada random block seperti CSS, On, itu random blocking.
Artinya jika value itu belum didapatkan, maka process rendering stop sampai value itu selesai didapat.
Dan ada cara untuk optimalisasi.
Nah kembali ke third party.
Kita harus memiliki mana third party yang dibutuhkan di awal rendering dan mana third party yang tidak perlu di awal.
Jadi semua third party yang tidak butuh di awal page load, di-defer aja ke belakang.
Artinya setelah page load selesai, dia baru random.
Contohnya adalah command system.
Jika kalian punya, anggap aja pada situs berita.
Lalu kemudian ada command system.
Command system-nya zaman dulu itu sempat ada yang namanya Discuss.
Kalau kita pikirkan, command system itu kan ada di bawah banget ya di article.
Arti kalau bahasa text-nya below the fold.
Dan tidak perlu di-render paling awal.
Terakhir-terakhir aja ya?
Terakhir, itu udah.
Jadi strateginya adalah bisa menggunakan intersection observer.
Jika user-nya scroll sampai mungkin 200 pixel sebelum element itu muncul, baru CSS-nya di-load.
Contohnya seperti itu.
Itu untuk command.
Ada mungkin ya paling sering ads lah ya, paling susah ads.
Kalau CSS sudah muncul di awal-awal ya harus tetap harus di, misalnya header bidding lah contohnya.
Itu memang harus di-load di awal.
Namun, kembali lagi ke si percakapan kalian dengan si client atau stakeholder.
Mereka bilang-bilang mana yang butuh di awal, mana yang butuh di akhir.
Dan mana yang benar-benar butuh benar-benar di awal banget.
Jadi ngomongnya soal kalau di bahasa saya itu, diet.
Jadi wealth-nya diet.
Mana yang benar-benar buruk.
Bahkan fault, fault itu gak semua butuh di awal.
Fault itu ada yang bisa di-swap, ada yang bisa di-mundurin.
Gak semua butuh di awal.
CSS juga gak semua butuh di awal.
CSS itu bisa asynchronous load, bisa ditunda.
CSS itu bisa ditunda.
Jadi hanya butuh yang above the fault aja yang kalian, atau critical CSS bahasa kerennya.
Critical CSS-nya aja di-load di atas, sisanya ditunda.
Sehingga ujung-ujungnya core web-writer-nya kalian bagus, score-nya.
Artinya, LCP-nya, Large Spontane Full-Penya bisa bagus.
Terus kemudian kalian harus bisa memahami yang mana supaya dia terjadi layout shift.
Dan memahami bagaimana supaya saya score yang mana yang perlu di-load atau tidak.
Sehingga tetap memperhatikan INP-nya.
Jadi semoga menjawabnya untuk soal tepati.
Kalian nama-nama aja.
Cukup-cukup.
Terima kasih.
Oke.
Banyak orang yang belum tahu ya dynamic import itu udah bisa di JavaScript Vanilla.
Jadi kalau kita pakai framework seperti React atau Svelte atau Vue kan.
Memang sudah bisa import dynamically untuk lazy loading tadi.
Tapi sebetulnya itu fitur yang sudah masuk standar ES6 kalau gak salah.
Ya dari 2020-2021.
Jadi apapun teknologi yang digunakan.
Ya bisa menggunakan lazy load seperti yang tadi disebut Divan.
Oke.
Pertanyaan berikutnya.
Bagaimana?
Eh udah kena.
Tips.
Apa rodent gods menggunakan core M seperti Krisma atau Sycolas dengan query data list secara langsung?
Yang pertama, pro-nya adalah kemudahan mudah.
Temen-temen diberikan API untuk lebar query, database, join dan operasi-operasi line and insert, update, dll.
Itu kemudahan yang di dapat.
Developer experience-nya enak gitu.
Cause-nya adalah belum tentu semua. Kan si ORM ini adalah translator ya. Translator ke database.
Ngomong ke database, ke SQL.
Line joins-nya kan.
Structure, query, and joins.
Nah, kalau yang misalkan kita udah mulai kompleks aplikasinya atau query-nya udah mulai kompleks, joins sana, joins sini.
Bisa jadi query yang dihasilkan oleh ORM ini bisa jadi kurang optimal.
Kurang efektif, kurang optimal.
Karena mungkin dia select-nya select bintang misalkan.
Join-nya juga mungkin full join.
Ya, ini import-bole aja gitu kan.
Jadi kurang optimal.
Dan itu yang bukan, menggunakan ORM itu tidak sepenuhnya salah.
Tapi ada case-paster.
Kalau misalnya kok ini lambat ya?
Kita kan bisa lihat log-nya, misalkan ada print query-nya.
Nah, dari itu kita bisa optimize.
Atau kalau di RDBMS itu biasanya ada explain.
Explain, query, query kita paste aja.
Terus kita lihat tuh apa yang terjadi.
Dan dari situ kayak debug lah.
Ada bottleneck dimana.
Nah, ini yang diperbaiki.
Mungkin itu bisa kita copy paste ke, saya yakin semua ORM ada execution langsung STL role kan.
Jadi kita bisa ambil si query yang sudah dioptimize.
Bisa tanyakan AI juga, tolong optimize gitu ya.
Hasilnya udah bagus.
Kita coba dilarangin di database.
Yang ada di database production ya, di database development.
Tidakan antara query yang pertama berapa mili detik millisecond.
Query yang optimize berapa millisecond.
Ada perubahannya enggak?
Kalau ada copy paste, jalankan query-nya secara raw di ORM juga.
Di frontend, ada tailwind buat orang-orang yang nggak bisa atau males tulis CSS.
Tapi kan sebetulnya ya overall positif ya.
Jadi ya itu kayak kebalikannya tailwind lah.
Dengan adanya Prisma atau Syqlize, kalau misalnya gue nggak bisa, nggak bisa paste command langsung.
Minimal bisa prototyping.
Atau bisa bikin aplikasi truth simple, ya bisa lah langsung cepat.
Langsung ada type script definition-nya.
Cus, tinggal pakai AI auto-optim, udah kelar.
Cuma kan itu tadi kalau use case-nya udah mulai rumir.
Terus performance concern, ya itu harus consult sama yang memang paham.
Dan itu kayaknya use case AI yang bagus deh buat bikin contoh-contoh SPL-nya.
Terus bikin perbandingannya.
Terus suruh ngelog berapa detik compare masing-masing.
Itu kan kita bisa minta tolong AI juga.
Kalau dari saya cost and cost kembali dalam konteks kemudahan berbanding dengan kompleksitas.
Jadi dengan menggunakan ORM, kemudahan yang didapatkan.
Tapi di dalamnya kompleks yang tinggi.
Jadi, ORM itu sebenarnya abstraction.
Satu layer ini adalah SKL query yang kalian lakukan.
Ada abstraction layer-nya.
Jadi, semakin banyak abstraction, semakin kompleks mengaturnya.
Bagaimana caching-nya, bagaimana optimized query-nya.
Semakin banyak abstraction, semakin kompleks untuk mengaturnya.
Jadi, ada trade-off-nya di situ.
Kalau dalam membangun sebuah aplikasi, kalian kalau mengaktif dengan trade-off itu ya silahkan melakukan strategi-nya.
Seperti kalian sudah sepakat di bersama.
Seperti saya tadi dengan Tailwind dan CSS.
Sebenarnya Tailwind itu adalah abstraction dengan CSS murdi.
Yang CSS netik.
Sebenarnya kalau saya ketemu salah satu dari kalian yang benar-benar menjarik oleh CSS.
Pasti tidak setuju dengan saya katakan saya suka Tailwind.
Tapi dengan trade-off yang tadi saya katakan.
Jika daripada saya menuliskan CSS yang berantakan dan tidak optimal.
Dan jilinya rendering-nya jadi kacau.
Atau maintain ability-nya jadi susah.
Mending saya pakai Tailwind contohnya.
Tetapi bagi sebagian orang yang benar-benar jago CSS.
Justru itu Tailwind pakai Tailwind itu bloated.
Itu adalah perbandingan.
Jadi ada kemudahan dan kompleksitas.
Saya suka pakai SQL.
Saya langsung query performance.
Karena saya sudah paham hal tersebut.
Maka pakai ORM bagi saya justru mengganggu.
Karena apa yang mau saya lakukan harus memikirkan bagaimana calanya ORM itu mendapatkan data.
Jadi saya desain untuk tidak menggunakan ORM.
Dan itu kembali lagi trade-off yang kalian sepakati bersama saat kalian membangun aplikasi dengan tim-nya kalian.
Mana yang kalian gunakan dan mana yang tidak digunakan.
Dan kembali ke tim-nya.
Sedikit tambahan.
Saya tidak tahu di JavaScript, ORM dan JavaScript.
Ada tipe ORM yang eager routing, ada yang lazy routing.
Jadi kalau yang eager routing itu misalkan kita punya relasi antara artikel dan komen.
Ketika kita query misalkan comment.getall itu komen-komennya ikut juga sudah ada di arainya.
Jadi dia kayak query dua kali, query table article dan table comment.
Tapi itu yang eager routing.
Eager routing itu kayak belong semua. Ada itu butuh.
Kita cuma butuh artikel doang.
Ada yang tipe-nya lazy routing.
Jadi kalau kita tidak mendefinisikan bahwa kita butuh galop semua, maka dia akan load satu table aja.
Jadi teman-teman mungkin bisa cari. Mungkin ada aussie-nya.
Saya tidak tahu karena belum pengalaman pengendangkan juga terlalu dalam.
Mungkin ada aussie-nya untuk eager routing dan lazy routing itu juga salah satu solusi.
Saya jadi keringat salah satunya kayak REST-MPI versus GraphQL.
Di mana REST-MPI kita tanya satu.
Satu objek ini terus isinya semua satu abrak-abrak dikirim.
Ini kalau artikel dari title, badinya, segala macam.
Terus komen-nya dikirim semua. Terus sekaligus.
Jadi kita bangkat.
Tapi saat batch load mungkin tidak butuh komen.
Tapi di REST-MPI tidak bisa karena sudah dikirim satu abrak-abrak.
Sedangkan GraphQL adalah abstraction lagi, sama-sama dengan REST-MPI.
Yang bisa kita waiting.
Yang mana yang mau kita customize.
Mana field yang kita mau dapet.
Tapi untuk buat GraphQL, bukannya itu beda.
Teknologi, stack-nya lagi, server-nya lagi.
Ada write-off juga di sana.
Sehingga, biar kembali lagi.
Kalian itu diserahkan ke kalian untuk menghasilkan.
Disitulah letak seni.
Dan web developer itu pekerja seni.
Bukan pekerjaan.
Jawabannya umumnya adalah, kalau ditanya nanti gitu, jawabannya adalah it depends.
Kalau ada masalah-masalah seperti ini, kita tidak bisa digantikan dengan AI.
Kita tidak bisa digantikan dengan Tailwave, Debit, Prisma.
Pertanyaan berikutnya.
Bagaimana cara optimize face API Python dan deployment agak lebih cepat.
Rewrite keras.
Tapi face API ini sudah ada framework Python yang paling cepat saat ini.
Kenapa perlu dioptimase lagi ya?
Saya bukan pengguna ya, jadi tidak tahu ya.
Cuma tahu sedikit-sedikit saja.
Ada masalah apa yang menyebabkan si face API ini jadi lambat?
Saya tidak tahu.
Karena setahu saya, banyak pengguna Python justru menggunakan face API.
Salah satunya karena fast, cepat.
Kalau sudah tidak cepat, mungkin ada sedikit yang senang.
Apa salah nama?
Mungkin dia slow.
Kita tidak bisa dioptimase sekarang ini karena kita bukan pengguna Python.
Kalau deployment juga indipensi juga ya.
Deploy-nya di mana, metode-nya seperti apa, apakah menggunakan Docker, Kubernetes, dan lain-lain.
Browser automation.
Tuduhannya kan untuk testing.
Tapi bagaimana jika automation browser itu digunakan untuk stranding?
Boleh, boleh.
Browser automation, use case-nya banyak ya.
Tidak cuma untuk testing ya.
Bisa buat macam-macam.
Kalau saya boleh katakan, browser automation ini buat orang malas seperti saya.
Saya developer malas.
Jadi apa yang bisa saya automate, saya pakai browser automation.
Kalau di bahasa Inggris ini sebenarnya lazy.
Lazy.
Tapi bukan malas kan.
Malas itu apa?
Contohnya, misalnya kalau ada kita sebelum deploy selalu nge-test dulu dari awal sampai akhir untuk make sure aplikasi intern berjalan dengan benar-benar.
Atau setelah kita refaktor.
Browser automation bisa digunakan begitu.
Bisa juga buat scraping data.
Contohnya, kalau misalnya saya mau, salah satu case, saya mau ngumpulin artikel yang ingin saya baca setiap hari.
Saya biasanya pakai kompetir, set up set up.
Dan dia jalan ke situs-situs berita yang saya suka.
Dan ambil taggingan berdasarkan tag.
Saya ambil beritanya, saya ambil artikelnya, saya kumpulkan ke satu tempat.
Dan saya summarize pakai AI untuk saya tahu berita apa yang berjadik di hari itu.
Itu bisa.
Dan bisa saja, karena saya automate, bukan untuk, kan ujungnya kalau yang salah adalah mengambil dan atau hitus.
Ya bukan haknya ya.
Atau misalnya tools itu adalah hanya sebuah tools.
Mau dipakai hal yang baik, mau dipakai tidak hal yang baik, persalahan lah.
Jadi sama seperti misal itu adalah tools.
Browser automation adalah tools.
Scrapping, tidak apa-apa sebenarnya, dengan tujuannya.
Jadi gampangnya cara kita mikir browser automation.
Apapun yang bisa kita atau user biasa lakukan dengan browser, ya bisa dilakukan oleh browser automation.
Tapi memudahkan karena di delegasikan ke sistem atau program yang kita buat.
Kita sebagai user kan bisa-bisa saja kita cari info, kita refresh atau kita buka banyak halaman.
Itu kan behavior normal.
Kalau memang datanya tersedia secara public, ya boleh-boleh saja.
Tapi misalnya kita membuka halaman website dengan refresh yang tidak wajar atau dengan frekuensi yang tidak wajar.
Ya itu dianggap salah oleh si pemilik website, bakal terkena rate limit.
Misalnya itu kan tanggung jawabnya yang bikin website untuk menge-enforce itu dan behavior.
Atau hasil yang kita terima baik kita membuka sebagai user biasa secara manual, maupun pakai browser automation kan sama saja.
Atau misalnya kita berusaha mengakses resource yang kita tidak punya hak untuk akses.
Ya kan bakal ada error not authorized juga, jadi nggak masalah.
Oke, pertanyaan berikutnya, bagaimana Chrome Lin dalam inklopitas ATML dan dapat kolomerasi dengan browser lain?
Lalu bagaimana cara dianggap konsumsi ATML dan VPI?
Ini internal browser ya, yang sama browser gitu ya.
Chrome, Timebox, Safari, dan sama-sama.
With 3GC ya?
Intro, bukan. With all this.
Jadi sebetulnya semua teknologi web, ATML, CSS, terus JavaScript, tapi yang web API, jadi JavaScript yang berjalan di browser.
Itu bukan milik satu perusahaan manapun, baik itu Chrome, atau Apple, atau Firefox, atau siapapun.
Jadi itu berdasarkan sebuah spesifikasi teknis.
Nah, yang bikin spesifikasi teknis itu konsorsium.
Konsorsium itu ya anggota-anggotanya adalah orang-orang dari browser-browser tersebut.
Terus bisa juga terbuka untuk komunitas atau misalnya expert di luar perusahaan browser tersebut.
Jadi nggak harus semua yang di konsorsium itu kerja untuk Google atau Apple dan lain-lain.
Jadi itu ditentukan bersama jauh banyak.
Nah, berdasarkan spesifikasi teknis itu, masing-masing mengimplementasikan di browser-nya.
Kayak misalnya kalau Chrome itu kan dari Chromium ya.
Nah, mereka menafsirkan spesifikasi teknis, misalnya HTML kalau button itu harus dirender seperti apa, cara kerjanya gimana.
Nah, implementasinya, kayak codingan benerannya, codingan dalam bahasa C++,
ya diserahkan pada masing-masing. Misalnya kalau orang Chrome bikinnya engine Chromium.
Terus Apple juga punya WebKit, Firefox, Spiderman, Gekko.
Jadi itu interpretasi mereka masing-masing.
Terus kalau yang pertanyaan kedua, "Eh, nggak keren-keren sih HTML dengan apa?"
Maksudnya, konsistensi rendering HTML antar satu browser ke satu browser lainnya, yang tadi ya.
Pertanyaan kedua ya?
Konsistensi HTML di-render antar satu browser ke satu browser lainnya.
Ya, tadi spesifikasi.
Jadi sebelum sebuah type HTML misalnya diimplementasi di satu browser atau di banyak browser,
itu yang propose, yang mengajukan itu wajib menulis dokumen namanya spesifikasi atau seperti requirement.
Ini adalah type marking, tujuannya untuk supaya ada rolling text dibawah atau gimana.
Cara kerjanya seperti ini, seperti ini, implementasinya nggak ditulis.
Jadi masing-masing browser, baik itu Firefox, Chromium, WebKit dll.
Melakukan implementasi masing-masing.
Begitu juga dengan JavaScript.
Jadi masing-masing browser itu JavaScript-nya, implementasi JavaScript ini bisa beda-beda.
Makanya kalau teman-teman yang berada di backend, di backend itu ada Node.js yang menggunakan engine yang crow namanya V8 atau EA.
Kemudian muncul Deno juga menggunakan VA.
Kemudian muncul Boon yang menggunakan JavaScript or yang ada di WebKit atau Safari.
Kok bisa lebih cepat Boon?
Bisa lebih cepat Boon.
Bisa lebih cepat karena itu, implementasi JavaScript-nya di Safari itu berbeda.
Makanya, kenapa cepatannya yang ini daripada, karena engine-nya beda.
Bisa kaya mobil aja lah, mobil yang engine-nya ini sama yang ini diadu, ya mungkin ada satu lebih cepat, yang satu lebih tanggung misalkan.
Yang gampang rusak atau minggu.
Jadi spesifikasinya, requirement-nya sama, tapi hasil berbeda-beda.
Terus antar, sekarang sudah ada inisiatif yang namanya Interop.
Pahit-pahit.
Interop itu inisiatif buat men-streamline-kan, jadi kan spesifikasi makin lama makin banyak, makin rumit case-nya banyak.
Nah gimana, padahal masing-masing browser tadi gue dengannya juga beda.
Gimana nyamain, pakai test driven, sebenarnya test driven development sih.
Jadi ada yang namanya web platform test, kalau misalnya tertarik bisa buka webpt.fyi.
Nah itu ada test case, banyak banget, ratusan bahkan dibuat.
Tadi sempat ditunjukin juga ya sama Ivan, yang ada Chrome, Firefox, Safari.
Jadi semua spesifikasi tersebut dibuat, test case-nya, assertion-nya, detail banget.
Bahkan sesimpel media query, misalnya di resize, jadinya gimana.
Jadi itu semua murni HTML, CSS, JavaScript.
Nah gimana cara memastikan masing-masing browser, behavior-nya konsisten, ya pakai test case itu.
Jadi mereka yang diluningkan bukan implementasi kode-kode browser masing-masing, tapi test case itu.
Test-nya behavior-nya begini ya, jadi kalau misalnya udah passing, berarti konsisten.
Oke, berhubung, waktunya sudah habis, kita tutup aja.
Maaf-maaf tidak bisa menjawab semua pertanyaan, temen-temen mungkin masih banyak.
Nanti kita akan ambil ini dan mudah-mudahan nanti kita akan jawab di silisi online kita.
Jadi dari kita bertiga pangin, sampai bertemu lagi di hari Selasa malam.
Waktunya kita berbualin web.
Terima kasih semua.
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://ksana.in/ngobrolinweb ----------------------------------------------------------------------------------- Bergabung menjadi anggota elit di kanal ini: https://www.youtube.com/channel/UCHhAlFGFCGgIusQkQIqJLYw/join Donasi dapat meningkatkan kualitas kanal ini: 💰 https://karyakarsa.com/rizafahmi/tip 💸 https://saw Kunjungi https://ngobrol.in untuk catatan, tautan dan informasi topik lainnya.
Episode Terkait
3 Jul 2024
Ngobrolin Elixir
Episode ini membahas tentang Elixir, bahasa pemrograman fungsional yang berjalan di BEAM (Erlang Virtual Machine), bersa...
18 Jun 2025
Ngobrolin Database
Episode ini membahas Database Scaling, khususnya perbedaan antara horizontal scaling dan vertical scaling. Topik ini dia...
1 Apr 2025
Ngobrolin Lebaran
Episode ini adalah ucapan Selamat Idul Fitri dari tim Ngobrolin WEB. Eka, Ivan, dan Rizah memberikan salam Lebaran denga...
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 .