Dalam dunia pengembangan perangkat lunak, hanya sedikit topik yang bisa memicu diskusi sesemangat format data. Sebuah posting blog terbaru oleh pengembang game veteran Ron Gilbert, pencipta Maniac Mansion dan Monkey Island, telah memicu debat segar tentang alat-alat yang digunakan pengembang setiap hari. Sementara Gilbert berbagi pengalaman pribadinya dengan Git, JSON, dan Markdown, komunitas pengembang dengan cepat fokus pada satu kontroversi tertentu: keterbatasan JSON dibandingkan dengan pendahulunya, XML.
Kebangkitan JSON Bertemu Nostalgia XML
Diskusi ini mengungkapkan pergeseran sentimen pengembang yang menarik. Banyak pengembang berpengalaman kini melihat kembali XML dengan apresiasi baru, mengenali fitur-fitur yang dulu dianggap biasa. Kesederhanaan JSON membuatnya sangat populer, tetapi kesederhanaan yang sama kini menunjukkan keterbatasannya dalam aplikasi yang kompleks.
JSON adalah salah satu tragedi paling ikonik yang terjadi dalam pengembangan perangkat lunak. Bukan berarti JSON itu buruk, tetapi jelas untuk ditulis oleh mesin, bukan oleh manusia.
Konsensus komunitas menunjukkan bahwa tujuan awal JSON sebagai format yang dapat dibaca mesin telah diregangkan melampaui kasus penggunaan yang dimaksudkan. Pengembang sekarang menggunakan JSON untuk segala hal mulai dari file konfigurasi hingga skema data kompleks, mengungkap keterbatasannya untuk konten yang ditulis manusia.
Fitur yang Hilang: Lebih dari Sekadar Komentar
Sementara kurangnya komentar dalam JSON sering disebutkan, diskusi komunitas mengungkapkan kekhawatiran yang lebih dalam. Pengembang menunjuk pada ketidakmampuan JSON dalam menangani metadata, tidak adanya alat validasi standar yang sebanding dengan XML Schema, dan tantangan dalam merepresentasikan hubungan data yang kompleks.
Percakapan ini menyoroti bagaimana JSON sedang menemukan kembali XML Schema, XML DTD, dll, padahal kita sudah memilikinya seperempat abad yang lalu. Sentimen ini bergema di seluruh komentar, dengan beberapa pengembang mencatat bahwa peralatan dan standardisasi XML jauh lebih matang daripada yang tersedia untuk JSON saat ini.
Fitur XML yang Terlewatkan oleh Developer dalam JSON:
- Dukungan komentar bawaan
- Validasi skema (XML Schema, DTD)
- Kemampuan transformasi (XSLT)
- Metadata melalui atribut
- Tooling dan library parsing yang terstandarisasi
- Dukungan rendering browser dengan stylesheet
Paradoks Konfigurasi
Salah satu poin diskusi yang paling panas berpusat pada penggunaan JSON untuk file konfigurasi. Pengembang berbagi solusi kreatif untuk keterbatasan JSON, termasuk menambahkan bidang komentar khusus untuk menyimpan teks penjelas. Ini menyoroti ketidakcocokan mendasar antara desain JSON dan pola penggunaannya yang umum.
Komunitas juga mendiskusikan alternatif seperti YAML dan TOML, dengan reaksi beragam. Sementara beberapa lebih menyukai keterbacaan YAML, yang lain mencatat kompleksitas parsing dan masalah keamanannya sendiri. Pencarian format konfigurasi yang sempurna terus berlanjut, tanpa pemenang jelas yang muncul dari diskusi.
Format Alternatif yang Dibahas:
- YAML: Superset JSON yang mudah dibaca manusia, namun memiliki kompleksitas dalam parsing
- TOML: Fokus pada file konfigurasi dengan keterbacaan yang lebih baik
- JSON5: Ekstensi JSON yang mendukung komentar dan trailing comma
- XML: Standar matang dengan perangkat yang ekstensif
Kesenjangan Peralatan
Beberapa komentator menunjuk pada kesenjangan signifikan dalam peralatan antara JSON dan XML. Fitur-fitur seperti XSLT untuk transformasi, dukungan browser bawaan untuk merender XML dengan stylesheet, dan sistem validasi yang matang disorot sebagai kekuatan XML yang masih kurang dalam JSON.
Seorang pengembang berbagi: Saya ingat ketika halaman web Blizzard hanyalah XML + XSLT. Saya sedang membangun semacam parser untuk mereka dan bingung sesaat ketika skrip Python saya mengembalikan XML mentah saat mengambil halaman depan. Contoh ini menggambarkan bagaimana pendekatan terintegrasi XML terhadap data dan presentasi menyediakan solusi yang masih berusaha direplikasi oleh sistem berbasis JSON.
Faktor Manusia
Di luar spesifikasi teknis, diskusi sering kembali ke faktor manusia dalam desain format data. Persyaratan ketat JSON seputar koma di akhir dan kunci yang dikutip diperdebatkan secara luas, dengan pengembang berbagi baik frustrasi maupun pembenaran untuk pilihan desain ini.
Percakapan mengungkapkan bahwa banyak pengembang telah menulis parser JSON khusus untuk melonggarkan pembatasan ini, hanya untuk menemui masalah kompatibilitas dengan alat standar. Ketegangan antara kenyamanan dan standardisasi ini masih belum terselesaikan dalam komunitas.
Solusi Alternatif Umum dari Developer untuk Keterbatasan JSON:
- Menambahkan field "comment":
{"_comment": "Ini adalah komentar", "data": "value"} - Menggunakan JSON5 atau JSONC untuk file konfigurasi
- Parser JSON kustom yang mengizinkan trailing comma dan key tanpa tanda kutip
- Validasi skema eksternal dengan JSON Schema
Melihat ke Depan
Diskusi ini menunjukkan bahwa format data yang ideal mungkin belum ada. Sementara JSON unggul dalam pertukaran data sederhana antar mesin, dan XML menyediakan fitur kuat untuk pemrosesan dokumen kompleks, keduanya tidak sempurna dalam mengatasi spektrum penuh kebutuhan pengembangan modern.
Refleksi komunitas tentang alat-alat ini menunjukkan pematangan dalam pemikiran pengembang. Daripada hanya mengejar teknologi terbaru, pengembang berpengalaman mengambil pendekatan yang lebih bernuansa, mengevaluasi alat berdasarkan kekuatan dan keterbatasan spesifiknya untuk kasus penggunaan tertentu.
Evolusi berkelanjutan format data mencerminkan evolusi yang lebih luas dari pengembangan perangkat lunak itu sendiri - sebuah tindakan penyeimbangan yang terus-menerus antara kesederhanaan dan kekuatan, antara keterbacaan manusia dan efisiensi mesin, antara produktivitas langsung dan pemeliharaan jangka panjang.
Seperti yang dicatat seorang komentator tentang pencarian konstan untuk alat yang lebih baik: Ini mengingatkan saya pada hal NoSQL dari dulu juga, disederhanakan menjadi 'bagaimana jika kita memasukkan gumpalan JSON ke dalam penyimpanan kunci/nilai?' Butuh bertahun-tahun untuk menyadari bahwa database relasional dan SQL sebenarnya tidak terlalu buruk. Pola menemukan kembali solusi yang sudah mapan ini tampaknya berulang dengan format data.
Referensi: Git, JSON dan Markdown walk into bar