3 poin oleh GN⁺ 2023-10-23 | 1 komentar | Bagikan ke WhatsApp
  • Jika situs web pribadi dibuat sebagai satu binary, satu orang dapat memahami seluruh strukturnya dan memeliharanya sendiri, sehingga beban dependensi dari kombinasi SSG dan hosting yang biasa digunakan menjadi berkurang
  • Kombinasi seperti Hugo dan GitHub Pages mengandaikan berbagai kondisi eksternal, seperti keberlanjutan layanan, pemeliharaan proyek, ekosistem plugin, cara deployment, Go, dan lainnya
  • Mengedit HTML secara manual itu sederhana dan stabil, tetapi sulit menangani fungsi umum secara berulang, dan alur kerjanya menjadi melelahkan, sehingga diperlukan cara yang lebih menyenangkan dan mudah disesuaikan
  • Situs dinamis berbasis Go menangani pekerjaan yang merepotkan di situs statis, seperti menampilkan IP atau memperbarui feed RSS, melalui kode sisi server, dan mengembalikan HTML lengkap juga untuk tool selain browser
  • Situs web pribadi cenderung lebih bertahan lama jika dimulai dari kecil lalu dikembangkan dengan standard library dan tool sederhana; jika dimulai dengan framework besar, sulit mengikutinya dalam waktu pribadi

Mengapa tool situs web yang ada tidak cocok

  • Saya mencoba berbagai cara, mulai dari Ghost, Hugo, Jekyll, sr.ht dengan tarball, hingga mengedit HTML secara manual, tetapi semuanya tidak sesuai dengan kriteria pribadi dan juga tidak memberi ketertarikan
  • Kriteria terpenting adalah sistem yang dapat dipahami dari awal hingga akhir oleh satu orang dan mudah dipelihara
    • Kode yang mudah dibaca
    • Feedback loop yang cepat
    • Kesenangan dan kecerdikan
    • Struktur yang bisa saya selami sendiri saat rusak
  • Static site generator (SSG) seperti Hugo menerima template dan Markdown sebagai input untuk membuat HTML, dan biasanya digunakan bersama platform hosting
  • Kombinasi Hugo dan GitHub Pages disertai berbagai kondisi pemeliharaan
    • Layanan GitHub Pages harus terus berjalan
    • Produk GitHub Pages harus terus dipelihara
    • Proyek Hugo dan dokumentasi komunitasnya harus dipelihara
    • Bisa bergantung pada ekosistem plugin
    • Binary Hugo harus tetap menghasilkan HTML dengan cara yang hampir sama seiring waktu
    • Mekanisme deployment GitHub Pages harus terus berfungsi
    • Go diperlukan
  • Ada juga cara mengunci versi Hugo tertentu, tetapi dalam praktiknya bisa muncul situasi ketika upgrade diperlukan karena bug

Kelebihan dan batasan mengedit HTML secara manual

  • Saya juga memilih cara meng-host situs web di mesin yang saya kendalikan langsung, lalu mengedit HTML sendiri dengan Vim
  • Versi pertama j3s.sh dibuat dengan cara ini, dan banyak ide layout saat ini berasal dari sana
  • Menulis HTML dengan tangan terasa seperti kerja manual yang berat, sehingga mengarah pada minimalisme ekstrem
    • Memasukkan style langsung ke dalam HTML
    • Meminimalkan fungsi umum di seluruh situs
    • Banyak menghindari styling
  • Cara ini sederhana, stabil, dan mudah dipelihara
    • HTML yang ditulis dapat digunakan ulang tanpa perubahan
    • Tidak ada dependensi eksternal
    • Memberi keyakinan bahwa situs akan bertahan lama
  • Namun, saya ingin menangani templating untuk fungsi umum dengan lebih efisien, dan membutuhkan cara yang menyenangkan untuk disesuaikan tanpa framework yang ada

Situs web Go dalam satu binary

  • Jika seluruh situs web ditulis dalam satu bahasa, hasilnya dapat dimasukkan ke satu binary untuk deployment
  • Go adalah pilihan yang cocok untuk pemeliharaan pribadi dan deployment sederhana
    • Mudah dipelihara oleh satu orang
    • Menekankan arah penggunaan dependensi yang sedikit
    • Bahasanya relatif sederhana
    • Ada jaminan kompatibilitas ke belakang
    • Mudah membuat binary hasil kompilasi statis
    • Sebagian besar kompilasi selesai dalam kurang dari 10 detik
    • Standard library-nya berkembang dengan baik
  • Hasilnya, j3s.sh menjadi satu binary yang menyajikan situs web

Kesederhanaan yang diberikan situs web dinamis

  • Dalam beberapa kasus, situs web yang dihasilkan secara dinamis bisa lebih sederhana daripada situs web yang dihasilkan secara statis
    • Tidak perlu memikirkan workaround untuk pembuatan konten
    • Konten yang dibutuhkan dapat dibuat saat itu juga
  • Fitur untuk menampilkan alamat IP pengunjung dapat diimplementasikan dengan mudah menggunakan http.HandlerFunc milik Go
    • Membaca header X-Forwarded-For
    • Menghubungkan handler ke path /ip
    • Dapat memanggil fungsi yang sama di tempat yang diperlukan
  • Untuk mengimplementasikan fungsi yang sama di situs statis, dependensi eksternal seperti JavaScript mungkin diperlukan, dan kasus tanpa JavaScript juga harus dipertimbangkan
    • Sebagian pembaca menolak menjalankan JavaScript
  • Jika server sudah mengembalikan HTML yang berisi alamat IP, klien tetap menerima respons yang benar meskipun tidak memahami JavaScript
    • Cara yang sama juga berlaku untuk tool selain browser
  • Feed RSS di halaman utama dibuat saat situs web mulai berjalan
    • Dapat mengambil artikel terbaru teman-teman
    • RSS feed fetcher buatan sendiri diperkirakan akan berjalan lama tanpa pemeliharaan
    • Saya memahami persis cara kerja internalnya

Deployment dan cara memulai

  • Deployment ditangani dengan skrip shell singkat
    • Mengambil repository Git
    • Jika branch lokal tertinggal, menjalankan git merge origin/main
    • Build dengan go build
    • Memindahkan binary ke /usr/local/bin/j3s.sh
    • Me-restart layanan dengan service j3s.sh restart
  • Skrip ini dijalankan setiap menit sebagai cronjob, sehingga ketika repository diperbarui, situs akan di-build ulang
    • Jika diuji secara lokal lalu diunggah, perubahan tercermin di situs publik dalam 1 menit
    • Cukup sederhana untuk dipahami dalam 10 detik jika sedikit tahu shell
  • Situs web pribadi memberi nuansa unik di web masa kini, dan dapat mencerminkan secara mendalam hal-hal yang dianggap penting oleh pengelolanya
  • Orang yang cocok dengan situs statis bisa terus menggunakannya, tetapi bagi orang dengan nilai yang serupa, mencoba situs web dinamis bisa sangat cocok
    • Dapat dimulai dari kecil
    • Dapat menambahkan ide menarik secara iteratif
    • Karena ini situs sendiri, hardcoding pun boleh
    • Dapat dibuat dengan bahasa yang disukai seperti Rust, Perl, Python, dan lainnya
  • Mulailah dari kecil
    • Pertama buat index.html, lalu fokus menyajikannya dengan bahasa yang dipilih
    • RSS atau Markdown ditambahkan nanti ketika diperlukan
    • Jika memungkinkan, gunakan tool yang paling sederhana dan mudah dipelihara, seperti standard library
    • Di Ruby, dapat mempertimbangkan opsi yang lebih kecil seperti Sinatra alih-alih Rails; di Python, Gin alih-alih Flask
    • Bisa juga terlebih dahulu mencoba apakah dapat diimplementasikan sendiri dengan 0 library
  • Jika dimulai dengan framework besar atau proyek yang terus mengalami breaking change, sulit mengikutinya dalam waktu pribadi dan bisa cepat melelahkan
  • Web membutuhkan lebih banyak keanehan, kegembiraan, dan kepribadian, dan mencoba membuat situs web dinamis sangat dianjurkan

1 komentar

 
GN⁺ 2023-10-23
Pendapat Hacker News
  • Di mobile, lebar situs web tidak dihitung dengan benar, jadi untuk membaca tulisannya harus menggulir ke kiri dan kanan
    Tepat sebelum melakukan itu, saya membaca kalimat “Saya punya standar yang sangat tinggi dan tidak biasa”, jadi jujur saja agak lucu :)

    • Ini bukan tulisan yang strukturnya dibuat dengan HTML seperti section atau paragraf, melainkan sekadar file teks biasa yang dirender dengan penanganan spasi pre, sehingga terlihat seperti satu paragraf raksasa ¯_(ツ)_/¯
    • Bahkan di Reader Safari pun formatnya 0, jadi itu juga cukup mengesankan
      Saya sering melihat format yang aneh, tapi baru kali ini melihat yang sama sekali tanpa format
    • Dengan mode baca Firefox Mobile masalahnya teratasi, jadi sebenarnya ketidaknyamanannya hanya sebatas menekan satu tombol
      Tetap saja, kesan pertamanya tidak bagus
    • Logika penulis dan fakta bahwa situs ini tidak dibuat menyesuaikan platform saling bertabrakan
      Saya tidak paham
    • Saya juga berpikir begitu
      Tidak apa-apa kalau ia bangga pada dirinya sendiri, tapi saya memilih untuk tidak membacanya saja
  • Intinya adalah apa sebenarnya arti “tetap sederhana”, dan apa arti “dapat dipahami”
    Tulisan seperti ini melewatkan perdebatan yang menarik dan langsung menganggap bahwa pendekatannya sederhana serta tujuannya adalah kesederhanaan
    Saat bisa memilih abstraksi, misalnya library atau framework, layanan atau API, mana yang lebih sederhana: menggunakannya atau tidak menggunakannya?
    Jika tidak menggunakannya dan membuat sendiri, kita jadi lebih tahu bagaimana seluruh sistem bekerja, jadi dalam arti tertentu itu lebih sederhana
    Namun kompleksitas tetap muncul, dan dalam beberapa kasus kita juga harus membuat sendiri lapisan abstraksinya
    Sebaliknya, jika menggunakannya, kompleksitas disembunyikan, sehingga pada jalur normal sistem bisa dianggap lebih sederhana, tetapi kompleksitas itu tetap ada dan tersembunyi sehingga tidak kita pahami
    Kedua cara itu sama-sama tampak jelas sederhana dari sudut pandang tertentu, tetapi kita harus melewati kejelasan itu untuk melihat trade-off-nya

    • Misalkan kamu ingin membuat pai apel
      Biasanya kamu akan membeli bahan dan alat, lalu memanggangnya di oven yang sudah ada
      Namun untuk membuat pai apel dari nol, pertama-tama kamu harus membuat alam semesta, dan mungkin kamu akan membuat alam semesta paling sederhana yang mendukung pai apel
      Seluruh stack-nya bisa jadi lebih sederhana, tetapi tahap terakhir, yaitu benar-benar membuat painya, bisa menjadi lebih rumit dan rasanya mungkin juga bukan yang terbaik
      Sebagai gantinya, kamu mendapatkan pai yang sepenuhnya kamu pahami mulai dari prinsip pertama
    • Yang dibicarakan di sini tampaknya lebih dekat ke perbedaan antara “sederhana (simple)” dan “mudah (easy)”
      Kamu mungkin akan menyukai presentasi Rich Hickey ini: https://paulrcook.com/blog/simple-made-easy
      Kita bisa menambahkan fitur untuk membuat sesuatu lebih mudah dibuat atau didistribusikan, tetapi tambahan itu membuat keseluruhannya lebih kompleks dan lebih sulit dipahami atau dilacak masalahnya
    • Terkait tulisan ini, komentar ini agak sulit saya pahami
      Di bagian akhir, penulis mengatakan dengan sangat jelas agar masing-masing orang melakukan dengan caranya sendiri
      Selain itu, ia juga mengatakan bahwa ia tidak puas menggunakan sistem yang sulit ia pahami atau terasa membebani
      Sebaiknya baca juga setelah paragraf pertama
  • Sangat keren!
    Saya sama sekali tidak setuju dengan “Kalian juga harus melakukan ini!” :)
    Maintainability adalah salah satu nilai inti saya, jadi seperti kamu, saya juga merawat sepeda sendiri
    Namun bagi saya itu bukan prioritas nomor satu sampai sejauh ini, jadi pilihan seperti ini tidak masuk akal untuk saya
    Laptop Framework adalah titik yang menunjukkan perbedaan kita dengan baik
    Kamu terus mencetak 9 poin di sisi DIY, sedangkan saya menjaga resiliensi dengan memiliki ThinkPad cadangan berusia 10 tahun yang kapan saja bisa dengan cepat menjalankan Linux dan Neovim, dan kalau itu pun rusak, saya percaya ke depannya masih akan ada banyak ThinkPad di bawah 100 dolar
    Jika suatu hari dibutuhkan, saya membawa cukup pengetahuan ilmu komputer dan matematika untuk menulis parser dari Markdown ke HTML dengan kombinator Haskell yang lambat, tidak resmi, dan penuh bug, tetapi sepertinya hari itu tidak akan segera datang
    Kalau bisa, saya ingin merekrut kamu
    Kamu akan menjadi penyeimbang yang sempurna bagi banyak orang yang condong ke arah berlawanan

    • Saya penasaran, apa yang dimaksud dengan condong ke arah berlawanan?
  • Saya sangat menikmati membaca tulisan ini
    Penulisnya jujur pada dirinya sendiri dan bersungguh-sungguh terhadap pembaca
    Ia hadir sebagai dirinya sendiri tanpa alasan-alasan pembenaran, dan berusaha mencapai tujuannya dengan cara yang sesuai dengan nilai-nilainya serta memberinya kesenangan
    Tidak apa-apa jika nilai itu tidak cocok denganmu; justru itu hal yang indah
    Sekarang kamu mendapatkan petunjuk tentang jalan yang bisa kamu jelajahi
    Tulisannya ramah, rendah hati, autentik, dan menurut saya penulis serta tulisannya membuat dunia menjadi sedikit lebih baik

    • Bahwa ia bersungguh-sungguh memang benar, tetapi soal jujur pada diri sendiri, rasanya hampir kebalikannya
      Begitu juga soal rendah hati
      Seluruh tulisan ini lebih mirip memuji diri sendiri, dan di sana-sini terlihat potongan yang terasa seperti /r/confidentlyincorrect
    • Tulisan ini lebih mudah dilihat bukan sebagai tulisan untuk pembaca, melainkan sebagai latihan dan alat bantu bagi penulis untuk mencapai tujuan internal seperti belajar atau rasa kendali
      Pembaca hanyalah sasaran sampingan, jadi sekeras apa pun pengalaman pembacanya ala Sparta, itu bukan inti; pengalaman penulislah yang menjadi inti
    • Kalau sudah membaca, bisa berbagi sedikit isinya?
      Sepertinya banyak orang dari platform mobile menyerah terlalu cepat untuk membacanya
  • Saya hanya membaca sekilas, tapi orang ini hampir pasti sedang memancing kita
    Situs webnya mengaku memakai “plain HTML” secara harfiah, tetapi sebenarnya itu plain text
    Tidak ada HTML untuk pemformatan sama sekali di sini
    Tidak ada judul, paragraf, daftar, bahkan tag a pun tidak ada
    Sedikit HTML dan CSS yang ada justru membuat situsnya dirender lebih buruk
    Penulisnya troll

    • Elemen itu sudah ditandai sebagai elemen yang deprecated setidaknya sejak 15 tahun lalu
  • Sambil mengatakan, “Saya punya standar yang sangat tinggi dan tidak biasa,” ia berkata, “skrip ini dijalankan setiap menit sebagai cronjob dan membangun ulang situs jika repositori git diperbarui.”
    Artinya mengambil repositori yang mungkin hanya mendapat beberapa commit setahun sebanyak 525.600 kali per tahun.
    Saya jadi paham kenapa kata “tidak biasa” dimasukkan.

    • Kalau tidak ada commit baru, git fetch pada dasarnya hampir seperti satu kali perbandingan string [0], jadi menurut saya operasinya tidak semahal kedengarannya.
      [0] https://stackoverflow.com/a/44476803
    • Dalam situasi ini, itu lebih dekat ke kegilaan daripada “tidak biasa”.
      Jangan tanya, langsung beri tahu saja.
    • Di sini terlalu banyak asumsi tentang bagaimana deployment saya bekerja!
      Semua repositori git saya berada di server yang sama dengan yang meng-host website.
      git tidak melakukan fetch jarak jauh, melainkan fetch lokal, jadi pada dasarnya selesai seketika.
      Bahkan kalaupun itu fetch jarak jauh, tetap tidak masalah.
      525.600 request HTTP per tahun itu lebih tidak boros dibanding heartbeat NetworkManager.
      Di Arch, default-nya adalah 1 request heartbeat setiap 30 detik.
      Sebagai referensi, server nginx standar dengan 8 CPU bisa menangani lebih dari 500 ribu request HTTP per detik.
  • Untuk OP:
    Di sini terlihat banyak tulisan yang sangat kritis.
    Dengan hormat… jangan terlalu dipikirkan.
    Kritiknya mungkin benar, tetapi industri ini sedang cepat menuju kebodohan skala besar dengan mengikuti “harus” dan “semestinya” kolektif.
    Sebagian besar dari itu, untuk saat ini, hanya punya validitas setingkat legenda urban.
    Apa yang sekarang disebut “engineering” akan bisa kita tertawakan saja kalau kita tidak sedang secara aktif membangun masa depan di atasnya.
    Ayah saya adalah insinyur aerospace, dan saya rasa beliau akan gelisah di kuburnya jika melihat apa yang disebut engineering dalam pengembangan software modern.
    Ini kolom komentar, jadi semua orang bebas bicara, tetapi secara pribadi baru setelah 25 tahun di industri ini saya bisa mengabaikan suara-suara cerewet itu dan, pada kesempatan langka yang memungkinkan, melakukan apa yang menurut saya masuk akal.
    Apalagi kalau ini situs pribadi, bukan?
    Kalimat lama dari iklan Apple, “untuk orang-orang gila”, sekarang pun terdengar jauh dari kebenaran.
    Melihat internet menjadi seperti ini, dan tempat-tempat yang dulu startup kini menjadi monster korporasi terbesar di lanskap ini, itu tidak mengherankan.
    Kutipan Theodore Roosevelt tentang “orang di arena” benar-benar terasa tepat belakangan ini.
    Lanjutkan, OP, lanjutkan…

    • Terima kasih atas dorongannya! Terutama di HN, terutama kritik terhadap tulisan tentang website pribadi saya, saya berusaha menerimanya dengan ringan.
      Website saya bukan situs yang dioptimalkan sempurna, melainkan taman bermain sakral dan unik milik saya sendiri.
      Semuanya saya tulis sendiri dan berevolusi seiring waktu.
      Jelas gaya saya kadang mengganggu orang, dan saya sudah terbiasa dengan kritik seperti itu.
      Saya kadang membuat keputusan aneh demi membengkokkan konten ke bentuk yang saya sukai, tetapi justru itulah yang menurut saya membuat konten saya terasa menyenangkan.
      Karena tidak sama dengan hal-hal lain di luar sana.
      Mungkin ada sisi-sisi kasar, tetapi sambil mengeksplorasi “format personal”, itu akan makin membaik :)
      Bagi saya, website seperti proyek seni jangka panjang.
      Ia harus merepresentasikan pembuatnya, dan dalam kasus saya, situs saya dengan bangga merepresentasikan saya.
  • Karena punyamu sudah muncul, saya akan menunjukkan punya saya juga.
    Website, game engine, dan webserver saya adalah satu binary.
    Source-nya 1000 baris kode C, dan ukuran binary-nya 164KB.
    Entah kenapa bisa sebesar itu.
    Webserver-nya juga saya masukkan sendiri.
    Server yang sudah ada menambahkan terlalu banyak kompleksitas tersembunyi.
    Hasilnya, game interactive fiction berbahasa Jerman, bisa dilihat di sini: http://vmd34232.contaboserver.net/
    Tidak ada pelacakan, tidak ada iklan, tidak ada tujuan komersial.

    • Bagus, dulu saya pernah memuat file z5 buatan inform7 dengan parchment.js di website saya.
      Executable-nya bisa dicoba dikompresi dengan upx https://upx.github.io/
    • Mengingatkan saya pada situs saya :)
      https://toldby.ai/
      Punya saya bukan single binary, melainkan asp.net.
  • Saya sepenuhnya setuju dengan semua poin yang diangkat dalam tulisan itu, tetapi website ini agak kurang bagus sebagai contoh.
    Website-nya disebut “satu binary”, tetapi strategi deployment-nya mencakup kompilasi alih-alih menjalankan artefak binary.
    Katanya tidak mau bergantung pada github pages, tetapi bergantung pada resource eksternal dari openlibrary.org.
    Katanya kalau membuat sendiri bisa memanfaatkan standar publik, tetapi file .html di dalam thoughts/ adalah struktur teks biasa dengan ekstensi palsu.
    Saat orang memilih jalan ini, biasanya mereka mencoba memasukkan semuanya ke initial page load, tetapi di sini ada beberapa file statis yang disajikan secara dinamis.
    Kode Golang-nya tidak melakukan cache untuk respons apa pun dan juga tidak menyimpan template di memori.
    Ada beberapa dependency di file go.mod, dan semuanya tampaknya tidak dipakai.
    Yang paling penting, tidak ada pembahasan tentang keunggulan teknis apa yang dimiliki semangat single binary dibanding infrastruktur modern.
    Secara pribadi menurut saya ini ide bagus, tetapi ini contoh yang buruk.

    • Sebenarnya ini bukan single binary.
      Ini single binary yang bekerja bersama filesystem.
      Semua kontennya ada di filesystem.
      “Single binary” di sini adalah webserver Golang ringan yang menyajikan konten dari filesystem.
  • Katanya “standar yang sangat tinggi dan tidak biasa”; tidak biasanya memang benar, tetapi desain website hasilnya sangat buruk sampai teks pun tidak bisa ditampilkan dengan benar sesuai layar, jadi standarnya justru sangat rendah