Выбор правильного инструмента для шаблонов пользовательского интерфейса - dust.js?

Я работаю над большим веб-приложением на основе Java, он был создан за последние 5 лет - пользовательский интерфейс нуждается в капитальном ремонте/в значительной степени переписан. Мы изучаем доступные инструменты/библиотеки/рамки UI для использования и встретили dust.js в качестве опции для шаблонов.

Вопросы: Мне интересно узнать, что пользователи dust.js думают об этом:

  • Успешно ли это?
  • Легко ли использовать?
  • Достаточно ли это документально оформлено?
  • Поддерживается ли поддержка сообщества? (только 6 вопросов на ST помечены "dust.js" !)
  • Каковы плюсы и минусы по сравнению с другими инструментами шаблонов, такими как Underscore templating, Google Closure Templates, Handlebars и Mustache.
  • Существуют ли какие-либо проблемы с его использованием структуры структуры MV *, например Backbone.js (онлайн-книга)?

Немного фона:

  • Почему мы заинтересованы в dust.js: следующие сообщения LinkedIn вначале обратили наше внимание на это:

    • Выход из JSP в пыли: перемещение LinkedIn в шаблоны клиентской панели dust.js

    • Клиентская настройка шаблонов: усы, рули, dust.js и т.д.

      Вторая из двух должностей очень хорошо отвечает на вопрос 5, но, как из LinkedIn, очень мало результатов от Google, детализирующей систему шаблонов, или подразумевают, что это популярный выбор. Кроме того, в сообщении упоминается, что они расширили функциональность и надеются однажды внести свой вклад в оригинальный проект. Я обеспокоен тем, что пока они этого не сделают, нам также может потребоваться расширить функциональность.

      Сказав это, оригинальные требования LinkedIn для системы шаблонов очень близки к нашим (см. ниже), и перед тем, как выбрать, они сделали очень тщательные исследования.

  • Наши требования:

    • DRY: Мы в идеале хотим использовать систему шаблонов на сервере (на основе Java) и на стороне клиента или просто на стороне клиента если мы выберем полный подход 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"
    • Полностью интернационализированный
    • Хорошая поддержка сообщества.
    • Достаточно легко использовать/подбирать
    • Хорошо работает с jQuery и Backbone.js
    • Хорошо документировано

Ответы

Ответ 1

Dust.js - хороший вариант. Это лучше, чем некоторые другие шаблоны шаблонов, потому что это не ограничивает того, что данные должны быть в файле или в строке и т.д.

Также он активно поддерживается https://github.com/linkedin/dustjs.

  • Успешно ли это?

    Да, я знаю, что, по крайней мере, LinkedIn использует его, а также вносит улучшения/исправления и т.д.

  • Легко ли использовать?

    Я попытался использовать его, и он так же прост, как Mustache или Handlebars.js.

  • Достаточно ли он документирован?

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

  • Поддерживается ли поддержка сообщества? (только 6 вопросов по ST помечены "dust.js"!)

    Если вы сравниваете Mustache или Handlebars.js, у dust.js не так много пользователей, но я считаю, что если у вас есть проблема и отправьте ее в репозиторий LinkedIn, они определенно ответят. Я тоже с тех пор, как буду смотреть: -)

  • Каковы плюсы и минусы по сравнению с другими инструментами шаблонов, такими как шаблоны Underscore, шаблоны Google Closure, ручные и усы.

    Как и для профессионалов, вы можете проверить, когда вы должны рассмотреть использование dust.js здесь https://github.com/linkedin/dustjs#readme.

    Как и в случае с минусами, пользователей dust.js недостаточно, по сравнению с такими популярными, как Mustache или Handlebars.js. Тем не менее, другие библиотеки, такие как Google Closure, страдают той же проблемой.

    Но, как я уже упоминал ранее, dust.js разработан очень хорошо по сравнению с другими системами IMHO.

  • Есть ли проблемы с использованием структуры структуры MV *, например Backbone.js(онлайн-книга)?

    Я не использовал его с другими фреймворками MVC, но я не думаю, что это должно быть проблемой вообще.

Надеюсь, что это поможет.

Ответ 2

  • Сейчас я занимаюсь проектом freelance для довольно большой и созданной нишевой ИТ-компании, и они выбрали dust.js для своей платформы мобильных приложений HTML5. И да, LinkedIn - большая и успешная компания.

  • Сортировка. Ничего сложного, но мне нужно было привыкнуть к нему. Я работал с Freemarker на Java - Freemarker казался довольно легким в использовании из-за множества встроенных функций питания. Тем не менее, многие могут найти dust.js nice - у него есть четкая логика, очень легкий синтаксис - вещи в dust.js действительно нравятся многим.

  • Freemarker для Java был документирован намного лучше. Страница dust.js GitHub очень хорошо для начинающих, но, например, я не мог найти описание всех фильтров dust.js и искать в Google для нее - однако этот поиск легко предоставил мне информацию я необходимо.

  • Не видел много поддержки сообщества, но библиотека была очень легкой и понятной - для поиска всей необходимой информации понадобилось несколько поисков Google, чтобы собрать всю необходимую информацию.

  • Не использовались другие инструменты шаблонов JS.

  • Компания, упомянутая в ответе на 1-й вопрос, построила легкую структуру HTML5 с использованием dust.js вместе с jQuery и Backbone.js. Я делаю проект для них, используя эту фреймворк, и все время нажимаю на функции jQuery и Backbone.js - не на что жаловаться. dust.js немного похож на Backbone.js - легкий и не накладывает много ограничений на ваш стиль кодирования или другие библиотеки, которые вы используете. Используя его, вы увидите, что есть некоторые предпочтительные формы объектов JS, которые вы используете для подачи данных, но их легко привыкнуть (я имею в виду, если вам нужны списки чего-то в ваших представлениях, лучше кормить dust.js списками а не хэш-объекты JS, которые в то же время являются естественными при описании отдельных объектов).

Одна вещь о производительности - вы можете создать свое приложение с "полной" версией, а затем скомпилировать свои шаблоны для производства (используя, например, node.js + dust.js npm module - grunt может быть здесь полезен) с "основной" версией. В этом случае вы могли бы получить мощный импульс в реальной производительности - объединение всех шаблонов и их минимизация освободят клиентский браузер от выбора шаблонов с сервера каждый раз, когда он им понадобится. "Полный" и "Ядро" не связаны с коммерческими/бесплатными - основная версия просто не имеет компилятора шаблона и должна использоваться с предварительно скомпилированными шаблонами.