Поиграй со мной

Итак, собственно что такое Play! - это современный веб-фреймворк на Java в его версии 1.x и Scala/Java в его грядущей второй версии. Одним из значительных отличий Play! от других фреймворков, основанных на Java (включая и Lift), является то, что он не базируется на Servlet API, но предоставляет свой полный стек для запуска приложений, и как написано в официальном FAQ - "Play is platform". Впрочем, если требуется, то приложение на Play! можно запустить с помощью Tomcat, Jetty или другого контейнера. Да, и ещё можно забыть об xml для конфигурации приложения.

Play! был выбран заказчиком, а нами опробован на этапе переговоров. Впечатления и тогда, и сейчас от Play!/Java целиком положительные. Простой и понятный роутинг, привычный по другим фреймворкам скелет приложения, хороший шаблонный движок, встроенная работа с тестами (включая Selenium), наличие документации, FAQ, ответов на StackOverflow, поддержка в IDE и редакторах - Eclipse, Idea, Netbeans, TextMate, Vim. Развёртывание предельно простое - распаковываем тарбол, прописываем каталог в PATH, "$ play new MyApp" - вот и все. С Play! быстрый старт действительно получается быстрым. И я считаю, что в таком виде фреймворк вполне годен для написания настоящих, "серьёзных" приложений.

Но заказчик захотел Scala. Предполагалась тесная интеграция с внешними сервисами, используя их XML API, а в таком случае на полную бы заработали встроенные средства языка, которые в Scala очень мощные. Да и согласитесь - Scala сама по себе интереснее. Можно сказать, что в Play! 1.x встроена поддержка Scala "из коробки" - в зависимости прописывается модуль, вместе с которым в проект приехали новый шаблонный движок и DSL для SQL-запросов Anorm взамен стандартного ORM. От последнего пришлось отказаться буквально в первый день: задумка хорошая, но отсутствие нормальной документации, отсутствие поддержки сообщества и общая сырость не позволили применить Anorm. На место был возвращён ORM на основе JPA. А дальше начали проявляться проблемы обратной совместимости Scala c Java: различия в работе с коллекциями, несоответствие типов (в Scala как таковых нет перечислений (enum), например), различия в объектной модели, доступ к API фрейморка в большинстве случаев через специальную прослойку, неработающие со Scala-кодом Java-модули. Шаблонизатор тоже отличился чувствительностью к переносу строки, пробелам, а иногда и к порядку следования аргументов. Пожалуй, единственное, что действительно понравилось, это библиотека для тестирования Scala Test.

Я для себя сделал следующие выводы: выбирать надо фреймворк, изначально написанный на том языке, который вы будете использовать. В случае Scala Lift гораздо привлекательнее Play!/Scala по всем статьям. Возможно, с выходом второй версии Play!, интеграция станет гораздо лучше, но пока она очень сырая. И ещё такой момент - изначальная Java-архитектура фреймворка все равно находит отражение в Scala-коде, а зачастую и не дает применять все возможности языка. Да, можно писать map вместо for, сократить общее количество кода, но, по большому счету, это мало что меняет - писать "по-другому" не очень-то получится.

Так или иначе, но пока что Play!/Scala - сырой стек, и использовать его я бы не рекомендовал.