Ngobrolin Metode Rendering
Ringkasan Episode
Bantu KoreksiSalah satu permintaan topik paling awal akhirnya dibahas: kumpulan singkatan yang membingungkan seputar cara halaman web dirender. SSR dan SSG kebetulan sama-sama diawali dua huruf S, padahal maknanya berbeda sepenuhnya — dan pesannya adalah jangan terjebak menghafal singkatan, melainkan pahami urutan sejarahnya, karena definisinya sering tumpang tindih dan satu situs bisa memakai beberapa cara sekaligus. Ceritanya dimulai dari halaman web yang benar-benar berupa berkas statis: setiap dokumen diketik manual, dan menambah satu artikel berarti menyunting navigasi di semua halaman satu per satu. Dari kerepotan itu lahir server-side scripting — mula-mula Perl lewat CGI, lalu PHP yang merajai karena kemudahannya — di mana halaman dirakit di server dari basis data setiap kali diminta. Lalu perangkat pengguna makin kuat dan muncul gagasan menyerahkan perakitan itu ke browser; yang dikirim cukup datanya saja. Gmail disebut sebagai contoh awal yang membuat orang tertarik, dan jauh sebelum itu ada Java applet, ActiveX, dan Flash yang bahasanya justru masih satu turunan dengan JavaScript. Setiap ayunan menyelesaikan masalah lama dan memunculkan yang baru. Client-side rendering membuat halaman awal terkirim kosong dan pengunjung menunggu, sekaligus menyulitkan mesin pencari yang saat itu belum bisa menjalankan JavaScript — solusinya mula-mula pre-render khusus untuk bot, yang kemudian berkembang jadi static site generation. Tapi menghasilkan halaman statis pun tidak berskala untuk situs berita dengan jutaan artikel, sebab mengubah satu menu berarti membangun ulang semuanya.
Poin-poin Utama
- •SSR dan SSG kebetulan sama-sama berawalan dua huruf S padahal maknanya berbeda sepenuhnya — pahami urutan sejarahnya, jangan menghafal singkatannya
- •Halaman web mula-mula benar-benar berkas statis yang diketik manual, dan menambah satu artikel berarti menyunting navigasi di semua halaman satu per satu
- •Server-side scripting lahir dari kerepotan itu — dimulai dari Perl lewat CGI, lalu PHP merajai karena kemudahannya dibanding Perl yang kurvanya curam
- •Perpindahan ke sisi klien terjadi bukan terutama karena soal cepat-lambat, melainkan karena kebutuhan pembaruan real-time — dan Gmail disebut sebagai contoh awal yang membuat orang tertarik
- •Flash punya bahasa skripnya sendiri yang masih satu turunan dengan JavaScript modern, dan justru interaktivitasnya yang mendorong JavaScript naik dari sekadar pembantu validasi form
- •Static site generation berakar dari pre-render: dulu HTML khusus disiapkan untuk bot karena mesin pencari belum bisa menjalankan JavaScript, lalu disadari lebih baik dikirim ke pengunjung juga
- •Menghasilkan halaman statis tidak berskala untuk situs berita dengan jutaan artikel, sebab mengubah satu menu berarti membangun ulang seluruhnya
Udah nih mulai, gak ada yang mau mulai nih.
Halo, selamat malam, selamat hari selasa, selasa malam, waktunya ngobrolin web.
Ini sebagai pengingat ya mungkin ada teman-teman yang baru, kalo yang lama pasti udah tau.
Ini adalah acara apa ini, ngobrolin web itu? Ada yang bisa menjelaskan mungkin?
Wah, kita sudah ngobrol santai tentang teknologi web.
Udah 19 episode, ngobrolin web, gak habis-habis karena ternyata skop cakupan teknologi web itu besar sekali ya.
Betul, betul.
Yang mana-mana gitu kan.
Gak habis-habis.
Gak habis-habis dan masih banyak juga bahasan-bahasan yang belum kita keluarkan dan banyak juga topik-topik yang sudah diberikan oleh teman-teman di rumah dan belum kita, belum sempat kita bahas.
Jadi tenang aja, kita masih banyak-banyak persengetaan di rumah untuk kita bahas satu persatu.
Tapi juga kalo misalkan teman-teman kepikiran ada ide menarik topik apa, bisa langsung ke bit.ly/ngobrolinweb.
Bisa juga kalo mau liat topik-topik sebelumnya, liat aja video-video kita yang sebelumnya.
Itu kita bahasnya sudah banyak sekali mulai dari apa tuh, fonts, CSS, iron architecture, image, event loop, service worker.
Bisa komen juga di videonya atau di yang tadi bit.ly/ngobrolinweb.
Seperti biasa, masih ditemani oleh kita bertiga, ada Eka, ada Ivan, dan ada saya Riza. Dan malam hari ini, sayangnya malam hari ini kita gak live.
Jadi kita rekam karena Eka gak bisa hari Selasa.
Karena satu dan lain kali.
Tapi kita commit, kita harus tetap rilis, tetap rilis walaupun gak live.
Walaupun gak live, kita akan rilis episode ini di Selasa Malam juga jam 8 waktu Indonesia Barat.
Jadi kita pantenin juga nanti komen-komennya pasti kita akan baca.
Jadi teman-teman bisa komen dan mudah-mudahan kita bisa diskusikan pada saat nanti live di beberapa episode ke depan.
Oke, kita langsung aja mulai malam hari ini kita akan membahas apa nih?
Ini salah satu request juga yang paling awal dari episode-episode awal nih di Slido-nya tuh udah ada request topik ini.
Cuma karena skopnya agak luas ya, macem-macem kita rangkum jadi satu istilah yaitu rendering method.
Atau methodnya rendering, ditermain doang gitu.
Rendering itu apa ya?
Apa render?
Cara untuk menampilkan di layar.
Gak harus di layar ya, rendering tuh bisa server-side juga kan, nah itu nanti kita lihat.
Lihat transkrip lengkap (1548 segmen lagi)
Oke, nah sebenarnya yang bisa disitu.
Ada nih artinya proses menghasilkan citra dari sebuah model.
Citra kan image kan?
Render itu bahasa dari itu kali, artisistektur, artisistektur.
Jadi kalau misalnya sudah dibikin desainnya, terus dirender, jadi tentu rumahnya gitu loh.
Jadi kayaknya dianggil dari istilah itu.
Iya, kalau awalnya walaupun tidak terlalu teknis, menampilkan isi halaman web.
Sebenarnya topik yang disajakan sama salah satu penonton, sama teman-teman
adalah sebenarnya dia mempertanyakan, menanyakan tentang client side rendering,
server side rendering, hydration dan lain-lain, static side rendering.
Mungkin teman-teman juga sering bingung karena singkatan itu banyak banget ya, ada SSR, SSG, CSR.
CSR banyak ya.
Dan dulu banget nih salah satu hal yang paling nyebelin, dulu pas pertama kali belajar webdev,
itu kan yang ngetrend lagi SSR versus SSG.
Nah, asumsi kan sama-sama depannya SS tuh, kirain sama singkatannya.
Tahunya SSR dan SSG itu singkatan SS-nya mengacu ke hal yang sepenuhnya berbeda, itu nyebelin banget sih.
Ada satu lagi SSG itu apa?
Sambel SS.
Special sambel ya.
Ada juga loh di luar kota.
Nah, SSG itu apa sih static side generation.
Sementara SSR itu server side rendering yang ada hubungannya.
Kebetulan aja depannya sama-sama SS.
Nah, jangan sampai terjebak cuma ngapalin atau stuck di singkatan-singkatan itu.
Cuma kita sekarang nih pengen lihat dari awal sejarahnya rendering di web itu gimana sih
sampai bisa jadi ada banyak banget gitu yang kadang definisinya dan bahkan penggunaannya overlap ya.
Bertumpuk-tumpuknya bisa berubah-ubah, bisa pakai beberapa cara sekaligus.
Mulainya dari mana nih sekarang?
Oke, kita bahas tentang perjalanan web dulu aja kali ya.
Jadi kan di awal itu seperti yang teman-teman tahu atau mungkin ada yang belum tahu.
HTML, CSS, dan JavaScript pada dasarnya di awalnya itu adalah dokumen statis gitu ya.
Isinya HTML, ada outarnya atau link atau anchor gitu kan, diklik ke dokumen kedua.
Dokumen kedua dilink ke dokumen ketiga dan seterusnya.
Itu static semuanya, nggak ada sesuatu yang berubah.
Misalkan artikel dan lain-lain itu ditulis manual semuanya, diketik ya.
Artikel satu, artikel dua, artikel tiga, dan seterusnya.
Terus kemudian berkembang, aplikasi web berkembang.
Belum aplikasi web, dulu sebutannya kan web page atau website.
Halaman web, jadi dokumen ya.
Jadi titik beratnya pada dokumen yang saling terhubung satu sama lain ya.
Nah itu yang tadi dia bilang, link, ngeklik satu link bisa pindah ke dokumen lain atau halaman lain.
Jadi dulu 30 tahun lalu ternyata belum ada teknologi yang seperti itu yang terbuka buat masyarakat luas.
Cuma dulu jaringan aja, misalnya jaringan di kampus atau institusi.
Cuma belum ada jaringan seperti itu untuk masyarakat luas.
Jadi presentasinya dokumen, terus image.
Kalau pun ngeklik image, image-nya dulu belum ada di dalam halaman ya.
Kayak cuma buka file, jadi file dokumen atau file image.
- Jadi bisa dibilang. - Sudah ada itu juga kan, standarisasi yang mereka buat itu kan makanya disebut markup language-nya itu kan ya.
Jadi dari kodenya itu disebut markup ya.
Markup itu makanya HTML, hypertext markup language.
Temannya yang lain ya, ada juga XML, ada juga apa lagi itu, yang lain lah.
Dan markup language lainnya ya.
Banyak. Kebetulan yang terkenal itu yang HTML, yang hypertext-nya itu.
Ya, ditandai dengan ada tag pembuka dan tag penutup biasanya ya.
Walaupun ada beberapa yang safe closing kan, kayak image, misalkan nggak perlu ditutup.
Jadi kombinasinya lah. Nah, dari sana ternyata dokumen-dokumen ini dikumpulin udah cukup banyak.
File text-nya lama-lama numpuk banyak dan sulit di-manage.
Kalau misalnya kita satu website ada 20 halaman, misalnya ada yang diganti sedikit,
bayangin footernya misalnya 20 harus diubah semua satu bersatu.
Jadi, bisa dibilang awalnya sejarahnya kan dulu sepenuhnya static file status biasa.
Nah, ini bentuknya kayak gini nih, kayak gini doang nih. Halaman web pertama.
Oh, ini halaman web pertama nih. Sampai sekarang masih bisa dibuka kerennya.
Masih bisa dibuka dan berfungsi.
Iya, kita bisa lihat isinya benar-benar statis dan masih menggunakan ini, apa?
Rupesar semua kayak orang marah-marah.
Itu HTML3 ya, terakhir pakai Ruf Kapital kalau nggak salah.
Iya, ini, apa namanya? Bisa diklik menuju ke halaman sebelumnya.
Halaman ini, halaman berikutnya atau dokumen-dokumen yang kita mau.
Tapi kita nggak bisa nggak ada itu, nggak ada navigasinya.
Mau balik gimana? Kita pakai back button.
Iya, ini masih sederhana sekali gitu kan.
Kalau misalkan nanti katakanlah kita mau update nih, mau tambahin "About Us" misalkan.
Ya, kita harus ketik manual di Text Editor gitu.
Ya, itu adalah pertama kali HTML dan mungkin CSS setelah ini ya.
Jadi untuk stylingnya itu diciptakan dan orang bisa langsung mengakses secara statik seperti ini.
Jadi nama file dan nama extensionnya yaitu HTML.
Iya, sama kayak file image yang misalnya kita punya sekarang di file system atau file blablabla.txt, blablabla.html.
Ya, beneran yang disimpan di server adalah file statisnya.
Karena lama-lama pusing akhirnya dibuat teknologi server side ya.
Biasanya kan diindeks dulu kan, wah, si ini punya artikel ini, si itu punya artikel itu.
Nah, muncul layanan-layanan seperti kalau dulu Yahoo itu dia indexing si halaman web yang tersedia public secara publik gitu kan.
Nah, orang capek tuh lama-lama liat index itu kan kayak liat buku telepon kan. Harus kita cari A sampai Z gitu kan.
- Yellow Pages lah. - Iya, Yellow Pages.
Kayak kita LS di Unix ya. Maksudnya dulu masih, mindsetnya tuh masih kayak file system banget ya.
- Karena sejarahnya emang statis. - Iya, jadi betul.
Iya, setelah itu baru muncul mesin pencari.
Jadi orang nggak perlu cari dari A sampai Z indexing kayak gitu, jadi mesin pencari.
Nah, setelah itu baru berkembang lagi kebutuhan apa?
Kebutuhan dokumen atau aplikasi web, bukan aplikasi, masih halaman web ini itu butuh lebih dinamis.
Iya, butuh, misalkan saya punya dua artikel awalnya.
Terus saya menulis artikel ketiga, masa saya harus menulis manual, tambahin di navigasi, tambahin di halaman yang ini.
- Header footer, layout. - Iya, header footer dan lain-lain gitu kan, capek akhirnya.
Kita minta tolong komputer buat rendering on the fly.
Tapi Duh, cuma bisa di server site ya?
Server site, jadi di server dia akan mengenerate, setiap ada permintaan, saya minta halaman index dong, index.html.
Dia akan mengambil halaman index, terus dia akan mengenerate hal-hal yang dinamis.
Misalkan artikelnya yang dua, yang tadinya dua, kita akses besoknya menjadi tiga, dan seterusnya dan seterusnya.
- Pak, pakai semacam parsial ya namanya Duh. - Betul.
Namanya server site scripting. Yang paling pertama itu dulu server site scripting itu pakainya Perl.
Perl, TGI, common gateway interface.
- Tidak nyamanin. - Tidak ngalamin juga sih, cuma tahu aja.
- Perl, TGI programming. - Perl, Perl.
- Masih ada tutorialnya Duh. - Masih, Perl itu masih ada.
- Iya, masih sampai sedang nih, masih banyak. - Iya.
Biasanya juga server site rendering ini itu di kombinasikan dengan database.
Jadi kontennya atau isinya, artikelnya itu disimpan ke database,
dan kemudian setiap ada request ke sebuah halaman, maka dia akan query ke database, dia ambil artikelnya.
- Lakukan query. - Iya, digabungin.
Halamannya dibuat dalam tanah kutip di render, baru dikirimkan ke klien.
- Jadi isi text, HTML text yang tadi kita lihat itu dibikin programatically on the fly oleh si server itu.
Ada for loopnya, ada macam-macam, ada kondisi kalau ini dia warnanya merah,
kalau itu warnanya hijau, dan lain-lain. Termasuk juga sudah mulai muncul JavaScript,
- walaupun penggunaannya hanya untuk hal-hal sederhana. - Masih baru client site ya, legend.
Iya, nampilin informasi, alert, form validation, dan lain-lain, baru sampai di situ.
Karena dulu juga masih belum standard juga kan JavaScript, masih browser JavaScript di Netscape.
Belum tentu sama dengan JavaScript di Internet Explorer.
- Pada pernah bahas tentang browser juga. - Browser.
Belum pernah di episode berapa, tahu deh.
Nah, di fase ini, salah satu yang populer, walaupun masih populer juga sampai sekarang adalah PHP.
Ada yang tahu kepanjangan PHP? Personal Homepage.
- Awalnya si Personal Homepage. - Awalnya. Awalnya PHP itu adalah scripting ya.
- Bahasa scripting ya. - Sekarang pre-hypertext processor.
Oh, benar-benar. Rada maksa sih, cuma ya udahlah.
Ini kalau di website ofisialnya, bahkan P yang di depan sudah dihilangin.
Cuma php.2 hypertext pre-processor.
- Pre-processor. - Tinggal HP.
Itu kan kalau yang open source open source itu kan banyak yang, apa ya istilahnya ya?
Rekursi ya, bukan ya?
Jadi kayak KDE, ke desktop environment. Knya ya tetap K aja, nggak ada apa-apa gitu.
Ya, intinya adalah...
- Udahlah ya udahlah, ya gitu aja. - Ya.
Selain P, yang mungkin kurang populer karena memang agak, secara developer experience,
kurang ini ya, agak susah ya kita develop di sana.
- Di sana. - Dan maksanya juga rumit ya.
Paul itu dibuat oleh, saya lupa namanya yang buat, namun learning curve-nya tinggi.
- Learning curve-nya tinggi. - Akhirnya.
- Akhirnya. - Unit gaining traction.
Sama siapa ya, si om siapa yang bikin php, kok gue lupa sih.
Lalu tiba-tiba ngeblank, oh, om Rasmus Lidov.
- Oh iya, Rasmus. - Nah, itu yang bikin.
Nah, om Rasmus. Masih aktif lho sampe sekarang.
Ya, ya, ya. Nah, kalau temen-temen penasaran, Perl itu kayak gimana ya?
Kalau mau icip-icip, tau regex nggak? Nah, itu salah satunya.
Asil dari Perl. Perl itu memang sangat powerful digunakan untuk string atau text manipulation.
Jadi memang, apa namanya, spesialisasinya di sana.
Jadi untuk yang bisa ngecode Perl itu, dia sangat low level, ya. Dia low level, bukan sangat, dia low level.
Jadi semuanya harus sebagaia step-nya banyak untuk melakukan sebuah fungsi.
Makanya muncul lah yang lebih high level, contohnya, php yang menyerupai cara coding-nya si C++.
Ya, sudah satu family ya. Pakai kurung-kurawal, kurung bulat, function, kurung bulat, ada parameter dan lain-lain kan.
Nah, php ini berjalan di atas web server, ya kan.
Kalau dulu terkenalnya Apache, kalau sekarang nginx sudah bisa.
Sekarang kerennya standard ya di Indonesia tuh banyak Apache.
Jadi, php itu bukan programming language, scripting language, scripting language.
Jadi, interpretor, dia itu interpretor.
Jadi instruksi yang kita tulis dengan php, harus ditransform dulu layer selanjutnya, makanya ada namanya php handler.
Modul ya? Bukan? Apa macam modul?
Ada yang merubah dari scripting-nya si php, interpretor-nya php, ke bahasa mesin.
Jadi, apa isilahnya itu?
Kayak perentara yang lebih low level-nya apa?
Interpreter.
Ya, intinya si php tidak bisa dijelankan, maksudnya tidak bisa menjadi web server sendiri.
Harus butuh antara Apache atau nginx yang ada modul php-nya.
Jadi, dia bisa mengerti scripting php-nya, kira-kira seperti itu.
Jadi, php tidak bisa berdiri sendiri, harus dibungkus sama executable-nya.
Tapi sekarang sudah bisa kan?
Enggak juga.
Kalau dulu kan pakai SAM, UAM, PAM.
Ya, php ada php CLI-nya, tetapi kan membutuh executable-nya untuk menjalankan si php.
Oh, itu untuk development-nya saja.
Kita install php juga, berarti ya, di mesin kita.
Sekarang dengan C++, Go, atau segala macam, sekali dikomplain, sudah jadi executable, mau dipindahin ke selama asitor.
Selama asitornya sama, bisa dijalankan.
Itu bedanya ya.
Ya, makanya dulu, mungkin sekarang sudah tidak ya, makanya dulu kalau kita mau pakai php,
kita harus punya web server-nya, harus install apache, harus install nginx.
Walaupun dibanding akhirnya kan ada SAM, ada MAM.
XIMPP, MAMMP ya.
Itu kan php dengan metal ya, dengan besi lah, dengan mesin.
Nah, terus sementara php dengan user, dengan browser,
ini kan berarti pelan-pelan mulai ada templating language ya, yang kayak semacam.
View templating language kayak handlebar dan teman-temannya.
Itu siapa yang paling duluan ya?
Handlebar dulu itu, kalau di php itu yang masih ingat, Smarty dulu ada namanya, smart templating language.
Itu cukup terkenal.
Ada yang sebelum Smarty.
Sebelum ya, ada yang sebelum ini.
Smarty itu kan belum pernah dengar, Smarty.
Smarty templating language.
Nah, biasanya si php juga itu dikombinasikan pasangan yang paling ini adalah database-nya MySQL.
MySQL, MySQL.
Sebutannya LAMP dulu ya.
LAMP, apache, MySQL, php.
Karena XIMPP itu dan lain-lain udah ada MySQL juga.
Jadi, sekali install udah ada apache, ada php, ada MySQL.
Jadi, orang ya sudah no-brainer gitu, nggak perlu install macem-macem gitu kan.
Itu awalnya si server site rendering atau dynamic web gitu muncul.
Jadi, kita lihat petoknya dari HTML document aja.
Dari full static file, terus jadi server site rendering.
Tapi dulu istilahnya belum begitu ya, belum pakai SSR.
Belum, belum, belum.
Belum disebut SSR.
Web aja, web server, sama ya, aksekusinya di client.
Ya, dynamic.
Dan itu disebutnya server site rendering.
Sekarang kan sebutannya server site rendering itu sekarang kan?
Betul. HTML-nya, jadi koneksi ke database, segala macem itu oleh server site scripting.
Mau itu poll, mau itu php, mau itu ruby, mau itu apapun itu.
Jadi, HTML-nya sudah diselesaikan, baru dikirimkan ke browser.
Terus penuhnya dikirim ke browser, jadi browser user nggak tahu,
sebetulnya nggak tahu apakah itu dikirim dari file static, file HTML status kayak di awal itu,
atau di generate oleh suatu teknologi server site scripting.
Kan sama aja, apalagi udah jadi text aja pas dikirim ke browser.
Lalu diterjemahkan jadi di render jadi download oleh si browser ya.
Ya, selain php, di masa ini yang cukup terkenal apa ya?
Apa ya? Php sih yang paling ini ya.
Ruby, Ruby on Rails itu masuk juga ke server, web server, server site rendering Ruby on Rails,
framework-nya on Rails.
Terus ada Python, Django, ada apa lagi ya?
- Java juga ada. - Visual Basic juga.
- Visual. - VB6.
- VB6. - No, no, no.
- Itu bisa buat ngerender web. - Ada web juga?
- Oh, baru tahu. - Oh, oke.
- Tapi pakai IES. - Oh, IES.
Oh iya, itu web server-nya di Windows ya?
- Iya. - Sebagai pengganti alternatif dari Apache.
- Java harus pakai Tomcat. - Java harus pakai Tomcat.
Benar, benar, benar.
Dan ada banyak yang lain ya, tentunya banyak ya.
Bahkan Perl juga masih ada sampai sekarang.
Jadi yang cukup terkenal itu php yang paling merajai, terutama karena kemudahannya.
Kemudian ada terus muncul setelah php itu, muncul Ruby on Rails, muncul Python, Django,
dan sejenis lainnya yang sederhananya cara kerjanya request dan response.
Jadi si klien yang melakukan request melalui web browser, kemudian di-respond oleh server
dengan query database, base-nya dinamis, di-render di server, dikirimin file HTML-nya ke klien kembali.
Itu cara kerja sederhananya.
Keliatannya sih kalau dilihat makin high level kayak yang Django, Ruby on Rails, Laravel,
itu kayaknya setara dengan atau pola yang sama dengan meta framework-nya jaman sekarang ya, kayak Next.js atau SvelteKit.
Jadi kan sebetulnya Django itu pakai Python, Laravel itu pakai php,
cuma dikasih berbagai kemudahan, kayak misalnya routing udah ada polanya lah, tinggal isi routing.
Terus kayak pola-pola kontrolernya gimana, sampai ke view-nya gimana, kayak memudahkan aja.
Trendnya sebenarnya berputar, nanti kita omongin lagi kan, jadi ini dari statik, dinamis server,
kemudian orang mulai merasa lambat ya.
Terus ribet kali ya infrastrukturnya, kan, mesti pasang Amat J dan lain-lain.
Tapi ya, sudah mulai merasa ada kebutuhan untuk real-time.
Terutama bukan masalah cepat atau lambatnya ya.
Kalau server mungkin bisa di-optimized dan lain-lain.
Tapi kebutuhan real-time-nya ini yang membuat orang akhirnya berfikir,
"Oh, kenapa nggak di-rendernya di sisi-sisi klien?"
Kalau sebelumnya kan di-rendernya semuanya, HTML-nya dikirimin semuanya.
HTML, CSS, JavaScript yang di-compilasi atau di-generate di sisi server, hasil akhirnya dikirimkan ke klien.
Nah, terus ada yang mikir, "Ya udah, karena si klien ini sudah cukup powerful."
- Browser makin canggih. - Browser makin canggih.
- Suruh browser aja yang urus. - Iya.
- Itu siapa ya yang pertama kali punya ide kayak gitu? - Gak tahu.
Untuk ukuran dulu kan itu kayak ide yang banget kan, yang breakthrough-nya.
Iya, dulu-dulu tuh nggak tahu ya siapa yang memulai.
Tapi dulu sempat awal-awal itu, kalau nggak salah,
salah satu yang cukup populer jadi bahan omongan adalah Gmail.
Kalau sebelum Gmail kan orang nge-check email itu kan refresh kan, F5 gitu kan.
Ada email baru? Dulu. Ada email baru nggak ya, gitu kan.
Harus request dulu ke server kan.
Begitu Gmail itu mereka kalau nggak salah pakai Java, ada framework internal-nya si Google.
Ada tuh JWIT.
- Bukan JWIT, bukan. - Bukan, bukan.
- Java apa gitu ya pokoknya. - Jacket.
- Semacam applet ya berarti. - Iya, kurang lebih kayak gitu.
Nah, dari situ ya berkembang lagi.
Wah, ini apa, jadi yang dikirimkan bukan halaman web lagi,
melainkan data. Data-nya dalam bentuk XML atau JSON.
Jadi yang dikirimkan datanya aja.
"Saya minta data email dong."
Ya udah, dikirimin JSON-nya, dirender di sisi klien.
Ketika data-nya udah didapat, ada subject, ada title, ada body.
Nah, akhirnya si browser lah yang mendapatkan tanggung jawab.
Java Script Engine di dalam browser yang mengolah itu,
meng-convert jadi string, jadi HTML kan sebetulnya.
Jadi HTML yang bisa dibaca oleh kita, gitu.
Aku baru ingat namanya GWT, Google Web Toolkit.
Google Web Toolkit masih ada sih sampai sekarang.
Google Web Toolkit.
- Toolkit, oh. - Iya, itu cikal bakalnya.
Tapi nggak tahu ya, itu beneran dia yang awal, tapi itu yang cukup terkenal
pada saat itu yang membuat orang-orang, "Wah, kayaknya menarik nih."
"Bisa kita explore nih, client-side rather than nine."
Tapi sebelumnya Java tuh punya applet, Mas.
Oh iya, applet. Bahkan sebelum itu Flash.
Iya, applet, terus si EA itu punya sendiri tuh yang ActiveX.
- Silverlight. - Sebelum Silverlight.
ActiveX, jadi ActiveX masih ada tuh.
Jadi bisa diinstall ActiveX-nya, itu yang selingkuh kena hack.
Kena vulnerability, kena virus, ya.
Jadi bisa install ActiveX dan membuat si web-nya itu menjadi lebih dinamis di lokal client.
Lebih interaktif.
Betul.
Ya, habis itu ada juga makromedia yang sekarang diambil Adobe kan.
Makromedia Flash kan.
Lebih interaktif lagi tetapi di browser.
Iya, di browser kita bisa bikin game, tapi sebelum itu harus loading dulu kan.
Dulu semua halaman web itu Flash moa gitu kan. Ada loading-nya.
Ada loading-nya, loading screen dan lain-lain gitu.
Dia download dulu si apa, si SWF-nya ini kan, engine untuk rendering-nya.
Tapi dia isolated ya, dia nggak bisa berinteraksi sama dom note di browser kan.
Cuma kayak di sandbox ke tempatnya dia sendiri.
Nah, tapi yang menariknya di Flash ini, dia punya bahasa scripting sendiri namanya ActiveScript.
Yang menjadi jika bakal JavaScript, ECMAScript versi 3 kalau nggak salah, yang modern sekarang itu salah satunya.
Sintas-sintasnya mirip sekali.
Terinspirasi.
Masih satu turunan.
Nah, dari interaktifitas itu akhirnya JavaScript baru mulai naik.
Kalau sebelumnya JavaScript itu kayak pembantu aja.
Iya, hanya sebagai pembantu aja dia cuma buat validasi form.
Oh, email-nya formatnya salah. Oh, ini bukan number dan lain-lain gitu kan.
Atau she'll learn to welcome to my website.
Alher, apa, play.
Dulu kan nggak ada format apa namanya audio, jadi pakainya MIDI.
Cuma instrumen doang gitu kan.
Lama-kelamaan akhirnya si JavaScript nih naik nih.
Mungkin dia melihat, wah si Flash ini lumayan seru ya bisa bikin interaktif.
Gimana kalau JavaScript kita bikin interaktif?
Akhirnya jadilah JavaScript seperti sekarang.
Itu yang bisa buat bikin request dulu masih XAR ya.
Request, ngerender sesuai hasil request, dan lain-lain.
Betul. Karena ya itu tadi si browser juga udah lumayan kuat kan, udah powerful.
Si device-device-nya juga udah lumayan powerful gitu kan.
Udah mampu melakukan rendering di jasi client.
Jadi akhirnya jadilah ini yang disebut sebagai client-side rendering.
Cuma kan sebetulnya di awal, terutama di awal,
CSR itu kan nggak mutually exclusive sama teknologi yang sebelumnya kita bahas kan.
Ke server-side yang pakai PHP, atau Rails, atau Django, atau apalah.
Dan lain-lain WordPress, apapun itu kan.
Sebetulnya di awal kebanyakan masih dirender dari server-side.
Tapi buat interaktifitas selanjutnya baru pakai yang client-side kan.
Masih banyak pola yang kayak gitu kan.
Jadi halamannya tetap dirender oleh misalnya Laravel, cuma buat run-end-nya pakai jQuery biasanya.
Jadi sebetulnya itu udah mulai kombinasi bukan nurni client-side rendering status juga bukan.
Ketika di fase ini, yang terkenal itu pasti jQuery kan.
Apalagi ya ada Dojo kalau nggak salah, ada XTJS, yang lain-lain, ada banyak lah ya.
Yang paling terkenal jQuery.
Nah setelah itu orang berpikir, ini di client udah makin kompleks kan.
Semua dihandle di sisi client.
Terus akhirnya mulailah muncul framework-framework yang mengadaptasi cara web bekerja di sisi server.
Dalam artian arsitekturnya pakai model view controller.
Muncul Backbone, ada Knockout.js, ada Batman, ada banyak ya macem-macem ya.
Batman framework, belum pernah denger.
Terus templatingnya pakai underscore.
Templatingnya ada handlebar, must test.
Terus di fase ini juga kalau teman-teman mungkin...
Ada Batman.js kofi script.
Di zaman ini ada satu framework yang akan menjadi cikal bakal framework kekinian.
Namanya Raktiv, R-A-C-K-T-I-V.
Itu yang buat adalah reseries.
Yang akhirnya menjadi Svelte sekarang.
Itu dia buat di waktu dia bekerja sebelum di New York Times.
Jadi dia bekerja di media juga, media online juga.
Nah dia bikin Raktiv.
Dia bekerja di New York Times, akhirnya dia bikin Svelte.
Itu awal ceritanya di situ.
Dulu dia di Guardian.
Jadi ini framework-framework ini udah mulai merasa butuh karena semuanya di handle oleh klien.
Akhirnya muncullah state management.
Waktu itu belum teroternal ya state management ya.
Kalau yang pakai Backbone, Knockout.js itu belum ada ya.
Ada tapi udah di include sama sih framework ini.
Dan nggak terlalu rumit kan karena orientasinya dulu awalnya masih banyak server side.
Expectasinya state-nya itu di handle di server lah.
Betul.
Jadi ini belum jamannya ada state management dan lain-lain.
Dan belum jamannya tadi ngomong apa ya? Jadi lupa.
Oh ini virtual DOM belum ada tuh.
Jadi semua manipulasi DOM langsung aja.
Seperti halnya si jQuery kan.
Beberapa framework juga seperti Backbone itu basenya jQuery.
Cuman sudah, arsitekturnya sudah menggunakan model view controller.
Model disini ya mungkin dia ambil API.
Terus abis itu kita bisa query, terus di handle sama controller view-nya ya buat nampilin.
Ya kira-kira kayak gitulah.
Dan biasanya jadi reactive. Reactive itu artinya.
Kalau misalnya ada data yang berubah, tadinya kalau pakai jQuery ya.
Kita harus, kalau ada data yang berubah, kita harus nge-domatin.
Re-render lagi semuanya?
Dua hal. Dua tempat yang berbeda.
Oh iya.
Sedangkan ya kalau dia reactive.
Kirim event gimana tuh caranya?
Ya dia observe. Observe kalau datanya berubah.
Kayak Backbone itu model view controller.
Kalau model data di modelnya berubah,
komponen yang lain yang dari view-nya itu re-render ulang, otomatis.
Ya.
Ya itu MVC di JavaScript.
Ya itu beberapa framework yang jadul gitu ya.
Yang tadi Backbone, OSJS, ada reactive, ada macem-macem gitu kan.
Setelah itu mulai berkembang lagi.
Mulai berkembang lagi muncul yang pertama kali framework modern,
yang masih aktif sampai sekarang adalah Angular.
Itu main bloom juga tuh.
Angular JS-nya masih.
Iya versi 1.
Itu main bloom kenapa? Karena dia two-way data binding.
Kalau dulu kita kan manual ya.
One way.
Jadi si Angular ini two-way data binding.
Jadi ketika kita ketik, wah langsung berubah.
Wah keren banget gitu.
Sekarang mah udah biasa aja.
Kalau dulu kayaknya, wah ini ini.
Kalau dulu itu kalau kita ketik sesuatu di tempat sini,
di tempat sini berubah secara otomatis,
kayaknya dengan kayak kita...
Kau pakai variable biasa gitu ya.
Iya, code-nya simple.
Tetapi beberapa tempat bisa berubah.
Itu keren gitu.
Karena kalau nggak, kita harus handle masing-masing.
Masing-masing, betul.
Satu per satu.
Jadi ya itu lumayan menjadi milestone juga ya
buat perkembangan web.
Itu adalah Angular 1.
Dan Angular 1 juga salah satu framework
yang pertama kali mempopulerkan testing di sisi klien.
Dia menggunakan Jasmine.
Sebelum-sebelumnya testing di klien itu susah banget.
Susah banget.
Kayak hampir nggak ada gitu.
Manual, manual testing.
Iya, acceptance test.
Orang yang ngetest gitu kan.
Begitu ada Jasmine, dia bisa bikin auto-metet test dan lain-lain.
Akhirnya diadaptasi sampai sekarang,
testing itu udah enak banget.
Itu salah satu handle-nya Angular juga.
Berarti itu milestone juga ya.
Bahwa di apapun yang terjadi di client-site,
di browser, itu kayak ada logiknya,
ada input-nya gimana, output-nya gimana.
Itu kan berarti kita web developer sadar
bahwa udah geser ke, nggak geser sih, udah nyebar ke...
Selain di server, ya server tetap perlu ditest.
Di klien juga perlu ditest juga.
Betul, betul.
Dan Jasmine juga masih ada sampai sekarang
dan diadaptasi oleh Jess.
Jess itu biasanya adalah Jasmine.
Terus dari Angular ini baru muncul
itu yang framework-framework yang sekarang,
seperti React, ada...
View.
View, ada...
Nah, View juga...
Ya, View juga sebenarnya sederahnya menarik juga
karena kabarnya si Ivan Yu itu
dulu dia intern di Google, masuk ke timnya Angular.
Makanya kan Angular 1 sama View awal kan mirip-mirip ya.
Begitu mereka announce bahwa Angular yang kedua
bakal diganti total, berubah total,
kemudiannya ganti Ivan Yu-nya dan di sana
akhirnya dia bikin View, gitu.
Kalau React itu muncul karena kebutuhan si Facebook
sebagai sosial media.
Jadi datanya dinamis, gitu kan.
Kalau tadi kan kita pathway data binding
mungkin butuhnya lebih dari di Google ya.
Facebook awalnya itu server-side rendering loh.
Iya.
Kan PHP, bahkan sampai tahun 2000,
berapa lah, 2010-an pokoknya,
masih server-side,
masih alamatnya bahkan profile.php,
cuma di depannya diperkaya oleh React.
Ya, bahkan sekarang mereka udah bikin engine PHP sendiri kan.
Sempat waktu itu kan PHP 5.6 stak ceritanya.
PHP 5.6 agak stak.
Nggak ada tuh 5.7 kayak masih kayak pada berantem gitu,
terus akhirnya pada bikin PHP 6.
Kayaknya selalu pada berantem dulu ya,
aja plus script buat PHP.
PHP 6.
Tadi PHP 6-nya kayak masih kayak nggak ada persetujuan gitu,
kayak nggak kompak.
Akhirnya si Facebook bikin sendiri kan
PHP engine-nya dia rewrite.
Nggak, dia rewrite sih.
Dia modifikasi.
Gua lupa namanya apa.
PHP engine-nya dia.
Bukan.
Highlight.
Bukan, bukan.
PHP engine-nya si Facebook itu namanya...
Kok gua lupa.
Itu dulu agak melenceng,
tapi pertama kali si Facebook punya itu
yang pakai namanya Just In Time.
HHVM.
Oh ya, HHVM.
Jadi dia pakai tekniknya Hip Hop Virtual Machine.
Jadi pakai Just In Time.
Ya ampun namanya Hip Hop Virtual Machine.
Tapi itu jadi cepet banget memang.
Fast forward, PHP 7 keluar,
maka semua tidak ada.
Karena sudah kompak lagi semua.
Udah dimasukin.
Udah diintegrate.
Polanya mirip kayak ECMAScript ya jadinya.
Sejarah ECMAScript yang dulu pernah kita bahas di episode berapa tuh.
Jadi, ya itu si React ini muncul karena kebutuhan social media
yang datanya dinamis sekali kan.
Dinamis.
Ada chat baru, ada like baru.
Ada like baru.
Ada feed baru dan lain-lain gitu kan.
Makanya si React ini muncul
dan dia mau, kan dia mau mengetamakan developer experience kan.
Kalau misalkan yang sebelumnya menggunakan 2D data binding,
ternyata itu bagus, menarik secara developer experience,
tapi kabarnya secara performa kurang.
Karena dia harus, apa istilahnya tuh, ngecekin ini lagi kan.
Tiap kali ada perubahan dia cek semua halaman dan itu berat gitu kan.
Nah, tapi React juga nggak mau dia kalau misalkan,
kalau dulu kita misalkan kayak server-site rendering,
pokoknya dia berusaha untuk membuat developer experience-nya seperti server-site rendering,
tapi ini di client-site.
Artinya apa?
Artinya misalkan kalau dulu kita mau cek email, ada email baru kan kita F5 ya.
Refresh gitu kan.
Nah, React pengen experience seperti itu.
Jadi setiap ada hal yang baru, kita nggak perlu ngapain, tiba-tiba ada muncul itu.
Makanya dia bikin virtual DOM.
Jadi ketika ada sesuatu yang baru, sebenarnya itu dia ngerefresh semuanya,
ngerender ulang semuanya, tapi yang hanya perubahannya aja.
Itu yang bantu.
- Dia punya gambar DOM yang real, yang nyata,
terus dipindahin dulu ke tempatnya React sendiri,
di dunia virtualnya dia,
terus dicek satu persatu mana yang berubah,
sampai dapet gambar yang baru sepenuhnya,
terus baru di-apply lagi ke DOM yang asli, yang nyata.
Karena browser juga masih belum terlalu super browser,
masih belum sama ya, belum seragam.
Jadi solusinya React kayak gitu.
Memudahkan buat semacam polyfill atau backwards compatibility juga,
karena semuanya digambar dulu di virtual DOM-nya dia.
- Virtual DOM ini juga salah satu milestones ya,
yang membuat framework-framework kalian juga mengikuti.
- Makin lama, makin dominan JavaScript ya jadinya.
- Iya.
- Sampai di satu titik, semuanya pada pakai JavaScript,
akhirnya website-nya lambat.
- Website yang dikirim di awal nggak ada isinya?
- Betul, kosongan.
Dia nunggu datanya nyampe,
begitu datanya nyampe, dirender,
jadi ada proses si user menunggu loading pertamanya,
hampir sama seperti kejadian seperti di Flash jaman dulu,
harus loading dulu.
Itu kejadian di client-side rendering.
Walaupun tidak begitu kelihatan ya,
karena mungkin koneksi internet udah bagus,
yang dirender juga,
ya mungkin text, image, dan lain-lain,
ya mungkin cukup oke lah, masih bisa ditolerir lah,
tapi untuk yang butuh performa yang bagus,
itu menjadi hal yang kurang menyenangkan gitu,
yang akhirnya munculah solusi-solusi seperti
server-side rendering yang kombinasi.
- SSG.
- SSG dulu yang muncul ya?
- Belum, belum.
Itu yang kayak pakai itu loh, pre-render.
Jadi pre-render.
Karena gini, masalahnya kan di SEO jaman itu,
Google Callbot itu belum bisa ngerender di JavaScript.
- Belum bisa baca...
- Bisa baca HTML-nya,
tetapi tidak bisa ngerender di JavaScript.
Jadi masalah, masalah nih bagi si Google.
Jadi dia nggak tahu kontennya apa,
web-site-web-site yang pakai client-side rendering itu,
gimana solusinya?
Akhirnya pakai namanya pre-render dulu.
Jadi kalau di-detect,
kalau yang request itu bot,
masuk ke pre-render.
Jadi di pre-render yang dikirimkan ke bot itu,
HTML-nya berbeda dengan HTML yang dikirimkan oleh user.
Itu awalnya pre-render.
Baru muncul...
- Baru muncul SSG,
itu adeknya strategi pre-render.
Sekalian aja dikirim HTML yang awal, yang mentah,
ya dikirim aja ke user juga.
Karena mungkin kena penalti,
kan sebetulnya kalau SEO,
crawling search engine kan sama Google dilarang kan ya,
kalau experience bot sama experience user terlalu beda,
kan sebenarnya itu kayak misleading kan,
mungkin ada penaltinya atau apa kali ya.
SSG itu dulu kayak mulai jamannya Gatsby kan.
- Gatsby itu yang paling terkenal awalnya SSG.
Atau apa tuh sebelumnya?
- Sebenarnya sebelum itu udah ada.
Ada Jekyll.
- Oh ya Jekyll, Jekyll, Jekyll betul.
- Ada Jekyll, itu awalnya banget.
- Jekyll Hugo berarti ya temennya.
Segenerasi.
- Jekyll duluan,
Hugo itu hampir segenerasi dengan Gatsby.
Gatsby terkenal karena dia di ecosystem JavaScript.
- Samaria Gatsby.
- Iya dia nempelnya sama Riai, GraphQL dan lain-lain.
Akhirnya yang bertransformasi,
yang bertransformasi menjadi
Jamstack.
Yang sekarang lumayan terkenal.
Karena orang kembali melihat kan,
wah ini lambat.
Kalau ke server ngapain golak-balik query ke database,
padahal website kita nggak terlalu dinamis.
Dalam artian, misalkan website pribadi nih.
Artikel, kita bikin artikel,
berapa sih, sebanyak apa sih, gitu kan.
Sebulan sekali juga udah bagus, gitu kan.
Lagi rajin, gitu kan.
Jadi ngapain harus,
setiap ada request harus ke server dulu,
ke database, balik ke server, baru ke klien, gitu kan.
Terlalu banyak makan resource.
Akhirnya, ya udah.
Yang bisa jadiin statik ya, di statikin aja.
Terus abis itu yang ininya, artikelnya,
di generate secara otomatis sekali aja.
Di generate lagi.
Di generate jadi file,
artikel 1.0 HTML, artikel 2.0 HTML,
dikirim balik ke server.
Jadi prosesnya lebih cepat dan lebih aman,
nggak ada database, nggak ada kemungkinan di hack,
karena database-nya bobol atau gimana.
Itu aman semuanya.
Lebih irit juga kan, Debbie, ya.
Balik ke awal kayak tadi Tim Berners-Lee lagi.
Jadi dokumen-dokumen,
tapi itu dibuat oleh si Gatsby
yang tahu program.
Walaupun itu di server lokal kita ya.
Kita bisa jalankan NPM run build,
itu nge-generate, kita push.
Udah deh. Terus irit biaya.
Biasanya...
Gak perlu server.
Kayak gini, biasanya dilakukan secara otomatis
lewat CI/CD.
Kalau teman-teman.
Bukan CI/CD, lewat CI/CD.
Jadi pakai jaman ini.
Kita connect repo kita.
Tapi yang sebelumnya kan,
yang paling pertama ada runner-runner itu kan
GitLab tuh yang awal-awal tuh.
GitLab yang punya runner yang free.
Nah, jadi biasanya kita push ke Git repo-nya,
pakai hook,
jalanin runner.
Men-trigger mereka yang jalanin NPM run build gitu misalnya.
Oh, biasanya pakai Travis dulu awal-awal tuh.
Travis CI kan.
Terus Travis-nya jalan.
Terus kemudian nge-push ke
kayak server-server SDN yang free.
Kayak Netlify, atau apa?
S3.
Ke storage lah intinya ke storage ya.
Yang tidak membutuhkan web server kan.
Maksudnya yang gak butuh install web server,
atau hosting yang ada PHP.
Jadi sudah dikirim.
Jadi bundlenya semua itu
JavaScript-nya, CSS-nya,
HTML-nya, lengkap-lengkap.
Satu folder
yang dikirimkan update.
Nah, itu static site generation.
Nah, terus kelebihan-nya
dianggap dulu SEO-friendly.
Karena misalnya blog,
website pribadi atau blog,
kan judulnya tetap sudah dikirim di
tag H1, H1 heading.
Ada titlenya, ada isinya.
Nah, pas disajikan
di server-user, tetap bisa di-hydrate.
Misalnya jumlah like-nya kan berubah tuh.
Jumlah like-nya mungkin
bakal di-hydrate.
Nah, disini mulai kenal sama istilah hydrate ya.
Dipanggil dari JavaScript,
terus di-render ulang.
Tapi kan gak semua kan sebetulnya.
Kayak judul blog juga kan
gak terlalu sering berubah.
Isinya juga gak terlalu sering berubah.
Cuma misalnya ada komentar
atau ada jumlah like baru itu yang
dilakukan di client-site.
Di client-site. Jadi di-hybrid lagi.
Jadi sudah static.
Static HTML dikirimkan.
Cuma bagian-bagian tertentu
di-hydrate.
Di-generate.
Di-hydrate ulang untuk request data
untuk diperbarui.
Ini ada
sebenarnya gak perlu, maksudnya
gak mesti pakai framework-framework
juga ya. Gak perlu pakai framework
kayak Gatsby, Jekyll. Karena
saya pernah buat juga dengan WordPress.
Jadi, dari php.
Kan WordPress kan php.
Dan server-user rendering. Jadi
buat ngerender
jadi setelah
konten ditulis, ya kan?
Konten ditulis itu
HTML nya di-generate via
php. Terus php yang meng-upload
ke S3.
Terus file itu
di-serve via
CDN. CDN Cloud Front.
Biasanya. Ya kan?
Itu juga bisa.
Dan projeknya sampai sekarang masih aktif.
Itu yang nge-generate itu
kayak si php-nya
gitu. Jadi gak mesti harus pakai
framework-framework JavaScript.
Dan kalau gak salah,
Next.js yang baru-baru
juga udah bisa
melakukan itu kan?
Benar gak sih?
Dan sebetulnya, balik lagi.
Lama-lama setelah
masa bulan Madu lah
honeymoon phase sama si
SSG ini, kan orang makin
developer sadar
kadang ada kalanya
butuh server-site ya, walaupun
misalnya authentication
atau hal-hal yang pakai
API key atau
punya butuh operasi server,
ya bisa sih client-site,
tapi kan tetap lebih
robust lah, lebih solid,
lebih enak kalau ada
server-nya. Jadi ya tetap
approach yang sama, cuma halamannya
si HTML awalnya tadi
degenerate oleh
server. Nah Next.js itu kelihatannya
yang paling pertama bisa
hybrid, bisa kombinasi.
Bisa pure start SSG,
misalnya ya udah dikirim
HTML-nya gitu aja, bisa
juga combine SSR.
Itu HTML-nya
degenerate oleh si
Next.js.
Remix habis itu ya, yang baru
remix bahkan
pure, murni server-site.
Karena kalau static-site
generasi itu kan memang cepat,
bisa di-service sedien, cuma
cons-nya adalah scale,
solid scale ya. Bayangkan aja
kalau
publishing site, new site, New York Times
yang punya jutaan artikel,
ya masa sekali
ngerender itu
nge-generate satu juta artikel.
Bayangin aja kalau menu-nya
dirobah,
masa ngerender satu juta?
Jadi nggak bisa.
Scaling dari sisi
generation-nya kan, bukan dari sisi
kalau misalkan kayak
S3 atau storage yang lain kan itu
automatic scaling kan.
Storage aman, tapi kan harus dibuild.
Harus dibuild biar nggak
generate sih file-file HTML tadi.
File dan asset-asetnya.
Banyak dan berat ya.
Oke, oke.
Nah.
Jadi mungkin karena
topiknya lumayan panjang,
kita ini ya, kita recap
dulu kali ya, kita recap ya. Jadi awalnya
muncul
di awal itu adalah
server-site rendering dulu,
walaupun dulu istilahnya nggak ada ya.
Eh, static dulu dong, awalnya.
Awalnya static dulu.
Bahkan static file.
Murni static file.
Static document file.
Terus ke server-site.
Server-site yang dinamis, ya.
Lalu kemudian baru ke...
Dynamic scripting language tadi ya.
Iya. Kita coba buka ya, ngeliat ya
contohnya ya di sini.
Ini sih
apa namanya, kalau SSR itu
istilah yang dibuat setelah
proses apa,
setelah fase-phase
web server itu terkenal dulu kan.
Ya, ini udah modern sih.
Jadi
ini server-site, kemudian muncul
client-site.
Client-site juga tadi ada fase-fasenya mulai dari
yang sederhana sampai yang
sudah modern seperti sekarang.
Client-site salah satunya adalah
react misalkan.
Jadi ketika kita buka, kalau misalkan yang client-site
salah satu ciri khasnya adalah
kita akan dapatkan, awalnya
kita akan dapatkan sebuah
halaman kosong. Karena semua
degenerate di sisi klien.
Seperti itu.
Lalu kemudian
kita ke static-site
generation, static rendering
ini proses
pre-render
ya, jadi
HTML dan
JavaScriptnya static
tapi ada proses generationnya
yang membuat dia setengah
dinamis, semidinamis ya.
Contohnya tadi misalkan
kita punya artikel,
artikel ini degenerate supaya
menjadi file-file static.
Tidak melalui
server dan tidak
menggunakan database sama sekali.
Pro dan consnya
temen-temen bisa baca sendiri. Tadi kita juga sudah bahas
cukup pendalam ya, untuk masing-masing.
Saya bisa kasih gambaran
pros dan consnya.
Kalau dokumen
static-site, kita mulai dari server-site
dulu deh. Karena itu mungkin teman-teman
sekarang itu ngerti PHP atau
yang dynamic itu.
Apa sih kebagusnya
dengan server-site, datanya bisa
dinamis, jadi real-time.
Apapun yang kita lihat, real-time.
Cuman kelemahannya adalah TTFB-nya tinggi.
Time-to-verse-back-nya tinggi, karena harus ada
proses request, server yang memproses
ngambil data dari database,
case segala macam, baru balik.
Jadi TTFB-nya tinggi.
Kalau klien...
Dan yang lupa biaya.
Dan SEO-nya bagus, karena
datanya update, karena yang dikirimkan sudah
HTML yang sudah tinggal di-render.
Jadi dari sisi bagusnya,
HTML-nya hanya tinggal perlu
dirender oleh si browser,
jadi FCP dan LCP-nya
secara side-performance bisa
lebih baik.
Kalau client-site rendering,
server kan tidak
perlu memproses apa-apa.
Dia cuma kayak kirimkan,
ini HTML kosongan,
ini JavaScript-nya,
ini datanya,
render aja nih.
Jadi TTFB-nya bagus,
karena cepat,
bahkan bisa di-case
oleh CCDN dengan bagus,
karena datanya sudah ada di-CDN semua.
Jadi cepat banget.
Tapi blocking time-nya
bakal tinggi.
Ya, kelemahannya FCP dan LCP-nya
side-performance-nya,
untuk user bisa ngelihat
konten-nya,
butuh waktu sampai JavaScript-nya selesai di-download.
Betul.
Downside-nya
SEO, secara SEO
kurang bagus, karena
crawler board itu harus
men-download JavaScript yang besar,
dan ada crawler board itu
punya budget
untuk nge-download itu.
Kalau kita ke-block gara-gara itu,
bakal konten kita nggak bisa dibaca.
Balik lagi ke
static-site.
Static-site itu, TTFB-nya
bagus, karena
HTML-nya sudah di-case,
sudah jadi.
Sudah disiapkan, sudah jadi file.
LCP-nya, kalau
misalnya dengan JavaScript-nya nggak berat ya,
asumsi nggak berat, LCP-nya
bagus. Jadi secara SEO juga bagus.
Konten-nya sudah jadi semua.
Kelemahannya adalah,
kalau file-file-nya atau
publishing-site yang
besar,
akan
makan
waktu untuk nge-generate ulang.
Jadi
scalability-nya kurang bagus.
Dan satu sisi, datanya
tidak real-time.
Jadi nggak masuk akal
untuk website
atau web-app yang banyak konten user
generated, nggak mungkin tiap.
Misalnya kayak medium
atau booking-site yang user-nya banyak,
setiap orang nge-post artikel baru,
generate ulang semua.
Itu recap-nya.
Oke, oke.
Jadi itu
pro dan cons-nya.
Kalau penggunaannya,
kapan kita perlu menggunakan
server-site, kapan kita perlu
website, web seperti apa?
Biasanya bagi teman-teman itu,
"Tus yang bagus yang mana?"
"Tus saya pakai yang mana?"
Server bullet.
Padahal sebenarnya semua
bisa diakalin dalam tanda kutip ya.
Misalkan contohnya,
static-site generator ini
nggak bisa bikin, mungkin kurang bagus.
Bukan nggak bisa ya, kurang bagus untuk
yang sifatnya dinamis.
Sebenarnya bisa juga. Misalkan nih, kita
bisa bikin aplikasi e-commerce
dengan SSG.
Gimana caranya?
Ya SSG-nya biasa.
Kelain site, sisanya semua.
Kontennya dari mana?
Kontennya kita pakai yang headless.
Misalkan headless e-commerce apa namanya?
Yang dikirimkan cuma yang
degenerate shell-nya doang.
Ya, shell-nya doang. Selebihnya
di generate di sisi klien dengan menggunakan JavaScript.
Dia cek ke API,
"Oh, ini ada data baru."
Data item atau barang-barang yang
mau di render di halaman satu yang mana
munculin. Itu bisa.
Tapi secara SEO,
belum tentu bagus karena
balik lagi.
Pre-render. Apatih server-site.
Balik-balik, bolak-balik kita.
Bingung kan yang mana kan?
Sebenarnya gampangnya gini, kalau kita terlalu banyak
dicoba aja dulu, maksudnya kita
tetap perlu pernah nyoba semua.
Kita nyobain semua nih.
Terus kita tahu plus-minusnya.
Gampangnya sih kalau kita terlalu banyak pakai workaround,
ada satu titik
dimana udah mending pakai
server-site aja.
Satu titik trade-off-nya
gak sebanding ya, ya udah.
Kalau use case kayak e-commerce
atau dynamically
user-generated site,
ada titik dimana kita
lebih baik pakai server-site
rendering. Nah itu kan tergantung
use case spesifiknya buat
siapa ya. Cuma kalau cuma pengen nyoba,
explore, ya saksah
aja semua cara dipakai.
Kalau menurut saya tergantung
aplikasinya mau dibikin apa.
Kalau sifatnya
banyak konten,
janganlah pakai static site.
Ya, jangan pakai static site.
Mau gak mau kan
atau misalnya banyak konten dan pengen
kontennya diindeks oleh
search engine. Itu syaratnya ya.
Jadi jangan pakai static site karena akan
makan waktu untuk build time.
Kalau misalnya
situsnya kecil,
blog pribadi yang nulisnya sekali sebulan,
ya gak perlu juga server-site.
Karena ada biaya kan
untuk biaya server kan.
Minimal beli hosting.
Kalau sedangkan kalau pakai
static site,
yang itu minimal kita bisa
hosting-nya di github.io, gratis kan.
Iya, betul.
Nah, cuma sekarang
kalau penggunaannya kecil
sedikit sih, sebenarnya sekarang udah banyak
free tier yang lumayanlah.
Netrify,
gratis ya.
Tapi ya,
kalau penggunaannya kecil, kalau misalnya
udah mulai terkenal, banyak pengunjungnya,
ya,
free tier-nya habis.
Maksudnya itu kan konsekuensi lah.
Yang bikin covid,
situs yang untuk
menampilkan jumlah kasus covid,
kawal covid.
Madroid, ya.
Iya.
Oh iya.
Itu kan sebenarnya
hanya
dia tampilkan itu
hanya dengan static site.
Klien site rendering.
Jadi nggak perlu karena misalnya
situsnya hanya dipakai
untuk kebutuhan tertentu
dan kita belum tentu
contohnya
buat nge-tracking sesuatu
yang datanya nggak perlu SEO,
SEO amat. Contohnya
dashboard, dashboard internal
yang bisa kita bikin internal
pakai static,
sorry, klien site, dan
datanya itu
real-time misalnya.
Dynamis, real-time.
Dan interaktif bahasanya.
Ya udah, pakai aja
klien site rendering, nggak perlu mikir-mikir
yang sampai mewah-mewah
pakai server site rendering atau static
site generation.
Kalau internal, klien site aja.
Nggak ada SEO.
Atau mungkin kontennya emang yang harus JavaScript
generated. Misalnya
game atau aplikasi yang
kan fast banget tuh.
Banyak pakai teknologi kan fast
WebGL. Ya itu kan
bakal klien render juga.
Jadi nggak perlu terlalu menikmati
di rendering method.
Anggap aja aplikasinya Figma,
contoh. Anggap aja. Itu kan
klien site rendering kan.
Jadi
ada patternnya. Tapi kan Figma
juga punya main site-nya kan.
Itu yang main site-nya.
Ya static aja main site-nya.
Marketing site,
static aja biar cepet dan
hemat.
Blocknya pakai server site, pakai aja
WordPress, beres kan.
Jadi tergantung situasi.
Jadi satu domain pun
bisa banyak.
Mungkin halaman utamanya
static site,
blocknya server site,
aplikasinya sendiri
client site.
Itu
penggunaannya.
Jelas ya.
Ada lagi yang seru nih. ISR kita belum bahas nih.
Si incremental static rendering.
Incremental static rendering.
Ini kelihatannya dipopuler
dipopulerkan
sama Next.js ya
kalau nggak salah.
Ini ya, ISG ini. Bukan.
ISG, iya.
Jadi ini trobosan yang lumayan
baru sebetulnya.
Kalau tadi kan SSG dibuild sekali,
abis itu ya udah.
Kalau misalnya ada konten baru,
nge-build ulang semuanya.
Kalau misalnya satu website
punya 300
artikel atau 300
konten, harus build ulang
keseluruhan
ya semua 300 halaman itu.
Nah, ISG ini
memungkinkan bahwa
nge-build ulang cuma halaman yang berubah
aja.
Cuma ini relatif baru sih.
Beratif baru ya.
Namun ada kelemahannya
disini, kalau yang berubah itu
elemen yang
ada di seluruh page,
di seluruh page ya, mau nggak mau
render mula.
Contoh menu, logo.
Navigation gitu-gitu ya.
Ya, navigation.
Cuma ini membantu aja sih
alternatif buat enrich.
Ya, misalnya kita belum terlalu butuh
glom se-level media
kayak New York Times atau Guardian.
Maksudnya kita belum sebesar itu.
Cuma emang pengen
nge-build, misalnya tetap
personal site, sebetulnya cuma blog pribadi
aja. Cuma ya misalnya kita mulai
produktif lah. Tadinya
lepost sebulan sekali, sekarang
jadi sebulan 3-4 kali.
Terus kita mulai males kalau harus
nungguin nge-build semua.
Kalau yang berubah emang cuma
satu bagian, satu post.
Misalnya kalau kita cuma
satu post kan yang perlu dirender adalah
misalnya halaman index-nya sama
halaman
post-nya itu sendiri ya, asumsi
kita nggak banyak widget atau
site bar atau apalah, kita cuma punya
website sederhana. Ini kan
bagus buat DX sih.
Buat developer experience-nya ya.
Kita bisa lebih produktif
bikin post baru, tanpa
males, aduh nge-build-nya lama.
Ya, sekarang lumayan.
Terus kalau untuk server site
rendering juga
kita bisa
ngakalin biaya
atau beban dari server
site rendering sebenarnya diakalin dengan
cache. Kita
manfaatin cache
sebisa mungkin, jadi yang di-serve
adalah cache, jadi lebih cepat
juga. Oh, ini yang
benar-benar dimanfaatkan oleh
Remix ya, kalau nggak salah ya.
Dia menggunakan... Remix dan Next.js.
Dan Next.js, oke.
Mereka punya text yang
memudahkan caching.
Gimana dengan framework-nya
baru seperti Astro?
Astro dia pakai arsitektur
island ya. Island architecture ya.
Sudah pernah kita bahas kan.
Sudah pernah kita bahas. Mungkin TLDR-nya
bisa dijelaskan sedikit
aja. Nah, si Astro...
Oh, island ya. Island itu
memandang seluruh
dome itu kayak
apa ya, secara geografis lah.
Jadi,
dibagi jadi modul-modul
kayak di layar itu. Nah, kan
nggak semua perlu
dinamik dan
terus-menerus berubah.
Jadi, ini dianggap
semua di awal, status,
bagian-bagian yang perlu
dinamis, di hydrate,
atau di
dome-nya diubah
atau ditimpa dengan
JavaScript saat
butuh. Jadi, saat butuh itu apa?
Bisa waktu pertama kali di loading,
misalnya waktu suatu blog post pertama
kali muncul, kita pengen tahu jumlah like-nya
kan harus nampilin di like
beberapa orang. Yaitu begitu loading,
bisa dilangsung panggil.
Atau bisa juga
nggak usah dulu. Misalnya, comment kan paling bawah.
Kan belum masuk viewport tuh.
Belum tentu user scroll sampai bawah.
Jangan ngeboros, jangan bikin boros
total booking time ya itu.
Abang, biar
JavaScript browser bisa ngerjain hal lain.
Ya udah, biarin dulu.
Nggak usah melakukan apa-apa.
Kalau user mulai scroll ke arah
ke bawah, ke arah comment,
baru JavaScript-nya
muncul dan beraksi dan
nge-fetching, ngambil data comment
terus nge-replace
dome-nya di browser dengan isi
komentar.
Pasti saya bisa scroll sedikit.
Jadi, dia kayak hybrid. Scroll lagi ke bawah sedikit.
Jadi,
si framework ini akan menentukan
mana yang harus di server,
sorry, bagian yang tadi.
Naik atas-naik atas sedikit.
Ya, stop.
Jadi, si framework itu bisa menentukan
yang mana yang perlu dirender di server,
yang mana perlu dirender di client.
Jadi, contohnya, untuk page layout-nya
dirender server-side rendering,
block title-nya server-side rendering,
block content-nya
itu sudah static side,
dia sudah
case secara static,
dan untuk beberapa
tempat, dia sudah
di server render, cuma belum di-hydrate.
Mungkin dia perlu
interactivity, ya,
perlu interactivity, dan hanya
di-hydrate saat
itu muncul di viewport.
Oke, berarti ini
sederhananya gabungan
antara server-side
rendering dengan
side generation. Benar nggak?
Dan ada client-side
dan ada client-side rendering juga.
Ya, pokoknya gabungan semua yang
tadi kita ceritakan, gitu ya.
Menarik sekali. Ini
ada contoh framework-nya, ada Marko,
Astro, ada Elefanti,
yang bisa di-communicate.
Si creator Angular
bikin lagi, apa tuh?
Quick. Dia island juga, kan ya?
Gak salah, ya.
Ya, ya.
Quick island. Perusahannya gimana?
K-W-I-K.
Builder.io, kalau nggak salah, kan?
Nah, ini dia, benar.
Kalau nggak salah, ya.
Anggular, betul?
Misko Hegri.
Ini island architecture,
betul. Island, ya?
Dia ada tulis di sini, ya?
Dia kan yang diutamakan
di sini, kan? Resumeable ini, kan?
Iya.
Jadi makin lama, makin banyak kombinasinya, ya.
Iya. Jadi ada
dari semua pendekatan itu
ya kayak base of
both worlds, ya. Kayak dicomot mana yang
bermanfaat, mana yang
banyak dibutuhkan,
di-mix semua.
Betul.
Terakhir,
sebelum kita
tutup, ya, dan tadi udah ada
server side, ada yang lain-lain, teman-teman
bisa ke patterns.dev untuk melihat
metode-metode apa?
Contoh-contohnya sama detailnya.
Sama detailnya, ada
yang bahas macam-macam juga.
Nah, ini ada sesuatu
yang menarik di
beberapa
bulan belakangan.
Jadi, kan tadi di awal,
kalau server side trending itu
mengirimin semua static site-nya
yang degenerate di server
ke client-nya.
Ya, kontennya, semua kontennya, kan.
Kemudian berubah di
client side itu yang dikirimkan
adalah datanya.
Tapi dengan
mengirimkannya dengan request dan
response, kan.
Nah, ini muncul
tren lagi
yang dikirimkan itu
HTML-nya, HTML CSS dan
JavaScript-nya, tapi dikirimkan tidak
melalui
request-response yang biasa, tapi melalui
websocket.
Websocket.
Ini ada contohnya
di sini, namanya Unpoly.
Jadi kayak streaming, dong?
Iya, kayak streaming.
Ya, kelebihan-nya berarti speed dan
kayak observability juga ya, berarti
itu secara ga langsung, kan?
Dia sebenarnya dirender di server, tapi dikiriminnya
pakai websocket jadi agak lebih cepat
dibandingkan server side trending.
Ini ada beberapa contoh, ada Unpoly
yang sifatnya
lebih unopinionated
atau Hotwire.
Hotwire ini
mumpulnya bareng
si Ruby on Rails yang
dibikin oleh Basecamp, kan?
Hotwire. Ada satu lagi
nah, ini
dia beradanya dimana?
Dia beradanya diantara server side
trending dengan SPA.
Jadi, dia ada di tengah-tengah sini.
Jadi, dia
secara halaman itu tetap
di server
yang harusnya cukup cepat
kemudian, tapi
secara interaktifitasnya
bisa menyayangi single-place application.
Menarik.
Ada baru lagi.
Ini baru ya.
Jadi, ada tadi Hotwire.
Kalau ga salah, Laravel juga ada.
Namanya apa ya? Livewire, kalo ga salah.
Ada ga disini?
Kenapa mirip-mirip namanya?
Livewire itu
kayak ini, kayak
aplikasi jaman dulu, Livewire.
Nah, ini Hotwire.
Kalau temen-temen tertarik,
ini implementasinya dimana?
Kalo ga salah, hey.com
itu email kliennya si Basecamp
itu menggunakan Hotwire.
Iya.
Dia menggunakan frameworknya namanya Stimulus.
Framework JavaScriptnya.
Ada Django juga ada.
Kemudian untuk
Phoenix Elixir ada namanya Liveview.
Itu semua pake Websocket.
Pake Websocket.
Bukan HTTP.
Kenapa?
Itu Laravel Livewire.
Itu Livewire?
Ada juga.
Dan Unpoly yang
sifatnya unopinated.
Jadi framework
agnostik.
Htmx juga ada.
Oh, Htmx.
Htmx itu kayaknya sering disebut.
Sering disebut ya.
Nah, itu.
Trendnya ke arah sana.
Kita ga tau ya, yang mana yang lebih
populer nantinya.
Tapi ini alternatif aja.
Karena kalo di software, renderingnya pasti cepet.
Tapi proses ngirim ke
HTTP-nya lambat. Kurang bisa
interaktif. Kalo misalkan diklik kayak gini ya.
Retweet atau like gitu kan.
Apa namanya?
Gak bisa kan kalo di software kan.
Harus refresh kan.
Nah, ini di tengah-tengahnya.
Jadi dia tetep bisa update, tapi...
Tinggal kalian pake Websocket.
Terus meringankan kerja
JavaScript Engine di browser.
Karena ga harus passing apa-apa ya.
Dikirim udah jadi HTML.
Jadi yang kerja beratnya tetep software.
Oke, makin banyak ide aneh-aneh.
Kurangan. Yang bikin...
Kenapa Websocket?
Kenapa ga HTTP? HTTP kan dia
request-response kan. Harus ada proses
refresh-nya gitu kan.
Kalo Websocket dia kan kebuka terus.
Koneksinya kan.
Jadi ketika ada update, ya udah.
Dia bisa komunikasi lagi gitu.
Kalo HTTP kan dia
begitu request, response udah nyampe,
udah dia putus kan koneksinya kan.
Kalo kita mau request yang baru, kita harus
konek lagi.
Jadi ini adanya di tengah-tengah.
Jadi sebagai alternatif juga,
lain pattern-pattern yang kita
pelajari tadi. Mungkin
disini lebih ke streaming server side
kali ya? Masuknya ya?
Ada kekurangannya?
Ada kekurangannya sih
dengan Websocket. Artinya
server-nya harus kuat, karena
Websocket itu harus
keep alive.
Iya, dia buka terus jaringannya.
Apa, koneksinya ya?
Koneksinya. Dan kalo
ga bisa pake CDN, ya. Rata-rata CDN
itu ga bisa sih. Contohnya kalo
CloudFront itu ga bisa
keep alive.
Jadi harus konek langsung ke load balancer.
Jadi load balancernya temen-temen harus
kuat.
Intinya orang infrared-nya kudu
jago ya. Kalo engga, bisa ga
sengaja ngedidos itu sendiri.
Apa isilahnya?
Rawan...
Kan satu...
Koneknya kan tetap liat
load balancer. Nah, load balancernya itu harus
kayak punya bandwidth
yang besar. Karena harus bisa
simultaneous user kan depends ya.
Tergantung sama komedian. Jadi kalo
Websocket semuanya dibuka
ya harus kuat.
Tapi ya memang cepet sih.
Iya.
Dari sisi klien juga lebih ringan
kan. Karena yang bertugas
melakukan rendering itu adalah
pekerjaan yang paling berat itu di sisi server kan.
Jadi klien tidak terlalu diberatkan untuk
renderingnya.
Ya, gitu.
Oke.
Kita sudah satu jam lebih? Ada
lagi yang mau didiskusikan?
Engga. Tidak ada?
Sudah cukup? Oke.
Kalo gitu, untuk
episode kita
malam hari ini, yang tadinya
kita bingung mau ngomong apa, ternyata
panjang juga ya. Ternyata tetep jam
juga. Tetep ya. Tetep sih jam juga ya.
Emang luar biasa ya.
Berolan kita sampai
kemana-mana. Ya, jadi
itu dia
pembahasan tentang berbagai metode
untuk melakukan rendering. Mulai dari
static,
server, klien,
dan kombinasi-kombinasi yang lainnya.
Dan ada banyak lagi
kedepannya juga pasti akan berkembang terus.
Jadi, untuk itu
sekian dulu aja untuk episode kita
episode ke-19 tentang
metode rendering. Buat teman-teman
yang punya pertanyaan atau
mau diskusi topik
tertentu bisa ke
bit.ly/ngobrolinweb
gitu ya. Terima kasih
buat atensinya.
Kita ketemu lagi di episode
berikutnya minggu depan.
Selamat malam. Dadah.
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 ----------------------------------------------------------------------------------- Bergabung menjadi anggota elit di kanal ini: https://www.youtube.com/channel/UCHhAlFGFCGgIusQkQIqJLYw/join Donasi dapat meningkatkan kualitas kanal ini: 💰 https://karyakarsa.com/rizafahmi/tip 💸 https://sawer Kunjungi https://ngobrol.in untuk catatan, tautan dan informasi topik lainnya.
Episode Terkait
22 Mar 2023
Ngobrolin Teknologi Edge
Teknologi edge dibahas bersama Donny, head of engineering di Zero One Group, dan penjelasan paling gampangnya: mirip CDN...
27 Jun 2023
Ngobrolin Bundler
Module bundler dibahas lewat sejarahnya, bukan daftar perkakasnya — dan pesan pembukanya bahwa hampir semua orang yang m...
21 Jun 2023
Ngobrolin DevTools
Chrome DevTools dibahas sebagai salah satu alasan sesungguhnya orang bertahan pada sebuah browser — bukan mesin renderin...
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 .