Paradoks Situs Statis

• Bahkan untuk situs sederhana seperti blog pribadi atau halaman kontak, pengguna umum tetap menggunakan CMS seperti WordPress, sementara situs HTML statis justru lebih mudah dioperasikan oleh engineer profesional—sebuah fenomena yang terbalik dari dugaan
• Untuk membuat situs statis sendiri, seseorang harus menangani sendiri berbagai langkah perantara, mulai dari membeli domain, memilih hosting, mengatur DNS, memilih SSG, hingga menyusun pipeline deployment
• Engineer memanfaatkan hosting gratis dan domain kustom lewat GitHub Pages atau Cloudflare Pages, tetapi pengguna umum akhirnya bergantung pada layanan yang lebih mahal dan berat, bahkan ketika situs statis sebenarnya sudah cukup
• SuperHTML diperkenalkan sebagai server bahasa HTML pertama yang melaporkan diagnosis kepada pengguna, sementara alat diagnosis yang ada umumnya terikat pada framework frontend tertentu sehingga sulit dipakai hanya dengan vanilla HTML
• Jika pengembangan web sederhana tidak dibuat mudah, web akan makin jauh dari non-ahli, dan pengguna umum akan terdorong masuk ke ruang tertutup seperti jejaring sosial

---

Paradoks ketika situs statis menjadi lebih sulit

• Dua contoh situs web pribadi diperbandingkan
  • Yang satu adalah CMS kompleks yang ditulis dengan PHP dan membutuhkan server web, beberapa worker, cache Redis, serta database SQL
  • Frontend-nya juga dimuat sebagai Single Page Application, meminta konten dalam bentuk JSON, lalu menyusunnya kembali di sisi klien
  • Yang lain terdiri dari file HTML statis dan satu atau dua file CSS, tanpa JavaScript
• Sekilas, pengguna umum tampaknya akan memakai situs statis yang sederhana dan engineer profesional akan memakai struktur yang kompleks, tetapi kenyataannya hampir sebaliknya
• Agar pengguna umum dapat mengoperasikan sendiri situs statis, mereka harus melewati banyak tahap
  • Membeli domain
  • Mencari platform hosting
  • Mengatur DNS
  • Memilih SSG atau membuatnya sendiri
  • Menyusun pipeline deployment
• Sebaliknya, software engineer dapat menikmati hosting gratis dan dukungan domain kustom melalui GitHub Pages, Cloudflare Pages, dan sejenisnya
• Akibatnya, bahkan dalam 99% kasus ketika situs web statis sudah memadai, pengguna umum terikat pada solusi kompleks yang lebih mahal dan memakai lebih banyak sumber daya komputasi

Perlunya alat yang memudahkan web sederhana

• Presentasi SquiggleConf di Boston membahas pengalaman mengimplementasikan server bahasa HTML, dan kesimpulannya mengarah pada isu aksesibilitas web
• SuperHTML diperkenalkan sebagai server bahasa HTML pertama yang melaporkan diagnosis kepada pengguna, dan artikel terkait masuk ke halaman depan Hacker News
• Linter memang ada dan diagnosis di editor juga dimungkinkan, tetapi biasanya terikat pada framework frontend tertentu
  • Karena itu, pengguna akhirnya memilih framework meskipun sebenarnya tidak membutuhkan kompleksitas tersebut
• Web bukan hanya milik software engineer, dan semakin kita membuat web lebih kompleks, semakin pengguna umum terdorong masuk ke pagar jejaring sosial
• Startup maupun big tech sulit menyelesaikan masalah ini sebagai pengganti karena insentif ekonominya tidak selaras, sehingga diperlukan upaya untuk membuat web sederhana menjadi lebih mudah

[GN⁺]

Pendapat di Hacker News

• Saya punya banyak pengalaman pahit mencoba meyakinkan para pemasar untuk meninggalkan WordPress dan memakai situs statis
  Pada akhirnya intinya adalah kemudahan mengedit. Situs WordPress dioptimalkan untuk editor, bukan untuk hosting, penanggung jawab teknis, bagian akuntansi, atau pembaca, dan orang-orang yang mengedit situslah yang akhirnya menentukan cara implementasinya
  Jika diminta memilih antara situs yang dirender dalam kurang dari 100 ms, sepenuhnya aman, biaya hostingnya nol, tetapi membutuhkan berkas Markdown dan sedikit deployment Git, dengan WordPress yang lambat, mahal, rentan, dan perlu pemeliharaan terus-menerus tetapi pengalaman mengeditnya bagus, mereka selalu memilih WordPress
  Saya selalu bingung kenapa orang-orang ini punya hak memilih, tetapi meski eksperimen yang sama diulang berkali-kali, hasilnya selalu sama

  • Itu terdengar cukup tidak ramah pengguna. “Tugas” para marketer adalah membuat konten dan menampilkannya di depan audiens sasaran, jadi wajar jika pengalaman mengedit diprioritaskan dibanding keamanan atau kecepatan rendering
    Saya tidak paham apa yang aneh dari memilih WordPress alih-alih mempelajari editor teks dan Git. Eksperimennya seharusnya membandingkan WordPress dengan alat yang menyediakan pengalaman mengedit yang baik, tetapi di belakang layar membuat situs statis dan deployment Git. Dengan begitu, kebutuhan sampingan seperti keamanan dan kecepatan bisa menjadi bermakna
  • Anda sendiri sudah menjawabnya. Teknologi yang Anda usulkan tidak memenuhi kebutuhan mereka. Situs marketing memang seharusnya dioptimalkan untuk editor, dan ini kegagalan developer, bukan marketer
  • Ini inti masalahnya. Saya pun seorang engineer, dan beberapa tahun lalu meninggalkan WordPress lalu sekarang memakai Ghost, tetapi WordPress memberi rasa kendali: cukup cari “online store” dan muncul 100 plugin, termasuk WooCommerce, yang terasa seperti platform e-commerce siap pakai
    Alih-alih sekadar blog, ia lebih mirip aplikasi kustom yang bisa dibentuk oleh non-ahli hanya dengan klik dan drag sesuai fitur yang diinginkan. Tidak perlu coding sampai situsnya diretas atau muncul kebutuhan fitur kustom yang benar-benar memerlukan engineer
    Kalau memakai Hugo, Ghost, dan sejenisnya, ujungnya menjadi “ini butuh platform lain”, dan platform itu bisa berupa Shopify, sistem akuntansi, plugin jejaring sosial/keanggotaan, papan lowongan kerja, dan sebagainya. WordPress telah menjadi benda yang bisa diubah menjadi apa saja
    Ketika seseorang mengatakan ke konsultan apa yang mereka inginkan, jawabannya menjadi “akan saya siapkan dengan WordPress”, dan karena semua orang memakai WordPress, mudah mencari orang untuk menangani masalah, sedikit memodifikasi plugin, atau memasang hook pengiriman email. Era konsultan PHP membentuk dominasi WordPress
    Masalahnya, bahkan termasuk solusi berbayar, kebanyakan bukan solusi yang lengkap. Begitu mulai dipakai, Anda akan cepat menyadari WordPress memaksakan batasan yang tidak masuk akal. Anda tidak bisa merancang toko online di luar bencana performa sistem entitas/metadata yang membuat query berukuran sedang saja memakan 5 detik dan menghasilkan 50 query tambahan yang tidak dioptimalkan. Beberapa plugin bahkan melewati WordPress dan membuat tabel database sendiri
    Arsitektur WordPress buruk untuk apa pun selain blog, tetapi dipakai sebagai alat untuk segalanya. CMS lain tidak melakukan itu, jadi orang-orang tidak memakainya
  • Anda mencampur dua fungsi yang berbeda. WordPress menyediakan sistem manajemen konten yang disukai pengguna, dan cara konten itu disajikan bisa dipisahkan dengan mudah
    Konten tetap bisa didistribusikan sebagai berkas statis yang dihasilkan melalui CDN. Situs statis tidak harus membutuhkan Markdown dan Git
  • Mereka punya hak memilih karena merekalah yang menanganinya setiap hari. Tujuannya adalah memublikasikan konten dengan cepat, dan kontennya sangat beragam, mulai dari hal-hal yang tidak cocok di Markdown seperti tabel hingga gambar yang perlu hosting terpisah
    Saya sudah lama mencari toolchain yang memungkinkan intern tanpa pengalaman teknis sama sekali untuk menerapkan perubahan tanpa tersangkut detail teknis, tetapi belum menemukannya
    Yang paling mendekati adalah menaruh generator situs statis di atas headless CMS, tetapi sejujurnya semuanya kurang bagus

• Pada 2016, ketika saya bekerja di sebuah agensi yang membuat situs profil untuk bisnis lokal, seorang klien meminta kami memasukkan iframe kecil untuk sistem reservasi ke situs web yang mereka buat sendiri. Yang mereka kirim hanyalah satu dokumen Word, dan ternyata mereka mengekspornya ke HTML lalu mengunggahnya ke shared hosting murah.
  Bagi mereka, itu sangat cocok. Mereka bisa selalu memperbarui menu online, karena cukup mengekspornya langsung dari dokumen Word yang dipakai untuk membuat menu cetak. Saat itu kami di internal agak menertawakannya, tetapi sekarang saya merasa bersalah. Ketika ada sejuta hal yang lebih penting seperti menjalankan restoran, sebenarnya itu cara yang jenius.
  Membuat situs statis tetap lebih mudah. Hanya saja, alat authoring yang menghasilkan HTML saat ini kurang bagus, atau kalaupun bagus, ada proses yang harus berjalan di server untuk menyajikan situsnya.

  • Saya suka ketika bisnis menyelesaikan masalah dengan cara seperti ini. Kalau berfungsi, ya berarti berfungsi.
    Tugas saya bukan mengejek dengan mengatakan “ini bisa dibuat lebih baik”, melainkan meningkatkan solusi mereka, memastikan solusi yang saya berikan bekerja setidaknya sebaik cara lama, kalau bisa lebih baik, tanpa mengganggu keberhasilan yang sudah mereka raih.
    Banyak developer enggan mengakuinya, tetapi solusi web sementara seperti ini sering kali bekerja lebih baik daripada berbagai strategi yang akan diterapkan seorang web developer berpengalaman sendirian.
    Yang penting adalah apa yang disediakan bisnis itu serta bagaimana mereka berhubungan dan berinteraksi dengan pelanggan. Kadang mengekspor dokumen Word ke HTML saja sudah cukup. Teknologi bisa memperbaikinya, tetapi keajaiban sesungguhnya ada pada orang-orang yang menjalankan bisnisnya.
    Mencari cara untuk memperbaiki solusi semacam ini kadang benar-benar cukup sulit. Kita bisa membuat situs web yang lebih baik dan men-deploy-nya ke infrastruktur yang canggih, tetapi pada akhirnya apakah pelanggan lebih menyukainya? Apakah bisnisnya menjadi lebih baik? Bagian itu sama sekali belum tentu sepele.
  • Saya sudah lama mengeluhkan hilangnya FrontPage. Kami menertawakan HTML mengerikan yang dihasilkannya, tetapi pada saat yang sama itu adalah program yang memungkinkan pelaku usaha biasa atau orang biasa memperbarui situs web kecil dan murah tanpa mengkhawatirkan keamanan, asalkan memilih kata sandi yang baik.
    Selama bertahun-tahun saya mencari alternatif bagus yang menghasilkan HTML lebih benar daripada ekspor HTML Word dan memberi lebih banyak pilihan.
  • Menu restoran yang saya kunjungi di CDMX musim panas ini adalah tautan pratinjau publik ke dokumen Figma. Fakta itu sangat lucu, tetapi sekaligus saya senang karena ternyata bekerja dengan sangat baik.
    Saya suka hal-hal seperti ini. Ada banyak situs satu file HTML yang dibuat dengan Vue template, ada juga situs yang dipublikasikan sebagai dokumen Notion publik atau pustaka foto inline di iCloud. Ini membuat saya takjub betapa mudah dan luasnya kini sekadar menghubungkan sesuatu, dan juga membuat saya sadar betapa sering kita memperumit pekerjaan saat mencoba membuat semuanya dari nol.
    Saat tidak punya waktu, saya juga suka alat seperti mmm.page untuk cepat merangkai microsite kecil atau situs sekali pakai. Menjelajahi alat-alat seperti ini menyenangkan.
  • Saya pernah membuat “aplikasi data” untuk seorang klien yang melakukan berbagai hal keren seperti manajemen metadata, pemeriksaan kualitas, dan sebagainya.
    Namun “dokumen” di sebagian halaman hanyalah sekumpulan tabel berisi tanggal dan teks, dan klien mengelolanya sendiri. Solusi akhir yang kami capai juga mirip. Mereka memasukkan tabel ke dokumen Word dan memberikannya kepada kami, lalu kami mengekspornya ke HTML/CSS dan menaruhnya di lokasi yang sesuai.
    Tidak elegan dan bukan solusi yang scalable, tetapi untuk kegunaan tersebut jelas itu cara paling mudah.
  • Respons kemanusiaan Jerman segera setelah invasi Rusia ke Ukraina juga berjalan seperti ini sampai lembaga resmi menyusul beberapa hari hingga beberapa minggu kemudian. Notion, Telegram, WhatsApp, dan Google Docs menyelamatkan situasi.
    Saat itu terasa menakjubkan, dan sekarang pun masih terasa menakjubkan. Diam-diam, kita telah mewujudkan mimpi membawa komputasi kepada semua orang.

• Saat ini di Asheville kami sangat merasakan masalah ini. Bahkan ketika layanan ponsel baru saja kembali, semua orang memakai 3G buruk yang terus terputus, dan tidak satu pun situs web yang diperlukan untuk mendapatkan informasi dasar bertahan hidup bisa dimuat.
  Orang-orang baik membuat situs berita khusus teks, dan hari ini saya melihat situs web Buncombe County juga sudah memiliki situs bandwidth rendah, tetapi ketika saya membukanya, rendering masih terblokir oleh 130KB Bootstrap CSS dan 50KB jQuery.
  Hebat bahwa orang-orang melakukan hal seperti ini, tetapi warga membutuhkannya satu setengah minggu lalu. Sekarang kami sudah mengetahui di mana mendapatkan air, makanan, air non-minum, dan sebagainya. Mengalami kejadian ini dan melihat teknologi gagal separah ini membuka mata saya dengan cara yang menyedihkan.

  • Tidak separah bencana itu, tetapi saat listrik padam di lingkungan kami, biasanya yang tersisa hanya ponsel dengan sinyal buruk. Peralatan internet kabel tidak memiliki daya cadangan.
    Peta pemadaman perusahaan listrik tersembunyi di balik login, dan dirender dengan clustering serta fitur UI yang keren sehingga sudah lambat bahkan pada koneksi yang baik. Jadi mengecek status atau melaporkan pemadaman pun memakan waktu cukup lama.
    Kita juga bisa menelepon perusahaan listrik, tetapi mereka memilih navigasi suara untuk menunya, bukan nada keypad, dan sistemnya tidak mengenali dengan baik suara yang terdistorsi oleh koneksi 4G atau 2G yang buruk.
  • Situasi seperti ini membuat saya berpikir untuk mengambil lagi lisensi radio amatir. Dalam kondisi seperti bencana yang melanda bukan hanya Asheville, tetapi wilayah Western NC yang jauh lebih luas, saya tidak ingin bergantung pada sistem berbasis internet.
    Kita butuh panjang gelombang yang panjang dan daya rendah. Namun aksesibilitasnya sangat rendah, dan saya tidak yakin apakah itu karena alasan yang masuk akal.
    Koneksi terputus dari Black Mountain sampai perbatasan Tennessee dan Georgia. Saya ragu banyak orang bisa kembali mendapatkan 3G yang buruk sekalipun. Yang saya tahu, sulit mempertahankan kontak dengan orang-orang yang tinggal di sana.
  • Ada tautan ke situs berita khusus teks itu?
  • Saya sudah lama memakai segala macam koneksi internet buruk, jadi saya terbiasa dengan situasi seperti ini. Terlalu banyak bagian internet dirancang dengan asumsi komputer cepat, internet cepat, dan monitor bagus.
    Sebagian pekerjaan terbaik yang pernah saya lakukan saya kerjakan di MacBook 12 inci yang terhubung ke Wi-Fi hotel yang tidak stabil. Karena itu saya sangat memperhatikan kecepatan halaman.
  • Saya tinggal di Sylva, sekitar 45 menit dari Asheville, dan sangat buruk untuk mendapatkan informasi berguna di ponsel melalui layanan seluler. Kalau tidak ada Starlink, setidaknya selama seminggu saya tidak akan tahu apa-apa tentang banyak hal.
    Jika harus merangkum penderitaan bencana ini dalam satu kalimat, itu adalah runtuhnya komunikasi dalam segala bentuk.

• Saya sangat sepakat dengan pernyataan, “Web bukan hanya milik para insinyur perangkat lunak. Semakin kita membuat web menjadi rumit, semakin kita mendorong pengguna umum masuk ke dalam pagar yang kita sebut jejaring sosial.”
  Ada juga podcast terkait konferensi terbaru Squiggle Conf tempat kutipan ini muncul: https://changelog.com/jsparty/339

• Seiring waktu, fitur yang diharapkan orang dari “situs web dasar” meningkat pesat
  Bahkan saya yang programmer pun beberapa kali terjebak dalam perangkap static site generator
  Menyebalkan ketika memulai side project dengan static site generator, lalu saat ingin menambahkan fitur kecil, akhirnya menyesal dan berpikir seharusnya dari awal pakai aplikasi Rails atau PHP sederhana saja
  Sekarang kalau butuh situs statis, saya mulai saja dengan folder berisi file HTML. Jalan dari ide ke eksekusi jadi jauh lebih tidak rumit dan lebih cepat, tanpa berdebat di atas kertas soal tool atau menunda-nunda
  Saya cukup puas menulis HTML dan CSS secara langsung, tapi tidak akan merekomendasikannya untuk semua orang
  Hal keren lainnya adalah jika nanti memutuskan untuk “kabur” ke Rails, tinggal salin folder file HTML itu ke folder public/ milik Rails. Jalur upgrade-nya cukup mudah

  • Mungkin saja Anda belum menemukan static site generator yang cocok dengan kebutuhan
    Di sisi Ruby, Jekyll adalah yang paling terkenal, tetapi ia disesuaikan untuk use case spesifik menulis blog dengan Markdown atau bahasa markup ringan lainnya. Bisa dipaksa untuk keperluan lain, tetapi sebagai static site generator serbaguna tidak terlalu nyaman
    Jika ingin sesuatu yang mudah disalin/ditempel ke Rails, middleman, static site generator berbasis Rack, cocok. Anda bisa menulis dengan erb/haml dan ActiveSupport sejak awal
    Jika ingin mempertahankan kesederhanaan menulis HTML dan CSS dengan tangan sambil hanya mendapat fitur praktis seperti include, partial template, dan link helper, nanoc lumayan sebagai static site generator yang bertahap. Mulai dari HTML/CSS biasa, lalu tambahkan fitur hanya saat dibutuhkan
  • Memang sulit berdiskusi tanpa contoh. Saya mulai memakai Pelican lebih dari 10 tahun lalu dan masih puas
    Sesekali saya menulis kode untuk mengustomisasi perilakunya, tetapi hanya kira-kira beberapa tahun sekali. Sederhana dan berjalan dengan baik
    Ada hal-hal dari situs dinamis yang saya rindukan, tetapi saya tidak yakin folder berisi file HTML sederhana lebih baik daripada Pelican dalam hal apa
  • Saya sudah menulis di situs web pribadi selama lebih dari 20 tahun, dan alurnya kira-kira HTML dasar → Drupal → WordPress → HTML dasar lewat Jekyll
    Aturan dasar yang saya buat untuk mencegah pembengkakan fitur situs web adalah menentukan identitas yang saya inginkan. Saya ingin menjadikannya arsip dari hal-hal yang pernah saya lakukan, dan kalau arsip, ia harus bertahan sangat lama seiring waktu. Karena itu file statis yang mudah disalin, di-mirror, dan dijalankan di platform hosting apa pun adalah pilihan yang tepat
    Butuh waktu untuk membereskan situs multibahasa dengan benar, tetapi setidaknya itu biaya yang hanya dibayar sekali
  • Untuk blog saya memakai Hugo. Alasannya, lebih mudah fokus pada konten, bukan gaya. Itu juga alasan saya tidak suka menulis file HTML murni
    Perubahan gaya juga bisa jadi masalah jika di-hardcode di file HTML
    Pekerjaan yang lebih canggih saya tulis dengan Django. Bagi saya sangat mudah menambahkan fitur
  • Saya juga sekarang kalau butuh situs statis mulai dengan folder file HTML. Saya sempat mempertimbangkan menambahkan tahap .md → .html untuk konten, tetapi sejauh ini belum perlu
    Saya juga suka karena situsnya mudah dilihat lewat server lokal. Yang terbaik tentu kalau bisa dilihat juga lewat file://, tetapi saya belum sepenuhnya menyelesaikan strukturnya, jadi akhirnya memakai tahap make local yang membuat salinan terpisah untuk tampilan berbasis file

• Ada faktor yang membuat situs web pribadi milik web developer menjadi rumit: pengembangan yang digerakkan oleh CV
  Ada profesional yang ingin memakai side project pribadi untuk pengembangan yang digerakkan oleh CV, dan mereka berpikir dengan begitu kemungkinan merusak proyek pemberi kerja jadi lebih kecil
  Misalnya, baru pagi ini ada situs web independen yang sebentar lagi akan saya publikasikan; terutama karena alasan CV, situs itu memakai framework web modern yang populer, tetapi sekarang saya tidak bisa lagi memperbarui situsnya
  Salah satu paket NPM punya masalah keamanan kritis, dan ketika saya mencoba memperbaruinya, NPM tersangkut konflik dependensi timbal-balik yang tidak bisa diselesaikan otomatis. Ironisnya, karena itu saya tidak bisa mendorong pembaruan keamanan ke situs produksi
  Situs itu sebenarnya mungkin cukup dengan 5 file HTML yang ditulis tangan, sedikit JS inline, dan 2 skrip Perl CGI kecil. Kalau begitu, 25 tahun kemudian pun mungkin masih berjalan sempurna
  Sebaliknya, bagian NodeJS-nya saja punya 129 paket NPM, pembaruan keamanan yang sering diperlukan, potongan template dan konfigurasi TS, serta pohon file sumber yang sulit dipahami berisi handler
  Namun para profesional tidak punya kemewahan untuk tidak melakukannya dengan cara yang keterlaluan rumit. Misalnya, jika ada Perl di CV, itu pukulan telak bagi peluang kerja. Bahkan orang-orang yang tidak membuang CV Anda karena diskriminasi usia pun akan menganggap Anda bodoh karena tidak melakukan pengembangan yang digerakkan oleh CV

  • Saya rasa arusnya sedang berubah ketika orang mulai menyadari kerapuhan kompleksitas
  • Saya bekerja bolak-balik antara web dan sistem terdistribusi, tetapi untungnya situs PHP membosankan yang membaca konten dari file XML dan JSON belum pernah menghambat saya saat pindah kerja
  • Benar-benar sudah mencobanya? Dan kalau menurut Anda tidak membantu, Anda tidak perlu memasukkan semua yang pernah Anda lakukan ke CV
  • 5 HTML yang ditulis tangan, sedikit JS inline, dan 2 Perl CGI mungkin bisa berjalan sempurna selama 25 tahun, tetapi demi kenyamanan, bisa saja pilihannya ada di suatu titik di tengah
    Dalam kasus saya, saya sama sekali tidak tertarik pada CV atau proposal, tetapi tetap menginginkan sesuatu yang lebih ergonomis daripada memuntahkan HTML dari template JS/Python. Jadi situs-situs saya memakai kombinasi TypeScript, Mithril, Express, dan beberapa library utilitas
    Saya tidak tahu ada berapa paket dan tidak peduli. Yang penting hal-hal yang saya impor umumnya matang dan tidak melahirkan fitur-kerentanan baru setiap beberapa menit
    Anda tidak menyebutkan stack-nya, tetapi tampaknya besar kemungkinan itu React dan ekosistemnya yang “selalu membaik tetapi tidak pernah selesai.” Kalau boleh memberi saran yang tidak diminta, sebaiknya jangan percaya pada dikotomi palsu. Ada ruang besar di antara HTML murni dan kubangan terburuk, dan keadaan di dunia React itu spesifik untuk React, bukan mewakili dunia di luarnya

• Killer app WordPress adalah komentar. Generator situs statis hampir menurut definisi tidak mengizinkan komentar, tetapi blog WordPress hampir selalu memilikinya secara bawaan.
  Kalau sesuatu seperti Hugo benar-benar ingin naik daun di ranah blog, cukup buat tema yang bagus dilihat dengan komentar. Selesaikan dalam skala besar. Misalnya, pihak ketiga bisa meng-hosting-nya dengan sangat murah memakai SQLite yang di-shard per blog. Itu akan menjadi angsa kecil bertelur emas.

  • Itu benar pada era blog, tetapi menurut saya sekarang jauh kurang berlaku.
    Komentar dan diskusi tentang tulisan ada di komunitas pihak ketiga seperti Reddit, HN, dan Facebook. Mana yang lebih banyak: orang yang menelusuri daftar komentar di bawah tulisan Substack, atau orang yang membaca satu-dua halaman komentar HN tentang tulisan yang sama?
    Untuk tulisan teknis, hampir sudah pasti diskusi HN akan lebih berkualitas daripada rantai komentar pada tulisan tertentu. Karena HN sudah menarik audiens yang lebih luas daripada 99,9% dari seluruh blog.
    Keuntungan utama berkomentar langsung di tulisan blog hanyalah kemungkinan penulisnya melihatnya jauh lebih besar. Status sempat muncul di halaman depan HN itu cepat berlalu.
  • Hacker News dan para “programmer sejati” terus meremehkan konsep dasar CMS. Karena menganggapnya teknologi yang tidak seksi, mereka menganggap semua masalah di sekitarnya sebagai masalah membosankan yang sudah terselesaikan, sehingga tidak benar-benar tahu apa masalah nyatanya.
    Ekosistem WordPress justru kebalikannya. Ia berisi bisnis-bisnis bernilai miliaran dolar yang sangat memahami apa yang dibutuhkan orang-orang yang mengoperasikan CMS dan situs web di celah pasar kecil masing-masing, dan ukuran pasar ini kira-kira 500 juta situs web.
    Orang yang menulis artikel ini mungkin pintar, tetapi jelas tidak pintar soal penggunaan praktis CMS. Pandangan dunia bahwa “situs HTML statis lebih baik, tetapi tidak populer karena perusahaan-perusahaan jahat” akan terlihat hampir sepenuhnya salah setelah Anda sekali-dua kali membuat situs web berbayar.
    Generator situs HTML statis hampir tidak mungkin menyediakan semua hal yang diinginkan klien. WordPress sudah lama menyadari betapa luas dan beragamnya pasar ini, sehingga mengimplementasikan dukungan plugin.
    Saya 100% setuju bahwa komentar adalah salah satu penggunaan awal di web untuk memakai sesuatu yang lebih dekat ke CMS alih-alih generator situs statis. Namun selain itu ada sejuta kegunaan lain.
    Dokumen HTML statis saja tidak akan membawa Anda terlalu jauh. Begitu keluar dari blog developer minimalis, Anda butuh banyak logika program untuk melakukan hal-hal yang diinginkan pengguna dan klien nyata. Jadi pakailah CMS yang sesuai kebutuhan, lalu cache secara agresif agar tahan terhadap trafik besar. Itu juga bagian dari pekerjaan.
    Saya sama sekali tidak mengerti kenapa developer yang merasa dirinya hebat ingin menciptakan ulang roda, alih-alih belajar sedikit tentang cara kerja caching dan menerapkannya. Apakah ini juga terlalu membosankan sebagai “masalah yang sudah terselesaikan”?
  • Killer app WordPress bukan komentar, melainkan ekosistem plugin. Ada plugin yang di WordPress bahkan bisa dinyalakan ibu Anda dengan dua klik, sementara di Hugo Anda akan menghabiskan seluruh akhir pekan untuk mengonfigurasinya.
    Saya juga memakai Hugo, tetapi meski dari sudut pandang engineering jejaknya tidak perlu sebesar itu, pengalaman pengguna WordPress jauh lebih ramah.
  • Unsur “interaksi” lain adalah formulir kontak.
    Tidak semua situs bisnis menginginkan komentar, tetapi kemungkinan besar mereka menginginkan formulir kontak. Membuka alamat email juga alternatif, tetapi lebih baik menangani pipeline input.
    Pada situs statis, Anda harus mencari layanan tepercaya untuk menangani pengiriman dan memasangnya dengan benar ke situs. Ada satu komponen bergerak lagi, bisa menjadi tagihan terpisah, dan menjadi satu hal tambahan yang harus ditangani ketika industri berkonsolidasi.
  • Disqus sempat menyelesaikan ini untuk beberapa waktu, tetapi selama bertahun-tahun mereka melakukan hal-hal yang membuat orang menjauh: https://en.wikipedia.org/wiki/Disqus#Criticism,_privacy,_and...
    https://hn.algolia.com/?q=%22disqus%22
    Facebook juga menyediakan sistem komentar yang dipakai banyak situs, tetapi kehilangan kepercayaan dan jangkauan akibat berbagai skandal.

• Saya juga cocok dengan paradoks itu. Saya menulis ulang situs web pribadi saya dengan PHP modern, tanpa framework atau database.
  Sebagian besar adalah situs statis, tetapi saya memakai PHP untuk menempelkan header dan menangani daftar seperti daftar tulisan blog. Rasanya sedikit lebih nyaman jika tidak sepenuhnya statis. Saya menulis artikel, commit, push, lalu langsung online. Kebanyakan generator situs statis terasa terlalu rumit.
  Kode untuk satu halaman kira-kira seperti title = "Blog Article Title";, $this->shortTitle = "Title";, $this->date = mktime(0,0,0,1,27,2024);, if ($this->mode == PageMode::Meta) return;, lalu diikuti konten HTML mentah.
  Router otomatis menempelkan header dan footer situs, dan jika menambahkan file _layout.php ke sebuah folder, saya bisa menempelkan satu tingkat layout lagi ke halaman-halaman turunannya. Halaman daftar blog menelusuri file artikel individual di dalam folder untuk membuat indeks.
  Di sinilah $this->mode == PageMode::Meta dipakai. Ia menjalankan kode tiap file untuk mendapatkan metadata, lalu keluar sebelum merender sisanya. Kalau kontennya bertambah banyak, skalabilitasnya mungkin tidak bagus, tetapi kalau jadi masalah saya akan menyesuaikannya.
  Seluruh kode PHP “framework” saya hanya empat file: init.php, functions.php, Layout.php, Page.php.
  Keunggulan developer adalah bisa memakai kode alih-alih konfigurasi atau data. Kode juga bisa dipakai untuk menulis konten dengan lebih efisien.
  Hasilnya masih cukup belum selesai, tetapi ada di sini: https://www.codaris.com/

  • Salah satu situs web saya juga baru saja dimulai dengan cara yang sama. 90%-nya HTML, dan hanya header serta beberapa potongan global yang ditangani dengan include() di PHP.

• Jika memikirkan pengalaman pengguna dari sudut pandang pemilik situs web, ini tidak terlalu paradoks. WordPress membuat pekerjaan jadi luar biasa mudah, meskipun overhead-nya jauh lebih besar
  Ini hanya terlihat seperti paradoks jika dianggap sebagai trade-off dengan menghabiskan waktu untuk mengatur ini-itu. Bagi kebanyakan orang, alternatifnya adalah membayar seseorang untuk membuatkan situs web
  Kalau Anda membuat editor WYSIWYG untuk Hugo dan membuat proses dari pendaftaran domain hingga publikasi situs selesai hanya dengan beberapa klik, Anda bisa menghasilkan banyak uang

  • Bukankah itu yang dilakukan perusahaan seperti Netlify, Squarespace, dan GitHub Pages? Di Netlify, Anda bisa memindahkan domain yang diparkir, memilih template, lalu sebagian besar pengaturan ditangani sehingga situs naik dalam beberapa menit; penanganan domain memakan waktu sekitar 24 jam
    Saya paham maksudnya. Meski perusahaan-perusahaan seperti itu sudah mendekati apa yang disebutkan, jika ada yang bisa menangani langkah-langkah kecil di antaranya, itu akan menjadi keuntungan besar bagi seseorang
  • Bukankah barusan Anda mendeskripsikan Micro.blog[1]?
    [1] https://micro.blog

• Bagian “Saat merilis SuperHTML, saya tahu bahwa ini adalah language server pertama untuk HTML yang melaporkan diagnostik kepada pengguna. Saya menulis posting blog dan itu masuk halaman depan Hacker News, dan karena tidak ada yang mengoreksi saya, berarti itu benar” mungkin karena kebanyakan IDE sudah melakukan hal itu selama bertahun-tahun bahkan sebelum Microsoft memperkenalkan LSP

  • Saya rasa hampir tidak ada editor populer yang punya cara untuk menyediakan diagnostik bagi HTML murni. Satu-satunya pengecualian yang saya tahu adalah WebStorm
    Vim, Neovim, Helix, Zed, dan VSCode semuanya berbagi implementasi dasar yang sama tanpa dukungan diagnostik
    Helix akan mengaktifkan SuperHTML secara default mulai rilis berikutnya: https://github.com/helix-editor/helix/pull/11609