2012-04-17 25 views
34

Tôi làm việc trên một ứng dụng web dựa trên Java lớn, nó đã được xây dựng trong 5 năm qua - giao diện người dùng cần một đại tu/được viết lại phần lớn. Chúng tôi đang nghiên cứu các công cụ/thư viện/khung công cụ giao diện người dùng có sẵn để sử dụng và đã xem qua dust.js làm tùy chọn cho việc tạo khuôn mẫu.Chọn công cụ tạo khuôn mẫu giao diện người dùng phù hợp - dust.js?

Những câu hỏi: Tôi muốn nghe những gì người dùng của dust.js suy nghĩ của nó:

  1. Có phải là đã thành công?
  2. Có dễ sử dụng không?
  3. Tài liệu có đủ tài liệu không?
  4. Hỗ trợ cộng đồng có tốt không? (Chỉ có 6 câu hỏi về ST tagged 'dust.js'!)
  5. những ưu và khuyết điểm là gì khi so sánh với các công cụ khuôn mẫu khác như Underscore 's khuôn mẫu, Google Closure Templates, HandlebarsMustache.
  6. Có vấn đề gì khi sử dụng khung công tác với cấu trúc MV *, ví dụ: Backbone.js (online book)?

Một số nền:

  • Tại sao chúng ta quan tâm đến dust.js: Các LinkedIn bài đăng trên blog sau đầu tiên đã thu hút sự chú ý của chúng tôi với nó:

    • Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates
    • The client-side templating throwdown: mustache, handlebars, dust.js, and more 012 Thứ hai của hai bài viết rất độc đáo trả lời câu hỏi 5, nhưng bên cạnh LinkedIn, rất ít kết quả từ Google chi tiết hệ thống templating hoặc ngụ ý rằng nó là một lựa chọn phổ biến. Ngoài ra, bài viết đề cập rằng họ đã mở rộng chức năng và hy vọng một ngày sẽ đóng góp cho dự án ban đầu. Tôi lo ngại rằng cho đến khi họ làm điều đó, chúng tôi cũng có thể cần phải mở rộng chức năng. Sau khi nói điều này, các yêu cầu ban đầu của LinkedIn đối với hệ thống tạo khuôn mẫu rất gần với chúng tôi (xem bên dưới) và họ đã thực hiện một số điều tra rất kỹ lưỡng trước khi chọn.

  • yêu cầu của chúng tôi:

    1. DRY: Chúng tôi lý tưởng muốn sử dụng hệ thống khuôn mẫu trên máy chủ (Java dựa) và client-side, hay chỉ là client-side nếu chúng ta lựa chọn Cách tiếp cận hoàn chỉnh của LinkedIn; Instead of using a JSP, GSP, or ERB to assemble a page server side and send back HTML, we have the server send back just the dynamic data as JSON and have the page assembled in the browser using a static client-side template served from a CDN"
    2. Hoàn toàn được quốc tế hóa
    3. hỗ trợ cộng đồng Tốt
    4. túc dễ sử dụng/nhặt
    5. trình hạnh phúc với jQueryBackbone.js
    6. Vâng ghi
+0

Đây là một trang thử nghiệm nhỏ gọn mà tôi đã tìm thấy: http://linkedin.github.com/dustjs/test/test.html –

Trả lời

39

Dust.js là một lựa chọn tốt. Nó tốt hơn so với một số khung khuôn mẫu khác vì nó không hạn chế dữ liệu phải ở trong một tệp hoặc trong một chuỗi, v.v.

Ngoài ra, nó đang được duy trì tích cực https://github.com/linkedin/dustjs.

  1. Đã thành công chưa?

    Vâng, tôi biết ít nhất LinkedIn đang sử dụng nó và cũng có thể góp phần cải thiện/bản vá lỗi, vv

  2. Có dễ sử dụng không?

    Tôi đã thử sử dụng nó và dễ dàng như Mustache hoặc Handlebars.js.

  3. Tài liệu có đủ tài liệu không?

    http://akdubya.github.com/dustjs.

  4. Hỗ trợ cộng đồng có tốt không? (chỉ 6 câu hỏi trên ST được gắn thẻ 'dust.js'!)

    Nếu bạn đang so sánh Mustache hoặc Handlebars.js, dust.js không có nhiều người dùng, nhưng tôi tin rằng nếu bạn gặp sự cố và đăng nó lên repo LinkedIn họ chắc chắn sẽ trả lời. Tôi cũng sẽ vì tôi đang xem nó :-)

  5. Ưu và khuyết điểm khi so sánh với các công cụ tạo khuôn mẫu khác như khuôn mẫu của gạch dưới, Mẫu đóng cửa của Google, Tay lái và Ria mép.

    Đối với những người chuyên nghiệp, bạn có thể kiểm tra thời điểm bạn nên cân nhắc sử dụng dust.js tại đây https://github.com/linkedin/dustjs#readme.

    Đối với nhược điểm, không có đủ người dùng cho dust.js so với những người dùng phổ biến như Mustache hoặc Handlebars.js. Điều đó nói rằng, các thư viện khác như Google Closure cũng gặp phải vấn đề tương tự.

    Nhưng như tôi đã đề cập trước đây, dust.js được thiết kế rất tốt so với các khung công tác khác IMHO.

  6. Có vấn đề gì khi sử dụng nó với khung cấu trúc MV *, ví dụ: Backbone.js (sách trực tuyến)?

    Tôi đã không sử dụng nó với các khung công tác MVC khác, nhưng tôi không nghĩ rằng nó sẽ là một vấn đề.

Hy vọng điều đó sẽ hữu ích.

+0

Cảm ơn, tôi đã bỏ lỡ trang này trong các tìm kiếm của tôi - https://github.com/ linkedin/dustjs –

+0

http://engineering.linkedin.com/frontend/client-side-templating-throwdown-mustache-handlebars-dustjs-and-more –

+0

Paypal cũng đang sử dụng nó để hiển thị phía máy khách và máy chủ. – ontk

6
  1. Tôi đang làm một dự án tự do hiện nay cho một công ty CNTT khá lớn và được thành lập và họ đã chọn dust.js cho khung ứng dụng dành cho thiết bị di động HTML5 của họ. Và có, LinkedIn là một công ty lớn và thành công.

  2. Sắp xếp. Không có gì thực sự khó khăn nhưng tôi cần làm quen với nó. Tôi đã làm việc với Freemarker trên Java - Freemarker có vẻ khá dễ sử dụng hơn một chút vì có rất nhiều tính năng được tích hợp sẵn. Tuy nhiên, nhiều người có thể tìm thấy dust.js tốt đẹp - nó có logic rõ ràng, cú pháp rất nhẹ - có nhiều thứ trong dust.js thực sự thích cho nhiều người.

  3. Trình đánh dấu cho Java được ghi nhận tốt hơn nhiều. Trang GitHub của dust.js rất ổn cho người mới bắt đầu nhưng, ví dụ, tôi không thể tìm thấy mô tả của tất cả các bộ lọc dust.js ở đó và cần tìm kiếm trên Google - tuy nhiên, tìm kiếm đó dễ dàng cung cấp cho tôi thông tin tôi cần thiết.

  4. Không thấy nhiều hỗ trợ cộng đồng nhưng thư viện thực sự nhẹ và rõ ràng - một vài tìm kiếm trên Google là tất cả những gì tôi cần để thu thập tất cả thông tin cần thiết.

  5. Không sử dụng các công cụ tạo khuôn mẫu JS khác.

  6. Công ty tôi đã đề cập trong câu trả lời cho câu hỏi thứ nhất đã xây dựng một khung HTML5 nhẹ bằng cách sử dụng dust.js cùng với cả jQuery và Backbone.js. Tôi đang thực hiện dự án cho họ bằng cách sử dụng khung công tác đó và khai thác cả chức năng jQuery và Backbone.js mọi lúc - không có gì để phàn nàn. dust.js hơi giống Backbone.js - nhẹ và không áp đặt nhiều hạn chế về kiểu mã hóa của bạn hoặc các thư viện khác mà bạn sử dụng. Sử dụng nó, bạn sẽ thấy rằng có một số dạng JS thích hợp hơn bạn sử dụng để nạp dữ liệu với dữ liệu nhưng thật dễ dàng để quen với (ý tôi là nếu bạn cần danh sách thứ gì đó trong quan điểm của bạn và không phải JS đối tượng băm mà cùng một lúc là tự nhiên tại mô tả các thực thể riêng biệt).

Một điều về hiệu suất - bạn có thể phát triển ứng dụng của mình với phiên bản "đầy đủ" và sau đó biên dịch mẫu của bạn để sản xuất (ví dụ: node.js + dust.js npm module - grunt có thể hữu ích tại đây) được sử dụng với phiên bản "lõi". Trong trường hợp này, bạn có thể tăng cường hiệu suất trong thế giới thực - đặt tất cả các mẫu lại với nhau và rút gọn chúng sẽ giải phóng trình duyệt của khách hàng khỏi tìm nạp các mẫu từ máy chủ mỗi khi cần. "Đầy đủ" và "cốt lõi" không phải là về thương mại/miễn phí - phiên bản cốt lõi chỉ không có trình biên dịch mẫu và sẽ được sử dụng với các mẫu được biên dịch trước.

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