Ngobrolin Framework
Ringkasan Episode
Bantu KoreksiEpisode ini kedatangan seorang engineer yang kini bekerja di GovTech di kementerian pendidikan, dan salah satu pesan sampingannya melegakan: karier di ranah web tidak selalu berujung di startup, karena lembaga seperti itu pun memakai Tailwind, Headless UI, dan perkakas sekelas startup. Cerita utamanya soal melewati banyak generasi framework — dari ExtJS yang sudah berbasis komponen dan MVC jauh sebelum orang membicarakannya, ke masa halaman dirakit dengan template Java atau PHP lalu ditempeli jQuery, lalu AngularJS, lalu Vue.js, dan akhirnya Next.js. Dari situ muncul pengamatan bahwa dulu satu framework menyediakan segalanya, sementara sekarang berlapis: React yang menolak disebut framework di bawah, dan Next.js, Remix, atau Astro di atasnya, masing-masing memilih sendiri masalah mana yang diselesaikan. Bagian paling berharga adalah cerita memilih framework untuk tim besar di Blibli. Ia sendiri condong ke Angular 2 karena dekorator dan dependency injection-nya terasa akrab bagi tim yang berlatar Java dan Spring — dan ternyata salah. Setelah keduanya dicoba langsung, yang lebih cepat dikuasai justru Vue, karena direktifnya masih mirip AngularJS yang sudah mereka pakai. Dari sana lahir pelajaran yang ia tekankan: dalam bekerja bersama, singkirkan pertimbangan yang bersifat selera; ajukan yang bisa diukur seperti ukuran bundle, waktu muat, dan biaya perawatan — karena kurva belajar yang dimaksud adalah kurva belajar tim, bukan kurva belajar kita sendiri.
Poin-poin Utama
- •Karier di ranah web tidak selalu berujung di startup — GovTech pun memakai Tailwind, Headless UI, dan perkakas sekelas startup, serta banyak merekrut engineer web
- •ExtJS sudah berbasis komponen dan MVC jauh sebelum orang ramai membicarakan komponen
- •Dulu satu framework menyediakan segalanya; kini berlapis — React di bawah, lalu Next.js, Remix, atau Astro di atasnya
- •Tiap meta framework memilih sendiri masalah yang diselesaikan, karena memelihara semuanya punya biaya yang tak sanggup ditanggung maintainer
- •Dugaan bahwa Angular 2 paling mudah dipelajari tim berlatar Java dan Spring ternyata meleset — Vue lebih cepat dikuasai karena direktifnya mirip AngularJS yang sudah dipakai
- •Pelajarannya: singkirkan pertimbangan selera dan ajukan yang bisa diukur — ukuran bundle, waktu muat, dan biaya perawatan jangka panjang
- •Kurva belajar yang harus dipertimbangkan adalah kurva belajar tim, bukan kurva belajar orang yang mengusulkan
Hai, hai, hai selamat malam, halo, halo.
Selamat malam. Selamat hari, selesah?
Selesah malam. Selesah malam waktunya kita
Ngobrolin web. Ngobrolin web.
Asik.
Eka belum berangkat nih, kita sempat ya sebelum Eka berangkat.
Iya. Malam ini adalah episode ke-50 atau ke-51.
Karena kita mulai dari 0, jadi udah setengah dari 100 ya.
Hampir setahun. Hampir setahun ya.
Episode besok kayaknya pas tahun ya.
Jadi ditunggu aja. Kita sudah menjalani ini setahun.
Mungkin kita mau rekap ya, ada kalidoskop itu gitu ya.
Perjalanan acara ini dan gimana kelanjutannya.
Oke, gimana kabarnya semua teman-teman?
Mudah-mudahan dalam keadaan baik.
Malam hari ini kita mau ngobrol-ngobrol tentang framework ya.
Frontend framework. Javascript.
Nara sumbernya ya, ini sangat berpengalaman.
Karena sudah nyobain berbagai macam framework kita ya.
Sering gunta ganti ya.
Tidak sering sih, cuma sudah gunta ganti.
Ya, tergantung company-nya kali ya.
Sering juga bikin-bikin proyek-proyek pribadi.
Jadi ya bisa kita galilah di sana.
Kalau saya kan berkutatnya di framework itu aja kan.
Jadi pengalamannya kurang gitu. Apalagi Ivan ya.
WordPress terus ya.
Tidak jauh-jauh dari WordPress.
Tapi dengan semakin maraknya ya framework-framework sekarang muncul banyak yang baru-baru.
Nah, kita mau ini nih, mau ngobrol-ngobrol nih sama ya langsung aja kita invite ya.
Lihat transkrip lengkap (1606 segmen lagi)
Mas Irfan Maulana, halo-halo.
Halo, apa kabar mas?
Sehat-sehat.
Suara ku aman ya?
Aman.
Oh iya, Cep, ini ada yang nonton live nggak?
Kalau ada coba tulis si komentar suaranya, kedengeran gila semua atau nggak?
Yes, nah sebelum kita ngobrol-ngobrol ya, sebelum kita ngobrol-ngobrol, mungkin boleh lah perkenalan singkat lah dari mas Irfan.
Siapa tahu ada yang belum kenal? Kayaknya nggak ada, ada.
Coba-coba di komen ya, kalau ada yang nggak kenal, coba di komen ya.
Sungguh terlalu.
Sungguh terlalu.
Halo-halo, selamat malam.
Namaku Irfan Maulana, biasa ada yang manggil masipan di Slack atau di...
Slack.
Slack.
Karena Irfan tuh banyak banget, hampir setiap dimanapun diriku berada, kayaknya ada yang namanya Irfan.
Ada yang namanya Irfan ya.
Eka juga sesang mas.
Iya, di beberapa...
Nasib pema pasaran.
Di beberapa company bener-bener sama gitu, Irfan Maulana, Irfan Maulana gitu.
Nama depan dan nama belakangnya cukup pasaran ya.
Gak, unik ya bener-bener.
Unik.
Oke.
Sekarang lagi kerja di GovTech.
Sekarang lagi kerja di GovTech.
Country Masibam, masrin kemantikan pendidikan, tim di Pusgatin.
Ya, bikin-bikin web lah.
Masih ya.
Project-projectnya enterprise semua ya berarti ya.
Enterprise.
Nggak juga sih, yang kerja enggak enterprise.
Kalau skalanya negara kan itu enterprise ceritanya.
Sekali-kali semua lah.
Iya, scalingnya iya.
Tapi service, typical service-nya, terus typical cara kerja ini sih start-up banget ya.
Kayak kita udah pakai framework-framework yang lucu-lucu.
Kekinian ya.
Kita udah pakai UI-equip yang cukup-cukup trendy lah.
Boleh dibocorin nggak?
Jack Query UI bukan?
Itu 2012.
Senca, senca, senca.
2012.
Terus UI-kitnya bikin sendiri pakai Tailwind.
Terus ada beberapa yang dibantu pakai Headless UI buat bikin kayak dialog gitu-gitu kan nggak pakai Headless UI.
Unstyled ya, komponenunstyled.
Iya, bikin stylingnya atas ya.
Biasanya project yang dikerjain di GovTech itu berkisar ke project-project seperti apa sih?
Buat internal atau buat bantuin guru dan lain-lain gitu?
Depens on the team ya.
Karena kan ada yang mungkin banyak di-expose orang-orang yang banyak kelihatan ya produk-produk yang buat memang publik ya.
Ada yang buat guru-nya, ada yang buat murid-muridnya, ada yang buat sekolah atau sub-tech-nya juga.
Orang-orang yang...
Tapi banyak yang web-based berarti ya produknya?
Iya, ada yang apps malah kayak satu-dua gitu.
Itu pun nggak tahu apakah itu pakai natif atau pakai web-based, tapi kita punya banyak engineer web-nya.
Wajh, engineer web-nya banyak ya.
Hidup web.
Berarti teman-teman yang nonton jangan kotir perspek karir.
Mau di bidang...
Ya, kalau biasanya kan web mungkin dipikirnya bakal kerjanya cuma bisa di-start up atau di-company.
Nah, ini ternyata GovTech juga masa depannya lumayan cerah.
Iya, banyak kementerian lain juga kayaknya ngarahnya pengen kesana ya.
Jadi implementasi teknologinya udah mulai canggih-canggih lah.
Kalaupun nggak under GovTech.
Tapi ada...
Ya.
Begitu.
Sudah ada yang convert dari app natif ke web belum?
Nggak, begitu tahu.
Oke.
Ketanyaan memancing.
Kalau itu apa, maintain legacy code ada kan?
Maintain ada, tapi mostly yang tak kerjain sih migration justru ya.
Jadi karena...
Oh, di migration ya.
Ya, ada beberapa application kan yang mungkin belum under GovTech ya.
Legacy masih di handle sama tim kementerian sendiri ya.
Atau tim pusat daten atau mana-mana.
Nah, kalau mereka kesusahan handle-nya kadang-kadang kita migrate ke stacknya kita.
Tapi kan karena legacy, jadi ya biasanya ada strateginya ya.
Biar gimana mau gede-gedean atau dikit-dikit atau gimana.
Begitu.
Nah, sepanjang karir Mas Irfan, udah pernah nyobain framework apa aja sih?
Macam-macam.
Dulu jaman-jaman orang belum pakai framework pun.
Dulu tuh ada framework trendy namanya XTJ Essentia.
Oh, XTJ Essentia.
Ya, itu ph framework yang...
Apa itu?
Belum pernah.
Bukan pernah pakai XTJS.
Bukan pernah pakai XTJS.
Coba dulu.
Asik.
Bukan.
XTJS N-nya dia tuh.
Itu jamannya orang belum wedding MVC-MVC gitu dia udah MVC terus.
Dia udah komponen base.
Iya, dia komponen base saat orang-orang belum berpikir komponen base.
Belum.
Itu time of time sih.
Udah juga udah jaman-jaman.
Sebelum XTJ itu sebenarnya.
Udah lama banget kan juga, maksudnya.
Lama banget.
Jaman itu.
GWT pernah nggak?
GWT enggak.
GWT enggak.
Berarti kalau tadinya pakai XTJS mau migrasi ke next yes.
Tinggal tambah nuruf N.
Tembakan umur.
Itu mungkin salah satu ini ya.
Apa?
Pengalaman pertama.
In touch dengan full Javanese.
Front-end.
Full Javanese.
Mas Evan kan awalnya kan dari Java kan.
Iya, Java.
Itu pertama kalinya ke JavaScript gitu ya?
Iya.
Dan full feature framework istilahnya kan.
Kalau yang jQuery, JavaScript, Ntml, CSS kan.
UI framework.
Orang-orang akan kesitu ya.
Tapi ngerjain kayak satu halaman, full modingnya, JavaScript, semua itu XTJS.
XTJS.
Terus sempat ngerasain.
Ini menariknya ya, karena pengalaman ku bergabung dengan tim yang berevolusi gitu.
Jadi akhirnya punya pengalaman kayak ngerjain yang platesen dari pertama bergabung.
Mereka pakai PHP atau Java yang timplating gitu.
Terus berubah pakai ditambahin jQuery, ditambahin angulat CSS.
Jadi nggak cuma tiba-tiba ujuk-ujuk kita belajar angulat CSS, tapi kayak ada reasoningnya.
Kenapa mereka tiba-tiba pindah ke jQuery.
Terus nambahin angulat JS.
Terus tiba-tiba misalnya dari angulat JS move ke yang full feature framework.
Kayak misalnya view JS yang SPA full gitu.
Terus migrate ke meta framework kayak NuxJS di view.
Terus di Tokopedia tuh nggak bisa dibilang framework.
Tapi mereka punya in-house framework sendiri itu.
Di atasnya area.
Terus sekarang NuxJS.
Jadi yang profesional cukup.
Jadi dari XJS ke NuxJS ya.
NuxJS sekarang NuxJS.
Profesionalnya ya.
Waktu di Blibli pakai angulat atau view?
Sempet ngerasain pakai Java, terus tambahin jQuery, terus angulat JS.
Angulat JS yang satu ya.
Terus terakhir yang modernnya itu view JS yang versi 2-nya.
Oke.
Terus baru pindah ke React.
Pindah ke React.
Sempat ke ini dulu, meta framework dulu.
Ke NuxJS dulu.
Nah kalau bentar baru nyadar nih dari obrolan ini.
Jaman dulu tuh kayaknya nggak terlalu banyak layer framework ya.
Keliatannya.
Satu solusi itu udah ngasih semua.
Ya mungkin kalau XJS aku nggak ngejamanin segilanya.
Cuma kayak misalnya Laravel.
Ya udah di atas PHP.
Cuma semua udah preskriptif gitu lah.
Mungkin kalau yang ke bawah sampai sekarang kan.
Yang ada sampai sekarang pattern kayak gitu angular kan ya.
Cuma kalau di level React, View, Swelt.
Biasanya ada satu layer lagi kan meta framework.
Dari NuxJS lah, Nux, SweltKit.
Terus sebelum lagi ada Astro yang bisa dipakai buat semua.
Nah itu berarti perkembangan baru ya.
Relatif baru.
Atau mungkin jangan-jangan dari dulu udah ada fenomena kayak gitu.
Ada layer-layer framework dan meta framework.
Dulu tuh suka ada perdebatan antara kita mau nyebut React itu library atau framework.
Karena dulu kita biasanya nyebut framework.
Full feature.
Ada service layer-nya, ada model-nya, ada view-nya, bahkan...
Sampai effects-nya segala udah disediakan kan.
Ada client-nya.
Udah ada. Jadi kita nggak bikin kayak...
Jangan dulu ajaksia gitu.
Ajaksia itu udah bawaan dari framework ya.
Masing-masing.
Sampai sekarang mereka menolak disebut framework.
Mereka emang kalau misalnya kita pengen kaku-kaku makna semantiknya ya.
UI library.
Cuma kan karena nggak di standarisasi ya.
Maksudnya orang mau nyebut itu framework.
Terserah.
Makanya akhirnya ada framework dari atas framework kan.
Meta framework.
Omber muda.
Hal itu nggak ada di Angular.
Iya ya. Angular nggak ada ya.
Mungkin mereka juga visioner juga ya Angular.
Karena mereka sadar pada akhirnya orang akan butuh itu ketika develop full feature application gitu.
Masa lo nggak ada HTTP client-nya gitu.
Pada akhirnya kan lo akan nge-patch juga.
Tapi mereka berpikirnya begitu gitu.
Dan target audience-nya itu lain jenisnya.
Lebih korporat lah. Yang membutuh stabilitas.
Tapi kadang ini ya.
Plus minus lah. Kadang orang jadi problematik.
Ketika orang belajar react itu kayak mereka udah masuk ke hutan rimba nih.
Fetchingnya mau pakai apa? Orang udah bingung sendiri.
Karena gilanya banyak banget gitu.
State library.
State library-nya apa?
Templating engine-nya apa?
Kusing ya.
Routing-nya gimana?
Nah cuma di situ.
Pilihannya banyak.
Meta framework.
Meta framework kasih solusi.
Nah udah biar fokus.
Pakai cara gue aja.
Next.js kan nawarin.
Opionated.
Opionated.
Routingnya begini.
Tetap aja state management nggak dikasih.
Maksudnya meta framework ada banyak.
Maksudnya masing-masing milih mau ngasih solusi apa aja.
Misalnya kalau remix kan.
Remix kan meta framework diatas react.
Mereka tuh punya apa sih?
Kayak yang visioner tuh form kan.
Form handler-nya bagus.
Ya tapi.
Routing semua ada.
State management nggak dikasih.
Udah amat soal UI urus sendiri.
Jadi kayaknya lain-lain gitu.
Suka-suka mereka aja.
Betul.
Bawa GraphQL gitu kan.
Buat bikin blog harusnya juga.
Oh gitu jantung.
Ya ini pertama kali mereka ngasih image.
Image apa?
Image processingnya itu.
Itu di contek sama Next.js akhirnya kan.
Itu itu berguna sekali itu.
Cuma jadi berat banget makin banyak portionnya.
Open source maintainer itu kan punya cost.
Jadi mereka nggak bisa ngambil semua.
Kalau ngambil semua kegedean costnya.
Karena ada cost kan untuk maintain itu semua.
Ya begitulah.
Kenapa Anggular banyak dibenci?
Oh harusnya kita nanya sama itu.
Sama kemarin itu sama Jislin.
Anggular.
Enggak.
Kita nggak benci lho.
Siapa yang benci?
Banyak memes katanya.
Banyak memes tentang Anggular.
Anggular itu banyak jadi memes.
Jadi olok-olokan gitu ya.
Nama cerita dikit.
Jadi dulu di Blibli itu kan pakai Anggular JS versi 1 tuh.
Terus.
Sekarang?
Anggular dulu dulu dulu dulu.
Dulu dulu.
Anggular JS versi 1.
Anggularnya itu di treat kayak jQuery gitu lah.
Mereka masih ada timplating di server.
Terus baru Anggular JS nya datang di client gitu.
Di load ya.
Terus ada pikiran buat totally remove yang Java itu.
Java timplating.
Kalianya kan ke full feature framework itu ya.
Yang JavaScript framework.
Nah diriku itu salah satu orang yang POC.
Beberapa framework nya.
Dan.
Honestly.
Gue sebenernya condok ke Anggular versi 2 saat itu.
Kenapa?
Karena.
Saat itu Blibli itu orangnya.
Mostly orang Java gitu.
Lebih deket ya.
Dekat lah dengan OOP gitu.
Class dan lain-lain.
Mereka tau.
Tim intinya.
Blibli itu yang parent company itu udah.
Pake Java sejak lama.
Pake Spring.
Iya.
Dan menurutku Anggularnya.
Dekat ya dengan.
Cocok ya.
Cocok ya.
Ya banyak apa.
Approach nya yang Java banget gitu.
Pake dekorator.
Dependency injection gitu.
Itu di Java udah.
Udah.
Hatam lah istilahnya.
Udah keluar kepala lah ya.
Itu susah buat orang broad end.
Tapi buat orang Java gampang gitu.
Nah diriku berpikir.
Harusnya learning curve nya itu mudahan Anggular versi 2.
Dibanding.
VGS atau VGS.
Karena.
Kayaknya itu lebih mudah dipahami secara konsep gitu.
Karena mereka udah deket gitu.
Mereka udah biasa ngerjain MVC di Java gitu.
Tapi ternyata pas dilebar ke tim gitu ya.
Untuk ngeliat gitu.
Ini yang Anggular, ini yang VGS versi 2 saat itu.
Ternyata mereka lebih condong ke VGS versi 2.
Oh.
Karena dulu Anggular versi 2 itu kayak.
Belajar banyak dari Anggular versi 1.
Versi 1.
Ya.
Seolah-olah kayak kita ngomong.
Direktifnya ya.
Iya.
Kita ngomong bodohnya gitu ya istilahnya.
Semua yang Ang-if.
Ang-ang itu.
V-if.
Itu jalan.
Jalan.
Jadi kayaknya untuk migrasi dari.
Interaktifitinya gitu.
Iya.
Interaktifitinya API.
Enggak, ngomong-ngomongnya gitu loh.
Masih fun.
Iya.
Jadi sama-sama pakai interaktifitinya API kan.
Iya.
Iya.
DSLnya ya.
Jadi secara lerni kalau ternyata timnya lebih mudah pick up ya.
Few.
Few versi 2 dibanding Anggular yang versi 2 itu.
Padahal diriku berharap harusnya ini lebih mudah dipick deh.
Karena secara konsep itu lebih deket ke Java gitu.
Ya, begitulah.
Jadi salah satu konsiderasi saat itu memang learning curve-nya lebih mudah dipick sama teman-teman engineer-nya.
Dengan pengambil ke few.
Nah, cuma itu poin menarik sih.
Mungkin nyambung ke pertanyaan tadi.
Kalau dibenci itu kan subjektif ya.
Maksudnya orang suka nggak suka itu kan subjektif banget.
Ya, mungkin kalau yang latar belakangnya JavaScript banget.
Dari awal misalnya.
Web kan ini ngomongin orang web.
Zaman sekarang mungkin mulai belajarnya pasti ya dari JavaScript dan kawan-kawan kan ya.
Terus lihat Anggular.
Ya, mungkin karena kurang familiar.
Jadi nggak suka.
Bisa aja tuh.
Apa? Ini tebakan aja.
Mungkin banyak kejadian meme.
Salah satunya karena itu.
Sama kalau Anggular...
Selain Anggular 1, ya kalau Anggular JS kan udah beda banget kan ya.
Sama Anggular yang pasca dibeli Google.
Pasti diambil Google.
Enggak, dari awal memang punya Google.
Cuman dia rewrite.
Oh nggak.
Iya, dia rewrite.
Sebelumnya kayaknya pure open source deh.
Abis itu diakuisisi gitu kan ya.
Enggak.
Dari tim internal Google dari awal.
Oh.
Nah, kalau yang sekarang kan preskriptif banget ya kayak strict.
Oh, ya bisa dibilang strict banget lah.
Mungkin beda banget kan ya.
Sama cara pandangnya react.
Jadi mungkin kalau orang yang nggak terbiasa.
Mungkin ya merasa nggak nyaman.
Kayak, ah ribet banget, sulit banget.
Padahal maksudnya itu mempermudah.
Biar nggak harus decision making yang bergantung ke tim lead atau apapun.
Itu kan buat kalau di perusahaan besar berguna banget kan ya.
Soalnya kalau misalnya terlalu apa ya.
Bergantung sama pilihan subjektif tim lead.
Kalau orangnya pergi nggak ada yang bisa pakai.
Atau pada nggak suka, repot.
Itu yang ingin tak bahas ya.
Jadi ketika kita kerja di tim atau di kantor gitu ya.
Sebisa mungkin hilangin hal-hal yang subjektif tadi itu.
Karena, jadi gue nggak milih angular karena gue senang gitu.
Tapi...
Tapi karena cocok sama tim.
Iya.
Let's say yang jadi strong point-nya adalah learning curve.
Ya bukan learning curve-nya diriku, tapi learning curve-nya timnya.
Karena tiap orang kan nge-pick-nya beda-beda.
Makanya kasih dulu ke anak-anak.
Lihat bagaimana mereka bisa nge-pick up itu.
Terus ambil hal-hal objektifnya gitu.
Jadi kayak misalnya mau ngebandingin antara view dan angular.
Jangan, "Oh kayaknya gue lebih senang angular."
"Oh kayaknya gue lebih senang view."
Tapi ambil hal-hal objektifnya.
Misalnya bandingin aja bundle size-nya.
Bandingin aja berapa load time-nya hal-hal yang memang kita bisa measure dengan mudah gitu.
Nah, kayaknya itu lebih ini ya.
Lebih smooth biasanya.
Kalau kita mau nge-propos perubahan-perubahan yang radikal-radikal kayak gitu.
Let's say perubahan framework.
Kalau kita majuinya hal-hal objektifnya dibanding hal-hal subjektifnya gitu.
Karena akan selalu ada tuh.
Pasti misalnya karena gue datangnya dari orang Java, gue akan prefer ke angular dibanding view misalnya gitu.
Itu akan selalu ada.
Tapi kan beda ya.
Maksudnya diriku dengan timnya bisa jadi point of view-nya jadi beda gitu.
Makanya itu juga diriku nggak menuga gitu.
Ternyata hal yang learning curve-nya buat gue lebih muda, ternyata buat tim nggak begitu.
Belum tentu.
Malam ini judulnya kita ganti ya, jadi kita ngobrolin angular.
Jangan sedih Razak ya, jangan sedih ya.
Bukan cuma angular yang dibenciin, Java juga banyak pembencinya sekarang.
Di roasting mulu ya.
Di roasting mulu.
Jadi dua sahabat ini ya.
Satu lagi yang dari sudut pandang objektif itu adalah cost of maintenance itu.
Membalik cost maintenance.
Update dependency itu nggak semudah membalikkan telopot tangan NPM update jadi loh.
Ini tuh ini Mas Ivan.
Kita mesti lihat track record-nya si library tersebut dalam maintain backward compatibility-nya.
Karena ada beberapa framework yang memang mereka punya ini kan, update yang berkala.
Kayak angulan kan update berkala.
Setiap 6 bulan sekali kita akan update major misalnya.
Nah diperhatiin dalam beberapa waktu kebelakang, misalnya 1 atau 2 tahun kebelakang.
Bagaimana mereka menangani breaking-breaking change-nya tuh.
At least kalau kita lihat track record-nya kita bisa rada punya...
Memminimalisir risiko.
Cuma kalau ya kayak dulu kayaknya Ivan pernah bilang deh,
punya semua library apapun yang kita pakai itu faktor ya kayak risiko kedepannya.
Ada kemungkinan, ada kans besar atau kecil nggak tahu bakal ribet.
Kayak kemarin kan kalau yang round-end pada ngikutin yang kasus Gatsby nggak?
Kayak sempet ribut-ribut.
Nggak tahu cuma akhirnya kayaknya udah nggak terlalu masalah.
Kan Gatsby dibeli Netlify. Abis itu ya namanya nggak dimatiin sih.
- Nggak sampai dimatiin ya? - Nggak, belum, nggak tahu.
Di sunset banyak yang kena lay off kan?
- Banyak yang kena lay off. - Lagi pacir klik gini ya.
Mungkin di luar perkara Gatsby mereka harus, si Netlify-nya harus melangsingkan personelnya.
Terus Gatsby-nya tuh kayak beberapa minggu gitu nggak di-update.
- Terus marah-marah? - Tapi ya maksudnya jadi nggak di-update aja.
Terus kayaknya yang sebelumnya jadi maintainer yang in charge ngejalanin projeknya
tuh kayaknya pada di-kena lay off semua atau gimana nggak tahu.
Jadi maksudnya ini bukan kasus yang ekstrim beneran.
- Progresnya tidak berjalan gitu ya? - Bukan se-ekstrim beneran dimatiin.
Cuma jadi kayak orang-orang yang pakai jadi curiga ini terbengkalai atau gimana.
Orang-orang yang tadinya ngerjain kayak udah nggak di situ semua.
Jadi maksudnya kalau kita pilih meta framework entah kecil atau besar
ke depannya bakal ada risiko kayak gitu.
Kecuali kita ngurangin faktor-faktor risiko kayak gitu kayak yang tadi dibilang itu
bikin compiler atau bikin meta framework sendiri yang dikerjain di Tokopedia dengan React.
Misalnya itu kan salah satu cara ngamanin.
Gue nggak bisa bilang sih. Gue nggak bisa bilang semua orang harus bikin meta framework-nya.
- Karena itu penjara-dara banget. - Usahalah.
Bisa jadi nggak. Benefitnya mungkin nggak segede yang dikira.
Kalau nggak salah Tokopedia pernah mau bikin kan.
Pernah lihat dokumentasinya. Udah bikin kan.
Tapi terbengkalai akhirnya ya.
- Enggak. Sekarang malah ada di produksi. - Kok ada?
Sebelum diriku resign soalnya.
Tapi publik? Bisa dipakai sama orang?
- Enggak. Enggak. Enggak. Enggak. - Bukan.
Dulu pernah ada yang typescript, yang generator gitu kita ketik-ketik gitu.
- Ada kan dulu ya? - Ada, ada, ada.
- Kita bikin lagi yang menyerupai itu. - Oh bikin lagi.
- Tapi internal. - Ya. Udah ini lah ya.
Itu adalah kulminasi dari apa yang kita belajar bertahun-tahun lah.
Jadi kayak dikumpulin jadi framework baru lagi.
Kayak kita udah pernah bikin luarin framework sendiri,
tapi pada akhirnya malah adopsi internalnya kesusahan gitu kan.
Jadi ya udah kita bikin spesial buat kita aja gitu.
Jadi ada meta frameworknya sendiri.
Nah kalau React itu problemnya ini nih.
Masing-masing punya gaya masing-masing sendiri-sendiri.
Tidak apa unopinonated. Jadi masing-masing ya terserah gitu, bebas.
Mau struktur foldernya satu file juga bisa gitu kan.
Mau per folder juga bisa gitu.
Jadi terlalu bebas yang kalau angular itu terlalu mengekang gitu ya.
Kalau project personal mah udah amat. Tiba-tiba pengen, tiba-tiba.
Diurus ulang semua dari awal.
Nah cuma kalau kampanye kebayang sih pusing.
Dan dulu pernah denger cerita orang yang apa sih kayak codebase cukup besar.
Terus migrasi. Dulu kan si React itu masih apa?
- Klas-klas base komponennya. - Klas komponen.
- Iya. - Nah terus sebagian yang baru,
ya setelah-setelah kan React udah keluar juga sebenarnya ya.
Setelah 5 tahunan gitu, kan mulai ya sekarang kan hampir semua fungsin komponen.
Jadi kayak masih campur-campur.
Tapi kalau nggak terliti kopasnya ya bisa celaka.
Masih ada disk, apa? Disk-disknya itu loh.
Masih pakai komponen di-mount, masih disk.
Nah kalau misalnya ada, sebenarnya kalau terpisah,
kenungnya terpisah sih, nggak apa-apa ya aman-aman aja.
Cuma kalau ada kebutuhan yang pakai atau extend
atau modifikasi dari kode yang style lama ke style baru,
itu nambah-nambahin kerjaan, ngerepotin.
Terus kalau provider, jadikan semua jadi pakai hukum,
semua use-use gitu.
Jadi lumayan banyak juga yang harus dimodify
kalau codebase-nya besar.
Nah itu kalau diriku biasanya masukin ini ya.
Either itu masukin ke THDEP atau improvement,
tergantung apa yang mau di-achieve.
Misalnya kita tahu nih, classbase dan functional component
ada gap dari bundle size yang dihasilkan nih.
Dan kita misalnya mau ambil, mau measure-nya adalah performance-nya.
Nah jadi ketika kita ngerjain refactoring dari classbase
ke functional, yang mau di-achieve adalah final result-nya
ke bundle size-nya atau ke performance-nya tersebut.
Nah itu gampang tuh nge-execute hal-hal gitu.
Atau memang ke technical depth.
Kalau technical depth biasanya jangan di-execute gede-gedean kan,
pelan-pelan aja gitu.
Misalnya kalau di Tokopedia dulu karena kita punya tim Korea
jadi suka bikin alat-alat yang lucu-lucu,
termasuk kayak deteksi gitu, jadi kita punya dashboard
yang ngedeteksi seberapa banyak jumlah class component
di dalam satu base gitu.
Jadi kita bisa tahu.
Oh tim dev ops-nya lah ya, tim dev ops gitu ya.
Untuk infra gitu, beberapa orang juga buat tim infra,
tim platform, atau tim functional.
Jadi kita tahu tuh project ini masih, misalnya 1% masih punya classbase.
Nah itu kadang bisa dimasukin ke KPI timnya gitu.
Jadi bisa dimesure karena ada angkanya gitu.
Jadi kayak nggak suka-suka aja.
Kayaknya gue lebih suka functional, tapi ada yang bisa di-achieve gitu.
Nah itu biasanya kalau kerja di tim itu lebih menyenangkan
kalau kita ngeliat hasil dari apa yang kita kerjakan.
Jadi kayak ini buat apa sih ganti dari classbase ke functional gitu.
Makanya kadang ada yang repot-repot bikinin alatnya lah,
repot-repot ngukur before-afternya, performance-nya kayak gitu-gitu
biar kerjaannya lebih menyenangkan ketika di-deploy di production.
Dan ke depannya kalau butuh buy-off word,
ijin bikin fitur ini itu, improvement ini itu,
udah ada datanya ya, bukan mau bikin improvement apa,
baru nyari-nyari dulu apa, argumennya apa.
Nah kalau ini kan udah ada, tinggal cari-cari.
Nah ini terbukti kalau pakai ini, speed-nya naik sekian persen.
Ya kadang-kadang nggak selalu ini ya, nggak selalu berbanding lurus.
Oh, nggak sesuai.
Nggak selalu berbanding lurus dengan, tergantung apa yang mau di-achieve.
Misalnya kayak implementasi TypeScript itu bisa jadi nggak berbanding lurus tuh
dengan performance, tapi kayaknya ini ya maintainability-nya misalnya.
Yaudah kita bikinin aja dashboard-nya untuk kompo.
Karena kan adopsi TypeScript bisa incremental ya.
Kita bisa masih LOJS gitu, jadi kita bisa aja bikin satu project tuh
support TypeScript dan support JavaScript.
Tapi misalnya kita punya target akhir tahun kita bisa 80-90% TypeScript.
Yaudah kita bikin dashboard aja ngukur seberapa banyak adopsi TypeScript
di dalam codebase tersebut gitu.
Oh ya pelan-pelan aja, biasanya awal-awal pasti ada yang ini, ini gitu.
Penasaran nih buat, maksudnya kalo di produk-produk kebayang lah ya.
Misalnya kalo mau migrasi atau mau memang maintain produk itu bisa bertahap.
Cuman kalo kita kerjanya client-based atau punya deadline.
Atau misalnya punya sesuatu yang perlu dikejar gitu ya.
Meskipun contohnya startup lah ya, apa justifikasi kita untuk misalnya migrasi framework
atau migrasi codebase, justifikasi ke client atau ke product owner.
Sedangkan migrasi itu tidak menambah feature, tidak menambah apapun gitu.
Maksudnya hasil akhirnya dengan waktu yang digunakan dan cost akan menjadi hal yang sama
yang dengan sebelumnya. Apa justifikasi nya gitu biasanya?
Itu yang tadi yang sebenarnya re-rec kan gak buat semua orang ya,
atau gak buat semua perusahaan atau agensi.
Kalo gak dibutuhnya kenapa kita nyari-nyari justifikasi gitu.
Itu kan berarti kerjaannya nyari-nyari gitu.
Kerjaan yang kita nyari-nyari itu biasanya udah gak bener gitu.
Misalnya kalo kayak yang saya...
Ya betul-betul ekstrim banget, misalnya frameworknya discontinue.
Kalo itu kan udah gak bisa ngapa-ngapain lagi.
Kalo itu ya beda.
Atau udah gak bisa halir siapapun.
Nah apa nih?
Jadi di beberapa company sebelumnya itu ada yang ngukur developer productivity
pake jumlah commit. Apa yang terjadi?
Citing-citing.
Jadi gak beneficial.
Sampai tuh 200...
Udah jadi, kerjaannya udah nyari-nyari mode nya.
Oh, nyari-nyari.
Tapi rewrite itu gak untuk semua orang.
Kalo memang perusahaannya masih aman-aman aja pake WordPress ya.
Kenapa kita rumit-rumitnya nyari pake next.js gitu.
Karena pake WordPress juga masih jalan.
Kita masih bisa maintain dengan baik.
Nah, problemnya misalnya di Tokopedia nih.
WordPress nya di rewrite ke next.js.
Kenapa gak ada developer yang bisa WordPress gitu.
Nah, kalo itu...
Ini make sense kan maksudnya.
Aku masuk akal hiring sama productnya di discontinued.
Pilihannya kan kita hire WordPress developer.
Atau yaudah kita rewrite aja.
Sehingga siapapun developer nya di tim kita bisa maintain.
Nah itu make sense kan.
Tapi kalo kayak WordPress gue, gue rewrite ke next.js.
Tapi gue sebenernya lebih jago WordPress yang apa?
Atau, agensi klien nya emang gak pernah peduli kita pake apa.
Fiturnya jalan kok, fiturnya jalan.
Kenapa mau dirilis gitu ya.
Itu biasanya link-in driven development.
Biar bisa update CV.
Update CV, abis itu rewrite.
Ada waktu belajar Mas Ivan, kalo tujuannya belajar misalnya gue pengen punya pengalaman.
Bagaimana cara memigrasi WordPress ke next.js.
Kan gak masalah tuh kita belajar deployment nya.
Belajar bagaimana porting fitur-fitur di next.js ke...
Fitur-fitur di WordPress ke next.js.
Atau kalo mau WordPress nya dibikin headless kita jadi punya penanggung.
Gimana consume API nya WordPress dengan baik.
Hal-hal kayak gitu kan gak masalah ya.
Tapi kalo ngobrolin profesional term.
Gue sih bilang kayaknya harus seribu kali mikir ya.
Kalo gak ada benefit.
Ya kalo kayak gitu kasusnya belajar.
Mending malah bikin project open source aja gak sih.
Personal, maksudnya di luar tempat kerja.
Itu kan tetep bisa buat link-in, buat portfolio.
Iya, tapi problemnya kadang ini ya kak.
Maksudnya kalo project pribadi itu dirimu gak ngerasain migration dari satu hal ke hal lain.
Kalo iseng beneran bikin dulu di WordPress.
Ya padahal di world experience kadang-kadang dirimu harus maintain legacy application.
Terus bikin incremental improvement disitu.
Incremental improvement bisa jadi dirimu terpaksa maintain legacy.
Atau kita coba rewrite dikit-dikit.
Nah pengalaman itu kan yang mahal ya maksud gue ya.
Nah itu reda susah kalo kita starting project baru.
Jadi kalaupun belajar...
Bikin project baru itu gampang. Maintain dan minahin yang sulit.
Belajarnya belajar migrationnya.
Oke ngomongin migration, nah ini sebenernya topik utama kita nih.
Ini dia.
Jadi mungkin background story dulu ya.
Jadi ada satu projectnya mas Irfan yang namanya Baca Kuran.
Open source juga kan ya.
Jadi awalnya dibikin pake NuxJS.
Itu bener, itu pengalaman profesional pribadi itu artinya.
Oh professional dan pribadi ya.
Kamu ngomongin aja.
Iya iya.
Jadi dari NuxJS meta frameworknya NuxJS.
Kemudian di conversi di Migrasicle.
Bukan Nux itu meta frameworknya Vue.
Vue, sorry.
Bukan NuxJS. NuxJS itu meta framework dari VueJS.
Ada XJS, ada NuxJS, ada NuxJS. Pusing-pusing.
Developer susah cari nama ya.
Tinggal dari Nux jadi U aja Nux.
Bersyukur banget pas Svelte Kit rilis namanya Svelte Kit, oke dari Supper pindah nama apa? Pindah ganti nama jadi Svelte Kit.
Yang pun bersyukur banget kirain bakal namanya Nux.
Dan Nux ada Nux View.
Nux React.
Nux, habis itu ada Nux lagi.
Terus aja.
Nah ini kita pengen gali lebih dalam alasannya kenapa kok pindah dari Nux ke Svelte Kit.
Kan sama-sama meta framework kan ya.
Pertama kenapa dulu tak tulis pake NuxJS karena itu jaman-jamanya diriku profesional masih pake VueJS.
Terus kaya perlu explore other things lah.
Jadi yang di kantor bisa jadi diriku gak ketemu hal-hal yang simple-simple gitu lah.
Karena diriku dateng projectnya udah ada jadi ada banyak hal ya diriku gak tau ceritanya sudah begitu.
Tiba-tiba udah ada aja.
Ya jadi salah satu caranya adalah bikin dari nol sendiri pake framework yang sama yang dipake di kantor.
Jadi itu ceritanya sampe tak maintain bertahun-tahun lah.
Terus akhirnya pindah ke Tokopedia pake ReactJS.
Mulai profesional pake ReactJS tuh bertahun-tahun kan.
Akhirnya kaya merasa mulai ketinggalan banget nih sama perubahannya Vue.
Terus tiba-tiba mereka release gede-gedean yang versi 3 itu masif banget.
Itu kabarnya kaya angular 1 ke angular 2.
Iya. Approachnya banyak yang berbeda lah.
Buat orang-orang yang gak mengikuti terus belajannya dulu Vue 2 itu rada susah untuk kaya.
Kan itu harus ini ya. Masih bisa unlearn semua yang kita ketahui.
Terus belajar dengan approachnya.
Vue 3 itu kadang masih kebawah-bawah gitu loh.
Nah diriku kesusahan untuk catch up hal-hal yang terjadi di Vue JS.
Sementara diriku sudah tidak profesional moden Vue JS.
Nah kondisinya lagi setelah Vue release versi 3, NaxJS tuh ketinggalan tuh.
Terceret-ceret, tersyok-syok gitu.
Ini udah versi 3, udah major berarti ya.
Si NaxJS-nya untuk adopsi Vue 3-nya itu mereka mesti rewrite grown up gitu.
Benar-benar dari engine-nya harus di rewrite sampai ke atas-atasnya.
Terus proses migration-nya jadi rumit kan.
Mereka coba bikin jalan tengah lah.
Biar gak tiba-tiba gede-gedean ke cara pandangnya Nax3.
Karena kan ada orang-orang yang pada akhirnya tersyok-syok gitu.
Diriku salah satu orang yang tersyok-syok.
Dan coba mengikuti dari Nax2, harus adopsi Vue 3, harus adopsi Nax3.
Itu kayak.
- Dua kali naiknya ya? - Iya.
Harus belajar Vue-nya, harus belajar NaxJS-nya.
Sudah begitu diriku punya pengalaman dengan Nax2 kan.
Nax2 itu memang salah satu framework yang menurutku cukup terkenal dengan magic-magic-nya gitu.
Jadi banyak hal ajaib yang bisa terjadi di Nax3S.
Kayak kita bisa pakai sesuatu tanpa harus impor barangnya.
Itu bisa di Nax3S.
Which untuk banyak orang itu membantu ini ya, productivity-nya.
- Dan ada yang mau bingung. - Bingung.
- Sebenarnya kalau posisi kita udah di dalam. - Itu juga sih.
Kalau dapat kode yang bukan kita tulis, itu pusingnya minta ampun.
Kalau kita sudah berada di ekosistem Nax2-nya, itu kita paham kok sebenarnya.
Memang cara kerjanya begitu.
Tapi untuk outsider, orang yang baru belajar, misalnya datang dari yang react yang apa-apa.
Harus jelas runtungannya, belajar caranya Nax3S. Ini kadang-kadang khawatir terus tersesat di jalan.
Kok ini dia bisa pakai sesuatu tapi gak pernah diimpor?
Yang begitu-begitu bikin learning curve-nya tersyok-syok.
Jadi aku udah mencoba rewrite dari yang versi 2 ke versi 3.
Udah, udah coba. Ngikutin path-nya dia, terus coba kosongin semuanya.
Terus mulai create awal, terus masukin kode-kode kita ke kodenya mereka.
Tapi tetap susah banget gitu.
Itu mungkin bukan salah framework-nya, tapi salah diriku juga.
Karena di yang versi 2 itu diriku bikin banyak walk-around.
Jadi akhirnya walk-around itu tidak secara offisial terdokumentasi dengan baik di path migration-nya.
Jadi kesusahan untuk memindahkan dari versi 2 ke versi 3.
Karena projeknya juga bukan projek yang beresiko, gak ada yang akan rugi kalau diriku tulis ulang dari awal.
Tentu mempertimbangkan itu ya, mempertimbangkan ini projek pribadi, gak ada yang akan rugi.
Terus gak ada analitiknya juga, dari diriku gak tau ada yang pakai tokoh.
- Oh saya pemakai, saya pemakai.
- Saya gak berasa ada yang dirubikan dengan proses rewrite ini.
Terus benefit-nya buat diriku sendiri jadi belajar spell kit dengan lebih baik.
Sebelumnya udah gak ada yang type spell kit juga.
- Yang pakai spell udah di mana?
- Sebelumnya udah.
- Sebelum pakai spell kit udah nyoba spell kit.
- Tapi kalau view ke spell lebih enak memang migrasinya, maksudnya pemahamannya.
- Depens ya, soalnya secara sintax banyak yang berbeda.
Jadi banyak hal yang mesti di pelajari ulang memang, dari view ke spell kit.
- Spell.
- Tapi nanya, iya spell, spell kit beda lagi.
- Spell.
- Kalau pengalaman ketemu spell kit itu sebenarnya di tokoh beda udah ada yang satu halaman yang pakai spell.
Homepage-nya dia, homepage yang pervisit.
Jadi kalau kita belum pernah nunjungi halaman tokoh beda, terus kita nunjungi itu yang serve SSN spell.
Tapi begitu kita klik sesuatu atau refresh halaman ini itu udah pindah ke halaman react-nya.
- Oh ya waktu di feature di Chrome Dev Summit 2018 ya.
- Buat ngeplik si performance-nya.
- Tapi itu masih spell versi 2 loh, gak di update tapi ya.
- Pada akhirnya gak ada yang maintain juga karena cuma satu halaman, terus ada fitur.
Fiturnya jadi gak ketinggalan sama fitur yang di halaman react-nya.
Gak tahu akhirnya gimana obrolan dibuang aja, malih pakai react aja gitu ya.
- Udah dari server component juga sekarang kalau misalnya mau DSSR.
- Udah stable emang tuh?
- Ya stable-stable aja sih sebenarnya ya.
Cuma maksudnya sekarang kan udah ada spell kit ya SSR-nya ya.
Jadi kayak approach mereka tuh paling different gitu.
Kayak mereka dulu tuh render manual gitu aja di server.
Kayak react tuh render to string di server lah.
- Jalanin aja sampe jadi HTML.
- Itu pertama ketemu spell.
Jadi secara sintaks sudah pernah ketemu lah.
Terus di Shirebox juga ada tuh satu internal application yang pakai spell.
Tapi pada akhirnya juga gak di maintain karena developer-nya developer react semua.
Jadi di maintain tapi ini kayak liar gitu modingnya.
Ada cerita lancung masa bisa.
Jadi kalau di react itu kan kita biasa offer props ke children.
Terus kalau kita pengen ngubah props tersebut kan kita lempar callback ke atas ya.
Handle chain atau on chain gitu ke atas nanti.
Bagian atas yang ngubah props tersebut kan, biar propsnya di drill ke bawah gitu.
Nah disvel, gak tau ini fitur atau bakat atau gimana ya.
Disvel, some how ada orang yang bisa ngubah children.
Ngubahnya di children.
Jadi secara data flow kan bingung ya maksudnya.
Ini kok propsnya berubah ya?
- Nah cuman salah, misalnya mindset-nya.
- Mindsetnya masih mindset-nya.
- Iya, as is well punya convenience.
Metode sendiri kan dispensi.
- Iya, kalau mau chance flow.
- Seperti kan dengan cara mana kita di react.
- Akak-akak memontir lah ya.
- Kok ini ada yang ubah props di children ya?
"Ajir ini siapa orang ya?"
Itu susah banget dipres.
Gimana cara kita tau komponen mana yang diubah di children?
"Hahaha, susah banget cari, Pak."
Dan some how kan itu bisa bikin ini ya.
Bug yang unintended dan susah nge-debugnya gitu.
Karena secara data flow sebenarnya bisa aja lempar aja callback ke belakang
atau pake event bus atau listener gitu ya.
Biar ini jangan langsung diubah, di-assign gitu loh maksudnya.
- Nah cuman kalau kayak gitu di kerja satu team,
terus tiba-tiba random suka-suka masing-masing nggak.
Maksudnya nggak satu sisi kita, cara kerjanya gimana mah.
Bukan karena react-nya atau swell-nya, tapi kalau misalnya...
- Kesepakatan bersama.
- Akal-akalan sendiri tanpa kesepakatan style-nya atau kayak filosofinya,
ya itulah pokoknya passing data-nya gimana, ngeubah state dimana,
itu mah ke depannya tetap bakal repot.
- Diriku siakin begitu-begitu itu fitur ya, soalnya jalan gitu.
- Fitur, fitur.
- Developer-nya ini developer-react semua ya.
Jadi cara, approach-nya masih approach-react, jadi kebingungan.
Nah, terus selain profesional ketemu di Tokopedia dan Cyrebox,
diriku sempat bantuin PHP ID, bikin beberapa project kecil-kecilan,
itu sengaja pakai, dulu awal-awal tak bikin itu pakai Cyper.
Terus muncul Svelkit, satu project tak migrate itu.
Jadi diriku ngerasain migrasi dari Cyper ke Svelkit-nya.
Nah, di situ kayaknya nemu ininya loh, nemu kliknya gitu sama si Svelkit.
Ah, enak banget nih ngoding di lokalnya, kenceng banget.
Refresya kenceng.
Jadi begitu kemarin dapet kesusahan migrate dari Nox 2 ke Nox 3,
yang kepikiran pertama tuh Svelkit.
- Svelkit.
- Kok dibanding Next.CS gitu.
- Kesempatan real-real.
Pas itu Next.CS lagi ini juga, lagi heboh-hebohnya itu naik ke yang 13 itu.
Eh, orang maju-mundur-maju-mundur gitu kan.
Ini app router apa patch router?
Daripada itu pake yang geletek aja Svelkit.
Jadi gue nggak ikut kebingungan mikirin patch router atau app router,
tapi tetap ngerasain hal yang baru gitu.
Jadi itu pilihan mudah yang terambil.
Nah, kita pengen tahu nih, kan dengar-dengar kabar katanya,
karena berhubung kita bertiga ini belum pernah ada yang nyobain Nox.
Kalau kata Damar nih, auto importnya itu keren.
Tapi kalau buat orang di luar Nox, bisa jadi, ini dari mana ya gitu kan.
Karena udah biasa pake import kan.
Jadi kalau itu memudahkan buat orang yang sudah terbiasa.
Jadi si Nox.CS ini katanya developer experience-nya keren banget gitu.
Apakah benar demikian dari pengalaman Mas Irvan yang mencoba Nox.CS versi sebelumnya ya?
Bukan versi yang terbaru ya.
Compare dengan katakan Svelkit atau Nox gitu.
Bahkan dulu ketika diriku pake Nox.CS versi 2 ya, itu sebenarnya cukup convenient kok.
Tapi ya problemnya kita mesti di situ gitu.
Mesti stay di situ, karena magic-nya itu totalnya magic yang cuma bekerja di Nox.
Itu bukan hal yang bisa diimplementasi di tempat lain gitu.
Jadi memang itu ketika kita kerja pake Nox.CS, kalau mau produktif emang harus nyikuti...
- Stay di satu framework itu ya?
- Opininya si Nox.CS, termasuk teknik-teknik magic-magicnya itu.
Somehow kalau kalian adopsi Nox.CS dan fokus di situ menurutku sih akan sama produktifnya lah.
Sama framework-framework lain gitu.
Terus di belakang layar kan dia mulai ini juga ya, mulai pakai fit juga ya.
- Iya belakangnya fit.
- Menyenangkan.
- Sama aja dengan mengatakan pakai angular, ya udah stay aja di angular pasti produktif juga ya kan?
- Iya.
- Tapi learning curve-nya agak lebih tinggi ya kali ya?
- Coba bentar, angular sama Nox nggak tahu ini subjektif ya?
Jadi aku sebenarnya nggak terlalu bisa ngerti dikit,
cuma bukan power user, pernah megang codebase Nox sekitar satu minggu.
Kuat satu minggu doang.
Jadi kasusnya di tempat kerja dapet legacy code ditulis oleh pihak lain,
maksudnya di luar kita, dan kita nggak punya akses.
Iya punya tiba-tiba dapet code aja,
terus sebagian harus diintegrate ke produk lain yang produk di tempat kerjaku.
Cuma satu timnya kecil, developernya cuma tiga soalnya, kita bertiga nggak ada yang ngerti view.
Cuma kan sebenarnya biasanya bisa dikira-kira ya dari ngebaca, ngejalanin.
Ini susah banget.
Terus akhirnya yang front-end satu doang kebetulan sendirian,
yang lain aja cuma support moral doang,
karena bisa react, maksudnya kalau JavaScript ngerti,
cuma kalau nggak menguasaiin kalau buat bikin UI.
Kebetulan UI-nya harus dibuat baru juga, jadi cuma pakai service-nya.
Apalagi intinya terakhirnya, akhirnya nggak pakai karena itu alesan specific project itu.
Banyak yang harus di-rewrite, akhirnya dapet buy-in view dengan alasan
ini kita semua nggak ada yang bisa, nggak ada yang ngerti, sulit banget dijalanin.
Bakal lebih cepat kalau bikin baru dengan stack lainnya.
Cuma ya dari pengalaman ngeliat codebase nax sekitar seminggu gitu,
kayaknya sama angular mirip-mirip deh.
Soal kemudahan dipelajarin kalau kita dadakan harus mempelajari
existing codebase yang bukan ditulis oleh kita sendiri atau tim kita.
Yang lain teman-teman setuju atau nggak, silahkan coba yang dicat.
Jadi mau compare sama, mana tadi, filekit ya?
Enggak, compare-nya sama angular lah. Yang dianggap sulit juga.
Angular kan emang roommate, cuma mvc, yang penting kita pelajarin mvc-nya,
terus pelajari, ya kan dokumentasinya juga sebenarnya cukup bagus juga,
ya maksudnya tetap take time, cuma cukup jelas juga.
Jadi kelihatannya comparable deh tingkat kerepotan mempelajari codebase angular dan nax 2 sih.
- Sama-sama susah. - Sama-sama susah.
Tapi ketika sudah dikuasai, susah keluarnya.
Jadi kayak di makan masuknya susah, begitu sudah di dalam itu susah keluarnya.
Mau belajar framework lain itu pasti susah tuh, karena semuanya sudah disediakan,
semuanya sudah magic, gitu kan.
- Nah sama itu sih. - Boleh, boleh, boleh.
- Tapi di luar dari framework-nya sendiri ya, di luar dari banyak aturan di framework-nya sendiri
yang menjadikan seseorang podsider kayak kita, itu harus belajar dengan, apa istilahnya,
dengan sungguh-sungguh untuk bisa mengerti framework tersebut.
Di luar hal itu, itu sebenarnya kita mesti maklum juga bahwa bahkan mereka-mereka yang pakai metaframewalk,
yang sudah punya convention yang cukup banyak gitu, jadi berbagai hal,
itu mudah untuk menjadi kacau, sehingga orang-orang yang bahkan mengerti framework itu
bisa kesusahan untuk memahami codebase tersebut.
Itu kita mesti maklum hal itu, bahwa itu bisa terjadi di perusahaan apapun,
di projek apapun, oleh siapapun, gitu.
Diriku sudah ngoding Rack.js sejak di Tokopedia.
Tapi ketika pindah ke cyborg, itu banyak hal yang mesti dipelajari lagi.
Karena ternyata cara render-nya berbeda, banyak hal yang berbeda.
Ketika pindah ke GovTech, sama juga.
Padahal pakai Next.js kan yang sudah metaframewalk.
Padahal ada banyak hal yang mesti dipelajari.
Jadi maksudku bahkan pakai metaframewalk pun, biasanya tiap-tiap company atau tiap-tiap orang
punya opini-nya terhadap patuhya yang bikin outsider itu
mesti memahami konvensi atau opini-opini tersebut,
biar bisa seproduktif kayak kita megang framework yang biasa kita pegang sehari-hari.
Jadi memang mesti dipahami bahwa ketika kita pegang framework orang, bahkan yang samapun,
itu produktivitas kita akan drop.
Menurun dulu, ya. Menurun dulu.
Sampai kita bisa catch up dengan bagaimana mereka bekerja.
Jadi kalau melihat use case-nya yang cuma misalnya 2 minggu pegang project tersebut,
jadi mungkin itu adalah masa-masa untuk memahami konvensi dan opini-opini yang terjadi di bahkan metaframewalk tersebut.
Tapi kalau AI coding chatbot, LLM, dan lain-lain tambah canggih,
mungkin ini kedepannya bisa membantu. Sekarang udah kayak co-pilot atau code dan lain-lain,
kan udah ada feature explain this code.
Asal coding-nya nggak, maksudnya work around-nya dengan aneh-aneh amat.
Justu jadi kacau ya nanti ya.
Banyak tangan yang pegang, bayangin satu codebase, banyak tangan yang pegang,
dan taksain akal-akalan mounted dimana-mana.
Monkey patching.
Ya chatbot-nya suruh explain, coba ini pelajarin seluruh codebase, coba jelasin ke saya ini maksudnya mau ngapain.
Itu yang bikin bot itu susah replace programmer, karena programmernya bikin work around di mana-mana.
Ini nggak ada di dokumentasinya, atau cara satu orang dengan orang lain dalam satu team beda-beda ternyata.
Chatbot-nya bingung, ini pattern-nya kayak apa.
Sama-sama pake redact aja beda, bisa beda ya gitu.
Diasain ke bebe, diasain ke cewek, terus ada warning-nya jangan diilangin yang di tengah-tengah.
Jangan langsung, nanti nggak jalan.
Contohnya, satu codebase state management-nya ada dua, coba gimana sih.
Sainnya tuh, satu dipaksain, bikin satu middle layer state management.
Tapi diriku pernah ngerasain gitu Mas Ivan, itu biasanya kalau kita in the middle of migration.
Dan projeknya gede misalnya, terus kita mau migration, hal-hal lainnya misalnya redact itu.
Kita nggak bisa serta-merta membuang karena kita bahkan belum tahu konteksnya misalnya redact ini, state management kan kadang liar ya.
Bisa di dispatch dari mana aja bentuk string misalnya, susah-susah di-tag-nya gitu.
Nah, caranya adalah yaudah kita install library lain dulu, pelan-pelan kita migrate satu-satu.
Bikin middle layer-nya, terus satu-satu.
Tapi kan itu tujuan akhirnya yang lama bakal diilangin.
Nah, terus yang terjadi Mas Ivan pindah ke tempat lain, projek Mas Ivan.
Yang ngelanjutin bikin state management itu ketiga, supaya kalian nggak tahu yang kedua dan satu itu ngapain.
Bisa jadi, bisa jadi.
Tapi kan itu senenya maintain legacy kan, dan nggak semua orang bisa melakukan hal itu Mas Ivan.
Tidak semua orang punya kesabaran untuk melakukan itu.
Saya rasa sih itu kenapa kita dibayar mahal ya.
Kalau cuma nulis kode, sekarang AI bisa disunuh nulis kode.
Tapi kalau mikirin beginian, cuma manusia ya yang bisa.
Mungkin orang best practice sekarang nyuruh kita install 2 state management dalam satu codebase.
Tapi untuk orang yang sudah punya pengalun bertahun-tahun, mereka tahu bahwa
ini projek mesti tetap jalan di production dan kita harus mulai dengan sekecil apapun.
Ya udah install 2 aja dulu gitu.
- Oke, nah tadi kan dari Nux, terus Mas Irvan di professional kan Next.js, terus ke SpellKit.
Kira-kira selain tadi cepat development build-nya, SpellKit kelebihan dan kekurangannya apa?
Apakah tidak terganggu dengan +.paste.js?
- Itu, itu, itu. Parah banget, parah. - Parah ya.
- Parah itu kok. - Saya juga terganggu dengan hal itu sih.
- Kenapa nggak ada +.paste aja gitu. - Iya.
Parah sekali emang itu.
Itu lagi-lagi adalah pilihan yang diambil tim SpellKit ya.
Yang mana kalau kita mau nyamplung di situ, kita mesti mahmum dengan ini tersebut.
- Ada bloknya ya, ada artikelnya ya. - Iya, buat orang-orang outsider kayak kita
memang sepertinya harus melakukan hal-hal salah dulu gitu.
Biar kita paham bahwa ini mesti diperhatikan gitu.
Jadi kok begitu kayak nambahin sesuatu di + layout atau +.paste gitu lupa.
Kok nggak berubah-berubah itu sampai seharian? Ternyata tanda + itu mempengaruhi.
- Tanda + mempengaruhi. - Tak kira cuma.
- Temen-temen XJS yang baru yang app router juga kayak gitu tuh kan ada,
nah ini nggak pakai +, cuma kan ada konvensi yang reda ribet, layout.tfx,
ada layout, ada template, ada page.
Nah itu kalau, jadi ya kan ada hirarkinya tuh.
Kalau misalnya urut salah hirarki, ya maksudnya nggak jalan sesuai kemauan kita.
- Terin baru ini ya, annoying.
- Fun fact diriku tau ini justru di filekit dulu dibanding Next 3 Glass.
Jadi diriku sebenarnya sebelumnya ngerjain yang migration dari Ceper ke filekit,
terus sudah ketemu tuh yang kenapa dia harus ada layout, ada page gitu-gitu.
Kan itu hal baru ya, terus perasaan kok rumit banget ya,
satu direktori harus ada beberapa file gitu.
Diriku komplain tuh di Twitter soal hal itu kenapa harus begini ya.
Ternyata ada yang nyautin, "Mas itu bisa jadi company direction tuh."
Karena si Next app router ternyata ada opsi konvensinya sama.
Masa lihat, "Ini mirip banget sama filekit."
Jadi kayaknya emang direction dari company-nya, dari versalnya biar orang makin familiar dengan router-nya Next CS.
Jadi cara ngatur director ini tuh mirip banget sama filekit itu.
- Spellkit kan diakuisisi sama Versal kan, jadi ketawa sih.
- Iya, tapi kan maksudnya karena kita... - Riserisnya yang di-hire.
- Iya, kita lihat kan itu hal yang berbohong. - Oh iya, riserisnya, sorry.
Bukan, bukan, iya. Bukan, sorry, salah, salah, salah.
Bukan spellkitnya yang diakuisisi tapi riserisnya yang di-hire.
- Riserisnya. - Riserisnya.
- Riserisnya. - Iya.
- Riserisnya. - Iya.
- Riserisnya. - Iya.
- Riserisnya halus lah. - Berarti...
- Riserisnya halus. - Iya.
- Iya, berarti timnya Next CS, timnya Versal banyak belajar dari Riseris.
Jadi influence-nya kalah. Lebih menang Riseris sekali. Jadi ngikut.
- Itu bikin diriku sadar. Jadi mungkin kadang-kadang kita nggak cukup belajar framework-nya doang gitu.
Kita mesti dengerin beritanya gitu.
- Cuma ini kan... - Itu jadi mesin sekarang.
Kalau kita baca isu-nya, itu kan juga sebetulnya C-next up-router itu kan beta udah lumayan lama ya.
Dan apa, di GitHub, ya keuntungannya ngikutin apa, project open source, ya kita bisa liat semua diskusinya
walaupun panjang banget, ya itu back and forth-nya kayak apa, argumen-argumennya juga.
Maksudnya, pas kita udah baca itu semua, pertama pasti capek karena baca panjang banget.
Cuma abis itu kita jadi oh ya oke, yang tadinya pas pertama kita mesti ngerjain,
kan refleksinya complain ya, "Abang, ribet banget sih kayak gini, nambah-nambahin hal yang harus diafal,
dan ini tuh belum tentu bisa di-carry, belum tentu bisa dibawa di teknologi lain."
Tapi setelah kita tahu why-nya, kita jadi punya insight kenapa pakai solusi ini
buat mecahkan masalah ini, ini, ini, jadi ya menarik juga sih.
- Itu reflek pertama aku complain memang, karena diriku kayaknya ketika ketemu itu nggak keingat gitu,
kalau spellkit dengan C-next itu payungnya sama sekarang.
Tapi ketika ada yang ngikutin itu jadi oh, jadi make sense ya, jadi ketika diriku moding spellkit,
diriku tetap bisa bawa nih knowledge yang ada di up-router-nya atau kebalik.
Misalnya diriku ternyata lebih duluan moding spellkit, ternyata pas mau catch up di next,
yang versi 13-nya, sudah punya pengalaman dengan spellkit-nya.
Pada akhirnya kan familiaritinya ya, jadi lebih mudah ininya, belajarnya gitu.
Itu kayaknya nggak didapatkan dari dokumentasi, harus ngikutin beritanya.
- Harus pengalaman ya, harus pengalaman.
- Nah, berhubung kita bicara soal spellkit dan spell juga,
Liz Harris juga lagi pindah dari TypeScript ke Vanilla JS.
- Ini udah lama sih. - Dan JS Doc.
- Udah lama, udah tau. - Udah lama ini.
- Udah tau dia. - Iya, tapi panasnya baru kemarin-kemarin
gara-gara digosok sama DHH dan teman-teman.
- Digosok ngomongin TypeScript dan JS Doc.
- Nah, ini apa teman-teman, pada migrasi lagi nggak ini TypeScript ke JS biasa?
- Pengalaman dari JavaScript ke TypeScript? Atau sebaiknya?
- Atau TypeScript ke JavaScript? - Atau secara arsitektur ya.
Jadi, masalahnya TypeScript adalah karena butuh transpilasi, ada proses untuk dibuat
dari TypeScript ke JavaScript.
Masalahnya adalah, leceh, diriku kasih kasusnya apa ya di Tokopedia ya?
Tokopedia itu mono repo, terus consists of tens of services and tens of libraries.
Jadi, ketika kita build satu services, kita akan detect depedensi-depedensis,
termasuk internal depedensis ya, berarti adalah libraries yang ada di mono repo tersebut.
Kenapa? Karena kalau dia depedensis, berarti dia harus dibuild sebelum service tersebut dibuild kan?
Karena dia dibutuhkan sama service yang dipakai.
Ya, masalahnya adalah kalau librariesnya ditulis pakai TypeScript, itu hal itu dilakukan terus-terusan.
Jadi, tiap kali kita build satu services, jadi kita harus transpilasi libraries-librariesnya.
Itu mungkin bisa disolok kalau punya kasing strategi yang bagus gitu.
Dan most of the cases kadang kasing DCI suka benar-benar salah lah.
Dan kalau kita punya hundreds of developer yang coding di satu repo seharian,
itu frekuensinya tinggi banget untuk case-nya nggak valid.
Jadi, kerjaan untuk nge-transpile TypeScript itu terus-terusan terjadi.
Dan saya rasa itu kasus yang mungkin ditemui sama kecerdasan itu.
Karena librariesnya mungkin ketika mereka development internal itu kayaknya nggak perlu banget di transpile.
Kalau di Tokopedia sih kita kasusnya di offload.
Kayak yang tadinya kita mono repo, jadi mono repo kan nggak kenal versi.
Dia link ke atas saja, kalau dia belum di transpile ya transpile.
Akhirnya ya udah kita publish aja ke library, bentuknya udah transpile kan, udah JavaScript.
Tinggal download dari registry aja.
Cuma itu kan jadi kayak kita offload tugasnya ke luar gitu ya.
Tapi pada akhirnya sebenarnya library-nya akan nge-transpile juga.
Cuma nggak dilakukan on the fly yang ketika kita mau nge-build si service-nya.
Karena itu nggak make sense gitu, kita mau nge-build service-nya, tapi library yang jarang berubah itu di transpile terus-terusan.
Karena cache-nya nggak valid itu.
Jadi kalau ngobroli kasusnya Rich Harris, make sense karena kasusnya library.
Karena dipakai oleh, di-consume oleh sysvill codebase yang Tok akan di, itu juga kan.
Di transpile juga, bakal di-transpile juga.
Jadi kayak buat apa gitu. Mungkin ya, mungkin ya.
Tapi kalau sebagai developer, apakah perlu pake TypeScript?
Atau pake JS Docs aja cukup?
Karena diriku banyak modingnya application gitu ya, yang full gitu ya.
Client gitu ya, untuk client.
Jadi aku masih mikir itu perlu ya, karena banyak intensif mainan data gitu ya.
Terus culture team-nya juga biasanya diriku kerja dengan team yang banyak.
- Udah terbiasa TypeScript. - Terus yang modingnya.
Maksudnya itu salah satu kontrak lah kalau buat gue ya.
Kayak TypeScript itu kontrak untuk kita bisa tahu struktur data apa aja yang ada yang mengalir di halaman tersebut.
Jadi kalau tanya penting atau nggak, buat gue mungkin masih penting ya.
Tapi kalau apakah semua harus pake TypeScript mungkin nggak.
Tergantung case by casenya.
Jadi kalau hype-hype kayak gini tuh yang harus diperhatikan itu kesamaan-nya, polanya.
Oh, spell kit itu library atau framework.
Terus yang si David Hennemeyer Hansen itu nggak mau pake TypeScript juga, dia di library juga.
Library-nya Ruby on Rails kan. Dua-duanya library gitu.
Kalau kita yang pemakai library dan kita yang pakai untuk end-user, ya nggak hampir bisa dibilang tidak ada hubungannya.
Jangan tiba-tiba begitu bilang, begitu ngeliat beritanya langsung, "Oh nggak usah pakai TypeScript, pakai JavaScript lagi."
- Kadang mesti lihat kondisinya juga sih, kondisi kitanya maksudnya. - Kondisi, iya, iya.
Soalnya nggak semua yang bahkan kasurnya cocok itu make sense di kondisi kita.
Soalnya kondisinya adalah CI-nya bayarnya udah gila-gilaan, pengen reduce cost.
Ya mungkin salah satunya ya reduce aja, compile time-nya itu.
Jadi udah nggak usah nulis JavaScript, karena mungkin duitnya itu lebih mahal daripada maintenance costnya nggak bisa jadi gitu ya.
Ya itu nggak bisa dibilang, cuma kalau ada kondisi begitu bisa jadi TypeScript jadi nggak make sense lagi.
Atau misalnya timnya sendirian dan...
Sama learning curve-nya kan tinggi ya, learning curve-nya tinggi, kalau timnya kecil ya buat apa?
- Learning curve itu depend. - Nggak terlalu tinggi, nggak terlalu tinggi.
- Ini bisa incremental juga. - Bisa incremental dan bisa any.
Nah, kalau pakai any itu udah, waktu di Tokopedia kalau pakai any apakah itu udah dianggap sebagai TypeScript atau belum?
Bisa, bisa, karena kan kita ngitungnya ininya, extension-nya.
Extension ya, selama .ts udah gitu ya, padahal dalamnya JavaScript gitu ya.
- Tess ignore, Tess ignore. - Itu proses ya.
- Itu proses menurut Mas Rita. - Process ya?
- Itu proses, karena yang ditakutkan adalah dengan adopsi TypeScript itu productivity... - Turun.
- Turun jauh gitu, kalau turun doang, turun lantai gitu ya. - Aman lah ya, masih bisa.
Tapi kalau tiba-tiba turun tinggi gitu, buat mikirin type-nya doang itu udah nggak make sense.
Kalau dirimu kesusahan, ngetypingnya udah any aja dulu gitu.
Padahal mungkin harganya nggak sebanding dengan waktu yang habiskan gitu.
Pada akhirnya orang akan belajar kok dengan sendirinya gitu.
Ingat ya, kalau para senior lihat juniornya any jangan dimarahin dulu.
- Lihat situasi. - Iya, lihat situasi.
Ganti aja tess config-nya, dibikin string.
- Harus ada inilah, dibantu lah maksudnya. - Dibantu, dibantu.
- Kulturnya tuh ini, collaboration, jangan blaming gitu. - Iya.
Sulit loh, maksudnya kalau belajar TypeScript-nya itu mungkin oke lah.
Belajar TypeScript terus dipakai di back-end di Node.js itu masih oke.
- Ketemu reeks, tengah mati. - Pusing.
- Pusing. - Bikin props ada children-nya ya, pusing.
- Ini children gimana cara typingnya? - Tipenya, tipen HTML lah, apa?
Pusing loh. Jadi semuanya, iya.
Jadi ya harap dimaklumi aja. Harus banyak-banyak berempati ya.
Di kolaborasi lah, intinya di bagian yang susah.
Betul.
Prop types aja dibikin objek semua?
Objek dan nggak di depan kan intinya kan?
Nggak di depan, objek aja udah gitu ya.
- Itu kan alias dari any ya, objek. - Iya.
Objek isinya apa, nggak tahu.
Oke, kita kembali ke Next.js. Nah ini ada pertanyaan dari Damar.
Next.js itu populer gara-gara apa ya awalnya?
Dia adalah meta framework pertama awal-awal ya, kalau nggak salah ya?
Meta framework, iya.
Yang salah satu yang pertama dulu kan Next.js sama Gatsby itu yang...
Betul. Oh iya, Gatsby, Next.js.
Tapi bedanya Next.js ini dibundling sama Versel.
Deploy-nya mudah, dipermudah.
Dan dia bisa server-side rendering kan, sudah ada langsung SSG.
Server-side rendering, iya.
- Kalau Gatsby kan berangkat dari... - Static side generation.
- Static side generator. - SSG.
SSG, dia yang awal-awal.
Kita harus percaya, Next.js itu di-boost banget sama Versel.
Iyalah, jualannya dia itu.
Engga, yang bikin kan emang, yang bikin Versel adalah yang bikin Next.js.
Ini emang produknya dia.
Kalau hal yang sama gitu ya, Next.js yang bukan Versel.
Jadi aku nggak melihat kalau itu akan bisa segede sekarang gitu.
Karena kayak semuanya udah di first-class-nya lah istilahnya, Next.js itu first-class-nya.
Kita sebelum ada Versel gitu ya, front-end engineer, bagaimana cara dia deploy.
Aplikasi yang server-side render dan bisa nge-serve API.
Itu nggak kepikiran.
Harus belajar server-side language juga kayak PHP.
Deploy-nya juga harus deploy-an server-side.
- Harus bisa nge-deploy server-side. - Iya.
Berapa banyak orang-orang yang bisa nge-deploy ke server-side.
Tapi apakah tidak menuju ke vendor login?
Ya iyalah. Makanya kan yang pakai Next.js coba tanyain deploy-nya.
Dikira muda deploy Next.js di cloud lain.
Di kantor sekarang pakai Versel gitu?
- Enggak, enggak. - Oh enggak kan?
Pai GCP ya.
Sebenarnya bisa node-node-f biasa kan, tapi ribet.
- Yes. Tapi kan maksudnya... - Tidak optimal.
Atau apa ya? Nggak sejati surga ketika kita pakai Excel gitu.
- Sulit. - Versel tuh, apa?
- Kalau... - Adhiktif karena konfiniens.
Jadi kayak cuma dipush ke repo, udah diurus sendiri.
Bahkan kayak hal-hal kayak environment config, udah dikasih UI-nya kan.
Maksudnya kita kan nggak mungkin nge-push .env ke repo.
Nah, terus gimana biar di server-side?
Kan kalau misalnya kalau php-side ya kayak harus ngubah-ngubah engine-exe atau apa yang ribet kan.
Nah, ini equivalent-nya si Versel udah ngasih UI buat masukin environment config value.
Build command-nya apa.
- Terus... - Sama kayak kita pakai Firebase deh.
Sama kayak Firebase sudah pasti segak gitu.
Dan sulit loh sebenarnya nge-deploy Node.js application itu loh.
Karena pertama Node.js itu single-trading.
Dan scaling-nya itu sulit loh.
Saya pernah coba dari menyerah.
- Iya. - Gak semudah.
Gak semudah men-scale php web server.
- Iya. - Makanya sekarang muncul kan?
- Silahkan Mas. - Mereka muncul itu kan.
Next.js yang bisa di-deploy ke tempat lain.
- Oh, ada ya? - Ada, ada.
- Ada, coba dicari. - Lucu ya.
- Gimana Mas Irfan? Lanjut. - Lucu-lucu.
Ya itu maksudnya banyak yang mengira tuh kayak ketika deploy Next.js
ke selain Versel itu semudah kayak kita deploy ke Versel.
- Jadi ada hal yang mesti di-deploy. - Tapi justru itu selling point-nya.
Maksudnya codebase-nya sendiri, Next.js-nya sendiri kan open-source gratis.
- Kita tinggal pake. - Betul, betul.
Nah, terus yang dijual apa ya udah yang dijual kan layanannya.
- Iya. - Hosting.
Layanan, hosting, dan kemudian devops-nya kan selain hosting-nya,
layanan devops dan infra-nya yang dijual kan sebetulnya.
Iya, betul sekali.
Ya, begitulah.
Nah, ini ada pertanyaan menarik nih mengenai rewrite codebase yang sudah besar ke framework lain,
tapi PM tetap butuh fitur baru di framework yang lama.
Apakah fitur baru masih rewrite ke framework baru atau tetap ke yang lama?
- Codebase baru, fitur baru di framework lama.
Ya udah, terus yang baru aja semua.
- Ini ilmu mahal ya. - Ilmu mahal.
Tidak ada jawabannya, it depends, kan?
Ini kalau ilmu mahal, jawabannya it depends.
Tergantung, tergantung banyak hal, variable-nya banyak sekali.
Udah konsultasi, udah.
Tapi ini, ini, ini, kamang sih sebenarnya.
Maksudku banyak developer yang kadang berpikirnya ketika rewrite itu harus selalu full rewrite gitu.
Padahal kasus nyatanya itu hampir jarang banget kita bisa punya opsi untuk full rewrite satu application.
Lagi kayak Tokopedia, maksudnya kita mau full rewrite dari halman homepage sampai checkout sampai order history.
Siapa yang mau ngerjain, terus dikerjain berapa lama, nggak make sense gitu.
Buat hampir kebanyakan company itu nggak make sense untuk full rewrite gitu.
Jadi biasanya jadi muncul strategi rewrite tuh, macem-macem strateginya, bisa, let's say satu halman full.
Atau bisa kontennya aja tengah.
Bahkan diriku pernah ngeliat ada yang gitu ya.
Kayak one on one mentoring gitu ya.
Itu kaget sih lucu, lucu.
Jadi ada yang pake Next.js gitu, terus mereka mau pindah ke Next.js.
Dia benar-benar nunjukin hasilnya di produksinya gitu, Mas Rizal.
Jadi nggak omong kosong lah ya.
Oke, oke, oke.
Benar-benar ada yang melakukan hal itu.
Itu dia pake iframe, terus Next.js nya itu ditempel di iframe.
Terus kayak header nya itu masih pake Nux.js gitu.
Itu asli, diriku baru ngeliat.
Absolute.
Diriku baru ngeliat ada yang pake cara begitu.
Dan itu berhasil di produksi gitu. Berarti kan bisa kepikiran gitu.
Itu micro front-end itu.
Micro front-end itu, beneran.
Tapi diriku aja nggak kepikiran pake.
Tapi itu berhasil kan.
Dan itu bisa enabling cara dia incremental rewrite itu tadi.
Ada cost nya pasti yang harus dibayar.
Misalnya performa nya pasti turun tuh ketika proses migration itu.
Karena dia jadi punya waktu untuk rewrite satu halaman demi halaman.
Sampai pada akhirnya terselesaikan semua.
Jadi macam-macam ada yang model seliar itu gitu.
Kayak pasang iframe aja di tengahnya.
Tempelin tuh aplikasi barunya.
Bisa begitu gitu.
Ada yang melakukan itu.
Ada yang berani melakukan itu ya?
Iya di produksi dan company yang menghasilkan duit gitu.
Ini bukan mentertawakan ya.
Bukan mentertawakan.
Tapi itu inovasi kan.
Begitu ya.
Kepikiran gitu ya.
Jadi kalau di satu halaman aja di rewrite.
Terus di proxy aja.
Kepikirannya gitu ya.
Kalau duit di lapangan berarti.
Kalo kita masih belajar nih di bootcamp.
Atau belajar tutorial.
Karena kan kita mikirnya yang jago coding adalah yang punya yang bisa ngebulak-bulikin ray lah.
Yang lead code-nya jago.
Atau dan lain-lain.
Tapi praktiknya di lapangan itu kreativitas.
Buat mecahkan masalah yang spesifik banget kan.
Masalahnya spesifik, tujuannya spesifik.
Ada konstrin waktu dan biaya.
Nah ini kan berarti yang diuji adalah kreativitas di akal-akalan montir tadi.
Berani ambil risiko aja.
Tapi harusnya kan.
Tapi kita mau mengacilkan itu ya kak.
Gak mau mengacilkan kemampuan untuk lead code tadi.
Karena di banyak kasus itu memang sangat-sangat dibutuhkan.
Apalagi kalo udah ngobrolin performance tuning dan lain-lain.
Jadi tanpa mengacilkan hal itu.
Itu memang kadang-kadang di kasus nyata itu kadang kita suruh ngerjain hal-hal yang lucu.
Mungkin bukan best practice yang dipahami orang-orang di luar sana.
Kerjaan kita ada naikin works aja udah.
Kita punya bisanya begini jalan.
Ya udah kita kerjain pakai cara ini dulu aja.
Nah itu kan bagian dari problem solving kan.
Lead code dan lain-lain itu juga melatih kita problem solving.
Walaupun dengan case dan cara tentu yang berbeda gitu.
Kalo lead code kan lebih ke apa ya logic kan.
Kalo ini kan lebih ke praktikalnya yang kayak gimana gitu.
Tapi itu sama-sama problem solving gitu.
Dan itu yang memang harus dilatih gitu.
- Ya itu kalo nanya tadi ya soal rewrite tadi caranya bisa macem-macem.
Tapi prinsipnya adalah jangan propose full rewrite in the first place ya.
Karena cost-nya sangat gede waktu yang dibutuhkan gede bisa jadi itu gak bisa ditanggung 1 team.
Atau bahkan projeknya kadang-kadang kalo full rewrite kan harus stop feature ya.
Feature development ya harus ada freeze.
- Ya karena resursi yang dipake buat semua.
- Iya nah kalo bisa itu jangan diajukan di awal gitu.
Jadi sepengalaman ku sih biasanya kalo bisa cari cara biar sebagian dulu.
Atau sebagian bisa macem-macem ya entah sebagian komponen atau sebagian halaman.
Atau sebagian apapun gitu.
Maksudnya kalau bisa jangan ajukan full rewrite dari satu hal ke hal lain di saat pertama gitu.
Ajukan dulu separoh rewrite atau satu halaman rewrite sampe dirimu bisa ngajuin full rewrite gitu.
- Incrementer.
- Ya itu common kok atau biasanya kadang ada yang nyebutnya ini juga ya.
POC gitu loh biar battle tested dulu gitu di production.
Kita rewrite satu halaman lempar ke production langsung test apple to apple.
Kita liat misalnya sebulan apa-apa cukup stable atau engga.
Kalo stable bisa ditambah lagi tuh.
Itu umum jadi kalo di Tokopedia itu kadang kita pindah satu halaman ke halaman lain.
Itu sebenernya ga router push gitu loh.
- Ya link biasa.
- Kala rev itu kenapa gitu? Karena service nya beda gitu.
- Bisa jadi juga pake ini.
Kalo saya pernah ada, mirip tetapi pakenya dari sisi load balancer.
Jadi kalo request ke halaman X itu lempar ke sudah aplikasi yang baru.
Nanti kalo udah jadi, nanti pelan-pelan halaman-halaman itu berubah di load balancer.
Jadi dua aplikasi tetep jalan, tetapi ini syaratnya headless ya.
Jadi datanya tetep sama, kukisnya sama-sama bisa dibaca.
Intinya semua sama untuk sisi simpan-simpanan data dan persisten datanya tetep sama.
Jadi cuma UI yang berubah.
Saya pake load balancer satu-satu, jadi gantinya di load balancer.
Jadi si user ga merasa.
- Iya makin lama pindah tuh, pindah satu-satu.
- Makin lama sampe habis proksinya.
- Sampe habis.
- Tapi itu kamen dong, maksudnya ga perlu merasa itu adalah cara curang gitu.
Karena diriku pindah dari satu company ke company lain melakukan hal yang sama di beberapa company.
Terima kasih taruh di infra di ininya.
- Oke, semoga menjawab ya.
- Nah ini pertanyaan dari Damar, kalau mau belajar spelt, pengetahuan JS nya apa ga jadi berantakan?
Soalnya kan teknikal spelt itu script.
Engga sih, justru malah melatih.
- Terbasis javascript juga kok.
- Cuma diri DSL nya.
- Yang beda cuma di syntax markup nya, ya standard lah kayak misalnya.
Apalah Laravel ada blade ya, atau ada mustache atau apa.
Jadi kayak buat ngelup, ada syntax nya sendiri, age, buat kondisional, if.
Cuma kalau, jadi spelt itu kan dibagi dua markup nya, markup kayak, ya kayak HTML.
Sebenernya apa, syntax nya sekian persen hampir mirip banget sama HTML.
Cuma ya itu ada khusus sampling language nya buat ngeprint value, buat ngelup, buat kondisional if, markup nya itu.
Terus script nya, javascript atau typescript nya bisa sendiri di dalam text script.
Kayak ada helper nya sih, ada helper yang reactive value nya itu dollar sign.
Di luar itu 99 persen nulis javascript biasa sih.
- Nulis javascript biasa.
Apalagi library nya pun vanilla ya.
- Kadang-kadang itu jadi ininya, sandungannya.
- Itu yang, kalau bisa Rie, ya malah. Rie kan ngobrol apapun harus pake state ya.
Nah ini gak ada malah.
- Itu yang kadang diriku gak mau, ini ya, gak mau meremehkan gitu.
Karena semuda apapun framework yang kata orang spelt itu muda, terus speltkit itu cukup muda.
Pada akhirnya ketika dirimu belajar satu hal, tetep ada hal yang mesti dipelajari dengan caranya dia.
Jadi bahkan orang Rie kalau masuk speltkit gak bisa ujuk-ujuk gitu.
Tetep aja dirimu akan kebingungan gitu, misalnya looping gimana pun sebaliknya.
Orang speltkit, misalnya orang speltit pindah ke Rie.
Pasti ada hal-hal yang kita, oh kok begini ya di Rie, oh kok begini di speltit.
Maksudku itu proses onboarding gitu loh. Pada akhirnya kayak let's say diriku ngerjain satu project ya.
Mungkin satu, dua, tiga halaman diriku akan kesusahan gitu ya.
Tapi empat, lima, enam halaman diriku mulai lancar tuh.
Karena onboardingnya di halaman-halaman yang awal tadi gitu.
Maksudnya apa ya, kayak perspektif sih, kayak apa ya, filosofinya ya. - Filosofinya dipelajari gimana?
- Cara svelte mentret rendering UI, meng-update state, dll. Sama cara react rendering UI, update state dll.
Itu kan lain. Nah cuma kalau kita masih bawa cara pikir framework A ke framework B,
ya jelas pusing. Tapi kita belum punya cukup pengalaman kerja di framework B.
Jadi mindset kita masih kosong, otomatis refleks mungkin kebawa pakai framework-framework lain.
Nah mungkin tadi setelah beberapa halaman, nama-nama kepala kita, ya pikiran kita keisi sama mindset si framework baru itu kan.
- Problemnya kadang kita gak punya waktu sih kak. Problemnya kadang kita gak punya waktu.
Maksudnya, kayak biasanya kasusku ya, diriku mau rewrite.
Gue gak merasa gue punya cukup waktu untuk baca dokumentasinya svelte di awal.
Jadi yang kalau bukan ya udah, babat aja. Gue merem dulu, gue migrate dengan sebisa gue.
Kalau gue kebingungan, ini kok kaya ternyata salah memahami reactivity-nya.
Misalnya gitu. Jadi modelnya patching gitu loh. Tempat mana yang kita kebingungan baru kita baca.
Jadi cara belajarnya mundur memang. Kita kayak dengan pemahaman kita dulu, kalau kita kebingungan, baca.
Misalnya diriku kebingungan gimana untuk passing props ke dalam children, terus gimana cara nangkep di children-nya.
Kalau biasanya kan jelas-jelas di function ya, ada argumennya.
Kalau di react cukup clear lah, argumennya jelas-jelas aja di functionnya.
Kalau svelte ternyata ditambahin export doang, jadi props.
Itu kan hal yang gue nggak bisa catch up di awal gitu.
Yang gue lakukan ya, gue saat kebingungan akan baca.
Tapi gue nggak punya waktu untuk baca itu di depan.
Jadi kalau gue kadang memang rada barbar ya.
Udah nyemblung aja dulu, kalau kebingungan, mundur.
Kalau gue kebingungan, kalau pake react, bingung sudah sampai tingkat tinggi,
udahlah dangerous, set it at emel dulu, trus ubahnya pake jQuery.
Itu legendaris, itu legendaris.
Itu kan jenis jQuery.
Itu jalan kan.
Sama sih, kayak jQuery.
Apa pun saksah aja kan.
Kita boleh kasih trophy nggak, masa susah?
Boleh, gue kasi trophy.
- Kasi trophy buat Mas Rizab. - Oh, kasih trophy.
- Bila seberung, kalau benar sambilnya. - Siap, siap.
- Ini ada pertanyaan lagi nih. - Bukan kepikiran ya.
Di 2023 masih perlu belajar react atau turunan frameworknya saja?
Belajar react dulu, jangan belajar langsung komita frameworknya ya.
Bahaya.
- Kalau yang benar. - Belajar JavaScript dulu.
- Belajar HTML dulu. - Kali menit.
Gini sih, Mas Rizab.
Ini yang selalu omongin ke hampir semua yang one-on-one denganku.
Ya.
Cara-cara belajar begitu biasanya kalau kita punya orang yang bisa ngasih unjuk.
Atau bisa ngasih unjuk gininya, Mas Rizab.
- Kurikulum atau kayak... - Roadmap-nya.
Masa ada banyak orang-orang kayak gue gitu, nggak.
Nggak punya waktu untuk memperhatikan semua hal.
Jadi kalau melarang orang-orang belajar Next.js sebelum belajar react.js,
itu menurutku jadi kayak gatekeeping gitu loh.
Karena bisa jadi cara tercepat untuk belajar react saat ini, hari ini.
Mungkin lewat Next.js gitu.
- Karena itu langsung bisa deploy. - Langsung bisa deploy.
- Bisa deploy dan everything kayaknya... - Di dokumentasi juga diarahkan ke Next kan sekarang.
Nah iya, makanya kalau orang tanya harus belajar react.js dulu atau Next.js dulu,
gue sih ambil cara yang convenient aja sih.
Yang nggak boleh lupa adalah jangan takut mundur gitu kalau maksudnya kesusahan di pengajalan.
Karena bisa jadi yang dirimu temui itu bisa jadi bukan masalahnya Next.js tapi masalahnya react.js.
Kenapa itu bisa dirimu temui? Karena dirimu lonsap belajannya.
- Nggak belajar react.js. - Dan bahkan mungkin bukan masalah react.js tapi masalah JS.
- That's it. Sama kayak dispel. - Masalah browser.
Bisa jadi, tapi kan maksudnya mental model bahwa kita nggak malu untuk drop.
- Mundur gitu, belajarnya mundur gitu ya. - Belajar underlying technology.
Jadi mungkin bukan perkara mana duluan yang dipelajarin tapi kita harus paham layer-layernya.
Maksudnya itu pas kita ngerjain Next.js nih sebetulnya under the hood dibawahnya tuh ada react.
Pas kita nulis react, component react misalnya TSX itu dibawahnya under the hood.
Itu kan TSX atau JSX-nya bakal di compile, bakal di transpile jadi JavaScript.
Berarti kita harus tahu JavaScript. JavaScript dijalani oleh JS engine di browser atau di environment lain.
Berarti kita harus tahu tentang itu. Berarti kesadaran bahwa ada banyak lapisan hal yang dipelajarin kali ya.
Itu lebih penting dibanding mana duluan.
- Di Riku dulu, di react ya belajar ya karena dari view gitu ke react. - Dari view.
Jadi ku berasumsi kalau loopingnya react yang pakai .map itu, itu react.
- Jadi di Riku selalu nyari gimana cara loopingnya react. - Bukan JavaScript gitu ya.
Padahal kita capa script kan. Jadi sebenarnya kayak kita bisa pakai filter atau apapun gitu ya.
Yang looping pokoknya bisa pakai for, bisa pakai apapun yang ketuknya looping.
- For each juga bisa gitu kan bebasin. - Iya maksudnya ketika kita...
- Ketika ada returnnya gitu kan. - Iya. Kita jadi make sense gitu.
- Bukan murni JavaScript, itu prototype. - Iya, iya.
- Iya kan? Map for each itu prototype semua. - Yes.
- Yang diadopsi. Jadi core.
- Berarti lebih ke apa ya, kita sadar bahwa kita belum belajar fundamentalnya.
Sehingga kalau ada kesulitan, kita harus berkuat fundamentalnya.
Jangan hanya merasa "Wah belajar next.js", "Gak mau ah belajar react", "Gak mau ah belajar HTML" gitu ya.
- Tapi nyuruh orang belajar fundamental di awal, itu bisa jadi gak... - Gak efektif buat mereka ya.
Kecuali kuliah atau apa ya, kalau kuliah kan ada semester satu ya kita kan harus ikut matanya.
Itu kan sudah ada kurikulum.
- Sudah ada kurikulum, kalau sudah kurikulum mungkin step by step. - Untuk belajar sendiri, di jemput malas sih pasti.
Apa ya, karena mungkin gak konkret ya, kalau kita baru banget belajar, belum kebayang dan gak jadi apa-apa.
Maksudnya beca teori, hasilnya kayak gak jelas, hello world doang, malas kan pasti.
- Iya bukan pasti sih, kemungkinan. - Belajar untuk ngajarin orang.
Itu juga biasanya dirimu harus belajar dengan comprehensive itu.
- Jadi jangan yang skip modelnya. - Oh iya kan.
- Oh iya benar, itu justru juga belajar. - Sepertinya kayak Mas Trinta nih.
Dia belajarnya untuk ngajarin orang kan, itu gak boleh model yang kayak diriku belajar lupain semua.
Udah nyemplung dulu, nanti orang yang mau diajarin kebimbungan juga.
- Yah itu bahaya sih. - Jadi kayaknya disesuaikan aja sih sama kebutuhannya, kondisinya,
atau dengan kontennya si orang yang ingin belajar.
Oke, oke, mantap. Ini ada satu lagi nih.
View 3 menurut temen-temen gimana? Mas Irvan, ada opini tentang view 3 dibandingkan view 2?
- Gak, oh gak ngikutin ya view 3? - Iya pakai.
- Katanya orang sih lebih dekat ya, lebih dekat ke rakyat. - Lebih dekat ke rakyat.
Tapi karena diriku gak in touch langsung, jadi gak bisa banyak komentar lah.
- Tapi fitnya luar biasa, luar biasa. - Fitnya luar biasa, dipakai di mana-mana sekarang.
- Langsung wuss wuss wuss. Redwood aja sekarang katanya. - Tidak menyakitkan secara ekosistem sih sebenarnya.
Tidak tahu pakai fit, kan tadi pakai webpack, akhirnya release selanjutnya pakai fit kalorimix, gak tahu ya pakai apa kalorimix.
- Belum liat sih. - Kalo Next.js itu masih pakai webpack ya.
- Gabung sama, campur sama SWC itu ya. - Mereka bakal pakai turbo pack nanti, turbo pack.
- Mereka kan bikin sendiri ya. - Oh iya, cuma sekarang masih eksperimental.
- Sama juga yang bikin. - Oh iya, si Marcel tuh gila ya.
- Yang ngambil orang webpack. - Tapi ngobrolin soal fit ya.
Sebenarnya revolutionera yang fit itu karena secara ekosistem gitu.
- Karena bowser juga udah support es modul. - Maksudku sebelum ada yang fit itu yang dibikin si Evan,
itu kayak kita hampir gak pernah berpikir untuk menggantikan webpack, karena yang susah dari webpack itu secara ekosistem.
Kayak besar banget gitu, kayak hampir semua plugin ada disitu, orang banyak contribute disitu, bisa melakukan macem-macem.
Hal itu kan yang bikin orang maju-mundur ya untuk replace webpack terhadap sesuatu yang lain.
Makanya kan sebenarnya roll up nya udah dari dulu ya, tapi tetep gak bisa ngelewatin bagaimana webpack diadopsi gitu.
Nah, liat hari ini diadopsi oleh banyak framework secara ofisial gitu, itu gak menyangka sih.
Maksudnya secara ekosistem kok bisa sebesar itu ya, jadi pinternya itu bisa pintar ngebangun ekosistemnya gitu.
Secara teknologi jago lah ya, udah terbukti lah. Tapi maksudnya secara ekosistem kok bisa jadi?
- Kan ada banyak... - Dan bisa menembus batas ya?
Iya, ada banyak teknologi yang...
Gitu gak sih? Sekali meluncur, kan tadinya berat di dorong biar diadopsi project-project besar.
Sekali satu-dua, satu-dua project besar adopsi, yaudah seling, abis itu blending aja.
Ya, diriku bilang maksudnya ada banyak teknologi yang dibikin orang pinter dan secara teknik bagus itu ya.
Tapi ngebangun ekosistemnya susah, gak semua orang bisa gitu.
Nah, Evan kayak bisa kombinasi itu, makanya kayaknya fit bisa jadi lebih revolusi dari dunia itu sendiri.
Oh, udah sambil lah.
Iya, luar biasa ya.
Ada pertanyaan lagi, belum terjawab? Oh, banyak.
Sebagai pengguna framework yang unopinionate kayaknya.
Karena kan teman-teman pakai kode convention prinsip seperti clean code, arsitektur misalkan.
Banyak ya, banyak. Tergantung perusahaan juga ya. Tergantung kesepakatan ya.
Clean code ini yang dimasuk, clean code-nya ini kan ya?
Arsitektur?
Iya gak sih maksudnya?
Mungkin, mungkin. Coba, Farizal coba.
Maksudnya clean code itu apa? Soalnya ada beberapa ini ya.
Ada bukunya, ada arsitekturnya.
Ini emang ini ya, maksudnya Mas Riza, jadi clean code ini banyak diadopsi sama backend sebenarnya.
Nah, satu pengunggulannya adalah adopsinya bisa beda-beda tuh rada beda antara satu dengan lain-lain.
Tapi mereka punya benang merah yang membuat ketika kita pindah dari satu project ke project lain kayak kita punya satu benang merah yang sama.
Nah, problem different, emang kadang opini-nya terlalu tinggi yang bikin kadang benang merahnya hilang gitu loh.
Jadi ketika kita pindah dari satu project ke project lain, itu kayak it's totally different climate gitu ya.
Semacam style guide mungkin, bukan style guide ya, bukan style guide UI, cuma maksudnya coding style guide kali ya.
Tapi diriku cukup pragmatis kalau di hari-hari gitu ya, di kerjaan cari hari.
Jadi diriku merasa daripada kita capek-capek, ini opini ya, jadi jangan dianggap ini adalah hal yang benar gitu.
Diriku merasa daripada kita capek-capek mencoba adopsi clean arsitektur seperti yang sudah dijelaskan sama Pak Robert Martin bertahun-tahun yang lalu gitu ya.
Jadi aku merasa kayaknya lebih fit kalau yaudah kita pindah-pindah aja sampai convenient buat dirimu dan timnya gitu.
Jadi kayak salah satu yang dijelaskan sama clean arsitektur kan mecah-mecah file yang itu ya, mana yang use case, mana yang domain repository dan sebagainya gitu.
Nah maksudku, emang harus banget kita capek-capek gitu ya, nggak semua orang convenient gitu loh maksudnya dengan pattern yang bahkan sudah dijelaskan secara teori di buku bertahun-tahun yang lalu.
Atau kita juga nggak yakin nggak, apakah ini masih makes sense nggak buat hari ini.
Maksudku kadang-kadang ya kalau ada gitu tuh jangan jadi kultus yang kita harus ikutin mentah-mentah gitu ya.
Maksudnya kalau itu nggak nyaman, kenapa harus diikutin gitu ya.
Kalau memang itu works dan nyaman buat timnya, buatku nggak ada masalah kalau mau ikutin pelakan-pelakan apa yang ada di bukunya.
Tapi kalau nggak nyaman, pindah-pindahin aja sih. Sampai timnya ngerasa kayaknya kita naruh file berdekatan dengan ininya kayaknya lebih oke deh buat timnya gitu. Kenapa nggak gitu ya.
- Oh iya berarti semacam cherry pick itu nggak sih? Manuali cherry pick tanda kutip ya maksudnya berarti lead-nya atau siapapun lah yang di tim itu,
pilih hal-hal apa aja yang cukup penting buat di-enforce. Kayak misalnya yang file-file structure kan nggak mungkin ya lain-lain.
Maksudnya gimana pun walaupun nggak ngikut prinsip apa yang strict, ya minimal folder dan file-nya kayak gimana, komponennya taro mana, atau utility-nya taro mana,
itu kan kayaknya bisa dibilang harus ada kesepakatan. Yaitu satu contoh yang paling ekstrim. Mungkin berarti pilih-pilih aja kali ya hal yang dirasa perlu.
Nah kalau misalnya nggak keburu-murus yang lain ya udah kayak bisnis gitu. - Sebenernya praktiknya semudah. Kalau di front-end ya.
Praktik clean architectur semudah kayak sebenarnya kita selalu bikin komponen atau module base gitu loh yang berdekatan-berdekatan gitu.
Misalnya file-file yang bervariasi tapi sebenarnya beririsan dengan module tersebut apakah mau dijadikan satu module apa di tengah gitu.
Nah kalau clean architectur kan macanya based on domain gitu ya. Domain terus dia punya repository, punya use case, punya lain-lain, tapi domain-nya dibungkus.
Nah kalau di front-end, gue rasa sih itu kayak modulnya gitu ya maksudnya. Let's say modulnya transaction atau checkout ya udah kumpulin aja di situ file-nya.
Tapi kalau timnya nggak merasa nyaman dengan cara begitu ya, gue sih nggak merasa itu harus diikutin gitu maksudnya.
Intinya kita mengambil intinya ya, tujuan apa yang diterapkan oleh clean code itu kan adalah untuk membantu dinamisasi tim dan keharmonisan tim dalam membaca dan membangun dan maintain code itu.
Jadi itu sih tujuan utamanya. Jadi kalau misalnya ada sesuatu yang tim nggak nyaman dengan beberapa bagian, ya nggak perlu diadopsi, pakai lah.
Ada komen yang mungkin make sense nih Mas Irvan. Jadi clean architectur itu sumbernya dari DDD, Domain Development. Ini kadang-kadang nempelnya ke kultur atau manajemen si perusahaannya sendiri.
Perusahaannya itu mencah timnya based on domain atau nggak gitu. Misalnya front-end-nya sendiri yang ngerjain semua domain. Terus di pencah-pencah domainnya make sense nggak gitu ya.
Itu kayak, kayak nambahin burden aja gitu. Tapi kalau timnya pesanya based on domain, itu jadi make sense tuh. Biar gue nggak perlu lihat file-file lo karena gue nggak pernah ngurusin juga urusan lo gitu.
Jadi ya udah kita spread folder aja. Itu make sense menurut gue. Tapi kan jadi ngeliat situasi struktur timnya ya maksudnya. Jadi kayak clean architectur itu bagus ketika kondisinya memang terpenuhi gitu.
Tapi kalau kita menganggap itu adalah hal yang seharusnya kita implementasi di semua project kita, itu mungkin nggak ya kalau menurut gue ya.
Kalau saya masih di DDD. Bucket Development. Kalo ada bug baru dibenerin, baru dikerjain. Kalo nggak ya udah jangan aja.
Intinya sebenernya kalau mulai project ya jangan. Mulai dari yang simple aja sampai ketemu masalah baru mikirin. Ini kira-kira gimana nih folder-nya mau dipisahin atau nggak.
Jangan tiba-tiba pakai clean architectur baru sendiri 2 orang gitu ya. Setengah mati nanti. - Ribet sendiri.
- Ribet sendiri nanti. Jadi ya disesuaikan aja sama kultur timnya, sama ukuran timnya gitu. - Tapi ada satu yang perlu saya ini ya. Kalau sudah mulai projectnya sudah mulai lebih matang dan timnya sudah mulai terbentuk,
perlu dibuat standarisasi. Jadi supaya ada tim yang baru masuk bisa mengikuti standar, dan standar itu tetap didokumentasikan. - Padahal ini lagi support convention ya.
- Itu kan yang di support convention kan. - Betul. - Sederhananya ini sebenarnya kesepakatan yang disepakatin bersama-sama gitu.
Kalau semua tim sudah setakat, kita ngerjainnya begini. Ya udah secara tidak langsung, tetap didokumentasikan. Itu sebenarnya ya udah convention dari tim tersebut gitu.
Para kerjaannya begitu. Plusnya adalah tidak didokumentasikan aja biar nggak lari-larian lagi tuh. - Betul.
- Iya, saya barusan ngerjain CSS, saya bikin font saya sendiri, terus kena marah. Kan sudah ada CSS variable. Ya siap.
- Disinilah pentingnya code review ya. Karena kadang-kadang nggak aware kan. Oh udah ada ini ya fungsinya ya, saya nggak tahu.
- Kenapa didefine sendiri? Oh iya nggak ada ya? Terus bikin sendiri color-nya apa? Kan sudah ada mixinnya, kenapa nggak pakai? Oh iya sudah ada ya, tinggal pakai. Siap.
- Gitu ke depan bisa bikin bencana semua important-important-important karena saling mau meng-overwrite.
Itu ketahuan orang-orang lama tuh kalau banyak pakai important tuh. Aku masih pakai bahwa masih banyak.
- Yang udah pakai Tailwind masih suka kata override-overwrite.
Soalnya yang ngedesign nggak ngikutin aturan yang kita buat gitu loh. Jadi sukanya dia bikin dia melayang-layang kemana-mana ya udah.
- Tiba-tiba ada 6 pixel.
- Ngomongin designer.
- Belum lagi kira tiba-tiba ada, ini permintaan klien iklannya harus gini ukurannya, hai lo.
Pusing-pusing deh. Nggak bisa kalau nggak duit nggak masuk gimana. Mau nggak di gaji.
Itu nggak ada pilihan itu. Mau nggak mau ya walaupun iklannya pakai gift gitu ya. Harus diterima ya.
Oke. Wah seru sekali ya kita tidak, terasa sudah hampir 2 jam.
Biasanya sejam udah ya.
Ada yang nanya Astro. Astro nanti kita bikin topik sendiri lah ya.
Sudah hampir 2 jam. Jadi kita masuk ke penghujung acara. Terima kasih banyak ya buat Mas Ivan. Insight-nya luar biasa menarik ya.
- Ada pesan-pesan nggak dari Mas Ivan? - Pengalaman yang luar biasa.
- Atau selfa? Bebas? Apapun?
- Apa ya?
- Jangan lupa kalau ada topik bisa kirimkan ke sana.in. Ini salah satu produknya Mas Irvan.
- Ini yang baru ya. - Yang pakai teman-teman sendiri.
- Eh jangan salah loh kalau kalian buka website-nya Mas Irvan ke bagian About itu project open source-nya banyak sekali.
Jadi bisa dilihat kodenya. Luar biasa.
- Tiap yang belajar framework baru bikin project baru ya.
- Itu privilege kan? - Gak semua orang bisa bikin di situ kan?
- Bebas. - Betul.
- Itu topsters-nya kok. Stretch. - Iya ya.
- Stretch ini ya. - Ya malu lah. Masih cukup bikin chassis-nya.
- Nggak tapi yang main nggak.
- Kena flex kali. Karena di dua baris.
- Oh iya karena URL-nya. - Iya dua baris.
- Band-nya dua baris. - Panjang.
- Makan aku, maafkan.
- Santai. Jadi bisa langsung ke website-nya. Bisa dipelajari juga.
Website-nya juga sangat ini ya. Best practice ya. Ada CI-nya, ada speed-nya.
- Sudah mau hard cover face. Sudah mau hard cover face. Contribute aja tuh.
- Liatan tuh ada LCP-nya, ada CLS-nya tuh. Diitung semuanya ya. Mantap.
- Bebas sekali bikinnya ya. - Implementasi dari apa yang dipelajari itu.
- Guys. Oke. Saatnya implementasi ya untuk itu ya.
Bikin project-project sendiri. Bikin block-nya dipeperbagus gitu ya.
Oke kalau gitu. Ada lagi yang mau disampaikan sebelum kita...
- Apa ya? Itu kalau nggak punya kesempatan untuk nyobain framework yang lucu-lucu di kantor.
Itu bisa dikerjain di open source. Kalau bisa bikin satu project yang selesai.
Jadi jangan project yang makrak. Karena selain kita bisa pamer code, kita bisa pamer result-nya gitu.
Dan akan tidak backfire kalau ditaro di CV gitu. Karena kalau taro kerjaan yang separoh jadi itu...
- Mengerikan di CV. - Kok nggak selesai gitu. Wah ini ada yellow flag ya.
- Ada, ada, ada. - Ada nggak yang di CV-nya taro localhost 3000 gitu.
- Ya itu kan ini ya. Kamen ya buat kita ya. Kan kita bikin project belum selesai.
- Bikin lagi, bikin lagi. - Ditinggal, lupa.
- Maksudnya yang pedih-pedih kita jangan ditaro di CV lah. - Iya jangan taro CV.
Terus kalau di kerjaan sehari-hari jangan disamain kayak ngerjain di project gitu.
Kalau di project ya dirimu bisa rewrite satu application gede-gede.
Tapi kalau di kerjaan sehari-hari ya itu jadi pilihan terakhir lah.
- Pilihan ke 1000 sebelum dirimu cobain banyak... - Praktikal. Praktikal ajalah ya.
Kalau mau nyobain framework-framework baru.
Ada banyak tekniknya kayak tadi satu halaman atau satu komponen atau lain-lain.
Dan sampai dirimu bisa confidence untuk deliver ke page-page lainnya gitu.
Terus apalagi ya soal framework ya.
Ya kalau belajar sih jangan ini lah jangan ngasih gatekeeping gitu.
Maksudnya belajar apa aja gitu, belajar apa aja.
Jangan dengerin kata orang belajar harus ini dulu itu dulu belajar aja gitu.
Kalau dirimu ko susahan jangan malu untuk belajar hal-hal yang underlyingnya dibawahnya gitu.
Itu aja kayaknya. Thank you-thank you buat waktu nya.
Terima kasih banyak buat Mas Itpan.
Terima kasih.
Mudah-mudahan nanti kita bisa undang-undang lagi lain waktu.
Semoga kita bisa ketemu lagi nih.
Kita ketemu lagi di berbagai acara-acara offline.
Acara-acara offline.
Oke kalau gitu terima kasih juga buat teman-teman semua yang sudah hadir.
Ada Mas Budi tuh, bantuin jawab tuh.
Kayaknya kududung-dung lagi nih kapan gak panjang bahas clean architecture sama best practice ini.
Sama ini, sama Imre.
Kalau sama Imre harus rekaman gak bisa lah.
Harus rekaman iya.
Beda timezone, beda timezone.
Sama harus banyak dekat nanti.
Sama harus banyak dekat.
Oke deh kalau gitu.
Terima kasih buat semuanya yang sudah hadir, yang sudah menemani diskusi kita.
Seru banget malam hari ini.
Selamat malam, sampai jumpa minggu depan. Bye-bye.
Thank you, bye.
Deskripsi asli dari YouTube
Yuk mari kita diskusi dan ngobrol ngalor-ngidul tentang dunia web. Agar tetap up-to-date dengan teknologi web terkini. Topik, tautan dan pertanyaan menarik bisa dilayangkan ke https://bit.ly/ngobrolinweb Pembahasan: - 00:00 intro - 2:48 kenalan dengan mas irvan - 15:38 Alasan Angular dibenci - 20:25 Tips kerja dengan team - 32:45 Syarat untuk Rewrite - 35:32 Migration - 49:00 kelebihan nuxt js - 56:09 Kenapa dokumentasi menjadi penting - 59:02 kelebihan dan kekurangan svelte kit - 1:04:31 j Kunjungi https://ngobrol.in untuk catatan, tautan dan informasi topik lainnya.
Episode Terkait
2 Jan 2024
Yang Seru di 2024
Episode ini membahas tentang hal-hal seru yang dinantikan di dunia web development pada tahun 2024. Para host membahas p...
1 Mei 2024
🔥 UI Component Library: Pakai atau Gak?! Untung Rugi, Tips Memilih, & Pengalaman Developer!
Episode ini membahas secara mendalam tentang UI Component Library, mulai dari definisi, perbedaan dengan CSS framework d...
20 Agu 2024
Ngobrolin Astro
Episode ini membahas tentang Astro, sebuah meta framework JavaScript yang semakin populer di kalangan developer. Pembaha...
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 .