Membangun situs web tanpa framework dan banyak library

 (kodingkitty.com)
3 poin oleh GN⁺ 2023-07-05 | 1 komentar | Bagikan ke WhatsApp
  • Koding Kitty menerapkan stack berbasis HTML statis untuk situs web perusahaan kecil, sehingga dapat menjalankan halaman yang dibutuhkan dan blog tanpa CMS besar atau framework
  • Kriteria pemilihannya adalah kecepatan, kemudahan pengembangan, hosting murah, dan kompleksitas rendah, dan WordPress, no-code, framework, serta Jamstack dianggap memiliki beban konfigurasi dan pembelajaran yang terlalu besar dibanding kebutuhan
  • Konten ditulis langsung dalam HTML alih-alih memakai Markdown atau editor visual, sehingga lebih mudah menangani susunan posting yang mencampurkan teks dengan widget HTML/CSS/JS
  • Struktur berulang dan blok umum ditangani dengan template Jinja, sementara skrip Python 45 baris menghubungkan deteksi perubahan, rendering HTML, dan pemanggilan Tailwind CSS CLI
  • Karena berupa situs statis, hosting murah sudah memadai, dan web hosting Hetzner mulai dari 2 EUR serta mampu menahan lonjakan trafik hingga level masuk halaman depan Hacker News

Alasan memilih stack yang sederhana

  • Stack teknologi situs web Koding Kitty disusun secara sengaja agar sederhana sesuai kebutuhan nyata, alih-alih mengikuti tren terbaru pengembangan web ringan
  • Tujuannya adalah konfigurasi dengan friksi rendah bagi pengembang, dan mereka menilai solusi sederhana bisa lebih baik bagi klien dibanding kombinasi framework dan library yang kompleks
  • Desain yang unik tetapi tidak berlebihan sebenarnya bisa dibuat dengan berbagai cara, namun konfigurasi saat ini adalah pilihan yang disesuaikan dengan cakupan kebutuhan

Kebutuhan dan kriteria awal

  • Sejak awal diputuskan untuk membuatnya sebagai situs web statis
  • Fitur yang dibutuhkan hanya halaman depan, showcase, dan blog, tidak lebih dari itu
  • Ada empat kriteria
    • situs web yang cepat
    • pengembangan yang cepat
    • hosting yang murah
    • kompleksitas minimum

Opsi yang dipertimbangkan tetapi tidak dipilih

  • WordPress dan CMS sejenis

    • Mereka mengakui bahwa WordPress telah memainkan peran besar di internet
    • Namun, itu terasa berlebihan untuk kebutuhan yang sederhana
    • Tidak perlu menyimpan konten di database, dan juga tidak memerlukan plugin atau editor visual

  • Alat no-code

    • Menggunakan alat no-code terasa canggung bagi seorang pembuat web yang memang bisa coding
    • Mereka ingin memiliki konten secara langsung dan menangani situs web sesuka mereka
    • Mereka menganggap membangun lewat coding lebih cepat daripada editor WYSIWYG no-code
    • Beban pembelajaran awal dan pembelajaran berkelanjutan juga tetap menjadi pertimbangan

  • Framework

    • Mereka punya pengalaman dengan framework, tetapi tidak ingin membawa seluruh konfigurasi bawaannya
    • Komponen seperti database, konfigurasi, library, dan fitur admin bisa menjadi terlalu banyak
    • Walaupun bisa dikustomisasi sepenuhnya, mereka menilai hasil akhirnya bisa saja menjadi bentuk yang mirip WordPress

  • Jamstack dan static site generator

    • Static site generator tampak seperti opsi yang sangat cocok dengan kebutuhan
    • Setelah memilih bahasa dan menulis kode, situs statis cepat bisa dibuat lewat tombol atau skrip
    • Namun tetap diperlukan konfigurasi awal serta pembelajaran awal dan berkelanjutan
    • Mereka mengakui kemudahan menulis blog dengan Markdown, tetapi secara keseluruhan memilih solusi yang lebih sederhana

Susunan KittyStack

  • Konfigurasi Koding Kitty disusun berdasarkan empat kebutuhan utama

  • Situs web yang cepat

    • Situs web statis berjalan dengan cepat

  • Pengembangan yang cepat

    • Konten ditulis dalam HTML, bukan Markdown atau editor canggih
    • Karena posting Koding Kitty mencampurkan teks dengan widget HTML/CSS/JS, menulis langsung dalam HTML dianggap paling cocok

  • Hosting yang murah

    • Biaya hosting situs statis berbeda-beda tergantung penyedia dan fitur tambahan yang dibutuhkan
    • Situs statis tidak membutuhkan konfigurasi perangkat keras berskala besar, sehingga bisa memilih paket minimum
    • Hetzner webhosting mulai dari 2 EUR
    • Situs Koding Kitty mampu bertahan dari lonjakan trafik setingkat masuk halaman depan Hacker News

  • Kompleksitas minimum

    • Beberapa halaman dan posting memiliki pola yang berulang
    • Itu memang bisa dilakukan dengan salin-tempel, tetapi lama-kelamaan bisa sulit dikendalikan
    • Mereka membutuhkan loop serta fitur penyertaan blok kode seperti header dan footer

Jinja dan alur build

  • Struktur berulang dan penyertaan file umum ditangani dengan template Jinja
  • Jinja menyediakan loop, penyertaan file seperti navigation bar dan footer, serta fitur template lainnya
  • Tim tersebut pernah menggunakan framework berbasis Jinja di masa lalu, jadi tidak perlu mempelajari sistem baru

Rangkaian alat yang sederhana

  • Halaman statis akhir dihasilkan dengan skrip Python 45 baris
    • Jumlah itu termasuk komentar dan baris kosong
  • Alur build-nya seperti ini
    • Pengembang mengedit index.src.html
    • Watchdog.py mendeteksi perubahan file
    • Template Jinja dirender menjadi index.html
    • Tailwind CSS CLI dipanggil untuk menghasilkan styles.min.css
  • Saat pengembangan, Live Server menyajikan file dan memuat ulang saat ada perubahan
  • Pada saat deployment, file diunggah secara manual lewat FTP

Keuntungan pengembangan web yang lebih tidak rumit

  • Pengembangan web bisa tetap sederhana tanpa harus mengorbankan terlalu banyak hal
  • Membatasi pilihan ke beberapa opsi justru bisa terasa lebih membebaskan
  • Bagi banyak klien, solusi yang lebih cepat, lebih sederhana, dan lebih murah bisa lebih membantu
  • Perlu meninjau ekosistem web secara luas untuk menilai apakah hasil yang sama bisa dicapai dengan stack teknologi yang lebih tidak rumit

Bacaan terkait

1 komentar

 
GN⁺ 2023-07-05
Opini Hacker News

  • Portofolio fotografi saya juga akhirnya memakai pendekatan yang sama. Setelah beralih dari pengembangan ke fotografi, keuntungannya adalah tidak perlu bergantung pada Squarespace seperti fotografer lain
    Setelah mencoba opsi berbasis server yang dibuat dengan Ghost, Statamic, Phoenix/Vapor, serta beberapa generator situs statis umum, akhirnya saya menulis HTML murni tanpa templat dan mengunggahnya ke server Hetzner dengan rsync
    Tidak adanya templat untuk UI umum seperti navigasi memang agak mengganggu, tetapi sejauh ini belum ada perubahan yang butuh lebih dari beberapa menit dengan regex, dan ketika di awal regex yang terlalu rakus sempat menghapus konten, git menyelamatkannya
    Membuat variasi ukuran dan format gambar memang merepotkan, tetapi itu mendorong saya mencoba tata letak baru tanpa bergantung pada layout kaku seperti Ghost. Selain itu, saat mengekspor gambar untuk web dari editor RAW Capture One, kualitasnya tampak sedikit lebih baik daripada library atau alat CLI yang dipakai kebanyakan generator situs statis
    Memang lambat, tetapi menurut saya ini lebih mirip membuat buku foto. Di awal memang butuh lebih banyak kerja manual, tetapi setelah selesai ya selesai, dan selama 20 tahun ke depan tidak perlu berpindah-pindah CMS lalu merusaknya

    • Navigasi dasar sebelumnya/berikutnya serta menu, header, dan footer yang konsisten bisa ditangani dengan server-side include
    • Situs fotografi pribadi saya memakai Svelte + TailwindCSS, Flickr API, dan Netlify
      Strukturnya pada dasarnya beberapa file HTML dengan kekuatan templat; foto diambil dari album khusus untuk situs ini lewat Flickr API, dan Netlify otomatis melakukan deploy hanya dengan git push
      Total biayanya, termasuk hosting, 0 dolar, dan foto bisa dikelola dari ponsel lewat aplikasi Flickr. Berkat Netlify, saya juga senang karena tidak perlu menyentuh boks server sungguhan
    • Saya penasaran bagaimana pengalaman memakai Vapor
      Cara yang saya pakai baru-baru ini mungkin juga berguna (https://news.ycombinator.com/item?id=36592641). Menggunakan Google Sheet sebagai sumber data itu mudah, dan seharusnya sama saja jika diganti menjadi sistem file foto
    • Saya memang sedang ingin lepas dari Smugmug dan mencoba pendekatan seperti ini; apakah Anda bisa membagikan portofolio atau source-nya?

  • Ini tampaknya bukan “sederhana (simple)”, melainkan lebih dekat ke hanya tampak sederhana (simplistic). Jika tidak melakukan apa-apa dan memotong banyak sudut, memang bisa membuat situs web yang relatif sederhana
    Ambil saja dark mode, yang hampir menjadi satu-satunya fitur non-sepele di halaman ini: ia ditangani dengan JS yang dimuat terlambat, sehingga setiap kali halaman dimuat muncul kedipan layar putih yang tak terhindarkan. Agar benar, seharusnya memakai pendekatan kelas CSS pada body, dan solusi yang tidak berfungsi tidak ada artinya, entah sederhana ataupun kompleks
    Selain itu, membawa seluruh interpreter ‘hyperscript’ kustom seperti https://hyperscript.org/ hanya untuk 3 baris JS semacam localStorage dan pengaturan dark mode bertentangan dengan gagasan “kesederhanaan adalah penyempurnaan tertinggi”. Memuat library 96KB yang belum tercache hanya untuk tujuan itu terasa aneh, dan saya juga bertanya-tanya apakah itu penyebab HTML-nya tidak lolos validasi
    Terakhir, toggle biner adalah implementasi dark mode yang buruk karena mengabaikan pengaturan sistem/browser. Bahkan jika dark mode dinyalakan di OS ponsel, situs tetap tampil light mode sampai pengguna menyalakannya sendiri, dan ia juga tidak menghormati pengaturan sistem yang berubah berdasarkan waktu atau cahaya sekitar. localStorage bisa kedaluwarsa dan perangkat juga bisa berganti, sehingga pengguna harus mengaturnya berulang kali; kemungkinan besar pengguna tidak akan setuju dengan implementasi yang oleh pengembang disebut ‘sederhana’ itu

    • Jika tujuannya adalah situs web yang sesederhana mungkin, dark mode itu sendiri seharusnya tidak ada. Pada tahun 90-an pun sudah ada situs web yang sederhana dan enak dibaca, dan sebelum tren dark mode, light mode saja sudah cukup
      Jika mulai mempertimbangkan pengaturan sistem/browser, pergantian berdasarkan zona waktu, cahaya sekitar, dan semacamnya, kompleksitasnya makin besar dan bertabrakan dengan filosofi situs web sederhana. Lebih baik hilangkan saja dark mode; HN juga selalu light mode, tetapi tidak terlalu bermasalah untuk dibaca pada malam hari
    • Saya setuju bahwa pendekatan JS yang dimuat terlambat itu keliru, tetapi pendekatan media query juga rumit
      Biasanya kita ingin menghormati prefers-color-scheme sekaligus menyediakan toggle, dan jika pengguna sebelumnya memilih langsung di situs, kita ingin memprioritaskan pilihan itu. Maka tetap saja perlu JS dan localStorage
      Cara yang saya sukai adalah memasukkan body {visibility: hidden; opacity: 0;} sebagai gaya inline. Halaman sebelumnya dipertahankan, lalu pada saat DOMContentLoaded, prefers-color-scheme dan localStorage diperiksa, kelas body diatur dengan benar, baru halaman dirender
    • Saat membaca saya sempat berpikir “analisis yang bagus”, lalu melihat penulisnya dan langsung paham. Untuk OP, ini adalah penulis https://gwern.net, dan situs tersebut sangat memengaruhi desain banyak blog teknis dan situs pribadi, dengan banyak ide orisinal dan bagus
      Situs saya menghormati tema light/dark melalui CSS dan tidak memiliki toggle manual. Saya punya tujuan pribadi membuat situs HTML/CSS murni tanpa JS, dan menurut saya pengaturan light/dark harus menghormati preferensi pengguna. Jika perlu toggle, seharusnya itu ada di pengaturan toolbar browser, bukan di dalam situs
      Jika /u/gwern membaca ini, situs saya https://daveon.design/ dipengaruhi oleh desain gwern dan Tufte.css. Ada juga campuran publikasi lama, manuskrip, dan selera pribadi, tetapi contoh utama yang pertama kali memberi saya inspirasi tentang seperti apa situs web pribadi yang modern dan rapi bisa terlihat serta apa yang bisa dimuatnya adalah gwern
    • Di Firefox, Chrome, Safari pada Mac serta Firefox dan Chrome pada Android, saya tidak melihat kedipan layar putih. Pemuatan pertama, refresh, maupun pergantian dark/light semuanya tampaknya berjalan baik-baik saja
    • Itu poin yang tepat. Sayangnya, pola pikir yang rusak tetapi tampak sederhana juga sama tersebar luasnya dengan pendekatan yang rusak dan bloat

  • Kalau harus disebutkan, saat ini SvelteKit + Skeleton benar-benar mengesankan dari sisi kecepatan membuat prototipe yang layak pakai
    Meski tidak benar-benar menguasai Svelte, selama paham routing berbasis file, sisanya hampir seperti HTML sampai benar-benar dibutuhkan; Tailwind sudah tersedia secara default, dan temanya juga pada umumnya cukup dekat dengan vanilla
    Dalam beberapa bulan terakhir saya mencoba berbagai hal seperti Astro, Lit, Next.js, template bawaan Go, pug, Eleventy, dan sejauh ini kombinasi ini yang paling saya sukai di hampir semua aspek

    • SvelteKit memang bagus, tapi saya sulit setuju soal Skeleton. Awalnya terasa produktif dan aman, tetapi banyak jebakannya, dan ketika ada bagian yang tidak disukai, kustomisasinya jadi sulit
      Lihat saja situs Skeleton sendiri https://www.skeleton.dev/docs/get-started: menekan Page Down tidak membuat halaman bergulir, mengarahkan mouse ke bilah navigasi juga tidak memungkinkan scrolling, dan saat dicetak hanya bagian yang terlihat di layar yang terpotong/tercetak. Saya sudah mengangkat masalah ini, tetapi tampaknya belum menjadi prioritas besar, padahal banyak situs memakai pola komponen ini
      Skeleton tampaknya menganggap bahwa membalik warna tema gelap akan menghasilkan tema terang yang bagus, padahal kenyataannya tidak begitu. DaisyUI lebih matang, lebih berkinerja baik, lebih luas dipakai, dan memperlakukan aksesibilitas dengan serius. Kemampuannya melakukan banyak hal hanya dengan animasi CSS tanpa JS juga mengagumkan; ia menyelesaikan bagian HTML/CSS yang sulit sambil membiarkan kita menulis sendiri bagian Svelte yang mudah. Ketergantungannya pada Svelte juga rendah, sehingga HTML DaisyUI mudah dipindahkan ke framework lain
    • Setuju. Memang framework, tetapi mudah menghasilkan situs statis yang tetap bekerja dengan baik meski JS dimatikan, bisa dipakai tanpa tahu Svelte, dan kalau perlu Svelte juga bisa digunakan
      Tailwind langsung berfungsi, dan deployment ke tempat seperti Netlify juga sangat sederhana. Menurut saya, saat ini ini adalah static site builder terbaik, dan jauh lebih sederhana daripada pendekatan yang dijelaskan di artikel
    • Sebagai orang yang menyukai minimalisme, saya sudah mencoba Astro dan SvelteKit; SvelteKit terasa seperti lapisan yang sangat kecil di atas Svelte, yang memang sudah merupakan library komponen yang sangat kecil
      Dengan +page.ts dan konfigurasi yang tepat, kita bisa membuat situs web statis, atau beralih ke aplikasi multi-halaman maupun aplikasi satu halaman
    • Saya tidak banyak melihat contoh bergaya “kalau memasukkan ini, halaman akhirnya akan terlihat seperti ini”. Akan bagus kalau ada contoh yang bisa langsung dilihat sebelum menginstal dan mengikuti langkah-langkahnya
    • Rekomendasi yang bagus. Saya juga ingin mendengar lebih banyak pengalaman dengan framework web lain, dan penasaran apakah Flutter juga sudah dicoba

  • Astaga, membuat situs web dengan HTML dan CSS terdengar seperti tindakan gila
    Selain bercanda, saya memakai stack yang sama kecuali untuk template. Kalau bukan pengembang web, saya tidak begitu paham perlunya framework CSS; membuat sendiri jauh lebih mudah. Saya juga pernah mencoba generator situs Hugo, tetapi sama sekali tidak menghemat waktu
    Beberapa bulan lalu, untuk meningkatkan kemampuan CSS, saya mencoba mereplikasi beberapa situs web perusahaan, dan tampilannya bisa direplikasi sepenuhnya hanya dengan HTML dan CSS. Namun situs web asli perusahaan-perusahaan itu bahkan tidak muncul sama sekali jika JS dimatikan
    Kita terus menumpuk framework di atas framework, bahasa baru, alat baru, dan kebanyakan hanya menambah kompleksitas serta pekerjaan sibuk bagi generasi berikutnya. Situs web 5% yang memang benar-benar membutuhkan hal semacam itu adalah pengecualian
    Menarik juga bahwa itu adalah situs yang menjual layanan nyata, dan saya penasaran kisaran harganya seperti apa

    • Mendesain, lalu menjaga desain itu tetap konsisten, terasa terlalu sulit. Karena itu bagus kalau ada CSS yang sudah didefinisikan sebelumnya; kalau tidak, hasilnya terlihat berantakan
    • Secara umum setuju, tetapi saya pernah memakai Astro dengan cukup sukses

  • Menurut saya, cara yang paling minimal dan produktif adalah cukup memakai PHP. Karena bahasa itu memang dibuat untuk tujuan seperti itu
    Untuk situs sederhana, tidak perlu composer maupun logika router; cukup buat file header/footer/navigation terpisah dan include dari tiap halaman

    • Tanpa library pun, dengan sekitar 100 baris sudah bisa membuat router dan layout. Router hanya mengecek apakah file ada, dan layout cukup include header.php, pagename.php, footer.php. Untuk situs sederhana saya melakukannya seperti ini, dan sangat mudah serta cepat
    • Tidak harus PHP; bahasa scripting sisi server apa pun bisa. Intinya adalah kemampuan memberi nama, menyimpan, dan memuat data serta blok kode agar situs bisa direfaktor
      Jika HTML bisa menyisipkan HTML eksternal seperti CSS atau JS, bahkan hal ini pun sebagian besar tidak diperlukan. Saya hanya berharap itu bisa digunakan dengan bebas
    • Kalau menginginkan kesederhanaan, sulit mengalahkan PHP + HTML. Untuk sesuatu yang lebih besar daripada skrip tujuan tunggal, saya tidak ingin sesederhana itu dan biasanya setidaknya akan memakai library template terpisah, tetapi menyenangkan bahwa itu bisa dilakukan
    • Saya setuju dengan maksudnya, tetapi dengan hanya sekitar 5–20 jam, kita bisa membuat generator situs kustom yang efektif berbasis Eleventy dan men-deploy-nya gratis di Netlify
      Saat ada yang diubah lalu git commit/push, perubahan akan tersebar ke seluruh dunia dalam 30 detik. Cukup hebat, dan tidak perlu hosting server terpisah
    • Ada banyak framework sederhana, tetapi begitu menambahkan beberapa hal lagi, dengan cepat kita kembali ke kegemukan yang umum terjadi

  • Teringat ungkapan “sesederhana mungkin, tetapi jangan lebih sederhana dari itu”. Mungkin bukan kata-kata Albert Einstein
    HTML + CSS murni, dengan CSS dimasukkan ke tiap tag HTML atau di dalam halaman, cukup baik untuk memulai. Begitu halamannya menjadi dua, CSS biasanya dipisahkan ke file tersendiri
    Namun ketika mulai membuat situs dengan beberapa halaman berformat sama, kita akan membutuhkan sistem template dengan include dan generator halaman statis
    Jika halaman berbasis data, kita membutuhkan generator situs yang bisa diprogram untuk menelan data dan memuntahkan halaman; jika datanya “real-time”, halaman harus dibuat untuk tiap view, sehingga setidaknya masuk ke ranah PHP, atau lebih jauh lagi ke ranah framework web modern dengan server yang berjalan
    Baru-baru ini saya membuat situs pro bono terkait hobi. Itu situs promosi tari dan acara, dan pemiliknya adalah guru tari yang tidak terlalu paham teknologi. Saya membuat situs statis di tier gratis Netlify dengan Eleventy(https://www.11ty.dev/), lalu menambahkan kode build kustom yang mengambil data dari Google Sheet agar sang guru bisa mendefinisikan acara mendatang
    Butuh belasan jam untuk membuatnya, tetapi sekarang berjalan baik tanpa biaya operasional/pengelolaan. Saya jadi tahu ada sweet spot yang kuat di antara konfigurasi yang benar-benar minimal dan level Rails/Phoenix/Django

    • Pada akhirnya OP juga memakai dua library: template Jinja dan styling Tailwind. Itu titik tengah yang pas antara HTML/CSS murni dan Django/Phoenix/Rails + Angular/React/Vue
    • Biasanya saya melakukan refactor saat sesuatu muncul dua kali, tetapi saya juga pernah mendengar bahwa untuk DRY, menundanya sampai tiga kali lebih mungkin mencapai titik impas dari sisi usaha
      Namun jumlah halaman sebuah situs hampir pasti lebih dari 3, jadi ini mungkin agak berbeda dari kemungkinan sebuah blok kode umum dipakai 3 kali atau lebih
    • Saya penasaran apakah ini sudah dirilis sebagai open source, atau apakah Anda pernah menemukan proyek serupa
      Saya juga penasaran apakah arsitekturnya memanggil Google Sheets API dari sisi klien untuk mengisi data, dan jika begitu, apakah ada lapisan cache atau tiap klien selalu mengambil salinan baru setiap kali

  • Perdebatan soal framework dan kompleksitas sekarang benar-benar melelahkan
    Jika klien meminta CMS kustom dengan workflow penerbitan bertahap, internasionalisasi, dan aksesibilitas yang patuh regulasi, kita membutuhkan alat yang kuat agar bisa membuatnya dalam waktu yang diharapkan klien. Di enterprise ada banyak klien seperti ini, sehingga permintaan untuk alat semacam ini besar. Jika pengalaman Anda hanya B2C, ini mungkin mengejutkan, tetapi inilah bagian bawah permukaan dari gunung es industri teknologi
    Memang benar blog statis tidak membutuhkan konfigurasi Next.js yang rumit atau toolchain Vite. Namun orang-orang yang membahas alat-alat seperti ini secara serius bukan sedang berbicara tentang membuat situs blog sederhana. Contoh tutorial yang diperkecil mungkin berupa blog, tetapi masalah nyatanya berbeda
    Jadi saya berharap kebencian terhadap framework agak diredakan. Jika ada ide bagus untuk membuat situs web secara sederhana, publikasikan saja tutorialnya; jika menarik, orang akan memakai pendekatan itu di tempat yang sesuai. Namun sebaiknya hindari cara berargumen dengan membangun musuh samar bernama “toolchain pedas dan framework tren” lalu menentangnya

    • Banyak orang yang ikut percakapan ini belum pernah menangani langsung masalah yang membuat alat-alat semacam ini berguna. Mereka mungkin engineer, tetapi tidak menyentuh frontend sehingga tidak tahu lebih dari dasar-dasarnya, atau mahasiswa CS yang pernah membuat blog pribadi dengan Jekyll lalu merasa sudah tahu seluruh pengembangan frontend
      Atau mereka mungkin merasa tahu semuanya hanya karena lama membuat aplikasi bisnis internal dengan jumlah pengguna dua digit dan tanpa kebutuhan UX. Penilaian rendah informasi seperti ini mendorong arah diskusi
    • Jika melakukan hal yang kompleks tanpa memakai framework, pada akhirnya kita akan membuat framework lain sendiri
      Bedanya, kali ini orang yang mewarisi kode itu tidak akan mendapat update dan sulit mencari bantuan di Stack Overflow
    • Setuju. Bahkan dari posisi yang tidak menyukai kompleksitas yang dibawa framework
      Saya tidak mengerti mengapa orang merasa tidak boleh memakai alat yang berbeda untuk pekerjaan yang berbeda. Ada saat-saat framework tidak diperlukan, tetapi menurut pengalaman saya itu jarang, kecuali kita membuat sesuatu yang sangat sederhana dan tidak sering berubah
      Sulit bagi saya membayangkan bagaimana situs dengan “alat sederhana” akan berjalan dalam situasi yang melibatkan tim dan klien, dan itu bukan celaan; saya benar-benar tidak tahu

  • Pendekatan ini pun sudah terdengar terlalu rumit bagi saya
    Saya menulis artikel dalam Gemtext, yaitu Markdown untuk Gemini, lalu membuat skrip Python yang mengubahnya ke HTML dan membuat halaman indeks
    CSS-nya hanya 42 baris, jadi saya masukkan ke tiap halaman, dan saya juga menghitung bahwa biaya tambahan 42 baris per file tidak akan pernah lebih besar daripada request HTTP kedua
    Tanpa library Python atau template, hasilnya jauh lebih sederhana dari yang saya perkirakan. Bagian paling sulit adalah membuat email untuk dikirim ke mailing list. Saya menghabiskan beberapa bulan menganalisis berbagai framework dan generator situs statis, serta beberapa minggu mencari CSS yang bagus
    Menurut riwayat git, termasuk mengimpor riwayat WordPress selama 18 tahun, semuanya selesai setelah 2 minggu mengutak-atik. Karena Python murni, tidak ada hal baru yang perlu dipelajari, dan jika ada bug, mudah diperbaiki atau diganti. Karena itu kode saya sendiri
    Ilmuwan komputer sudah benar-benar lupa bahwa kita bisa saja mengodekan solusi ad hoc yang disesuaikan alih-alih berusaha memakai ulang semuanya. Waktu untuk belajar dan menyesuaikan sering lebih besar daripada waktu membuat sendiri
    Kode: https://git.sr.ht/~lioploum/ploum.net
    Situs: https://ploum.net

    • Email? Skrip Python? Git? Ini mesin Rube Goldberg yang hebat
      Situs saya disajikan dari prosesor 6502 yang pada 2003 saya pahat dari kayu balsa dan saya rekatkan ke kabel Ethernet dengan epoksi. Saat ingin mengubahnya, saya memanaskan EPROM dengan pengering rambut agar bit yang saya inginkan terbalik. Tidak ada template, tidak ada kode, tidak ada bloat
    • Blog yang bagus sekali. Saya membukanya hanya untuk melihat desain, lalu tanpa sadar membaca 4 tulisan berturut-turut
      Rasanya seperti menelusuri sejarah teknologi saat menggulir ke bawah, benar-benar membangkitkan nostalgia

  • Kalau saya tidak salah paham, ini tidak terlihat jauh berbeda dari static site generator rata-rata. Kelihatannya seperti perbedaan antara membuat file HTML dengan template Jinja berbasis Python dan Jekyll yang membuat file HTML/Markdown dengan template Liquid berbasis Ruby

    • Ini dibuat sendiri alih-alih memakai framework siap pakai. Dan itu tidak masalah. Membuat sesuatu itu menyenangkan
    • Saya juga berpikir begitu. Kalau tujuannya adalah kesederhanaan, membuat generator kustom sendiri alih-alih memakai static site generator yang sudah ada terlihat seperti pilihan yang aneh
      Menurut saya situs PHP untuk include atau static site generator siap pakai jauh lebih masuk akal

  • Saya tidak paham. Karena tidak ingin static site generator, pada akhirnya malah menulis static site generator sendiri