Хочу спросить в основном о GWT, я в чем то не прав? Как вам технология? Тяжеловесная?

http://code.google.com/p/closure-templates/

GWT не вписывается в стек Java.

Правда, я такое и сам заметил и от других слышал. Хотя вообщем-то я смотрел поверхностно

а почему?

Спасибо за совет, но это тоже всего навсего движек темплейтов. В моем списке уже есть Velocity и XSLT. В обеих (мне уже) не надо учить еще один язык и никаких тулзовин для компиляции кода.

> В моем списке уже есть

Velocity

Cам, же сказал, только «server side»

XSLT

Вообще мне даже страшно предположить с чем приходиться работать, если кажется, что «XML/XSLT - прекрасная технология».

Apache Click подходит по всем параметрам кроме случая с JavaScript. Но насчет продуктивности, там напротив, очень все хорошо, видно, что разработчики фреймворка поработали над удобством повторного использования кода.

Если смотреть активность мейл-листов, то лидеры - Play! framework, Grails, GWT, Spring MVC.

но ничего особенного и нужет Spring, низкоуровневая штука

Поверь, что-то более особенное, чем Spring MVC ты и не найдешь. Если понравился Spring MVC, но хочется отвязаться от самого Spring, то посмотри на Jersey со включенной поддержкой JSP. Хз правда, умеет ли оно JSTL, а то голого JSP маловато будет.

ЗЫ. Был еще хороший проект - Google SiteBricks, да жаль загнулся.

ЗЗЫ. Я не спец по XSL, но знаю людей, которые от него ловят приходы. Можно попробовать сделать на нем свою библиотечку, таким образом повысить его «уровневость».

> Вообще мне даже страшно предположить с чем приходиться работать, если кажется, что «XML/XSLT - прекрасная технология».

JSF

K.O.

> Хз правда, умеет ли оно JSTL, а то голого JSP маловато будет.

JSTL - обычный taglib.


K.O.

Play! и Grails - жир, погоняемый толстотой и нагромождением фреймворков

>Wicket, Tapestry - маргинальщина
Викет давно уже мейнстрим, привет. Очень удобная на мой взгляд библиотека. Функционала чуть меньше чем в JSF, но и проще она в разы.

Я бы все таки выбрал бы jsf, благо он довольно шустр, несмотря ни на что, особенно вторая версия. И использовал бы richfaces.

та ну ладно вам. Я писал когда-то OpenFaces - опенсорсная библиотека компонент - вполне вменяемая штука этот JSF, как изнутри так и снаружи. А уж сколько компонент уже есть и работают OutOfTheBox - так такого больше нигде нету. RichFaces, PrimeFaces, IceFaces, ADF и т.д.

> вполне вменяемая штука этот JSF, как изнутри так и снаружи.

Ага, только для его использования надо скрестить ui:define с ui:insert в представлении, наложить это на маппинг урлов, и только потом забрезжит рассвет хотя бы логики контролёров.

Человек слаб. На таком фоне его легко искусить @RequestMapping'ом.

Лишние абстракции - лишний мусор на пути к светлому и чистому.

Во-во.

> Play! и Grails - жир, погоняемый толстотой и нагромождением фреймворков

Grails - да, но только если вы уже не используете Spring + Spring-MVC + SiteMesh + Hibernate + Apache Commons + SLF4J. Других зависимостей у Grails нет по сути. Зато в плюс идёт поддержка SpringSource = 4 человека, которые ежедневно занимаются непосредственно Grails + люди работающие над Groovy & STS.

Play! - наоборот очень легковесный фреймворк, код в репозитории читается легко и пробегается за выходные. Там конечно не сервлеты а Netty + перезагрузка кода при изменении, но если уж нужна тупо абстракция над сервлетами - берите Spring MVC и не парьте мозг.

Есть еще vaadin.

Хоть я и подбираю общее решение, но сейчас я буду использовать его во встроенном Jetty в Java SE приложении, которое вообще работает на десктопе. В нем уже дофигища логики, кешей, разных пулов потоков, встроенная СУБД H2 и встроенный Jetty с веб-интерфейсом на базе XML/XSLT, тоесть в классическом понимании у меня отдается по HTTP запросу голый XML из JAXP и нет даже самых базовых обьектов веб-программирования мира Java, даже таких как сервлеты. Потому весь JVM со всем добром занимает 40 МБ в ОЗУ на Server VM

Хм, я криво мерял. Там для тестирования оказалось 2 инстанса внутри одной VM, -client убирает 5 МБ и планируется выпиливание Spring Context с заменой на Guice. Ну вы поняли сколько это будет потом кушать, думаю метров 20-25. Потому важно сохранить такой размер, все-таки десктопный демон

>Play! и Grails - жир, погоняемый толстотой и нагромождением фреймворков

grails в последней версии уже сравним с jsp по скорости, а по простоте использования даст фору большинству других фреймворков:
http://www.jtict.com/blog/rails-wicket-grails-play-lift-jsp/

К несчастью это технологически невозможно в силу принципов его построения

что технологически невозвожно?

Чтобы гигантское нагромождение слоев поверх которого динамический Groovy работал на уровне с голым сервлетом, который получается из jsp

а по моей ссылке вы принципиально не ходили?

Вы как будто сами не ходили. Там числа феерические. Особенно супернагрузка 20 юзеров на JRuby с ответом в 2,5 с. Доооо, сто пудофф

ну так там большие страницы рендерятся, а ruby - известный тормоз.
т.е. вас только результаты ruby смущают что ли или как?

Вас не смутит если код на С заработает медленнее кода на Ruby? Так же и Grails и JSP, толстота разная, потому фейк

>Вас не смутит если код на С заработает медленнее кода на Ruby?

ну так вы пример нормального кода приведите, а потом говорить будем

Так же и Grails и JSP, толстота разная, потому фейк

все сорцы открыты - берите да тестируйте

> grails в последней версии уже сравним с jsp по скорости

Штоааа?!?

Норкоман, штоле?

>Норкоман, штоле?

ещё один неосилятор, неспособный сходить по ссылке?

Ссылка как бы лжет, это очевидно. Проверять самим нужно время, я бы это сделал если бы числа не были столь вызывающе неправильными.

почему очевидно-то?

Потому что Grails безнадежный тормозище, потом как написан на Groovy, который безнадеждый тормозище, который является динамическим ЯП, которые все безнадежные тормозищи by design. Достаточно развернуто?

нет, особенно учитывая что кода на groovy в grails меньше, чем на java даже без учёта мильона строчек spring'а и прочих библиотек (типа hibernate, скажем) в составе grails

Раз ты не понимаешь намёков размером с бревно, разжую - по ссылке jsp идёт сразу после tapestry перед grails. Т.е. jsp быстрее.

>Раз ты не понимаешь намёков размером с бревно, разжую - по ссылке jsp идёт сразу после tapestry перед grails. Т.е. jsp быстрее.

я этого не отрицал, но отставание 1.4-trunk минимально и явно уж не «безнадежные тормозищи», как пишет vertexua

повторное использование кода

По другому это называется кокпонентно-ориентированные фреймворки. К ним кроме Click относятся ещё Wicket, Tapestry и HybridJava. Насколько я знаю всё остальное никакой реальной компонентности не обеспечивает.

Насчёт маргинальности автор загнул.

попробуй [url=http://metawidget.sourceforge.net/index.php]metawidget[/url]

JSF

>JSF/PrimeFaces - 100500 либ, работает очень медленно за счет гимнастики с состоянием

Для собственных нужд хватит производительности любой имплементации JSF. Не преувеличивайте.

Я же говорил, иногда гоняется все в Java SE приложения на десктопе.