2012-02-22 30 views
15

Tôi đã phát triển java toàn thời gian, bây giờ tôi cũng làm việc trên JavaScript. vài năm trở lại khi tôi bắt đầu học JavaScript, thư viện đầu tiên tôi đã thử là jquery giống như hầu hết mọi người. Nhưng nó làm cho cuộc sống của tôi trở nên khó khăn hơn, và đôi khi tôi bắt đầu viết một ứng dụng JavaScript khá lớn. Nó không đến với tôi bằng cách sử dụng jquery. Tôi có một bộ mã nguồn rất lớn mà không có nhiều cấu trúc. Đó là các khối phương pháp cập nhật các khối HTML bằng cách sử dụng các bộ chọn. Sau đó, tôi đã thử mootools và lãng quên như một nhà phát triển java nó kêu gọi tôi rất nhiều. Và tôi đã có thể viết các ứng dụng web có thể quản lý có cơ sở mã lớn.Là mootools thay thế của jquery + xương sống/cột sống/sprouteCore

Theo hiểu biết của tôi, Mootools không được coi là cách ưa thích để viết JavaScript vì nó bắt chước OO thông thường trên ngôn ngữ OO dựa trên nguyên mẫu mặc định. Vì vậy, bây giờ để thực sự hiểu javascript và mong muốn đi bộ với thế giới, tôi quyết định thử phương pháp tiếp cận khác, vì vậy một lần nữa tôi quay trở lại jquery, và nhận ra rằng chỉ jquery là không đủ. Vì vậy, bắt đầu xem xét các khuôn khổ xu hướng hiện tại như xương sống, cột sống, ember.js, sprouteCore. Kỳ lạ là tôi thấy rằng các khung này ở lõi của chúng cố gắng bắt chước các OO thông thường như mootools chỉ bằng cách có các hàm tạo và tạo một đối tượng của lớp và tái sử dụng đối tượng lớp này để tạo các đối tượng thể hiện. Vì vậy,

  • Tôi có thiếu gì đó không?
  • Đường mootools có thực sự sai không?
  • dự án
  • Mootools là rất sống động và phiên bản mới phiên bản/tính năng, nhưng tôi không thấy nhiều người nói về nó trên mạng Internet, cũng không có comparisions vs xương sống/cột sống, vv
+0

er. Mootools không sai bởi một biên độ dài. Tôi làm việc với một nhóm các nhà phát triển java đã chọn nó chính xác vì mẫu oo cổ điển. Có một cộng đồng nhỏ hơn nhưng phát triển mạnh xung quanh nó với một số ppl rất am hiểu thực sự. Mặc dù mootools đã có kế thừa, sự kiện, vv, nó không phải là một giải pháp chính xác mvc clientside của chính nó. Tôi sẽ đăng thêm khi tôi có thời gian. –

+0

hay không. Bài viết khác của bạn có tựa đề 'moootools chống lại loại thế giới 'đặt âm điệu sai. Gl mặc dù. –

+0

@title đã thay đổi .. – Nachiket

Trả lời

41

Như theo hiểu biết của tôi, Mootools không được coi là một cách ưa thích để viết JavaScript vì nó bắt chước OO thông thường trên ngôn ngữ OO dựa trên nguyên mẫu mặc định.

Bạn nhận được từ đâu? Điều tuyệt vời nhất về javascript là được đánh máy rất lỏng lẻo (xem những gì tôi đã làm ở đó) - bạn có thể viết cùng một điều theo một cách đầy đủ. Cũng có rất nhiều cách để trừu tượng hóa nó và đóng gói lại - và điều này áp dụng từ một đơn giản new Array()[] về cách bạn cấu trúc ứng dụng của mình.

Nếu bạn yêu thích JavaScript (hoặc chỉ biết và bí mật ghét nó), bạn sẽ ổn với MooTools. API chủ yếu là bản địa js hoặc thông số ES5 hoặc - hiếm khi - một tiện ích bổ sung cũng cảm thấy 'tự nhiên'. Ngoại lệ đáng chú ý nổi bật là Class. Và thực tế là bạn có thể trừu tượng phải đối phó với sự thừa kế nguyên mẫu bằng cách truyền một đối tượng đến một hàm tạo đặc biệt Type hàm trả về cá thể của bạn là ... oh đợi đã. Nó trông khác nhau nhưng những gì nó hiện khá nhiều âm thanh như javascript bình thường. Chỉ dễ dàng hơn - tại sao sẽ không bạn thích điều đó?

Rất nhiều thứ đang được thực hiện trong những ngày này của sự bùng nổ MVC của khách hàng và 'cách phát triển ứng dụng mới' này. Đột nhiên, những người sử dụng jQuery đã được đưa ra sự sang trọng của nước máy! Tôi đã nói chuyện với rất nhiều của các nhà phát triển MooTools về điều này và (un) đáng ngạc nhiên phát hiện ra rằng hầu hết các MooTools nghĩ rằng hiếm khi cần bất cứ điều gì như thế. Tôi có xu hướng đồng ý với họ. Lỗ hổng duy nhất là một bộ điều khiển xem với khuôn mẫu nhưng có một vài giải pháp hợp lý.

Điều này là, bạn không thể trực tiếp so sánh khung MVC với MooTools, nó không giống nhau. Ở tất cả. Bạn có thể so sánh cái gọi là constructor Model vs Classes.

Tôi hiện đã dành một chút thời gian nghiên cứu các giải pháp và khuôn khổ MVC khác nhau để xem ứng dụng mới của chúng tôi có thể được tạo thành hình dạng 'thực hành tốt nhất' hay không.

Về cơ bản, tôi đã thử backbone.js (với và w/o một bộ chuyển đổi mootools) và thấy nó khó xử khi sử dụng sau khi MooTools - nó cảm thấy như một bước trở lại. Khi tôi nói sử dụng Tôi không có nghĩa là tôi không thể sử dụng nó nhưng nó cảm thấy khó xử với mở rộng và tích hợp. Tôi chắc chắn nó chỉ xuống để trải nghiệm, mặc dù, vẫn chưa đọc tất cả các ví dụ mẫu xương sống ra khỏi đó.

Vấn đề điển hình tôi gặp phải - muốn có một thuộc tính Mô hình đặc biệt cho phép sử dụng localStorage để tìm nạp/lưu. Không rõ ràng như thế nào - ví dụ có xu hướng hiển thị cho bạn hoặc có thể tuyến đường Backbone.sync đến một hoặc khác nhưng không phải cả hai cùng một lúc. Tôi đã thực sự trang trí chức năng và mở rộng nó, giữ nguyên bản gốc được tham chiếu trong trường hợp mô hình không yêu cầu localStorage. KHÔNG phải là mô hình tốt nhất/rõ ràng nhất để duy trì và để tôi phụ thuộc vào những thay đổi của họ không vi phạm mã của tôi.

Trong MooTools, tôi đã chỉ cần mở rộng lớp Mô hình của mình và có thể đã xác định thuộc tính Biến thể lớp tùy chỉnh (như Binds hoặc Implements). Làm xong. Viết những gì bạn biết, họ nói, và không có gì ...

Một vấn đề khác - nó được kết hợp chặt chẽ với dữ liệu và bạn không thể sử dụng lại các mô hình như lớp học - ví dụ: Mô hình người dùng tải người dùng và hiển thị thông qua chế độ xem Chỉnh sửa người dùng . Sau đó, bạn muốn tạo một khách hàng mới và đột nhiên, bạn không thể sử dụng lại đối tượng cũ dễ dàng và chỉ hiển thị cùng một chế độ xem nhưng với các giá trị rỗng. Tôi nghĩ rằng nó cũng sẽ làm giảm sự thiếu kinh nghiệm về kiến ​​trúc của tôi hoặc một phần không tốt.

Ember.js Tôi tìm thấy hơi moo-ish như một giao diện mặc dù Nó không hoàn toàn nhấp vào một trong hai. Thành thật mà nói, xương sống là ít rắc rối để thiết lập.

Có nhiều lần thử khác. Composer là một - một lần nữa cho mootools nhưng nó cố gắng quá khó để được xương sống và được viết bởi những người tương đối mới với khuôn khổ vì vậy tôi sẽ không gọi nó trưởng thành. Knockout vv vv Có một cái mới mỗi ngày, theo nghĩa đen.

Garrick Cheung đã phát hành một khung có tên là Neuro có tiềm năng rất lớn.

Tôi đã viết Epitome - một triển khai MVP đầy đủ dựa trên các lớp và sự kiện và được bao bọc trong các mô-đun AMD, vui lòng kiểm tra. Nó cũng đi kèm với một người xây dựng, xây dựng tài liệu và nhiều tính năng nhỏ để giúp bạn bắt đầu.

SeanMonstar phát hành Shipyard, được sử dụng bởi Mozilla Flight Deck - http://seanmonstar.github.com/Shipyard/. Trong khi đó nó không phải là mootools bản địa, đó là mootools-ish với mootools lớp vv - chỉ w/o mở rộng người bản xứ, do đó, một thay thế tuyệt vời.

BTW, hãy thử irc.freenode.net #mootools hoặc danh sách thư và bạn sẽ luôn nhận được câu trả lời hay.

Dù sao, đủ trên MVC. Các điểm về MooTools đã được thực hiện vô số lần. Haters sẽ là kẻ thù. Những người yêu thích nó không nhìn lại. Nếu bạn là một lập trình viên từ một nền tảng OOP hoặc đang tìm kiếm thứ gì đó thể hiện bản thân tốt cho các mẫu, hãy tự làm một việc và gắn bó với nó. Thời gian thú vị đang ở phía trước. Lộ trình cho 1.5: AMD, cho 2.0 (aka, Prime) Đối tượng lưu trữ tạo mẫu tùy chọn. Đây là hai điểm thảo luận lớn nhất trong con mắt các nhà phê bình. Không còn nguyên mẫu 'bẩn' để mọi người có thể tiếp tục sử dụng ... trong các vòng lặp không chính xác trên các đối tượng không phải và không có kiểm tra hasOwnProperty. Dù sao...

Những điều khác cần phải lo lắng về điều này có thể rất quan trọng. Giống như, kích thước của 'cộng đồng'. Tôi nghĩ rằng có một cộng đồng lành mạnh là một điều tuyệt vời nhưng ngay cả khi bạn nhìn vào jquery, số lượng người đóng góp thực tế so với người dùng thấp. Tỷ lệ CODE chất lượng so với hiệu ứng tìm kiếm tốt là xấu. Các plugin bạn có thể sử dụng - rất nhiều plugin không được viết hay chết và không được hỗ trợ. Khi bạn vẽ đường thẳng, nó ít hấp dẫn hơn bạn nghĩ!

Tôi không nói rằng mootools hoặc các khung công tác khác không có những vấn đề này. Nó là công bằng để nói MooTools người và đặc biệt là các devs lõi là khá riêng tư và ít giọng hát về những gì họ làm. Nó có thể gửi ấn tượng sai, tôi không biết. Nó chắc chắn không phải là jQuery. Cuối cùng - nếu bạn có tài nguyên và bí quyết, hãy sử dụng những gì hoạt động tốt nhất và những gì sẽ mở rộng. Thậm chí có những cái sử dụng coffeescript và thề bởi nó. Tôi là ai để phán xét ...

Vì lợi ích của việc tiết lộ đầy đủ - bạn sẽ thấy khó khăn hơn khi tìm một nhà phát triển mootools đàng hoàng khi bạn tuyển dụng. Không thể bỏ qua ...

+4

* Vì lợi ích của việc tiết lộ đầy đủ - bạn sẽ thấy nó khó hơn để tìm ra một mootools phong nha dev khi bạn tuyển dụng. * - True đủ, mặc dù chúng tôi giảm thiểu vấn đề này bằng cách nhìn vào mặt tươi sáng: bạn sẽ đào tạo một người nào đó để sử dụng Mootools ngay từ đầu, mà không phải phá vỡ mọi thói quen khó chịu. –

+1

Vâng nói Dimitar! –

+1

Tôi mới phát triển web, javascript và mootools, nhưng tôi phải nói rằng tôi yêu mootools đặc biệt là kể từ khi tôi chủ yếu viết trong Delphi. Tôi cũng đã tự hỏi nếu tôi nên cố gắng tìm hiểu JQuery như có vẻ là meny nhiều nhà phát triển trên stackoverflow đặt câu hỏi. Nhưng sau khi đọc thêm về mootools.net và bài viết này, tôi nghĩ tôi sẽ tiếp tục như vậy, câu trả lời rất hay Dimitar. – Dampsquid

Các vấn đề liên quan