который компилит шаблон пол часа и до рельс как до луны

А как там в рельсе со скоростью и потреблением?
Мне кажется рельса чмок, чмок и отсосала.

со скоростью чего простите?

Отсоса

А подробнее, что с ним не так можно?

Есть нечто более хорошее, чем Spring MVC?

А чего в нём хорошего? Поправте, если я ошибаюсь, но когда в него углубляешься, то предлагают выбирать между Struts2, Velocity и FTL - все три жутко устарели. Попробуйте посмотреть HybridJava чисто для сравнения.

В .NET дженерики «нормальные», и из-за этого там нельзя сделать реализацию Scala

С потреблением у Плея так: небольшое приложение с подключенным Hibernate и JPA и несколькими картинками - весит в раме 750 мегабайт. Не профайлил, кто виноват, но как-то вот так.

Мы делаем несколько приложений в день. На второй день рама на тестовом сервере закончилась. Пришлось подключить своп 10 гигабайт. Скоро и он закончится.

Как с этим у Рельсов?

А Скалу там и не нужно делать. Там есть F#, который на порядок лучше.

Там неплохая идея, хранить состояние и логику на серваке и гонять гуёвые события между браузером и серваком. Проблема в том, что в качестве базы для веб-форм они взяли gwt (ну а чё, все компоненты уже есть), суть которого была максимально вынести логику с сервака на клиента. Короче в результате им пришлось подстраивать внутреннюю сруктуру vaadin'а к тому, что удалость сотворить из gwt. Как результат дикий трафик между клиентом и серваком (во всяком случае так было год или 2 назад, но судя по коду там сложно что-то поменять) и неудобная внутренняя структура. К тому же совершенно не расширяемый, как только нужен нестандартный компонент начинается ад АД.

Ну и по-мелочи всякого.

ну как бы самая идея GWT и Vaadin «я Java разработчик, я не хочу web/html/css/javascript, я просто хочу писать на Java» слегка провальная и подходит только для каких-то интранетов с тремя пользователями колеками, а кастомизация.. ну ее не будет, будут сидеть на стандартных компонентов, тех кто «смог».

hybridjava

Язык HybridJava определен через слияние HTML с подмножеством Java на уровне грамматик. Код на HybridJava содержит как Java код, так и HTML. тэги,

как вы задрали с пхп подходом, когда смешали мух с котлетами

я Java разработчик, я не хочу web/html/css/javascript, я просто хочу писать на Java

Это как раз прекрасная идея, только в реализации она достаточно сложна. Вот и возятся все с тем что есть. Вот vaadin'овцы например ниосилили, как результат совмещение парадигм десктопа и веба, подход который совмещает минусы обоих подходов.

Это как раз прекрасная идея, только в реализации она достаточно сложна.

учитывая как быстро развивается web/html/css/javascript и как сильно нужно их кастомизировать в типовых задачах, то gwt и vaadin всегда будут играть роль догоняющих, задача не решаема.

допустим вы запустили какой-то там проект на gwt/vaadin и он вроде как начал пользоваться спросом, делаете кастомный дизайн + верстку, сколько месяцев или лет вам потребуется для внедрения это в gwt/vaadin, учитывая какой батхерт по изменению пары формочек испытывают разработчики java на stackoverflow/форумах итд?

учитывая как быстро развивается web/html/css/javascript и как сильно нужно их кастомизировать в типовых задачах, то gwt и vaadin всегда будут играть роль догоняющих, задача не решаема.

Ну про это я и писал, хотя если подумать эту задачу решать ненужно. Впрочем веб тоже чаще всего не нужен, но заказчика в этом убедить сложно.

учитывая какой батхерт по изменению пары формочек испытывают разработчики java

В том то и дело что не "разработчики java" а "разработчики gwt", ибо такой гибкий инструмент как css становится злейшим врагом. А это растёт из попытки совместить идеологии, о чм я и писал, это попало в раздел "по мелочи".

Впрочем веб тоже чаще всего не нужен, но заказчика в этом убедить сложно.

то есть у вас есть адекватная замена каким-то распределеным приложениям доступным с любой точки земного шара из любого браузера или мобильного устройства?

А 7-ю версию смотрели? Они там окончательно на gwt перешли, вроде как чуть лучше стало. Не идеал конечно, но все-таки для небольших проектов очень даже.

Во-первых подобрать замену для каких-то приложений невозможно в принципе, как и написать сами приложения.

Во-вторых не существует приложений доступных из любого браузера или любого мобильного устройства.

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

Не, я на него забил, велосипедю свой.

Это как раз прекрасная идея, только в реализации она достаточно сложна.

См. RMI-over-JRMP. ;)

Проблема в том что заказчики почемуто поголовно хотят хтмл, хотя им в основном нужен десктоп.

потому-что не надо обновлять десктоп на 500 рабочих мест + все централизовано и хранится на одном сервере, поэтому заказчики хотят хтмл, да, даже в рамках интранета уже

потому-что не надо обновлять десктоп на 500 рабочих мест + все централизовано и хранится на одном сервере

Вот в этом конкретном случае людям нужно не веб приложение а возможность обновить приложение на 500 рабочих мест. Только если у них с инфраструктурой бардак, который обычно и не позволяет без проблем обновить 500 рабочих мест, то веб их не спасёт, т.е. им не веб нужен а нормальный админ.

метрика трудозатрат поддержания когерентности «мэйнфрейм»(УЕБ и гигант(хоть облако) за ней)+тонкии VS стадо «персоналок» всегда на стороне первого варианта.

а вариант хитро распределённой системы требует квалификации у админа - а басфактор все помним да.

На стороне, да, но это же не выход. Потом всё равно эникеям бегать обновлять браузер, ставить плагины для того что б принтер/сканер работали, разрешать activeX, помещать приложение в доверенную зану, разрешать флеш и прочая мутотень. Объём трудозатрат то сопоставимый, поразительно какой химерой стали веб приложения.

PS. Не нужно распределённое приложение, нужна нормальная инфрастуктура.

Мир изменился, + заказчики голосуют рублем, вам стоит перестать отрицать очевидные вещи и взяться изучать яваскрипт.

зомби с носимыми компьютерами с телефонией и есть готовая и нормальная инфраструктура.

однородность среди клиентов в интранете поддерживается административными методами «всем зомби придти на вакцинацию их устройств»

А какие конкретно претензии к JSP?

заказчики голосуют рублем

Голосуют, но это не делает веб нужнее, прибыльнее - да, нужнее - нет.

отрицать очевидные вещи и взяться изучать яваскрипт

Это я отрицаю очевидные вещи? Я достаточно работал с ним, что б его ненавидеть.

однородность среди клиентов в интранете поддерживается административными методами «всем зомби придти на вакцинацию их устройств»

Правильно, это позволяет легко обновить десктоп.

эникеям бегать обновлять браузер

единственная локальная программа на «сетевом» компьютере - браузер. И он обновляется автоматически.

0) Веб-разрабу хочется готовый движок, на котором сразу сел и делаешь непосредственно задачу. На голом Spring/JSP - это не движок ни разу, какая-то низкоуровневая хрень. Хочешь чтобы регистрация пользователей и админка к ним искаропки, всякие отсылки имейлов «вы только что зарегистрировались, перейдите по ссылке для подтверждения»? Лососни тунца. Толпа народа сидит пишет это гонево каждый раз заново.

1) Возможность писать умную логику превращает типичную JSP-страницу в подобие PHP-кода. Дальше список того, почему PHP говно.

2) дебажить эту логику адово (каша сгенерированного кода)

3) не поддерживают искаропки то, что нужно веб-разработчику (разные манипуляции с шаблонами типа автоматического наследования, ручного с параметрами, prepend/append, etc). Соответствующий механизм расширения в виде кастомных тэгов - неудобный.

5) мы говорим JSP, подразумеваем - бины. Ко всей жаве вообще - очень сложно писать thread-safe код. Например, как формально проверить, что текущая страница не ломает состояние других пользователей? Что твоя генерация PDF'ки на 22 гигабайта не заблочит у других пользователей отображение страниц или генерацию такой же PDFки? Что не будет NullPointerExceptions? Ну да, есть всякие stateless beans, и тут начинается прыжок в шаманство

apache click

Ещё раз повторюсь, я не о блогах говорю.

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

1. +

2. Дебаг не нужен

3. Кастомные теги это легко и просто

4. Где №4?

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

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

... а в это время НЕНОРМАЛЬНЫЕ сделали 20 проектов уже на готовом движке

2. Дебаг не нужен

если там обширная PHP-лапша - нужен.

а в это время НЕНОРМАЛЬНЫЕ сделали 20 проектов уже на готовом движке

Похоже мы снова говорим о разных вещах, я вообще не рассматриваю написание блогов и форумов на пхп.

если там обширная PHP-лапша

Не нужно писать PHP-лапшу, и дебаг не будет нужен.

а что ты рассматриваешь?

и кто это у тебя купит?

я тоже не рассматриваю блоги и форумы, т.к. они уже написаны

а что ты рассматриваешь?

Корпоративные порталы, документооборот, прочая автоматизация работы пользователей, системы поддержки принятия решений и т.п.

и кто это у тебя купит?

Их сначала покупают потом пишут.

Их сначала покупают потом пишут.

какой-то аутсорс? Прибыль низкая, процентов 10. Когда есть собственные продукты - прибыль может быть больше.

Когда есть собственные продукты - прибыль может быть больше.

может быть больше, а может не быть вообще или быть отрицательной))

какой-то аутсорс?

Повсеместный. Специфика рынка.

0) Веб-разрабу хочется готовый движок, на котором сразу сел и делаешь непосредственно задачу. На голом Spring/JSP - это не движок ни разу, какая-то низкоуровневая хрень. Хочешь чтобы регистрация пользователей и админка к ним искаропки, всякие отсылки имейлов «вы только что зарегистрировались, перейдите по ссылке для подтверждения»? Лососни тунца. Толпа народа сидит пишет это гонево каждый раз заново.

При чём тут язык разметки и отправка имейлов? Ты куда-то не в ту степь ушёл.

1) Возможность писать умную логику превращает типичную JSP-страницу в подобие PHP-кода. Дальше список того, почему PHP говно.

Не надо этой возможностью злоупотреблять, вот и всё. Код должен быть в контролере, в JSP пишется view в декларативном виде.

3) не поддерживают искаропки то, что нужно веб-разработчику (разные манипуляции с шаблонами типа автоматического наследования, ручного с параметрами, prepend/append, etc). Соответствующий механизм расширения в виде кастомных тэгов - неудобный.

Не очень понял. Есть include, в каком случае его не хватает?

5) мы говорим JSP, подразумеваем - бины. Ко всей жаве вообще - очень сложно писать thread-safe код. Например, как формально проверить, что текущая страница не ломает состояние других пользователей? Что твоя генерация PDF'ки на 22 гигабайта не заблочит у других пользователей отображение страниц или генерацию такой же PDFки? Что не будет NullPointerExceptions? Ну да, есть всякие stateless beans, и тут начинается прыжок в шаманство

При чём тут JSP и бины, я нифига не понял. Всё, что связывает JSP с бинами это то, что вызываются getter-ы. Как геттеры влияют на всё вышеописанное и какая альтернатива предлагается?

Stripes

Я пользуюсь компоновкой трёх фреймворков: Stripes в качестве основы, ORMLite для работы с БД, а jQuery Mobile для мобильного интерфейса. Кратко принципы работы описаны здесь: http://habrahabr.ru/post/156781/