Apa itu Node.js? [Tutup]

Saya tidak sepenuhnya mendapatkan apa Node.js adalah semua tentang. Mungkin itu karena saya terutama pengembang aplikasi bisnis berbasis web. Apa itu dan apa gunanya?

Pemahaman saya sejauh ini adalah:

1. Model pemrograman event driven, terutama cara menangani I / O .
2. Ini menggunakan JavaScript dan parser adalah V8 .
3. Dapat dengan mudah digunakan untuk membuat aplikasi server bersamaan.

Apakah pemahaman saya benar? Jika ya, lalu apa manfaat dari I / O yang terjadi, apakah itu lebih untuk hal-hal konkurensi? Juga, apakah arah Node.js menjadi kerangka kerja seperti, model pemrograman berbasis JavaScript (berbasis V8)?

Saya pikir kelebihannya adalah:

1. Pengembangan web dalam bahasa dinamis (JavaScript) pada VM yang sangat cepat (V8). Ini jauh lebih cepat daripada Ruby, Python, atau Perl.

2. Kemampuan untuk menangani ribuan koneksi bersamaan dengan overhead minimal pada satu proses.

3. JavaScript sangat cocok untuk loop acara dengan objek dan penutupan fungsi kelas satu. Orang-orang sudah tahu cara menggunakannya dengan cara menggunakannya di browser untuk merespons acara yang dimulai pengguna.

4. Banyak orang sudah tahu JavaScript, bahkan orang yang tidak mengaku sebagai programmer. Ini bisa dibilang bahasa pemrograman paling populer.

5. Menggunakan JavaScript pada server web dan juga browser mengurangi ketidakcocokan impedansi antara dua lingkungan pemrograman yang dapat mengkomunikasikan struktur data melalui JSON yang bekerja sama di kedua sisi persamaan. Kode validasi formulir duplikat dapat dibagikan antara server dan klien, dll.

Saya menggunakan Node.js di tempat kerja, dan merasa sangat kuat. Terpaksa memilih satu kata untuk menggambarkan Node.js, saya akan mengatakan "menarik" (yang bukan kata sifat murni positif). Komunitas itu bersemangat dan berkembang. JavaScript, meskipun keanehannya bisa menjadi bahasa yang bagus untuk kode. Dan Anda setiap hari akan memikirkan kembali pemahaman Anda sendiri tentang "praktik terbaik" dan pola-pola kode yang terstruktur dengan baik. Ada energi besar gagasan mengalir ke Node.js sekarang, dan bekerja di dalamnya memaparkan Anda pada semua pemikiran ini - angkat berat mental yang hebat.

Node.js dalam produksi sudah pasti dimungkinkan, tetapi jauh dari penyebaran "turn-key" yang tampaknya dijanjikan oleh dokumentasi. Dengan Node.js v0.6.x, "cluster" telah diintegrasikan ke dalam platform, menyediakan salah satu blok bangunan penting, tetapi skrip "production.js" saya masih ~ 150 baris logika untuk menangani hal-hal seperti membuat log direktori, mendaur ulang pekerja yang mati, dll. Untuk layanan produksi "serius", Anda juga harus siap untuk membatasi koneksi masuk dan melakukan semua hal yang dilakukan Apache untuk PHP . Agar adil, Ruby on Rails memiliki masalah persis ini . Ini diselesaikan melalui dua mekanisme yang saling melengkapi: 1) Menempatkan Ruby di Rails / Node.Apache / Lighttd ). Server web dapat secara efisien menyajikan konten statis, mengakses logging, menulis ulang URL, mengakhiri SSL , menegakkan aturan akses, dan mengelola beberapa sub-layanan. Untuk permintaan yang mengenai layanan simpul aktual, server web proksi permintaan melalui. 2) Menggunakan kerangka kerja seperti Unicorn yang akan mengelola proses pekerja, mendaur ulangnya secara berkala, dll. Saya belum menemukan kerangka kerja Node.js yang tampaknya sepenuhnya dipanggang; mungkin ada, tapi saya belum menemukannya dan masih menggunakan ~ 150 baris di "production.js" linting tangan saya.

Kerangka kerja membaca seperti Express membuatnya tampak seperti praktik standar adalah hanya melayani semuanya melalui satu layanan Node.js yang serba bisa ... "app.use (express.static (__ dirname + '/ public'))" . Untuk layanan dan pengembangan yang lebih rendah, itu mungkin bagus. Tetapi segera setelah Anda mencoba untuk menempatkan beban waktu yang besar pada layanan Anda dan menjalankannya 24/7, Anda akan dengan cepat menemukan motivasi yang mendorong situs-situs besar untuk membuat kode-C yang dipanggang dengan baik seperti Nginx yang membuka situs mereka dan menangani semua permintaan konten statis (... hingga Anda menyiapkan CDN , seperti Amazon CloudFront )). Untuk pandangan negatif yang agak lucu dan tanpa malu-malu tentang hal ini, lihat pria ini .

Node.js juga menemukan semakin banyak penggunaan non-layanan. Bahkan jika Anda menggunakan sesuatu yang lain untuk menyajikan konten web, Anda mungkin masih menggunakan Node.js sebagai alat build, menggunakan modul npm untuk mengatur kode Anda, Browserify untuk menjahitkannya menjadi satu aset, dan uglify-js untuk memperkecilnya agar dapat digunakan. . Untuk berurusan dengan web, JavaScript adalah pasangan impedansi sempurna dan sering kali menjadikannya rute serangan paling mudah. Misalnya, jika Anda ingin melihat-lihat banyak muatan respons JSON , Anda harus menggunakan modul garis bawah-CLI saya , sabuk utilitas data terstruktur.

Pro kontra:

• Pro: Untuk seorang pria server, menulis JavaScript di backend telah menjadi "obat gerbang" untuk mempelajari pola UI modern. Saya tidak lagi takut menulis kode klien.
• Pro: Cenderung mendorong pengecekan error yang tepat (err dikembalikan oleh hampir semua panggilan balik, mengganggu programmer untuk menanganinya; juga, async.js dan perpustakaan lain menangani paradigma "gagal jika ada subtugas ini gagal" jauh lebih baik daripada kode sinkron khas) )
• Pro: Beberapa tugas yang menarik dan biasanya sulit menjadi sepele - seperti mendapatkan status pada tugas-tugas dalam penerbangan, berkomunikasi antara pekerja, atau berbagi keadaan cache
• Pro: Komunitas besar dan berton-ton perpustakaan hebat berdasarkan paket manager yang solid (npm)
• Con: JavaScript tidak memiliki perpustakaan standar. Anda menjadi terbiasa mengimpor fungsionalitas yang rasanya aneh ketika Anda menggunakan JSON.parse atau metode build in lainnya yang tidak perlu menambahkan modul npm. Ini berarti ada lima versi dari semuanya. Bahkan modul yang termasuk dalam "inti" Node.js memiliki lima varian lebih jika Anda tidak puas dengan implementasi standar. Ini mengarah pada evolusi yang cepat, tetapi juga beberapa tingkat kebingungan.

Lawan model satu proses-per-permintaan ( LAMP ) sederhana:

• Pro: Dapat diukur ke ribuan koneksi aktif. Sangat cepat dan sangat efisien. Untuk armada web, ini bisa berarti pengurangan 10X dalam jumlah kotak yang diperlukan dibandingkan PHP atau Ruby
• Pro: Menulis pola paralel itu mudah. Bayangkan Anda perlu mengambil tiga (atau N) gumpalan dari Memcached . Lakukan ini di PHP ... apakah Anda baru menulis kode untuk mengambil gumpalan pertama, lalu yang kedua, lalu yang ketiga? Wow, itu lambat. Ada modul PECL khusus untuk memperbaiki masalah spesifik untuk Memcached, tetapi bagaimana jika Anda ingin mengambil beberapa data Memcached secara paralel dengan kueri basis data Anda? Dalam Node.js, karena paradigma ini tidak sinkron, memiliki permintaan web melakukan banyak hal secara paralel sangat alami.
• Con: Kode asinkron pada dasarnya lebih kompleks daripada kode sinkron, dan kurva pembelajaran di muka bisa sulit bagi pengembang tanpa pemahaman yang solid tentang apa arti sebenarnya eksekusi bersamaan. Namun, ini jauh lebih sulit daripada menulis segala jenis kode multithread dengan penguncian.
• Con: Jika permintaan komputasi intensif berjalan, misalnya, 100 ms, itu akan menghentikan pemrosesan permintaan lain yang sedang ditangani dalam proses Node.js yang sama ... AKA, multitasking koperasi . Ini dapat dikurangi dengan pola Pekerja Web (memutar subproses untuk menangani tugas yang mahal). Atau, Anda bisa menggunakan sejumlah besar pekerja Node.js dan hanya membiarkan masing-masing menangani satu permintaan secara bersamaan (masih cukup efisien karena tidak ada proses daur ulang).
• Con: Menjalankan sistem produksi JAUH lebih rumit daripada model CGI seperti Apache + PHP, Perl , Ruby , dll. Pengecualian yang tidak ditangani akan menurunkan seluruh proses, memerlukan logika untuk memulai kembali pekerja yang gagal (lihat klaster ). Modul dengan kode asli buggy dapat merusak prosesnya. Setiap kali seorang pekerja meninggal, permintaan apa pun yang ditanganinya akan dibatalkan, sehingga satu API buggy dapat dengan mudah menurunkan layanan untuk API cohosted lainnya.

Lawan menulis layanan "nyata" di Java / C # / C (C? Sungguh?)

• Pro: Melakukan asynchronous di Node.js lebih mudah daripada melakukan thread-safety di tempat lain dan bisa dibilang memberikan manfaat lebih besar. Node.js sejauh ini merupakan paradigma asinkron yang paling tidak menyakitkan yang pernah saya gunakan. Dengan perpustakaan yang baik, hanya sedikit lebih sulit daripada menulis kode sinkron.
• Pro: Tidak ada bug multithreading / mengunci. Benar, Anda berinvestasi di muka dalam menulis lebih banyak kode verbose yang mengekspresikan alur kerja asinkron yang tepat tanpa operasi pemblokiran. Dan Anda perlu menulis beberapa tes dan membuatnya bekerja (itu adalah bahasa scripting dan nama variabel fingering yang gemuk hanya tertangkap pada waktu unit-test). TETAPI, begitu Anda berhasil, area permukaan untuk heisenbug - masalah aneh yang hanya muncul sekali dalam jutaan berjalan - area permukaan itu hanya jauh lebih rendah. Pajak yang menulis kode Node.js sangat dimuat di depan ke fase pengkodean. Maka Anda cenderung berakhir dengan kode stabil.
• Pro: JavaScript jauh lebih ringan untuk mengekspresikan fungsionalitas. Sulit untuk membuktikan ini dengan kata-kata, tetapi JSON , pengetikan dinamis, notasi lambda, pewarisan prototypal, modul ringan, apa pun ... cenderung mengambil kode kurang untuk mengekspresikan ide yang sama.
• Con: Mungkin Anda benar-benar suka layanan pengkodean di Jawa?

Untuk perspektif lain tentang JavaScript dan Node.js, lihat Dari Java ke Node.js , posting blog tentang tayangan pengembang Java dan pengalaman mempelajari Node.js.

Modul Saat mempertimbangkan simpul, perlu diingat bahwa perpustakaan JavaScript pilihan Anda akan MEMBENTUK pengalaman Anda. Kebanyakan orang menggunakan setidaknya dua, pembantu pola asinkron (Step, Futures, Async), dan modul gula JavaScript ( Underscore.js ).

Gula Pembantu / JavaScript:

• Underscore.js - gunakan ini. Lakukan saja. Itu membuat kode Anda bagus dan dapat dibaca dengan hal-hal seperti _.isString (), dan _.isArray (). Saya tidak begitu yakin bagaimana Anda bisa menulis kode aman jika tidak. Juga, untuk meningkatkan command-line-fu, lihat Underscore-CLI saya sendiri .

Modul Pola Asinkron:

• Langkah - cara yang sangat elegan untuk mengekspresikan kombinasi tindakan serial dan paralel. Rekomendasi pribadi saya. Lihat posting saya tentang seperti apa kode Langkah.
• Futures - cara yang jauh lebih fleksibel (apakah itu benar-benar hal yang baik?) Untuk mengekspresikan pemesanan melalui persyaratan. Dapat mengekspresikan hal-hal seperti "mulai a, b, c secara paralel. Ketika A, dan B selesai, mulai AB. Ketika A, dan C selesai, mulai AC." Fleksibilitas semacam itu membutuhkan kehati-hatian untuk menghindari bug dalam alur kerja Anda (seperti tidak pernah menelepon kembali, atau menelepon berkali-kali). Lihat posting Raynos tentang penggunaan futures (ini adalah postingan yang membuat saya "mendapatkan" futures).
• Async - perpustakaan yang lebih tradisional dengan satu metode untuk setiap pola. Saya mulai dengan ini sebelum konversi agama saya ke langkah dan realisasi selanjutnya bahwa semua pola di Async dapat diekspresikan dalam Langkah dengan satu paradigma yang lebih mudah dibaca.
• TameJS - Ditulis oleh OKCupid, ini adalah precompiler yang menambahkan bahasa baru "menunggu" untuk menulis alur kerja serial dan paralel secara elegan. Polanya terlihat menakjubkan, tetapi memang membutuhkan pra-kompilasi. Saya masih mengambil keputusan tentang hal ini.
• StreamlineJS - pesaing ke TameJS. Saya condong ke arah Jin, tetapi Anda dapat mengambil keputusan sendiri.

Atau untuk membaca semua tentang perpustakaan asinkron, lihat wawancara panel ini dengan penulis.

Kerangka Web:

• Express Great Ruby on Rails-esk framework untuk mengatur situs web. Menggunakan JADE sebagai mesin templating XML / HTML, yang membuat membangun HTML jauh lebih menyakitkan, bahkan hampir elegan.
• jQuery Meskipun bukan secara teknis modul simpul, jQuery dengan cepat menjadi standar de-facto untuk antarmuka pengguna sisi klien. jQuery menyediakan pemilih seperti CSS ke 'kueri' untuk set elemen DOM yang kemudian dapat dioperasikan (set handler, properti, gaya, dll). Sepanjang nada yang sama, kerangka Bootstrap CSS Twitter , Backbone.js untuk pola MVC , dan Browserify.js untuk menjahit semua file JavaScript Anda menjadi satu file. Modul-modul ini semuanya menjadi standar de-facto sehingga Anda setidaknya harus memeriksanya jika Anda belum pernah mendengarnya.

Pengujian:

• JSHint - Harus digunakan; Saya tidak menggunakan ini pada awalnya yang sekarang tampaknya tidak bisa dipahami. JSLint menambahkan kembali banyak verifikasi dasar yang Anda peroleh dengan bahasa yang dikompilasi seperti Java. Tanda kurung yang tidak cocok, variabel yang tidak dideklarasikan, jenis huruf dari banyak bentuk dan ukuran. Anda juga dapat mengaktifkan berbagai bentuk apa yang saya sebut "mode anal" di mana Anda memverifikasi gaya ruang kosong dan yang lainnya, yang OK jika itu adalah cangkir teh Anda - tetapi nilai sebenarnya berasal dari mendapatkan umpan balik instan pada nomor baris persis di mana Anda lupa penutupan ")" ... tanpa harus menjalankan kode Anda dan menekan garis yang menyinggung. "JSHint" adalah varian yang lebih dapat dikonfigurasi dari Douglas Crockford 's JSLint .
• Pesaing Mocha ke Sumpah yang mulai saya sukai. Kedua kerangka tersebut menangani dasar-dasarnya dengan cukup baik, tetapi pola yang kompleks cenderung lebih mudah untuk diekspresikan dalam Mocha.
• Sumpah Sumpah benar-benar sangat elegan. Dan itu mencetak laporan indah (--spec) yang menunjukkan kepada Anda kasus uji mana yang lulus / gagal. Habiskan 30 menit untuk mempelajarinya, dan Anda dapat membuat tes dasar untuk modul Anda dengan sedikit usaha.
• Zombie - Pengujian tanpa kepala untuk HTML dan JavaScript menggunakan JSDom sebagai "browser" virtual. Hal yang sangat kuat. Gabungkan dengan Replay untuk mendapatkan tes deterministik cepat dalam kode browser.
• Sebuah komentar tentang cara "berpikir tentang" pengujian:
  • Pengujian bersifat non-opsional. Dengan bahasa dinamis seperti JavaScript, ada sangat sedikit pemeriksaan statis. Misalnya, meneruskan dua parameter ke metode yang mengharapkan 4 tidak akan rusak hingga kode dieksekusi. Bilah cukup rendah untuk membuat bug di JavaScript. Tes dasar sangat penting untuk memperbaiki kesenjangan verifikasi dengan bahasa yang dikompilasi.
  • Lupakan validasi, cukup buat kode Anda dieksekusi. Untuk setiap metode, kasus validasi pertama saya adalah "tidak ada istirahat", dan itulah yang paling sering terjadi. Membuktikan bahwa kode Anda berjalan tanpa membuang tangkapan 80% bug dan akan melakukan banyak hal untuk meningkatkan kepercayaan kode Anda sehingga Anda akan menemukan diri Anda kembali dan menambahkan kasus validasi bernuansa yang Anda lewatkan.
  • Mulai dari yang kecil dan hancurkan penghalang inersia. Kita semua malas, dan terdesak waktu, dan mudah untuk melihat pengujian sebagai "pekerjaan ekstra". Jadi, mulailah dari yang kecil. Tulis test case 0 - muat modul Anda dan laporkan keberhasilan. Jika Anda memaksakan diri untuk melakukan hal ini, maka penghalang inersia untuk pengujian rusak. Itu <30 menit untuk melakukannya pertama kali, termasuk membaca dokumentasi. Sekarang tulis test case 1 - panggil salah satu metode Anda dan verifikasi "tidak ada istirahat", yaitu, bahwa Anda tidak mendapatkan kesalahan kembali. Test case 1 akan membawa Anda kurang dari satu menit. Dengan inersia yang hilang, semakin mudah untuk memperluas cakupan pengujian Anda.
  • Sekarang kembangkan tes Anda dengan kode Anda. Jangan terintimidasi oleh seperti apa tes ujung-ke-ujung yang "benar" dengan server tiruan dan semua itu. Kode mulai sederhana dan berkembang untuk menangani kasus baru; tes juga harus. Saat Anda menambahkan kasus baru dan kompleksitas baru ke kode Anda, tambahkan kasus uji untuk menggunakan kode baru. Ketika Anda menemukan bug, tambahkan verifikasi dan / atau kasing baru untuk menutupi kode yang salah. Ketika Anda melakukan debug dan kehilangan kepercayaan pada sepotong kode, kembali dan tambahkan tes untuk membuktikan bahwa itu melakukan apa yang Anda pikirkan. Ambil string contoh data (dari layanan lain yang Anda panggil, situs web yang Anda gesek, apa pun) dan berikan mereka ke kode parsing Anda. Beberapa kasus di sini, validasi ditingkatkan di sana, dan Anda akan berakhir dengan kode yang sangat andal.

Juga, periksa daftar resmi modul Node.js yang direkomendasikan. Namun, Modul Node GitHub's Wiki jauh lebih lengkap dan sumber daya yang baik.

Untuk memahami Node, ada baiknya mempertimbangkan beberapa pilihan desain utama:

Node.js adalah EVENT BERBASIS dan ASYNCHRONOUS / NON-PEMBLOKIRAN. Peristiwa, seperti koneksi HTTP yang masuk akan memadamkan fungsi JavaScript yang sedikit bekerja dan memulai tugas asinkron lainnya seperti menyambung ke database atau menarik konten dari server lain. Setelah tugas-tugas ini telah dimulai, fungsi acara selesai dan Node.js kembali tidur. Segera setelah sesuatu yang lain terjadi, seperti koneksi basis data yang dibuat atau server eksternal merespons dengan konten, fungsi panggil kembali diaktifkan, dan lebih banyak lagi kode JavaScript dieksekusi, berpotensi memulai lebih banyak tugas yang tidak sinkron (seperti permintaan basis data). Dengan cara ini, Node.js akan dengan senang hati melakukan interleave aktivitas untuk beberapa alur kerja paralel, menjalankan aktivitas apa pun yang tidak terblokir pada titik waktu tertentu. Inilah sebabnya mengapa Node.js melakukan pekerjaan hebat mengelola ribuan koneksi simultan.

Mengapa tidak menggunakan satu proses / utas per koneksi seperti yang lainnya?Di Node.js, koneksi baru hanyalah alokasi heap yang sangat kecil. Memutar proses baru membutuhkan memori yang jauh lebih besar, satu megabita pada beberapa platform. Tetapi biaya sebenarnya adalah overhead yang terkait dengan pengalihan konteks. Ketika Anda memiliki 10 ^ 6 utas kernel, kernel harus melakukan banyak pekerjaan mencari tahu siapa yang harus menjalankan selanjutnya. Banyak pekerjaan yang telah dilakukan untuk membangun penjadwal O (1) untuk Linux, tetapi pada akhirnya, hanya cara yang jauh lebih efisien untuk memiliki satu proses yang digerakkan oleh peristiwa daripada 10 ^ 6 proses yang bersaing untuk waktu CPU. Selain itu, dalam kondisi kelebihan beban, model multi-proses berperilaku sangat buruk, membuat layanan administrasi dan manajemen kritis kelaparan, terutama SSHD (artinya Anda bahkan tidak bisa masuk ke dalam kotak untuk mengetahui seberapa benar-benar kacau itu).

Node.js adalah THREADED TUNGGAL dan KUNCI GRATIS . Node.js, sebagai pilihan desain yang sangat disengaja hanya memiliki satu utas per proses. Karena itu, pada dasarnya tidak mungkin bagi banyak utas untuk mengakses data secara bersamaan. Dengan demikian, tidak diperlukan kunci. Utas itu sulit. Sangat sulit. Jika Anda tidak percaya itu, Anda belum cukup melakukan pemrograman utas. Mengunci dengan benar sulit dan menghasilkan bug yang sangat sulit dilacak. Menghilangkan kunci dan multi-threading membuat salah satu kelas bug paling jahat hilang begitu saja. Ini mungkin satu keuntungan terbesar dari simpul.

Tetapi bagaimana saya memanfaatkan kotak 16 inti saya?

Dua arah:

1. Untuk tugas komputasi besar yang berat seperti pengkodean gambar, Node.js dapat menjalankan proses anak atau mengirim pesan ke proses pekerja tambahan. Dalam desain ini, Anda akan memiliki satu utas yang mengelola aliran peristiwa dan proses N yang melakukan tugas komputasi yang berat dan mengunyah 15 CPU lainnya.
2. Untuk scaling throughput pada layanan web, Anda harus menjalankan beberapa server Node.js pada satu kotak, satu per inti, menggunakan cluster (Dengan Node.js v0.6.x, modul "cluster" resmi yang ditautkan di sini menggantikan versi learningboost yang memiliki API yang berbeda). Server Node.js lokal ini kemudian dapat bersaing di soket untuk menerima koneksi baru, menyeimbangkan beban di seluruh mereka. Setelah koneksi diterima, itu menjadi terikat erat ke satu proses bersama ini. Secara teori, ini terdengar buruk, tetapi dalam praktiknya ini bekerja dengan sangat baik dan memungkinkan Anda untuk menghindari sakit kepala menulis kode yang aman. Juga, ini berarti bahwa Node.js mendapatkan afinitas cache CPU yang sangat baik, lebih efektif menggunakan bandwidth memori.

Node.js memungkinkan Anda melakukan beberapa hal yang sangat kuat tanpa berkeringat. Misalkan Anda memiliki program Node.js yang melakukan berbagai tugas, mendengarkan padaport TCP untuk perintah, mengkodekan beberapa gambar, apa pun. Dengan lima baris kode, Anda dapat menambahkan portal manajemen web berbasis HTTP yang menunjukkan status tugas aktif saat ini. Ini mudah untuk dilakukan:

var http = require('http');
http.createServer(function (req, res) {
    res.writeHead(200, {'Content-Type': 'text/plain'});
    res.end(myJavascriptObject.getSomeStatusInfo());
}).listen(1337, "127.0.0.1");

Sekarang Anda dapat menekan URL dan memeriksa status proses Anda yang sedang berjalan. Tambahkan beberapa tombol, dan Anda memiliki "portal manajemen". Jika Anda memiliki skrip Perl / Python / Ruby yang sedang berjalan, cukup "melempar di portal manajemen" tidak sepenuhnya sederhana.

Tapi bukankan JavaScript lambat / buruk / jahat / menelurkan-setan-? JavaScript memiliki beberapa keanehan aneh, tetapi dengan "bagian yang bagus" ada bahasa yang sangat kuat di sana, dan dalam hal apa pun, JavaScript adalah bahasa pada klien (browser). JavaScript ada di sini untuk tinggal; bahasa lain menargetkannya sebagai IL, dan bakat kelas dunia bersaing untuk menghasilkan mesin JavaScript paling canggih. Karena peran JavaScript dalam browser, sejumlah besar upaya rekayasa dilemparkan untuk membuat JavaScript menyala dengan cepat. V8adalah mesin javascript terbaru dan terhebat, setidaknya untuk bulan ini. Ini menghancurkan bahasa scripting lain dalam efisiensi DAN stabilitas (melihat Anda, Ruby). Dan itu hanya akan menjadi lebih baik dengan tim besar mengerjakan masalah di Microsoft, Google, dan Mozilla, bersaing untuk membangun mesin JavaScript terbaik (Ini bukan lagi "penerjemah" JavaScript karena semua mesin modern melakukan banyak JITkompilasi di bawah tenda dengan interpretasi hanya sebagai mundur untuk mengeksekusi kode sekali). Ya, kita semua berharap dapat memperbaiki beberapa pilihan bahasa JavaScript yang lebih aneh, tapi itu tidak terlalu buruk. Dan bahasanya sangat fleksibel sehingga Anda benar-benar tidak mengkode JavaScript, Anda mengkode Langkah atau jQuery - lebih dari bahasa lain, dalam JavaScript, perpustakaan menentukan pengalaman. Untuk membangun aplikasi web, Anda cukup banyak harus tahu JavaScript, jadi coding dengan itu di server memiliki semacam sinergi keterampilan-set. Itu membuat saya tidak takut menulis kode klien.

Selain itu, jika Anda BENAR-BENAR membenci JavaScript, Anda dapat menggunakan gula sintaksis seperti CoffeeScript . Atau apa pun yang membuat kode JavaScript, seperti Google Web Toolkit (GWT).

Berbicara tentang JavaScript, apa itu "penutupan"? - Cukup banyak cara mewah untuk mengatakan bahwa Anda mempertahankan variabel cakupan leksikal di seluruh rantai panggilan. ;) Seperti ini:

var myData = "foo";
database.connect( 'user:pass', function myCallback( result ) {
    database.query("SELECT * from Foo where id = " + myData);
} );
// Note that doSomethingElse() executes _BEFORE_ "database.query" which is inside a callback
doSomethingElse();

Lihat bagaimana Anda bisa menggunakan "myData" tanpa melakukan sesuatu yang canggung seperti menyembunyikannya ke objek? Dan tidak seperti di Jawa, variabel "myData" tidak harus hanya baca. Fitur bahasa yang kuat ini membuat pemrograman asinkron jauh lebih sedikit bertele-tele dan tidak terlalu menyakitkan.

Menulis kode asinkron selalu akan menjadi lebih kompleks daripada menulis skrip single-threaded sederhana, tetapi dengan Node.js, ini tidak terlalu sulit dan Anda mendapatkan banyak manfaat selain efisiensi dan skalabilitas ke ribuan koneksi bersamaan. ..

V8 adalah implementasi dari JavaScript. Ini memungkinkan Anda menjalankan aplikasi JavaScript mandiri (antara lain).

Node.js hanyalah sebuah pustaka yang ditulis untuk V8 yang menampilkan I / O. Konsep ini agak sulit untuk dijelaskan, dan saya yakin seseorang akan menjawab dengan penjelasan yang lebih baik daripada saya ... Intinya adalah daripada melakukan beberapa input atau output dan menunggu itu terjadi, Anda hanya tidak menunggu untuk itu selesai. Jadi misalnya, tanyakan waktu terakhir file yang diedit:

// Pseudo code
stat( 'somefile' )

Mungkin butuh beberapa milidetik, atau mungkin butuh beberapa detik. Dengan I / O yang terjadi, Anda cukup mematikan permintaan dan alih-alih menunggu Anda melampirkan panggilan balik yang dijalankan saat permintaan selesai:

// Pseudo code
stat( 'somefile', function( result ) {
  // Use the result here
} );
// ...more code here

Ini membuatnya sangat mirip kode JavaScript di browser (misalnya, dengan fungsionalitas gaya Ajax ).

Untuk informasi lebih lanjut, Anda harus memeriksa artikel Node.js benar-benar menarik yang merupakan pengantar saya ke perpustakaan / platform ... Saya merasa cukup bagus.

Node.js adalah alat baris perintah sumber terbuka yang dibangun untuk kode JavaScript sisi server. Anda dapat mengunduh tarball , kompilasi, dan instal sumbernya. Ini memungkinkan Anda menjalankan program JavaScript.

JavaScript dijalankan oleh V8 , mesin JavaScript yang dikembangkan oleh Google yang digunakan di browser Chrome . Ini menggunakan JavaScript API untuk mengakses jaringan dan sistem file.

Ini populer untuk kinerjanya dan kemampuan untuk melakukan operasi paralel.

Memahami node.js adalah penjelasan terbaik dari node.js yang saya temukan sejauh ini.

Berikut ini adalah beberapa artikel bagus tentang topik ini.

• Mempelajari Server-Side JavaScript dengan Node.js
• Kali ini, Anda akan Belajar Node.js

Penutupan adalah cara untuk mengeksekusi kode dalam konteks yang dibuatnya.

Apa artinya ini untuk concurency adalah bahwa Anda dapat mendefinisikan variabel, kemudian memulai fungsi I / O nonblocking , dan mengirimkannya fungsi anonim untuk panggilan baliknya.

Ketika tugas selesai, fungsi panggilan balik akan dieksekusi dalam konteks dengan variabel, ini adalah penutupan.

Alasan penutupan sangat baik untuk menulis aplikasi dengan nonblocking I / O adalah sangat mudah untuk mengelola konteks fungsi yang dijalankan secara tidak sinkron.

Dua contoh yang baik adalah mengenai bagaimana Anda mengelola template dan menggunakan perangkat tambahan progresif dengannya. Anda hanya perlu beberapa kode JavaScript yang ringan untuk membuatnya bekerja dengan sempurna.

Saya sangat menyarankan Anda menonton dan membaca artikel ini:

• Node kaca video
• Manipulasi Node.js YUI DOM

Ambil bahasa apa pun dan coba ingat bagaimana Anda akan mengelola templat file HTML Anda dan apa yang harus Anda lakukan untuk memperbarui satu nama kelas CSS dalam struktur DOM Anda (misalnya, pengguna mengklik item menu dan Anda ingin yang ditandai sebagai "terpilih" dan perbarui konten halaman).

Dengan Node.js semudah melakukannya dalam kode JavaScript sisi klien. Dapatkan simpul DOM Anda dan terapkan kelas CSS Anda untuk itu. Dapatkan simpul DOM Anda dan konten dalamHTML Anda (Anda akan memerlukan beberapa kode JavaScript tambahan untuk melakukan ini. Baca artikel untuk tahu lebih banyak).

Contoh bagus lainnya, adalah Anda dapat membuat halaman web Anda kompatibel baik dengan JavaScript dihidupkan atau dimatikan dengan potongan kode yang sama. Bayangkan Anda memiliki pilihan tanggal yang dibuat dalam JavaScript yang akan memungkinkan pengguna Anda untuk mengambil tanggal apa pun menggunakan kalender. Anda dapat menulis (atau menggunakan) bagian kode JavaScript yang sama untuk membuatnya berfungsi dengan JavaScript Anda AKTIFKAN atau MATI.

Ada analogi tempat makanan cepat saji yang sangat baik yang paling menjelaskan model event-driven Node.js, lihat artikel lengkapnya, Node.js, Kantor Dokter dan Restoran Makanan Cepat Saji - Memahami Pemrograman Berbasis Acara

Berikut ini ringkasannya:

Jika sambungan fast food mengikuti model tradisional berbasis benang, Anda akan memesan makanan dan menunggu dalam antrean sampai Anda menerimanya. Orang di belakang Anda tidak akan dapat memesan sampai pesanan Anda selesai. Dalam model event-driven, Anda memesan makanan dan kemudian keluar dari barisan untuk menunggu. Semua orang kemudian bebas untuk memesan.

Node.js adalah event-driven, tetapi sebagian besar server web berbasis thread.York menjelaskan cara kerja Node.js:

• Anda menggunakan browser web Anda untuk membuat permintaan "/about.html" pada server web Node.js.

• Server Node.js menerima permintaan Anda dan memanggil fungsi untuk mengambil file itu dari disk.

• Ketika server Node.js sedang menunggu file untuk diambil, ia melayani permintaan web berikutnya.

• Ketika file diambil, ada fungsi callback yang dimasukkan dalam antrian server Node.js.

• Server Node.js menjalankan fungsi itu yang dalam hal ini akan merender halaman "/about.html" dan mengirimkannya kembali ke browser web Anda. "

Yah, saya mengerti itu

• Tujuan Node adalah menyediakan cara mudah untuk membangun program jaringan yang dapat diskalakan.
• Node serupa dalam desainnya dan dipengaruhi oleh sistem seperti Mesin Acara Ruby atau Python Twisted.
• I / O untuk javascript V8.

Bagi saya itu berarti Anda benar dalam ketiga asumsi. Perpustakaannya memang terlihat menjanjikan!

Juga, jangan lupa untuk menyebutkan bahwa Google V8 SANGAT cepat. Ini benar-benar mengubah kode JavaScript ke kode mesin dengan kinerja yang cocok dari kompilasi biner. Jadi bersama dengan semua hal-hal besar lainnya, itu GILA cepat.

Q: Model pemrograman event driven, terutama cara menangani I / O .

Benar. Itu menggunakan panggilan balik, sehingga setiap permintaan untuk mengakses sistem file akan menyebabkan permintaan untuk dikirim ke sistem file dan kemudian Node.js akan mulai memproses permintaan berikutnya. Itu hanya akan khawatir tentang permintaan I / O setelah mendapat respons kembali dari sistem file, di mana saat itu akan menjalankan kode panggilan balik. Namun, dimungkinkan untuk membuat permintaan I / O yang sinkron (yaitu, memblokir permintaan). Terserah pengembang untuk memilih antara asinkron (panggilan balik) atau sinkron (menunggu).

T: Ini menggunakan JavaScript dan parser adalah V8.

Iya

T: Dapat dengan mudah digunakan untuk membuat aplikasi server bersamaan.

Ya, meskipun Anda perlu kode tangan JavaScript cukup banyak. Mungkin lebih baik untuk melihat kerangka kerja, seperti http://www.easynodejs.com/ - yang dilengkapi dengan dokumentasi online lengkap dan contoh aplikasi.