ANTVirGEO

/**
     * @var array|\Closure the HTML attributes for the data cell tag. This can either be an array of
     * attributes or an anonymous function that ([[Closure]]) that returns such an array.
     * The signature of the function should be the following: `function ($model, $key, $index, $gridView)`.
     * A function may be used to assign different attributes to different rows based on the data in that row.
     *
     * @see \yii\helpers\Html::renderTagAttributes() for details on how attributes are being rendered.
     */
    public $contentOptions = [];

Зависит от приложения и архитектурных требований.

Во-первых, компонентный или action-based?

Компонентные — легко писать (i.e. «разрабатывать большие сложные гуи») но долго разрабатывать кастомные компоненты, приложение будет в среднем тяжелее (медленнее) и будет жрать больше памяти (особенно JSF имплементации с conversation state сохраненным в HttpSession) на одного юзера. Кроме того, их нередко сложно кластеризовать из-за плохого использования сессии библиотеками.
Из компонентных: JSF (XxxFaces), Tapestry 5, GWT. Тапестри 5 не советую — имел опыт разработки большого публичного сайта на нем. Посоветовал бы попробовать GWT — слышал максимум положительных отзывов от людей, кто что-либо на нем делал. Опять-таки, лично я не советую JSF — сразу потеряете контроль за тем, что находится у вас в сессии, приложение станет «тяжелым».

Action-based фреймворки: чуть медленнее разработка, легко сделать приложение stateless и получить простую кластеризацию, приложение получается легковесным и быстрым.
Посоветую такие комбинации: Spring MVC + FreeMarker, Spring MVC + Velocity, Spring MVC + JSP 2 (EL-based). Слышал положительные вещи про Stripes (но он очевидно менее популярен, чем Spring MVC) и Play (всем хорош, кроме странных архитектурных закидонов — например, предлагается пихать бизнес-логику в модели, а не в выделенный сервис-леер. одно это скорее всего будет для вас критично).

Потом, что еще надо учесть —
1) HTML это не XML. Если движок шаблонов использует XML — это уже не очень хорошо. DOCTYPE, browser-specific комменты придется вставлять через хаки.
2) streaming, not buffering. Правильная работа с вебом — писать в outputStream по ходу, а не копить строчку и потом выбрасывать ее целиком. Почти все компонентные фреймворки грешат лишней буферизацией, многие action-based тоже. Отсюда завышенные требования к памяти, OOME при генерации тяжелых страниц, etc.
3) Обратите особое внимание на то, как в выбранном фреймворке сделаны Layouts — они должны быть удобные (ie. ближе к Django-style) и имплеменчены без буферинга (см. п. 2)
4) Если ваш фреймворк диктует вам одну конкретную прошитую javascript-библиотеку — подумайте дважды. Для intranet приложения это может сработать. Для публичного — я бы взял другой фреймворк. GWT вроде используют в паблике, но я лично с ним не работал.
5) Если к сервису понадобится REST Api, возьмите сразу фреймворк, в котором это есть, а не надейтесь на авось.

В целом так. Дадите больше требований к приложению — могу посоветовать что-то более конкретное.