🤚🏽 🥈 👩🏽‍🤝‍👩🏻 5 klaim ke Deno 🚸 🤳🏿 💆🏻

Kata pengantar

Saya bukan bagian dari tim deno. Saya bukan penggemarnya. Saya tidak mengikutinya. Aku bahkan tidak benar-benar percaya padanya. Tetapi melihat reaksi negatif dari komunitas, saya tidak bisa membantu tetapi campur tangan. Dalam artikel ini, saya ingin mempertimbangkan klaim paling umum terhadap Deno dan menawarkan sudut pandang alternatif.

Deno - pembunuh NodeJs

Ini tidak benar. Cara ini hanya dipromosikan oleh "saksi mata", penggemar gila, atau penerjemah yang hype. Sejauh yang saya tahu, bahkan Ryan Dahl sendiri (penulis Deno) tidak memposisikan perkembangannya sebagai pengganti atau alternatif untuk NodeJs. Sebaliknya, visinya adalah "apa yang mungkin menjadi NodeJs yang sama di masa depan." Konsepnya, jika Anda mau (kami tidak memarahi konsep mobil atau smartphone karena tidak praktis dalam realitas modern). Dari sudut pandang Ryan, NodeJs memiliki beberapa masalah. Dan dia menunjukkan kepada masyarakat ide tertentu tentang bagaimana masalah ini bisa diselesaikan. Dan Anda dapat berpartisipasi dalam ini. Datanglah ke GitHub sekarang dan jelaskan masalah arsitektur yang Anda lihat. Diskusikan mereka. Munculkan solusi.

Saya tidak berpikir Deno akan pernah menggantikan NodeJs. Tetapi bisa menjadi baginya seperti apa TypeScript untuk JavaScript.

Impor dengan URL

Banyak orang melihatnya sedikit dari sudut yang salah. Idenya adalah untuk menjatuhkan daftar ketergantungan global untuk seluruh proyek. Sehingga alih-alih satu package.json besar Anda memiliki daftar dependensi independen Anda sendiri di setiap modul / file Anda. Saya melihat beberapa keuntungan dalam hal ini.

Jika Anda perlu menulis beberapa fitur, Anda tidak perlu melihat dependensi apa yang sudah digunakan dalam proyek. Anda tidak terbatas pada mereka. Anda menggunakan apa yang Anda butuhkan.
Anda dapat menambahkan fungsionalitas tanpa melihat warisan. Modul baru akan memiliki dependensi sendiri, dan yang lama akan memiliki sendiri.
Selama migrasi proyek besar ke versi baru dari beberapa dependensi, Anda dapat mengubah basis kode dan meluncurkan perubahan ini di bagian-bagian.

Tetapi untuk pendekatan ini, Anda perlu kemampuan untuk menggambarkan dependensi untuk setiap modul. Nama, versi, dan tempat untuk mendapatkan ketergantungan ini. Akibatnya, impor dengan URL. Dan itu bahkan bukan gagasan Deno. Ini adalah bagian dari standar . Hanya saja semua orang terbiasa bekerja seperti biasanya. Tapi ini bukan satu-satunya cara.

Tetapi bagaimana saya sekarang bekerja tanpa internet?

Sama seperti Anda akan bekerja dengan NodeJs. Apa Deno, bahwa NodeJs mengunduh dependensi di direktori terpisah. Hanya di NodeJs Anda menjalankan ini npm install, dan Deno melakukan ini secara otomatis saat pertama kali Anda meluncurkannya.

Kedengarannya menarik, tetapi saya menolak!

Tidak masalah. Ada hal seperti itu - peta impor . Dan Deno mendukungnya , meski tidak sepenuhnya. Dengan demikian, Anda dapat menggambarkan sinonim untuk semua dependensi dengan membuka analog package.json. Tetapi Anda tidak akan terbatas pada ini:

Modul individual masih dapat menggunakan versi ketergantungan mereka sendiri, mengabaikan peta impor sesuai kebutuhan.
Spesifikasi peta impor menunjukkan kemampuan untuk menentukan beberapa sumber untuk diunduh. Deno saat ini tidak mendukung ini. Tetapi secara teknis itu mungkin. Anda dapat menunjukkan beberapa sumber, dan jika satu tidak tersedia, ketergantungan akan diunduh dari yang lain.
```
{
   "imports": {
      "moment/": [
         "https://deno.land/x/moment/",
         "https://raw.githubusercontent.com/lisniuse/deno_moment/master/"
      ]
   }
}
```

Tanpa npm, saya tidak dapat mengirimkan utilitas konsol secara global!

Sebenarnya Anda bisa . deno installIni analog npm install --global. Deno mengunduh, mengkompilasi pustaka yang diperlukan ke dalam biner, dan menyimpannya secara global. Perbedaannya adalah Anda harus memberi perpustakaan semacam izin. Yaitu, paket yang diinstal secara global tidak akan mendapatkan akses ke jaringan, atau ke file, atau di mana pun tanpa persetujuan Anda.

Perasaan aneh deja vu

Dan itu bukan tanpa ketelitian. Deno adalah NodeJs yang sama . Saya hanya melihat beberapa perbedaan:

Deno menolak kompatibilitas ke belakang. Apa yang memungkinkannya untuk menyadari hal yang sama, tidak menggunakan sepedanya sendiri, tetapi sepeda yang dijelaskan dalam spesifikasi bahasa. Saya yakin jika semacam "Node-next" keluar tanpa kompatibilitas, kita akan mendapatkan hal yang sama seperti yang ditawarkan Deno. Dan NodeJs secara bertahap bergerak ke arah ini: semua chip ES baru (seperti modul ES, tingkat atas menunggu, dll.) Secara bertahap diperkenalkan ke NodeJs.
Penolakan daftar umum dependensi. Ini bisa menjadi plus atau minus. Itu tergantung pada kasus spesifik. Tetapi tidak dapat dipungkiri bahwa arsitektur semacam itu memiliki hak untuk hidup.
Idenya adalah untuk mencegah skrip mengakses sistem tanpa izin eksplisit.

Itu semua perbedaan pendapat saya. Jadi saya tidak melihat alasan untuk membenci Deno. Apakah itu orang-orang PR agresifnya :)

5 klaim ke Deno