Kebijaksanaan pengaturcaraan lama jangan sekali-kali menulis perpustakaan penghuraian tarikh sendiri telah mencetuskan perdebatan sengit dalam komuniti pembangun selepas pencipta Eleventy melanggar peraturan utama ini. Walaupun memulakan artikelnya dengan amaran yang sama, beliau meneruskan untuk mencipta @11ty/parse-date-strings, sebuah perpustakaan penghuraian tarikh tersuai yang serasi dengan RFC 9557 yang mengurangkan saiz bundle secara dramatik daripada 229 kB kepada hanya 2.3 kB.
Perbandingan Saiz Bundle
| Pakej | Jenis | Saiz Cakera | Saiz Bundle |
|---|---|---|---|
| [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 perpustakaan penghuraian tarikh tersuai diserlahkan melalui perbincangan dalam komuniti pembangun |
Perpecahan Antara Pembelajaran dan Produksi
Respons komuniti mendedahkan ketegangan asas dalam falsafah pembangunan perisian. Sesetengah pembangun berhujah bahawa menangani perkara sukar seperti penghuraian tarikh adalah penting untuk pertumbuhan dan pembelajaran. Mereka menegaskan bahawa semua perpustakaan matang yang kita bergantung hari ini bermula sebagai pelaksanaan tersuai seseorang. Walau bagaimanapun, yang lain menekankan perbezaan kritikal antara latihan pembelajaran dan kod produksi.
Dengan segala cara, tulislah ia. Cuma jangan gunakannya. Amaran ini hampir selalu dalam konteks kod yang akan anda keluarkan, bukan latihan pembelajaran sendiri.
Perspektif ini menyerlahkan bahawa amaran terhadap perpustakaan tarikh tersuai bukanlah untuk menghalang pembelajaran, tetapi untuk mengiktiraf ujian besar-besaran dan pengendalian kes tepi yang telah dilalui oleh perpustakaan sedia ada yang siap untuk produksi. Sifat teruji pertempuran perpustakaan yang mantap datang daripada berjuta-juta penggunaan dunia sebenar yang mendedahkan kes sudut yang mungkin tidak pernah ditemui oleh pembangun individu.
Kerumitan Di Sebalik Tarikh Mudah
Perbincangan mendedahkan mengapa tarikh adalah wilayah yang sangat berbahaya untuk pelaksanaan tersuai. Selain komplikasi zon masa yang jelas, pembangun berkongsi cerita tentang cabaran yang tidak dijangka. Aplikasi perubatan bergelut dengan tarikh lahir yang berubah apabila pesakit berpindah zon masa. Aplikasi antarabangsa mesti mengendalikan pelbagai sistem kalendar, termasuk kalendar Jepun dengan sistem pentarikhan berasaskan era.
Komuniti juga menyerlahkan sifat politik zon masa, yang bukan binaan matematik tetapi undang-undang yang berubah berdasarkan keputusan kerajaan. Ini menambah lapisan kerumitan yang sama sekali berbeza yang melampaui logik pengaturcaraan tulen.
Perbandingan Sokongan Format Tarikh
| Format | ISO 8601 | Date.parse | Luxon | RFC 9557 |
|---|---|---|---|---|
| YYYY | ✔ | ✔ | ✖ | ✖ |
| YYYY-MM | ✔ | ✔ | ✔ | ✖ |
| YYYY-MM-DD | ✔ | ✔ | ✔ | ✔ |
| YYYY-MM-DDTHH:II:SS | ✔ | ✖ | ✖ | ✖ |
| YYYY-MM-DDTHH:II:SSZ | ✔ | ✖ | ✖ | ✔ |
✔ Disokong ✖ Tidak Disokong
Penyelesaian Praktikal dan Penyelesaian Sementara
Beberapa pembangun berkongsi pendekatan dunia sebenar mereka terhadap cabaran pengendalian tarikh. Untuk aplikasi yang berurusan dengan tarikh lahir, sesetengah telah beralih kepada merawat tarikh sebagai rentetan mudah dan bukannya objek temporal, mengelakkan pepijat berkaitan zon masa sepenuhnya. Yang lain menyokong penggunaan jenis tarikh khusus seperti LocalDate atau PlainDate API Temporal yang akan datang untuk senario di mana maklumat zon masa tidak relevan.
Perbincangan juga menyentuh pertimbangan antara muka pengguna, dengan pembangun mempertikaikan merit pemilih tarikh berbanding medan input teks. Walaupun pemilih tarikh memberikan lebih kawalan, ia boleh menjadi menyusahkan bagi pengguna yang memasukkan tarikh jauh di masa lalu, seperti tahun kelahiran.
Kesan Bundle Eleventy
- Penggunaan Luxon dalam @11ty/eleventy: 4.7 MB daripada 21.3 MB (22%)
- Penggunaan Luxon dalam @11ty/client: 229 kB daripada 806 kB (28%)
- Unjuran penjimatan: ~230 kB dalam bundle klien, node_modules berkurang daripada 21.3 MB kepada 16.6 MB
Realiti Saiz Bundle
Keputusan Eleventy akhirnya bergantung kepada kekangan praktikal dan bukannya falsafah. Dengan Luxon menggunakan 22% daripada bundle Node.js mereka dan 28% daripada bundle klien mereka, kesan prestasi adalah ketara. Kes penggunaan mereka yang sangat khusus - hanya memerlukan penghuraian ISO 8601 tanpa pemformatan atau paparan - menjadikan penyelesaian tersuai berdaya maju.
Komuniti mengakui bahawa keperluan khusus sedemikian boleh membenarkan pelaksanaan tersuai, terutamanya apabila perpustakaan sedia ada tidak menyokong tree-shaking atau apabila kes penggunaan sangat sempit. Walau bagaimanapun, mereka menekankan bahawa ini sepatutnya menjadi pengecualian dan bukannya peraturan, dan hanya selepas menilai alternatif sedia ada secara menyeluruh.