Привет, Хабр! Помоги выбрать веб-фреймворк? Требования: модный, молодежный, популярный, качественный фреймворк для соло-технономада.
Надо ли нам каждый месяц читать очередной пост про это?
Несколько лет участия в проектах на границе энтерпрайза и системщины окончательно отбили нюх. Чтобы разобраться в вопросе, я заглянул в топ гугла и обнаружил там кучу однобоких рейтингов. Наверное, самым лучшим оказался Java Web Frameworks Index от ZeroTurnaround.
Хорош он тем, что
- создатели основательно погулили, а также притащили туда статистику StackOverflow, LinkedIn, GitHub — примерно то же самое, что сделали бы и мы;
- очевидно, что для ZeroTurnaround верное понимание расклада по фреймворкам — это основа для зарабатывания бабла.
Вот как рейтинг выглядит на момент написания статьи:
| Rank | Framework | Popularity |
|---|---|---|
| 1 | Spring MVC | 28.82 |
| 2 | JSF | 15.2 |
| 3 | Spring Boot | 13.35 |
| 4 | GWT | 7.74 |
| 5 | Grails | 6.35 |
| 6 | Struts | 5.4 |
| 7 | Dropwizard | 4.9 |
| 8 | Play framework | 3.26 |
| 9 | JHipster | 2.49 |
| 10 | JAX-RS | 2.44 |
| 11 | Vaadin | 2.15 |
| 12 | Seam | 1.94 |
| 13 | Wicket | 1.91 |
| 14 | Tapestry | 1.9 |
| 15 | Sparkjava | 0.77 |
| 16 | Vert.x | 0.76 |
| 17 | Rapidoid | 0.25 |
| 18 | Lagom | 0.24 |
| 19 | Ratpack | 0.13 |
Стойте, там Struts в первой десятке? Серьезно? Кажется, я ничего не потерял за эти несколько лет. Точнее, даже начиная с раннего средневековья.
Давайте пробежимся по списку.
Оу, Spring MVC и Spring Boot — это два разных элемента списка? Наверное, это можно понять и простить? (напишите в комментариях!). Не имеет смысла спрашивать, при чем тут Spring — он, как и Docker, всегда при чем.
Кстати, к нам на JPoint 2018 Moscow собрался Юрген Хеллер — это главный спринговец. Вот его можно дрючить вопросами типа "при чём тут спринг" по полной программе.
Но что действительно страшно, это то, что между ними (то есть по сути, на первом месте) находится JSF. Когда-то я делал на ЛОРе несколько обсуждений на тему, какой шаблонизатор для Java лучший. Годы шли, но всегда находилась половина треда с универсальным ответом: зачем тебе шаблонизатор, когда есть JSF? Вначале был просто JSP/JSTL, но потом они потихоньку сдали позиции, и остался один JSF.
Давайте глянем, что есть нового в JSF. Да, теперь мы можем больше не писать FacesContext facesContext = FacesContext.getCurrentInstance();. Можно сделать @Inject FacesContext facesContext;. Или если ты EL-камикадзе, то можно даже #facesContext. В нужных местах можно навешать @FlowMap или достать настроечку через @ManagedProperty ("#{bean.property}") private String stringProperty; Имхо, всё это совершенно очевидные рефакторинги, в соответствии с текущей модой на синтаксис. То же касается валидации в форме <f:convertDateTime type="localDate" pattern="MM/dd/yyyy"/> — ну запилили в Восьмерке Date-Time API, пришлось отреагировать, чтобы люди не писали бесконечных конвертеров самостоятельно. Список можно продолжить. Так и представляешь, как архитекторы Oracle пилили эти фичи за один вечер, батон колбасы и бутылку водки.
Интересная фича — это тэг <f:websocket>, который можно юзать вот так:
<h:body>
<f:websocket channel="jaxArticle"
onmessage="function(message){alert(message)"} />
</h:body> В целом, прогресс с 2009 года (наш эквивалент «XV века») не перестает поражать воображение.
Дальше по рейтингу — Grails и PlayFramework. Grails — это, строго говоря, вообще не Java, а JVM. C PlayFramework под Java API не встречался со времен Play 1, поэтому — можете рассказать об этом в комментариях? Пока условно будем считать PlayFramework вторым годным фреймворком из списка, просто по причине наличия чудесного Scala API (за который можно простить ему историю с ORM и прочие мелкие ляпы).
Grails. Ну, допустим. Закроем глаза, тем более что Барух обещал, что Groovy — это круто. Но у них до сих пор открыты тикеты против Java 9! Ничего личного, чуваки, но это никуда не годится. В самом Groovy тоже какая-то фигня творится с поддержкой модулей и Java 9: насколько понял, --add-opens=java.base/* с нами навечно.
Wicket, Vaadin и GWT хотелось бы выделить в отдельную группу. С Vaadin и GWT я встречался только в смысле правки багов в чужих проектах. Но с Wicket у меня давний и болезненный опыт. Не знаю, кто первый притащил Wicket в Новосибирск, но он как эпидемия прошелся по нашим Java-компаниям. Мы писали на Wicket систему для управления профсоюзами в США. Мы писали мобильную MMO-игру. И для российских государственных компаний тоже писали разное, так что если заходите вылечиться от насморка в соседнюю больницу — осторожней, возможно, там в компьютерах полный неоперабельный Wicket. Каждый раз меня не оставляло ощущение, что Wicket не нужен вообще никогда и нигде. Может быть, про это стоит написать отдельную статью или даже целую книгу?
Давайте посмотрим еще раз на стартовую картинку. (Не знаю, кто настоящий автор, я ее нагуглил вот здесь).
Wicket появился в том же году, что и термин AJAX. В свою очередь, AJAX спас веб, благодаря этому мы все с вами такие богатые и знаменитые, хе-хе. В свою очередь, Wicket появился как средство управления Аяксом и как эксперимент был очень удачным. Потом он пошел в продакшн, и это история, полная боли и фейлов. С точки зрения архитектуры, он так никогда и не стал кластерным, и в некоторых компаниях стал причиной полного отсутствия горизонтального масштабирования. С перфомансом у него очень плохо — просто гляньте, сколько он весит в памяти и как медленно отвечает на запросы. Ну или просто откройте wicket.apache.org и посчитайте, за сколько загрузится страница.
С AJAX у него тоже так и не вышло: в 2017 году нас все еще преследуют оптимизации в названиях параметров. Пожалуйста, поднимите руки все, кто с первого раза догадается о назначении следующих параметров запроса: m, mp, e, f, sc, dt, wr, ch, bh, pre, bsh, ah, sh, fh, coh, ep, dep, rt, ad, sp, tr.
Ответы на задачку находятся здесь. Спойлер: АД расшифровывается как «allow default». Это булевский флаг, который показывает, разрешать ли исполнение поведения по умолчанию для того элемента HTML, который слушает данное событие.
Да, многие из нас работают в банках, и там всё на GWT. Но, оглядываясь назад на этот долгий-долгий путь, давайте честно признаем: управлять JavaScript из Java — наиболее дурацкая и деструктивная идея, которая когда-либо приходила в голову.
Если посмотреть на репозиторий Wicket, становится очевидно, что в период с 2007 по середину 2010 он был скорее мертв, чем жив, и далее возродился силами всего одного пользователя GitHub — Martin Grigorov, который сделал туда около четырех тысяч коммитов.
Картинка хороша, но давайте обратим внимание на конкретные циферки.
git clone https://github.com/apache/wicket.git
cd ./wicket
И теперь долбанём адским однострочником:
git log --shortstat --pretty="%cE" | sed 's/\(.*\)@.*/\1/' | grep -v "^$" | awk 'BEGIN { line=""; } !/^ / { if (line=="" || !match(line, $0)) {line = $0 "," line }} /^ / { print line " # " $0; line=""}' | sort | sed -E 's/# //;s/ files? changed,//;s/([0-9]+) ([0-9]+ deletion)/\1 0 insertions\(+\), \2/;s/\(\+\)$/\(\+\), 0 deletions\(-\)/;s/insertions?\(\+\), //;s/ deletions?\(-\)//' | awk 'BEGIN {name=""; files=0; insertions=0; deletions=0;} {if ($1 != name && name != "") { print name ": " files " files changed, " insertions " insertions(+), " deletions " deletions(-), " insertions-deletions " net"; files=0; insertions=0; deletions=0; name=$1; } name=$1; files+=$2; insertions+=$3; deletions+=$4} END {print name ": " files " files changed, " insertions " insertions(+), " deletions " deletions(-), " insertions-deletions " net";}'Или можно получить еще более подробную кумулятивную статистику:
sudo gem install git_fame
git fameБолее подробная статистика займет минут 30 (на SSD, на новеньком макбуке с мобильным i7).
Statistics based on master
Active files: 5,407
Active lines: 578,441
Total commits: 15,600| name | loc | commits | files | distribution (%) |
|---|---|---|---|---|
| martin-g | 161,089 | 98 | 2,898 | 27.8 / 0.6 / 53.6 |
| Igor Vaynberg | 67,983 | 2,872 | 1,993 | 11.8 / 18.4 / 36.9 |
| Juegen Donnerstag | 66,234 | 1,867 | 2,250 | 11.5 / 12.0 / 41.6 |
| andrea del bene | 58,583 | 5 | 654 | 10.1 / 0.0 / 12.1 |
| Eelco Hillenius | 30,287 | 2,932 | 1,051 | 5.2 / 18.8 / 19.4 |
| svenmeier | 28,504 | 307 | 1,130 | 4.9 / 2.0 / 20.9 |
| Martijn Dashorst | 22,470 | 1,089 | 727 | 3.9 / 7.0 / 13.4 |
| Frank Bille Jensen | 19,854 | 235 | 1,403 | 3.4 / 1.5 / 25.9 |
| Johan Compagner | 17,637 | 1,484 | 1,503 | 3.0 / 9.5 / 27.8 |
| Jonathan Locke | 14,257 | 1,321 | 437 | 2.5 / 8.5 / 8.1 |
| Jean-Baptiste Quenot | 14,022 | 277 | 448 | 2.4 / 1.8 / 8.3 |
| Gerolf Seitz | 13,189 | 205 | 1,041 | 2.3 / 1.3 / 19.3 |
| Matej Knopp | 8,565 | 963 | 291 | 1.5 / 6.2 / 5.4 |
| Peter Ertl | 8,281 | 354 | 417 | 1.4 / 2.3 / 7.7 |
| Pedro Henrique Oliveira d... | 7,474 | 98 | 169 | 1.3 / 0.6 / 3.1 |
| Tobias Soloschenko | 6,373 | 100 | 161 | 1.1 / 0.6 / 3.0 |
| Emond Papegaaij | 4,624 | 168 | 207 | 0.8 / 1.1 / 3.8 |
| Alastair Maw | 3,257 | 422 | 172 | 0.6 / 2.7 / 3.2 |
| Carl-Eric Menzel | 2,338 | 36 | 112 | 0.4 / 0.2 / 2.1 |
| Jesse Long | 2,230 | 12 | 261 | 0.4 / 0.1 / 4.8 |
| Jeremy Ryan Thomerson | 2,146 | 51 | 84 | 0.4 / 0.3 / 1.6 |
| Andrea Del Bene | 1,999 | 46 | 450 | 0.3 / 0.3 / 8.3 |
| bitstorm | 1,972 | 14 | 116 | 0.3 / 0.1 / 2.1 |
| Michael Mosmann | 1,397 | 43 | 31 | 0.2 / 0.3 / 0.6 |
| Felipe Campos de Almeida | 1,396 | 4 | 24 | 0.2 / 0.0 / 0.4 |
| klopfdreh | 1,329 | 39 | 27 | 0.2 / 0.2 / 0.5 |
| Janne Hietamaki | 996 | 218 | 46 | 0.2 / 1.4 / 0.9 |
| Timo Heikki Rantalaiho | 883 | 42 | 105 | 0.2 / 0.3 / 1.9 |
| Maurice Marrink | 784 | 12 | 28 | 0.1 / 0.1 / 0.5 |
| Bertrand Guay-Paquet | 773 | 1 | 3 | 0.1 / 0.0 / 0.1 |
| John Sarman | 767 | 8 | 21 | 0.1 / 0.1 / 0.4 |
| Maxim Solodovnik | 716 | 26 | 38 | 0.1 / 0.2 / 0.7 |
| sourceforge-skipoles | 605 | 40 | 42 | 0.1 / 0.3 / 0.8 |
| manuelbarzi | 476 | 2 | 5 | 0.1 / 0.0 / 0.1 |
| Domas Poliakas | 432 | 9 | 9 | 0.1 / 0.1 / 0.2 |
| Alexander Morozov | 412 | 4 | 16 | 0.1 / 0.0 / 0.3 |
| Thomas Go?tz | 403 | 1 | 13 | 0.1 / 0.0 / 0.2 |
| Martin Funk | 313 | 3 | 20 | 0.1 / 0.0 / 0.4 |
| Gwyn Richard Evans | 249 | 62 | 67 | 0.0 / 0.4 / 1.2 |
| admin | 247 | 3 | 13 | 0.0 / 0.0 / 0.2 |
| kensakurai | 208 | 5 | 3 | 0.0 / 0.0 / 0.1 |
| Michael Haitz | 207 | 1 | 2 | 0.0 / 0.0 / 0.0 |
| Guillaume Smet | 204 | 3 | 7 | 0.0 / 0.0 / 0.1 |
| Cedric Gatay | 185 | 9 | 13 | 0.0 / 0.1 / 0.2 |
| Thomas Matthijs | 185 | 3 | 12 | 0.0 / 0.0 / 0.2 |
| Roman Grigoriadi | 169 | 1 | 12 | 0.0 / 0.0 / 0.2 |
| Artur Michalowski | 156 | 4 | 6 | 0.0 / 0.0 / 0.1 |
| Martin Grigorov (Netwalk) | 149 | 4 | 12 | 0.0 / 0.0 / 0.2 |
| Robert Gruendler | 127 | 6 | 8 | 0.0 / 0.0 / 0.1 |
| Matthias Metzger | 122 | 5 | 2 | 0.0 / 0.0 / 0.0 |
| Rene Dieckmann | 119 | 1 | 3 | 0.0 / 0.0 / 0.1 |
| Ate Douma | 114 | 14 | 15 | 0.0 / 0.1 / 0.3 |
| Pedro Santos | 110 | 2 | 4 | 0.0 / 0.0 / 0.1 |
| Sebastien Briquet | 110 | 3 | 3 | 0.0 / 0.0 / 0.1 |
| Manuel Barzi | 105 | 5 | 6 | 0.0 / 0.0 / 0.1 |
| jac-czerwinski | 94 | 4 | 4 | 0.0 / 0.0 / 0.1 |
| Sven | 82 | 1 | 8 | 0.0 / 0.0 / 0.1 |
| ozeray | 79 | 1 | 11 | 0.0 / 0.0 / 0.2 |
| Thomas Heigl | 75 | 1 | 4 | 0.0 / 0.0 / 0.1 |
| Sebastien | 71 | 2 | 4 | 0.0 / 0.0 / 0.1 |
| Fridolin Jackstadt | 42 | 2 | 6 | 0.0 / 0.0 / 0.1 |
| meno | 37 | 3 | 8 | 0.0 / 0.0 / 0.1 |
| Thibault Kruse | 33 | 2 | 2 | 0.0 / 0.0 / 0.0 |
| Vit Rozkovec | 24 | 1 | 1 | 0.0 / 0.0 / 0.0 |
| Tim Fleming | 16 | 2 | 5 | 0.0 / 0.0 / 0.1 |
| Luke Niesink | 13 | 2 | 4 | 0.0 / 0.0 / 0.1 |
| Jan Blok | 10 | 8 | 1 | 0.0 / 0.1 / 0.0 |
| Nils Schmidt | 9 | 1 | 1 | 0.0 / 0.0 / 0.0 |
| Nick Pratt | 9 | 1 | 2 | 0.0 / 0.0 / 0.0 |
| slowery | 8 | 1 | 2 | 0.0 / 0.0 / 0.0 |
| astrapi69 | 4 | 5 | 2 | 0.0 / 0.0 / 0.0 |
| Jezza | 3 | 1 | 1 | 0.0 / 0.0 / 0.0 |
| tatjana19 | 3 | 1 | 1 | 0.0 / 0.0 / 0.0 |
| robert mcguinness | 3 | 1 | 1 | 0.0 / 0.0 / 0.0 |
| Peter Dave Hello | 3 | 1 | 1 | 0.0 / 0.0 / 0.0 |
| barney2k7 | 2 | 1 | 2 | 0.0 / 0.0 / 0.0 |
| bsaad | 1 | 1 | 1 | 0.0 / 0.0 / 0.0 |
| Sander Evers | 1 | 1 | 1 | 0.0 / 0.0 / 0.0 |
| Yoann Rodiere | 1 | 1 | 1 | 0.0 / 0.0 / 0.0 |
| Jeremy Thomerson | 1 | 4 | 1 | 0.0 / 0.0 / 0.0 |
| Peter Lamby | 1 | 3 | 1 | 0.0 / 0.0 / 0.0 |
| Dan Retzlaff | 0 | 2 | 0 | 0.0 / 0.0 / 0.0 |
| Jared Renzullo | 0 | 1 | 0 | 0.0 / 0.0 / 0.0 |
| Joe Schaefer | 0 | 1 | 0 | 0.0 / 0.0 / 0.0 |
| Leonid Bogdanov | 0 | 3 | 0 | 0.0 / 0.0 / 0.0 |
| Yoshiki Higo | 0 | 1 | 0 | 0.0 / 0.0 / 0.0 |
| cvs2svn | 0 | 1 | 0 | 0.0 / 0.0 / 0.0 |
В любом случае, мы увидим, что Wicket, по сути, разрабатывается не более чем десятью людьми. Если кто-то из этих десяти человек навернется (особенно Мартин), то вашему свободному времени настанет неминуемый капец — придется вечерами и ночами сидеть и осознавать баги в рендеринге страницы.
Думаю, пора заканчивать избиение младенцев и сделать какой-то вывод.
Совсем недавно было такое время, когда мы возмущались «программистами на фреймворках». «Как же так, — говорили мы на собеседовании, — ты умеешь использовать Spring, но понятия не имеешь, как работает изнутри HashMap! Что за дичь!» В еще больший ужас мы приходили, когда человек начинал рассказывать о десятках различных фреймворков, ни один из которых он не знал даже приблизительно, но все успешно применял на практике. Совсем ужасно, когда человек сам написал пять веб-фреймворков и даже в них не разбирался!
Ну что ж, если долго жечь поляну, то в конце концов травы на ней не останется. В результате своих возмущений мы получили ситуацию, когда JavaScript-проекты растут как грибы после дождика, а вот создание новых фреймворков для Java оказалось не такой уж популярной задачей. Теперь вы легко найдете того самого Senior Framework Coder (если этот фреймворк — Spring Boot, JSF и Play), который назубок расскажет про устройство табличных компонентов и внутреннюю кухню хэшмапы, но вряд ли сможет написать пять своих фреймворков и десять вариантов хэшмапы. И ни одного такого, кто сможет написать нечто лучшее, чем Spring Boot.
Возможно, вот прямо сейчас стоит остановиться и начать раздувать большущий такой фреймворк-хайп. Что думаете?
И возвращаясь к стартовому вопросу. Эй, читатель! Помоги выбрать веб-фреймворк? Требования: модный, молодежный, популярный, качественный фреймворк, и чтобы им кто-то действительно пользовался в проде, а не как Vert.x.
UPD: если кто-то из новосибирцев пишет на Wicket и не согласен с написанным выше, предлагаю встретиться на JBreak и перетереть за всю хурму. Как раз будет несколько месяцев, чтобы подготовиться к защите любимого фреймворка — готовьтесь тщательней :-)
Комментарии (147)
fzn7
19.12.2017 13:37+1Автор, присаживайся поудобнее, завари кофе и слушай сермяжную правду, будет грустно. Чистые java разработчики еще в ~2015 были освобождены от написания фронтэнда и в настоящее время, как правило, заняты написанием api(Rest/oData) для него.
olegchir Автор
19.12.2017 13:47ну так теперь ведь новые челленжи. Например, пишем мы сайтик с фронтом на реакте. Значит нужно внутрь maven-проекта запихать ноду, вебпак, собрать это всё. А эндпоинты, отдающие статику можно сделать джавовыми, и тогда можно будет управлять модульностью страниц джавовым образом — например, тот же JS управлять через Maven. А если это не просто приложуха, а десктопная софтина с гуем на Electron? Как раз огромный простор для построения велосипедов для интеропа с JS, JS-фреймворками (пробрасывание модели из NoSQL в React), WebComponents, WebAssembly, и так далее. А с веб-ассемблером можно будет писать и фронт прямо на Java! Смелый новый мир :)
AstarothAst
19.12.2017 15:13+1Например, пишем мы сайтик с фронтом на реакте. Значит нужно внутрь maven-проекта запихать ноду, вебпак, собрать это всё
А что мешает собрать «вот это все» где-то отдельно, после чего уже полученный итог положить туда, где у вас в проекте статика хранится?olegchir Автор
19.12.2017 15:14Первая заповедь ФП: не сломается то, чего нет. Зачем вручную менеджить все эти заморочки, экспозить их наружу пользователю (пользователю фреймворка), если можно всё это скрыть и автоматизировать?
Вот есть у меня сущность — мост между фронтом и сервером. Мне как пользователю (пользователю фреймворка) только один гемор, менеджить отдельно реактовую модель, DTOшки на стороне джавы, и проброс по какому-то протоколу между ними. Это три сущности, каждая из которых ломабельна. Если это будет один монолитный фасад, будет проще всё, начиная с интеграционного тестирования. (Но при этом, конечно, не стоит опускаться до идеи что «вы пишете только на джаве, жс не должен волновать» — потому что жс волновать должен, но по-другому, осмысленно)AstarothAst
19.12.2017 15:28+1Может я чего не понимаю, но. В моем текущем проекте мы как раз пилим ангуляровский фронт (не сильно проще react) и spring-boot бэк. Фронт пилят фронтэндщики, верстальщики и прочие дизайнеры, а бэк — джависты. Одним совершенно не интересна кухня других, и ни один джавист не захочет видеть в своем проекте непонятные куски, которые туда натащат js-ники, и наоборот. Собственно договорились о высокоуровневом формате взаимодействия бэка и фронта — json сообщения по websocket, если интересно — и все, друг-другу не мешаем. Все пишется в естественной для них среде — у джавистов junit, у js-ников Karma и прочие npm, а вместе все встречается только на сборке — отдельными шагами собираем фронт и бэк, бэк прямо в свой jar получает инъекцию фронтовой статики, после чего все автоматически раскатывается на сервер, и запускается практически через java -jar. По-моему это отлично, когда фронт в разработке максимально изолирован от бэка. А вы обратно хотите :)
olegchir Автор
19.12.2017 15:34Да, понимаю. Но в других местах, еще есть такие чуваки — full stack web developer. Они пилят всё. Особенно актуально, когда команда состоит из 5 человек, каждый из которых по нескольку ролей сразу выполняет.
AstarothAst
19.12.2017 15:46И как описанное мной может им помешать? :) В один момент времени такой «и жнец и швец» может выполнять только одну роль, которую при описанном мной flow выполнять легко и приятно, а главное относительно легко и относительно приятно понимать, что же там такое понаписано и как работает. Я довольно долго варился в соку проекта, где как раз практиковалось АДСКОЕ смешение технологий с их взаимным протикновением, и мало того, что подчас было невозможно понять, как оно работает, так оно еще и не расширябельно было просто никак. Как вспомню xslt-преобразования на уровне БД — глаз дергается… Взаимное проникновение таких разных вещей, как js и java отзовется не меньшей болью на поддержке и развитии, я думаю.
m1ld
19.12.2017 15:48Пора уже избавиться от мысли, что статику нужно в war запихивать. Она должна обслуживаться апачем или нгинксом. Томкату оставьте только обработку динамики.
И не зачем пытаться впихнуть невпихуемое в java сборку, webpack для java устарел с первым релизом т.к. js world сразу же убежал вперед. Собирать отдельно единственный верный путь.
AstarothAst
19.12.2017 15:52Если уж от чего избавляться, то для начала от war, вот уж что устарело и нафиг не нужно :D А где держать статику — вопрос дискуссионный. Если нужно максимальное место для маневра, то статика инкапсулированная в jar сильно поможет — раскатка новой версии ограничивается раскаткой одного бинаря. При статике на nginx неизбежно возникают грабли вида «сервер с nginx упал, ой, не упал, а не доступен, да, мы выложили новую версию фронта, ой, простите выложили не туда, ой, простите, не новую версию, а ту, которая три версии назад...», и так далее. Но если этот момент не важен, то можно статику и отдельно раздавать, никаких проблем.
m1ld
19.12.2017 16:10Все тоже самое высказывание применимо и к деплойменту jar.
А масштабировать лучше веб-сервер отдельно от java.AstarothAst
19.12.2017 16:26Ну, я и говорю — дискуссионный вопрос. А если точнее, то решаться должен исходя из контекста, а не партийным постановлением «правильно вот ТАК».
m1ld
19.12.2017 16:40Я исхожу из своего опыта работы как с webjars в war плагинах мавна и грэдла, так и из опыта использования сборки средствами npm + webpack.
Обратно уже никогда не захочется )
Как и обратно от single page application типа react/angular не хочу к Wicket, JSF, JSP, GWT, Vaadin, Struts или прочий темплейтный java-трэш. Прочтение данного топика только напомнило о боли от использования данных вещей.
Разделение сборки backend и ui, кстати также положительно сказалось на общем времени деплоймента и тестов.AstarothAst
19.12.2017 16:54Так я ж всеми руками за! Сам топлю за разделение сборок, отделение фронта от бэка и так далее. единственное разногласие — я допускаю существование папки static внутри собранного jar, внутри которой лежит отдельно собранная статика. То есть различие в основном уже за пределами разработки, это ближе к девопсу.
dravor
20.12.2017 17:01+1Зачем сначала организовывать SOA (REST/ Websocket / etc ), а потом лепить все так, что фронт и бэк полностью зависимы друг от друга на уровне даже минорных версий? Может поискать проблему в другом направлении?
olegchir Автор
20.12.2017 17:02То есть, если у меня всё ОК с тем, что фронт и бэк зависят друг от друга — REST/Websocket/etc мне не нужны?
Так это же замечательно. Минус одна надуманная проблема :) Тащить адовые архитектурные паттерны только по причине карго-культа это как то не того
olegchir Автор
19.12.2017 16:03Как-то ты агрессивно подошел к делу) Почему бы не раздавать статику джавой? Джавовские веб-сервера не уступают по перфомансу nginx, но при этом можно оставаться внутри своей родной экосистемы. И не обязательно это должна быть Вебсфера, можно отлично раздать статику чем угодно другим, и даже написать своё (поверх готового типа jetty/netty/...). А в качестве бонуса мы получаем отсутствие необходимости вручную что-то настраивать — у нас же век девопса, совершенно всю информацию можно вывести из кода на Java
Опять же если говорить об nginx, то его конфиг тоже можно сгенерить, например по джавовым аннотациям. И весь nginx тащить с собой в maven. Многие так и делают. А может, попробовать JNI? (не знаю чтобы кто-то так делал, но в чем проблема?) То есть, то, что внутри статику отдает nginx никак не отменяет строгой инкапсуляции этого nginx внутри джавового фреймворка.m1ld
19.12.2017 16:16Дело не в перфомансе того или иного изделия, просто не зачем кэшировать статитку в сервлет контейнере – это не его основная функция.
Веб-сервер для этого больше подходит и обладает достаточной гибкостью в настройке. И да – настройки также легко переносятся.
Вебсфера кстати раньше шла со своим apache http и статику скорей всего через него пускала.
Написать своё – если есть нцать лет, то тогда это выход конечно.olegchir Автор
19.12.2017 16:43Настройки, повторюсь, можно вывести из Java-кода все. Написать вывод настроек из Java-кода — это считаные минуты (либо дни, если хочется качественно). Любой школьник с этим справится, ни о каких нцать лет речи не идет :-)
Низкоуровневые движки уже для всего есть. Сейчас самому измерять лень, поэтому легкий гуглинг нашел как создатель фреймворка Xitrum измерял Netty vs Nginx и получил одинаковую производительность, т.е. производительность была ограничена скорее железом. Прикрутить кэширование опять же можно любое! (Первый результат запроса в гугле по кейвордам "netty file cache")
Ну и да, написание фреймворка занимает год(ы). И что, ничего теперь не писать? Может, вообще с Java предложите сбежать и писать сразу на nodejs? )))
m1ld
19.12.2017 17:08Угу, а потом будем слушать Шипелёва какой сборщик мусора выбрать для нашей странной кучи с постоянно хранящимися в ней файлами )
olegchir Автор
19.12.2017 17:23Стало интересно! Я запилю тест чуть позже, отдельным постом. Наверное тогда, в двух вариантах — кэшировать и в кучу, и в оффхип.
diafour
19.12.2017 18:21сайтик с фронтом на реакте
JS управлять через Maven.Если небольшой соло проект или статику зачем-то обязательно надо собирать в war/jar, можно взять webjars. Я пробовал, не всегда в репе есть нужные версии, бывает, что версии debug и prod это разные dependency, добавляешь debug, war становится похож на директорию node_modules. В случае же не маленького веб-проекта и команды, если захочется сделать больно фронтендерам, то webjars это прям годнота, но «моднее, молодёжнее» управлять api на Java через maven/gradle/etc., а react-ом через package.json/bower/grunt/etc. Всё равно это всё собирать в докеры и деплоить отдельно, а не в одном war-e.
Xandrmoro
20.12.2017 12:38-1Например, пишем мы сайтик с фронтом на реакте. Значит нужно внутрь maven-проекта запихать ноду, вебпак, собрать это всё. А эндпоинты, отдающие статику можно сделать джавовыми, и тогда можно будет управлять модульностью страниц джавовым образом — например, тот же JS управлять через Maven. А если это не просто приложуха, а десктопная софтина с гуем на Electron? Как раз огромный простор для построения велосипедов для интеропа с JS, JS-фреймворками (пробрасывание модели из NoSQL в React), WebComponents, WebAssembly, и так далее
Веб-девелоп в какой-то момент свернул куда-то не туда…
GeorgWarden
19.12.2017 13:44+1Боже упаси, чтобы у нас в Джаве было как в Джаваскрипте. Слава православному Спрингу.
olegchir Автор
19.12.2017 13:54+1Кстати, что думает о нём Егор Бугаенко?
GeorgWarden
19.12.2017 14:13Делаем чатик Джокера в коментариях на Хабре?)
olegchir Автор
19.12.2017 14:25+1А ведь это идея! yegor256, молви словечко за Спринг :)
yegor256
19.12.2017 14:32А почему Takes не попал в обзор? www.takes.org
GeorgWarden
19.12.2017 14:45"Зачем меня призвали?"
olegchir Автор
19.12.2017 21:02+1Ты не поверишь, но можно призвать даже jbaruch. Правда, тогда придется отвечать за слова про Groovy и Grails в суе, что опасно. За одним может выясниться, что у них там всё в порядке :)
jbaruch
19.12.2017 21:08+1Ну в целом всё в порядке, да. С девяткой есть вопросы, но понятно что делать. Так что Grails живее всех живых (а чего ему сделается, когда там всемогущий Spring Boot внутри), но я бы вообще на RatPack посмотрел.
Foror
19.12.2017 21:17А что он привносит нового? На гитхабе валом таких фреймворков.
olegchir Автор
20.12.2017 13:55У Егора есть своя книжка — Elegant Objects. Я сам не читал, потому что надо её заказывать на Амазоне и ждать до пенсии (месяц?). Но я вживую общался с Егором, он переполнен хорошими идеями, и книжка должна быть стоящая.
Этот фреймворк (takes) судя по всему, написан Егором и единомышленниками. Соответственно, это образец правильного ООП дизайна (насколько такой дизайн вообще можно сделать в Java) и является живым воплощением идей из книжки.
Хотя бы за это стоит этот фреймворк если не использовать, то по крайней мере — ознакомиться с базовыми идеями
yegor256
21.12.2017 10:16Книжку можно купить на территории РФ, Украины, Беларуси и ближайшего зарубежья минуя Амазон. Нужно написать емейл на shop@yegor256.com.
Foror
19.12.2017 21:27+1А как вы на спринге решаете задачи работы с DOM? Или для вас веб заканчивается на написании REST API?
GeorgWarden
21.12.2017 06:58Как правило да, дальше Реста ничего не идет. Но если приспичивает возвращать странички, то в Spring MVC есть класс ModelAndView, в экземпляр которого передается хэш-таблица и имя статического файла, который обычно какой-нибудь Thymeleaf, через который можно получать значения полей переданной таблицы конструкциями а-ля
<p>Hello, {{username}}</p>
(выше это не Thymeleaf, я не помню, какой там синтаксис)
nestor_by
19.12.2017 16:16Я бы предложил https://github.com/reactor/reactor-netty.
Модно реактивно современно и легко.Hixon10
19.12.2017 21:10+1Так это и есть, читай, spring webflux
nestor_by
19.12.2017 21:50+1и да и нет, сравните зависимости
https://mvnrepository.com/artifact/io.projectreactor.ipc/reactor-netty/0.7.2.RELEASE
https://mvnrepository.com/artifact/org.springframework/spring-webflux/5.0.2.RELEASE
Да эти либы все от одного создателя, pivotal. И вторая использует первую. Но используя reactor-netty необязательно вообще использовать spring, даже как dependency injection.
Spring можно заменить например на https://github.com/SalomonBrys/Kodein + подключить graphql и получить мога модное и современное приложение на сегодня, с минимальными зависимости.
Hixon10
19.12.2017 21:53+1Конечно, можно использовать спринг без реактивности, можно использовать спринг с реактивностью и без Netty (tomcat или undertow подойдут), можно реактивность с Netty, но без спринга. Просто, вероятней всего, весь мир сейчас перейдёт на 5-й спринг, и по дефолту все будут использовать Netty (как дефолт)
Throwable
19.12.2017 16:29Да, многие из нас работают в банках, и там всё на GWT. Но, оглядываясь назад на этот долгий-долгий путь, давайте честно признаем: управлять JavaScript из Java — наиболее дурацкая и деструктивная идея, которая когда-либо приходила в голову.
В GWT Java не управляет Javascript-ом. Java управляет DOM-ом, точно также как это делает Kotlin.js, Scala.js, TypeScript, Dart и вообще любой кросс-компилятор в JavaScript. Более того, это то, что должно было мейнстримом по причине ущербности JavaScript-а, но внезапно успело подрасти поколение JS-рунов, которым ущербность языка и динамическая типизация стало норм.
Для сложных клиентских приложений использование GWT очень даже оправдано.
GWT-проект очень нетривиально подготовить для воркбенча (вкратце пускайте вручную com.google.gwt.dev.DevMode.main(args)), но работает сносно и инкрементально компилится достаточно быстро.stardust_kid
19.12.2017 16:35А в чем ущербность js, по вашему?
Throwable
19.12.2017 17:24+1Ну, тут целой статьи мало будет, если рассматривать все косяки языка и его интергации с браузером. Для меня основным недостатком является динамическая типизация. При нескольких кодерах и растущем функционале код постепенно превращается в натуральное дерьмо, отрефакторить которое будет очень нетривиальной задачей. Как правило количество тупых тестов в JS-проектах зашкаливает, которые тестируют не функционал, а тупо правописание. Для меня основное преимущество статический типизации не в раннем обнаружении ошибок при компиляции, а в поддержке IDE:
- индикация описок, и ошибочных идентификаторов
- подстрочник: подсказки при вызове методов
- элементарный рефакторинг
- простая навигация по коду (своему и библиотечному), позволяющая отследить всю цепочку вызовов
- контрактный стиль программирования
- различные тулзы для статического анализа кода
- умные хинты и варнинги от IDE
- кодогенерация и умные темплейты
relgames
19.12.2017 22:20+1Typescript?
Foror
19.12.2017 23:28Typescript наверное хорош как замена JS, но зачем изобретать джаву заново? Не проще транспилить джаву с некоторыми оговорками, не изобретая нового ЯП с очень похожим синтаксисом?
justboris
20.12.2017 02:04Как раз-таки наоборот, это GWT изобретает Java рантайм в браузере на JS. А зачем тащить тяжелый рантайм, когда нужна всего лишь строгая типизация, которая проверяется в compile-time и выкидывается из бандла?
Foror
20.12.2017 06:28Джава нормально ложится на ES6 классы, а с учетом новых proposal, в будущем можно положить чуть-ли не строка в строку. При этом не нужно тащить в браузер JDK, как это делает GWT. Как вы и сказали «нужна всего лишь строгая типизация», я как раз этим и занимаюсь.
Выходит довольно приемлемо и Hello World занимает столько же, сколько делать его на чистом ES6. Я даже планирую отказаться от JSON и обмениваться сжатыми сериализованными POJO между фронтендом и бекендом.justboris
20.12.2017 12:27А можно поподробнее узнать, почему вы решили, что нормально ложится? Например,
this.aв JS сможет обратиться к супер-классу, а в Java только к своему собственному свойству. При транспиляции придётся что-то делать с именами, чтобы не пересекались. И таких случаев ещё много.
А ещё у Java и JS разный набор методов в нативных объектов, поэтому по-любому придётся тащить их имплементацию в рантайм, как минимум коллекции, как это делает Kotlin to JS
Foror
20.12.2017 14:30>И таких случаев ещё много.
Такие случаи редки. И для них есть воркараунды при трансляции в ES6. Я не говорил, что на выходе получите 100% как на джаве, но код будет очень похож.
>придётся тащить их имплементацию в рантайм
Используется только то, что может W3C API и ECMAScript Specification. Основная сложность это как быть с битовыми операциями на примитивных типах. Есть конечно идея инлайнить их в WebAssembly или может TypedArray.
>как это делает Kotlin to JS
Собственно, как это делает GWT, такой подход устарел, да и изначально это было глупое решение. Из-за него джава сильно отстала на фронтенде.justboris
20.12.2017 14:36Возьмем такой фрагмент Java-кода:
List<String> items = new ArrayList<>(); items.add("A"); items.add("B"); items.add("C"); items.stream() .filter(s->s.contains("B")) .forEach(System.out::println);
В какой JS это превратится? Особенно интересно что станет со
stream().Foror
20.12.2017 15:03Это ни во что не превратится, ваш код должен быть таким:
Array<String> items = new Arrays<>("A", "B", "C"); // предположим у нас Java 10 и уже можно _ items.filter((String s, _, _) -> S.includes(s, "B")). .forEach((String s, _, _) -> console.log(s));
Выглядит это не совсем круто, но мне пока не до красоты. Хотя в этом случае добавить красоты можно переопределив стандартные методы Array из ECMAScript спецификации. Т.е. в джава коде нужно создать новые методы с разными функциональными интерфейсами (на один и два аргумента).
По итогу будет так:
Array<String> items = new Arrays<>("A", "B", "C"); items.filter((String s) -> S.includes(s, "B")). .forEach(console::log);
В ES6 коде будет примерно так:
let items = new Array("A", "B", "C"); items.filter((s) => s.includes("B")). .forEach((s) => console.log(s));konsoletyper
20.12.2017 15:16А чем это отличается от jSweet?
Foror
20.12.2017 15:24+1— Код сразу транспилится в ES6 классы
— Более проработанная система типов, фактически ручная подготовка классов и методов из ECMAScript Specification
— jSweet умеет только IE API, а точнее то, что там лежит в репозитории тайпскрипта. У меня на данный момент готово Chromium API, на подходе Firefox, ну и IE будет легко спарсить. И опять же, более качественная система типов, без многоэтажных дженериков и any.
— Окончательно хочу полностью распарсить W3C веб-сайт и создавать javadoc на каждый класс и метод.justboris
20.12.2017 16:12О каких API вы говорите? DOM-API — вещь стандартная и описаная в документации.
Если какие-то отдельные браузеры поддерживают дополнительные методы, лучше их не использовать в продакшене, потому что их могут внезапно задепрекейтить и выпилить.
Foror
20.12.2017 16:37+1>DOM-API — вещь стандартная и описаная в документации
1. Я работаю в IDE и мне не удобно держать отдельное окно и искать в нём документацию на метод или поле класса.
2. Ваша ссылка не всегда поспевает за W3C документацией. И тем более отстает от того, что сейчас реализовано в браузерах. Плюс я бы хотел иметь срез фич W3C в виде JAR библиотеки еще не реализованных в браузерах.
> лучше их не использовать в продакшене
Я разрабатываю не только веб-сайты, но и расширения и веб-приложения. В хроме есть набор специфичного API для этих нужд.
Foror
20.12.2017 16:31+1Ах, да, совсем забыл поддержка async/await, не знаю сделали ли это в jSweet, но последний раз когда смотрел issue всё так и висела.
justboris
20.12.2017 16:08То есть код написанный в таком стиле нельзя будет запустить в JVM на бекенде? Тогда теряется основное преимущество написания кода не на JS — возможность переиспользовать серверный код на клиенте.
Кроме того, ни Guice, ни Guava, ни другие полезные Java-библиотеки в коде использовать не выйдет.
В чем смысл такого подхода?
Foror
20.12.2017 16:49+11. Все пишется на одном ЯП со статической типизацией и качественными IDE
2. Вы сможете переиспользовать POJO, с возможностью объявлять поля типа List, Set, Map или любым другим типом для которого напишете специальный конвертер название методов из Java в ES6. Т.е. если в джаве map#put, то его нужно конвертнуть в map#set при транспилинге.
По хорошему можно развить идею конвертера и переиспользовать более сложный код, но пока этого нет в ближайших планах.
>Кроме того, ни Guice, ни Guava, ни другие полезные Java-библиотеки в коде использовать не выйдет.
Не выйдет и слава богу, я не хочу на лендинге грузить клиенту мегабайты джава библиотек. Для этого придумали GWT.
>В чем смысл такого подхода?
Разрабатывать фронтенд и бекенд полностью на джаве без пересечения джаваскриптом (или с минимальным пересечением).justboris
20.12.2017 17:311.Все пишется на одном ЯП со статической типизацией и качественными IDE
Typescript же, ну. Уже обсудили, что ни типизация, ни удобство IDE не являются эксклюзивом для Java.
2.Вы сможете переиспользовать POJO, с возможностью объявлять поля типа List, Set, Map или любым другим типом для которого напишете специальный конвертер
А как предлагается обрабатывать аннотации? О Lombok можно в принципе забыть?
Foror
20.12.2017 17:39>Typescript же, ну
Невозможно переиспользовать POJO.
Да и так или иначе мне нужно делать кучу доп. работы, тот же парсинг W3C или исходников Chromium. Лучше я сделаю это для ЯП, который имеет прошлое и будущее, чем для непонятного однодневки, который может пропасть с радаров как допилят вебассембли и в браузер полезут все возможные ЯП со своими рантаймами.
>А как предлагается обрабатывать аннотации?
Пока они игнорируются, да и зачем они на фронтенде? Как-то жили без них. Если кому-то уж очень будет нужно можно впилить в виде скрытого поля в ES6 классе.
>О Lombok можно в принципе забыть?
Пожалуйста, серьезно, не используйте Lombok. Я считаю это очень плохая идея.justboris
20.12.2017 17:46Лучше я сделаю это для ЯП, который имеет прошлое и будущее, чем для непонятного однодневки
На самом деле код будет писаться не на Java, а на каком-то усеченном диалекте, который понимается транслятором.
И однодневкой здесь является именно ваш транслятор, а не Typescript, уже несколько лет разрабатываемый такой крупной компанией, как Microsoft
Foror
20.12.2017 18:23>На самом деле код будет писаться не на Java, а на каком-то усеченном диалекте, который понимается транслятором.
Код будет писаться на джаве, поддерживаться будет весь синтаксис джавы. Просто что-то может игнорироваться и не транспилиться на фронтенд.
Да, не будет поддержки JDK, но так на фронтенде совсем другое API, нужно изучать его, как изучают Андроид, кому нужно под него делать приложения.
>И однодневкой здесь является именно ваш транслятор, а не Typescript, уже несколько лет разрабатываемый такой крупной компанией, как Microsoft
Вот не нужно тыкать крупными компаниями, Гугл вон пытался протолкнуть дарт, даже в браузер его впилил, но не полетело.
И тайпскрипт может ждать та же судьба, когда в wasm добавят GC и прочие фичи, когда сюда придут питоны, руби, джава, сишарпы, go и т.д.
justboris
21.12.2017 14:04Пока они игнорируются, да и зачем они на фронтенде?
В аннотациях хранятся правила валидации. Будет полезно, чтобы
@NotNull, например, работал и на клиенте.
P.S. для переиспользования моделей с север-сайда я бы не изголялся с компиляторами и трансляторами, а описал бы схему в XSD/JSON Schema, чтобы клиент-сайд генерировал себе классы и интерфейсы на любом удобном языке.
Foror
21.12.2017 15:10>я бы не изголялся с компиляторами и трансляторами
Вы опять теряете основной посыл проекта — сделать разработку фронтенда полностью на джаве, не на тайпскрипте, не на кофескрипте, не на *скрипте.
Переиспользование POJO это лишь один из плюсов, который он принесёт.justboris
21.12.2017 15:14А про аннотации что скажете? Как переиспользовать правила валидации?
Foror
21.12.2017 15:26На базе этого проекта делаю веб-фреймворк отвечающий как за фронтенд (что-то типа Angular, но значительно легковеснее и проще), так и за бекенд (на Undertow на данный момент).
Валидация происходит на сервер-сайде, т.е. отправляется ajax запрос проверить валидность POJO (текущей веб-формы). На клиенте валидации нет.
Но как я и говорил, когда я всё выложу в opensource и кому-то будут нужны аннотации на клиенте — это не проблема. Может даже к тому времени аннотации можно будет транспилить сразу на клиента с поддержкой во всех браузерах.
Foror
21.12.2017 15:45>Будет полезно, чтобы NotNull, например, работал и на клиенте.
Я сейчас точно не помню, но NotNull по моему у меня обрабатывается на клиенте. Я просто очень долго уже работаю над основной базой и точно не помню деталей реализиации веб-фреймворка. Более того, сейчас нет четких критериев как всё будет выглядеть в итоге.
olegchir Автор
20.12.2017 17:51А что аннотации? Они есть в JavaScript: habrahabr.ru/post/277021
Typescript даже близко по статике не стоял со статичной жабой.
Ломбок — это очень плохая идея.
justboris
20.12.2017 18:14То что декораторы в Javascript начинаются с
@не делает их аннотациями.
Они в принципе работают по-другому, больше похожи на декораторы в Питоне (отсюда и название). Декораторы вызываются при инициализации объекта и позволяют переопределить поведение метода или целого класса. Никаких
getElementsAnnotatedWithи myClass.getAnnotations() здесь нет.olegchir Автор
21.12.2017 06:14> getElementsAnnotatedWith и myClass.getAnnotations() здесь нет
так напиши сам! Делаешь декоратор, сигнатура — как у Object.defineProperty, дефайнишь проперти отдельно. Лукап по пропертям делаешь отдельно. Понимаешь на что намекаю? Точно то же самое в питоне.justboris
21.12.2017 10:58так напиши сам! Делаешь декоратор, сигнатура ...
Я понимаю, что все мы здесь программисты и сможем решить поставленную задачу. Только вот декораторы здесь вам не помогают. Метод
getAnnotationsможет с тем же успехом использовать JSDoc комментарии, имя функции или имена аргументов, чтобы достать необходимую мета-информацию. Декораторы в виде фичи языка здесь не помогают никак. reflect-metadata proposal может помочь, а декораторы в их текущем состоянии — нет.
По сути это то же самое, что в спринге, только более убогое
То, что у декораторов другая механика не делает их лучше или хуже. Они другие. С ними сложее заниматься метапрограммированием, зато легче обернуть (e.g. задекорировать) метод или класс. Как в Java заимплементировать
@Memoized,@Readonlyили@Timeчерез аннотации?
Foror
20.12.2017 18:15Проверил в хроме — не работает ) Я всё таки хочу вариант работающий в текущих браузерах. Но в целом, я и говорил, что по итогу можно код чуть-ли не строка к строке транспилить в каком-нибудь ближайшем будущем )
olegchir Автор
21.12.2017 06:09так ты код через Babel прогони. Без него в современном JS делать нечего
Maccimo
21.12.2017 09:00Например,
this.aв JS сможет обратиться к супер-классу, а в Java только к своему собственному свойству.Это как? (при условии, что поле
aне приватное)justboris
21.12.2017 10:47Java-код// A.java class A { public String property = "A"; String getParentProp() { return property; } } // B.java class B extends A { public String property = "B"; String getChildProp() { return property; } } //где-то в коде... B b = new B(); System.out.println(b.getParentProp()); // A System.out.println(b.getChildProp()); // Bmayorovp
22.12.2017 10:01В таком случае у вас ошибка с терминологией:
this.propertyв методеgetParentPropв такой аналогии является свойством субкласса, а не суперкласса.
Throwable
20.12.2017 12:40GWT абсолютно ничего не имеет общего с Java-рантаймом. Это распространенное ошибочное мнение. У него есть определенная Runtime Library Emulation, чтобы можно было работать с коллекциями, строками, стримами, лямдами, etc как в Java. Но в рантайме GWT не таскает с собой вообще никакие библиотеки. Вместо этого он анализирует весь код приложения начиная от EntryPoint, включая только те функции из всей кодовой базы, которые используются въявную (а для 100% явности была выпилена reflection). Остальной шлак жестко шринкается. Дополнительными бонусом идет минимизация и обфускация. В итоге для функционального приложения код получается меньше, чем на нативном JS, т.к. последний грузит все используемые JS-библиотеки полностью со всем функционалом. Кстати, GWT поддерживает SourceMaps при запуске в DevMode, поэтому можно дебажить вживую в Chrome или Firefox, а в SourceMaps показывается только Java-код, который GWT оставил после шринкинга, т.е. то, что реально будет в рантайме.
Насколько GWT-код может быть минимальным полностью зависит от того, что вы будете использовать. Откажитесь от стандартных GWT-виджетов и UiBinding, используйте библиотеку Elemental, и Overlay Types. Для манипуляции с DOM-ом для GWT есть аналог JQuery — GwtQuery.
justboris
20.12.2017 13:45Достаточно написать в своем приложении myList.addAll(items) и вы уже получите немалую часть java.util.* По сравнению с ванильным JS myArray.concat(items) вы получаете значительный оверхед.
Сравнивать этот оверхед с весом какого-нибудь реакта не буду, просто заметил, что от простого использования Java вместо Typescript вы уже получите рантайм-нагрузку.
olegchir Автор
20.12.2017 09:02Может быть, не дергаться и подождать честной джавы в браузере? Или подождать возможности, и запилить такую джаву самостоятельно (вот в это я бы вписался). Веб-ассемблер уже на пути в мейнстрим. Можно будет перетащить туда не «подобие openjdk», а прямо самое настоящее полноценное openjdk, и тогда код будет портируем между фронтом и беком с оговоркой только на сендбокс браузера (попытка открыть файл может закончиться фейлом).
Foror
20.12.2017 09:22Да, я этого отчасти боюсь, что на васме впилят разумный JVM рантайм. Но затем я задумываюсь над тем, сколько нужно будет кода, чтобы запилить JVM на васме. И всё опять сходится к тому, что для лендинга или обычных веб-форм на клиента придется загружать довольно объемный код для запуска хеловорда.
Впрочем, если даже запилят такой рантайм и он будет занимать скажем 50 Кб (очень сомневаюсь), то всё равно остается вопрос портирования W3C API классов и методов в виде JAR библиотеки и Javadoc. А мой фреймворк решает эту задачу. Мне по сути нужно будет выкинуть только часть отвечающую за транспилинг джавы в es6. А всё остальное будет по прежнему актуально. Хотя будет обидно, что я потратил полгода на реализацию такого транспилинга )
Foror
20.12.2017 09:39>Или подождать возможности, и запилить такую джаву самостоятельно (вот в это я бы вписался)
Сейчас на васме толком не запилить джавы, можно конечно, но получится страшный монстр с загрузкой на клиента нескольких мегабайт кода. А когда подойдет wasm 2.0 не известно, можете еще лет 5 ждать.
konsoletyper
20.12.2017 10:48Опять же, мой проект уже поддерживает WebAssembly (частично). Есть демка. И полноценное openjdk очень долго качать, даже очень сильно порезанное — всё равно несколько мегабайт. В TeaVM это решается достаточно умным dead code elimination, который умудряется для hello world оставить примерно 60кб от всего JDK. Правда, достигается это путём отказа от reflection (и запиливания своей альтернативы, которая хорошо дружит с DCE).
Затащить JDK таким обhазом можно и в JS, причём WebAssembly пока непонятно какие преимущества даёт в этом плане. Там ни GC нет (пришлось свой написать), ни человеческого интеропа с DOM, а в плане размера бинарника и скорости WebAssembly совсем пока не радует.
olegchir Автор
20.12.2017 13:42Чот ты какой-то позитивный. Всего несколько мегабайт? Прозреваю мегабайт эдак тридцать в лучшем случае :-) Но ведь их можно будет все закэшировать. А если есть кэш, то что такое тридцать мегабайт во времена высокоскоростного интернета?
konsoletyper
20.12.2017 13:57- Интернет не всегда высокоскоростной
- Из-за размера увеличивается нагрузка на устройство (больше парсить, кэш браузера отжирает больше хранилища).
Foror
20.12.2017 14:10>В TeaVM это решается достаточно умным dead code elimination, который умудряется для hello world оставить примерно 60кб от всего JDK.
А сама TeaVM входит в эти 60кб или загружает свои мегабайты отдельно?konsoletyper
20.12.2017 14:11+1Сама TeaVM никуда не входит. Это всего лишь AOT-компилятор, который порождает самодостаточный JS-файл, где всё есть и которому ничего больше не нужно загружать.
Foror
20.12.2017 14:41Значит перепутал ваш проект с другими, просто VM смутило, сколько уже этих VM портов на JavaScript было — запутаешься )
relgames
20.12.2017 11:57Вы изобрели апплеты :) Но зачем? Эта лошадь давно мертва.
olegchir Автор
20.12.2017 13:39Это в корне отличается от апплетов тем, что использует модель безопасности браузера. К апплетам была единственная претензия — дырявость (а учитывая что их используют банки — это было действительно важно и скалось на отношении к технологии в целом). Wasm будет рабоать относительно Хромиума, и все репутационные риски будет тащить на себе Хромиум вообще и Гугл в частности.
mayorovp
20.12.2017 10:14Typescript наверное хорош как замена JS, но зачем изобретать джаву заново?
Затем, что в итоге получается более выразительный язык чем джава.
DarthVictor
20.12.2017 11:36+1Typescript наверное хорош как замена JS, но зачем изобретать джаву заново?
- для нормального взаимодействия с JS библиотеками
- для нормально совместимой с JS системой типов, поддерживающей вывод типов
- для поддержки уже написанного кода
- для легкого поиска новых разработчиков и быстрого переучивания имеющихся
- для того чтобы можно было писать хотя бы так github.com/tastejs/todomvc/blob/gh-pages/examples/typescript-react/js/todoItem.tsx, а не так github.com/tastejs/todomvc/blob/gh-pages/examples/gwt/src/com/todo/client/ToDoCell.java
Видите, сколько причин? Выберете сами, какая вам больше нравится.olegchir Автор
20.12.2017 13:44Не забывай, что скоро будет webassembly, JS перестанет быть единственным нативным языком браузера, и все JS фреймворки со стороны клиента можно будет просто переписать на Java. Тем более что тот же React это не бог весть какая сложная штука.
relgames
20.12.2017 11:57Вы так говорите, будто знать несколько ЯП — это плохо. Это здорово помогает переосмыслить свои знания и выучить новые подходы. Скажем, функциональное программирование.
И вообще, ЯП — это мелочь, по сравнению со знаниями фреймворков. Akka Java vs Spring — это 2 разных мира, со своими подходами и принципами. ЯП уже не играет особой роли.
stardust_kid
20.12.2017 00:52Значительную часть вашего списка покрывает ESLint с плагинами. Подсказки дает Webstorm. Типы можно реализовать через Flow (про TS уже писали).
С кодогенерацией и умными темплейтами не сталкиваюсь.
kemsky
21.12.2017 03:40На текущий момент TypeScript решает все перечисленное (ну понятно, что по библиотекам легко не походишь они же на JS), придется конечно поработать со сборкой всего этого и с npm и прочим, но это в разы лучше чем то, что получается когда несколько человек правят JS даже в рамках одной страницы.
j_wayne
19.12.2017 16:52> Для сложных клиентских приложений
Для них — вполне вероятно.
А вот для публичных веб-сайтов с кастомным дизайном ИМХО GWT еще какое зло.
Foror
19.12.2017 21:21GWT очень тяжелый и подходит разве, что для изобретений что-то уровня Google Docs. Вот зачем тащить чуть ли не весь JDK на клиента? Как с ним делать лендинги, форумы, простенькие веб-приложения, веб-формы и прочий типой веб? Там на хеловорде сразу 500 Кб клиенту отгружается.
konsoletyper
19.12.2017 23:56Вот зачем тащить чуть ли не весь JDK на клиента?
Это заблуждение. GWT умеет этот JDK очень хорошо вырезать. И небольшое приложение на GWT скорее всего приведёт к генерации небольшого количества JS. И вовсе GWT не тяжёлый
konsoletyper
19.12.2017 23:59Кстати, раз уж речь зашла о GWT, то хочу напомнить, что в качестве альтернативы есть ещё и мой проект. Там и вкусненький фреймворк есть, напоминающий Angular, и проблем с подготовкой воркбенча меньше.
Foror
20.12.2017 06:37>who want to develop web front-end, but don't want to learn JavaScript
Это изначально неверный посыл. Тот кто занимается фронтендом обязан знать HTML, CSS, SVG, JavaScript и весь прочий W3C API. Но не обязан программировать его на JavaScript. В этом плане Typescript интересно придумали. Я думаю джава должна последовать примеру тайпскрипта, без загрузки на клиента мегабайтов JDK.konsoletyper
20.12.2017 10:54Я думаю джава должна последовать примеру тайпскрипта, без загрузки на клиента мегабайтов JDK
TeaVM как раз и ставит задачу: сделать Java на клиенте достаточно лёгкой, чтобы не тащить за собой мегабайты JDK (как это делает, скажем, какой-нибудь CheerpJ). Hello World на чистом DOM сейчас занимает порядка 30 кб (на System.out чуть побольше, ибо надо тащить кусок java.io). Это, конечно, не сотня байт, как в случае ES или TS, но уже и не пара мегабайт. Скажем, какой-нибудь TodoMVC занимает всего 125 кб, сравните с TS + Angular 4. Кстати, справедливости ради, GWT такой же: если отказаться от его (весьма ущербной) библиотеки виджетов и писать на чистом JSInterop, то результирующий JavaScript очень радует своими размерами.
Foror
20.12.2017 14:39> сравните с TS + Angular 4
С этим нет смысла сравнивать, пока вы не скажите какой фреймворк был использован в вашем TodoMVC.
>Кстати, справедливости ради, GWT такой же
А в чем преимущества в вашем проекте, если «GWT такой же»?konsoletyper
20.12.2017 14:57+1С этим нет смысла сравнивать, пока вы не скажите какой фреймворк был использован в вашем TodoMVC.
Самописный, идеологически напоминающий Angular. Посмотрите сайт проекта, там про всё это написано
А в чем преимущества в вашем проекте, если «GWT такой же»?
А в том, что в отличие от GWT можно писать на Java, Kotlin и Scala. А ещё есть несколько приятных фишек, отсутствующих в GWT (например, эмуляция тредов на корутинах). Ну и собственно, упомянутый фреймворк, которого для GWT нет.
olegchir Автор
20.12.2017 09:08Чувак, так это твой проект? Дай пожму тебе обе ноги. Это волшебно.
А есть у тебя какие-нибудь дополнительные документы, кроме короткой документации на глагне? Про внутреннюю архитектуру и решения.
Олсо, можно забуриться внутрь и написать по этому проекту еще один пост на Хабр? Третий :)konsoletyper
20.12.2017 11:01Чувак, так это твой проект? Дай пожму тебе обе ноги. Это волшебно.
Спасибо
А есть у тебя какие-нибудь дополнительные документы, кроме короткой документации на глагне? Про внутреннюю архитектуру и решения.
На глагне вверху есть ссылочка на раздел Docs, там много всего. Можно и больше, но для этого мне нужно понимать, какие вопросы возникают у людей.
Про внутреннюю архитектуру есть совсем немного на wiki в github. Там проще не статьи писать, а сразу послать читать Мучника + дать ссылок на несколько имеющихся статей по оптимизациям на SSA.
Олсо, можно забуриться внутрь и написать по этому проекту еще один пост на Хабр? Третий :)
Можно, но я не буду этого делать. Раздел "Я пиарюсь" мало кто читает, а правила Хабра запрещают где-либо ещё публиковать статьи. Я хотел написать статью про то, как я делал online TeaVM (который на самом деле является просто javac, скомпиленным в JS), но буду публиковать на англоязычных платформах, скорее всего.
taujavarob
22.12.2017 17:36Для сложных клиентских приложений использование GWT очень даже оправдано.
GWT — это COBOL начала 21 века для веба. (С)
sovaalexandr
19.12.2017 16:50+1Эй, читатель! Помоги выбрать веб-фреймворк
В зависимости от того что вам нужно/чего достаточно. Если PHP-style request->db->response и пользователей будет 2k-потолок то и Spring Boot хватит с головой.
Если данные либо имеют потоковую природу или request->response, но уже с болше чем 2k планируемых пользователей то Play! По его API — там сейчас новые фичи (некоторые) пилятся сначала на Java, а уже потом портируются в Scala. Для остальных есть правило: вы не можете отправить пулл с фичёй в Play только для одного из API — вам нужно будет давать поддержку вашей фичи как для Java так и дл Scala. Лично я не понимаю зачем это правило ввели — всегда отличто пользовался Java кодом из Scala и Scala кодом из Java.
Детальнее можно почитать тут. Оно то рекламный whitepaper, но там описаны как сильные так и слабые стороны и почему надо и когда не надо.
Если к спрингу прикипели, а более 2k всё равно надо — то Netty и Spring Boot Webflux поверх. Только не сервлет 3.0. Почему — всё в том же whitepaper.Londoner
20.12.2017 23:43А Play! стал надёжным? Или он всё ещё как несколько лет назад, на ровном месте вываливается загадочный ексепшн, про который уже задано пять вопросов на стековерфлоу, но решение проблемы так в течение года и не найдено?
Foror
19.12.2017 16:51+1Фреймворков нет. Есть tapestry5, но он как всегда отстаёт на 5 лет от того, что нужно разработчикам сейчас на фронтенде.
Поэтому я пилю новый фреймворк для разработки современного фронтенда на джаве. В том числе и веб-приложений с портированием на андроид. У меня в этой теме лет 10 опыта с отслеживанием трендов, так что не очередной реактивный MVC фреймворк с гитхаба.
Проблема лишь в том, что не всегда удается выделять время. Из-за чего все очень медленно развивается.
Готовы ли вы вложить собственные деньги, если скажем я все подробно распишу и запущу краудфандинг компанию на кикстартаре? Сколько бы вы вложились — $100, $1000, или вложились бы в крипте более существенные средства?
viru0
19.12.2017 19:25Использовали Dropwizard на backend и angular на фронтенд. Работало как часы. Фронтенд в maven тащить не надо. Собирай локально статику и выкладывай в какой нить cloudfront
fribu
19.12.2017 20:52+1Интересно, знаком с «svenmeier» лично, сам он говорил что Wicket по сути только в легаси проектах используется
jbaruch
19.12.2017 21:01+1Если (когда) ты захочешь написать сиквел про хорошие фреймворки, не забудь посмотреть на ratpack.
Foror
19.12.2017 21:29+1В 2010 про него можно было что-нибудь написать. Сейчас заканчивается 2017 год и веб сегодня в браузере, а не на бекенде. Таких как ratpack на гитхабе сотни, они ничего не дают современному фулстек разработчику.
relgames
19.12.2017 22:19+1Full stack development скорее мертв, чем жив. Технологии шагнули далеко вперёд. React + REST по удобству и скорости работы на порядок превосходит все эти Java web фреймворки.
Дело то в том, что frontend технологии развивают все подряд, а Java web фреймворки — только java сообщество.
Foror
19.12.2017 23:24Судя по комментариям у java сообщества толком нет понимания, что такое современный веб. Либо Spring, либо веб-фреймворк из времен когда jquery было модно…
olegchir Автор
20.12.2017 09:14Есть подозрение, что у значительной части Java-сообщества есть мечта: свалить с Java на что угодно другое.
Человек сначала ставит перед собой задачу: свалить из Java, и потом уже придумывает список аргументов.
Аргументы в таком варианте нужны не чтобы что-то аргументировать, а чтобы выглядеть социально-одобряемым способом. Хейтить Java на работе Java-программистом, или хотя бы даже в блоге Java на Хабре — это не социально-одобряемая активность. Но вот если сформулировать это как-то другими словами, уже может проканать :)
relgames
20.12.2017 12:05Именно поэтому и пишутся веб-фреймворки на Java — чтобы попробовать, ужаснуться и спокойно писать фронтенд на фронтенд-технологиях :)
Throwable
20.12.2017 13:39+1А дело в том, что Java изначально семантически очень плохо приспособлена для декларативных конструкций и DSL-ей. Фреймворки, построенные на аннотациях — это некий компромисс между декларацией и исполнением, причем очень фиговый по сравнению с тем же DSL. В бекенде еще как-то прокатывает, но во фронтенде, где приходится создавать иерархические конструкции (напр. DOM), в императивном стиле на Java это превращает код в линейную кашу. Поэтому на Java никогда не было и не будет нормальных html-темплейтеров, тем более type-safe как на скале или котлине. Хотя попытки есть: https://j2html.com/
Alexufo
20.12.2017 00:36Как меня бесят java фреймворки, в которых по дизайну нельзя открыть больше одной вкладки за раз из-за вьюстейтов. Какие же сайты ущербные с ними попадаются…
olegchir Автор
20.12.2017 09:22Согласен. Но на самом деле, даже в Wicket можно открыть несколько вкладок. Например, можно на каждый таб начинать новую сессию, но при этом сделать signle sign on для всех этих сессий. Или перехватить
AjaxNewWindowNotifyingBehaviorи сделатьsetResponsePage(getPage().getClass()). Другое дело, что создатели фреймворка подумали об этом в последнюю очередь, и при попытке применить это в хайлоаде, результат скорей всего опечалит (даже не дебажная версия страницы как нефиг делать может внезапно вырасти до нескольких мегабайтов). А еще, мало кто смотрел как работает фреймворк, и не в курсе о значительной части "возможностей, о которых подумали в последнюю очередь" — а ведь никто о них не скажет.
Terras
20.12.2017 01:211) Разработка на Java трудозатратней, чем разработка на php/python/ruby, поэтому, если и использовать Java, то получать профит от всех секьюрити библиотек, клаудов и прочего тяжеловесного треша.
Разработка тяжеловесных компонентов — сложная вещь, и если это сделано на отлично в Spring, какой смысл изобретать велосипед и использовать что-то еще? Тем более уже понятно, что не разработаешь ты что-то лучше, тупо времени не хватит.
2) Ну возьмешь ты какой-то левый Java Web-framework, ну начнешь ты нам нем что-то писать. Где по итогу ты возьмешь людей на проект? И так людей компетентных сложно найти, а если искать на какой-то непопулярный фрейм, то забей сразу.
3) Смешивать front и back в коде — это мужеложство. Если очевидно, что потребуется что-то сложнее, чем пропихнуть переменные через шаблонизатор в html, то надо разделять front и back и пихать все через Rest.
Отсюда все Java фреймворки, которые пытаются дать генерацию фронта через бек — это убожество, которое дает результат уровня 2010 года.
4) Я понимаю, что у многих мужиков появляются желания сменить своего партнера и попробовать что-то новое, неизведанное, запретное, но зачем такой подход тащить в разработку? К чему такое яростное желание уйти от Spring?
Он решает задачи и делает это хорошо. Он идеально подходит для современного веба, если его завязывать исключительно на бек. Он стабилен и надежен. Вон те же .net-разработчики сидят на одной платформе и не парятся, даже везде кричат, что .net — это легкий выбор стека, а java — это пьяная драка в коммуналке.olegchir Автор
20.12.2017 09:28я буду искать не senior framework coder, а senior software engineer. То есть человека, который программирует на идеях, а не на конкретных реализациях. Тогда конкретную реализацию можно будет выбирать в зависимости от ситуации. А ситуации бывают разные (иначе всех программистов можно было бы автоматизировать по-Грефовски)
web_devel
20.12.2017 18:26+1Более полная версия картинки:
github.com/mraible/history-of-web-frameworks-timeline
kemsky
21.12.2017 04:44Каждый наверное спрашивал себя, почему у них на руби/пхп/шарпе все так легко? Там уже все сделали, а вы еще настраиваете проект и конфигурируете самолет? (Или поддерживаете что-то на тапестри 4.2)
Даже если взять для примера Core.Net (а можно рельсы там или еще что), то в нем уже практически все готово для веб и на блюдечке, садись пиши страницы, рест апи, сервисы, что хочешь, даже в той же самой идее, которая Rider.
olegchir Автор
21.12.2017 06:01start.spring.io
Перечисляешь модули, какие тебе надо, на выходе — работающий проект
Даже для Викета такая страница где-то там на их сайте есть
Рельсы имхо плавно умирающая технологияkemsky
21.12.2017 07:20Работающий проект — это мягко говоря не совсем так.
Чтобы ощутить разницу, можно попробовать накидать в этом конструкторе работающий рест сервис с поддержкой JWT токенов или например добавить SSO Keycloak через SAML протокол в проект с серверным рендерингом. Если не помогло — заменить контейнер со спринга на джус, шучу, но в коре так можно, он не завязан на конкретный контейнер.
Если из этого конфигуратора вырезать то, что покрывает EntityFramework, Razor, WebApi и несколько других пакетов (предельно (!) простых в установке и настройке), то выбирать будет практически нечего, а это значит что все работают со стандартными инструментами, компонентами, апи и так далее.
Да, в конце результат будет похожий, но затраты времени сильно отличаются.
Terras
21.12.2017 09:04Ruby — согласен. В нем нет ничего, чтобы держало технологии на плаву. Как фокус хипстеров сместился на node.js, популярность упала сильно. Сейчас если и вижу работу, то на проекты 2008-2010 года.
Terras
21.12.2017 09:08Тоже через это проходил. После Python с его Django, которая за считанные часы позволяет написать проект, поднять рест, настроить почтовики и прочее, Java показалась каким-то адом. А потом мне пришлось делать на Python GIS проект — получилось так себе, так как основная часть GIS библиотек: .net/java/c++. В итоге, сделали проект изначально на Java и сам удивился тому, как с java было все проще.
А вообще надеюсь в net.core, ибо на .net писать веб-сервисы приятней, чем на Java, но из-за отставания эко-системы и лока на Windows — сфера разработки крайне ограничена.
AstarothAst
Spring Boot :) Простите.
Miraage
Я абсолютный 0 в Java. Начинал с PHP, последние годы делаю исключительно SPA на React/Angular.
Так вот. Без знаний Java/spring собрал весьма работающий pet-project REST API с помощью Boot. Всего-то погуглил статьи/доки за несколько вечеров. Итого: security, actuator (вырубил там всё, кроме endpoints/health), data rest. Работает, как часики.
Чего не хватает: той «легкости» работы с зависимостями, которая есть в npm/composer. Конечно, maven/gradle + idea делают своё дело, но порой слишком много времени тратил на поиск нужных «пакетов».
Kwisatz
Я вот писал и на яве и на php но спринг мне показался каким то монстром неповоротливым. А туторы совсем плохи: везде происходит магия которую никто не собирается объяснять (а вот тут ткнем @аннотацию и все будет волшебно) и читать мануал от корки до корки желания нет.
Кроме того вы уж меня простите, а что нужно от фреймворка? Я как то плохо стал понимать смысл этих монструозных махин при условии того что весь бек — rest api.
Мне понравился Spark. Маленький, простенький и все есть)
olegchir Автор
Чтобы понять, что делает аннотация, не нужно читать мануал.
Нужно взять IDE и посмотреть использование аннотации по коду Спринга.
Зачастую через пару минут становится понятно, что происходит.
Мануалы искать бессмысленно хотя бы потому, что их тупо нет. То что дается в доках по Spring и Hibernate — это некий высокоуровневый Overview с перечислением корневых компонентов. К сожалению.
У Java в этом огромное преимущество перед JS, например. В джаве с помощью IDE можно найти что угодно, прицельно, быстро. В JS нужно делать все то же самое, но приходится целиком читать код библиотек.
Kwisatz
Действительно, однако по спрингу можно бегать кругами часами.
Ну и раз уж вы решились ответить: вся эта махина, она зачем?) Какая килер фича вынуждает тащить этого монстра даже в простейшие api?
Очень жаль, ибо я лично хочу знать как это работает до мельчайший подробностей. Потому как тот ужас с быстродействием который получается у людей меня не устраивает.
AstarothAst
Жека Борисов и его доклад «Спринг-потрошитель» в двух частях доступен на ютубе черт знает сколько уже. Рекомендую!
Kwisatz
Спасибо, изучу.
Всего несколько лет назад гугл выдавал мне чудное количество релевантных ссылок на английском со всем чего я желал по яве. А нынче мало того что поисковики научились подсовывать русские статейки на английский запрос, дак еще и 100500 howto для нубов превращают поиск чего либо в некий адЪ