Apakah ada alasan bagus untuk menghindari node.js untuk aplikasi web non-realtime?

29

Saya telah melihat banyak pembicaraan tentang betapa hebatnya Node.js untuk aplikasi web waktu nyata - hal-hal yang membutuhkan soket, Komet, komunikasi berat AJAX, dan sebagainya. Saya tahu bahwa model-driven, asynchronous, thread-driven modelnya juga bagus untuk concurrency dengan overhead yang rendah.

Saya juga melihat tutorial Node.js untuk aplikasi non-realtime yang lebih sederhana, 'tradisional', (misalnya, contoh blog standar, yang tampaknya menjadi standar 'Hello World' untuk orang yang mempelajari pengembangan aplikasi). Dan saya juga tahu bahwa simpul-statis memungkinkan Anda untuk melayani aset statis.

Pertanyaan saya adalah: apakah ada alasan bagus untuk menghindari Node.js untuk aplikasi web tradisional, seperti iklan baris, forum, contoh blog yang disebutkan di atas, atau jenis aplikasi CRUD yang Anda buat untuk aplikasi bisnis internal? Hanya karena ia unggul di semua hal realtime yang funky, apakah itu kontraindikasi untuk penggunaan yang lebih tenang?

Satu-satunya hal yang bisa saya pikirkan, adalah kelangkaan perpustakaan yang sudah matang (meskipun itu berubah).

(Alasan saya bertanya adalah bahwa saya sedang mempertimbangkan membuang PHP untuk Node.js, sebagian besar untuk mengatasi ketidakcocokan impedansi beralih antar bahasa, tetapi juga agar saya dapat menggunakan kembali kode validasi dan yang lainnya. Superego saya memperingatkan saya untuk memilih alat terbaik untuk pekerjaan itu , namun, saya tidak punya banyak waktu untuk belajar lima belas bahasa dan semua perpustakaan pengguna mereka hanya untuk memiliki gudang senjata yang komprehensif. Ini juga meyakinkan bahwa Node.js mungkin memberi saya jalur pengoptimalan yang lebih mudah daripada PHP / Apache di masa depan ketika saya harus mulai memikirkan lalu lintas yang padat.)

[EDIT] Terima kasih atas jawabannya sejauh ini, teman-teman; Saya hanya ingin melihat apakah ada orang lain yang mempertimbangkan sebelum saya memilih jawaban. Jawaban dari @Raynos agak mengkonfirmasi apa yang saya pikirkan, dan tautan dari komentator memberikan makanan yang baik untuk dipikirkan, tetapi saya ingin melihat apakah ada orang lain yang memiliki jawaban spesifik-Node, seperti 'JANGAN GUNAKAN NODE UNTUK MASALAH X ' (Selain tugas CPU tinggi; Saya sudah tahu :-)

web-development web-applications node.js

— Paul d'Aoust
sumber

1

@ default.kramer: Terima kasih atas tautannya, saya sangat menikmatinya!

— Zach

1

Wow! Chap agak berargumentasi, eh? Dalam artikel tindak lanjut, ia tampaknya mengatakan bahwa, untuk aplikasi I / O tinggi dan CPU rendah, sistem beralamat dan berulir kira-kira setara, dan bahwa masalahnya ada pada programmer pemula yang tidak tahu kapan harus menyerah pada acara dan menelurkan utas baru. Tetapi ketidaktahuan programmer tidak berarti alat itu buruk, bukan? Saya setuju bahwa menggunakan lingkungan yang nasibnya merupakan loop acara untuk tugas-tugas intensif CPU agak aneh, tetapi apakah itu jahat?

— Paul d'Aoust

1

Kebenciannya pada JavaScript tampaknya juga menjadi masalah penting, yang saya khawatirkan mungkin ikut bertanggung jawab atas energi di balik argumennya.

— Paul d'Aoust

@ Paul - Anda mungkin harus mengambilnya dengan sebutir garam. Saya tidak tahu banyak tentang Node.js; Saya hanya berpikir itu lucu. (Seperti kebanyakan tulisannya)

— default.kramer

@ default.kramer terima kasih atas pengingatnya; Saya cenderung menganggap pendapat orang sebagai Injil. Kritik utamanya yang valid tampaknya adalah bahwa Anda seharusnya tidak menggunakan Node.js untuk tugas-tugas yang intensif CPU. Saya bingung tentang kritiknya terhadap proses pekerja; Adakah masalah besar dengan menciptakan pekerja terpisah untuk tugas tertentu?

— Paul d'Aoust

13

apakah ada alasan bagus untuk menghindari Node.js dari aplikasi web tradisional

Ya, jika Anda memiliki N tahun di platform web X maka jelas Anda dapat mengembangkan aplikasi di platform X lebih cepat.

Jika Anda ingin melakukan Y dan platform X memiliki solusi pra-dibuat Y yang melakukan X maka lakukanlah.

Semua alasan umum mengapa Anda harus menggunakan satu platform di atas yang lain.

jenis aplikasi CRUD yang Anda buat untuk aplikasi bisnis internal?

Ya ada platform lain yang memungkinkan Anda menulis aplikasi generik lebih cepat, ruby on rails muncul di benak Anda.

Namun, itu dikatakan. Saya memiliki pengalaman dengan simpul dan tidak dapat mengklaim bahwa saya akan memilih platform lain daripada simpul kecuali ia melakukan sejumlah besar fitur di luar kotak bagi saya.

Pada dasarnya ini adalah pertanyaan sederhana

Apakah ada alat yang melakukan semua ini untuk saya? Tidak, lalu pilih platform yang paling nyaman untuk menulis alat.

Tidak ada alasan kuat mengapa node.js adalah platform yang tidak nyaman (selain "i hate javascript")

— Raynos
sumber

Jadi Anda pikir prinsip-prinsip pragmatis seperti keakraban, ketersediaan perpustakaan, dll, adalah argumen kuat untuk platform tertentu, eh? Itu adalah pikiran yang baik, dan itu pasti hal yang saya pertimbangkan. (Saya terkejut Anda mengadvokasi solusi out-of-the-box; Saya pikir Anda adalah pria yang agak

— aneh

@ Pauld'Aoust Saya seorang pria yang baik-baik saja. Namun saya tidak menyelesaikan apa-apa dan tidak punya tenggat waktu.

— Raynos

heh, terima kasih atas peringatannya. Saya ingat komentar Anda di node.js mengobrol tentang menggunakan perpustakaan model orang lain (Backbone.js, dll) dan menyadari bahwa saya menghabiskan terlalu banyak waktu untuk belajar Backbone.js dan tidak cukup waktu hanya mengambil keuntungan dari (dan belajar) JavaScript mekanisme pewarisan prototipikal. Saran yang bagus; Saya merasa jauh lebih santai sekarang.

— Paul d'Aoust

4

-1 samar-samar. 1) Hanya karena Anda memiliki pengalaman N tahun di X - tidak berarti Anda harus menghindari Node.JS. Apakah Anda mengusulkan ketidaktahuan yang disengaja berdasarkan pengalaman? Dan apa "alasan umum"? 2) 'aplikasi lain yang memungkinkan Anda menulis aplikasi generik lebih cepat' - adalah murni subjektif. 3) 'selain * * Saya benci * JavaScript' - juga subjektif dan bukan alasan yang sah untuk menghindari teknologi yang berkembang. * Ejaan.

— Jack Stone

@ClintNash beberapa alasan Anda tidak berbeda dengan alasannya. "Sumber Daya Manusia" vs "N tahun pengalaman" adalah sama persis. "NodeJS tidak setua kerangka tradisional" vs "Ya ada platform lain yang memungkinkan Anda menulis aplikasi generik lebih cepat, ruby on rails muncul di pikiran." juga sama. Tidak hanya mereka sama, tetapi milik Anda tidak lebih terukur (objektif) daripada miliknya.

— aaaaaa

6

Setelah bekerja dengan node selama beberapa minggu, saya akan mengatakan ya, itu sangat keren. Tetapi belum tentu sesuatu yang ingin Anda gunakan untuk mengganti aplikasi web yang sedang berjalan dengan ... atau, imo, memang seharusnya begitu.

Ingat, simpul adalah server sendiri. Ini memperkenalkan kompleksitas jika Anda ingin menjalankan lebih dari satu aplikasi node.js Anda. yaitu, jika Anda memiliki lebih dari satu situs / domain yang dihosting di mesin. Ini tidak seperti tumpukan LAMP, di mana Anda dapat memiliki selusin aplikasi PHP untuk setengah lusin domain yang berbeda menjalankan server yang sama (pada port 80, setidaknya). Ada kerangka kerja untuk simpul yang mungkin memungkinkan, tetapi menambahkan kompleksitas yang tidak Anda perlukan jika Anda terjebak pada platform web tradisional. (Anda tentu saja dapat juga mengatur proxy dengan meletakkan server web di depan node, tetapi hal tersebut mengalahkan manfaat menggunakan node).

imo, Node sangat cocok untuk bekerja bersama dengan server web tradisional. Cara saya mengatur hal-hal sekarang adalah untuk menyajikan html / js / gambar statis melalui apache, dan menangani kebutuhan data 'real time' dengan polling panjang ke aplikasi node.

— GrandmasterB
sumber

+1 kemudahan penggunaan dalam menyiapkan beberapa host jelas patut dipertimbangkan.

— Paul d'Aoust

Cukup mudah untuk meletakkan aplikasi simpul di belakang server Apache httpd atau nginx dan merutekan permintaan dengan tanda tangan URI aplikasi itu ke port node (atau port).

— TomG

+1 - gagasan node.js sebagai proxy sisi-server ('dalam hubungannya dengan server web tradisional') memperoleh daya tarik awal tahun ini dan layak untuk dilihat - terutama jika Anda memiliki arsitektur tradisional yang besar untuk dikelola. Ini adalah pola desain yang tampaknya masuk akal bagi perusahaan. Tapi, ini perlu diperhatikan - ini bukan alasan untuk MENGHINDARI Node.js tetapi alasan untuk menggunakannya untuk tujuan tertentu.

— Jack Stone

4

-1 - Menempatkan proxy (seperti nginx) di depan node adalah use case yang sempurna dan sebenarnya jauh lebih aman dan performant dalam beberapa kasus daripada tidak memilikinya sama sekali. Itu tidak mengalahkan manfaat node. Saya cenderung menjalankan aplikasi simpul saya di soket domain unix, dan kemudian memiliki nginx bertindak sebagai penjaga gerbang.

— Scott Anderson

3

Alasan yang baik untuk memiliki pemikiran detik tentang simpul tidak teknis - ini bagus dan menakjubkan pada apa yang dilakukannya.

Mereka adalah bisnis dan khususnya sumber daya manusia, yaitu programmer yang mengetahuinya, berapa biayanya dan ketersediaannya. Ini tidak terlalu sulit untuk dipelajari, tetapi seperti halnya dengan teknologi yang lebih baru, jumlah orang yang mengenalnya dengan baik (atau ingin) adalah subest dari kumpulan pekerja yang lebih besar.

— Michael Durrant
sumber

jadi Anda pikir tidak ada banyak yang menentang menggunakan Node di tempat tumpukan aplikasi yang lebih tradisional; masalah lebih banyak berkaitan dengan masalah dunia nyata?

— Paul d'Aoust

+1. Sumber Daya Manusia - dan keengganan beberapa orang untuk belajar JavaScript - adalah kebenaran yang tidak nyaman. Jawaban ini menyatakannya dengan baik. Tapi, menghindari Node "karena orang-orang Benci JavaScript" juga bukan perkembangan logis. Di mana kita akan secara teknis jika kita menghindari setiap inovasi - yang dibenci orang lain? Tidak ada tempat Tantangan dengan simpul adalah A) Mendapatkan bakat baru, atau B) Mendidik bakat tradisional menjadi bakat baru. Sampai saat itu - kita melihat sekolah kode JavaScript muncul di mana-mana sejak kejelian John Resig dalam mendirikan Khan Academy. Singkatnya, ini adalah jalan yang benar. +1. Dinyatakan dengan baik.

— Jack Stone

3

Ini adalah pertanyaan yang sangat bagus, yang harus kita tanyakan, agar terlalu memajukan seni.

Saya sangat ingin tahu (seperti Paul d'Aoust) di mana keterbatasan Node.JS ada. Sayangnya, banyak jawaban yang PENUH dari bias subyektif dan alasan yang relevan untuk sementara.

Saya bertanya pada diri sendiri: BISAKAH KITA MENYARANKAN BIAS SUBJEKTIF DAN MENDAPATKAN JAWABAN PADAT DENGAN PERTANYAAN YANG RELEVAN INI?

Poin yang tersisa tampaknya adalah:

1. NodeJS tidak setua Kerangka Tradisional. Seperti yang disarankan Paul d'Aoust, ini hanya alasan yang relevan untuk sementara waktu, bukan untuk penghindaran penuh - tetapi sebaliknya meninjau dan uji tuntas. Melakukan pekerjaan rumah kita sebagai profesional web diharapkan, dan itu adalah tugas kita untuk menentukan yang paling cocok dari teknologi untuk organisasi, kebutuhan mereka, masa depan mereka, tim (dan bukan kita). Kedewasaan adalah kebutuhan untuk klarifikasi dan penilaian untuk selera risiko, tetapi bukan penghindaran.

2. NodeJS sebagai Server Proxy. Sebuah saran bijak, dari diskusi sebelumnya, yang patut ditinjau dan dipertimbangkan. Ini adalah gagasan menggunakan Node dalam korelasi dengan teknologi yang ada sebagai pola desain proxy antarmuka front-end. Tetapi juga, itu bukan alasan untuk MENGHINDARI menggunakan node, tetapi sebagai alasan untuk menghindari menggunakannya sebagai pengganti penuh. Alih-alih memilih pendekatan wajar.

3. Debugging Node. Dalam percakapan dengan pengembang inti Node di Joyent ada banyak komplikasi seputar debuggability dan melacak kembali akar penyebab masalah yang dihasilkan dari inti (berdasarkan pada eksekusi thread tunggal dan ketidakmampuan untuk melihat ke thread sebelumnya). Ini patut dipertimbangkan dan dievaluasi - tetapi (sekali lagi) kemungkinan tidak benci untuk penggunaan umum hanya kasus tepi yang dapat mendorong amplop. Mungkin kebutuhan spesifik Anda akan masuk dalam kategori ini dan mungkin tidak.

4. Sumber Daya Manusia. Ini adalah alasan terbaik untuk MENGHINDARI menggunakan JS di halaman ini, dan menurut pendapat saya yang sederhana itu adalah kebenaran yang nyata dan tidak nyaman. Ini menimbulkan pertanyaan: apakah perusahaan Anda memiliki profesional berbakat yang tepat untuk melihat proyek melalui siklus hidup penuh? Jika tidak, tidak ada pertanyaan yang perlu Anda hindari NodeJS. Atau sebagai gantinya pertimbangkan A) menemukan bakat yang tepat, atau B) Mendidik bakat yang ada.

Keluhan: Pengamatan saya terhadap keluhan pada JavaScript adalah bahwa, banyak hasil lebih banyak dari Kesalahan Pengguna daripada kesalahan yang konsisten dari bahasa tersebut. Kami telah membantah banyak klaim terhadap "The Hate JavaScript Diatribe" dan kami akan terus membantah lebih banyak lagi. Masalah seperti - dokumentasi tidak cukup baik, tidak cukup seksi, tetapi orang tidak menyukainya, itu kanker, itu iblis, atau terlalu "salah ketik" (-Cichardson), bersifat subyektif dan keluhan bias yang perlu disingkirkan untuk pengambilan keputusan perusahaan yang akurat.

Pada akhirnya, jawaban yang benar mungkin - tidak ada alasan bagus untuk MENGHINDARI NodeJS . Mungkin inilah sebabnya ia mengalami pertumbuhan, adopsi, dan kontribusi yang cepat. Tetapi bagi kita semua, mungkin jawabannya di sini adalah untuk terus mengevaluasi, meneliti, dan memahami NodeJS dengan lebih baik - dan mencari keengganan yang nyata. Dalam upaya menjadi terbuka untuk memahami dengan tepat di mana Node.JS belum dewasa - kami menemukan di mana kita harus membuatnya lebih baik. Dan itu adalah berkah.

Pertanyaan bagus. Saya tetap ingin tahu seseorang untuk mengemukakan alasan yang lebih baik untuk menghindari NodeJS - daripada ini.

— Jack Stone
sumber

-1

Apakah ada manfaat menggunakan simpul lebih dari X untuk aplikasi non-realtime:

Penskalaan : Node memiliki kinerja yang baik tetapi platform lain juga; PHP, Ruby, Python, dan Java semua skala. Anda dapat menemukan nama-nama BESAR dengan jutaan pengguna menggunakannya.
Satu bahasa untuk frontend dan backend : Ini adalah lelucon, seperti halnya Java "Write once run anywhere"
Panas dan seksi : Satu-satunya poin yang valid. Tapi tidak ada yang peduli bahwa situs web Anda menggunakan teknologi edgy!

Manfaat menggunakan X over Node untuk aplikasi non-realtime:

Praktik Terbaik : Karena Node baru, ia memiliki praktik terbaik yang lebih sedikit daripada platform lain, khususnya untuk aplikasi web CRUD.
Bahasa Javascript : Orang tidak suka Javascript. Meskipun Node.js panas, Javascript tidak. Inilah sebabnya mengapa orang membuat Coffeescript untuk menghindari penulisan Javascript bahkan untuk sisi klien.
Mengembangkan Kecepatan : Kerangka kerja lama dan membosankan termasuk dan tidak terbatas pada Rails dan Django telah teruji dan ditingkatkan selama bertahun-tahun untuk situs web CRUD. Meskipun Anda dapat mengimplementasikan aplikasi serupa di Node, itu hanya lebih mudah dilakukan dalam kerangka kakek Anda.
Stabilitas : Kerangka kerja web Node menjadi lebih baik dengan kecepatan lebih cepat. Ini berarti mereka berubah dan akan memiliki lebih banyak ketidakcocokan API dalam waktu dekat.
Perpustakaan dan alat : Teknologi lama dengan lebih banyak pengguna memiliki lebih banyak perpustakaan dan alat.

Jawaban saya pasti tidak akan valid pada tahun 2015. Pada tahun 2014, lewati Node untuk aplikasi web non-realtime tetapi tetap awasi.

Setiap kerangka kerja web memiliki poin kuat. Anda akan bahagia saat Anda menggunakannya untuk saat itu. Aplikasi web non-realtime bukanlah titik kuat kerangka kerja web Node.

— Hossein
sumber

2

-1. Saya setuju jawaban ini tidak akan valid pada tahun 2015. Tapi itu juga alasan untuk downvote. Intinya - keputusan hari ini ADALAH keputusan untuk besok. Ini membatalkan 8 poin-poin di atas - jika kita dapat melihat bahwa mereka hanya sementara relevan. 1) Scaling - Walmart Mobile skala, bukan alasan untuk menghindari Node. 2) Isomorphic JS bukan lelucon. Bukan alasan. 3) Server Sexyness? Sebagian besar pengguna hanya tahu ux. 4) Praktik terbaik bersifat subyektif, 5) Tidak Panas? -subjective 6) Lebih mudah? -subyektif. 7) Stabilitas adalah titik sementara yang relevan. 8) NPM diproyeksikan lulus Maven pada 2014. Tidak ada alasan di sini. Downvote.

— Jack Stone

-1

Node.js adalah platform yang sangat populer dan memiliki banyak fitur menarik blah blah blah, tetapi penggunaan alat adalah preferensi pribadi. Saya memberi Node.js empat kali dan saya tidak senang dengan itu. Inilah alasan saya. Harap diingat bahwa beberapa alasan tersebut sudah usang, atau hanya bersifat pribadi: P

Saya lebih suka bahasa / sintaks yang berbeda (saya suka Python, Scala, bahasa favorit saya adalah Prolog jadi ya).
Kualitas dokumentasi untuk kerangka kerja dan pustaka yang saya gunakan tidak sebagus pustaka Java, Scala, Python.
Desainer dari nodejs sangat terobsesi dengan callback daripada model acara, pengamat atau masa depan.
Ada solusi siap untuk apa yang ingin saya lakukan di Ruby, Python, Java dikembangkan kembali pada tahun 2005, saya hanya perlu mengedit file konfigurasi.

— David Sergey
sumber

2

-1 - Poin subyektif. "Sintaks yang Diutamakan", "Dokumentasi tidak sebagus", "Callback Obsessive", dan "Sudah Dilakukan dalam bahasa saya" - semuanya kabur dan subyektif. Kami pernah mendengar ini sebelumnya. Mereka dibantah. Tidak ada alasan untuk menghindari Node.JS di sini. Downvote.

— Jack Stone

1

Semua poin adalah preferensi pribadi saya yang saya nyatakan secara terbuka. Juga bagaimana Anda menyanggah preferensi pribadi?

— David Sergey

-9

HTTP tidak memiliki kewarganegaraan, jadi sebenarnya tidak ada aplikasi web non-realtime dan karenanya tidak ada alasan Anda tidak dapat menggunakan simpul untuk semuanya.

Yang mengatakan, simpul lebih cocok untuk jenis arsitektur aplikasi tertentu. PHP adalah file html yang mengandung sedikit kode. Node adalah kode yang secara opsional mengandung sedikit html.

Ini berarti bahwa jika aplikasi Anda adalah bentuk html standar tanpa skrip sisi klien, PHP akan lebih mudah. Node memang memiliki alat templating, tetapi jelas tidak seatur sesuatu seperti PHP.

Jika Anda memiliki banyak skrip sisi klien dan menyimpan data dengan ajax, Anda berakhir dengan fungsi panggilan klien html statis di server. Persis seperti inilah simpulnya. Meskipun bukan cara aplikasi CRUD biasanya dibangun, Anda dapat menghasilkan sesuatu yang cukup bagus dengan kerangka kerja yang tepat.

— Tom Clarkson
sumber

Poin yang diambil tentang HTTP adalah stateless dan realtime-ish; namun, saya lebih tertarik pada keprihatinan pragmatis tentang definisi khas waktu nyata: volume tinggi permintaan berbobot rendah. Tampaknya agak berlebihan untuk memutar contoh PHP baru hanya untuk memuntahkan tiga atau empat baris JSON kadang-kadang. Apakah saya benar, atau apakah saya hanya menderita sindrom parrot?

— Paul d'Aoust

Jika Anda tidak memuat PHP, Anda memuat javascript, dan ada berbagai jenis caching yang terlibat, jadi perbedaannya tidak akan cukup untuk dikhawatirkan. Perbedaan besar adalah dalam gaya pengkodean dan karena itu rawatan - kedua platform dapat menampilkan HTML atau JSON, tetapi PHP dirancang untuk orang-orang yang digunakan untuk mengedit file html statis, sedangkan node dirancang untuk orang-orang yang terbiasa dengan pemrograman javascript modern.

— Tom Clarkson

Saya tahu bahwa saya harus memuat penerjemah beberapa waktu, tetapi saya melihat manfaatnya dengan menjalankan salah satu contoh penerjemah sepanjang waktu (untuk aplikasi dengan CPU yang rendah, tentu saja) seperti pada Node.js daripada memiliki interpreter berputar. bangun dan akhiri dengan setiap permintaan, seperti dalam PHP.

— Paul d'Aoust

Ya, dan saya juga berharap js akan memiliki kinerja yang lebih baik pada tingkat permintaan individu mengingat jumlah kompetisi di ruang itu baru-baru ini. Namun, saya pikir itu adalah bagian yang relatif kecil dari perbedaan - Dengan node Anda memiliki kontrol langsung dan persis jumlah kode yang diperlukan untuk melayani permintaan, sementara sistem berbasis template yang mengasumsikan Anda melayani halaman akan menambah overhead yang tidak perlu dan kompleksitas dalam skenario lain.

— Tom Clarkson