Kebijaksanaan lama dalam pemrograman jangan pernah menulis library parsing tanggal sendiri telah memicu perdebatan sengit di komunitas developer setelah pencipta Eleventy melanggar aturan utama ini. Meskipun memulai artikelnya dengan peringatan yang sama persis, dia melanjutkan untuk membuat @11ty/parse-date-strings, sebuah library parsing tanggal kustom yang kompatibel dengan RFC 9557 yang secara dramatis mengurangi ukuran bundle dari 229 kB menjadi hanya 2,3 kB.
Perbandingan Ukuran Bundle
| Package | Type | Disk Size | Bundle Size |
|---|---|---|---|
| [email protected] | Dual | 4.59 MB | 81.6 kB (min) |
| [email protected] | CJS | 4.35 MB | 204.9 kB (min) |
| [email protected] | CJS | 670 kB | 6.9 kB (min) |
| [email protected] | Dual | 22.6 MB | 77.2 kB (min) |
| @11ty/[email protected] | ESM | 6.68 kB | 2.3 kB (min) |
 |
|---|
| Perdebatan mengenai penulisan pustaka parsing tanggal kustom disorot melalui diskusi dalam komunitas developer |
Pembagian antara Pembelajaran dan Produksi
Respons komunitas mengungkapkan ketegangan fundamental dalam filosofi pengembangan perangkat lunak. Beberapa developer berargumen bahwa menangani hal-hal sulit seperti parsing tanggal sangat penting untuk pertumbuhan dan pembelajaran. Mereka menunjukkan bahwa semua library matang yang kita andalkan saat ini dimulai sebagai implementasi kustom seseorang. Namun, yang lain menekankan perbedaan kritis antara latihan pembelajaran dan kode produksi.
Silakan saja menulis itu. Hanya saja jangan gunakan. Peringatan ini hampir selalu dalam konteks kode yang akan kamu rilis, bukan latihan pembelajaran sendiri.
Perspektif ini menyoroti bahwa peringatan terhadap library tanggal kustom bukan tentang mencegah pembelajaran, tetapi tentang mengenali pengujian masif dan penanganan edge case yang telah dilalui library siap produksi. Sifat battle-tested dari library yang sudah mapan berasal dari jutaan penggunaan dunia nyata yang mengekspos corner case yang mungkin tidak pernah ditemui developer individu.
Kompleksitas di Balik Tanggal Sederhana
Diskusi mengungkapkan mengapa tanggal adalah wilayah yang sangat berbahaya untuk implementasi kustom. Selain komplikasi timezone yang jelas, developer berbagi cerita tentang tantangan tak terduga. Aplikasi medis berjuang dengan tanggal lahir yang berubah ketika pasien pindah timezone. Aplikasi internasional harus menangani beberapa sistem kalender, termasuk kalender Jepang dengan sistem penanggalan berbasis era.
Komunitas juga menyoroti sifat politik timezone, yang bukan konstruksi matematis tetapi legal yang berubah berdasarkan keputusan pemerintah. Ini menambahkan lapisan kompleksitas yang sama sekali berbeda yang melampaui logika pemrograman murni.
Perbandingan Dukungan Format Tanggal
| Format | ISO 8601 | Date.parse | Luxon | RFC 9557 |
|---|---|---|---|---|
| YYYY | ✔ | ✔ | ✖ | ✖ |
| YYYY-MM | ✔ | ✔ | ✔ | ✖ |
| YYYY-MM-DD | ✔ | ✔ | ✔ | ✔ |
| YYYY-MM-DDTHH:II:SS | ✔ | ✖ | ✖ | ✖ |
| YYYY-MM-DDTHH:II:SSZ | ✔ | ✖ | ✖ | ✔ |
✔ Didukung ✖ Tidak Didukung
Solusi Praktis dan Workaround
Beberapa developer berbagi pendekatan dunia nyata mereka terhadap tantangan penanganan tanggal. Untuk aplikasi yang menangani tanggal lahir, beberapa telah beralih untuk memperlakukan tanggal sebagai string sederhana daripada objek temporal, menghindari bug terkait timezone sepenuhnya. Yang lain mengadvokasi penggunaan tipe tanggal khusus seperti LocalDate atau PlainDate dari Temporal API yang akan datang untuk skenario di mana informasi timezone tidak relevan.
Diskusi juga menyentuh pertimbangan antarmuka pengguna, dengan developer memperdebatkan manfaat date picker versus field input teks. Meskipun date picker memberikan kontrol lebih, mereka bisa merepotkan bagi pengguna yang memasukkan tanggal jauh di masa lalu, seperti tahun kelahiran.
Dampak Bundle Eleventy
- Penggunaan Luxon di @11ty/eleventy: 4,7 MB dari 21,3 MB (22%)
- Penggunaan Luxon di @11ty/client: 229 kB dari 806 kB (28%)
- Proyeksi penghematan: ~230 kB pada bundle klien, node_modules berkurang dari 21,3 MB menjadi 16,6 MB
Realitas Ukuran Bundle
Keputusan Eleventy pada akhirnya bermuara pada kendala praktis daripada filosofis. Dengan Luxon mengonsumsi 22% dari bundle Node.js mereka dan 28% dari bundle klien mereka, dampak performa signifikan. Kasus penggunaan mereka yang sangat spesifik - hanya membutuhkan parsing ISO 8601 tanpa formatting atau display - membuat solusi kustom menjadi layak.
Komunitas mengakui bahwa persyaratan spesifik seperti itu dapat membenarkan implementasi kustom, terutama ketika library yang ada tidak mendukung tree-shaking atau ketika kasus penggunaan sangat sempit. Namun, mereka menekankan bahwa ini harus menjadi pengecualian daripada aturan, dan hanya setelah mengevaluasi secara menyeluruh alternatif yang ada.
Referensi: NEVER WRITE YOUR OWN DATE PARSING LIBRARY