Привет.
Поделитесь личным опытом.
Какие дополнительно фреймворки (javascript, css) или другие инструменты вы использовали для создания Visialforce страниц?
jQuery наверное используют все 
Мне еще приходилось использовать Twitter Bootstrap в разработке customer portal.
Сталкивался ли кто с js библиотеками Backbone, Knockout или аналогичными, для создания RIA приложение и интеграции с Salesforce?
В работе столкнулся с Backbone, а так же в целях самообразования покрутил AngularJS. И вот в принципе мои выводы:
Учитывая неспособность salesforce в принципе работать с достаточно большим объёмом данных - можно смело использовать AngularJS. Все отмечают его медленность по сравнению с Backbone(особенности реализации, в том числе темплейтирование c псевдо-html и соответственно его парсингом), но на тех объёмах данных с которыми мы можем работать по средствам APEXа со всеми его лимитами эта самая неспешность не критична. При этом сам функционал фрэймворка в коробке даёт те возможности которые на Backbone придётся накручивать самостоятельно.
Также для тех кто ещё не видел рекомендую посмотреть готовые реализации простейших приложений на Angular, Backbone и jQueryMobile от самого salesforce http://www2.developerforce.com/mobile/getting-started/html5
Вот вопрос такого плана назрел.
Насколько это оправдано использовать Backbone или AngularJS с Salesforce? Насколько возможности данных фреймворков выше стандартных возможностей visualforce page. Скажем так, если бы вам предложили выбирать использовать нативный SF или JS фреймворк, то какое решение приняли бы вы как разработчик?
Дмитрий, ну по крайней мере два момента можно назвать с ходу:
1. При необходимости создания одностраничного сайта. Реализовывать это можно и стандартными средствами(кучей секций с рендером, пагинацией через setcontroller и т.д.), но это уже слишком порнографией попахивает. 
Сложно ориентироваться в странице в несколько десятков тысяч строк. А при использовании фрэймворка, допустим Backbone и подключенного темплейтера типа mustache каждый отдельный темплейт можно вынести в статик ресурс и подгружать на страницу по необходимости. Ну и в целом однастраничные сайты с хэшэм и якорями сейчас в тренде. В эту же категорию можно отнести страницы внутри salesforce орга, когда кастомер просит всё и в одном месте. Объект с десятками релэйтед листов на которых можно редактировать, создавать записи не уходя с этой самой одной страницы. По сути продуктивный проект на котором мы бекбон решили использовать - это и есть по сути целая CRM в одной странице. Сэйлс-менеджер на неё зашёл и может никуда не уходить весь рабочий день. 
2. Реализовав страницу по средствам фрэймворка можно не бояться вылететь по вью стэйту. Темплэйторы имеют функциональность схожую с <apex:repeat> но на вью стэйт никак не влияет. Таким образом в теории - хотите отобразить 50000 записей - никаких проблем, ничего не упадёт - никаких ошибок с вью стэйтом(но грузиться будет долго, особенно в ангулар). Стандартными средствами таблицы падали парой и на 800 записях, плюс лимит на вывод в одном репите равен 1000.
Николай, спасибо за ответ. Очень интересно услышать про реальный опыт.
Но вот как-то не особо приятно звучит хранить часть логики (вернее большую ее часть) страницы в статик ресурсах. Наверное не самое приятно занятие потом поддерживать такой код? У меня был один раз опыт размещения куска js в статик ресурсах - это было то еще извращение с постоянной упаковкой и заливкой архива на орг. Больше я такие эксперименты не хотел повторять.
А по поводу большого количества записей на странице - как показала практика это не проблема SF или кода. Это проблема проектирования (каюсь сам был грешен). Ну нафига на странице 1000, 10000, 50000 записей. Какой адекватный админ будет рыться во всем этом? Если я сталкиваюсь с коллекциями более 200 записей, то тут приходится экстренно придумывать и применять всякие поиски, фильты, пагинации.
Сори что пока принимаю сторону SF. Но пока вижу только возможность применения js frameworks для customer portals где отключается вся функциональность SF. Для internal пользователей отход от стандартных стилей и элементов SF это плохой тон. Хотя если умело скрестить тот же AngularJS и стандартные стили, чтобы было максимально похоже на родной интерфейс - вот это уже очень интересная задача.
Ну как раз таки поддерживать и добавлять/убирать что при таком темплейтном подходе куда проще чем искать что-то в классе на 4К строк и такого же размера странице. Опять же незазипованные статик ресурсы(именно в таком безархивном виде логично заливать одиночные темпейты и js файлы) открываються и редактируються прямо в эклипсе. В общем всё не так плохо. ;)
