Apakah Node.js suatu kerangka kerja? [Tutup]


35

Saya terus melihat perekrut, pengembang, dll. Merujuk ke Node.js sebagai kerangka kerja. Menurut pendapat saya, ini karena ketidaktahuan untuk apa Node.js sebenarnya.

Seringkali, dalam deskripsi pekerjaan, Node.js dikelompokkan sebagai perpustakaan di antara AngularJS , React , dll. Secara umum, saya melihatnya dimasukkan oleh seseorang yang tidak mengetahui perbedaannya (SDM, perekrut, dll.).

Menurut pendapat saya, Node.js adalah platform , atau lingkungan runtime; itu mematikan DOM API (JavaScript di browser) untuk berbagai API lainnya, seperti sistem file (karena berjalan sebagai server, dan bukan di browser).

Mengapa orang berpikir bahwa Node.js adalah kerangka kerja; Apakah aku salah? Apakah ini sebenarnya sebuah kerangka kerja?



5
Tidak terlalu, tetapi saya bisa melihat kebingungan.
ndugger

1
Dulu, ketika simpul pertama kali keluar, saya memposting jawaban pada SO yang mengatakan bahwa simpul itu bukan kerangka. Jawaban itu sangat tidak disukai pada saat itu. Saat ini, sangat-sangat sedikit orang yang menggunakan simpul percaya itu kerangka kerja. Ini kerangka kerja dalam arti yang sama bahwa Swift adalah kerangka kerja atau Go adalah kerangka kerja atau Karat adalah kerangka kerja. Bahasa pemrograman modern hanya memiliki API tingkat sangat tinggi yang dulu diimplementasikan sebagai kerangka kerja. "Platform" adalah kata yang bagus. Saya akan mengatakan itu sendiri adalah seorang juru bahasa (menggunakan makna tradisional unix dari kata itu)
slebetman

Perhatikan bahwa simpul tidak mematikan API DOM dan apa pun yang dapat Anda jalankan dengan javascript masih tersedia untuk Anda, dengan atau tanpa simpul.
Rob

@slebetman Apa arti "lain" dari juru bahasa? Saya tidak menyadari ada perdebatan di sana juga! : S
J. Abrahamson

Jawaban:


44

Agak sulit untuk mengatakannya karena kata-kata ini tidak terdefinisi dengan baik. Dalam bahasa umum, saya pikir itu agak tidak lazim untuk memanggil Node. Saya pikir itu kerangka kerja, tapi saya akan mengalami kesulitan berdebat mengapa tidak tepatnya.

Ini semua menjadi tidak pasti, dan saya sering melihat penggunaan bahasa yang sangat buruk, jadi saya akan secara eksplisit dan mulai dari bawah


JavaScript adalah bahasa komputer, yang berarti, secara sempit, seperangkat konvensi yang memungkinkan kita untuk membaca dan menafsirkan sekelompok teks sebagai memiliki semantik eksekusi - kata yang bagus untuk "cara menafsirkan bahasa sebagai seperangkat instruksi". Kelas-kelas program yang disebut interpreter , compiler , transpiler , linter , highlighters , dll. Semuanya memuat teks dan berupaya melakukan sesuatu dengan pemahaman konvensional tentang cara menjalankan kode ini.

  • Penerjemah sebenarnya melakukan semantik eksekusi dengan mengoperasikan beberapa mesin — biasanya komputer Anda. Anda dapat menganggap mereka sebagai orang kecil di dalam komputer Anda dengan membalik saklar seperti "cetak karakter ini" berdasarkan instruksi yang tertulis dalam program JavaScript Anda.
  • Compiler mencoba untuk mengkonversi teks JavaScript ke set teks baru yang memiliki semantik eksekusi untuk bahasa yang berbeda — mungkin dengan properti khusus yang dapat dieksekusi langsung oleh komputer.
  • Transpiler adalah bentuk kompiler umum yang mengambil teks JavaScript dan teks keluaran dari bahasa lain. Perbedaannya dengan demikian sedikit subyektif, tetapi biasanya orang menganggap kompiler sebagai keluaran kode tingkat sangat rendah dan transpiler sebagai keluaran kode tingkat tinggi .
  • Linters , highlighters , checker type , dll. Semuanya mengambil teks JavaScript dan mengeluarkan beberapa jenis produk analitik, misalnya teks yang disorot, yang dipengaruhi oleh semantik eksekusi, tetapi sebenarnya tidak mewakili itu.

Sekarang, mari kita menggali sedikit tentang semantik eksekusi. Secara umum, semantik eksekusi melibatkan proses membaca teks bahasa dan sampai pada deskripsi mesin abstrak atau deskripsi efek samping yang dapat diamati . Yang ingin saya sarankan adalah bahwa keduanya menganggap perlu ada semacam "API tingkat rendah" baik untuk mengoperasikan mesin atau untuk melakukan efek yang dapat diamati. Ini biasanya dianggap sebagai bagian dari lingkungan runtime

  • Lingkungan runtime atau runtime adalah seperangkat asumsi primitif yang diperlukan oleh konvensi bahasa agar dapat beroperasi. Sejauh bahasanya, mungkin ada beberapa asumsi tentang perilaku mereka, tetapi mereka tidak dapat diamati. Dalam citra juru bahasa di atas, "orang dalam" hanya menjentikkan sakelar runtime --- dia tidak dapat secara pribadi memeriksa apa yang mereka lakukan.

Kata runtime biasanya disalahgunakan berarti kumpulan yang diasumsikan primitif sendiri dan instantiasi aktual dari mereka.


Jadi, sekarang kita sampai pada sesuatu yang berbulu. Bahasa adalah seperangkat konvensi yang mengasumsikan keberadaan runtime untuk memberikan makna pada semantik pelaksanaannya. Itu tidak pernah "menyelidiki mereka" karena mereka berada di luar ruang lingkup.

Untuk benar-benar menggunakan bahasa Anda ingin sesuatu seperti kompiler atau juru bahasa di samping implementasi runtime. Compiler / interpreter dan runtime ini berjalan seiring dalam menjalankan kode Anda.

  • Chrome V8 , sering disebut engine , adalah paket yang berisi interpreter, compiler, implementasi runtime yang kompatibel dengan antarmuka runtime yang diminta oleh konvensi standar JavaScript ECMA.

Jadi di mana Node.js cocok dengan ini?

Kita harus memecahnya menjadi beberapa bagian:

  1. Node.js memperluas bahasa JavaScript dengan menyediakan sekumpulan primitif lingkungan runtime yang lebih besar — ​​yang berada di luar ruang lingkup standar ECMA. Ini termasuk hal-hal seperti file I / O . Ini berarti bahwa Node.js mengubah bahasa dan dalam beberapa hal bahasa baru: "JavaScript Node.js"
  2. Node.js, sebagai sebuah paket, berisi penerjemah dan kompiler. Itu hanya mencuri ini dari V8.
  3. Node.js menyediakan implementasi lingkungan runtime Node.js yang memungkinkan "JavaScript Node.js" dijalankan.
  4. Node.js menyediakan satu set perpustakaan standar yang dibangun di atas primitif baru yang membuatnya lebih mudah diakses oleh pengguna akhir "Node.js JavaScript".

Jadi Node.js banyak hal!

Tetapi apakah ini sebuah kerangka kerja?


Di sinilah terminologi benar-benar berantakan — tidak ada yang memiliki definisi yang baik, konsisten, bermakna tentang apa sebenarnya kerangka kerja itu.

Ada perdebatan yang mengamuk: "apa itu kerangka kerja versus perpustakaan" dan mereka berakhir dengan hal-hal yang tidak memuaskan seperti "perpustakaan adalah sesuatu yang Anda panggil dan kerangka kerja adalah sesuatu yang memanggil Anda". Saya bahkan tidak benar-benar ingin memberikan penjelasan yang menyedihkan hari itu — tetapi JavaScript, dan JavaScript khususnya, adalah pukulan besar bagi definisi ini karena keseluruhan teknik panggilan balik berarti Anda terus - menerus beralih antara menelepon dan dipanggil.

Menurut pendapat pribadi saya, ada sesuatu yang substansial di sini. Saya tidak ingin menggambar garis yang terang, tetapi saya hanya akan mengatakannya

  • Seperangkat kode mirip perpustakaan jika berfungsi seperti seperangkat lego : dapat dibagi dan dibuat untuk perakitan. Meskipun mungkin ada beberapa contoh cara menggunakan perpustakaan, umumnya pada pengguna sendiri untuk mengumpulkannya sesuai kebutuhan mereka.
  • Seperangkat kode mirip kerangka kerja jika tidak dapat dibagi dan menyiratkan konvensi *: memisahkan beberapa bagian dapat menyebabkan banyak asumsi gagal sehingga Anda harus memahami penggunaan konvensional untuk menggunakan kerangka kerja dengan benar.

Ini adalah garis gelombang tangan yang pasti, tapi saya ingin menarik poin yang sangat menarik tentang kerangka kerja:

Kerangka kerja menyiratkan seperangkat konvensi tentang bagaimana menafsirkan kode; karena itu mereka adalah bahasa dalam hak mereka sendiri.

Ini mungkin sesuatu yang juga ingin diperdebatkan orang, tetapi jika Anda membeli definisi saya sebelumnya bahwa suatu bahasa hanyalah seperangkat konvensi yang memberi kehidupan pada sekumpulan teks, maka setiap kali Anda meletakkan lapisan konvensi baru, Anda Saya sudah membangun bahasa baru. Mungkin dengan kerangka kerja bahan baku adalah interpretasi semantik dari bahasa inang mereka alih-alih file teks mentah, tetapi idenya sama!


Jadi dengan semua yang dikatakan, saya benar-benar senang memanggil Node.js sebuah kerangka kerja bahkan jika itu bertentangan dengan norma! Node.js menambahkan fungsionalitas ke JavaScript mentah dengan cara memperluas bahasa . Dengan itu membawa asumsi dan alat baru untuk bekerja dalam bahasa yang diperluas ini. Secara fungsional, ide-ide ini sama dengan ide-ide kerangka kerja lain yang diterima dengan baik seperti Ruby on Rails .

Saya berpendapat bahwa jika pada saat ini Anda merasa sedikit mual dan ingin berdebat bahwa ada perbedaan besar antara Ruby on Rails dan Node.js dengan cara ini maka saya di sana bersama Anda , tentu saja. Jenis dunia konseptual yang didiami keduanya secara dramatis berbeda - saya hanya ingin mengatakan bahwa mereka adalah hal yang sama: seperangkat konvensi untuk memperluas kekuatan bahasa dasar dalam domain tertentu.

Saya juga senang menyarankan bahwa domain Node.js kecil dan ketat sehingga konvensi yang ditambahkannya sederhana untuk dipikirkan dan relatif mudah dibuat benar. OTOH, Ruby on Rails hidup dalam domain kompleks "aplikasi web bisnis" yang tidak didefinisikan dengan baik, yang berarti bahwa konvensi yang dihimpunnya jelas tidak jelas dan rusak.


Tapi semua ini jauh dari kata, ya, perekrut mungkin tidak tahu apa artinya ketika mengatakan itu. Saya menduga "framework" hanya terdengar seperti kata yang lebih baik, lebih grokkable daripada "runtime" atau "engine".


hei, sangat seimbang! jadi probably have no idea,: 'framework' adalah sebuah kata yang dapat Anda pahami tanpa menjadi seorang programmer, fitur yang berguna, jika tidak digunakan ketika itu benar-benar akan membuat perbedaan.
n611x007

"Node.js menambahkan fungsionalitas ke JavaScript mentah dengan cara memperluas bahasa." Tidak benar, ini memperluas fungsionalitas dan bukan bahasa, itu tidak mengubah cara Anda perlu menulis kode seperti yang dibutuhkan banyak kerangka kerja. Ada fungsi atau objek lain yang ditambahkan seperti perpustakaan yang bisa ditambahkan. Anda dapat memanggilnya atau menggunakannya seperti fungsi atau objek baru. Gaya pemrograman tidak berubah, dasar-dasar bahasa sama 'hanya' menambahkan beberapa fungsi. Jadi ini bukan kerangka kerja atau memperluas bahasa, javascript dengan pustaka platform ditambahkan standar dan dengan demikian fungsionalitas.
Codebeat

Tentu, saya bisa sepenuhnya mengikuti sisi Anda. Saya pikir garis di sini tidak jelas. Apa pun cara berpikirnya masuk akal. Sebagai titik yang ketat, node memperluas JS dengan menyediakan FFI, yang kemudian menjadi bagian inti yang memungkinkan node selanjutnya menyediakan lebih banyak pustaka sistem. Di sisi lain, sedangkan "inti" simpul hanya runtime (dan FFI ini), sebagian besar waktu ketika orang membahas simpul mereka sebenarnya berarti "inti runtime, ekstensi FFI, dan fungsi perpustakaan dasar yang dibangun di atasnya" karena ini adalah bagaimana simpul dikemas.
J. Abrahamson

20

Node.js® adalah runtime JavaScript yang dibangun di atas mesin JavaScript V8 Chrome.

sumber

Node adalah runtime atau lingkungan. Ini bukan kerangka kerja. Orang (saya merasa) sering mendapatkan kesalahan ini karena kerangka kerja seperti express ada di mana-mana dengan simpul.

lebih banyak membaca tentang runtimes vs frameworks jika Anda tertarik.


inb4 "tetapi halaman tentang mengatakan 'Sebagai kerangka kerja yang didorong peristiwa asinkron' '" Saya sadar.
rlemon

3
Bukankah tertanam v8 runtime? ;-)
johannes

@ Johannes Saya cenderung setuju dengan Anda tentang ini. V8 adalah runtime dan node hanya memperluas alat yang tersedia untuk pengembang (http server, util, dll) jadi saya pikir label framework masih berfungsi. Namun, ini adalah lingkungan v8 yang dimodifikasi; simpul bukanlah sesuatu yang baru saja Anda "sertakan" dalam proyek Anda. Kurasa itu semua masalah perspektif.
nick

@ rlemon, kerangka kerja bagian telah dihapus.
ebram khalil
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.