Mengapa seorang pria di dunia Jawa menjadi pendukung Node.js dan JavaScript yang bersemangat?

David Harron, penulis materi yang kami terbitkan hari ini, mengajukan pertanyaan berikut: “Haruskah seseorang yang telah bekerja selama lebih dari 10 tahun di Sun Microsystems, di tim Java SE, sampai nafas terakhir hanya memikirkan Java bytecode dan membuat instance antarmuka abstrak? ". Dia mengajukan pertanyaan ini sehubungan dengan dirinya sendiri, dan baginya platform Node.js, setelah Jawa, ternyata seperti embusan angin segar. David mengatakan bahwa ketika dia dipecat dari Sun pada Januari 2009 (tepat sebelum pengambilalihan perusahaan Oracle ini), dia mengetahui tentang Node.js. Teknologi ini mengaitkannya. Apa artinya "ketagihan"? Sejak 2010, ia banyak menulis tentang pemrograman untuk Node.js. Yaitu, ia menulis beberapa buku, termasuk Node.js Web Development, edisi keempat yang dirilis tahun ini. Dia telah menyiapkan banyak materi kecil tentang Node.js yang diterbitkan di Internet. Bahkan, ia menghabiskan banyak waktu dan upaya untuk berbicara tentang platform Node.js dan fitur JavaScript. Mengapa mereka yang sebelumnya bekerja secara eksklusif di Jawa begitu tertarik dengan Node.js dan JavaScript?

Tentang Dunia Jawa

Saat bekerja di Sun, saya percaya pada teknologi Java. Saya membuat presentasi di JavaONE, berpartisipasi dalam pengembangan kelas java.awt.Robot, menyelenggarakan acara Mustang Regressions Contestions (itu adalah kompetisi yang bertujuan menemukan bug di Jawa 1.6), membantu meluncurkan proyek Lisensi Distribusi untuk Java, yang berfungsi sebagai jawaban untuk pertanyaan tentang distribusi JDK Linux sebelum kedatangan OpenJDK. Kemudian, saya memainkan peran dalam meluncurkan proyek OpenJDK. Sepanjang jalan, selama sekitar 6 tahun, saya menerbitkan materi blog di java.net (sekarang situs ini ditutup). Ini adalah 1-2 artikel per minggu yang didedikasikan untuk peristiwa penting di ekosistem Jawa. Peran penting dalam pekerjaan saya dimainkan dengan melindungi Jawa dari mereka yang memperkirakan masa depan suram untuk teknologi ini.


Penghargaan ini, Penghargaan Duke, diberikan kepada karyawan Sun yang paling terkemuka. Saya mendapatkannya setelah saya menyelenggarakan Kontes Regresi Mustang

Apa yang terjadi pada orang yang melakukan banyak hal dengan segala hal yang berhubungan dengan Jawa? Sebenarnya, di sini saya ingin berbicara tentang bagaimana saya berubah dari penggemar Java menjadi pendukung Node.js dan JavaScript yang bersemangat.

Saya harus mengatakan bahwa apa yang terjadi pada saya tidak dapat disebut sebagai pengabaian sepenuhnya terhadap Jawa. Selama 3 tahun terakhir, saya telah menulis cukup banyak kode Java, menggunakan Spring dan Hibernate. Meskipun apa yang sekarang saya lakukan di bidang ini saya sangat suka (saya bekerja di industri energi surya, melakukan apa yang saya sukai, misalnya - saya menulis permintaan untuk bekerja dengan data dari sektor energi), pemrograman Java di mata saya sekarang kehilangan kemegahannya sebelumnya.

Dua tahun pengembangan dengan menggunakan Pegas memungkinkan saya untuk dengan jelas mengklarifikasi satu hal penting: upaya untuk menyembunyikan mekanisme kompleks tidak mengarah pada kesederhanaan, itu hanya mengarah pada penampilan struktur yang lebih kompleks.

Di sini, secara singkat, adalah ide-ide utama yang akan saya sentuh dalam materi ini:

• Program Java penuh dengan kode boilerplate yang menyembunyikan niat programmer.
• Bekerja dengan Spring and Spring Boot telah memberi saya pelajaran yang baik, yaitu bahwa mencoba menyembunyikan mekanisme yang rumit mengarah pada konstruksi yang lebih kompleks.
• Platform Java EE adalah proyek yang dibuat, dengan kata lain, oleh "upaya bersama", yang mencakup sepenuhnya semua kebutuhan pengembangan aplikasi perusahaan. Akibatnya, platform Java EE telah terbukti menghambat.
• Berkembang bersama Spring adalah, sampai titik tertentu, pengalaman yang menyenangkan. Ilusi ini menghilang pada hari ketika pengecualian yang benar-benar mustahil untuk dipahami muncul dari kedalaman suatu subsistem yang belum pernah Anda dengar, dan dibutuhkan setidaknya tiga hari untuk mencari tahu apa masalahnya.
• Mekanisme bantu apa yang membuat beban berlebihan pada sistem yang Anda butuhkan kerangka kerja yang dapat "menulis" kode untuk programmer?
• Meskipun IDE seperti Eclipse adalah aplikasi yang kuat, mereka adalah indikator kompleksitas ekosistem Java.
• Platform Node.js muncul sebagai hasil dari upaya satu orang untuk meningkatkan visinya tentang arsitektur berbasis event yang ringan.
• Komunitas JavaScript tampaknya sangat antusias untuk menyingkirkan kode boilerplate, yang memungkinkan pemrogram mengekspresikan niat mereka sejelas mungkin.
• Async / await adalah solusi untuk masalah neraka panggilan balik JS, yang merupakan contoh penolakan kode templat dan berkontribusi pada kejelasan ekspresi niat pemrogram.
• Pemrograman untuk Node.js adalah kesenangan nyata.
• Tidak ada ketikan kuat khusus untuk Java dalam JavaScript. Inilah berkah dan kutukan lidah. Ini membuatnya lebih mudah untuk menulis kode, tetapi untuk memverifikasi kebenarannya, Anda harus mencurahkan lebih banyak waktu untuk pengujian.
• Sistem manajemen paket yang diperkenalkan oleh npm / benang mudah dan menyenangkan untuk digunakan. Dia tidak bisa dibandingkan dengan Maven.
• Baik Java dan Node.js menawarkan kinerja hebat. Ini bertentangan dengan mitos bahwa JavaScript adalah bahasa yang lambat, yang penggunaannya menyebabkan kinerja platform Node.js yang buruk.
• Performance Node.js dibangun berdasarkan upaya Google untuk meningkatkan V8, mesin yang memengaruhi kecepatan browser Chrome.
• Persaingan sengit antara produsen mesin JS berbasis browser berkontribusi pada pengembangan JavaScript, dan ini sangat bermanfaat bagi Node.js.

Tentang Masalah Pembangunan Jawa

Beberapa alat atau benda adalah hasil dari upaya bertahun-tahun oleh para insinyur untuk memperbaikinya. Pemrogram mencoba ide yang berbeda, menghapus atribut yang tidak perlu, dan sebagai hasilnya mereka mendapatkan entitas di mana ada secara eksklusif apa yang diperlukan untuk memecahkan masalah tertentu. Seringkali, teknologi semacam itu memiliki semacam kesederhanaan yang sangat menarik yang menyembunyikan kemampuan kuat. Ini tidak berlaku untuk Java.

Spring adalah kerangka kerja populer untuk mengembangkan aplikasi web berbasis Java.

Tujuan utama Spring, dan khususnya Spring Boot, adalah untuk memberikan kemampuan untuk menggunakan Java EE stack yang telah dikonfigurasi sebelumnya. Programmer yang menggunakan Spring tidak boleh, untuk membuat sistem yang sudah jadi, merawat servlet, sistem penyimpanan persisten, server aplikasi, dan apa yang masih belum diketahui. Semua masalah ini diteruskan ke Spring, dan programmer menulis kode yang mengimplementasikan logika aplikasi. Misalnya, mekanisme JPARepository bertanggung jawab untuk menghasilkan kueri basis data untuk metode yang namanya mirip dengan findUserByFirstName . Programmer tidak perlu menulis kode untuk metode seperti itu. Cukup mengirimkan deskripsi metode ke sistem, dan Spring akan melakukan sisanya.

Semuanya terdengar sangat bagus, senang bekerja dengan gaya ini, tetapi - sampai sesuatu yang tidak terduga terjadi.

Maksudku situasi di mana, misalnya, Hibernate PersistentObjectException dilemparkan dengan pesan yang detached entity passed to persist . Apa artinya itu? Butuh beberapa hari untuk mengetahuinya. Ternyata, jika Anda menggambarkan semuanya dengan cara yang sangat sederhana, ini berarti bahwa data JSON yang diterima di titik akhir REST memiliki bidang ID dengan beberapa nilai. Hibernasi, sekali lagi, jika tidak masuk ke detail, berusaha untuk mengontrol nilai ID, dan, sebagai hasilnya, melempar pengecualian yang tidak jelas di atas. Ada ribuan pesan kesalahan seperti itu yang membingungkan dan sulit dibaca. Mempertimbangkan bahwa ada seluruh kaskade subsistem berdasarkan satu sama lain di Musim Semi, tumpukan Spring terlihat seperti musuh bebuyutan seorang programmer yang mengawasinya dan menunggu programmer membuat kesalahan sekecil apa pun, dan ketika ini terjadi, melempar pengecualian yang tidak kompatibel dengannya. operasi normal aplikasi.

Selanjutnya, di sini Anda dapat mengingat jejak tumpukan terpanjang. Mereka mewakili beberapa layar penuh dengan segala macam metode abstrak. Musim semi jelas menciptakan konfigurasi yang diperlukan untuk mengimplementasikan apa yang dinyatakan dalam kode. Tingkat abstraksi seperti itu, tidak diragukan lagi, memerlukan sejumlah besar logika bantu, yang bertujuan menemukan segala yang diperlukan agar kode berfungsi, misalnya, untuk memenuhi permintaan. Dan jejak tumpukan panjang belum tentu buruk. Hal-hal semacam itu lebih cenderung merupakan gejala, yang mengarah pada pertanyaan tentang jenis beban apa pada sistem yang diciptakan oleh mekanisme bantu.

Bagaimana metode findUserByFirstName , mengingat bahwa programmer tidak menulis kode untuk metode seperti itu? Kerangka kerja perlu mem-parsing nama metode, memahami maksud programmer, membuat sesuatu seperti pohon sintaksis abstrak, menghasilkan beberapa jenis kode SQL, dan sebagainya. Bagaimana semua ini memuat sistem? Dan semua ini hanya ada sehingga programmer tidak perlu menulis kode?

Setelah Anda harus melalui beberapa puluh kali melalui sesuatu seperti mencari makna kesalahan di atas, menghabiskan berminggu-minggu mencoba mengungkap rahasia yang, pada umumnya, Anda tidak boleh mengungkap, Anda bisa sampai pada kesimpulan yang sama dengan yang saya dapatkan. . Artinya adalah bahwa upaya untuk menyembunyikan mekanisme yang kompleks tidak mengarah pada kesederhanaan, itu hanya mengarah pada penampilan struktur yang lebih kompleks. Platform Node.js jauh lebih sederhana.

Slogan "Masalah Kompatibilitas" menyembunyikan ide bagus, yang menurutnya kompatibilitas ke belakang adalah fitur paling penting dari platform Java. Kami menganggap ini serius, menempatkan gambar pada t-shirt seperti yang Anda lihat di bawah.


Kompatibilitas mundur sangat penting.

Tentu saja, tingkat perhatian terhadap kompatibilitas ke belakang ini dapat menjadi sumber kecemasan yang konstan, dan dari waktu ke waktu bermanfaat untuk menjauh dari mekanisme lama yang tidak lagi menguntungkan.

Java dan Node.js

EE Musim Semi dan Java terlalu rumit. Platform Node.js dengan latar belakang mereka dianggap sebagai angin segar. Hal pertama yang Anda perhatikan ketika berkenalan dengan Node.js adalah pendekatan Ryan Dahl untuk pengembangan inti platform. Pengalamannya mengatakan kepadanya bahwa platform yang menggunakan stream diperlukan untuk menciptakan sistem kelas berat yang kompleks. Dia mencari sesuatu yang lain, dan menghabiskan beberapa tahun untuk memperbaiki set mekanisme dasar yang terkandung dalam Node.js. Sebagai hasilnya, ia mendapatkan sistem yang ringan yang ditandai dengan satu utas eksekusi, penggunaan inventif fungsi JavaScript anonim sebagai callback asinkron, dan pustaka runtime yang awalnya menerapkan mekanisme asinkron. Pesan awal saat membuat sistem seperti itu adalah untuk menyediakan pemrosesan acara berkinerja tinggi dengan pengiriman peristiwa ini dalam fungsi panggilan balik.

Selanjutnya, fitur penting Node.js adalah penggunaan JavaScript. Ada perasaan bahwa mereka yang menulis di JS memiliki kecenderungan untuk menyingkirkan kode templat, yang memungkinkan mereka untuk menggambarkan dengan jelas niat programmer.

Sebagai contoh perbedaan antara Java dan JavaScript, pertimbangkan implementasi fungsi pendengar (pengamat). Di Jawa, untuk bekerja dengan pendengar, Anda perlu membuat contoh spesifik dari antarmuka abstrak. Ini memerlukan penggunaan konstruksi bahasa besar yang menyembunyikan esensi dari apa yang terjadi. Bagaimana membedakan niat seorang programmer yang tersembunyi di balik sampul kode boilerplate?

Sebaliknya, JavaScript menggunakan fungsi anonim sederhana. Saat menerapkan pendengar, Anda tidak perlu mencari antarmuka abstrak yang cocok. Sudah cukup, tanpa perlu menggunakan berbagai teks tambahan, untuk menulis kode yang diperlukan.

Jadi, berikut adalah satu ide penting yang dapat diambil dari analisis mekanisme di atas: sebagian besar bahasa pemrograman menyembunyikan niat programmer, yang mengarah pada fakta bahwa kode tersebut sulit dipahami.

Keputusan tentang penggunaan fungsi callback yang ditawarkan Node.js terlihat sangat menarik. Tetapi ini bukan tanpa masalah.

Pemecahan Masalah dan Pemecahan Masalah

Dalam JavaScript, sudah ada dua masalah yang terkait dengan pemrograman asinkron. Yang pertama adalah apa yang disebut Node.js panggilan balik neraka. Masalah ini terletak pada kenyataan bahwa, selama pengembangan, mudah untuk jatuh ke dalam jebakan yang dibangun dari fungsi-fungsi callback yang sangat bersarang, di mana setiap tingkat bersarang mempersulit program, serta memproses hasil kode dan kesalahan. Ada masalah lain yang terkait dengan ini, intinya adalah bahwa mekanisme bahasa JavaScript tidak membantu programmer mengekspresikan ide-ide eksekusi kode asynchronous.

Beberapa perpustakaan telah muncul untuk menyederhanakan pengembangan asinkron pada JS. Tapi ini adalah contoh lain dari upaya untuk menyembunyikan mekanisme kompleks yang hanya mengarah pada tampilan struktur yang lebih kompleks.

Pertimbangkan sebuah contoh:

 const async = require('async'); const fs = require('fs'); const cat = function(filez, fini) { async.eachSeries(filez, function(filenm, next) {   fs.readFile(filenm, 'utf8', function(err, data) {     if (err) return next(err);     process.stdout.write(data, 'utf8', function(err) {       if (err) next(err);       else next();     });   }); }, function(err) {   if (err) fini(err);   else fini(); }); }; cat(process.argv.slice(2), function(err) { if (err) console.error(err.stack); }); 

Ini adalah tiruan sederhana dari cat Unix. Pustaka async dalam menyederhanakan urutan panggilan asinkron. Namun, penggunaannya membutuhkan sejumlah besar kode boilerplate yang menyembunyikan maksud programmer.

Intinya, kode ini berisi loop. Itu tidak ditulis sebagai siklus reguler, tidak menggunakan konstruksi alami dari deskripsi siklus. Selanjutnya, hasil eksekusi kode dan kesalahan yang dihasilkan oleh mereka tidak sampai ke tempat mereka seharusnya benar. Mereka dikunci dalam callback, yang tidak nyaman. Tapi, sebelum penerapan standar ES2015 / 2016 di Node.js, tidak ada yang lebih baik yang bisa dilakukan.

Jika kami menulis ulang kode ini dengan mempertimbangkan fitur-fitur baru, yang, khususnya, tersedia di Node.js 10.x, kami mendapatkan yang berikut:

 const fs = require('fs').promises; async function cat(filenmz) { for (var filenm of filenmz) {   let data = await fs.readFile(filenm, 'utf8');   await new Promise((resolve, reject) => {     process.stdout.write(data, 'utf8', (err) => {       if (err) reject(err);       else resolve();     });   }); } } cat(process.argv.slice(2)).catch(err => {   console.error(err.stack); }); 

Dalam contoh ini, kami menggunakan konstruk async/await . Mekanisme asinkron yang sama disajikan di sini seperti pada contoh sebelumnya, tetapi struktur yang biasa digunakan dalam mengatur loop digunakan di sini. Bekerja dengan hasil dan kesalahan terlihat sangat normal. Kode semacam itu lebih mudah dibaca dan ditulis. Pendekatan ini memudahkan untuk memahami maksud programmer.

Satu-satunya kelemahan adalah bahwa process.stdout.write tidak memiliki antarmuka Promise, akibatnya, mekanisme ini tidak dapat digunakan dalam fungsi async tanpa membungkusnya dengan janji.

Sekarang kita dapat menyimpulkan bahwa masalah panggilan balik neraka dalam JavaScript telah dipecahkan dengan cara yang berbeda dengan mencoba menyembunyikan mekanisme yang kompleks. Sebagai gantinya, perubahan dilakukan pada bahasa, yang memecahkan masalah itu sendiri, dan menyelamatkan kami dari ketidaknyamanan yang disebabkan oleh kebutuhan untuk menggunakan sejumlah besar kode templat dalam solusi sementara. Selain itu, dengan menggunakan mekanisme async / menunggu, kode menjadi lebih indah.

Kami memulai bagian ini dengan diskusi tentang kelemahan Node.js, tetapi solusi yang sangat baik untuk panggilan balik yang hebat menyebabkan pembicaraan tentang kekurangan berubah menjadi pembicaraan tentang kekuatan Node.js dan JavaScript.

Ketikan, antarmuka, dan kejelasan kode imajiner yang kuat

Pada hari-hari ketika saya melindungi Java dari segala macam serangan, saya menekankan bahwa pengetikan yang ketat memungkinkan Anda untuk menulis aplikasi besar. Pada masa itu, pengembangan sistem monolitik sedang digunakan (tidak ada layanan mikro, tidak ada Docker dan sejenisnya). Karena Java adalah bahasa yang sangat diketik, kompiler Java membantu programmer menghindari banyak masalah dengan mencegahnya dari mengkompilasi kode yang salah.

JavaScript, tidak seperti Java, tidak diketik dengan kuat. Dari sini kita dapat membuat kesimpulan yang jelas bahwa programmer tidak tahu persis objek apa yang harus dia kerjakan. Bagaimana seorang programmer bisa tahu apa yang harus dilakukan, misalnya, dengan objek tertentu yang diterima dari suatu tempat?

Sisi lain dari pengetikan Java yang kuat adalah Anda harus terus-menerus melakukan tindakan boilerplate. Programmer terus-menerus melakukan casting atau memeriksa bahwa semuanya persis seperti yang diharapkan. Pengembang menghabiskan waktu menulis kode, melakukannya dengan akurasi luar biasa, menggunakan banyak sekali desain template, dan berharap semua ini akan membantunya menghemat waktu dengan deteksi dini dan koreksi kesalahan.

Masalah pemrograman dalam bahasa yang diketik sangat besar sehingga seorang programmer, yang hampir tidak memiliki pilihan, harus menggunakan IDE yang besar dan kompleks. Editor kode sederhana tidak cukup di sini. Satu-satunya cara untuk menjaga programmer Java dalam kondisi yang memadai (dengan pengecualian pizza) adalah dengan terus-menerus menunjukkan kepadanya daftar drop-down yang berisi bidang objek yang tersedia atau deskripsi parameter metode. Ini dan mekanisme pendukung lainnya dari IDE seperti Eclipse, NetBeans, atau IntelliJ membantu dalam pembuatan kelas, memfasilitasi refactoring, dan tugas-tugas lainnya.

Dan ... aku tidak akan berbicara tentang Maven. Ini hanyalah alat mimpi buruk.

Dalam JavaScript, tipe variabel tidak ditentukan saat dideklarasikan, tipe casting biasanya tidak digunakan, dan sebagainya. Akibatnya, kode lebih mudah dibaca, tetapi keadaan ini juga berarti risiko kesalahan pemrograman yang sulit dideteksi.

Apakah yang disebutkan di atas berkaitan dengan nilai plus Jawa atau minus tergantung pada sudut pandang.

Sepuluh tahun yang lalu, saya percaya bahwa semua kesulitan ini membenarkan diri mereka sendiri dengan memberi programmer lebih percaya diri pada kode yang dia tulis. Hari ini, saya percaya bahwa pengetikan yang kuat meningkatkan beban kerja programmer dan jauh lebih mudah untuk mengembangkan proyek seperti yang mereka lakukan dalam JavaScript.

Perangi kesalahan dengan modul kecil yang mudah diuji

Node.js mendorong programmer untuk memecah proyek-proyeknya menjadi fragmen kecil, menjadi modul yang disebut. Anda mungkin menemukan fakta ini tidak signifikan, tetapi sebagian menyelesaikan masalah yang baru saja kami sebutkan.

Berikut adalah karakteristik utama dari modul:

• Kemandirian Modul ini menggabungkan kode yang saling berhubungan menjadi satu kesatuan.
• Batas yang jelas. Kode di dalam modul dilindungi dari gangguan oleh mekanisme eksternal.
• Ekspor eksplisit. Secara default, kode dan data modul tidak diekspor. Pengembang secara independen memutuskan fungsi dan data mana yang harus tersedia untuk umum.
• Impor eksplisit. Ketika mengembangkan sebuah modul, programmer memutuskan sendiri modul mana yang akan ia andalkan.
• Potensi independensi. Modul dapat dibuat tersedia untuk umum, dalam arti yang sangat luas, dengan menerbitkannya dalam npm, atau, jika ditujukan untuk kebutuhan internal perusahaan, dengan menerbitkan dalam repositori tertutup. Ini membuatnya mudah untuk menggunakan modul yang sama di aplikasi yang berbeda.
• Kode mudah dimengerti. Fakta bahwa modulnya kecil, menyederhanakan pembacaan dan pemahaman kode mereka, membuka kemungkinan untuk diskusi bebas tentang mereka.
• Fasilitasi pengujian. Modul kecil, jika diimplementasikan dengan benar, dapat dengan mudah diuji unit.

Semua ini membuat modul Node.js entitas dengan batas yang jelas, kode yang mudah ditulis, dibaca, dan diuji.

Namun, khawatir tentang bekerja dengan JavaScript adalah fakta bahwa kurangnya pengetikan yang kuat dapat dengan mudah menyebabkan kode melakukan sesuatu yang salah. Dalam sebuah modul kecil yang ditujukan untuk memecahkan beberapa masalah sempit dengan batasan yang jelas, "ada sesuatu yang salah" hanya dapat mempengaruhi kode modul itu sendiri. Ini mengarah pada fakta bahwa masalah yang dapat menyebabkan kurangnya pengetikan yang ketat, terkunci di dalam modul.

Solusi lain untuk masalah pengetikan dinamis dalam JavaScript adalah dengan menguji kode secara menyeluruh.

Pengembang harus menganggap serius pengujian, yang menghilangkan sebagian manfaat yang berasal dari kesederhanaan proses pengembangan JS. Sistem pengujian yang dibuat oleh seorang programmer JS harus menemukan kesalahan-kesalahan itu, jika dikembangkan olehnya dalam sesuatu seperti Java, kompiler dapat secara otomatis menemukan. Apakah Anda menulis tes untuk aplikasi JS Anda?

Bagi mereka yang membutuhkan sistem pengetikan statis dalam JavaScript, mungkin bermanfaat untuk melihat pada TypeScript. Saya tidak menggunakan bahasa ini, tetapi saya telah mendengar banyak hal baik tentang itu. Ini kompatibel dengan JavaScript dan memperluas bahasa dengan sistem kontrol tipe dan fitur berguna lainnya.

Pada akhirnya, kita dapat mengatakan bahwa menggunakan pendekatan modular untuk pengembangan adalah kekuatan dari Node.js dan JavaScript.

Manajemen paket

Saya merasa tidak enak hanya dengan memikirkan Maven, jadi saya bahkan tidak bisa menulis dengan normal tentang itu. Dan, seperti yang saya pahami, Maven, tanpa kompromi, dicintai atau dibenci.

Masalahnya di sini adalah bahwa di lingkungan Java tidak ada sistem holistik untuk mengelola paket. Paket Maven ada, Anda dapat bekerja dengan mereka secara normal, mereka didukung oleh Gradle. Tetapi cara kerja dengan mereka diatur tidak mirip dengan kenyamanan yang diberikan oleh sistem manajemen paket untuk Node.js kepada pengembang.

Di dunia Node.js, ada dua manajer paket hebat yang saling bekerja sama. Pada awalnya, satu-satunya alat tersebut adalah repositori npm dan alat baris perintah dengan nama yang sama.

Berkat npm, kami memiliki skema yang sangat baik untuk menggambarkan dependensi paket. Ketergantungan dapat ketat (katakanlah, ini mengindikasikan bahwa hanya versi 1.2.3 dari paket tertentu yang diperlukan), atau diberikan dengan beberapa derajat kebebasan - hingga * , yang berarti menggunakan versi terbaru dari paket tertentu.

Komunitas Node.js telah menerbitkan ratusan ribu paket di repositori npm. Pada saat yang sama, menggunakan paket-paket yang tidak ada di npm semudah menggunakan paket-paket dari npm.

Sistem npm ternyata sangat sukses sehingga tidak hanya pengembang produk server di Node.js yang menggunakannya, tetapi juga programmer front-end. Sebelumnya, alat seperti Bower digunakan untuk mengelola paket. Bower sudah tidak digunakan lagi, dan sekarang Anda dapat menemukan bahwa semua pustaka JS untuk pengembangan frontend ada sebagai paket npm. Banyak alat pendukung untuk pengembangan klien, seperti Vue.js CLI dan Webpack, ditulis sebagai aplikasi Node.js.

Sistem manajemen paket lain untuk Node.js, utas, mengunduh paket dari repositori npm dan menggunakan file konfigurasi yang sama. Keuntungan utama dari benang melebihi manajer paket npm adalah kecepatannya yang lebih tinggi.

Repositori npm, apakah menggunakan manajer paket npm atau manajer paket benang, adalah fondasi yang kuat untuk apa yang membuat pengembangan untuk Node.js begitu mudah dan menyenangkan.


Suatu hari, setelah saya membantu mengembangkan java.awt.Robot, saya terinspirasi untuk membuat hal ini. Sementara gambar Duke resmi terdiri dari kurva, RoboDuke dibangun dari garis lurus. Hanya sambungan siku robot ini yang bulat

Performa

Java, JavaScript . -, , . , , - .

Java, JavaScript . Java Node.js, . JavaScript . -.

JDK Sun/Oracle HotSpot — , -. , , , , , . HotSpot — , .

JavaScript, , JS-, , , - . , JavaScript . , , . , , Google Docs, . JS .

Node.js , V8 Google Chrome.

, Google, V8, . , V8 Crankshaft Turbofan.

— , , R Python. , , . JavaScript, , , JavaScript.

JavaScript , TensorFlow.js. API API TensorFlow Python, . , , , .

IBM, Node.js, , , Docker/Kubernetes. , Node.js Spring Boot. -, . , Node.js , , , V8.

, Node.js . . - , Node.js , . , «Node.js Web Development», , :

• — .
• , Node.js .
• .

JavaScript , Node.js. — Node.js-. Node.js- node-gyp , . , Rust- Node.js.

WebAssembly , , JavaScript, . WebAssembly , JavaScript-. WebAssembly Node.js.

-

- (Rich Internet Applications, RIA) . , , ( ) JS-, .

, 20 . Sun Netscape Java- Netscape Navigator. JavaScript , , Java-. , Java-, — Java-. , . .

JavaScript , . RIA, , - Java -.

, RIA . Node.js , , , . JavaScript.

Berikut ini beberapa contohnya:

• Google Docs ( ), , .
• , React, Angular Vue.js, , HTML, CSS JavaScript.
• Electron — Node.js Chromium. - . , Visual Studio Code, Atom, GitKraken, Postman.
• Electron/NW.js , -, , React, Angular, Vue, .

Java, , - -, JavaScript. , , - Sun Microsystems. Sun , . . Java- , Java Java Web Start. Java- Webstart-.

Java, , , IDE NetBeans Eclipse . Java , , Java.

JavaFX.

JavaFX, 10 , Sun iPhone. , Java, , , . Flash iOS. . JavaFX , , . - React, Vue.js .

JavaScript Node Java.

Java, - JavaONE. Java . , , , .


Java

Ringkasan

. «P-» (Perl, PHP, Python) Java, Node.js, Ruby, Haskell, Go, Rust, . .

, , , Java, Node.js, , , Node.js-. Java , Node.js . , , , Java, .

. , , Node.js - , - . . , XBRL-. XBRL Python, , , Python. , , , .

Pembaca yang budiman! , , JavaScript - , - Node.js, .