Блеск и нищета джавовых веб-фреймворков

    Привет, Хабр! Помоги выбрать веб-фреймворк? Требования: модный, молодежный, популярный, качественный фреймворк для соло-технономада.


    Надо ли нам каждый месяц читать очередной пост про это?



    Несколько лет участия в проектах на границе энтерпрайза и системщины окончательно отбили нюх. Чтобы разобраться в вопросе, я заглянул в топ гугла и обнаружил там кучу однобоких рейтингов. Наверное, самым лучшим оказался 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 Gö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 Michałowski 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
    René 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 Rodière 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 и перетереть за всю хурму. Как раз будет несколько месяцев, чтобы подготовиться к защите любимого фреймворка — готовьтесь тщательней :-)

    JUG.ru Group
    1163,00
    Конференции для взрослых. Java, .NET, JS и др. 18+
    Поделиться публикацией

    Похожие публикации

    Комментарии 155

      +4
      Эй, читатель! Помоги выбрать веб-фреймворк? Требования: модный, молодежный, популярный, качественный фреймворк, и чтобы им кто-то действительно пользовался в проде

      Spring Boot :) Простите.
        +1
        Я абсолютный 0 в Java. Начинал с PHP, последние годы делаю исключительно SPA на React/Angular.

        Так вот. Без знаний Java/spring собрал весьма работающий pet-project REST API с помощью Boot. Всего-то погуглил статьи/доки за несколько вечеров. Итого: security, actuator (вырубил там всё, кроме endpoints/health), data rest. Работает, как часики.

        Чего не хватает: той «легкости» работы с зависимостями, которая есть в npm/composer. Конечно, maven/gradle + idea делают своё дело, но порой слишком много времени тратил на поиск нужных «пакетов».
          +3
          Я вот писал и на яве и на php но спринг мне показался каким то монстром неповоротливым. А туторы совсем плохи: везде происходит магия которую никто не собирается объяснять (а вот тут ткнем @аннотацию и все будет волшебно) и читать мануал от корки до корки желания нет.

          Кроме того вы уж меня простите, а что нужно от фреймворка? Я как то плохо стал понимать смысл этих монструозных махин при условии того что весь бек — rest api.

          Мне понравился Spark. Маленький, простенький и все есть)
            +2
            Чтобы понять, что делает аннотация, не нужно читать мануал.
            Нужно взять IDE и посмотреть использование аннотации по коду Спринга.
            Зачастую через пару минут становится понятно, что происходит.

            Мануалы искать бессмысленно хотя бы потому, что их тупо нет. То что дается в доках по Spring и Hibernate — это некий высокоуровневый Overview с перечислением корневых компонентов. К сожалению.

            У Java в этом огромное преимущество перед JS, например. В джаве с помощью IDE можно найти что угодно, прицельно, быстро. В JS нужно делать все то же самое, но приходится целиком читать код библиотек.
              +2
              Действительно, однако по спрингу можно бегать кругами часами.
              Ну и раз уж вы решились ответить: вся эта махина, она зачем?) Какая килер фича вынуждает тащить этого монстра даже в простейшие api?

              К сожалению.

              Очень жаль, ибо я лично хочу знать как это работает до мельчайший подробностей. Потому как тот ужас с быстродействием который получается у людей меня не устраивает.
              +1
              А туторы совсем плохи: везде происходит магия которую никто не собирается объяснять

              Жека Борисов и его доклад «Спринг-потрошитель» в двух частях доступен на ютубе черт знает сколько уже. Рекомендую!
                +2
                Спасибо, изучу.
                Всего несколько лет назад гугл выдавал мне чудное количество релевантных ссылок на английском со всем чего я желал по яве. А нынче мало того что поисковики научились подсовывать русские статейки на английский запрос, дак еще и 100500 howto для нубов превращают поиск чего либо в некий адЪ
          +9
          Автор, присаживайся поудобнее, завари кофе и слушай сермяжную правду, будет грустно. Чистые java разработчики еще в ~2015 были освобождены от написания фронтэнда и в настоящее время, как правило, заняты написанием api(Rest/oData) для него.
            +2
            ну так теперь ведь новые челленжи. Например, пишем мы сайтик с фронтом на реакте. Значит нужно внутрь maven-проекта запихать ноду, вебпак, собрать это всё. А эндпоинты, отдающие статику можно сделать джавовыми, и тогда можно будет управлять модульностью страниц джавовым образом — например, тот же JS управлять через Maven. А если это не просто приложуха, а десктопная софтина с гуем на Electron? Как раз огромный простор для построения велосипедов для интеропа с JS, JS-фреймворками (пробрасывание модели из NoSQL в React), WebComponents, WebAssembly, и так далее. А с веб-ассемблером можно будет писать и фронт прямо на Java! Смелый новый мир :)
              +1
              Вот он и пришел, закономерный итог идеи виртуальных машин.
                +4
                Например, пишем мы сайтик с фронтом на реакте. Значит нужно внутрь maven-проекта запихать ноду, вебпак, собрать это всё

                А что мешает собрать «вот это все» где-то отдельно, после чего уже полученный итог положить туда, где у вас в проекте статика хранится?
                  +1
                  Первая заповедь ФП: не сломается то, чего нет. Зачем вручную менеджить все эти заморочки, экспозить их наружу пользователю (пользователю фреймворка), если можно всё это скрыть и автоматизировать?

                  Вот есть у меня сущность — мост между фронтом и сервером. Мне как пользователю (пользователю фреймворка) только один гемор, менеджить отдельно реактовую модель, DTOшки на стороне джавы, и проброс по какому-то протоколу между ними. Это три сущности, каждая из которых ломабельна. Если это будет один монолитный фасад, будет проще всё, начиная с интеграционного тестирования. (Но при этом, конечно, не стоит опускаться до идеи что «вы пишете только на джаве, жс не должен волновать» — потому что жс волновать должен, но по-другому, осмысленно)
                    +11
                    Может я чего не понимаю, но. В моем текущем проекте мы как раз пилим ангуляровский фронт (не сильно проще react) и spring-boot бэк. Фронт пилят фронтэндщики, верстальщики и прочие дизайнеры, а бэк — джависты. Одним совершенно не интересна кухня других, и ни один джавист не захочет видеть в своем проекте непонятные куски, которые туда натащат js-ники, и наоборот. Собственно договорились о высокоуровневом формате взаимодействия бэка и фронта — json сообщения по websocket, если интересно — и все, друг-другу не мешаем. Все пишется в естественной для них среде — у джавистов junit, у js-ников Karma и прочие npm, а вместе все встречается только на сборке — отдельными шагами собираем фронт и бэк, бэк прямо в свой jar получает инъекцию фронтовой статики, после чего все автоматически раскатывается на сервер, и запускается практически через java -jar. По-моему это отлично, когда фронт в разработке максимально изолирован от бэка. А вы обратно хотите :)
                      +1
                      Да, понимаю. Но в других местах, еще есть такие чуваки — full stack web developer. Они пилят всё. Особенно актуально, когда команда состоит из 5 человек, каждый из которых по нескольку ролей сразу выполняет.
                        +3
                        И как описанное мной может им помешать? :) В один момент времени такой «и жнец и швец» может выполнять только одну роль, которую при описанном мной flow выполнять легко и приятно, а главное относительно легко и относительно приятно понимать, что же там такое понаписано и как работает. Я довольно долго варился в соку проекта, где как раз практиковалось АДСКОЕ смешение технологий с их взаимным протикновением, и мало того, что подчас было невозможно понять, как оно работает, так оно еще и не расширябельно было просто никак. Как вспомню xslt-преобразования на уровне БД — глаз дергается… Взаимное проникновение таких разных вещей, как js и java отзовется не меньшей болью на поддержке и развитии, я думаю.
                          +7

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


                          И не зачем пытаться впихнуть невпихуемое в java сборку, webpack для java устарел с первым релизом т.к. js world сразу же убежал вперед. Собирать отдельно единственный верный путь.

                            +1
                            Если уж от чего избавляться, то для начала от war, вот уж что устарело и нафиг не нужно :D А где держать статику — вопрос дискуссионный. Если нужно максимальное место для маневра, то статика инкапсулированная в jar сильно поможет — раскатка новой версии ограничивается раскаткой одного бинаря. При статике на nginx неизбежно возникают грабли вида «сервер с nginx упал, ой, не упал, а не доступен, да, мы выложили новую версию фронта, ой, простите выложили не туда, ой, простите, не новую версию, а ту, которая три версии назад...», и так далее. Но если этот момент не важен, то можно статику и отдельно раздавать, никаких проблем.
                              +2
                              Все тоже самое высказывание применимо и к деплойменту jar.
                              А масштабировать лучше веб-сервер отдельно от java.
                                0
                                Ну, я и говорю — дискуссионный вопрос. А если точнее, то решаться должен исходя из контекста, а не партийным постановлением «правильно вот ТАК».
                                  0
                                  Я исхожу из своего опыта работы как с webjars в war плагинах мавна и грэдла, так и из опыта использования сборки средствами npm + webpack.
                                  Обратно уже никогда не захочется )
                                  Как и обратно от single page application типа react/angular не хочу к Wicket, JSF, JSP, GWT, Vaadin, Struts или прочий темплейтный java-трэш. Прочтение данного топика только напомнило о боли от использования данных вещей.
                                  Разделение сборки backend и ui, кстати также положительно сказалось на общем времени деплоймента и тестов.
                                    0
                                    Так я ж всеми руками за! Сам топлю за разделение сборок, отделение фронта от бэка и так далее. единственное разногласие — я допускаю существование папки static внутри собранного jar, внутри которой лежит отдельно собранная статика. То есть различие в основном уже за пределами разработки, это ближе к девопсу.
                                +1
                                Зачем сначала организовывать SOA (REST/ Websocket / etc ), а потом лепить все так, что фронт и бэк полностью зависимы друг от друга на уровне даже минорных версий? Может поискать проблему в другом направлении?
                                  0
                                  То есть, если у меня всё ОК с тем, что фронт и бэк зависят друг от друга — REST/Websocket/etc мне не нужны?

                                  Так это же замечательно. Минус одна надуманная проблема :) Тащить адовые архитектурные паттерны только по причине карго-культа это как то не того
                                0
                                Как-то ты агрессивно подошел к делу) Почему бы не раздавать статику джавой? Джавовские веб-сервера не уступают по перфомансу nginx, но при этом можно оставаться внутри своей родной экосистемы. И не обязательно это должна быть Вебсфера, можно отлично раздать статику чем угодно другим, и даже написать своё (поверх готового типа jetty/netty/...). А в качестве бонуса мы получаем отсутствие необходимости вручную что-то настраивать — у нас же век девопса, совершенно всю информацию можно вывести из кода на Java

                                Опять же если говорить об nginx, то его конфиг тоже можно сгенерить, например по джавовым аннотациям. И весь nginx тащить с собой в maven. Многие так и делают. А может, попробовать JNI? (не знаю чтобы кто-то так делал, но в чем проблема?) То есть, то, что внутри статику отдает nginx никак не отменяет строгой инкапсуляции этого nginx внутри джавового фреймворка.
                                  0
                                  Дело не в перфомансе того или иного изделия, просто не зачем кэшировать статитку в сервлет контейнере – это не его основная функция.
                                  Веб-сервер для этого больше подходит и обладает достаточной гибкостью в настройке. И да – настройки также легко переносятся.
                                  Вебсфера кстати раньше шла со своим apache http и статику скорей всего через него пускала.
                                  Написать своё – если есть нцать лет, то тогда это выход конечно.
                                    0

                                    Настройки, повторюсь, можно вывести из Java-кода все. Написать вывод настроек из Java-кода — это считаные минуты (либо дни, если хочется качественно). Любой школьник с этим справится, ни о каких нцать лет речи не идет :-)


                                    Низкоуровневые движки уже для всего есть. Сейчас самому измерять лень, поэтому легкий гуглинг нашел как создатель фреймворка Xitrum измерял Netty vs Nginx и получил одинаковую производительность, т.е. производительность была ограничена скорее железом. Прикрутить кэширование опять же можно любое! (Первый результат запроса в гугле по кейвордам "netty file cache")


                                    Ну и да, написание фреймворка занимает год(ы). И что, ничего теперь не писать? Может, вообще с Java предложите сбежать и писать сразу на nodejs? )))

                                      +1
                                      Угу, а потом будем слушать Шипелёва какой сборщик мусора выбрать для нашей странной кучи с постоянно хранящимися в ней файлами )
                                        +1
                                        Стало интересно! Я запилю тест чуть позже, отдельным постом. Наверное тогда, в двух вариантах — кэшировать и в кучу, и в оффхип.
                        +1
                        сайтик с фронтом на реакте
                        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.

                          +1
                          Например, пишем мы сайтик с фронтом на реакте. Значит нужно внутрь maven-проекта запихать ноду, вебпак, собрать это всё. А эндпоинты, отдающие статику можно сделать джавовыми, и тогда можно будет управлять модульностью страниц джавовым образом — например, тот же JS управлять через Maven. А если это не просто приложуха, а десктопная софтина с гуем на Electron? Как раз огромный простор для построения велосипедов для интеропа с JS, JS-фреймворками (пробрасывание модели из NoSQL в React), WebComponents, WebAssembly, и так далее


                          Веб-девелоп в какой-то момент свернул куда-то не туда…
                          +2
                          >и в настоящее время, как правило, заняты написанием api(Rest/oData)
                          И что, за эту плевую работу еще и деньги получают? )
                            +2
                            Это вам не формошлепить вечерами )
                          +2
                          Боже упаси, чтобы у нас в Джаве было как в Джаваскрипте. Слава православному Спрингу.
                            +4
                            Кстати, что думает о нём Егор Бугаенко?

                              0
                              Делаем чатик Джокера в коментариях на Хабре?)
                                0
                                А ведь это идея! yegor256, молви словечко за Спринг :)
                                  0
                                  А почему Takes не попал в обзор? www.takes.org
                                    +1
                                    "Зачем меня призвали?"
                                    image

                                    По вопросу — видимо, автор olegchir рассматривал только те фреймворки, что находятся в вышеупомянутом рейтинге. Насчет Takes — что-то интересное, но лично, например, я ни разу не слышал
                                      +1
                                      Ты не поверишь, но можно призвать даже jbaruch. Правда, тогда придется отвечать за слова про Groovy и Grails в суе, что опасно. За одним может выясниться, что у них там всё в порядке :)
                                        +1

                                        Ну в целом всё в порядке, да. С девяткой есть вопросы, но понятно что делать. Так что Grails живее всех живых (а чего ему сделается, когда там всемогущий Spring Boot внутри), но я бы вообще на RatPack посмотрел.

                                      0

                                      Не попал в десятку из ZT Index :)



                                      Ясно. Он достоин отдельного обзора!

                                        +3

                                        O, даёшь Егоросрач на Хабре!

                                        +2
                                        А что он привносит нового? На гитхабе валом таких фреймворков.
                                          0

                                          У Егора есть своя книжка — Elegant Objects. Я сам не читал, потому что надо её заказывать на Амазоне и ждать до пенсии (месяц?). Но я вживую общался с Егором, он переполнен хорошими идеями, и книжка должна быть стоящая.


                                          Этот фреймворк (takes) судя по всему, написан Егором и единомышленниками. Соответственно, это образец правильного ООП дизайна (насколько такой дизайн вообще можно сделать в Java) и является живым воплощением идей из книжки.


                                          Хотя бы за это стоит этот фреймворк если не использовать, то по крайней мере — ознакомиться с базовыми идеями

                                            0

                                            Книжку можно купить на территории РФ, Украины, Беларуси и ближайшего зарубежья минуя Амазон. Нужно написать емейл на shop@yegor256.com.

                                    +2
                                    Если вкратце, то так же как и об аннотациях и «Скрипач не нужен».
                                      +3
                                      Кстати, что думает о нём Егор Бугаенко?
                                      Ничего хорошего, я уверен :D
                                      +2
                                      А как вы на спринге решаете задачи работы с DOM? Или для вас веб заканчивается на написании REST API?
                                        0
                                        Как правило да, дальше Реста ничего не идет. Но если приспичивает возвращать странички, то в Spring MVC есть класс ModelAndView, в экземпляр которого передается хэш-таблица и имя статического файла, который обычно какой-нибудь Thymeleaf, через который можно получать значения полей переданной таблицы конструкциями а-ля
                                        <p>Hello, {{username}}</p>

                                        (выше это не Thymeleaf, я не помню, какой там синтаксис)
                                      +1

                                      Я бы предложил https://github.com/reactor/reactor-netty.
                                      Модно реактивно современно и легко.

                                        +1
                                        Так это и есть, читай, spring webflux
                                          +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 и получить мога модное и современное приложение на сегодня, с минимальными зависимости.

                                            +1
                                            Конечно, можно использовать спринг без реактивности, можно использовать спринг с реактивностью и без Netty (tomcat или undertow подойдут), можно реактивность с Netty, но без спринга. Просто, вероятней всего, весь мир сейчас перейдёт на 5-й спринг, и по дефолту все будут использовать Netty (как дефолт)
                                        0
                                        Да, многие из нас работают в банках, и там всё на 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)), но работает сносно и инкрементально компилится достаточно быстро.

                                          +3

                                          А в чем ущербность js, по вашему?

                                            +2

                                            Ну, тут целой статьи мало будет, если рассматривать все косяки языка и его интергации с браузером. Для меня основным недостатком является динамическая типизация. При нескольких кодерах и растущем функционале код постепенно превращается в натуральное дерьмо, отрефакторить которое будет очень нетривиальной задачей. Как правило количество тупых тестов в JS-проектах зашкаливает, которые тестируют не функционал, а тупо правописание. Для меня основное преимущество статический типизации не в раннем обнаружении ошибок при компиляции, а в поддержке IDE:


                                            • индикация описок, и ошибочных идентификаторов
                                            • подстрочник: подсказки при вызове методов
                                            • элементарный рефакторинг
                                            • простая навигация по коду (своему и библиотечному), позволяющая отследить всю цепочку вызовов
                                            • контрактный стиль программирования
                                            • различные тулзы для статического анализа кода
                                            • умные хинты и варнинги от IDE
                                            • кодогенерация и умные темплейты
                                              +4

                                              Typescript?

                                                +1
                                                Typescript наверное хорош как замена JS, но зачем изобретать джаву заново? Не проще транспилить джаву с некоторыми оговорками, не изобретая нового ЯП с очень похожим синтаксисом?
                                                  +7

                                                  Как раз-таки наоборот, это GWT изобретает Java рантайм в браузере на JS. А зачем тащить тяжелый рантайм, когда нужна всего лишь строгая типизация, которая проверяется в compile-time и выкидывается из бандла?

                                                    0
                                                    Джава нормально ложится на ES6 классы, а с учетом новых proposal, в будущем можно положить чуть-ли не строка в строку. При этом не нужно тащить в браузер JDK, как это делает GWT. Как вы и сказали «нужна всего лишь строгая типизация», я как раз этим и занимаюсь.

                                                    Выходит довольно приемлемо и Hello World занимает столько же, сколько делать его на чистом ES6. Я даже планирую отказаться от JSON и обмениваться сжатыми сериализованными POJO между фронтендом и бекендом.
                                                      +3

                                                      А можно поподробнее узнать, почему вы решили, что нормально ложится? Например, this.a в JS сможет обратиться к супер-классу, а в Java только к своему собственному свойству. При транспиляции придётся что-то делать с именами, чтобы не пересекались. И таких случаев ещё много.


                                                      А ещё у Java и JS разный набор методов в нативных объектов, поэтому по-любому придётся тащить их имплементацию в рантайм, как минимум коллекции, как это делает Kotlin to JS

                                                        +2
                                                        >И таких случаев ещё много.
                                                        Такие случаи редки. И для них есть воркараунды при трансляции в ES6. Я не говорил, что на выходе получите 100% как на джаве, но код будет очень похож.

                                                        >придётся тащить их имплементацию в рантайм
                                                        Используется только то, что может W3C API и ECMAScript Specification. Основная сложность это как быть с битовыми операциями на примитивных типах. Есть конечно идея инлайнить их в WebAssembly или может TypedArray.

                                                        >как это делает Kotlin to JS
                                                        Собственно, как это делает GWT, такой подход устарел, да и изначально это было глупое решение. Из-за него джава сильно отстала на фронтенде.
                                                          +1

                                                          Возьмем такой фрагмент 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().

                                                            +1
                                                            Это ни во что не превратится, ваш код должен быть таким:

                                                            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));
                                                            
                                                              +1

                                                              А чем это отличается от jSweet?

                                                                +2
                                                                — Код сразу транспилится в ES6 классы
                                                                — Более проработанная система типов, фактически ручная подготовка классов и методов из ECMAScript Specification
                                                                — jSweet умеет только IE API, а точнее то, что там лежит в репозитории тайпскрипта. У меня на данный момент готово Chromium API, на подходе Firefox, ну и IE будет легко спарсить. И опять же, более качественная система типов, без многоэтажных дженериков и any.
                                                                — Окончательно хочу полностью распарсить W3C веб-сайт и создавать javadoc на каждый класс и метод.
                                                                  +1

                                                                  О каких API вы говорите? DOM-API — вещь стандартная и описаная в документации.


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

                                                                    +1
                                                                    >DOM-API — вещь стандартная и описаная в документации
                                                                    1. Я работаю в IDE и мне не удобно держать отдельное окно и искать в нём документацию на метод или поле класса.

                                                                    2. Ваша ссылка не всегда поспевает за W3C документацией. И тем более отстает от того, что сейчас реализовано в браузерах. Плюс я бы хотел иметь срез фич W3C в виде JAR библиотеки еще не реализованных в браузерах.

                                                                    > лучше их не использовать в продакшене
                                                                    Я разрабатываю не только веб-сайты, но и расширения и веб-приложения. В хроме есть набор специфичного API для этих нужд.
                                                                  +1
                                                                  Ах, да, совсем забыл поддержка async/await, не знаю сделали ли это в jSweet, но последний раз когда смотрел issue всё так и висела.
                                                                  +2

                                                                  То есть код написанный в таком стиле нельзя будет запустить в JVM на бекенде? Тогда теряется основное преимущество написания кода не на JS — возможность переиспользовать серверный код на клиенте.


                                                                  Кроме того, ни Guice, ни Guava, ни другие полезные Java-библиотеки в коде использовать не выйдет.


                                                                  В чем смысл такого подхода?

                                                                    +1
                                                                    1. Все пишется на одном ЯП со статической типизацией и качественными IDE

                                                                    2. Вы сможете переиспользовать POJO, с возможностью объявлять поля типа List, Set, Map или любым другим типом для которого напишете специальный конвертер название методов из Java в ES6. Т.е. если в джаве map#put, то его нужно конвертнуть в map#set при транспилинге.

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

                                                                    >Кроме того, ни Guice, ни Guava, ни другие полезные Java-библиотеки в коде использовать не выйдет.
                                                                    Не выйдет и слава богу, я не хочу на лендинге грузить клиенту мегабайты джава библиотек. Для этого придумали GWT.

                                                                    >В чем смысл такого подхода?
                                                                    Разрабатывать фронтенд и бекенд полностью на джаве без пересечения джаваскриптом (или с минимальным пересечением).
                                                                      +1
                                                                      1.Все пишется на одном ЯП со статической типизацией и качественными IDE

                                                                      Typescript же, ну. Уже обсудили, что ни типизация, ни удобство IDE не являются эксклюзивом для Java.


                                                                      2.Вы сможете переиспользовать POJO, с возможностью объявлять поля типа List, Set, Map или любым другим типом для которого напишете специальный конвертер

                                                                      А как предлагается обрабатывать аннотации? О Lombok можно в принципе забыть?

                                                                        0
                                                                        >Typescript же, ну
                                                                        Невозможно переиспользовать POJO.

                                                                        Да и так или иначе мне нужно делать кучу доп. работы, тот же парсинг W3C или исходников Chromium. Лучше я сделаю это для ЯП, который имеет прошлое и будущее, чем для непонятного однодневки, который может пропасть с радаров как допилят вебассембли и в браузер полезут все возможные ЯП со своими рантаймами.

                                                                        >А как предлагается обрабатывать аннотации?
                                                                        Пока они игнорируются, да и зачем они на фронтенде? Как-то жили без них. Если кому-то уж очень будет нужно можно впилить в виде скрытого поля в ES6 классе.

                                                                        >О Lombok можно в принципе забыть?
                                                                        Пожалуйста, серьезно, не используйте Lombok. Я считаю это очень плохая идея.
                                                                          +1
                                                                          Лучше я сделаю это для ЯП, который имеет прошлое и будущее, чем для непонятного однодневки

                                                                          На самом деле код будет писаться не на Java, а на каком-то усеченном диалекте, который понимается транслятором.


                                                                          И однодневкой здесь является именно ваш транслятор, а не Typescript, уже несколько лет разрабатываемый такой крупной компанией, как Microsoft

                                                                            –1
                                                                            >На самом деле код будет писаться не на Java, а на каком-то усеченном диалекте, который понимается транслятором.

                                                                            Код будет писаться на джаве, поддерживаться будет весь синтаксис джавы. Просто что-то может игнорироваться и не транспилиться на фронтенд.

                                                                            Да, не будет поддержки JDK, но так на фронтенде совсем другое API, нужно изучать его, как изучают Андроид, кому нужно под него делать приложения.

                                                                            >И однодневкой здесь является именно ваш транслятор, а не Typescript, уже несколько лет разрабатываемый такой крупной компанией, как Microsoft

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

                                                                            И тайпскрипт может ждать та же судьба, когда в wasm добавят GC и прочие фичи, когда сюда придут питоны, руби, джава, сишарпы, go и т.д.
                                                                            0
                                                                            Пока они игнорируются, да и зачем они на фронтенде?

                                                                            В аннотациях хранятся правила валидации. Будет полезно, чтобы @NotNull, например, работал и на клиенте.


                                                                            P.S. для переиспользования моделей с север-сайда я бы не изголялся с компиляторами и трансляторами, а описал бы схему в XSD/JSON Schema, чтобы клиент-сайд генерировал себе классы и интерфейсы на любом удобном языке.

                                                                              0
                                                                              >я бы не изголялся с компиляторами и трансляторами
                                                                              Вы опять теряете основной посыл проекта — сделать разработку фронтенда полностью на джаве, не на тайпскрипте, не на кофескрипте, не на *скрипте.

                                                                              Переиспользование POJO это лишь один из плюсов, который он принесёт.
                                                                                0

                                                                                А про аннотации что скажете? Как переиспользовать правила валидации?

                                                                                  –1
                                                                                  На базе этого проекта делаю веб-фреймворк отвечающий как за фронтенд (что-то типа Angular, но значительно легковеснее и проще), так и за бекенд (на Undertow на данный момент).

                                                                                  Валидация происходит на сервер-сайде, т.е. отправляется ajax запрос проверить валидность POJO (текущей веб-формы). На клиенте валидации нет.

                                                                                  Но как я и говорил, когда я всё выложу в opensource и кому-то будут нужны аннотации на клиенте — это не проблема. Может даже к тому времени аннотации можно будет транспилить сразу на клиента с поддержкой во всех браузерах.
                                                                                0
                                                                                >Будет полезно, чтобы NotNull, например, работал и на клиенте.
                                                                                Я сейчас точно не помню, но NotNull по моему у меня обрабатывается на клиенте. Я просто очень долго уже работаю над основной базой и точно не помню деталей реализиации веб-фреймворка. Более того, сейчас нет четких критериев как всё будет выглядеть в итоге.
                                                                              0
                                                                              А что аннотации? Они есть в JavaScript: habrahabr.ru/post/277021

                                                                              Typescript даже близко по статике не стоял со статичной жабой.

                                                                              Ломбок — это очень плохая идея.

                                                                                0

                                                                                То что декораторы в Javascript начинаются с @ не делает их аннотациями.


                                                                                Они в принципе работают по-другому, больше похожи на декораторы в Питоне (отсюда и название). Декораторы вызываются при инициализации объекта и позволяют переопределить поведение метода или целого класса. Никаких getElementsAnnotatedWith и myClass.getAnnotations() здесь нет.

                                                                                  0
                                                                                  > getElementsAnnotatedWith и myClass.getAnnotations() здесь нет

                                                                                  так напиши сам! Делаешь декоратор, сигнатура — как у Object.defineProperty, дефайнишь проперти отдельно. Лукап по пропертям делаешь отдельно. Понимаешь на что намекаю? Точно то же самое в питоне.

                                                                                  с классами то же самое, только получается фабрика. По сути это то же самое, что в спринге, только более убогое (меньше свободы метапрограммирования). А как ты уже на практике знаешь, в спринге через биндефинишенфактори, итп можно сделать любую супермагию, и уж точно можно сделать аннотации (лучше чем джавовые аннотации). Куда ткнуть хз, глянь «spring потрошитель», и видосы с Барухом, когда они spring-context поднимали не из xml или аннотаций, а из ini-файла
                                                                                    0
                                                                                    так напиши сам! Делаешь декоратор, сигнатура ...

                                                                                    Я понимаю, что все мы здесь программисты и сможем решить поставленную задачу. Только вот декораторы здесь вам не помогают. Метод getAnnotations может с тем же успехом использовать JSDoc комментарии, имя функции или имена аргументов, чтобы достать необходимую мета-информацию. Декораторы в виде фичи языка здесь не помогают никак. reflect-metadata proposal может помочь, а декораторы в их текущем состоянии — нет.


                                                                                    По сути это то же самое, что в спринге, только более убогое

                                                                                    То, что у декораторов другая механика не делает их лучше или хуже. Они другие. С ними сложее заниматься метапрограммированием, зато легче обернуть (e.g. задекорировать) метод или класс. Как в Java заимплементировать @Memoized, @Readonly или @Time через аннотации?

                                                                                      –1
                                                                                      > Как в Java заимплементировать @Memoized, Readonly или Time через аннотации?

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

                                                                                      Так работает Spring из коробки. Нужно гуглить BeanPostProcessor, BeanFactoryPostProcessor, BeanDefinitionRegistryPostProcessor, и другие соответствующие классы. Любой пользователь Spring это знает.

                                                                                      Хорошо рассказывает Женя Борисов на докладах на Joker/JPoint/JBreak в докладах типа «spring-потрошитель»: www.youtube.com/watch?v=BmBr5diz8WA

                                                                                      > Метод getAnnotations может с тем же успехом использовать JSDoc комментарии

                                                                                      Нельзя, потому что это ударит по перфомансу. В PHP вот это сделали, в мои времена это был такой перфоманс хит, что пользоваться было невозможно (может быть, сейчас починили?). В мои времена, создатели ORM Doctrine по этому поводу пилили пулл-риквест с нативной поддержкой аннотаций, но пыхеры отклонили.

                                                                                      А в жабе — язык достаточно статический, поэтому информация о типах используется для ускорения кода на всех этапах. Например, в жабе используется такая штука как верификатор байткода, поэтому сразу после верификации (после загрузки класса) мы можем выбросить все проверки на соответствия типов, а js будет проверять их вечно. Даже если этот js запустят под JVM на GraalVM — проверки всё равно никуда не денутся (но будут не строить граф заново, а деоптимизироваться в случае изменения типа).

                                                                                      Если мы реализуем Java поверх JS, надо понимать, что от аннотаций потребуется максимальный перфоманс. Если можно как-то заюзать для этого нативные возможности V8/Servo, обязательно нужно это сделать.
                                                                                        0
                                                                                        Если мы реализуем Java поверх JS, надо понимать, что от аннотаций потребуется максимальный перфоманс. Если можно как-то заюзать для этого нативные возможности V8/Servo, обязательно нужно это сделать.

                                                                                        Вот только максимальный перфоманс будет совсем не при эмуляции аннотаций через декораторы (а в ESNext декораторы сделаны крайне неудобно для этой задачи). Чтобы получить максимальный перфоманс — надо просто записать всю дополнительную метаинформацию в статическое поле в виде литерала объекта. Что может быть быстрее чтения константы?


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

                                                                                        То есть нужно либо самому генерировать прокси-класс (в байт-коде!), либо поручить это дело библиотеке (которая будет сама генерировать прокси класс в байт-коде). Или же использовать Proxy, устроив тем самым своему коду проседание производительности.


                                                                                        Декораторы же умеют делать это все из коробки.


                                                                                        Это как декораторы, только лучше, потому что из за тебя пишет компилятор.

                                                                                        Вот тут вообще не понял. Допустим, у меня нет библиотеки которая реализует @Memoized. Чем именно компилятор мне поможет в этой ситуации?

                                                                                  0
                                                                                  Проверил в хроме — не работает ) Я всё таки хочу вариант работающий в текущих браузерах. Но в целом, я и говорил, что по итогу можно код чуть-ли не строка к строке транспилить в каком-нибудь ближайшем будущем )
                                                                                    0
                                                                                    так ты код через Babel прогони. Без него в современном JS делать нечего
                                                                      0
                                                                      Например, this.a в JS сможет обратиться к супер-классу, а в Java только к своему собственному свойству.

                                                                      Это как? (при условии, что поле a не приватное)

                                                                        +1
                                                                        Java-код
                                                                        // 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()); // B

                                                                        JS код
                                                                        class A {
                                                                          property = "A";
                                                                        
                                                                          getParentProp() {
                                                                            return this.property;
                                                                          }
                                                                        }
                                                                        
                                                                        class B extends A {
                                                                          property = "B";
                                                                        
                                                                          getChildProp() {
                                                                            return this.property;
                                                                          }
                                                                        }
                                                                        
                                                                        const b = new B();
                                                                        console.log(b.getParentProp()); // B
                                                                        console.log(b.getChildProp());  // B
                                                                          0

                                                                          В таком случае у вас ошибка с терминологией: this.property в методе getParentProp в такой аналогии является свойством субкласса, а не суперкласса.

                                                                    +1

                                                                    GWT абсолютно ничего не имеет общего с 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.

                                                                      +2

                                                                      Достаточно написать в своем приложении myList.addAll(items) и вы уже получите немалую часть java.util.* По сравнению с ванильным JS myArray.concat(items) вы получаете значительный оверхед.


                                                                      Сравнивать этот оверхед с весом какого-нибудь реакта не буду, просто заметил, что от простого использования Java вместо Typescript вы уже получите рантайм-нагрузку.

                                                                    –1
                                                                    Может быть, не дергаться и подождать честной джавы в браузере? Или подождать возможности, и запилить такую джаву самостоятельно (вот в это я бы вписался). Веб-ассемблер уже на пути в мейнстрим. Можно будет перетащить туда не «подобие openjdk», а прямо самое настоящее полноценное openjdk, и тогда код будет портируем между фронтом и беком с оговоркой только на сендбокс браузера (попытка открыть файл может закончиться фейлом).
                                                                      +1
                                                                      Да, я этого отчасти боюсь, что на васме впилят разумный JVM рантайм. Но затем я задумываюсь над тем, сколько нужно будет кода, чтобы запилить JVM на васме. И всё опять сходится к тому, что для лендинга или обычных веб-форм на клиента придется загружать довольно объемный код для запуска хеловорда.

                                                                      Впрочем, если даже запилят такой рантайм и он будет занимать скажем 50 Кб (очень сомневаюсь), то всё равно остается вопрос портирования W3C API классов и методов в виде JAR библиотеки и Javadoc. А мой фреймворк решает эту задачу. Мне по сути нужно будет выкинуть только часть отвечающую за транспилинг джавы в es6. А всё остальное будет по прежнему актуально. Хотя будет обидно, что я потратил полгода на реализацию такого транспилинга )
                                                                        +1
                                                                        >Или подождать возможности, и запилить такую джаву самостоятельно (вот в это я бы вписался)
                                                                        Сейчас на васме толком не запилить джавы, можно конечно, но получится страшный монстр с загрузкой на клиента нескольких мегабайт кода. А когда подойдет wasm 2.0 не известно, можете еще лет 5 ждать.
                                                                          +1

                                                                          Опять же, мой проект уже поддерживает WebAssembly (частично). Есть демка. И полноценное openjdk очень долго качать, даже очень сильно порезанное — всё равно несколько мегабайт. В TeaVM это решается достаточно умным dead code elimination, который умудряется для hello world оставить примерно 60кб от всего JDK. Правда, достигается это путём отказа от reflection (и запиливания своей альтернативы, которая хорошо дружит с DCE).


                                                                          Затащить JDK таким обhазом можно и в JS, причём WebAssembly пока непонятно какие преимущества даёт в этом плане. Там ни GC нет (пришлось свой написать), ни человеческого интеропа с DOM, а в плане размера бинарника и скорости WebAssembly совсем пока не радует.

                                                                            0
                                                                            Чот ты какой-то позитивный. Всего несколько мегабайт? Прозреваю мегабайт эдак тридцать в лучшем случае :-) Но ведь их можно будет все закэшировать. А если есть кэш, то что такое тридцать мегабайт во времена высокоскоростного интернета?
                                                                              +2
                                                                              1. Интернет не всегда высокоскоростной
                                                                              2. Из-за размера увеличивается нагрузка на устройство (больше парсить, кэш браузера отжирает больше хранилища).
                                                                              0
                                                                              >В TeaVM это решается достаточно умным dead code elimination, который умудряется для hello world оставить примерно 60кб от всего JDK.
                                                                              А сама TeaVM входит в эти 60кб или загружает свои мегабайты отдельно?
                                                                                +2

                                                                                Сама TeaVM никуда не входит. Это всего лишь AOT-компилятор, который порождает самодостаточный JS-файл, где всё есть и которому ничего больше не нужно загружать.

                                                                                  +1
                                                                                  Значит перепутал ваш проект с другими, просто VM смутило, сколько уже этих VM портов на JavaScript было — запутаешься )
                                                                              +2
                                                                              Вы изобрели апплеты :) Но зачем? Эта лошадь давно мертва.
                                                                                0
                                                                                Это в корне отличается от апплетов тем, что использует модель безопасности браузера. К апплетам была единственная претензия — дырявость (а учитывая что их используют банки — это было действительно важно и скалось на отношении к технологии в целом). Wasm будет рабоать относительно Хромиума, и все репутационные риски будет тащить на себе Хромиум вообще и Гугл в частности.
                                                                              +2
                                                                              Typescript наверное хорош как замена JS, но зачем изобретать джаву заново?

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

                                                                                +3
                                                                                Typescript наверное хорош как замена JS, но зачем изобретать джаву заново?


                                                                                Видите, сколько причин? Выберете сами, какая вам больше нравится.
                                                                                  0
                                                                                  Не забывай, что скоро будет webassembly, JS перестанет быть единственным нативным языком браузера, и все JS фреймворки со стороны клиента можно будет просто переписать на Java. Тем более что тот же React это не бог весть какая сложная штука.
                                                                                    +2
                                                                                    Да что вы заладили WebAssembly-WebAssembly. Он не даст значительных преимуществ, значит, на него моментально все не перепишут. Конечно, возникнут всякие компиляторы Java, Kotlin и т.п. в wasm, но… Слишком много «но». Тут и нестабильность wasm, кроссбраузерность, скорость… Банально, сейчас весь веб держится за JS, убив апплеты, силверлайт, флэш. Вы считаете, что без весомых преимуществ все побегут переписываться на wasm? Так что может wasm и выстрелит, но в ближайшие 3-5 лет убийства ненавистного JS можно не ждать. А учитывая состояние прошлых конкурентов JS, у меня есть сильные опасения за wasm.
                                                                                    И да, ни одну из причин вы своим wasm не отменили.
                                                                                      0
                                                                                      Переписать всё на любимом языке (Java, C#) — это такое преимущество, прямо в ворота не пролезает. Конечно же все бросятся. Может быть, сайты-визитки — нет. Но корпоративные приложения, порталы, АРМы, крупные сложные площадки — короче то, за что нам платят бабки — тут же всё перетащат на джаву. Запомните этот пост!
                                                                                  0
                                                                                  Вы так говорите, будто знать несколько ЯП — это плохо. Это здорово помогает переосмыслить свои знания и выучить новые подходы. Скажем, функциональное программирование.

                                                                                  И вообще, ЯП — это мелочь, по сравнению со знаниями фреймворков. Akka Java vs Spring — это 2 разных мира, со своими подходами и принципами. ЯП уже не играет особой роли.
                                                                                  0

                                                                                  -

                                                                                  +2

                                                                                  Значительную часть вашего списка покрывает ESLint с плагинами. Хорошие подсказки дают IDE Jetbrains, например. Типы можно реализовать через Flow (про TS уже писали).
                                                                                  С кодогенерацией и умными темплейтами не сталкиваюсь.

                                                                                    0

                                                                                    На текущий момент TypeScript решает все перечисленное (ну понятно, что по библиотекам легко не походишь они же на JS), придется конечно поработать со сборкой всего этого и с npm и прочим, но это в разы лучше чем то, что получается когда несколько человек правят JS даже в рамках одной страницы.

                                                                                  +1
                                                                                  > Для сложных клиентских приложений
                                                                                  Для них — вполне вероятно.
                                                                                  А вот для публичных веб-сайтов с кастомным дизайном ИМХО GWT еще какое зло.
                                                                                    +2
                                                                                    GWT очень тяжелый и подходит разве, что для изобретений что-то уровня Google Docs. Вот зачем тащить чуть ли не весь JDK на клиента? Как с ним делать лендинги, форумы, простенькие веб-приложения, веб-формы и прочий типой веб? Там на хеловорде сразу 500 Кб клиенту отгружается.
                                                                                      0
                                                                                      Вот зачем тащить чуть ли не весь JDK на клиента?

                                                                                      Это заблуждение. GWT умеет этот JDK очень хорошо вырезать. И небольшое приложение на GWT скорее всего приведёт к генерации небольшого количества JS. И вовсе GWT не тяжёлый

                                                                                      +1

                                                                                      Кстати, раз уж речь зашла о GWT, то хочу напомнить, что в качестве альтернативы есть ещё и мой проект. Там и вкусненький фреймворк есть, напоминающий Angular, и проблем с подготовкой воркбенча меньше.

                                                                                        +2
                                                                                        >who want to develop web front-end, but don't want to learn JavaScript
                                                                                        Это изначально неверный посыл. Тот кто занимается фронтендом обязан знать HTML, CSS, SVG, JavaScript и весь прочий W3C API. Но не обязан программировать его на JavaScript. В этом плане Typescript интересно придумали. Я думаю джава должна последовать примеру тайпскрипта, без загрузки на клиента мегабайтов JDK.
                                                                                          +1
                                                                                          Я думаю джава должна последовать примеру тайпскрипта, без загрузки на клиента мегабайтов JDK

                                                                                          TeaVM как раз и ставит задачу: сделать Java на клиенте достаточно лёгкой, чтобы не тащить за собой мегабайты JDK (как это делает, скажем, какой-нибудь CheerpJ). Hello World на чистом DOM сейчас занимает порядка 30 кб (на System.out чуть побольше, ибо надо тащить кусок java.io). Это, конечно, не сотня байт, как в случае ES или TS, но уже и не пара мегабайт. Скажем, какой-нибудь TodoMVC занимает всего 125 кб, сравните с TS + Angular 4. Кстати, справедливости ради, GWT такой же: если отказаться от его (весьма ущербной) библиотеки виджетов и писать на чистом JSInterop, то результирующий JavaScript очень радует своими размерами.

                                                                                            +1
                                                                                            > сравните с TS + Angular 4
                                                                                            С этим нет смысла сравнивать, пока вы не скажите какой фреймворк был использован в вашем TodoMVC.

                                                                                            >Кстати, справедливости ради, GWT такой же
                                                                                            А в чем преимущества в вашем проекте, если «GWT такой же»?
                                                                                              +3
                                                                                              С этим нет смысла сравнивать, пока вы не скажите какой фреймворк был использован в вашем TodoMVC.

                                                                                              Самописный, идеологически напоминающий Angular. Посмотрите сайт проекта, там про всё это написано


                                                                                              А в чем преимущества в вашем проекте, если «GWT такой же»?

                                                                                              А в том, что в отличие от GWT можно писать на Java, Kotlin и Scala. А ещё есть несколько приятных фишек, отсутствующих в GWT (например, эмуляция тредов на корутинах). Ну и собственно, упомянутый фреймворк, которого для GWT нет.

                                                                                          +1
                                                                                          Чувак, так это твой проект? Дай пожму тебе обе ноги. Это волшебно.

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

                                                                                          Олсо, можно забуриться внутрь и написать по этому проекту еще один пост на Хабр? Третий :)
                                                                                            +2
                                                                                            Чувак, так это твой проект? Дай пожму тебе обе ноги. Это волшебно.

                                                                                            Спасибо


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

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


                                                                                            Про внутреннюю архитектуру есть совсем немного на wiki в github. Там проще не статьи писать, а сразу послать читать Мучника + дать ссылок на несколько имеющихся статей по оптимизациям на SSA.


                                                                                            Олсо, можно забуриться внутрь и написать по этому проекту еще один пост на Хабр? Третий :)

                                                                                            Можно, но я не буду этого делать. Раздел "Я пиарюсь" мало кто читает, а правила Хабра запрещают где-либо ещё публиковать статьи. Я хотел написать статью про то, как я делал online TeaVM (который на самом деле является просто javac, скомпиленным в JS), но буду публиковать на англоязычных платформах, скорее всего.

                                                                                              0
                                                                                              Ну тогда давай я тебя попиарю, мне можно. :)
                                                                                          +1
                                                                                          Для сложных клиентских приложений использование GWT очень даже оправдано.
                                                                                          GWT — это COBOL начала 21 века для веба. (С)
                                                                                          +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.

                                                                                            0
                                                                                            А Play! стал надёжным? Или он всё ещё как несколько лет назад, на ровном месте вываливается загадочный ексепшн, про который уже задано пять вопросов на стековерфлоу, но решение проблемы так в течение года и не найдено?
                                                                                            –3

                                                                                            Фреймворков нет. Есть tapestry5, но он как всегда отстаёт на 5 лет от того, что нужно разработчикам сейчас на фронтенде.


                                                                                            Поэтому я пилю новый фреймворк для разработки современного фронтенда на джаве. В том числе и веб-приложений с портированием на андроид. У меня в этой теме лет 10 опыта с отслеживанием трендов, так что не очередной реактивный MVC фреймворк с гитхаба.


                                                                                            Проблема лишь в том, что не всегда удается выделять время. Из-за чего все очень медленно развивается.


                                                                                            Готовы ли вы вложить собственные деньги, если скажем я все подробно распишу и запущу краудфандинг компанию на кикстартаре? Сколько бы вы вложились — $100, $1000, или вложились бы в крипте более существенные средства?

                                                                                              +2
                                                                                              Использовали Dropwizard на backend и angular на фронтенд. Работало как часы. Фронтенд в maven тащить не надо. Собирай локально статику и выкладывай в какой нить cloudfront
                                                                                                +1
                                                                                                Интересно, знаком с «svenmeier» лично, сам он говорил что Wicket по сути только в легаси проектах используется
                                                                                                  +1

                                                                                                  Если (когда) ты захочешь написать сиквел про хорошие фреймворки, не забудь посмотреть на ratpack.

                                                                                                    +1
                                                                                                    В 2010 про него можно было что-нибудь написать. Сейчас заканчивается 2017 год и веб сегодня в браузере, а не на бекенде. Таких как ratpack на гитхабе сотни, они ничего не дают современному фулстек разработчику.
                                                                                                      +1

                                                                                                      Кажется вы давненько не смотрели на ratpack.

                                                                                                        +1
                                                                                                        Покажите раздел документации, где показано как ratpack позволяет управлять DOM на фронтенде.
                                                                                                    +4

                                                                                                    Full stack development скорее мертв, чем жив. Технологии шагнули далеко вперёд. React + REST по удобству и скорости работы на порядок превосходит все эти Java web фреймворки.


                                                                                                    Дело то в том, что frontend технологии развивают все подряд, а Java web фреймворки — только java сообщество.

                                                                                                      +5
                                                                                                      Судя по комментариям у java сообщества толком нет понимания, что такое современный веб. Либо Spring, либо веб-фреймворк из времен когда jquery было модно…
                                                                                                        +2

                                                                                                        Есть подозрение, что у значительной части Java-сообщества есть мечта: свалить с Java на что угодно другое.


                                                                                                        Человек сначала ставит перед собой задачу: свалить из Java, и потом уже придумывает список аргументов.


                                                                                                        Аргументы в таком варианте нужны не чтобы что-то аргументировать, а чтобы выглядеть социально-одобряемым способом. Хейтить Java на работе Java-программистом, или хотя бы даже в блоге Java на Хабре — это не социально-одобряемая активность. Но вот если сформулировать это как-то другими словами, уже может проканать :)

                                                                                                          +2
                                                                                                          Именно поэтому и пишутся веб-фреймворки на Java — чтобы попробовать, ужаснуться и спокойно писать фронтенд на фронтенд-технологиях :)
                                                                                                            +2

                                                                                                            А дело в том, что Java изначально семантически очень плохо приспособлена для декларативных конструкций и DSL-ей. Фреймворки, построенные на аннотациях — это некий компромисс между декларацией и исполнением, причем очень фиговый по сравнению с тем же DSL. В бекенде еще как-то прокатывает, но во фронтенде, где приходится создавать иерархические конструкции (напр. DOM), в императивном стиле на Java это превращает код в линейную кашу. Поэтому на Java никогда не было и не будет нормальных html-темплейтеров, тем более type-safe как на скале или котлине. Хотя попытки есть: https://j2html.com/

                                                                                                        +4
                                                                                                        Как меня бесят java фреймворки, в которых по дизайну нельзя открыть больше одной вкладки за раз из-за вьюстейтов. Какие же сайты ущербные с ними попадаются…
                                                                                                          0

                                                                                                          Согласен. Но на самом деле, даже в Wicket можно открыть несколько вкладок. Например, можно на каждый таб начинать новую сессию, но при этом сделать signle sign on для всех этих сессий. Или перехватить AjaxNewWindowNotifyingBehavior и сделать setResponsePage(getPage().getClass()). Другое дело, что создатели фреймворка подумали об этом в последнюю очередь, и при попытке применить это в хайлоаде, результат скорей всего опечалит (даже не дебажная версия страницы как нефиг делать может внезапно вырасти до нескольких мегабайтов). А еще, мало кто смотрел как работает фреймворк, и не в курсе о значительной части "возможностей, о которых подумали в последнюю очередь" — а ведь никто о них не скажет.

                                                                                                          +3
                                                                                                          1) Разработка на Java трудозатратней, чем разработка на php/python/ruby, поэтому, если и использовать Java, то получать профит от всех секьюрити библиотек, клаудов и прочего тяжеловесного треша.

                                                                                                          Разработка тяжеловесных компонентов — сложная вещь, и если это сделано на отлично в Spring, какой смысл изобретать велосипед и использовать что-то еще? Тем более уже понятно, что не разработаешь ты что-то лучше, тупо времени не хватит.

                                                                                                          2) Ну возьмешь ты какой-то левый Java Web-framework, ну начнешь ты нам нем что-то писать. Где по итогу ты возьмешь людей на проект? И так людей компетентных сложно найти, а если искать на какой-то непопулярный фрейм, то забей сразу.

                                                                                                          3) Смешивать front и back в коде — это мужеложство. Если очевидно, что потребуется что-то сложнее, чем пропихнуть переменные через шаблонизатор в html, то надо разделять front и back и пихать все через Rest.

                                                                                                          Отсюда все Java фреймворки, которые пытаются дать генерацию фронта через бек — это убожество, которое дает результат уровня 2010 года.

                                                                                                          4) Я понимаю, что у многих мужиков появляются желания сменить своего партнера и попробовать что-то новое, неизведанное, запретное, но зачем такой подход тащить в разработку? К чему такое яростное желание уйти от Spring?

                                                                                                          Он решает задачи и делает это хорошо. Он идеально подходит для современного веба, если его завязывать исключительно на бек. Он стабилен и надежен. Вон те же .net-разработчики сидят на одной платформе и не парятся, даже везде кричат, что .net — это легкий выбор стека, а java — это пьяная драка в коммуналке.
                                                                                                            +1

                                                                                                            я буду искать не senior framework coder, а senior software engineer. То есть человека, который программирует на идеях, а не на конкретных реализациях. Тогда конкретную реализацию можно будет выбирать в зависимости от ситуации. А ситуации бывают разные (иначе всех программистов можно было бы автоматизировать по-Грефовски)

                                                                                                            0

                                                                                                            -

                                                                                                              +2
                                                                                                              Более полная версия картинки:
                                                                                                              github.com/mraible/history-of-web-frameworks-timeline
                                                                                                                0
                                                                                                                Это десять из десяти, чувак — бох. Спасибо!
                                                                                                                +1

                                                                                                                Каждый наверное спрашивал себя, почему у них на руби/пхп/шарпе все так легко? Там уже все сделали, а вы еще настраиваете проект и конфигурируете самолет? (Или поддерживаете что-то на тапестри 4.2)


                                                                                                                Даже если взять для примера Core.Net (а можно рельсы там или еще что), то в нем уже практически все готово для веб и на блюдечке, садись пиши страницы, рест апи, сервисы, что хочешь, даже в той же самой идее, которая Rider.

                                                                                                                  0
                                                                                                                  start.spring.io
                                                                                                                  Перечисляешь модули, какие тебе надо, на выходе — работающий проект

                                                                                                                  Даже для Викета такая страница где-то там на их сайте есть

                                                                                                                  Рельсы имхо плавно умирающая технология
                                                                                                                    0

                                                                                                                    Работающий проект — это мягко говоря не совсем так.
                                                                                                                    Чтобы ощутить разницу, можно попробовать накидать в этом конструкторе работающий рест сервис с поддержкой JWT токенов или например добавить SSO Keycloak через SAML протокол в проект с серверным рендерингом. Если не помогло — заменить контейнер со спринга на джус, шучу, но в коре так можно, он не завязан на конкретный контейнер.


                                                                                                                    Если из этого конфигуратора вырезать то, что покрывает EntityFramework, Razor, WebApi и несколько других пакетов (предельно (!) простых в установке и настройке), то выбирать будет практически нечего, а это значит что все работают со стандартными инструментами, компонентами, апи и так далее.


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

                                                                                                                      0
                                                                                                                      Ruby — согласен. В нем нет ничего, чтобы держало технологии на плаву. Как фокус хипстеров сместился на node.js, популярность упала сильно. Сейчас если и вижу работу, то на проекты 2008-2010 года.
                                                                                                                      +1
                                                                                                                      Тоже через это проходил. После Python с его Django, которая за считанные часы позволяет написать проект, поднять рест, настроить почтовики и прочее, Java показалась каким-то адом. А потом мне пришлось делать на Python GIS проект — получилось так себе, так как основная часть GIS библиотек: .net/java/c++. В итоге, сделали проект изначально на Java и сам удивился тому, как с java было все проще.

                                                                                                                      А вообще надеюсь в net.core, ибо на .net писать веб-сервисы приятней, чем на Java, но из-за отставания эко-системы и лока на Windows — сфера разработки крайне ограничена.
                                                                                                                      0
                                                                                                                      У Викета простая интеграция с html. В этом его плюс.
                                                                                                                        0
                                                                                                                        Хаос полный! Рынок, он такой))))
                                                                                                                          0
                                                                                                                          Когда-то в «Разборе полетов» обсуждался web framework Jooby — попробовав этот легковесный и мощный framework, тяжело от него отказаться.
                                                                                                                          Jooby из коробки имеет достаточно большое количество модулей (для работы с различными БД, pac4j, оптимизация статики и многое другое), которые помогают быстро создать проект (как REST так и рендерить html). Что не мало важно — данный проект имеет хорошую документацию.

                                                                                                                          А так же стоить упомянуть что в качестве embedded веб сервера можно выбрать netty/undertow/jetty и с удобной системой конфигов это все легко настроить.

                                                                                                                          Как итог приложение упаковывается в fatJar. Так что если нужен веб на java — люто советую использовать Jooby (ну или как упоминали SparkJava/Spring Webflux).
                                                                                                                            0

                                                                                                                            Если говорить про фреймворк на бекенде. А чем vert.x не угодил? В отличии от Spring Boot 1.x он не такой тяжёлый. Стартует гораздо быстрее. Есть интеграция со множеством middleware, БД, внешними сервисами. Шустрый (используется неблокирующая и асинхронная Netty
                                                                                                                            под капотом), реактивный. Не всем это правда нужно. Больше подходит для высоконагруженных микросервисов. Отсюда и не популярный.

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

                                                                                                                            Самое читаемое