http://www.stripesframework.org/display/stripes/Home

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

Spring

от веб-фреймвока целиком не_нужно средства по упрощению быдлокодинга тонн веб-страничек

Play Framework for Java

от веб-фреймвока целиком не_нужно средства по упрощению быдлокодинга тонн веб-страничек

<Любой другой веб-фреймворк>

от веб-фреймвока целиком не_нужно средства по упрощению быдлокодинга тонн веб-страничек

За день пишется и за день отлаживается простейший шаблонизатор на голом сервлете. Остальное по вкусу.

мне кажется, что Wicket - это такой монолитный кусок legacy-ужаса, пришедший к нам из глубин тёмных веков.

Нет, легаси ужос это жсф. А викет просто вещь в себе с приличным оверхедом.

Spring MVC решение проверенное временем, Play — более модное и современное. Play потребует знания Scala, даже если пользоваться Java-API. В опытных руках на play решение будет более производительное, как в плане скорости работы, так и в плане скорости разработки.

Про wicket я слышал только плохое.

более конкретные вопросы задавай

в какой мере потребуется знание Скалы? Только что по скайпу пугали каким-то «билдером на скале», но я так и смог взять в толк что это

лично я всяко за Play. НО!

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

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

(кстати, это секрет, на какой позиции ты в своей конторе? а то я мог бы использовать твое мнение как один из аргументов. Для людей не в теме, титутл «создатель Лора» не прозвучит =)

еще, ты не в курсе, насколько в Плее можно переключаться между жавной и скальной версией? Т.е. можно например начать на Жабе, и плавно перетекать на Скалу только когда надо, чтобы в отдаленной перспективе поставить цель - перетечь на скалу полностью?

Я с Play работал немного (делал курсач). Простая очень штука. Реально можно раскурить за неделю. Требует знания скала потому что шаблоны там в нем. Но я скала особо не знал и не знаю и сейчас. Там главное базовый синтаксис знать нормально. Как для прототипа сгодится вполне. Все равно потом переписывать.

P.S. Единственный существенный недостаток. Я так и не раскурил как его нормально внедрить в NetBeans. Проекты показывает, вроде все нормально, но запуск только из консоли и никаких помощей в автодополнении/обозначении ошибок. Нужно очень чисто писать, или выгребать ошибки при пробах.

в какой мере потребуется знание Скалы

Там все внутренности на скале, если например их Java API не хватит или что-то пойдет не так, то придется туда влезть и разбираться. Ну и в целом там scala из всех дыр торчит.

Я архитектор если что.

Смешивать можно, сборочная система такое нормально понимает. Но в целом сомнительная идея.

Понятно. Значит, выбираем чистую Java, Spring MVC, и мучение с ъынтерпрайзом.

А есть опыт написания чего-то командно на скале с нуля, нулевыми в смысле скалы людьми? Если да, поделись впечатлениями?

У нас Excelsior юзает скалу для инфраструктуры, они как раз так делали. Но там общий уровень кодеров очень высокий. Если человек может самостоятельно написать компилятор жавы, то вопрос о том, может ли он научиться новому синтаксису чтобы написать на нем пачку скриптов, наверное, не стоит =)

Даже так. Раз уж вы в компании все равно юзаете скалу и кложур, более детальный вопрос.

1) Считаешь ли ты, что скалу можно использовать в продакшене для написания реальных больших систем?

2) Сколько времени нужно типовому джуниору (с бэкграундом в криокамерной жаве под мобилки), чтобы с нуля въехать в синтаксис скалы, на уровне когда уже что-то можно делать?

не эксперт ни разу, но вроде как в Scala можно писать almost as Java, так что тут скорее проблемы не будет изначально, думаю больше web/network врубаться больше будут, чем в язык.

Интересно, почему никто не вспомнил про osgi?

Использовать можно, но способов прострелить себе ногу больше.

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

Понятно. Значит, выбираем чистую Java, Spring MVC, и мучение с ъынтерпрайзом.

Да нет там никакого мучения с интерпрайзом. Все довольно легко и непринужденно. Единственное - я бы в качестве шаблонизатора под spring mvc брал freemarker вместо jsp. Да и яву уже вполне можно восьмерку брать, благо её релиз будет явно быстрее, чем вы силами тебя одного + двух юниоров напишете свою убер-софтину.

Если надо - могу порыться в своих исходниках и скинуть готовый каркас проекта (maven, spring + spring mvc + freemarker + spring security)

JSP использовать абсолютно невозможно, это лютое ненужное говно, «PHP на жабе», только еще хуже PHP. Не понимаю, как в 2014 году можно такое предлагать по дефолту.

Каркаса пока не надо, мы начали на Плее. Потом если не асилим, я у тебя еще попрошу ))

По своему опыту могу сказать, что для Java нет нормальных веб-фрейворков. Текущий проект у нас на play framework. На первый взгляд он выглядит весьма привлекательным. Но если выйти за пределы хелло ворлдов, то тут же начинается сплошная головная боль. Мечтаю переписать всё на node.js, но вот времени особо нет :(

Какое отношение osgi имеет к веб-фреймворкам?

Есть нормальный Java вэб фреймворк. Называется HybridJava.

Вот тут его сравнивают с JSF: http://www.eonlinegratis.com/2014/is-jsf-really-ready-to-deliver-high-perform...

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

Да. Java EE 7 CDI и JSF2 с JPA.

Spring появился тогда, когда была Java 2.0 (об аннотациях и инверсии контроля не слышали). По одному этому Spring можно считать настоящим выжившим динозавром типа крокодила, который приспособился к меняющимся условиям (начиная с Java 5.0), но и несущий собственное видение на решение проблем из «глубины веков».

Стандартная Java отнюдь не стояла на месте, пока эволюционировал Spring, а вбирала всё лучшее, что могли предложить фреймворки, пока, наконец, не вышел шедевр — Java EE 7, затемевающий все нестандартные альтернативы своей логичностью и завершённостью концепций.

Да. Java EE 7 CDI и JAX-RS/HTML5/JS/CSS с JPA.

fixed

вот так

Выбрали Play и Java API. Параллельно будем ботанить Скалу. Первый прототип и первое реальное применение будет на Java, потом если Scala к тому времени будет на должном уровне, будем писать на ней. Если будут какие-то значимые успехи - отпишу на лоре.

а, еще как вариант Grails, слышал мнение от пары людей - вроде ок.

1) Считаешь ли ты, что скалу можно использовать в продакшене для написания реальных больших систем?

Да

2) Сколько времени нужно типовому джуниору (с бэкграундом в криокамерной жаве под мобилки), чтобы с нуля въехать в синтаксис скалы, на уровне когда уже что-то можно делать?

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

JSP используют как шаблонизатор, не размещаяя там лапши. Тоесть используешь контроллер например на спринге, а потом форвардишь на JSP. В JSP только JSTL и лютая смерть джунам хоть за один скриптлет. Да, в 2014ом

имхо JSP это legacy, в новом проекте я бы использовал scalate или что-нибудь подобное.

И какой диалект?

Мне jade нравится, но на ssp я тоже согласен.

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

Викет это «хоть что-то» по сравнению с Spring MVC каковой (если я не ошибаюсь) сводится к выбору из трёх равноустаревших технологий - Struts 2, Velocity и FTL. Попробуйте HybridJava.

«Java нет нормальных веб-фрейворков» есть - HybridJava.

Ну, Velocity если я правильно о чем речь, так вообще не технология, а подставлялка параметров внутрь файла =)

Так-то есть хотя бы http://scalate.fusesource.org/documentation/spring-mvc.html

+1 в Jade

в Node.JS простые блоки не имеют параметров (в том числе block), поэтому приходится симулировать поведение блоков с помощью миксинов. Например, я в шаблоне-наследнике хочу, чтобы у меня были все те же самые CSS, что и в родителе, но в самое начало списка добавился элемент. Это превращается в кучу бесполезного кода. Например, нужно вначале написать (или сгенерировать) файл со всеми названиями миксинов и пустым телом, и потом включать во все шаблоны. (нельзя вызывать миксин, которого еще не объявлено, поэтому нужно вначале составить список всех миксинов и дать им пустое тело).

Это как-то лечится?

Scalate - это ведь от слова Scala?

Например, я в шаблоне-наследнике хочу, чтобы у меня были все те же самые CSS, что и в родителе, но в самое начало списка добавился элемент.

prepend?

... собственно, если не Wicket, то что?

Альтернативой может быть HybridJava - http://hybridjava.blogspot.com/2014/01/hybridjava-vs-wicket.html

Да, Grails мне понравился. :-) Play тоже ничего, но он жрёт как не в себя cpu при компиляции. По-моему, тсу надо просто на чистой жабе писать под каким-нить Jetty. Прикрутить шаблонизатор с гитхаба, да и всё. Раз 3 странички будут.

GWT / Vaadin?

Play отличный, на нем сейчас ЛинкедИн сидит, http://engineering.linkedin.com/play/play-framework-linkedin, но плохая документация. еще есть Vaadin, как уже упоминали.

В опытных руках на play решение будет более производительное, как в плане скорости работы

По скорости разработки — оно очевидно и понятно. А по скорости работы чем Play будет лучше Spring'а? Мне казалось, что должно быть наоборот же.

Play более асинхронный и работает поверх своего собственного веб-сервера. А Spring - поверх контейнера сервлетов.

пока, наконец, не вышел шедевр — Java EE 7, затемевающий все нестандартные альтернативы своей логичностью и завершённостью концепций.

Правда? А что, дженерики в яве больше не фейк? Я что-то пропустил?

А что, дженерики в яве больше не фейк?

А что, дженерики должны быть шаблонами по-твоему?

На Vaadin можно забить только потому, что он написан задом наперёд.

Конечно.

Видишь ли, разработчики Java придерживаются другого (правильного) мнения относительно типовой безопасности во время компиляции и приведения типов во время выполнения.

Дженерики дали возможность безопасно и легко работать с типами данных, не используя явное приведение типов, как это было ранее с генерализованным типом Object, годным для вообще любого класса объекта в коллекции и небезопасным на явных приведениях типов (type cast) объектов коллекции к своим классам (чтобы можно было вызывать их методы). На этапе компиляции нельзя было точно сказать, какого типа объект находится в коллекции, если хранимый тип данных всегда один — Object. Дженерики исключили эту проблему на корню, предоставив настраиваемые типы коллекций и автоматическую проверку компилятором присваиваний.

Видишь ли, разработчики Java придерживаются другого (правильного) мнения относительно типовой безопасности во время компиляции и приведения типов во время выполнения.

Прелесть какая! Нормальные шаблоны не были сделаны просто из соображений обратной совместимости со старыми библиотеками. Все остальные рассуждения - это самооправдание.