jbaruch

Синхронизация когда то была, но безпроследно исчезла несколько лет назад. И похоже, что они этого уже не вернут.

Есть альтернатива — bintray.com

Фреймворки необходимы, как основа любого боле- менее сложного проекта.
Основные причины:
-Стандартизация и поддерживаемость кода, и уже это, практически всегда, важнее нескольких процентов оверхеда.
-Упрощение коллективной разработки.
-Повторное использование кода — отсутствие необходимости каждый раз реализовывать типичные вещи и отлаживать лишний код. Это касается и библиотек. Писать всё с 0, практически всегда, крайне неразумно. Кроме того, что заметно увеличиваются трудозатраты, так и качество в среднем падает(или трудозатраты растут уж совсем сильно — куда больше отладки и тестирования).
-Возможность генерации кода и.т.п., что помогает сильно ускорить разработку.

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

> Как остаться нормальным программистом не на задворках, не потерять хватку и не теряться во всем этом?
Постоянно учиться и специализироваться в более узкой области. Это верно для любого специалиста, собственно, и с программированием прямо не связано…

Делали приложение на Wicket — в целом остались довольны. Но для большой нагрузки он не подойдет — куча данных хранится в сессиях.

> Были посты про то, что железо улучшается, а программы продолжают тормозить — не из-за этого ли?
> Десятки слоев, абстракций, отъедающие свои ресурсы.

Посмотрите доклады архитектуры highoad проектов. Тормозить могут три вещи — дисковые операции, база данных и сеть. ООП конечно проигрывает по скорости выполнения процедурному подходу, но этот проигрышь 0.00001% запроса к БД. Если программа тормозит, то не из за слоев абстракции, а вышеуказанных причин.

>MVC — круто, наворочено, универсально — но проигрывает по сравнению с тем же PHP по многим пунктам.

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

>Простой проект MVC — это около десятка папок, пять конфигов, куча контроллеров. Опять же — куда такие сложности?
> Для чего?

Это очень сильно упрощает жизнь даже в небольших проектах, в больших польза от этого растет экспотенциально.

>когда вы в этом успеваете разобраться? Сколько лет ковыряния нужно, чтобы досконально знать, что вызов вот
> этого приведет к этому, вызов того делает то, причем на пять слоев абстракций в глубину, и особенность
> вон того дает преимущество в этом.

Это зависит от опыта и сложности платформы, опытному программисту (5 лет коммерческой разработки на полную ставку) хватит от пары дней до пары недель чтобы начать выполнять новый проект на незнакомом фреймворке, месяца 3 чтобы уверенно себя чуствовать и 1-2 года, чтобы досканально разобраться во всех внутренностях.

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

>И как можно вникнуть в технологию, чтобы применять её на практике, если через пару лет появляется
> более новая технология или в корне меняется старая и надо снова рыться, снова изучать и т.п.

Новые технологии принципиално оличающиеся от всех предыдущих появляются редко, если вообще появляются. Все новые технологии основанны на предыдущем опыте. Например новомодная MongoDB которой лишь предстоит стать мэйнстримом основана на JavaScript и JSON, а эти технологии знакомы любому веб-разработчику. Другой пример новомодных NoSQL технологий — это key-storage хранилища например memcached и redis, любой кто работал с реляционными БД разберется в них за 5 минут. Конечно чтобы внкнуть в тонкости API и конфигурации нужно больше времени, но ничего сложного там нет.

Если Вы пишете большое приложение, которое делают несколько человек, которое нужно сопровождать, то фреймворки экономят очень много времени. Конечно же не бесплатно, а ценой худшей производительности (т.е. нужно более серьезное железо). Я не специалист в PHP, могу сказать про Яву. Функциональность, которую мне дадут Spring, Hibernate, GWT — я бы сам писал годами.
Конечно в каждом конкретном случае надо решать — нужен ли фреймворк, и если да то какой…

если нужен очень Rich клиент, с богатым интерфейсом — GWT
если немного AJAX, но хочется писать в Swing style (листенберы и так далее- Wicket)
если не хотите интерфейс писать на Яве, а будете делать HTML, JavaSciprt, CSS и Вас интересует только сторона сервера —
Spring MVC, Grails. Будет почти тоже самое, что на сервлетах и jsp, но проще и гибче

я бы рекомендовал, не просто maven, а уже gradle.