Có một lý do chính đáng để tránh node.js cho các ứng dụng web không phải thời gian thực không?

Tôi đã thấy rất nhiều cuộc nói chuyện về việc Node.js tuyệt vời như thế nào đối với các ứng dụng web thời gian thực - những thứ cần ổ cắm, Comet, giao tiếp nặng AJAX, v.v. Tôi biết rằng mô hình hướng sự kiện, không đồng bộ, theo hướng sự kiện của nó cũng tốt cho việc tương tranh với chi phí thấp.

Tôi cũng đã xem các hướng dẫn của Node.js cho các ứng dụng phi truyền thống, 'truyền thống', đơn giản hơn (ví dụ: ví dụ blog tiêu chuẩn, dường như là tiêu chuẩn 'Hello World' cho những người học phát triển ứng dụng). Và tôi cũng biết rằng nút tĩnh cho phép bạn phục vụ các tài sản tĩnh.

Câu hỏi của tôi là: có lý do chính đáng nào để tránh Node.js cho các ứng dụng web truyền thống, như rao vặt, diễn đàn, ví dụ blog đã nói ở trên hoặc loại ứng dụng CRUD bạn xây dựng cho các ứng dụng kinh doanh nội bộ không? Chỉ vì nó vượt trội trong tất cả những thứ thú vị thời gian thực, liệu điều đó có chống chỉ định cho những mục đích sử dụng nhiều hơn không?

Điều duy nhất tôi có thể nghĩ ra, ngoài con dơi, là thiếu các thư viện trưởng thành (mặc dù điều đó đang thay đổi).

(Lý do tôi hỏi là tôi đang xem xét ditching PHP cho Node.js, chủ yếu là để vượt qua các impedance mismatch chuyển đổi giữa các ngôn ngữ, nhưng cũng vì vậy tôi có thể sử dụng lại mã xác nhận và không có điều gì. Superego tôi khuyên nhủ tôi để chọn Công cụ tốt nhất cho công việc , tuy nhiên, tôi không có nhiều thời gian để học mười lăm ngôn ngữ và tất cả các thư viện người dùng của họ chỉ để có một kho vũ khí toàn diện. Tôi cũng yên tâm rằng Node.js có thể cho tôi một con đường tối ưu hóa dễ dàng hơn PHP / Apache trong tương lai khi tôi phải bắt đầu nghĩ về lưu lượng truy cập lớn.)

[EDIT] Cảm ơn câu trả lời cho đến nay, folks; Tôi chỉ muốn xem liệu có ai khác sẽ cân nhắc trước khi tôi chọn một câu trả lời không. Câu trả lời từ @Raynos kinda xác nhận những gì tôi đang nghĩ và các liên kết từ những người bình luận đã cung cấp thực phẩm tốt cho suy nghĩ, nhưng tôi muốn xem liệu có ai khác có bất kỳ câu trả lời cụ thể nào về Node không, như 'KHÔNG SỬ DỤNG NODE CHO VẤN ĐỀ X '. (Bên cạnh các tác vụ CPU cao; tôi đã biết rằng :-)

Có lý do chính đáng nào để tránh Node.js cho các ứng dụng web truyền thống không

Có, nếu bạn có N năm trong nền tảng web X thì rõ ràng bạn có thể phát triển một ứng dụng trong nền tảng X nhanh hơn.

Nếu bạn muốn làm Y và nền tảng X có một giải pháp Y được tạo sẵn mà X thì làm như vậy.

Tất cả các lý do chung về lý do tại sao bạn nên sử dụng một nền tảng trên một nền tảng khác.

loại ứng dụng CRUD bạn xây dựng cho các ứng dụng kinh doanh nội bộ?

Vâng, có những nền tảng khác cho phép bạn viết một ứng dụng chung nhanh hơn, ruby ​​trên đường ray xuất hiện trong tâm trí.

Tuy nhiên, điều đó nói rằng. Tôi có kinh nghiệm với nút và không thể khẳng định tôi sẽ chọn một nền tảng khác qua nút trừ khi nó có một số lượng lớn các tính năng vượt trội cho tôi.

Về cơ bản đó là một câu hỏi đơn giản về

Có một công cụ tồn tại mà làm tất cả những điều này cho tôi? Không, sau đó chọn nền tảng thuận tiện nhất để viết công cụ.

Không có lý do chắc chắn tại sao node.js là một nền tảng bất tiện (khác với "tôi ghét javascript")

Sau khi làm việc với nút được vài tuần, tôi nói có, nó rất tuyệt. Nhưng không nhất thiết là thứ gì đó bạn muốn sử dụng để thay thế các ứng dụng web hiện đại của bạn bằng ... cũng không, imo, có phải là dự định không.

Hãy nhớ rằng, nút là máy chủ của riêng nó. Điều này giới thiệu sự phức tạp nếu bạn muốn chạy nhiều hơn chỉ một ứng dụng node.js của bạn. tức là, nếu bạn có nhiều hơn một trang web / tên miền được lưu trữ trên một máy. Nó không giống như ngăn xếp LAMP, nơi bạn có thể có hàng tá ứng dụng PHP cho nửa tá tên miền khác nhau chạy trên cùng một máy chủ (ít nhất là trên cổng 80). Có các khung cho nút có thể làm được, nhưng đó là sự phức tạp mà bạn không cần nếu bạn mắc kẹt với các nền tảng web truyền thống. (Tất nhiên, bạn cũng có thể thiết lập proxy bằng cách đặt máy chủ web trước nút, nhưng đó là loại đánh bại lợi ích của việc sử dụng nút).

imo, Node hoàn hảo để làm việc kết hợp với máy chủ web truyền thống. Cách tôi sắp xếp mọi thứ bây giờ là phân phát html / js / hình ảnh tĩnh thông qua apache và xử lý các nhu cầu dữ liệu 'thời gian thực' bằng cách bỏ phiếu dài cho ứng dụng nút.

Một lý do chính đáng để có vài giây suy nghĩ về nút không phải là kỹ thuật - thật tuyệt vời và tuyệt vời với những gì nó làm.

Họ là doanh nghiệp và đặc biệt là nguồn nhân lực, tức là các lập trình viên biết điều đó, họ có giá bao nhiêu và tính sẵn có của họ. Điều đó không khó để học, nhưng như với bất kỳ công nghệ mới hơn nào, số người biết rõ về nó (hoặc muốn) là một nhóm nhỏ trong nhóm công nhân lớn hơn.

Đây là một câu hỏi rất hay, mà chúng ta phải hỏi, để quá tiến bộ của nghệ thuật.

Tôi đã rất tò mò muốn biết (như Paul thủy âm) nơi những hạn chế của Node.JS tồn tại. Đáng buồn thay, nhiều câu trả lời ĐẦY ĐỦ sự thiên vị chủ quan và lý do tạm thời có liên quan.

Tôi đã tự hỏi mình: CHÚNG TÔI CÓ THỂ LẬP TỨC BIAS ĐỐI TƯỢNG VÀ TẢI XUỐNG ĐỂ GIẢI QUYẾT TRẢ LỜI CHO CÂU HỎI LIÊN QUAN NÀY KHÔNG?

Các điểm còn lại dường như là:

1. NodeJS không trưởng thành như các Khung truyền thống.Như Paul thủy âm gợi ý, đây chỉ là một lý do tạm thời có liên quan, không phải để tránh hoàn toàn - mà thay vào đó là xem xét và siêng năng. Làm bài tập về nhà của chúng tôi như các chuyên gia web được mong đợi và công việc của chúng tôi là xác định sự phù hợp nhất của công nghệ với tổ chức, nhu cầu của họ, tương lai của họ, nhóm (chứ không phải chúng tôi). Trưởng thành là một nhu cầu để làm rõ và đánh giá sự thèm ăn cho rủi ro, nhưng không phải là tránh.

2. NodeJS là máy chủ proxy.Một đề nghị khôn ngoan, của các cuộc thảo luận trước, đó là giá trị xem xét và xem xét. Đó là khái niệm sử dụng Node tương quan với các công nghệ hiện có làm mẫu thiết kế proxy giao diện mặt trước. Nhưng ngoài ra, đó không phải là lý do để AVOID sử dụng nút, mà thay vào đó là một lý do để tránh sử dụng nó như một sự thay thế hoàn toàn. Thay vào đó chọn cách tiếp cận hệ quả.

3. Nút gỡ lỗi. Trong cuộc trò chuyện với các nhà phát triển Node cốt lõi tại Joyent, có nhiều sự phức tạp xung quanh khả năng sửa lỗi và truy tìm nguyên nhân gốc rễ của các vấn đề phát sinh từ lõi (dựa trên thực thi luồng đơn và không thể nhìn vào các luồng trong quá khứ). Điều này đáng để xem xét và đánh giá - nhưng (một lần nữa) có thể không ác cảm đối với việc sử dụng thông thường chỉ các trường hợp cạnh có thể đẩy phong bì. Có thể nhu cầu cụ thể của bạn sẽ rơi vào loại này và có thể chúng sẽ không.

4. Nhân sự. Đây là lý do tốt nhất để TRÁNH sử dụng JS trên trang này và theo ý kiến ​​khiêm tốn của tôi, đó là một sự thật phũ phàng và bất tiện. Nó đặt ra câu hỏi: công ty của bạn có các chuyên gia tài năng phù hợp để xem dự án trong suốt vòng đời không? Nếu không, không có câu hỏi mà bạn cần tránh NodeJS. Hoặc thay vào đó hãy xem xét A) định vị tài năng chính xác hoặc B) Giáo dục tài năng hiện có.

Khiếu nại: Quan sát của tôi về các khiếu nại về JavaScript là, nhiều kết quả từ Lỗi người dùng hơn là do các lỗi ngôn ngữ nhất quán. Chúng tôi đã gỡ bỏ nhiều khiếu nại chống lại "The Ghate JavaScript Diatribe" và chúng tôi sẽ tiếp tục gỡ lỗi nhiều hơn nữa. Những vấn đề như - tài liệu không đủ tốt, nó không đủ gợi cảm, nhưng mọi người không thích nó, đó là ung thư, là ma quỷ, hoặc nó quá "dễ bị đánh máy" (-CRichardson), là chủ quan và khiếu nại thiên vị cần được loại bỏ để đưa ra quyết định chính xác của công ty.

Cuối cùng, câu trả lời đúng có thể là - không có lý do chính đáng nào để TRÁNH NodeJS . Có lẽ đây là lý do tại sao nó đang trải qua sự tăng trưởng nhanh chóng, áp dụng và đóng góp. Nhưng đối với tất cả chúng ta có lẽ câu trả lời ở đây là tiếp tục đánh giá, nghiên cứu và hiểu rõ hơn về NodeJS - và tìm kiếm những ác cảm cụ thể. Theo đuổi việc mở để hiểu chính xác nơi Node.JS chưa trưởng thành - chúng tôi tìm thấy chính xác nơi chúng tôi cần để làm cho nó tốt hơn. Và đó là một phước lành.

Câu hỏi hay. Tôi vẫn tò mò muốn ai đó đưa ra một lý do tốt hơn để tránh NodeJS - hơn những điều này.

Có bất kỳ lợi ích nào của việc sử dụng nút trên X cho các ứng dụng không theo thời gian thực không:

• Chia tỷ lệ : Node có hiệu suất tốt nhưng các nền tảng khác cũng vậy; PHP, Ruby, Python và Java tất cả các quy mô. Bạn có thể tìm thấy tên LỚN với hàng triệu người dùng đang sử dụng chúng.
• Một ngôn ngữ cho frontend và backend : Đó là một trò đùa, giống như "Viết một lần chạy ở bất cứ đâu" của Java
• Nóng bỏng và gợi cảm : Điểm hợp lệ duy nhất. Nhưng không ai quan tâm rằng trang web của bạn đang sử dụng công nghệ sắc sảo!

Lợi ích của việc sử dụng X trên Node cho các ứng dụng không phải thời gian thực:

• Thực tiễn tốt nhất : Vì Node là mới nên nó có ít thực tiễn tốt nhất so với các nền tảng khác, đặc biệt dành cho các ứng dụng web CRUD.
• Ngôn ngữ Javascript : Mọi người không thích Javascript. Trong khi Node.js nóng, Javascript thì không. Đây là lý do tại sao mọi người tạo Coffeescript để tránh viết Javascript ngay cả cho phía khách hàng.
• Tốc độ phát triển : Các khung cũ và nhàm chán bao gồm và không giới hạn ở Rails và Django được thử nghiệm và cải thiện tốt trong nhiều năm cho các trang web CRUD. Mặc dù bạn có thể triển khai các ứng dụng tương tự trong Node, nhưng nó dễ thực hiện hơn trong khuôn khổ của ông bạn.
• Tính ổn định : Các khung web của Node đang trở nên tốt hơn với tốc độ nhanh hơn. Điều đó có nghĩa là họ đang thay đổi và sẽ có nhiều khả năng không tương thích API hơn trong tương lai gần.
• Thư viện và công cụ : Các công nghệ cũ hơn với nhiều người dùng hơn có nhiều thư viện và công cụ hơn.

Câu trả lời của tôi chắc chắn sẽ không có giá trị trong năm 2015. Trong năm 2014, hãy bỏ qua Node cho các ứng dụng web không phải thời gian thực nhưng hãy chú ý đến nó.

Mỗi khung web có một điểm mạnh. Bạn sẽ hạnh phúc trong khi bạn đang sử dụng nó cho điểm đó. Các ứng dụng web không phải thời gian thực không phải là điểm mạnh của khung web của Node.

Node.js là nền tảng rất phổ biến và nó có rất nhiều tính năng thú vị blah blah blah, nhưng sử dụng một công cụ là một sở thích cá nhân. Tôi đã cho Node.js bốn lần và tôi không hài lòng với nó. Đây là lý do của tôi. Xin lưu ý rằng một số lý do đã lỗi thời hoặc đơn giản là cá nhân: P

• Tôi thích ngôn ngữ / cú pháp khác nhau (Tôi thích Python, Scala, ngôn ngữ yêu thích của tôi là Prolog nên yeah).
• Chất lượng tài liệu cho các khung và thư viện mà tôi đã sử dụng không tốt cho các thư viện Java, Scala, Python.
• Các nhà thiết kế của nodejs khá bị ám ảnh bởi các cuộc gọi lại thay vì mô hình sự kiện, người quan sát hoặc tương lai.
• Có sẵn các giải pháp cho những gì tôi muốn làm trong Ruby, Python, Java được phát triển trở lại vào năm 2005, tôi chỉ cần chỉnh sửa tệp cấu hình.

HTTP là không trạng thái, vì vậy thực sự không có thứ gọi là ứng dụng web không theo thời gian thực và do đó không có lý do gì bạn không thể sử dụng nút cho mọi thứ.

Điều đó nói rằng, nút phù hợp hơn cho một kiểu kiến ​​trúc ứng dụng cụ thể. PHP là các tệp html chứa một chút mã. Nút là mã tùy ý chứa một chút html.

Điều này có nghĩa là nếu ứng dụng của bạn là các dạng html tiêu chuẩn mà không có bất kỳ tập lệnh phía máy khách nào, PHP sẽ dễ dàng hơn. Node không có các công cụ tạo khuôn mẫu, nhưng rõ ràng là không trưởng thành như một cái gì đó như PHP.

Nếu bạn có nhiều tập lệnh phía máy khách và lưu dữ liệu bằng ajax, bạn sẽ kết thúc với chức năng gọi máy khách html tĩnh trên máy chủ. Đây chính xác là những gì nút tốt. Mặc dù không phải là cách các ứng dụng CRUD thường được xây dựng, bạn có thể tạo ra một cái gì đó khá đẹp với khung đúng.