Diagram Venn curl-wget

 (daniel.haxx.se)
2 poin oleh GN⁺ 2023-09-05 | 1 komentar | Bagikan ke WhatsApp
  • wget bukan pesaing langsung curl, melainkan sebaiknya dipandang sebagai alat dengan sebagian fungsi yang tumpang tindih yang bisa digunakan bersama tergantung pekerjaannya
  • Kriteria pemilihannya bukan preferensi alat, melainkan apakah lebih cocok untuk menyelesaikan pekerjaan, dan jika wget lebih sesuai maka gunakan wget
  • Perbedaan teknis dan area yang bertumpang tindih antara curl dan wget dirangkum dalam diagram Venn agar bisa dilihat sekilas, dan tersedia juga gambar resolusi penuh
  • Kedua proyek ini bukan berada dalam hubungan saling berlawanan; pihak curl pernah menyumbangkan kode ke wget dan beberapa maintainer wget juga pernah berkontribusi ke curl
  • Kesalahan atau hal yang terlewat dalam diagram dapat diperbarui, dan detail lebih lanjut bisa dilihat di dokumen perbandingan terpisah serta tabel perbandingan alat unduh

Kriteria untuk melihat curl dan wget

  • wget lebih dekat sebagai alat pendamping daripada pesaing curl
  • Kedua alat memiliki sebagian fungsi yang bertumpang tindih, tetapi yang penting bukan bersikeras pada alat tertentu melainkan memilih yang sesuai dengan pekerjaan yang ingin diselesaikan
  • Jika dalam situasi tertentu wget lebih cocok untuk menuntaskan pekerjaan, maka lebih baik menggunakan wget

Perbedaan yang dirangkum lewat diagram Venn

  • Diagram Venn dibuat untuk menunjukkan secara visual perbedaan teknis dan beberapa kemiripan antara curl dan wget
  • Gambar diagram dapat diklik untuk melihat versi resolusi penuhnya
  • Penulis meminta agar masalah atau item yang terlewat diberitahukan, dan bila perlu diagram dapat diperbarui

Kolaborasi antarproyek

  • Pihak curl pernah menyumbangkan kode ke wget
  • Beberapa maintainer wget juga pernah berkontribusi ke curl
  • Hubungan kedua proyek ini lebih dekat ke kolaborasi daripada persaingan atau pertentangan

Materi perbandingan lain yang layak dilihat

Bacaan terkait

1 komentar

 
GN⁺ 2023-09-05
Opini Hacker News

  • Menurut saya, di sisi Wget setidaknya perlu dimasukkan default yang masuk akal, resume, dan retry saat terjadi error
    Baru-baru ini saya harus menulis skrip untuk mengunduh file yang sangat besar di koneksi yang tidak stabil, dan pemahaman umum di kalangan engineer adalah bahwa untuk pekerjaan seperti ini sebaiknya memakai Wget
    Saya juga mencoba curl, tetapi secara default ia tidak melakukan resume atau retry, dan saya harus membaca manual untuk menentukan berbagai opsi dan argumen. Rasanya perilaku seperti ini seharusnya menjadi default
    Pada Wget, cukup satu opsi --continue untuk mengaktifkan resume di semua situasi, termasuk setelah crash, dan di pengantar manualnya juga tertulis bahwa Wget dirancang agar tangguh di jaringan yang lambat atau tidak stabil, sehingga jika unduhan gagal, ia akan terus mencoba ulang sampai seluruh file terunduh
    Dengan curl pun mungkin semua opsi bisa disetel agar andal di koneksi buruk, tetapi Wget tampaknya sudah mengaktifkan perilaku default seperti itu, sehingga membuat saya percaya ia akan bertindak sesuai harapan bahkan pada skenario error yang tidak sempat saya uji sendiri. Meski protokol HTTP diperbarui, Wget baru kemungkinan akan mendukungnya secara default, sedangkan curl mungkin membutuhkan switch baru untuk mengaktifkan perilaku yang lebih baik, dan itu tidak bisa ditambahkan setelah produk dirilis
    Bagi saya, curl adalah alat level rendah yang hebat dan sangat serbaguna, dan CLI-nya juga mencerminkan karakter itu, tetapi untuk pekerjaan sehari-hari saya lebih suka Wget karena perilaku default-nya jauh lebih baik. Manualnya juga lebih cepat dipindai, mungkin karena tidak mendukung semua protokol esoteris yang disebutkan di sini

    • Saya setuju soal default yang masuk akal
      Fakta bahwa wget url saja sudah mengunduh dan menyimpan URL membuat Wget menang untuk penggunaan command line, menurut saya
    • curl juga punya tepat fitur itu. Resume memakai flag -C, dan retry memakai --retry
      Secara pribadi, saya merasa default curl juga cukup masuk akal, dan untuk alat seperti curl saya tidak ingin salah satu dari keduanya aktif secara default
    • Opsi -i pada Wget, yang memungkinkan membaca URL dari file, juga perlu ditambahkan
      Terutama wget -i -, karena membaca dari standard input, sangat berguna dalam pipeline
      Setahu saya curl tidak bisa melakukan ini. Biasanya orang menyarankan memakai xargs, tetapi itu menunggu sampai semua URL datang baru menjalankan curl, sehingga paralelisme antara perintah pembuat URL dan perintah unduhan hilang; jadi sebagai pengganti agak kurang pas
    • Kedua alat punya kegunaan masing-masing. Dengan hadirnya large language model seperti ChatGPT, menurut saya jauh lebih mudah mendapatkan mantra command line yang tepat apa pun alat yang dipakai
      Bahkan jika dulu pernah membaca manual, tidak mudah mengingat flag yang tepat, dan memverifikasi command line yang dihasilkan biasanya lebih ringan daripada merangkainya dari nol sambil membaca manual
      Di web modern, kadang lebih mudah memakai alat seperti Puppeteer dalam skrip buatan sendiri. Terutama jika situs yang berinteraksi banyak memakai JavaScript
    • Parser URL curl yang jauh lebih ketat daripada wget juga secara pribadi mengganggu saya
      Misalnya, $ curl -sSLOJ 'example.com/file name.txt' menghasilkan error curl: (3) URL using bad/illegal format or missing URL, dan $ curl -sSLOJ 'example.com/file%20name.txt' membuat file bernama file%20name.txt
      Sebaliknya, wget membuat file "file name.txt" dari kedua URL itu tanpa flag tambahan. Namun karena URL contoh ini 404, secara ketat wget juga perlu ditambahi --content-on-error

  • Bagi banyak orang, perbedaan intinya mungkin adalah antara alat yang secara default menulis ke standard output dan alat yang secara default membuat file

    • Atau alat yang secara default bisa di-pipe ke sh ;-)

  • Bagi saya, fitur penentu Wget adalah bahwa secara default ia mengunduh file dengan nama file yang diturunkan dari URL
    Jika menjalankan wget url://to/file.htm, akan muncul file bernama "file.htm" di direktori kerja saat ini
    Dengan curl, harus menulis seperti curl url://to/file.htm > file.htm, atau memakai mantra lain yang kurang nyaman

    • curl -O
      https://curl.se/docs/manpage.html#-O
    • Memang, tapi ada kasus seperti wget "url://to/file.htm?uid=foo&q=bar&rnd=4"
    • Saya selalu menganggap ini sebagai fitur Wget yang keliru. Alasannya prinsip umum bahwa utilitas command line harus menulis hasil utamanya ke standard output kecuali diberi instruksi lain
    • curl -O lebih nyaman
      Jika “fitur penentu” itu dianalogikan dengan cat, maka cat file.html berubah menjadi cat file.html > file.html. Lalu saat benar-benar ingin menampilkan, bukan menyalin, kita harus menulis semacam cat file.html -o -; jadi saya senang curl tidak punya fitur seperti itu

  • Daniel Stenberg termasuk jenis developer langka yang mencurahkan hati dan jiwa ke ciptaannya
    Di big tech modern, developer yang seperti bayangan terlihat seperti roda gigi yang dapat diganti dalam mesin pencetak uang, dan sifat seperti itu tampaknya makin menghilang
    Ia tampak memperlakukan curl sebagai jejak yang ia tinggalkan di dunia IT

    • Free software penuh dengan orang seperti ini. Karena itu saya memakai free software meski secara teknis lebih inferior
      Tentu sekarang banyak juga yang sebenarnya lebih baik secara teknis, sehingga pilihannya makin mudah
    • Kalau bekerja di perusahaan, mungkin orang tidak mencurahkan hati ke ciptaannya, tetapi jika punya proyek pribadi populer yang menghasilkan banyak uang tunai, siapa pun mungkin akan berdedikasi sebesar itu

  • Perbandingan ini tampaknya agak lama. Misalnya, di diagram, dua hal berikut hilang dari sisi Wget
    HTTP PUT bisa dilakukan dengan wget --method=PUT --body-data=, dan proxy serta HTTPS juga bisa seperti wget --use-proxy=on --https_proxy=[https://example.com](<https://example.com>;)
    curl memang secara konsisten punya lebih banyak opsi dan fleksibilitas, tetapi dari banyak item di sisi kanan diagram Venn, ada beberapa yang juga bisa dilakukan Wget sampai tingkat tertentu

    • Berdasarkan halaman manual, sepertinya ada dukungan FTP juga

  • Wah, saya tidak tahu curl mendukung protokol sebanyak ini. Meski begitu, area irisan kecil itu mungkin bagian yang benar-benar dipakai oleh lebih dari 90% pengguna curl/Wget
    Dari sudut pandang developer, area yang tumpang tindih tidak terlalu besar, tetapi dari sudut pandang pengguna bisa terlihat jauh lebih besar

  • Bagian terbaik dari tulisan itu bagi saya adalah kalimat ini
    “Saya pernah berkontribusi kode ke wget. Beberapa maintainer wget juga berkontribusi ke curl. Kami semua berteman.”

  • Perbandingan yang dibuat Daniel Stenberg juga wajib dilihat
    https://daniel.haxx.se/docs/curl-vs-wget.html

    • Perbandingan baru ini juga dibuat oleh Daniel Stenberg dan di-host di domain yang sama, tetapi diposting di blognya, bukan di dokumentasi curl

  • Dulu saya memakai Wget ketika ingin melakukan mirroring sebuah website. Wget adalah alat yang terspesialisasi
    curl adalah library request serbaguna dengan frontend CLI, dan juga sering disematkan di program lain atau dipakai seperti API library standar di PHP dan lain-lain

    • Secara pribadi saya suka httrack untuk mirroring, tetapi Wget punya fitur konversi href/src sehingga kadang lebih cocok untuk tujuan tertentu

  • Penggunaan paling umum tampaknya adalah bagian yang tumpang tindih di antara keduanya. Jadi saya ingin melihat diagram Venn yang menunjukkan sistem operasi dan image Docker mana saja yang memasang masing-masing alat secara default