Học phát triển web: Django vs Node vs Rails vs Other [đã đóng cửa]


80

Tôi biết Java và Python (với một số Django) và một chút về Ruby (không có Rails) và không có Node.js và có lẽ còn nhiều thứ nữa mà tôi không biết.

Tôi đang có kế hoạch bắt đầu học phát triển web và ngăn xếp hoàn chỉnh của nó, nhưng khi tôi quan sát xung quanh, tôi thấy vô số tùy chọn và điều này khiến tôi bối rối. Tôi cần đề xuất dựa trên các thông số sau

  1. dễ học
  2. dễ xây dựng và lặp lại
  3. dễ triển khai (như các giải pháp lưu trữ miễn phí và giá rẻ)
  4. phổ biến

Xin vui lòng ném một số lời khuyên

Cảm ơn bạn


GWT của googles thì sao? Hay grails?
Angel O'Sphere

Câu trả lời:


82

Viên ngọc trên tay vịn:

Dễ học? - Có - tài liệu tuyệt vời tại Guide.rubyonrails.org và hướng dẫn tuyệt vời tại railstutorial.org .

Dễ dàng xây dựng và lặp lại? - chắc chắn - đường ray có khả năng phát triển nhanh và lặp đi lặp lại rất tốt.

Dễ dàng triển khai? - Để triển khai (ít nhất là đối với các ứng dụng nhỏ và trong khi học), bạn không thể thực sự dễ dàng hơn việc sử dụng heroku.com - git dựa trên push và hoàn toàn miễn phí.

Mức độ phổ biến - rất phổ biến!

Django

Dễ học? - giống như Rails, Django có tài liệu tuyệt vời tại docs.djangoproject.com/en/1.3/ . Có thể là một đường cong học tập hơi dốc (hoàn toàn là ý kiến ​​ở đây, nhưng tôi thấy đường ray có xu hướng "sẵn sàng hoạt động" trong khi django cần một chút cấu hình trước khi bạn bắt đầu phát triển).

Dễ dàng xây dựng và lặp lại? - một lần nữa, giống như Rails, một khi bạn đã thiết lập và chạy với nó, việc lặp lại khá dễ dàng.

Dễ dàng triển khai? - không dễ dàng như Rails. Có các phiên bản tương đương với heroku gondor.io , djangozoom.com , stable.io nhưng chúng có xu hướng ở phiên bản beta riêng tư. Điều đó nói rằng, tôi không gặp khó khăn gì khi nhận được lời mời tham gia gondor.io .

Mức độ phổ biến - nó phổ biến, nhưng cộng đồng người dùng kém .... sôi nổi hơn đám đông Rails.

Nút

Dễ học? - ừm có và không, dễ dàng để đặt một máy chủ hello world nhanh chóng lại với nhau, nhưng phức tạp hơn nếu bạn muốn có một ứng dụng quy mô đầy đủ. Tôi sẽ tránh xa điều này trong trường hợp đầu tiên - nó mới và đang phát triển nhanh chóng. Ngoài ra, bản thân Node không thể so sánh với Rails hoặc Django vì hai cái sau là các framework trong khi Node là một bộ apis đơn giản hơn mà bạn có thể sử dụng để phát triển một cái gì đó. Bạn có thể chọn một khuôn khổ như expressjs.com phù hợp hơn với Rails và Django. Tôi đã không sử dụng nó nên tôi thực sự không thể cho bạn ý kiến.

Dễ dàng xây dựng và lặp lại? - dễ xây dựng - có, dễ lặp lại - có.

Dễ dàng triển khai? - bạn có thể chuyển đến no.de và đăng ký để nhận một chiếc máy thông minh - hiện tại miễn phí và dễ triển khai - dựa trên git.

Mức độ phổ biến - nó đang tăng lên.


13
Tôi đồng ý với 3 điểm đầu tiên của bạn về RoR. Thật không may, điểm cuối cùng của bạn không đúng. Có lẽ thật đáng tiếc, nhưng RoR không phổ biến trong thực tế. Nhìn vào Tiobe, Ruby chỉ có 1,3% thị phần, nghĩa là RoR thậm chí còn ít hơn. Nhìn vào các công việc được cung cấp cho các đường ray. Rất khó để tìm một cái.
Mike Braun

4
đủ công bằng Mike - có lẽ cộng đồng mạng chỉ gây ồn ào đến mức tôi nhận thấy rằng nó phổ biến. :)
slthelownote

2
Tôi thực sự không biết, nhưng nếu bạn kết hợp tất cả các câu hỏi được gắn thẻ với các khung công tác Web Java, bạn sẽ không đạt được bất kỳ đâu gần với số lượng câu hỏi Rails trên SO. Đó là 1,3% thị phần cho bạn.
Filip Dupanović

19
Heroku hiện hỗ trợ Django.
Ben Racine

5
Thực tế là có nhiều câu hỏi SO hơn cho Rails có thể là một chỉ báo về kiểu lập trình viên đang cố gắng tìm hiểu nó hơn là mức độ phổ biến của khung công tác trong các ứng dụng được triển khai thực tế. Một loạt các newbs sẽ có một loạt các câu hỏi
A_funs

44

Một vài ghi chú từ nhà phát triển Django, người đã dành một chút thời gian khám phá Node.js:

  • Cách tiếp cận lập trình không đồng bộ trong Node.js khó hơn về mặt khái niệm. Mặc dù bạn có thể thực hiện cách tiếp cận tương tự trong Django hoặc Rails, nhưng cách làm như vậy không phổ biến.

  • Node.js thực sự, rất nhanh. Nhưng một phần lý do là nó không bao gồm nhiều OOB.

  • Thế giới Node hiện đang rất phân mảnh, với hàng tá thư viện, giải pháp và khung công tác Node đang cạnh tranh để thu hút sự chú ý. Express có vẻ là khuôn khổ phổ biến nhất cho Node ngay bây giờ, nhưng chúng ta đang chờ đợi xem điều gì sẽ xảy ra. Django và Rails đã có tất cả các bit bạn cần để tạo các ứng dụng nâng cao mà không cần phải tự kết dính mọi thứ lại với nhau.

  • Khung công tác phổ biến nhất cho Node.js hiện tại là Express, nhưng Express thậm chí còn không bao gồm cách kết nối với cơ sở dữ liệu. Bạn phải thêm điều đó vào. Nó cũng không bao gồm ORM - bạn cần phải thêm nó vào. Tôi đã xem xét một số Node ORM, nhưng chúng dường như không hoàn chỉnh hoặc phức tạp như Django.

  • Django là một giải pháp hoàn chỉnh, gắn kết, từ đầu đến cuối, nơi tất cả các bộ phận khớp với nhau một cách liền mạch ("theo cách của Mac"). Node.js là đường cơ sở mà trên đó bạn chọn khung công tác của riêng mình, ORM của riêng bạn, trình điều khiển db của riêng bạn, hệ thống định tuyến URL của riêng bạn, v.v. ("cách Unix").

  • Phương thức Unix có những ưu điểm, nhưng các hệ thống IMO như thế này khó phát triển hơn và khó bảo trì hơn. Các phần không nhất thiết phải nói chuyện với nhau như bạn mong đợi và toàn bộ dự án không được nâng cấp cùng một lúc. Các hệ thống end-to-end như phần mềm / phần cứng liên tục của Mac và Django / Rails là những thành công lớn về năng suất. Để so sánh, hãy lưu ý sự mù mờ tương đối của TurboGears của Python (một loạt các phần bị ngắt kết nối) so với Django. Django đã ăn bữa trưa của TurboGears vì nó gắn kết và nhất quán. Nếu năng suất là quan trọng đối với bạn, bạn sẽ làm việc năng suất hơn trong một khuôn khổ trưởng thành hơn. Một khung công tác Node.js đáp ứng tầm nhìn này sẽ đến vào một ngày nào đó, nhưng nó vẫn chưa có.

  • Express không cung cấp nhiều công cụ dòng lệnh hữu ích, API dữ liệu, v.v. mà Django hoặc Rails cung cấp.

  • Các khung công tác Node.js chắc chắn không bao gồm bất kỳ thứ gì như quản trị viên Django, đây là một chiến thắng năng suất lớn cho các nhà phát triển Django.

  • Hoàn toàn là ý kiến ​​của tôi, nhưng Python chỉ cảm thấy thanh lịch hơn Javascript. Mã nhỏ gọn hơn và dễ đọc hơn. Tuy nhiên, không phải là một trở ngại lớn, chỉ là một sở thích.

Nhìn chung, Django cảm thấy giống như một nền tảng "bao gồm pin" trong khi Node giống như một cuộc mua bán lục lọi hơn.

Node / Express thực sự rất trẻ. Thú vị theo nhiều cách và cho thấy nhiều hứa hẹn, nhưng sẽ mất bao lâu để các khung công tác Node.js cảm thấy cạnh tranh với các khung công tác trưởng thành? Tôi không biết.


3
với CoffeeScript. Mã nhỏ gọn hơn và dễ đọc hơn nhiều như Python
jwchang

"Express là một khuôn khổ web tối giản, nhanh chóng, chưa được tích hợp sẵn cho Node.js" từ trang chính của Express.

27

Về cơ hội việc làm, tôi cho rằng bạn sẽ có được một công việc tốt nếu đi cùng Rails hoặc Django. Hiện chỉ có một số công ty thực sự trả tiền cho các nhà phát triển Node.js, vì nó chưa đủ lớn.

Về cơ hội khởi nghiệp, Rails hoàn toàn có thể. Hầu hết các cơ hội khởi nghiệp thú vị và thú vị đều được hỗ trợ bởi Ruby on Rails. Tôi đã bắt gặp một vài người sử dụng Django. Nhưng các công ty như Groupon và Living Social đều được viết chủ yếu trên Rails. Ruby cũng phổ biến gần gấp đôi Python trên Github . Và có câu hỏi Quora này:

Về tương lai, Node.js là con đường. Các mẫu HTML bắt đầu được viết gần như hoàn toàn bằng JavaScript ( jQuery.tmpl ), vì vậy việc tạo ra nó để bạn chỉ cần thông thạo 1 ngôn ngữ, JavaScript, sẽ làm cho bộ kỹ năng của bạn trở nên mạnh mẽ hơn nhiều. Và node.js thực sự có lợi cho các ứng dụng web thời gian thực . Thêm vào đó, đám mây nền tảng triển khai như Heroku, mà ban đầu 100% ruby, cũng đang bắt đầu để hỗ trợ Node.js . Có những người khác cũng làm điều đó cho tất cả các ngôn ngữ, như dotcloud .

Vẫn còn rất nhiều việc cần phải làm để Node.js có đầy đủ tính năng như Ruby on Rails (vì vậy Rails vẫn là tiêu chuẩn hiện tại), nhưng những điều cơ bản đã có:

Nếu bạn muốn vượt trội, chắc chắn Node.js. Nếu bạn muốn

  1. dễ dàng để học
  2. dễ xây dựng và lặp lại
  3. dễ triển khai (như các giải pháp lưu trữ miễn phí và giá rẻ)
  4. phổ biến

Viên ngọc trên tay vịn.


5

Phổ biến (điểm 4)): Công nghệ Java Server Faces (JSF) . Từ JSF 1.2 đến JSF 2.1 hiện tại, nó hiện trùng với Java EE 5 và Java EE 6 tương ứng. Điều đó có nghĩa là bây giờ nó là một Tiêu chuẩn Java EE. Ngoài ra, một lợi thế sẽ có nghĩa là Máy chủ Ứng dụng Web (chẳng hạn như JBoss AS 5 trở lên, GlassFish, WebSphere AS, Oracle AS, v.v.) hoàn toàn tuân thủ Java EE (5 trở lên) có thể chạy JSF (không cần cấu hình, để giải quyết điểm c)).

Có rất nhiều hướng dẫn khác nhau cho JSF, ví dụ như trong CoreServlets . BalusC đã viết một hướng dẫn đơn giản và tuyệt vời về cách thiết lập và viết một Ứng dụng web JSF đơn giản từ đầu.


3
Tôi hoàn toàn đồng ý! JSF ngày nay rất tốt (các phiên bản cũ không tuyệt vời như vậy). Thêm vào các ví dụ của bạn; JSF cũng là một phần của Java EE Web Profile, vì vậy các máy chủ siêu nhẹ như Resin cũng hỗ trợ JSF ngay lập tức.
Mike Braun

1
Các blog và bài báo của Ps BalusC là hoàn toàn tuyệt vời! :)
Mike Braun

1

JSF 2.x ngày nay trở nên quá phổ biến và nhiều khung làm trung tâm giao diện người dùng hơn kết hợp với các giao diện nguyên tố , nếu bạn cần phát triển ứng dụng nhanh chóng trong hệ sinh thái JSF như rails, bạn nên xem xét

http://www.springfuse.com/

http://www.myeclipseide.com/documentation/quickstarts/ME4STutorialScaffoldingJSF/scaffoldingjsfarticle.html

Spring Roo với JSF Addon http://java.dzone.com/articles/jsf-20-spring-roo

1)ease to learn (http://www.vogella.com/articles/JavaServerFaces/article.html)

2)ease to build and iterate

3)ease to deploy (like free and cheap hosting solutions) 

   a) http://www.mkyong.com/google-app-engine/google-app-engine-jsf-2-example/
   b) http://blog.jelastic.com/2012/06/11/how-to-deploy-primefaces-applications-into-jelastic-cloud/

4)popular (http://www.primefaces.org/whouses.html)
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.