Почему J2EE разработчики враждебны к JSON

В последнее время перед J2EE разработчиками открывается дивный новый мир веб-приложений, которые хотят их заказчики, но в которых они оказываются совершенно чуждыми и бесполезными. Почему так происходит?
Заказчики хотят всех прелестей тонкого клиента - хотят запускать красивые легкие приложения везде, где есть браузер. Наибольший прогресс в веб-разработке достигнут разработчиками таких фреймворков, как ExtJS, jQuery UI, YUI. Однако при попытке их использования в J2EE получаются интересные вещи:

1. Веб-приложение построено по модели MVC исключительно на JavaScript + HTML + CSS (в которых J2EE-разработчики практически не разбираются), то есть серверный Java MVC-фреймворк (Struts, Spring MVC и т.д.) становится не нужен.
2. Веб-приложению в процессе работы от сервера нужен в основном JSON, получаемый на основе запросов к СУБД, то есть вместо толстого сервера приложений типа WebSphere, который просто запускается несколько десятков минут, нужна тонкая прослойка, умеющая запрашивать БД и отдавать клиенту JSON, что-то типа Jaxer или NoSQL-базы данных, сразу дающей ответ в JSON. Всякие JSP, Tiles и прочие сервлеты и шаблоны больше не нужны.
3. Веб-приложение может не содержать ни строчки Java-кода. И вообще, разработка без постоянных пересборок проекта идёт намного быстрее и приятнее: сохранил код в редакторе IDE - сразу же посмотрел результат в браузере (соседняя вкладка в той же IDE).

Получаем взаимоисключающие требования:

• Либо мы разрабатываем веб-приложение, например на ExtJS, и на сервере нам нужны только Apache (или nginx), PHP и MySQL (или MongoDB, CouchDB, Riak, ...), а J2EE - ненужный балласт (как и весь имеющийся штат Java-разработчиков).
• Либо мы требуем обязательного использования J2EE-технологий, сервера приложений, EJB, накопленного опыта Java-разработчиков (которые в основном разбираются только в серверных технологиях), и оставляем самое важное на потом - собственно клиентскую часть "прикручивают" немногочисленные разработчики, как-то разбирающиеся в веб-технологиях.