- Berbeda dari pandangan bahwa perbedaan antara situs web statis dan dinamis telah memudar, dalam rentang operasi jangka panjang situs web berbasis berkas statis tetap memiliki sifat yang berbeda
- Metode penempatan berkas yang berlanjut sejak awal web dan efisiensi penyajian berkas statis adalah alasan mengapa situs statis cenderung lebih mudah dipertahankan dalam jangka panjang
- Situs web statis memiliki batas tanggung jawab yang jelas seperti sistem berkas di antara server web dan konten, sehingga hal yang perlu diketahui kedua sisi satu sama lain sangat terbatas
- Situs web dinamis sulit memiliki batas antara server web dan kode pengguna yang kecil dan sederhana, dan juga sulit distandardisasi menjadi satu batas dan API
- Kriteria pembedanya bukan jumlah pekerjaan atau frekuensi perubahan, melainkan di mana batas itu berada dan apa yang harus diperhatikan masing-masing sisi
Titik awal perdebatan situs web statis
- There is no such thing as a static website karya Wesley Aptekar-Cassels berpendapat bahwa perbedaan antara situs web statis dan dinamis lebih kecil daripada yang dibayangkan
- Situs web statis lebih dinamis dan kompleks daripada yang terlihat
- Membuat dan mengoperasikan situs web dinamis menjadi lebih mudah daripada sebelumnya
- Masing-masing poin dikembangkan secara meyakinkan, tetapi tidak sampai mendukung kesimpulan bahwa perbedaan antara situs web statis dan dinamis telah mengecil
Perbedaan yang dibentuk oleh daya tahan dan batas tanggung jawab
- Dalam rentang waktu panjang, konten web berbasis berkas statis telah menunjukkan daya tahan yang tinggi
- Meski server web dan host tertentu berubah, metode menempatkan berkas statis dan pohon direktori telah berlanjut sejak awal web
- Penyajian berkas statis juga sering diperlukan dan efisien pada situs web dinamis, sehingga situs yang hanya memiliki berkas statis pun memanfaatkan keunggulan yang sama
- Jika hanya menyajikan konten statis, situs menjadi stabil dan mudah terus dioperasikan, dan secara historis hal ini tidak berlaku untuk situs web dinamis
- Inti situs web statis adalah batas tanggung jawab dengan isolasi yang sederhana dan kuat
- Di satu sisi ada kompleksitas server web statis, termasuk pembaruan dinamis seperti perpanjangan sertifikat HTTPS
- Di sisi lain ada berkas statis, dan di antaranya terdapat sistem berkas atau sesuatu yang menyerupai sistem berkas
- Apa yang diminta kedua sisi satu sama lain sangat terbatas
- Situs web dinamis sulit memiliki batas kecil dan jelas seperti ini antara server web dan kode pengguna
- Kemungkinan untuk menstandarkannya menjadi satu batas dan API juga rendah
- Dalam beberapa hal, web memang dirancang untuk menyajikan berkas statis
- Perbedaan ini membuat server web berkas statis lebih unggul untuk operasional dan migrasi dibanding server web dinamis dan lingkungan eksekusinya
- Server web berkas statis mudah ditemukan
- Bahkan jika operator saat ini berhenti, situs mudah dipindahkan ke tempat lain
- Daya tahan ini berlaku setidaknya untuk situs web statis skala kecil hingga menengah yang muat dalam satu server
- Pembedaan antara situs web statis dan dinamis tidak kabur
- Ukurannya bukan jumlah pekerjaan untuk membuat dan mengoperasikan situs, atau banyaknya elemen yang berubah secara berkala seperti perpanjangan sertifikat HTTPS
- Ukurannya adalah di mana batas berada, dan apa yang harus diperhatikan masing-masing sisi
- Situs web statis memiliki batas tegas yang memungkinkan kedua sisi ditangani secara independen, sedangkan situs web dinamis pada dasarnya tidak memiliki batas seperti itu sehingga, bila perlu, garisnya harus ditarik secara artifisial
1 komentar
Pendapat Hacker News
Saya mencari nafkah dari situs web konten, dan tahun ini pindah dari Craft CMS ke generator situs statis buatan sendiri
Sekarang saya tidak perlu memikirkan server atau CMS, tidak perlu pembaruan, dan sudah menyingkirkan database berat serta konfigurasi caching yang rumit. Kini hanya server berkas statis, jadi lebih stabil dan hampir tidak butuh pemeliharaan
Hal terbaiknya adalah bisa bekerja offline. Cukup dengan editor teks, jadi Macbook 12" kecil pun terasa sangat cepat
Kontrol versi juga sangat berguna karena saya bisa meninjau atau membatalkan perubahan, dan melakukan cari/ganti dengan regex di seluruh konten. Berkas teks mudah ditangani
Saya menulis seperti apa rasanya transisi ini dan mengapa ia berjalan baik di sini: https://nicolasbouliane.com/projects/ursus
Namun saya berharap teknologi ini menjadi lebih mudah diakses juga bagi orang yang tidak punya kemampuan untuk mengompilasi ulang dan menerapkannya. Ini cara membangun situs web yang cepat dan murah, tetapi alat yang ada seperti Hugo menuntut cukup banyak prasyarat dari pengguna sehingga menciptakan hambatan masuk
Tulisannya juga menarik. Saya membuat versi awal html-to-markdown yang dipakai untuk migrasi itu, dan senang melihatnya masih berguna
Cepat, berisi hal-hal yang dibutuhkan, dan tanpa embel-embel
Secara pribadi, saya ingin ada bagian serial TV dan film yang berlatar Berlin dulu dan sekarang, serta penilaian singkat tentang seberapa realistis mereka menggambarkan Berlin yang sebenarnya
Kemungkinan besar lebih dari 95% dari seluruh situs web sudah cukup dengan menyimpan 70% konten populer di RAM, dan menyajikan 30% sisanya dari SSD yang mampu melakukan pembacaan acak 10.000 IOPS
Jika Anda tidak terus-menerus mengutak-atik desain situs, pembuatan situs dan HTML seharusnya dilakukan di perangkat lokal, dan keseluruhan proses generasi juga seharusnya kurang dari 1 detik
Namun pendekatan yang berpusat pada GitHub, kontrol versi, dan editor teks masih terlalu condong ke teknisi dan programmer. Yang dibutuhkan adalah sesuatu seperti WordPress terhosting, atau sesuatu yang lebih dekat dengan masa Dreamweaver/Frontpage dulu
Saya suka karena ketika ingin mengimplementasikan sesuatu yang khusus, saya bisa menggali sampai detail. Misalnya, jika saya mengedit tulisan Favorite Git Aliases, ia bisa diubah menjadi berkas
.bash_aliases, didorong ke GitLab, dan juga dimirror ke GitHubBagi yang penasaran, ada di https://jdsalaro.com. Saya belum menulis detail tentang stack atau alasannya, tetapi akan mendokumentasikannya sedikit demi sedikit
Untuk sementara saya sudah menulis cheat sheet Markdown dan Myst untuk Sphinx (https://jdsalaro.com/cheatsheet/sphinx-myst-cheat-sheet/) serta cara memuat
environment.pickle(https://jdsalaro.com/howto/sphinx-load-environment-pickle/)Ini juga berarti memakai lebih sedikit sumber daya seperti listrik, cukup dengan perangkat keras yang lebih kecil, dan yang terpenting, keamanan meningkat. Situs web statis lebih sulit diserang, dan kemungkinan cacatnya pun terbatas pada sisi server web, bukan kode situs web
Biasanya saya memakai Hugo, dan fiturnya sangat kaya serta matang. Saya juga pernah membuat situs web multibahasa
Mengintegrasikan Turbo Hotwired ke situs web statis juga layak dipertimbangkan. Ini bisa meningkatkan responsivitas navigasi dan mengurangi beban di sisi server maupun klien
Jika perlu, Turbo juga bisa diintegrasikan dengan Mercure untuk streaming halaman real-time
Perbedaan terbesar antara situs statis dan situs dinamis adalah permukaan serangan keamanan
Server web situs statis, dalam skenario terburuk, hanya bisa dibujuk untuk menyajikan berkas yang salah, dan itu bisa dimitigasi dengan hanya menaruh berkas yang memang boleh disajikan di server sejak awal
Situs dinamis bisa dibujuk untuk menjalankan kode, bisa dibuat mengembalikan data yang salah dari database yang dapat diakses, dan juga bisa dibuat mengubah data
Pembobolan WordPress terjadi terus-menerus, tetapi pembobolan Nginx tidak demikian
Secara teknis, tidak ada situs web yang tidak menjalankan kode. Mulai dari server web, driver sistem berkas, sampai sistem operasi, semuanya adalah kode
Memang benar berkas statis mengurangi permukaan serangan, tetapi kita perlu memikirkan lebih dalam mengapa begitu dan merancang sistem dinamis yang cerdas dengan keamanan seperti situs statis
Pada akhirnya intinya adalah input dan bagaimana input itu ditangani. Seberapa rumit pun kode yang dijalankan, jika tidak menerima input sama sekali, ia tidak bisa diserang. Tentu saja tanpa input kita bahkan tidak tahu halaman mana yang harus ditampilkan, jadi situs statis pun punya input. Di sinilah letak pembedaan yang penting
Saya setuju permukaan serangan situs statis lebih kecil, tetapi menurut saya alasan yang lebih besar adalah nginx mendapat jauh lebih banyak peninjauan dan laju pengembangannya lebih lambat daripada kombinasi plugin WordPress rata-rata
Jika Anda membuat server web statis sendiri, versi pertamanya kemungkinan besar lebih rentan diserang daripada instalasi WordPress dasar
Situs statis, secara teori, mungkin sama sekali tidak memerlukan pembaruan. Selama target seperti versi HTML tidak berubah, konsep pembaruan itu sendiri hampir tidak ada
locationyang memiliki direktifaliasDari sudut pandang developer, pembedaan ini cukup rapi jika didasarkan pada abstraksi yang disediakan web, yaitu hypermedia di atas HTTP/S
Semantik abstraksi ini adalah struktur di mana permintaan dengan header dan body masuk ke suatu path tertentu, lalu respons dengan header dan body keluar. Detail jaringan perantara seperti TLS disembunyikan
Dalam praktiknya, framework modern bahkan mengelola sesi autentikasi dan header permintaan secara otomatis, sehingga makin banyak hal disembunyikan dari developer. Di dalam abstraksi ini, pemisahan standar bahwa “statis tidak bergantung pada permintaan/status, dinamis bergantung” memang rapi, tetapi pembedaan itu bertumpu pada semantik yang disediakan abstraksi tersebut
Ini mirip dengan cara TCP beroperasi sebagai protokol berorientasi koneksi di atas infrastruktur bawah yang pada dasarnya berbasis paket. TCP bisa digunakan untuk aplikasi yang membutuhkan transfer data berbentuk stream maupun berbentuk paket
Orang bisa saja berargumen bahwa “sebenarnya semuanya di atas IP, jadi tidak ada perbedaan,” tetapi itu berarti melihat dari lapisan abstraksi yang keliru
Meski begitu, bukan berarti inti tulisan tersebut salah. Developer harus selalu mengingat adanya statefulness di bawah “situs web tanpa state”, dan sebaiknya memahami abstraksi beberapa lapis lebih dalam daripada yang mereka kira perlu
Situs web pribadi secara halus merupakan campuran antara statis dan dinamis. Sebagian besar statis, tetapi bagian blog menggunakan rendering dinamis
Saat URL blog diakses, file Markdown diambil dari disk lalu diubah menjadi HTML, kemudian HTML itu dimasukkan ke template untuk menyusun sisa halaman, CSS, dan sebagainya
Meski begitu, tetap cepat dan efisien. Pekan lalu, ketika salah satu tulisan blog saya naik ke posisi pertama HN, seorang teman mengirim pesan, “semoga kamu sudah menyiapkan Cloudflare.” Saya tidak menyiapkannya, tetapi load average VPS 2-core dengan memori 1GB tidak pernah melewati 0,15
Polanya seperti, “sebagian besar HTML, tetapi ketika sampai ke baris ini di file ini, jalankan kode untuk mem-parse file dalam format lain dan sisipkan hasilnya ke output”
Pada 2001, ini sangat masuk akal untuk membuat situs web statis yang memiliki sesuatu seperti bagian komentar pada setiap posting blog. PHP semacam ini cukup murah sehingga ISP biasa pun sering mengizinkan orang mengunggahnya ke
/~userdir/dan mengeksposnya ke internet publikDengan struktur yang masuk akal dan tidak terlalu berat bergantung pada database, VPS kecil pun bisa dengan mudah menahan arus trafik dari Hacker News
Jika Anda meluncurkan Threads, tentu Anda membutuhkan cara scaling seperti yang dilakukan Facebook, tetapi untuk situs baca-saja biasa, sama sekali tidak perlu menghabiskan banyak uang
Saya bisa membayangkan alasannya adalah memasukkan konten dinamis ke template, atau mengurangi waktu build dan kompleksitas, tetapi mungkin ada alasan lain yang belum terpikir oleh saya
Dari sudut pandang orang luar yang sedikit mengutak-atik wasm, saya tidak paham mengapa menjalankan kode pengguna di server untuk menghasilkan halaman web “dinamis” lebih baik daripada server berkas sederhana
Rasanya bagian dinamis bisa dijalankan di browser, sementara server cukup menyajikan berkas saja. Pengecualiannya adalah bahwa browser tahun 90-an sangat buruk untuk pekerjaan seperti ini
Dari sisi kesederhanaan dan skalabilitas, tidak ada yang bisa mengalahkan server berkas sederhana di depan CDN
Juga penting seberapa banyak teknologi yang ada yang tidak merusak fitur dasar browser
Sebagai referensi, GitHub saat menelusuri kode sumber masih merusak tombol kembali sekitar 40% di lingkungan saya. Saya memakai Chrome di OSX, dan saya bahkan tidak tahu bagaimana itu bisa terjadi
Dalam pengalaman saya, situs yang menghasilkan HTML di sisi server terasa lebih cepat dan lebih stabil daripada yang mengandalkan rendering klien. Membuka booru dengan lebih dari 50 gambar per halaman saat cache browser kosong selalu terasa lebih cepat dan nyaman daripada membuka halaman GitHub yang hanya berisi teks, sudah ter-cache di mana-mana, dan tidak berubah selama beberapa hari
Misalnya, Anda mungkin ingin menyimpan konten kiriman pengguna ke database, mungkin perlu autentikasi, atau harus menyediakan pencarian teks penuh pada dataset berukuran beberapa GB. Anda juga mungkin harus menyediakan antarmuka untuk hal-hal yang tidak bisa diakses dari browser, atau memvalidasi input pengguna
Semua ini membutuhkan kode pengguna yang berjalan di server. Maka data di server harus diubah menjadi protokol transfer yang terdefinisi dengan baik, dikirim ke klien, lalu diubah lagi dan dijadikan HTML
Arah sebaliknya juga sama; untuk mencegah klien kustom yang berniat jahat, validasi input harus dilakukan di sisi klien dan server
Atau Anda bisa langsung menjadikannya HTML di server dan selesai. Beban kerjanya jauh lebih kecil, dan untuk sebagian besar aplikasi pada dasarnya memberikan pengalaman yang sama
Jika ada nilai rahasia yang harus disembunyikan seperti kata sandi database, API key, atau kunci enkripsi, kode di server harus menanganinya. Jika semua kode berjalan di klien, selalu ada kemungkinan penyerang menemukan nilai rahasia itu
Memberikan API yang lebih kecil dan lebih terbatas kepada klien juga cenderung memudahkan pengurangan attack surface. Jika klien terhubung langsung ke database, izin dan konfigurasi keamanan harus tepat dan bebas masalah; tetapi jika aplikasi hanya menyediakan daftar buku atau film yang ditangani, pertahanannya lebih sulit ditembus
Sering kali situs terasa lebih responsif jika pemuatan awal diberikan sebagai satu paket data yang langsung bisa dipakai. Walaupun waktu sebenarnya sama dengan cara mengunduh aplikasi, menampilkan indikator loading, lalu mengambil dan menampilkan data, bagi pengguna cara pertama terasa lebih cepat
Server biasanya berada di dekat database dan server lain yang dibutuhkan, jadi memuat hal yang diperlukan di front end bisa lebih cepat. Panggilan jaringan di lingkungan seperti ini lebih stabil. Jika semua pemrosesan didorong ke sisi pengguna, Anda harus menangani panggilan yang lebih lambat dan kurang stabil
Server kemungkinan besar merupakan platform yang jauh lebih konsisten daripada browser pengguna. Browser memang sudah membaik, tetapi masih ada banyak perbedaan halus. Di server, Anda bisa menentukan dengan tepat alat dan versi runtime yang dibutuhkan dan memperbaruinya dengan lebih deterministik
Tentu saja ini tidak selalu benar semuanya dan ada pengecualian. Saya terutama menangani aplikasi front-end, tetapi ada nilai besar juga pada aplikasi yang dirancang baik dan melakukan sebagian besar atau seluruh pekerjaannya di browser. Hanya saja biasanya itu adalah web app yang cukup kompleks, atau memang tetap membutuhkan rendering di browser sampai taraf tertentu
Pembuatan hanya dilakukan sekali dan selesai sangat cepat. Setelah itu, dari sudut pandang pengguna, banyak keunggulan halaman statis tetap berlaku
Penggunaan sumber daya beberapa orde magnitudo lebih kecil dan halaman jauh lebih responsif. Pengalaman pengguna juga jauh lebih baik, tetapi selama 10 tahun terakhir kita tidak terlalu memedulikannya
rsync. Semua halaman dirender secara dinamisKelebihannya, setelah sekali dikonfigurasi, saya secara harfiah tidak perlu memikirkan situs web itu lagi dan cukup menulis Markdown yang saya sukai
Sangat menyenangkan. Sampai penyedia web hosting menghapus PHP
Karena alasan ini saya sangat menyukai ekspor halaman statis NextJS
Build lalu deploy hanya
.html,.js,.cssstatis ke CDN atau server web statis mana pun yang diinginkan. Tiap halaman dan route sudah di-prerender saat build, sehingga pemuatan pertama sangat cepat dan bisa diindeks mesin pencariCara NextJS membagi kode
.jsmenjadi chunk dan melakukan preload juga berkontribusi pada pengalaman loading yang cepat. Jika membutuhkan fitur kaya, Anda bisa menghubungkannya ke REST API yang diinginkan dan membuatnya sedinamis apa punDengan plugin MDX, Anda juga bisa dengan mudah membuat area yang sepenuhnya statis atau situs berfokus konten dalam proyek yang sama
Namun sejak app router v13 muncul, rasanya fitur ekspor statis kurang diperhatikan. Dari fitur yang ada di page router, shallow routing serta rewrite/redirect statis hilang dari ekspor statis
Kalau memakai ekspor statis, produk komersial Vercel sama sekali tidak diperlukan, jadi saya khawatir dalam jangka panjang fitur ini malah akan dihapus sepenuhnya
Sebagian besar bahkan tidak membutuhkan JavaScript, apalagi React, JSX, middleware, atau server-side rendering
Sulit membayangkan memelihara jangka panjang sesuatu dengan begitu banyak komponen bergerak dan dependensi npm. Bukan berarti tidak ada kegunaannya, tetapi untuk membuat satu landing page, sebaiknya mulai dari yang sederhana sebelum terjun ke proyek dengan checkout Git 1,8 GiB dan 828.128 baris kode
Lihat contoh dari Dan Abramov: https://gist.github.com/gaearon/9d6b8eddc7f5e647a054d7b33343...
Bukan karena model bisnis Vercel, melainkan karena proporsi penggunaan Next.js membuat use case ini kurang umum
Saya tidak yakin apa yang dimaksud dengan “rewrite statis”. Bukankah itu ditangani oleh middleware?
Pada suatu titik di era 90-an, sebelum mendengar istilah “static site generator”, saya membuat situs saya dengan m4
Setelah itu beralih ke PHP, Python, lalu sekarang kembali ke statis dengan Jekyll
Selama memungkinkan, pendekatan statis jauh lebih baik. Kecuali sertifikat SSL, semuanya bisa saya perbaiki sesuai jadwal saya sendiri
Bandingkan dengan situasi ketika upgrade PHP membuat sesuatu rusak: harus segera diperbaiki, dan situs down sampai selesai
Pada situs statis, bahkan jika generator-nya rusak, hasil kegagalannya hanya tetap dalam keadaan statis. Kalau tidak perlu menerbitkan tulisan baru, itu bukan masalah
Kalau server hancur pun, cukup minta teman meng-hosting beberapa file. Tidak perlu bertanya, “Kamu menjalankannya dengan PHP versi X dan konfigurasi Y, kan? Ada postgres juga, kan?”
Beberapa teman mungkin berkata, “Saya tidak mau memasang PHP di komputer saya”
Dari segi kompleksitas, rasanya hanya satu tingkat di atas
sed "s/VERSION/1.2.3/g". Kalau semuanya bisa ditangani dengan perintah shell eksternal, tidak perlu memasang sesuatu seperti PythonSelama beberapa tahun, saya telah mengeksplorasi pola arsitektur yang memberi keunggulan statis sekaligus dinamis
Pola ini bisa menjalankan kode sisi server yang dinamis, tetapi biaya penskalaannya sangat rendah dan dapat memulihkan diri ketika ada yang rusak
Saya menyebutnya pola Baked Data: https://simonwillison.net/2021/Jul/28/baked-data/
Ide intinya adalah mendistribusikan salinan lengkap data situs yang bersifat hanya-baca sebagai aset yang dibundel bersama aplikasi
Seperti situs yang sepenuhnya statis, setiap kali ada perubahan seluruh situs harus dideploy ulang, jadi tidak cocok untuk situs yang terus-menerus diperbarui
Keunggulannya adalah bisa dideploy ke hosting dinamis scale-to-zero yang murah seperti Vercel, bisa menjalankan banyak salinan aplikasi untuk menangani trafik apa pun, dan jika aplikasi mati host dapat otomatis menjalankannya ulang
Saya pernah melihat situs statis dengan pencarian sisi server atau sistem komentar, dengan tiap artikel atau komentar dikirim sebagai flat file terpisah lalu halaman statis dibuat ulang otomatis dari sana
Mungkin bedanya adalah data disimpan di sqlite alih-alih file Markdown dan dibangun dari situ. Dibanding situs statis dengan fungsi backend/sisi server yang umum, itu tampaknya satu-satunya perbedaan bermakna yang terlihat
Pada file executable biner yang dikompilasi, menyertakan resource biner terenkode seperti file atau gambar bukanlah hal yang jarang. Biasanya tidak memasukkan banyak karena ukuran executable akan membesar
Contoh C atau C++: https://github.com/graphitemaster/incbin
Yang menarik adalah program dibuat agar data di dalam executable tidak berubah. Kode terkompilasi berjalan di mesin, dan dari sisi keamanan pun masuk akal
Namun jika memikirkan container, misalnya docker, container yang sedang berjalan mirip dengan executable yang dipaketkan, tetapi juga memiliki file system
Jika data dimasukkan ke dalam container, konsepnya mirip dengan resource yang di-embed ke executable, bedanya data itu bisa berubah
Namun meski data berubah saat runtime di dalam container, perubahan itu tidak bertahan kecuali memasang penyimpanan persisten
Belakangan saya bertanya-tanya mengapa belum dibuat sesuatu seperti satu file tunggal yang “berisi executable sekaligus ruang data volatil di dalam executable itu”. Program dan data seperti database bisa digabung menjadi satu file
Ini sedikit berkaitan dengan “Baked Data”. Meng-embed resource ke executable pada akhirnya berarti memasukkan data terenkode ke dalam executable
Dalam bahasa skrip, kita bisa membuat file skrip yang langsung menyimpan data terenkode base64 di dalam variabel
Dua cara terakhir relatif hanya cocok untuk data statis berukuran kecil, tetapi akan menarik jika ada teknologi yang entah bagaimana mengangkat batasan semacam ini pada executable
Halaman proyek saya juga di-hosting seperti ini: https://usmanity.com/projects
Karena saya tidak ingin mengedit file HTML secara langsung setiap kali menambahkan proyek baru ke daftar atau mengubah detail entri yang sudah ada, saya memakai Notion dan membakar datanya sebelum commit ke GitHub
Jika diaktifkan, semua halaman situs dipanggang menjadi HTML di sebuah direktori, lalu
.htaccessdiubah agar semua trafik diarahkan ke sana. Saat konten diperbarui, semuanya dipanggang ulanghttps://www.drupal.org/project/boost
Menurut saya, bagian yang masih sangat kurang dari situs statis adalah di mana meng-host CMS untuk pengeditan
Tolong koreksi kalau saya keliru, tetapi Decap CMS (sebelumnya Netlify CMS) berjalan di browser, bisa membaca/mengubah melalui GitHub, lalu memicu rebuild dan deployment. Namun karena CORS, browser tidak bisa berkomunikasi langsung dengan GitHub API, jadi menurut saya server kecil atau proxy masih tetap diperlukan
Netlify memang meng-host backend GitHub yang mem-proxy request, tetapi itu berarti terikat pada Netlify dan perubahan kebijakan harganya
GitLab dan BitBucket kemungkinan punya masalah yang sama: https://github.com/isomorphic-git/isomorphic-git#cors-suppor...
Apakah ada cara sederhana untuk menyelesaikannya dengan konfigurasi minimal? Ekstensi browser mungkin bisa melonggarkan CORS secara selektif, tetapi itu tidak ideal
Jika ada CMS untuk generator situs statis berbasis Git yang punya pengeditan Markdown dan pratinjau live, berjalan di browser, serta minim batasan hosting/server, rasanya akan cocok untuk banyak situs web kecil dan blog
Generator statis cukup membaca data itu lewat sesuatu seperti feed JSON untuk membuat halaman. Misalnya, setiap record produk bisa memuat deskripsi isi dalam format HTML
Dengan begitu, meskipun orang lain memperbarui informasi produk, situs web tetap statis. Saya kira Airtable akan cocok, tetapi ternyata dukungannya untuk field HTML tidak terlalu bagus
Buat situs web dengan cara yang Anda inginkan, hubungkan Surreal lewat FTP, lalu biarkan pengguna atau klien hanya mengedit bagian yang diizinkan
USD 12 per bulan sangat murah untuk harga “tidak perlu khawatir lagi”, dan Anda bisa menyediakan editor WYSIWYG penuh untuk pengguna non-teknis
[1] https://www.surrealcms.com
Saat ini ekstensi ini berjalan di VS Code yang terpasang lokal di laptop, tetapi tidak berjalan di GitHub Codespaces
Kalau ini bisa dibuat berjalan dalam jatah gratis GitHub Codespaces dengan batas waktu penggunaan yang wajar, sepertinya akan jadi pemenang. Anda bisa punya konfigurasi yang sepenuhnya online dan terversi tanpa perlu memasang lingkungan pengembangan di komputer sendiri, menyajikan situs statis dari tempat seperti S3, tetapi tetap mendapatkan pengalaman CMS yang lengkap
Hal yang sangat penting dari situs statis adalah jauh lebih mudah untuk diunggah lalu dilupakan
Jika diunggah ke tempat seperti situs S3 bucket, hampir tidak perlu dikhawatirkan
Kalau membuat situs “unggah lalu lupakan” dengan PHP, atau lebih buruk lagi WordPress yang di-host sendiri, situs itu bisa penuh iklan porno Rusia jika tidak dicek selama beberapa bulan
Saya mengelola beberapa situs statis, dan rasanya sangat menyenangkan mengetahui semuanya selalu aktif dan tidak perlu diperbaiki. Sebaliknya, situs dinamis perlu notifikasi untuk memastikan apakah sedang down