В данный момент пилю приложение на vaadin.
Очень грубо это простой складской учет.
Судя по статьям в инете и форумам, сейчас очень популярны варианты архитектуры на
REST + JS-клиент (Что-то вроде AngularJS).
Собственно вопрос, правильно ли я понимаю тему?
Чтобы сделать тот же склад на такой архитектуре, надо на каждый чих клиента, создавать REST точку с обработкой этого чиха?
Т.е. появилась у меня сущность "товар", мне надо в REST сервисе сделать 4 метода CRUD, плюс еще куча методов для получения списка и других манипуляций с этой сущностью?

В результате, для боле менее серьезной программы получится просто тонна одинаковых REST сервисов методов для каждой сущности?
Плюс к этому, для интерактивных манипуляций процессом выполнения кода на сервере пользователем, количество этих самых точек еще больше возрастает?
Так в чем тогда преимущество и откуда такая популяность, если тот же ваадин позволяет вообще не думать о таких вещах? достаточно создать сущность и методы работы с ней.

Или я просто чего-то непонимаю в таком подходе?

Я пока еще не супер гуру, но все же.

kentbek1. Меньше рисков с наймом работников, javascript разработчиков больше чем знающих GWT, ZK, Vaadin и JSF вместе взятых, и зряплата у них всё таки поменьше чем у java разработчиков.
А на сколько они меньше реально? Не думаю что это на много критичнее зоопарка технологий в проекте.

kentbek2. Проще тестировать, контроллеры обрабатывающие JSON тестируются специально дрессированными на это либами типа rest-assured . А javascript тестироются через WEB driver, сервер по желанию можно замокать скажем через restito . В итоге мы каждый аспект(вью и контроллер) тестируем специально предназначенными для этого библиотеками, когда же у нас html/javascript автогенерируется server-side фреймворком то получается полная каша, и тестировать её сложнее.
А кто в здравом уме будет тестировать эту кашу?? Тестируется Java код. И стандартно селениум для гуя.

kentbek3. Масштабируемость лучше. Server-side фреймворк вынужден хранить на своей стороне состояние DOM дерева, в случае когда javascript пишется руками нам этого не требуется. В простых случаях можно на серверной стороне даже вообще нечего не хранить кроме айдишника сессии.
Масштабируемость чего лучше? У меня юзвери просто прутся от того, что на ваадине можно перейти за другой комп, залогиниться и увидеть все свои открытые окна в том же виде. Вот тут как раз и есть масштабирование нормальное, можно мотать пользователя по серверам как хочешь. А масштабирование клиентской части, кому оно надо?

kentbek4. Закрытое комьюнити стоящее за отдельно взятым java фреймворком, никогда не сможет противостоять скажем jquery в который вливают код программисты пишущие на всех языках php, ruby, java и других, программируя сразу на javascript мы имеем доступ ко всем самым свежим наработкам и ничем не ограничены.
А нафига противостоять слону и крокодилу? Они по жизни слабо пересекаются. Ну где вы увидели закрытое комьюнити-то? Исходники открыты, делай что хочешь... куда уж свежее то? И кто где чем ограничен если не использует javascript? По моему в попытках что-то доказать вы уже загнались совсем...

kentbek5. Чисто теоритически можно переиспользовать контроллеры, например заюзать их для мобильное версии клиента, им-то всё равно принимать и отдавть JSON, а браузеру или мобильному приложению это не важно.
Да да. Можете еще что-то там переизобретать или переиспользовать.. или еще что-то там пере... мое приложение люди просто открывают на планшете или мобильнике. Головняка нет вообще. Оно просто работает везде.

kentbek6. Выше внешнее качество видимое пользователем, javascript программисты более искуссны чем свои java собраться в плане создания интерфейсов.
Это вообще бред полный. Просто JS программисты могут только интерфейсы клепать, вот и натаскиваются на них. ))
А вообще, интерфейсы должен специалист делать, дизайнер там или спец по юзабилити. А вот кто их и на чем запрограммирует это дело уже десятое.

В общем очень не убедительные аргументы.