Ngobrolin Web & #KULTUM
Ringkasan Episode
Bantu KoreksiEpisode ini rekaman sesi #KULTUM bersama komunitas — formatnya tanya jawab terbuka dengan penonton di Discord dan YouTube, dan pertanyaannya melompat dari yang teknis sampai yang soal arah karier. Yang pertama dari Robert, soal mengapa client-side rendering merepotkan SEO. Dulu Google crawler memang belum bisa menjalankan JavaScript sama sekali, sehingga meta tag yang disisipkan React Helmet tidak pernah terbaca; sekarang sudah bisa, tapi ada crawler time budget yang membatasi, sehingga tidak semua halaman sempat dirender ulang. Dari situ lahir berbagai akal-akalan di masa lalu, termasuk menyajikan versi khusus untuk crawler — praktik yang justru berisiko dihukum karena isinya berbeda dari yang dilihat pengunjung. SSR dan static site generation jelas lebih ringan bagi crawler karena kontennya sudah jadi HTML dan tak butuh eksekusi apa pun. Sarannya tetap membumi: kalaupun tetap memakai CSR, entah lewat Create React App atau front-end React di atas Laravel maupun Ruby on Rails, pastikan shell HTML-nya sudah lengkap dengan title, meta description, dan canonical, jangan semuanya di-inject belakangan. Pertanyaan Zaky lebih personal, dan dibacakan apa adanya: "is it worth it to learn PHP Laravel for the future?" — trennya menurun tapi permintaan di kota kecil masih banyak. Jawabannya tidak seragam, dan justru itu yang menarik. Ada yang mengingatkan memisahkan mana yang ikut tren dan mana yang benar-benar dibutuhkan, sambil mencatat PHP kini sudah punya strict typing. Ada yang menyarankan menanyakan dulu apakah pasar di sana memilih Laravel karena alasan tertentu atau sekadar itu yang mereka tahu. Ada yang menyarankan kembali ke dasar — cara kerja JavaScript engine dan PHP interpreter, algoritma, struktur data — supaya bisa jadi agnostik terhadap bahasa apa pun. Dan ada yang menutupnya dengan bukti hidup: 15 tahun di dunia WordPress, sementara PHP yang katanya mau mati tak kunjung mati. Sisanya membahas Ruby on Rails versus Phoenix, hosting di Google Cloud, perlu tidaknya belajar WordPress, Web3, dan HTMX.
Poin-poin Utama
- •Google crawler kini bisa menjalankan JavaScript, tapi crawler time budget membatasinya sehingga tidak semua halaman sempat dirender ulang — dulu meta tag dari React Helmet malah tidak terbaca sama sekali
- •Mendeteksi crawler lalu menyajikan versi khusus untuknya berisiko kena penalty kalau ketahuan, karena isinya berbeda dari yang dilihat pengunjung sungguhan
- •SSR dan static site generation lebih ringan bagi crawler karena sudah berupa HTML; kalaupun tetap memakai CSR — Create React App atau React di atas Laravel maupun Ruby on Rails — pastikan shell HTML-nya lengkap dengan title, meta description, dan canonical
- •Untuk pertanyaan "is it worth it to learn PHP Laravel": pisahkan mana yang ikut tren dan mana yang benar-benar dibutuhkan, dan catat bahwa PHP kini sudah punya strict typing
- •Cari tahu dulu apakah pasar di kota itu memilih Laravel karena pertimbangan atau sekadar satu-satunya yang mereka tahu — itu menentukan seberapa dalam perlu didalami
- •Saran yang paling tahan lama: kuasai dasarnya — cara kerja JavaScript engine dan PHP interpreter, algoritma, struktur data — supaya jadi agnostik terhadap bahasa apa pun
- •Ruby on Rails dinilai tidak akan tergantikan Phoenix, sama seperti React yang akan tetap dipakai Meta — dan 15 tahun di WordPress jadi bukti bahwa PHP yang katanya mau mati tak kunjung mati
Oke, coba ulang lagi dulu. Share ulang, share ulang. Untung masih diperkenalan.
Kalau mau nanya gimana? Kalau mau nanya di Discord, nanti boleh di-text aja di samping
buat kasih tanda, tanya langsung gitu, nanti dibantu dari teman-teman Pani Tia
buat ap naik kesini bareng-bareng.
Oke, suaranya sudah aman.
Oh, aman, oke, oke.
Aman, kita bisa lanjut.
Oke, kita bisa lanjut. Langsung aja kita masuk ke sesi Tanya-jawab karena kemarin juga kita
udah collecting beberapa pertanyaan sembari menunggu teman-teman yang ingin bertanya langsung
via Discord atau di YouTube, nanti ada teman-teman yang stand-by buat collecting pertanyaannya juga.
Atau yang mau bertanya langsung sekarang juga boleh buat kasih tahu di kolom chat nanti dibantu
kakak-kakak Pani Tia buat naik ke on-hole-nya gitu.
Bisa tunjuk tangan gitu ya?
Ya, tunjuk tangan ya, tunjuk tangan bisa.
Tunjuk tangan.
Tunjuk tangan online.
Ya, ada yang gak bisa masuk.
Sekarang masih limit ya, semoga 150 ya.
150 ya.
Ya, semoga Discord kita bisa terus nge-boost ya.
300 bisa tuh.
300, iya terbatas.
Tadi ada yang nge-boost, ada yang nge-boost.
Iya, tadi ada, nge-boosting lagi baru bisa.
Nge-boosting lagi, let's go.
Iya.
Nah, udah 300.
Udah 300, ayo masuk.
Masuk, masuk.
Waduh, masing rame ini.
Lihat transkrip lengkap (1560 segmen lagi)
Waduh, rame, oke.
Oke, mungkin kita sembari mulai aja pertanyaan yang pertama dari Robert seputar SSR dan CEO.
Mungkin dari Mas Riza boleh membuka topiknya perhal itu.
Oke, SSR sama CEO ya.
Sebenarnya kita udah pernah bahas ya.
Iya, pertanyaan komplitnya gak ada.
Mungkin mempertanyakan itu konteksnya ya.
Jadi mungkin boleh dielaborasi lagi, kayaknya orangnya ada sih.
Kalau saya boleh mengimpulkan, merekak-rekak.
Karena ini menjadi pertanyaan yang paling sering banget di dunia web dan khususnya di dunia ini ya.
Apa namanya?
Di dunia ini.
Apa, yang kayak industri news gitu ya.
Jadi kalau mau pakai client side rendering atau server side rendering itu ada pros and consnya.
Nah, salah satu kekurangan menggunakan client side rendering itu kan,
ingat gak kalau, ini saya contohin pakai React ya.
Kalau React itu kan, kalau mau nambahin sesuatu di head, biasanya pakai React Helmet kan ya.
Ingat, React Helmet.
Primoq lain atau client side rendering library yang lain, menyesuaikannya.
Yang intinya menambahkan meta di head tag itu biasanya menggunakan library
dan proses itu terjadi saat client side rendering.
Sehingga saat Google crawler atau search engine crawler jaman dulu,
itu belum bisa nge-execusi JavaScript.
Sehingga tag SEO-nya itu gak kebaca atau meta description tag dan tag-tag yang lain gak kebaca.
Sampai di-execusi JavaScript dilakukan.
Namun beberapa tahun belakangan Google crawler sudah bisa nge-execusi.
Tetapi masih ada kelemahannya yaitu ada yang namanya execution budget
atau crawler time budget itu ada.
Jadi crawler itu gak bisa semana-mana datang nge-execusi semua JavaScript.
Karena kalau misalnya crawlernya, apa namanya, ngefisiknya terlalu sering untuk ngerender,
mereka akan menghabiskan bandwidth server teman-teman.
Jadi kayak nge-DOS, jadi ada time budget.
Sehingga saat itu kan mulai saat client side rendering naik,
trend itu menjadi masalah.
Dan akhirnya muncul lah yang namanya prerender kan.
Yang prerender server side diakalin dengan prerender intermediary atau sesuatu di tengah.
Wah, pernah kita set up ngerender Tron sampai capek lah.
Iya, prerender dulu.
Library yang sempat trending banget namanya ngerender Tron.
Kalau gak salah dibawah Chrome juga ya.
Tapi banyak lah itu.
Salah satunya namanya prerender, ada prerender IO.
Prerender IO.
Saya pakai itu dulu kan.
Jadi prerender IO ini kayak main in the middle,
dimana akan nge-execusi JavaScript kita dan jadi HTML aja.
Dan di output ke browser dan nanti ada process hydration.
Itu jaman dulu.
Sekarang kan sudah maju.
Sudah lebih canggih.
Ya, sudah lebih canggih.
Tapi di tengah-tengah itu sempat ada yang namanya static side generation.
Jadi semuanya sudah dirender dulu.
Jadi instead of jadi main in the middle, semuanya dirender dulu.
Static side generation itu jaman si siapa?
Gatsby.
Tapi sekarang ini semua yang JavaScript Framework Library yang digunakan itu kan mulai dari React, Vue, segala macam.
Sudah men-support yang namanya service head rendering juga, SSR.
Jadi bisa untuk first visit-nya tetap akan dirender di server.
Selanjutnya di hydrate di client saya.
Jadi SSR tetap lebih efisien.
Si crawler search engine untuk mengambil data SEO atau data konten kita jika konten kita langsung HTML saja.
Of course, ya.
Itu gak butuh execution power apa-apa.
Jadi dia cuma tinggal ambil HTML, ekstrak HTML-nya, that's it.
Jadi gak perlu execution JavaScript apa-apa.
Kita berasal dari SSR-nya maupun SSG ya.
Jadi maksudnya gak masalah mau generate statically.
Kalau di server side itu kan tergantung kontennya.
Betul. Crawler search engine crawler itu gak perlu mau pakai apa.
Yang penting dia tahu HTML-nya apa.
Hasil akhirnya ya.
Hasil akhirnya.
Jadi tetap menggunakan SSR.
Yes. Go ahead, Jessica.
Ya itu semuanya jadi inget sih waktu crawling-nya Google itu gak bisa ngelakuin kayak on-click gitu ya.
Waktu itu ternyata ada kontennya.
Tapi kalau load more gitu, itu gak bisa tercrawl.
Jadi bukan karena SSR-nya, bukan karena client range atau static render atau apa.
Tapi kalau ada event, dia harus click load more atau apa, ya gak bisa.
Udah gak masuk sisanya.
Ya benar-benar. Nah itu solusinya kalau kayak gitu kan jadi harus detect apakah ini bot atau enggak.
Kalau misalkan ini bot, tunjukin aja udah semua HTML belontong aja.
Ya, ya, ya.
Dulu juga sempat ada trend di mana jadi kebelah dua.
Kalau di detect apakah dia crawler atau bukan, kalau crawler diarahkan ke server.
Di render sendiri.
Itu namanya kalan-kalan montir.
Dan itu sangat di-scarge karena maksudnya search engine kayak Google dan lain-lain pengen ngasih hasil yang reflect ke user experience-nya.
Jadi kalau ketahuan malah bisa di-penalty atau apa lah.
Masa ilang.
Oke, mudah-mudahan sudah terjawab ya pertanyaan pertama.
Oh iya, sama bonus tips deh.
Kalau pun kita pakai client-side render nih.
Misalnya kan ada bagian yang emang harus atau emang perlu di client-side render.
Minimal kita pakai Shell, HTML biasa kayak yang disebut Ivan tadi.
Entah kita pakai create-write app atau kita pakai server-side framework kayak Laravel atau Ruby on Rails.
Tapi front-end-nya misalnya pakai React dan lain-lain itu kan common use case ya.
Gak apa-apa, tapi minimum pakai Shell yang ada markup-markupnya lengkap.
Two-head, meta-text.
Ya maksudnya sebisa mungkin kita kontrol Shell-nya jangan semua di-inject belakangan.
We are lebih optimal.
Terus canonical atau apapun lah, SEO-based practice itu banyak hal di luar SSR atau CSR.
Bener banget, itu SEO itu emang menarik sih diulikin, gak ada abisnya.
Iya, baru tamat tiba-tiba ada ini baru lagi, ada algoritma baru lagi, ganti lagi.
Tau-tau SEO score-nya tiba-tiba echo drop tiba-tiba ya.
Dari Pak Sandika ada tambahan Pat atau cukup?
Kayaknya udah diborong semua tadi.
Terdengar banget ya, sakit ya suaranya.
Oh maaf ya, aduh tidak berlaku ini suaranya.
Gak apa-apa, gak apa-apa.
Ini udah ada yang mau bertanya langsung, kayaknya udah mulai banyak.
Jadi kita tahan dulu yang pertanyaan di Docs, kita izinkan temen-temen bisa bertanya langsung.
Mungkin boleh dari, ini naikin dulu Zaky ya, GDSC Uni Persetas sama dia.
Tadi mau bertanya secara langsung, dari Gian boleh dibantu naik ke stage.
Ini versi online ya, kita yang nanya harus naik ke atas panggung.
Harus request dulu katanya.
Oh request dulu, dari ini ya request dulu.
Zaky nanti di accept, coba request naik ke panggung.
Itu ada di bawah buttonnya.
Zakynya mana?
Zaky, ada atau yang standby dulu, Muaz.
Siapa lagi, request, ayo request.
Oh iya, mungkin yang mau bertanya secara langsung boleh langsung request ya.
Biar nanti tinggal di approve buat naik ke atas.
Oke, tadi siapa ada lagi, Muaz ya, pertanyaannya udah ada tapi mau bertanya secara langsung kan.
Request to speak ya, temen-temen yang mau bertanya secara langsung biar clear.
Nah itu udah ada tuh Zaky, invite.
Nah, mantap.
Oke, Zaky, Zaky.
Wah, hilang lagi.
Jadi dia ambil ini dulu, ambil mic dulu.
Di salun dulu.
Oh, Fahri, request speak.
Oh, ini gambar ya.
Itu gambar ya.
Oh itu gambar.
Oke, oke.
Zaky, Zaky, boleh naik.
Kapan-kapan kalau kamu anak UX?
Nggak ada ya di sini, youtuber dong.
Iya, pokoknya kita jawab aja pertanyaan yang ada di chat dulu.
Iya, pertanyaan yang ada di chat text mungkin, yang mana nih?
Kita bingung kebanyakan.
Yang nanya di chat text pakai emote ini semua.
Oh iya.
Wih, nggak ada.
Wih, ada Mas Irfan di youtube.
Yey, halo Mas Irfan.
Oke, oke.
Mas Irfan harusnya di-invite ke belakang.
Eh, Mas Irfan.
Ternyata Zaky-nya lagi ada zoom.
Lagi kita wakilkan pertanyaannya.
Lagi ada zoom.
Oke.
Saya mau nanya sekarang.
Ya, semangat banget ini, Zaky.
Saya mau tanya sekarang, text saya type script and not TS.
Nah, is it worth it to learn PHP Laravel for the future?
Karena trend-nya juga menurun tahun ke tahun.
Tapi demand di kota kecil itu masih banyak.
Jadi bingung, gimana ya?
Boleh minta sarannya?
Kita terima kasih.
Oke, siapa yang mau bilang?
Rang-rang begini nih.
Ini sebentar.
Desika mau jawab?
Aduh, waduh, waduh.
Oh enggak, oh enggak.
Tapi terlepas dari, ini kita nggak bicara Laravel, langsung Laravel.
Baru-baru ini, sebenarnya PHP kayak ada, ya ada development gede juga kan.
Sebenarnya ada update, ada major update juga.
Yang bisa type checking.
Oh iya.
Ya, nah itu. Itu yang bikin kayak, wah.
Kayak akhirnya mulai ke arah situ juga.
Tadi kan PHP, ya sama kayak JavaScript.
Terus, wah jadi type checking sekarang.
Betul.
Trig data type maksudnya.
Oh iya.
Sudah bisa type checking dengan trig data type.
Cuma kelihatannya, ini kan bukan berkara PHP-nya atau TypeScript-nya.
Maksudnya soal teknologi kan, itu tergantung kita mau kerja di industri apa.
Terus kalau ini ada demand di kota kecil itu banyak.
Tapi berarti itu kan, berarti mungkin penanyanya nih.
Cuma mau kerja apa, apa namanya, kerja di kantor kan, kerja in person.
Walaupun tinggal di kota kecil, ya bisa aja kan kerja remote.
Misalnya kalau emang mau, terus apakah worth it to learn?
Kalau ini subjektif saran ya, itu kan soalnya ini udah di luar teknis teknologinya.
Tapi kalau mau ngulik sih, itu bagus.
Karena kita jadi bisa mikir dari banyak perspektif.
Tapi kalau misalnya dikejar atau nggak untuk karir kan,
maksudnya otomatis pengalaman kita di tech-tech yang baru itu.
Dalam kasus ini di Laravel, pengalamannya kurang.
Maksudnya walaupun kita speed-trans dokumentasi, nggak ada yang bisa mengalahkan real-world experience bikin production app kan.
Dan itu nggak bisa instant langsung kita dapetin semua insights-nya.
Nah berarti kan butuh waktu dan effort untuk mendalami itu.
Jadi kalau soal belajar dulu, worth it to learn sih worth it.
Tapi buat ngejarkan, ini berarti kayak tersirat,
pengen demi ngejar karir, pindah tech-tech ke Laravel.
Nah itu harus dipertimbangin kayak,
kalau emang mungkin pengen ngejar banget kerja di suatu perusahaan yang emang dream company,
emang tech-tech-nya itu, berarti kan itu patut diperjuangin kayak pindah tech-tech.
Tapi kalau misalnya nggak segitu prioritasnya, ya mungkin kedepannya kan,
ya itu entah mungkin bakal ada perusahaan baru di kotak kecil itu,
yang tech-tech-nya type script yang sesuai yang sekarang udah didalamin,
atau mungkin ada kan kerja di luar kota atau luar negeri secara remote.
Jadi itu untuk bisa dijadiin pertimbangan.
Yang lain gimana?
Yang apa, yang konten videonya banyak juga php nih Pak Dika,
mungkin bisa kasih tambahan gitu, insight dari sisi php-nya.
Tadi apa namanya, katanya javascript-nya udah belajar, javascript, type script udah belajar gitu ya.
Terus alasan kenapa mau belajar php-nya tadi gimana?
Karena kadang ya.
Kalau misalnya ada kebutuhannya sih ya gas aja pelajari.
Tapi kalau misalnya sekarang udah jauh gitu di ekosistemnya fast script,
kalau belum ada kebutuhannya rasanya gak usah gitu.
Di sini sih, kekhawatiran ke ini sih kayaknya, type script katanya node.js,
node.js itu menurun dari tahun ke tahun, apakah worth it learning php,
jadi kayak mau pindah gitu.
Menurun sih gak juga ya?
Gak ya, kayaknya ngeliatnya, ngeliat menurun itu karena statistiknya statistik javascript kali ya.
Iya bisa jadi.
Kalau statistik Lara.
Karena kalau menurut saya kalau udah masuk ke Laravel juga jangan Laravel aja,
harus ekosistemnya dipake juga semua, depan, belakang, server segala dipake gitu.
Maka itu akan jauh lebih optimal gitu.
Saya punya pendapat yang mungkin gak semua orang suka.
Kalau dari saya, kalau memang sudah tahu text tagnya, sudah pakai type script,
node type atau javascript, cobalah kembali ke basicnya, belajar awalnya,
belajar basic programming, belajar basic dari asik tektur, belajar basic servernya juga,
bagaimana cara execution dari javascript engine atau belajar execution dari php,
interpreter segala macem, dan belajar algoritma dan pemenggerapan data struct segala macem.
Sehingga kamu bisa menjadi agnostic untuk programming language apa aja.
Kalau mau pindah ya pindah gitu.
Jadi kalau bisa bikin programming language sendiri.
Nah itu kan, jadi kalau memang mau pindah ke programming language lain atau ke framework lain,
silahkan saja karena itu kebutuhannya.
Namun tetap harus kamu pegang satu, pegangan satu kamu kuat basicnya
dan juga kuat untuk di stack yang kamu nyaman.
Contohnya saya nyaman di php.
Dan saya basic untuk, apa maksudnya, secara pengetahuan php-nya banyak dan namun saya tidak terbatas untuk php.
Saya bisa hal-hal yang lain juga, sampai bus script juga bisa,
sampai mungkin sedikit rush dan golong juga bisa, javascript juga bisa.
Dan kalau mau pelajari program baru, saya so aja gitu.
Kalau mau belajar tinggal belajar gitu.
Karena basic dari pengetahuan cara programming language itu bekerja sudah punya.
Jadi mau kemana aja bisa.
Jadi kalau bisa agnostic.
Back to basic.
Ini kayaknya objek yang nggak kontroversial nih.
Saya mau nambahin diseputar Jessica dulu deh.
Ya sebenarnya juga kita perlu nanya lagi sih.
Kalau misalkan di main kotak-kotak kecil gitu, mereka pengen pakai Laravel itu
emang sebenarnya ada apakah sosibel karena mereka taunya Laravel aja
atau mereka ada consideration sendiri sebenarnya kan itu yang bisa jadi pertimbangan kita juga.
Apakah itu worth buat kita dalemin beneran?
Kalau sebutannya asal bisa pakai kan sebenarnya nggak usah sampai didalemin aja gitu.
Kalau misalkan ya asal, misalkan buat jadi kerja, buat jadi proyek gitu,
nggak usah sampai dalem-dalem banget juga kan.
Dan ya balik lagi ke agnostik aja.
Saya mau menambahkan sedikit tentang ini apa trend, ngikutin trend.
Jadi pindahnya itu apakah karena trend atau karena kebutuhan?
Jadi kalau saya sih lebih memilih ya karena butuh aja gitu.
Karena PHP sama Node itu kan dua hal yang ya bisa, kita bisa bikin apapun pakai keduanya.
Tapi juga specific problem yang hanya bisa diselesaikan OCS
belum tentu bisa diselesaikan dengan cepat dengan mudah di Laravel, begitu juga sebaliknya.
Jadi kalau misalkan tujuan hanya gara-gara trend itu kayaknya mendingan kita yang bikin trend.
Kalau mungkin di daerahnya ini Node.js kurang ngetrend nih, ya udah kita bikin trend.
Jadi jangan secara buta mengikuti trend.
Trend itu kan di luar, belum tentu di Indonesia juga seperti itu.
Jadi ada perlunya juga kita kayak menahan diri untuk tidak mengikuti trend,
menyelesaikan masalah apa yang bisa kita selesaikan dengan apa yang kita bisa, apa yang kita mampu.
Karena kalau belajar orang dari awal, jenjang karirnya kayak mulai dari awal lagi nggak sih?
Jadi dikonsiderasinya itu, kecuali kalau misalkan di kotanya ini,
dan Zaky nggak mau ke luar kota atau nggak mau di luar negeri misalkan.
Hanya di kota itu dan di kota itu hanya PHP atau Laravel.
Itu mau nggak mau ya, karena itu penyerapan tenaga kerjanya di sana, ya mau nggak mau harus mengikuti.
Ada yang percaya nggak saya di dunia WordPress sudah 15 tahun?
Enggak. Kenapa harus luar percaya?
Dan masih di dunia WordPress 15 tahun setelah nggak tahu berapa tahun lagi.
Ya itu kan katanya PHP mau mati kan. Dari tahun berapa itu nggak mati-mati.
Lama. JavaScript juga banyak hatersnya kan. Sama aja.
Gak jauh-jauh.
Ya itu mau bilang, aku harus bilang PHP mau mati, tapi perasaan WordPress tetap aja populer-populer terus.
Penuh lagi ini server.
Lanjut, lanjut, lanjut.
Ada pertanyaan lagi.
Sudah mulai banyak cicilan pertanyaannya.
Oke kita move ke pertanyaan selanjutnya.
Jadi kayaknya yang di Docs kita tahan dulu, kita pindah ke pertanyaan yang standby.
Di sini ada pertanyaan selanjutnya, apakah sekarang jamannya Ruby on Rails akan digantikan oleh Poenix?
Soalnya banyak sekarang konten-konten bahas tentang kelebihan Elixir ketimbang Ruby.
Dan bahkan ada X-Rails, Dev, dan Ruby on Rails.
Jawabannya adalah tidak. Ruby on Rails.
Terlalu dipakai karena yang bikin Ruby on Rails kan base cam kan.
Nama perusahaannya base cam.
Selama perusahaan itu ada kayaknya.
Tadinya 37 signal, sekarang nggak ada base cam.
Sudah nggak 37 signal lagi?
Sudah.
Tadinya nama produknya tuh, akhirnya jadi satu aja dia produknya base cam itu.
Dan base cam itu dibuat dengan menggunakan Ruby on Rails.
Dan mereka bikin framework itu untuk base cam ini.
Sama aja kayak Facebook menciptakan React untuk bikin sosial media-nya dia.
Iya. Kayaknya sulit kalau nanti React akan tidak dipakai.
Karena minimal akan ada satu perusahaan yang menggunakan.
Yaitu ya, yang menciptakan gitu kan.
Jadi, sebagai alternatif aja Ruby on Rails kabarnya kan karena dia bahasanya high level,
mirip-mirip kayak Python, JavaScript.
Jadi, secara performa mungkin agak tricky untuk di-scaling kan.
Sementara ada bahasa-bahasa yang agak low, yang out of the box itu udah cukup,
performanya udah cukup bagus.
Tapi, kembali lagi, sekarang dengan adanya cloud, server itu udah lebih murah.
Jadi, sebenarnya pemilihan teknologi itu udah nggak terlalu rev1 lagi.
Mau kita pakai bahasa yang lambat banget pun, kalau selama kita produktif
dan ada duit untuk bikin server, ya masih aman gitu.
Nggak perlu ganti yang, "Oh, harus pakai Rust, oh, harus rewrite ke Go."
Nggak juga gitu.
Dan kadang kita tuh developer yang aktif, yang suka agak fomo ya,
kebanyakan baca Hacker News dan sebagainya.
Itu kita kayak mikir kalau ada sesuatu yang baru, lebih bagus, lebih cepat,
semua bisa diganti. Padahal di kehidupan nyata, misalnya kita di tempat kerja,
existing codebase pakai teknologi apalah yang agak outdated atau kurang trend,
kan nggak segampang.
Itu kita meyakinkan atasan kita untuk rewrite semua dari awal pakai stack yang sempurna,
versi tahun 2023.
Jadi kelihatannya maksudnya bakal tetap banyak banget ada legacy framework yang bakal
masih dipakai di industri sampai lama ke depannya.
Ya pelan-pelan bisa dioptimize, kecil kemungkinan langsung diganti.
Sebenarnya masalah daripada apakah bahasa bisa menggantikan,
atau framework bisa menggantikan, kalau misalkan terlalu high level atau low level,
itu learning curve-nya gimana?
Jadi kalau kita jangan fomo-fomo, apakah bisa menggantikan, apakah orang lain gampang?
Maksudnya buat belajar hal yang baru itu, apakah itu worth it?
Kalau seandainya belajar hal baru, terus kita kembali cepat lagi buat development kayak gitu,
apakah itu worth it? Maksudnya nggak diganti kayak gitu sih.
Iya, betul. Yang dipikirin sebenarnya user.
User nggak peduli kita pakai apa selama aplikasinya bagus.
Dan cepat sih ya.
Cepat itu bisa banyak faktor ya.
Saya sedikit membagi pengalaman di proyek-proyek yang enterprise.
Di proyek enterprise kalian tidak dihadapi dengan pilih framework yang mana kok.
Karena jarang banget meminta, oh ini pakai framework yang mana.
Karena sehari-harinya framework ini, penamanya situsnya sudah jalan,
atau mereka sudah punya sistem sendiri yang mana kita tinggal menyesuaikan dengan apa yang dipakai.
Kalau memang kita mau introduce yang baru, itu butuh arkitektur yang besar.
Maksudnya dari sisi sistem arkiteknya akan mulai buat dokumentasi segala macam,
yang mana nanti pemilihan framework-nya pun adalah sesuatu yang untuk enterprise
dan yang sudah dipilih, yang sudah rata-rata, sudah punya track record,
dan bukan sesuatu yang baru-baru banget, tetapi sesuatu yang stable.
Jadi tidak pernah pakai sesuatu itu, eh tiba-tiba besok ada JavaScript framework baru.
Eh kita pakai itu, yuk gitu.
Nggak.
Jadi tetap akan ada backward compatibility dan stability.
Jadi apapun yang kalian pelajari sekarang, akan masih tetap relevan kok.
Dalam 3, 4, 5 tahun masih tetap relevan.
Oke, sudah terjawab?
Oh, lagi lanjut.
Framework yang populer-populer juga kan sebenarnya di-develop-nya juga dari yang lama-lama.
Jadi kita belajar yang lama, apakah dengan misalkan yang kita belajar itu ternyata nggak dipakai lagi,
kayaknya nggak langsung segitunya deh.
Karena banyak lagi sih memang kalau misalkan kita agnostik,
nah kalau kita agnostik kan akhirnya kalau kita belajar yang baru lagi juga ya,
kolanya mirip-mirip gitu bisa.
Itu sih.
Iya.
Oke.
Kita lanjut pertanyaannya semakin banyak, teman-teman.
Semoga menjawab ya Mas.
Ada satu pertanyaan terlewat tadi dari Hiko, bagaimana web scraping yang otabenya,
web yang ambil data article dari website lain, sudah dijawab?
Sudah saya banget, sudah saya jawab.
Asingkronus.
Asingkronus, asingkronus, oke.
Mungkin next pertanyaan Abdurrahman ya,
untuk mengintegrasikan Laravel dengan react.js, bagusan dengan inersia atau dengan API?
Ini aku kebetulan ada pengalaman, emang pengalaman pakai Laravel.
Ini tempat kerja.
Laravelnya sendiri malah nggak ahli-ahli amat.
Cuma ini kalau pertanyaannya agak aneh sih dengan inersia atau dengan API.
Ini hal yang beda ya.
Jadi inersia itu untuk front-end-nya.
Jadi Laravel itu kan full-text, full server-side.
Jadi misalnya kita nggak pengen front-end yang JavaScript-based,
pengen yang beneran markup template biasa aja,
kita bisa pakai Laravel dengan Blade.
Tapi kan kebutuhan sekarang, kebutuhan modern ya, web app yang interaktif,
perlu banyak intrasi JS, kita pengen pakai front-end framework.
Pilihan yang paling basic, mentahan nge-load react juga bisa sebetulnya.
Tapi kan agak sulit karena kita harus mengkonfigurasi segala macam build system sendiri
dan disambungin ke Laravelnya.
Jadi itu nggak sangat dipercaya.
Terus ada library namanya inersia nih yang cukup populer
karena dia bisa mengintegrasikan framework front-end.
Pilihannya bisa pakai react, bisa pakai swell, bisa pakai view,
terus pakai web pack build-in-nya Laravel itu disambungin.
Itu bisa jadi opsi karena cukup banyak yang pakai
dan dokumentasi lumayan, jadi ekosistemnya lumayan.
Atau bisa juga pakai semacam yang dibawah dari Laravelnya sendiri itu
ada jet stream, kalau jet stream itu sama juga punya buat handling UI.
Jadi kalau live wire itu lebih hanya dia offisial dari Laravelnya.
Jadi mungkin itu juga dokumentasinya bagus.
Tapi personal nggak pernah pakai sih, jadi nggak bisa ngasih saran.
Buat saya sih sebenarnya bagus dan cukup umum.
Tapi kalau pertanyaan luksia atau dengan API,
API itu kan di level data.
Maksudnya kita nge-grab data entah langsung dari database
atau kita pakai service eksternal, ya biasalah kita bikin controller,
terus kita serve datanya sebagai API, itu kan data doang.
Itu bisa dipanggil baik dari front-end itu,
baik dari front-end kita yang pakai react,
atau ya dipakai langsung di view blade.
Jadi ini masih agak kurang jelas sih maksud pertanyaannya.
- Kalau mau fleksibel mungkin lebih bagus API kali ya.
Tapi kekurangannya adalah kita harus menit lagi.
- Tapi API kan cuma ngasih data doang.
- Iya, harus menit si reactnya, mungkin pakai next.js atau pake vidka dan lain-lain.
Jadi API-nya dikonsumsi langsung.
Itu lebih fleksibel.
Kalau kita mau buat API-nya, servernya,
terus kita bikin front-end terpisah yang khusus react.
Kalau itu sih tergantung kebutuhan tim dan konteksnya ya.
Berarti kan bisa aja fleksibel, tapi kan jadi ada 2 database yang harus diurus.
Nah terus itu tergantung banget sama resursi tempat kerja
atau tim kamu itu orangnya pada terbiasa pakai apa.
Misalnya emang semua pada terbiasa pakai next.js atau pake track app,
emang pada bisanya itu dan pada benci gitu, nggak mau alergi pakai Laravel,
ya udah kalau itu kan ada tujuannya, kepentingannya.
Atau sebaliknya pada nggak mau pakai next.js,
kalau pada suka di Laravel aja, ya udah pakai Laravel dan Inertia.
Jadi ini kan pertanyaannya 1 di Laravel, back-end dan full-end,
atau dipisah, yaitu tergantung tujuan.
Tergantung resursi, tergantung kebutuhan.
Iya, sepuluh persen pertanyaan jawabannya adalah it depends.
It depends ya, gampang ya.
Ya udah, sisa berapa belas pertanyaan nih kita jawab, it depends semua.
It depends.
Iya, ini ada masukkan nih dari Lukman.
Lebih bagus Laravelnya jadi server, kalau dipakai front-end katanya berat.
Mungkin ada yang pengalaman ya, kalau kita nggak pengalaman soalnya menggunakan Laravel.
Oke, mungkin setus, semoga menjawab.
Oke, ada tambahan lagi dari Pak Sandika atau Kak Jess?
Atau Mas Ivan?
Engga, lanjut dulu.
Oke, kita lanjut pertanyaan dari Lil B.
Saya mau tanya dong mas terkait dunia front-end nih ke depannya.
At SS atau Prompt to Functional Web, jadi agak kena mental gitu.
Buat pemula yang lagi nekunin front-end.
Ini dalam konteks dunia kerja.
Jadi dia kayak butuh insight-insight lah dari suhu-suhu di sini.
Aduh.
SS mana ya?
Screenshot. Jadi kode. Yang kayak Excalibrol.
Jadi kita gamak-gamak, mokap gitu. Terus tiba-tiba di generate jadi kode.
Atau sekarang Versal tuh punya v0.
Ya pokoknya AI itu lah ya.
Ya per AI-an.
Figma dari ini sudah langsung jadi kode HTML.
Dan apa tuh? Tailwind. Sudah bisa gitu.
Itu katanya kena mental.
Gimana tuh?
Cuman balik lagi. Sebenarnya kayak gitu lebih...
Kita kalau mereka generate yang kayak gitu, keren-keren sih mungkin iya.
Itu event mungkin AI pun lebih baik daripada kita yang kadang-kadang agak mager nekunin.
SS-nya diulikan margin-marginnya.
Tapi kalau kita bahas integrasi ke back-end-nya.
Terus kayak arsitekturnya itu kan nggak akan nge-cover.
Jadi di situ sebenarnya skill front-end-nya mayannya di situ sih.
Mungkin kalau kita nggak usah sampai generate kayak gitu.
Event sebelum ada per AI-an ini juga.
Figma aja kan udah canggih ya.
Sebenarnya udah kayak kita si desainnya itu kan bisa langsung di-convert jadi SS.
Itu sebenarnya kan itu pun udah the wannabe automation ya.
Cuman waktu itu dulu maksudnya belum bisa populer sekarang aja.
Padahal sebetulnya itu pun udah bisa menggantikan tanda kutip front-end.
Saya, pendapat saya, sekali lagi pendapat saya mungkin nggak disuka.
Ini ternyata pendapatnya normal banget biasanya.
Jangan mengira kalau front-end itu hanya meng-convert desain.
Slicing, slicing, slicing.
Front-end itu bukan slicing.
Bukan, bukan.
Salah.
Itu baru kulitnya.
Itu baru kulitnya.
Front-end itu tugasnya apa?
Kita lihat, oke yang pertama memang membuat pixel perfect dari desain menjadi HTML.
Lalu membuat komponennya testable.
Jadi setiap komponennya itu bisa testable, bisa ada visual regression test.
Membuat komponennya itu semua accessible.
Accessibility AAA.
Kalau bisa.
Lalu membuat komponen-komponen yang dibuat itu cross-platform.
Maksudnya cross-browser.
Support sampai 3 browser, 3 major browser version yang sebelumnya dan ditest.
Testable juga.
Terus membuat komponen-komponennya itu progressive enhancement.
Mulai dari misalnya misalnya dia nggak bisa dipakai.
Contohnya annoying Firefox belum bisa hash.
Baru bisa nanti 3 hari lagi ya.
In titik 2 hash.
Itu Firefox belum bisa.
Tapi bagaimana bisa membuat progressive enhancement.
Jadi kalian buat itu.
Layoutnya itu stable.
Maksudnya mau di browser mana aja bisa tetap di jalan.
Dan di device mana aja tetap bisa load-nya bagus.
Terus memperhatikan core web vital.
Membuat load-nya sebagai lebih cepat, lebih sederhana.
Renderingnya lebih bagus.
Stable dan juga responsif.
Responsif masinya tidak patah-patah.
Tidak nge-like.
Terus juga front-end itu juga membingkirkan UX.
User experience-nya.
Bagaimana animasinya.
Bagaimana respons dari setiap komponen.
Jika di-click, di-hover dan di-slide atau di-swipe.
Itu juga dipikirkan oleh front-end.
Apa lagi?
Untuk nge-test data flow atau end-to-end testing.
Itu dari front-end.
End-to-end testing dibuat supaya mengikuti business process dan business logic.
Supaya minimal check-out-nya dan payment-nya tidak gagal.
Mungkin kalau di Tokopedia.
Kalau misalnya check-out dan gagal itu bisa tutup besok.
Kalau Tokopedia bisa fail.
Pasti mereka sudah punya itu.
End-to-end testing untuk payment.
Pasti punya dan itu gak boleh gagal.
Kalau fail gak bisa deploy.
Dan berbagai macam lagi.
Itulah scope front-end.
Jadi kalau misalnya liat SS prompt itu fungsional web.
Itu baru kulitnya.
Itu sprinkle-nya.
Baru apa namanya?
Mesejnya ya.
Baru mesejnya itu.
Mesej.
Sisa masih panjang.
Makin kena mental ini Lilby.
Makin kena mental malah.
Banyak.
Belum lagi back-end-nya.
Udah ada front-end-nya terus mau diapain.
Datanya disimpan di mana.
Jadi jangan jadikan AI itu sebagai lawan.
Tapi jadikan sebagai teman.
Bisa buat teman belajar.
Bukan teman sih.
Budi kacung aja.
Terlalu baik ya kalau jadi teman.
Terlalu baik ya.
Yang apa-apa bukan orang.
AI juga menganggap lu teman kok.
Nanti kalau misalkan dia jawab aneh-aneh.
Kamu terlalu baik buat aku.
Jadi kita harus dikacung aja.
Terlalu baik.
Terlalu baik.
Terlalu baik.
Yang tadi dibuat sama Ivan.
Tulus yang ada itu kita pakai buat mempermudah kita.
Jadi kan sebetulnya kadang kita misalnya nggak punya di kehidupan nyata,
kita nggak punya waktu atau sumber untuk nyunci sendiri atau masak sendiri.
Itu kan sebenarnya kita delegasikan.
Kita mampu bayar, kita beli makan di warung,
atau londri hilauan, atau apalah.
Sebenarnya tulus itu kayak gitu.
Tapi yang punya kontrol kita yaitu front-end tadi.
Terus satu lagi, selain semua yang udah dijelasin Ivan tadi,
satu, tulus AI itu nggak punya kemampuan untuk memahami konteks kebutuhan.
Misalnya kalau kita kerja di perusahaan atau organisasi,
kita punya tim lead yang punya suatu tujuan.
Mungkin organisasi kita membuat produk, entah itu berupa.
Entah itu komersil atau bukan komersil,
tapi kan pasti ada tujuannya.
Kita bikin aplikasi atau situs web kan harus ada tujuannya.
Yang simple kalau misalnya marketplace biar banyak orang yang beli berita,
biar banyak orang yang baca, dan seterusnya.
Yang bisa mahamin semua konteks itu developer yang manusia.
Terus kalau contoh penerapannya gimana?
Misalnya kalau tools,
tools AI itu kan bisa suruh buatin webform yang inputnya ini, ini, ini.
Tapi kan dia nggak punya.
Maksudnya misalnya orang marketing atau produk
bisa nuruh tools itu untuk bikin webform yang inputnya ini, ini, ini.
Tapi mungkin karena mereka nggak punya underlying,
nggak punya pemahaman kayak kita sebagai front-end dev,
mungkin mereka nggak bakal nanya soal validasi.
Maksudnya validasinya kriterianya apa, pesannya apa biar helpful untuk user.
Nah yang ngerti konteks itu kan cuma kita.
Terus kalau misalnya validasi error dikaitin sama aksesibilitas nih.
Kalau misalnya pesen error, itu munculnya pakai aria role apa sih.
Nah itu tools AI kan nggak,
mungkin bisa kita suruh.
Kalau kita prom dengan se-specific itu ya dia bisa bikin.
Tapi kan tetap harus lewat kita berarti.
Yang bisa mengontrol AI dengan baik ya itu cuma kita.
Cuma front-end developer.
Kalau misalnya di luar itu, misalnya orang yang bukan front-end dev,
minta bikin inform, ya udah dibikin inform doang.
AI-nya nggak akan inisiatif nanya soal hal-hal itu.
Atau kalau yang contoh bego-begonyalah,
kalau misalnya punya sign up form melalui OAuth,
punya melalui email dan password.
Kalau misalnya double, itu gimana UX-nya untuk misalnya menawarkan
merge account, atau bikin dua akun,
atau malah dilarang bikin akun lagi.
AI kan nggak bisa mikir sampai situ kalau nggak disuruh.
Jadi front-end itu ada kaitannya dengan UX tapi secara teknis.
Iya, itu form-nya itu tricky sih.
Nggak bisa diautomasi semudah itu.
Walaupun itu kayak tinggal isi-isi.
Tapi yang selalu yang membuat susah kan user biasanya minta form-nya itu,
karena mereka malas ngisi, form-nya itu bisa auto-fill,
terus terintegrasi, aneh-aneh.
Nah, itu kan, ya itu something yang saya nggak bisa banget gitu.
Itu dikasih AI aja, udah desain sendiri sana,
nanti generate baru kita coding.
Jadi kita nggak perlu berhadapan dengan user seperti itu.
Jadi kan terbantu.
Iya, bayangin kan kalau misalkan kita orang-orang seperti saya
yang skill CSS-nya payah gitu kan,
dengan adanya tools itu kan jadi lebih terbantu kan.
Wah, lebih cepat nih bikin form, oh lebih cepat nih bikin landing page gitu.
Jadi dimanfaatkan saja untuk belajar, untuk bikin sesuatu.
Jadi kita bisa fokus di integrasi-nya.
Fokus di integrasi, fokus di bikin produknya, gitu.
Fokus di business logic.
Iya.
Oke, mungkin karena pertanyaannya masih banyak kita boleh move dulu ya, Mas.
Lanjut.
Mau tanya pendapat Tarah Suhu nih,
terkait Spellty untuk mengembangun sistem yang cukup besar dan berkepanjangan,
bagaimana ya masa depannya?
Spellty terusannya S-T-I-L-Q.
Spell, iya.
Wah, ini nih, Suhu ngobrolin web ini yang apal.
Boleh, boleh.
Maaf kita bukan, nggak bisa menerawang ya, usah ya.
Kita bukan cenayang.
Iya.
Iya, jadi kalau ditanya masa depan ya, kita nggak tahu.
Antara 50-50 kan, antara suram atau cerah kan.
Jadi, kalau memang, ini kan pemilihan framework,
bahasa, library dan lain-lain itu kan personal ya.
Subjektif.
Jadi kalau kira-kira suka, ya udah pakai.
Kalau nggak suka, cari yang suka, gitu.
Jadi jangan hanya gara-gara, "Wah, Spellty rame ini di luar negeri."
Kayaknya pakai, gitu.
Tapi lebih serak, misalkan pakai ryek atau pakai view, gitu.
Iya, jangan gitu.
Iya.
Gimana, gimana?
Nggak, gue punya ini lagi, opinion circle lagi.
Boleh nggak?
Boleh, doang. Kurang pedas.
Oke, kurang pedas.
Masih terlalu normal.
Ini saya ngasih pendapat yang pedas kali ini.
Apapun framework yang kalian suka.
Ataupun apapun open source project yang kalian suka dan kalian pakai.
Kalau memang mau dia mati.
Pertama, support dia.
Pakai frameworknya.
Support frameworknya.
Kontribusi ke frameworknya.
Ajarkan frameworknya ke orang lain.
Bantu bikin dokumentasinya.
Translate dokumentasinya sehingga yang lain bisa pakai.
Dan racunin orang lain untuk bisa pakai.
Terus kontribusi kalau bisa dalam untuk finance, kalau bisa.
Kalau nggak, bikin extensinya.
Atau add-on-add-on-nya untuk mempermudah orang lain untuk bisa pakai.
Dan kalau bisa, bantu terus itu, ininya.
Maintainernya.
Dan mudah-mudahan kalian bisa salah satu jadi maintainernya.
Itu.
Kalau nggak mau mati.
Kalau nggak mau mati.
Projeknya.
Kadang-kadang, ya, kadang-kadang itu.
Kalau ditanya apa, prediksi kita nggak bisa.
Karena, ya, balik lagi ya.
Kalau kita ngomongin THP kan.
Dari tahun kapan di prediksi akan mati, gitu kan.
Terus tiba-tiba Laravel muncul.
Wah, naik lagi.
Sekarang jadi hame lagi, gitu.
Kadang-kadang ya, siklusnya berputar.
Karena waktu sempat itu kan, Laravel, eh, sorry.
Bukan Laravel, THP sempat dia mau hampir mati.
Tidak, bukan hampir sih, maksudnya sempat dia stagnan.
Saat lumayan.
Ya, 5-6, THP 5-6.
Terus dibikin.
Sudah mulai dibuat THP 6.
Tetapi THP 6 banyak politiknya.
Terus Facebook buat HHVM.
Oh.
Ya, jadi di 4K.
Buat yang Facebook, sorry, THP.
Compiler, interpreter.
Yang jadi executionnya jadi kayak PHP, FPM-nya.
Jadi seperti service-nya atau, inilah, compiler-nya ya, sorry.
Benar ya, compiler.
Ya, atau engine-nya.
VM, VM.
VM-nya, betul.
Nah, jadi PHP, Facebook buat HHVM.
Ya kan?
Yang mengatakan lebih cepat dari 5-6 dan lebih cepat dari PHP 6.
Kebakaran jenggot dong, ini komunitasnya.
Dan restrukturisasi, dan dapat pendan funding juga dari foundation-nya.
Lalu, rilis lah PHP 7.
Di mana jauh lebih cepat.
Tapi selalu gitu ya, ekmascript juga gitu.
Harus ada pecah dulu, masalah.
Harus ada dramanya.
Terus jadi terpancu, ya udah.
Oke, kita jadi progres lah.
Jadi drama itu ada tempatnya.
Drama tapi produktif ya, saling ini ya.
Drama sebagai produktifitas.
Semenjak PHP 7 kan, HHVM ditinggal.
Facebook juga tinggalin.
Dan mulai merging semua ke PHP 7.1, 7.2, 7.3, 7.4, 8, 8.1, 8.2, dan baru saja rilis.
Bulan lalu 8.3.
Oke.
Nah, mungkin sedikit masih tentang Svelte tadi nih.
Tadi kan, kayak Mas Tricia bilang ya, framework ma subjektif.
Nah, cuma kalau misalnya kita balik ke statistik.
Kalau dari state of JS yang 2022, itu Svelte itu sebetulnya opinion.
Jadi state of JS itu ada dua aksis.
Pertama, yang mengukur banyak dipakai atau enggak.
Nah, Svelte itu masih di bawah, tengah-tengah.
Jadi kayak yang pakai masih relatif sedikit.
Nah, terus aksis satunya adalah tingkat kepuasan.
Maksudnya negative opinion atau positive opinion.
Jadi makin lama, makin tak...
Dan Svelte itu berada di kanan.
Berada di quadrant yang opinionnya positif.
Jadi intinya, developer suka, tapi dikit yang pakai.
Nah, tapi jadi kalau dari itu datanya dari 2020 apa 2019,
sampai 2022, dalam 3 tahun, itu penggunaannya naik.
Jadi trendnya tetap naik.
Terus tingkat kepuasannya pun tetap naik.
Jadi makin banyak yang pakai.
Dan yang pakai itu pada happy.
Tapi tetap aja masih di bawah garis tengah-tengah.
- Kemiskinan. - Garis kemiskinan jumlah pengguna.
Jadi maksudnya sebetulnya prospeknya ada.
Masa depannya ada.
Tapi kalau mass scale adoption yang se-level react,
mungkin secara realistis enggak ya.
Tapi ya itu tadi bukan berarti kita nggak bisa pakai kan.
Tetap kita bisa.
Tapi ini sih aman ya.
Karena si Mas Rich Harisnya kan dapat sponsor kan.
Dia kan dipekerjakan untuk menguntin.
- Dihire oleh Versel. - Versel untuk.
Jadi so far masih aman.
Jangan sampai dia di lay off.
Kalau dia di lay off, ya...
Masa depan scale bisa jadi surang.
Maksudnya gitu loh.
Tapi itu drama lagi kan Mas.
Bisa jadi drama.
Mau micu lagi.
Bisa jadi micu drama lagi.
Bisa jadi foundation gitu. Rich Haris foundation bukan? Swell foundation.
Enggak lah. Kayak Evan Yu aja.
Jadi itu. Buka Patreon.
Jadi digaji sama netizen.
- Ya susten atau nggak? - Kalau nggak love you.
Iya.
Sudah, sudah? Puas, puas?
Hidup dan mati open source project itu adalah di pengguna dan maintainernya.
Iya.
Dan sponsornya.
Oke, mantap. Jadi itu jawabannya ya.
Semoga menjawab.
Selanjutnya kita next lagi.
Ada pertanyaan.
Tapi sepertinya yang ini inskripsi sudah dibantu jawab sama Pak Sdika tadi ya, Pak.
Di bawah.
Kuncinya sih bukan judul ya, tapi dosbing ya teman-teman.
Kalau cinta skripsi.
Ada yang nanya ini, Kak.
Untuk skripsi, soal web apa ya judulnya?
Untuk ideation di sini.
- Oh. - Mungkin nanti bisa.
Pake CGVT lah, manfaatkan ya.
Iya, iya betul.
Pake CGVT ya teman-teman itu lebih bisa menjawab pertanyaan teman-teman gitu.
Nah, selanjutnya ini aja ada pertanyaan dari Riza.
Mau tanya pendapatnya. Sekarang kan lagi trend kan ekosistem JS back to front.
Sampai banyak framework front-end yang berlangsung jadi full stack dan jadi sistem monolith sendiri.
Mungkin agak beda.
Saya mau tanya ekosistem .NET, C#.
Sekarang saya lihat banyak otor .NET khususnya buat corporate.
Mau tahu pendapatnya tentang .NET ke depannya apakah akan sepopuler JS karena ekosistemnya.
Dan .NET ini juga mulai rama environment-nya dulu, exclusive Windows.
Dengan munculnya .NET Core tapi di Indonesia masih sepi ya, content creator yang bahas ini.
Wah, sisi Pak Sandi kan kita bisa dibahas, Pak.
Dan Mas Riza boleh masih.
Dia ngerti dan ngupik itu.
Kembali lagi ya, kalau tanya prediksi kita gak bisa prediksi akan gimana-gimana.
Soalnya kita bukan dukun ya.
Jadi kalau ditanya ada pasarnya gak sih? Ada.
Ada banget. Microsoft itu banyak dipakai di corporate, di internet, lain-lain gitu.
Jadi yang pakai .NET, Pak.
Cuman gak ketahuan aja gak ada yang ngomong-ngomong kayak gini yang pakai .NET, coba.
Gak ada yang ngaku di sini. Siapa di sini yang pakai .NET?
Oh ada nih.
Siapa ya kemarin?
Rafki. Rafki pakai .NET kan?
Saya selama kuliah programmer .NET sejati loh.
Dari tahun 2004, 2005, 2006, 2007.
Sampai skripsinya juga pakai .NET C#.
Dan saya baru belajar PHP setelah lulus kuliah.
Ya .NET itu kayaknya mungkin secara tatanannya itu mirip-mirip kayak kalau di front-end itu kayak angular kali ya.
Kayak gak kedengeran ada yang pakai, tapi Microsoft pakai gitu kan.
Tapi corporate.
Corporate pakai.
Jadi corporate di breakdown apa sih? Stabilitas ya?
Stabilitas, support.
Support dan back one cooperative.
Coba kalau pakai PHP, mau minta support sama siapa?
Gak bisa kan?
Ngobrolin web loh.
Terima kasih.
Tolong itu email di bawah sini silahkan.
Kita buka konsultasi.
Iya, jadi .NET itu salah satu keunggulan terbesarnya adalah support.
Jadi kalau misalkan teman-teman di kantornya, bingung nih mau di optimize mana lagi ya.
Kok servernya agak lambat gitu.
Ya hubungi aja Microsoft, pasti bayar sih ya.
Cuman setidaknya ada supportnya, kita bisa nelfon, bisa email gitu.
Kalau open source, kita ke mana larinya?
Tech Overflow, Google, ya kan?
Belum tentu berhasil.
Kalau ini udah bayar, pasti berhasil.
Kalau yang dari Microsoft yang skala SAP-nya apa ya?
Ada itu produk Microsoft untuk SAP?
SharePoint?
Bukan.
SharePoint itu untuk CMS kan ya?
Bukan SAP.
Ada, saya lupa.
Atau di XP-nya, Digital Experience Platform-nya ada juga tuh Microsoft.
Nah, itu pakai .NET.
Terus gitu tapi akses database ya?
SharePoint.
Apa tuh?
Ya, Microsoft akses bukan ya, dia database ya.
Akses database.
Akses database.
Bukan yang dia skala SAP.
C# itu secara bahasa juga bagus loh.
Jadi secara teknik juga udah mature, udah mateng, supportnya lengkap.
Komentasinya pasti banyak.
Oh, sorry, dynamic of dynamic.
Oh, dynamic, oke.
Yang bikin C#, yang bikin bahasa C#, sama yang bikin TypeScript.
Dan yang bikin Pascal.
Itu satu orang?
Sama, satu orang.
Jadi memang udah suhu, hobinya bikin bahasa.
Ya, makannya gak makan nasi tuh, makan...
Engga, dia gak makan nasi, kentang dia sama roti.
Oh, iya, iya.
Boleh sih.
Jadi secara bahasa, secara teknik juga ini ya.
Banyak teman saya yang lulus kuliah, yang kita memang kuliahnya belajar .NET.
Masuk ke company yang urusannya ERP, yang SAP dan Microsoft Dynamic yang dipakai di perusahaan enterprise.
Mereka sampai sekarang masih pakai .NET.
Dan maintain aja gitu, maintain dan bikin internal-internal tools, office tools segala macam di internal, udah.
Dan mereka dapat pelatihan internali segala macam.
Jadi kita nyanyi, gak tahu, gak pernah kedengaran.
Mereka punya ekosistemnya sendiri.
Dan itu karena memang ekosistemnya bukan ekosistem yang terbuka, jadi gak banyak yang diskusi.
Di internet itu ya gak banyak yang ngomongin kan.
Gak ada program ngobrolin good night setiap hari setelah malam.
Bikin apa, bikin? Nanti ada GDN 60.
Ya bukan GDN apa, MDN.
Oh bukan ya, MVP, MVP.
MVP.
Ada Mas Danang loh, jadi hati-hati loh.
Waduh.
Bisa di lay off saya nanti.
Waduh.
Waduh, waduh, waduh.
Oke, kita lanjut ya.
Di sini ada pertanyaan lagi dari Nabil.
Ini kayaknya lebih kecurahan hati dari Nabilnya nih.
Misal ada suatu company yang meminta menggunakan tektor update kepada developernya.
Dan pada akhirnya kadang dependenciesnya ini sering berubah-ubah gitu.
Terus termasuk runtime terbaru dari JS, yaitu band.js yang memaksa kita harus cepat memahami sesuatu tektor baru itu.
Mungkin gimana pendapat dari Mas Andika, Maika, Mas Ipan, Mas Riza dan Jisika.
Soal perihal, mungkin pengalaman yang dia hadapi nih.
Siapa? Pak Adika dulu kali ya?
Gak, boleh Pak Adika.
Ini sih harusnya yang jawab yang pengalaman industri sih.
Kalau ada tiba-tiba permintaan perubahan teknologi yang baru gitu.
Kalau dari saya mungkin pindah kantor, opsi bukan.
Itu ekstrim.
Ekstrim, ekstrim.
Bisa, bisa.
Waduh, waduh, waduh.
Ini sebenarnya pertanyaan yang...
Masa ini kasus yang abis-abis dibilang aneh loh, gak biasa justru.
Di industri kan biasanya sebaliknya.
Ya, resource kan terbatas ya. Mereka membayar kita, developer 40 jam seminggu atau berapa jam lah.
Biasanya bikin fitur, nge-fix banget.
Biasanya malah pada sebelum kan,
kalau kita menghabiskan waktu buat ngutangatik text tag,
micro-optimize pakai hal terbaru.
Jadi pertama sih ini kayaknya kasus yang agak kurang biasa, kurang lazim.
Terus yang kedua, ya kan ini kalau di konteks kerja, asumsinya ada tim lead of some kind ya.
Dia tanya, sebenarnya komunikasi aja dulu sih, tanya aja.
Alatannya kenapa.
Tujuan nya apa.
Misalnya ban lebih cepat, kan emang ban lebih cepat tuh.
Waktu dulu ngobrolin web, kita pernah event live demo, jadi promo episode deh.
Promo episode.
Jadi maksudnya si bun.js itu kan emang lebih cepat,
tapi sebetulnya kita juga harus nge-check bahwa bun.js itu klaimnya adalah one-on-one sih.
Full compatibility.
Full compatibility semua fitur web.js bisa di-replace dengan perfect oleh bun.js.
Padahal kenyataannya belum sampai sana.
Maksudnya drop-in replacement.
Maksudnya itu tadi drop-in replacement.
Terus buat ngeganti text-text dan mastiin steam semua compact lah sama.
Update semua kan butuh waktu.
Kalau emang ada waktunya, misalnya perusahaannya emang nggak terlalu banyak kerjaan,
dan kelebihan duit nge-hire banyak developer gitu, padahal kerjaannya dikit.
Atau mungkin lagi sepi gitu, ada waktunya emang lagi downtime,
ya nggak apa-apa, tapi sebaiknya pastiin aja dulu tujuannya apa.
Kan itu bisa, itu hal yang harus di-decide sama-sama sih.
Maksudnya dalam satu tim tujuannya apa, worth it, atau nggak.
Kalau misalnya kita udah berargumin,
maksudnya kita nunjukin bahwa nggak segitu worth it, dan ke depannya nih fitur kita,
mungkin ada yang harus dipatch atau kita harus berwaktu lebih untuk nge-check ini nih,
kompatibel atau nggak dengan text-text terbaru.
Tapi misalnya kita bilang, ya udah nggak apa-apa, kerjain aja, bikin tiketnya.
Ya udah nggak apa-apa lah dibayar ini kalau dapat tuh.
Iya. Jadi lebih kebalik lagi ya, pemilihan ini sebenarnya motivasinya apa?
Kita harus gali kenapa dia memilih satu teknologi dibandingkan teknologi lain.
Ada temen yang cerita gitu ya,
jadi ada untuk dalam rangka membuat senang developer, kan developer suka ngulik kan.
Membuat senang.
Membuat senang gitu ya.
Jadi satu perusahaan itu membolehkan mereka untuk propose teknologi baru di satu perusahaan itu.
Akhirnya banyak tuh, pakai Kafka, microservice segala macem gitu kan.
Gak kebayang.
Ya, ini sebenarnya bukan teknologinya jelek ya.
Kalau sesuai kebutuhan bagus gitu.
Tapi kalau misalkan hanya demi meng-update LinkedIn, ngapain gitu.
Jadi kayak begitu dia diselesai implementasi, problemnya jadi apa?
Selesai implementasi, terus abis itu dia cabut.
Apply perusahaan lain dengan embel-embel di LinkedIn, ada.
Saya pernah implementasi Kafka.
Itu perusahaan rugi dua kali loh.
Rugi kehilangan talent.
Yang kedua, yang dijatahin untuk menghandle itu yang anak baru, bingung setengah mati dia.
Akhirnya si perusahaan itu balik lagi.
Dihabisin lah, Kafka-nya dihilangin, microservice-nya balik lagi ke monolith karena memang belum butuh.
Jadi balik lagi.
Dicari motivasinya, tujuannya apa, alasannya kenapa.
Kenapa, Bun? Apakah Node.js kurang cepat? Coba ditandingin.
Jadi konsidrasinya tuh panjang sekali.
Atau cara singkatnya tadi, Pak Dika ya.
Coba apply pekerjaan banget.
Soalnya kalau saya membaca pertanyaannya tadi perspektifnya kita sebagai karyawan.
Orang, karyawan.
Jadi kalau keputusan dari atas udah harus ganti teknologi, ya keputusannya ada di tangan kita.
Mau ikut aja gitu.
Tapi kan bisa di-argue kan, kenapa alasannya, apa yang menyebabkan keputusan ini.
Boleh tahu gak?
Kalau gak boleh tahu ya berarti benar, harus pindah aja.
Ya itu tadi, kita warning aja.
Nanti mungkin harus, kita bakal harus berwaktu sekian buat ngurus ini ini ini.
Apalagi minta tiketnya.
Maksudnya jangan sampai jadi numpuk di kita gitu.
Kita yang jadi puntang-panting.
Jadi yaudah kita tanya aja ini prioritasnya tinggi atau enggak.
Ini butuh waktu segini.
Oh gak bisa, kamu harus bikin fitur itu.
Wah ya, kalau ini gak bisa sama aku.
Kita rewrite ya, dari Node.js ke Boon gitu ya.
Tapi besok jadi ya.
Terima kasih.
Terima kasih.
Bye bye.
Oke, oke, semoga menjawab ya curahan hatinya.
Oke, selanjutnya ada pertanyaan lagi nih.
Semangat, semangat, tapi semangat, semangat.
Ini, gimana pendapatnya dari para expert di sini?
Pelihal mendingan deploy web di Google Cloud atau di penyediai layanan hosting?
Wah, nanya ke gini.
Google Cloud lah, Google Cloud.
Walaupun saya apply untuk credit, tapi gak dikasih.
Saya tetap memilih juga.
Jangan curhat dong.
Oke, mungkin boleh dikasih concern-nya mungkin, Mas.
Bari hal kenapa Google Cloud dan alasan behind-nya kenapa.
Ya, balik lagi ini.
It depends juga ya.
Gimana, Eka?
Ya, sebetulnya kalau itu mah.
Soal hosting pakai apa ya?
Silahkan disesuaikan kebutuhan masing-masing ya, biaya.
Terus kebutuhannya kayak gimana?
Google Cloud hosting kan ada free tier-nya tuh.
Bisa dicoba dulu, ya maksud saya cocok atau enggak?
Kalau beneran gak bisa memenuhi kebutuhan web yang dihosting,
ya bisa cari lainnya yang lebih cocok.
Karena biasanya kalau Google Cloud itu lebih fleksibel dan servisnya udah lengkap ya.
Kalau dihosting itu biasanya kan bahasanya terbatas ya.
Di bahasa-bahasa tertentu, database-nya juga tertentu.
Kita mungkin untuk implementasi continuous integration, continuous delivery agak susah.
Kalau dengan cloud cenderung lebih gampang, walaupun bisa ya.
Tapi agak lebih susah.
Oh ya, terus kalau kita pakai produk Google-nya, misalnya Firebase gitu, Cloud Firestore ya.
Dan sebagainya, ya otomatis kan kalau kita pakai web hosting-nya Google Cloud,
integrasinya otomatis.
Kita nggak perlu nge-set up sendiri.
Jadi kalau emang kebutuhannya sama penggunaannya seperti itu ya,
itu bisa jadi faktor yang memudahkan.
Mungkin dari Mas Ivan, Pas Hanika atau Majiska ada tambahan lagi?
Tergantung ukuran proyek.
Tergantung lagi kan?
Nggak perlu Google Cloud, menurut saya.
NG Rock aja cukup?
Pakai NG Rock aja atau pakai CloudFlare Tunnel juga cukup.
Bukan kalau proyeknya kecil dan nggak bisa malas set up, ya pakai web hosting aja.
Ada VPS yang cuma harganya 2,5 dolar per bulan atau yang 5 dolar cukup.
Atau kalau memang nggak penting-penting apa, pakai share hosting.
Share hosting yang 30 ribu sebulan.
Selama share hosting-nya ada si panel itu bisa menjalankan,
maksudnya mudah loh untuk menjalankan JavaScript ini.
Dia ada Node.js-nya, sudah bisa execute Node.js.
Jadi tinggal buka port tertentu, pasang domain-nya.
Di depannya ada nginx dan beres.
Jadi nggak perlu mewah-mewah.
Apalagi kalau untuk portfolio, nggak perlu mewah-mewah.
Semakin mewah, semakin mahal.
Saya juga pernah pakai Google Cloud, akhirnya boncos.
Lupa mati.
Biasanya kalau portfolio kecenderungannya over-engineering sih.
Tapi kalau emang ingin demonstrate bagian itu, nggak apa-apa sih.
Justification-nya, itu harus sesuai sama skillset yang ingin kita tonjolin.
Kalau misalnya kita demonstrate hal lain, tapi kita bikin settingan ribet,
ngesahin diri sendiri.
Masih ada Netlify, Firestyle, dan Next.js yang free tier.
Google Cloud musti sekarang support Next.js juga.
Tapi nggak free ya?
Tidak, TTR-nya sampai berapa sekian dolar itu dianggap free kan?
Tapi kita harus masukin credit card, tapi nggak ada billing.
David Cat bisa nggak? Karena pakai digital bank kan udah banyak.
Nggak bisa, nggak bisa.
Heroku udah mati, iya. Heroku ini andalan sekali.
Bukan mati, free-nya dimatiin.
Free-nya dimatiin.
Terus kan biar dia nggak mati.
Biar dibertahani.
Kalau misalkan mahasiswa bisa dapat GitHub Student Developer Pack ya?
Dapat gratis ya?
Iya.
Termasuk Copilot juga.
Eh bukan, Copilot nggak dapat ya?
Enggak lah.
Copilot itu untuk...
Enterprise.
Sama Open Source, Large Open Source Project Maintainer.
Dapat kok kayaknya.
Dapat ya?
Saya teacher sih.
Tapi student dapet, itu dapet-dapet di cat.
Boleh pinjam teacher card-nya Mas Sandika.
Biasanya disaplai juga.
Kan harus foto kayak KTP gini.
Iya, nanti fotonya Mas Sandika terus saya pakai.
Nggak ajar aja, jadi dosen satu semester lah.
Nggak ajar di sekolah kehidupan.
Oh jadi ini aja.
Jadi dosen tamu.
Dosen tamu aja.
Wah ini konspirasi demi Copilot.
Lanjut, lanjut, lanjut.
Ini ada pertanyaan lagi nih.
Merti gak sih belajar WordPress?
Apa lebih baik langsung fokus belajar nge-moding aja?
Emang belajar WordPress nggak nge-moding ya?
Oh maksudnya mungkin setup-setup kali ya.
Kita install Teams gitu ya.
Ya, kalau kalian mau mulai karir sebagai di WordPress dan mendalem ya.
Pertama, pastinya kalian jadi implementator dulu.
Jadi beli Teams, beli plugin, install-install, setup-setup.
Jadi itu namanya implementator.
Lalu selanjutnya mulai ngulik-ngulik ada mutuh feature tambahan
atau ada plugin yang masalah dikulik-kulik dibenerin.
Selanjutnya bikin Teams sendiri.
Selanjutnya bikin plugin sendiri.
Selanjutnya kontribusi misalnya jadi pembicara di WordCamp.
Atau jadi organizer di WordCamp.
Selanjutnya bisa jadi translator di WordPress ID.
Ada juga itu komunitasnya, WPID.
Selanjutnya jadi core contributor.
Selanjutnya jadi core committer.
Dan selanjutnya, ya, terusin lah.
Nanti berkembang terus.
Kalau kalian sudah di level itu,
banyak banget agensi di dunia ini
yang masih menggunakan WordPress
dan punya banyak client enterprise di WordPress.
Kalau kalian punya jam terbang
dan juga banyak menghasilkan atau banyak dikenal orang,
bukan lagi kalian yang melamar perusahaan.
Kalian yang ditarik-tarik mau ke mana.
Jadi worth it, worth it.
Kalau memang mau terus didalami.
Sama dengan framework lain, sama dengan CMS lain.
Enggak cuma WordPress.
Drupal punya komunitasnya.
Jumlah punya komunitasnya.
Jadi mau yang mana, pilih.
Pick your interest.
Pick your poison.
Pick your poison, betul.
Kak Jess, gak ada suaranya?
Oh iya.
Kak Jess, ada tambahan dari Kak Jess?
Di-mute nih, di-mute nih.
Oh, gak ada suaranya.
Siapa yang nge-mute?
Siapa yang nge-mute nih?
Belum masuk.
Dari tadi ya?
Dari tadi lu ngomong ya?
Iya, pasti.
Coba tes-tes, Kak Jess.
Oh, rejoin, rejoin.
Rejoin, rejoin.
Tapi kayaknya ini, sambil nunggu Kak Jessica,
WordPress itu ekosistem yang berbeda ya, Mas Ivan ya.
Jadi kalau udah nyemplung ke WordPress tuh kayaknya
dia lebih deket ke publisher ya,
daripada ke developer yang natif.
Maksudnya ke publisher itu gimana?
Iya, jadi implementator tadi kalau kata Mas Ivan ya.
Oh, kebanyakan, misalnya kalau sistem piramid ya,
yang dari basic sampai yang expert kan,
pasti yang di atas-atas kan,
yang basic itu pada rata-rata kan implementator ya.
Yang paling tinggi itu dan paling banyak biasanya.
Dan semakin mendalam itu kan,
semakin yang expertnya gitu.
Nah yang experience semakin sedikit.
Jadi, kalau misalnya di ekosistem WordPress itu,
yes banyak banget yang implementator.
Banyak.
Tapi bukan berarti itu hal yang jelek.
Kembali lagi itu hanya profesi.
Dan mereka tetap dibutuhkan.
Jadi kalau misalnya kebutuhan sebuah perusahaan
yang ingin yang budgetnya terbatas
dan hanya ingin maunya spesifik,
gak butuh banyak customization.
Apa kayak apa yang ada, set up dengan cepat.
Website-nya bisa launch dengan cepat, mereka cepat bisa jualan.
Dan cepat bisa melakukan bisnis mereka.
Jadi gak butuh yang aneh-aneh.
Dan itulah fungsinya CMS.
CMS ya, gak cuma WordPress ya, apapun CMS-nya.
Jadi CMS-nya membantu di sisi itu.
Nah, selanjutnya kalau misalnya sudah skalanya meningkat,
jadi dari sisi penggunaan, dari sisi perusahaan
yang berskala mulai lebih banyak kebutuhannya,
itu mulai dari sisi kebutuhan legal lebih terutama.
Misalnya butuh banyak customisasi,
legal isu-isu-nya soal legal,
dan banyak fitur-fitur yang gak ada pernah dibuat sebelumnya,
itu namanya custom development.
Nah, itulah yang berbeda.
Dan dari sisi maintain juga, bayangin aja sebuah situs,
misalnya gini, sebuah company yang ada di 180 negara,
dan kalau mereka punya untuk membuat sebuah situsnya satu-satu
pakai Next.js, ya silahkan aja sih buat 180 situs sih.
Kalau di WordPress gak perlu kan,
bisa jadi sebuah multisite network di setiap,
themes-nya hanya satu, plug-in-nya sama,
tapi site-nya dibikin 180.
Atau bahkan mungkin lebih dari 180.
Terakhir saya pernah menghandle multisite network
yang isinya sampai 80.000 sites.
80.000 sites itu berbagai jenis kebutuhan.
Nah, itu database-nya udah gede banget.
Itu untuk menghandle performance,
asitektur, infrastruktur, dan sampai updates.
Itu juga membutuhkan pengetahuan yang lebih dalam di WordPress.
Gak bisa cuma sebagai, "Oh, saya mau install plug-in."
Gitu install plug-in, ternyata plug-in-nya buat fatal error.
Semua 180.000 situs bisa down.
Kita gak boleh juga seperti itu, kan?
Jadi sudah ada, semakin skalanya semakin besar,
maka butuh rule-rule yang lebih strict.
Gak bisa nge-deploy sembarangan,
harus ada testing, segala macam.
Nah, itu butuh persiapan dan scale yang lebih firm
atau workflow-nya juga gak bisa sembarangan di situ.
Ya, itu dari sisi environment WordPress.
Jadi mau dilihat dari mana.
WordPress bisa dibentuk di basic setup, bisa, atau hanya untuk kebutuhan simple site, bisa,
sampai yang skalanya enterprise dan complex juga bisa.
Ya, itu kayak yang beneran langsung aja.
Kadang kan kita lihat tuh di pinggir jalan atau apa yang
website bisa langsung jalan 100.000 saja.
Nah, itu kan yang cuma pakai WordPress, ya.
Udah, langsung diinstall, langsung pakai.
Pakai plugin yang udah ada, gak ada customize, macam-macam itu bisa.
Nah, sampai yang sekasem, serumit yang tadi dibahas Ivan, juga bisa.
Terus kan sampai ada ekosistemnya sendiri kan,
yang Elementor dan teman-teman, itu kan, dan sejenisnya,
itu kan juga harus butuh buat customize dan connect ke custom field kan.
Itu kayaknya udah kayak framework sendiri ya, kayak meta framework sendiri malah.
Lucky guess, WordPress.com ada berapa subsitesnya?
WordPress.com bisa create site free kan?
WordPress.com bisa create website free disitu.
Lucky guess, berapa subsites yang ada di WordPress.com?
WordPress.com sudah ada 15 tahunan. So, lucky guess.
Wah, miliaran pasti.
Enggak, gak sampai miliaran.
Jutaan.
Karena mereka juga ada bersih-bersih, kalau gak aktif atau gak di login berapa kali,
di shut down juga kan.
500 juta, tuh, Fahri itu jawab, 500 juta.
500 juta.
Ya, mendekatin.
Can you imagine how to handle scale 500 juta subsites?
Kayak gak kebayang bayar server-nya sih.
Oh, Lucky guess punya server farm sendiri.
WordPress.com punya WordPress farm sendiri.
Punya data center.
Yes.
Oke, oke, oke.
Lanjut, lanjut, lanjut.
Dari Kak Jessica, udah aman audionya, Kak?
Udah bisa.
Senggeran gak?
Yay!
Welcome back.
Welcome back.
Oke, oke.
Oke, sebenernya dari, harusnya kalau rundown sih 5 menit lagi ya.
Cuman melihat 252 pertanyaan chat yang banyak banget.
Jadi, apakah boleh di extend 15 menit dari...
Pak, boleh ya?
Ya, boleh.
Biar penonton tidak kecewa ini.
Saya masih stand by, sampe sekarang pun masih full ya.
Discord-nya dan gak tau di Youtube kayaknya juga banyak.
Jadi, izin melanjutkan pertanyaan.
Mungkin ini ada interesting question sih.
Kayak izin bertanya dalam sebuah project, siapa yang harus mengikuti siapa?
Apakah back-end mengikuti front-end atau front-end yang mengikuti back-end?
Wah, kontroversial.
Kontroversial sih pertanyaannya.
Berantung, oh ini ada yang ketiganya.
PM, ya, front-end, back-end, 15 PM.
Wah, itu lebih runyum lagi ya, Kak.
Tapi mungkin boleh explanation dari project-project yang pernah...
Back-end, maksudnya back-end mengikuti front-end atau front-end mengikuti back-end, maksudnya gimana sih?
Maksudnya...
Maksudnya apakah dari back-end kan nge-lebar data ke front-end, apakah front-end itu...
...mengikuti berdasarkan dari back-end atau sebaliknya back-end yang nyampe data sesuai itu.
Yang benar adalah, keduanya mengikuti bisnis logic dan bisnis requirement.
Tapi kalau secara data-dataan itu...
...kalau dari saya, bukannya harus mendesainnya sama-sama ya?
Karena skema nya dibuat bareng.
Iya. Kenapa harus dipisah-pisah?
Iya.
Ya.
Tapi keadaannya API-nya sudah jadi duluan.
Oh, mungkin ini kayak apa ya?
Kalau dari dulu, ya diikuti.
Iya.
Kan biasanya kan...
Dan kita request, "ini dong tolong diubah."
Karena nanti kalau ini nggak diubah, nanti nggak bisa ini loh.
Itu kan jadi tiket baru lagi, ya kan?
Iya sih.
Iya.
Terus, bilangnya API-nya sudah jadi duluan.
Tapi kalau misalkan mau dibikin API yang sesuai request...
...wah ini kayaknya harus rombak strukturnya.
Nah, oh kok jadi keler hati.
Tapi gini, teman-teman.
Kalau misalnya kita disuruh bikin solo gitu ya, aplikasi full stack.
Teman-teman apa dulu?
Sendiri? Nggak tim?
Iya, benar.
Bikin apa dulu? DB dulu?
Kalau saya lebih ke itu, bisnis model kan dari bisnis model ke mock up.
Jadi front end dulu.
Baru ketahuan.
Table yang dibutuhin apa, field-field yang dibutuhin apa.
Itu kalau saya.
Benar, benar. Sama.
Jadi bisnis logic dulu ya?
Bisnis logic dulu, terus larinya ke screen.
Screen-nya ada berapa, dari mana ke mana.
Marahin dari login ya, login nggak usah lah ya. Dari halaman utama, di-click ke mana, isi form dan lain-lain.
Itu kan semuanya, datanya dapat dari sana.
Kalau dari database duluan, biasanya kita ngerawang-rawang tak kebayang.
Jadi dari UX dulu.
Nama user story.
User story dulu pengen apa ini?
Nah, terus habis itu ya sisanya kayak Mas Risa tadi sih.
Ya, cuma ya itu sih yang kadang mungkin nggak ideal, kadang-kadang.
Ya, mungkin kalau tim besar lah.
Wah, wah, wah.
Itu kan kalau kita sendiri.
Ini idealisnya.
Kalau ada politiknya, nah ini beda.
Nah, kalau ada politik.
Terus jujur aja nih.
Ya, ya.
Ya, yang kadang jadi tricky kan karena back-end-nya udah jadi duluan.
Baru terus mau dibikin interface-nya, front-end-nya.
Nah, terus kalau gitu kan akhirnya jadi kita mau mintain ke back-end-nya,
si back-end-nya ngomong lah, "Ah, lu yang baru mau jadi.
Tapi ini udah ada dari kapan?
Ya, lu yang ngikutin kita lah."
Nah, itu akhirnya jadi biasanya emang konfliknya kan di situ.
Padahal, walaupun PM-nya, PM sama front-end misalkan udah satu pendapat,
udah pengen bikinnya kayak gimana.
Tapi tadik lagi, dengan keadaan sistemnya back-end-nya udah kayak gimana, akhirnya apa boleh buat?
Akhirnya kadang-kadang kan jadi suka ada bisnis logik di front-end.
Solusinya tim front-end bikin middleware sendiri supaya bisa nge-fetching data dari back-end itu,
dari API back-end, bikin fetchingnya sendiri jadi middleware,
dan nanti mereka bikin data yang mereka mau.
Jadi lah, GraphQL.
Nah, betul.
Belum pernah bikin kayak gitu sih.
Karena lebih ke constraint kayak, mungkin beda banget ya,
kalau Jessica kan kerja di perusahaan yang besar banget.
Nah, aku kayak kebalikannya, kecil banget, yang nge-oding itu literalnya cuma tiga orang.
In a way sih enak karena jadi simple, kayak maksudnya kalau bikin fitur baru,
ya beneran bisa diskusi semua, bisa ada kesepakatan karena orangnya dikit.
Tapi ada constraint-nya juga karena resource terbatas,
semua orang yang bisa bikin API lagi opi-opain ngerjain yang lain,
sementara ada fitur yang API-nya kayak nggak terlalu kompatibel,
sebenarnya agak mirip, lucunya malah nggak mirip sama yang dibilang Jessica tadi,
dalam hal jadi duluan dan ternyata nggak bisa memenuhi kebutuhan.
Tapi kan sisa dua orang ini masih nggak bisa diburu-buru sekarang harus bikin
karena ngerjain hal lain yang juga urgent.
Ya udah, akhirnya sementara kebutuhan data kayak gimana,
sebagian malah ada yang di-hardcode kayaknya,
beneran buat apa sementara di monkey page staff bikin sendiri kayak API-API-an,
pakai JSON data, sambil membeli waktu, sambil request API-nya ditambahin.
Dan akhirnya nanti diintegrate kalau memungkinkan.
Jadi intinya kalau siapa menurut siapa, idealnya kerja sama,
mengikuti kalau yang diseparatin.
Tapi kalau kepepet, ya udah, yang pernah kita ngejadiin tasnya kita kan.
Cara agak-agak, ya udah, kalau misalkan kayak gitu bagiannya misalkan maksa,
ya udah, kita business logic query di front-end,
tinggal nanti kalau slow, user-nya ngomel,
otomatis kan tergantung ke back-end.
- Ya kan harus ini dulu kan, kalau nggak ada yang pakai, ya ngapain jawab timas dulu?
- Bener. - Buat apa?
Sedih sekali, nggak ada yang pakai.
- Oke, kita coba lanjut lagi ya, Mas Bapak.
- Oke, ini ada pertanyaan lagi, mungkin nih dia pengen bertanya apakah ada yang,
apakah di industri ada yang pernah mengalami permintaan untuk mengintegrasikan project dengan Web3?
Ada yang pernah? - Enggak.
- Belum ya, oke.
- Ini kan sebelumnya kita ngobrolin Web3, sama orang lain yang ngerti.
- Yang ngerti, kita nggak ngerti juga soalnya.
Yang ngerti, kita belum sampai ke arah sana.
- Oke. - Kita masih web 2.0.
- Oke, oke, wah ini mencoba mencari pertanyaan di selip-selip diskusi di chat ya.
- Nggak bisa dipin ya di sini ya, kalau bisa dipin kan asik ya.
- Iya, benar-benar, oh ada, ada, ada, gimana sih Pak caranya mengevaluasi sebuah fitur
atau modul dalam kode yang lama yang masih relevan atau sebaiknya itu dihapus untuk meningkatkan
keterbacaan dan keberlanjutan terkait code refactoring?
- Wah kata-katanya keren banget ya, meningkatkan keterbacaan dan keberlanjutan.
- Saya punya jawaban yang cepat untuk legacy code. - Yang penas?
- Oh yang penas. - Nggak, nggak, legacy code.
If it is still relevan dan masih working jangan diapa-apai.
- Iya, kalau masih working dan masih relevan jangan diapa-apai, biarin aja.
- Iya, tapi yang paling sial, sesial-sialnya, terus tiba-tiba disitu disuruh nabain fitur major,
disuruh bongkar, terus nge-buck, crash, ah udah.
- Curhat lagi. - Nah, saya pernah ada pengalaman untuk membongkar sebuah plugin legacy yang mana
itu kompleks dan tetapi itu mau tambahin fitur dan ada beberapa bug yang cukup meng-annoying,
tetapi akhirnya ada work aroundnya, tetapi akhirnya di-decide ok, saatnya untuk di-rewrite.
Pertama bikin ininya dulu, testnya. Paling awal bikin.
Jadi kalau yang plugin itu, plugin legacy, nggak ada testnya atau apa.
- Testingnya? - Bukan unit test maksud saya.
- Oh yang unit test, yang lama ya? - Iya, yang lama.
Jadi buat testnya, apapun test scenario-nya, apapun itu ya, mau manual kah, mau automated, up to you.
Yang penting ada list of test, fiturnya apa, testnya begini sampai mendalam.
Ada baganya, ada spreadsheet-nya, saat itu saya pake simple aja, pake spreadsheet.
Ada scenario-nya, nah saat rewrite, itu sesuai dengan scenario itu dan rewrite semuanya dan waktu di-test
sama client itu sesuai dengan scenario dari yang sudah kita setujui bersama.
Itu baru di-rewrite setelah dan itu legacy code.
Dan setelah berhasil semua tinggal di-replace, jadi sebagai drop-in replacement,
yang lama dibuang, tinggal yang baru dipakai.
Oke, ada tambahan lagi dari Kak Jessica, atau Pak Sandika, atau Kak Eka, Mas Riza, cukup?
- Cukup, cukup. - Oke.
Kalau harus bikin fitur baru.
Kalau harus bikin fitur baru.
- Berdoa dulu. - Jangan disentuh,
tapi kalau harus bikin fitur baru, milah dulu aja, terus siap-siap git revert.
- Siap-siap git revert. - Siap-siap git revert.
Oke, berhubung waktunya sisa 5 menit lagi, jadi aku mau reminder ke temen-temen,
jadi nanti buat yang mau foto bareng, silahkan prepare dulu kameranya,
nanti kita bantu ap naik ke podium, podium online kita,
nanti prepare dulu, biar bisa bareng foto bersama JDI,
kalau 268 orang mau naik semua, bisa sih dapet info dari tim,
nanti kalau itu silahkan siap-siap temen-temen on-cam, nanti kita foto bareng-bareng.
Oke, ini pertanyaan terakhir, sembari menunggu temen-temen juga yang bakal on-cam,
pendapat soal HTMX Pro and Cons-nya, cocok digunakan dalam kasus seperti apa?
- Kita pernah bahaskan ya HTMX ya? - Pernah bahas sekilas,
mungkin akan dibahas lagi di episode-episode berikutnya.
- Karena belum pakai di production. - Belum pernah ada yang pakai, iya.
- Dan ini, cuma ini tren yang menarik ya, kalau tentang HTMX-nya sendiri,
ya itu nggak bisa ngasih pendapat di dalam karena belum pakai,
tapi tren menarik gitu karena dia bisa server-side ya,
server-side kapa bu Witi tanpa lewat framework-framework yang established.
Ya sebetulnya in a way ini kan behave-nya kayak seperti framework juga kan.
Kayak React pun sekarang ada Server Components, HTML pakai pendekatan HTMX.
Jadi semua kayak full-cycle server-side lagi.
- Kembali lagi, kita udah pernah bahas juga ya dari awal,
client-server, SBA, SSR, balik lagi ke client-server.
Jadi ini tren ya, tren baru.
Tren baru yang muncul untuk mengantisipasi karena orang sudah mulai lelah dengan SBA,
SBA itu mungkin agak jengky, lambat dan lain-lain karena tergantung si kliennya kan.
Akhirnya muncul solusi untuk kayak semacam SBA tapi melalui Websocket.
Koneksi datanya. Jadi bukan data, sorry, dia ngirimin HTML-nya.
Dia ngirimin HTML-nya dari server, streaming ke client menggunakan Websocket.
Ini juga yang dilakukan oleh Phoenix Live View, kemudian LiveWire,
Ruby on Rails, HotWire. Jadi namanya kebalik-balik.
Tapi trennya dimulai dari si Elixir Phoenix ya.
Dan terakhir, HTMX yang lebih agnostik karena semua bahasa dia support.
- Karena bisa on HTML direkli, nggak lewat Rails, nggak lewat Laraksana.
- Selama web server-nya bisa Websocket.
- Oh iya. Kayaknya udah umum sekarang ya Websocket.
- CloudFront belum tentu bisa. Itu harus...
- CloudFront itu produk mana ya?
- Sebelah lah. - Oh sebelah.
- Oke, oke, oke. Sudah cukup?
- Iya, pertanyaan selawnya. Itu kayak gitu bisa offline nggak?
- Pertanyaan ponyolnya itu bisa offline nggak?
- Pake service worker, big cash. Cuma kan nggak bisa streaming baru.
Ya nggak bisa yang baru, cuma ada follow back.
Tergantung buat apa kan, kalau misalnya berita gitu.
- Kalau SPA bisa offline nggak? Tetap nggak bisa kan?
Datanya tetap data yang terakhir kan?
- Iya sama aja. - Sama aja jadinya kan?
- Iya. - Iya.
- Iya tetap sama aja ya? - Sama.
- Mencapkan bisa kita bikin episode sendiri ini di ngobrolin.
- Yes. Nantikan saja, nantikan.
- Nantikan. Wah udah di-spill tuh nantikan temen-temen.
Oke, berhubung waktu 4 menit lagi kita coba foto bersama dulu.
Habis itu baru nanti di-classing.
- Nah ini acara utama ini, foto bareng. - Wah ini, foto bareng.
- Kalau saya mau pasang busa-busa di belakang kayak Pak Dika gimana caranya?
- Beli-beli busa, satu beli busa, dua tempel.
- Ada lampunya juga.
- Buat temen-temen yang masih bingung caranya buat nanti dinaikin ke stage
itu ada request to speak ya.
Nanti itu di-click aja nanti dibantu sama Gian buat naik.
Nah ini udah wah, udah ada naik. Boleh on-cam, boleh on-cam.
- Harus on-cam ya yang naik ya. - Harus on-cam yang naik.
- Ramai, ramai, ramai. - Ramai, ramai, ramai.
- Dimute aja, dimute. Jangan sampai feedback.
- Wah ini screenshotnya gimana? - Anjay, anjay.
- Wow, wow, wow. - screenshotnya gimana ini?
- Hallo Pak Dika. - Halo, halo, halo.
- Ini yang nggak approve 200 kali. 200 kali nggak approve.
- Nggak bisa satu layar semua. - Nggak bisa ternyata.
- Penuh, penuh. - Ini nggak responsif ini.
- Penuh, penuh. Waduh, nggak jadi.
- Penuh, penuh ternyata. - Belum menonton...
- Oh ini komen minus. - Belum menonton sesi Pak Dika ini.
- Komen minus aja biar muat semua. - Oh iya bisa, tapi tambah gede.
- Oh iya. - Tambah gede.
- Nggak bisa, nggak bisa. - Oke, nggak bisa ya.
Ada limit ya ternyata kalau buat naik semua.
- Oke, nggak apa-apa ya ternyata. - Scroll aja.
- Scroll aja jawabannya. - Scroll.
- Oke, mungkin dari kakak-kakak dan moderator boleh bantu untuk di screenshot.
Kita mulai fosesi foto bersamanya seperti biasa karena ini di Google Maps ID.
Boleh dengan gaya Google-nya.
- Head, body, dan putar. - Kayak kita hitung ya.
- Head, body, dan putar. - Bener. Oke, kita hitung.
Udah stand back kakak moderator? Aman ya, coba aku cek dulu.
Oke, gas. Oke, 3, 2, 1.
Oke, mungkin ditahan dulu karena ini agak di scroll ke bawah.
3, 2, 1.
Lagi, 3, 2, 1. Oke, aman kakak-kakak? Cukup atau lagi?
- Cukup. - Atau belum selesai screenshot-nya?
- Bentar, bentar. - Sabar, katanya masih kayak screenshot.
Saya screenshot masing-masing kali ya, nanti kita tag gitu.
- Oke. - Screen, screen.
- Oke. - Bentar, bentar. Saya lagi screenshot.
- Lagi screenshot. - Lagi screenshot, bentar.
Gak bisa gini. Screenshot harus mencet.
- Enggak. Bisa auto scroll. - Auto scroll. Oke, oke.
- Ulang lagi, ulang lagi berarti? - Udah, sudah selesai kak.
- Udah selesai. - Oke.
- Oke. - Ada 2 kali, nanti saya share ya.
Oke, siap. Oke, terima kasih.
Udah melebihi harus batas waktunya, tapi seru banget.
Dan ini teman-teman masih standby sampai akhir.
Terima kasih banyak kepada all the GDI expert kita di web yang udah hadir hari ini, teman-teman.
Terima kasih. Excited juga lihat teman-teman.
Pala-pala ini event perdana kak, mas, pak. Jadi, tapi lihat entusiasi teman-teman.
Semoga kita ada ini secara rutin. Dan yang bukan di teknologi web.
Pengen ada event-event lainnya, boleh di request ya.
Nanti kita bikinin buat speaker-speaker selanjutnya.
Tapi bisa jadi nanti balik lagi ke GDI web juga gitu.
Jadi, pantengin aja di discord kita, google.com/id. Oke.
Dan seru banget seputar website yang udah kita obrolin.
Walaupun harus lebih lama, tapi kayaknya kultum hari ini kita tutup dulu.
Dan sampai berjumpa di kultum-kultum selanjutnya yang gak kalah seru tentunya.
Konten kultum ini hadir sebagai ruang untuk belajar, bertumbuh dan berkarya bersama.
Serta berkolaborasi untuk mengahirkan karya-karya dan gerakan baik untuk sesama.
Thank you teman-teman udah join di kultum.
Maaf jika ada salah kata, padahal saya mau nampun.
Sampai jumpa di kultum selanjutnya.
Goodbye semuanya. Terima kasih Mas Riza, Mbak Eka, Kak Jess, Alvan, Pak Sandika.
Terima kasih, Cyen.
Terima kasih, Pak.
Ntar ini collab sama WPU ntar.
Wah, boleh Pak.
Let's go.
Next, let's go.
Nanti lebih lama lagi, jadi cross nanti.
Tapi gantian ke sana, ngisi gitu.
Oke, boleh Pak, boleh Pak.
Boleh Pak note dari event noted dulu ini.
Siap, terima kasih Pak.
Ya semoga cepat sembuh, Pak.
Terima kasih, Assalamualaikum.
Waalaikumsalam.
Thank you semuanya.
Thank you semuanya.
Terima kasih semuanya.
Semuanya belajar.
Terima kasih.
Deskripsi asli dari YouTube
Halo semuanya! Apakabar nih, semoga sehat selalu yaaa😊 Udah lama gak sih kita gak bincang-bincang bareng di Discord? Jangan khawatir ya karena besok kita bakal ada event special yaitu #KULTUM: Eps. 1: KULiah Teknologi Untuk Masyarakat Edisi GDE Web! Kalian bisa sharing-sharing mengenai web development dengan para GDE Web yang sudah berpengalaman dan pastinya keren-keren banget, antara lain: - Riza Fahmi, Co-Founder @Hacktiv8 Indonesia - Sandhika Galih, Content Creator at Web Programming Kunjungi https://ngobrol.in untuk catatan, tautan dan informasi topik lainnya.
Episode Terkait
1 Apr 2025
Ngobrolin Lebaran
Episode ini adalah ucapan Selamat Idul Fitri dari tim Ngobrolin WEB. Eka, Ivan, dan Rizah memberikan salam Lebaran denga...
18 Jul 2023
Ngobrolin Public Speaking
Topik malam itu keluar dari kebiasaan: bukan teknologi, melainkan berbicara di depan umum. Ketiganya berbagi cerita awal...
2 Okt 2024
Ngobrolin Drama Trademark & Open Source
Episode ini membahas drama perseteruan antara Matt Mullenweg (co-founder WordPress) dengan WP Engine, sebuah perusahaan ...
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 .