Victor MetelitsaAJAX расшифровывается "Asynchronous Javascript And Xml", да, но ныне подразумевается, что данные не обязаны быть в виде XML. При этом механизмы никуда не делись и активно используются всевозможными JS-фреймворками, так что если термин стал упоминаться реже, то по существу AJAX стал использоваться чаще. HTTP/2, разумеется, не имеет отношения к данному вопросу.
Ну, давайте дальше поиграем в капитана очевидность и посмотрим на более полную историю базвордов
IFRAME - темные времена
AJAX (XmlHttpRequest) - конец 90х
JSON - начало нулевых
REST - начало нулевых
WebSocket - конец нулевых
HTTP/2 - два года спеке, но только начинает внедрятся

Так, вот, когда вы в 2017м году упоминаете AJAX в контексте изучения новых (для себя) технологий, возникает ощущение что вы последние 10+ лет где-то пропадали на рудиках и всё пропустили. И вместо того чтобы изучать актуальные вопросы, решили зачем-то наверстать всю декаду.

HettА каким образом Angular данные подгружает?
Возможно это поможет: https://ru.wikipedia.org/wiki/Тренд

Victor MetelitsaВначале была бузина, затем вместо неё появился дядька, затем вместо дядьки огород, а теперь в моде Киев. Забудьте про бузину - это тёмные времена, устаревшие технологии.
Продолжаейте кривлятся и кичится своим невежеством. Поможет по жизни.

Victor MetelitsaА ведь моя цель в жизни - пользоваться самыми модными, только что появившимися, технологиями.
Ну, да. А жигули "шестёрка" - лучший автомобиль. Вы путаете "модное" и "актуальное". Не нравится HTTP/2 - не ешьте. Но от этого JSF и JEE не перестанут быть унылым говном. Я бы мог вам и про историю создания и развития JSF написать. Но вам же плевать. Всё равно только кривлятся можете вместо того чтобы технически аргументировать свою позицию.

Victor MetelitsaНадеюсь, это секретная история - из тех, что не рассказывают в книгах?
Да, я её на форумах озвучивал не однократно. В книгах об этом не пишут. Из википедии можно частично подчерпнуть, если читать внимательно.

Victor MetelitsaА какую мне позицию аргументировать?
JSF актуальный фреймверк, потому что... Просто потому что.
Spring MVC - говно потому что с помощью него можно сделать SPA.

Victor MetelitsaСделаю тестовое приложение, оценю, попривыкну к элементам EE, потом смогу как-то оценивать.

Вы не сможете оцнить, потому что не знакомы с альтернативами. Сгенерируйте себе проект в Spring Boot или JHipster и сравните на сколько меньше требуется кода и работы чтобы получить аналогичное решение.

Victor MetelitsaПока моя оценка "мне это стоит попробовать для расширения кругозора".
Просто потому что актуальные технологии вам давно знакомы, вы решили расширять кругозор в сторону старых и переусложненных. Археология как она есть.

HettДа JEE7 не требует тонны XML конфигов, в отличие от своих предшественников. И все так же как в спрингбуте управляется при помощи аннотаций. Есть и интеграции упомянутого вами ангулара и для JEE и я не думаю, что оно работает хуже, чем со спринг.
Во-во-во. Я ж об этом же. То что JEE избавился от кучи нелепых конфигов, ещё не делает его адекватным фреймверком. Там всё ещё куча остального boilerplate кода и за пределами конфигов.

HettНикто не кричит, что спринг, как вы выразились, говно.
А я где-то утверждал что "кричит"? Вы снова мне приписываете свои домыслы.

HettСкорее наоборот, вы заявляете что JEE говно.
Да откуда же "скорее" ваше взялось? Так и говорю прямо без намёков - "JEE унылое говно, и не важно что там за циферка после этих трех букв". Куча особых случаев, которые тупо не реализованы, и которые нельзя прописать самому, потому что это уровень фреймверка, а не приложения. Куча boilerplate кода, не смотря на то что появился CDI. Если вы плотно пишете на JEE, то в итоге всё равно изучаете решение от конкретного вендора, а не полноценный фреймверк. Вот автор споткнулся об DataSource. Потому что снача ему надо было изучить как с DataSource работает в JEE. А потом изучить как его добавить в Glassfish. А потом ещё упереться в какую-то магию, которая в одном контейнере работает, а в другом - нет. А когда автору нужно будет настроить JDBC пул, ему придется дальше изучать конкретику пула в GF.

И это всё вместо того чтобы просто взять пул, создать его экземпляр в Spring конфиге и дергать метод getConnection().

HettЧерез это и сам спринг прошле, между прочим.
Вы невидите разницы, потому что не работали с JEE времен конфигов. В то время как в Spring XML вы декларативно программировали своё приложение, в JEE конфигах вы писали кучу всякой ерунды просто потому что так надо.

Victor Metelitsaспасибо,
а в чём разница?
Поищи по форуму название контейнера. Баги GF тут всплывают каждые несколько месяцев.

mad_nazgulПо мне, что то Г, что это Г.
ИМХО для большинства задач вполне хватает Tomcat или Jetty.
Ну, им же JSF, CDI нужны.