-
![[image]](https://www.balancer.ru/cache/images/forums/logos/1358/128x128-crop/1358631-programming_oop_wallpaper_red_by_hexeno.png)
Некоторые сумбурные мысли о выборе Web-фреймворка и языка программирования
Теги:
Роман Каршиев
Некоторые сумбурные мысли о выборе Web-фреймворка и языка программирования
Я уже довольно давно морально дозрел до реализации основных концепций своего PHP-фреймворка на какой-то иной платформе, чем PHP. И, поскольку мне без особой разницы, над чем надстраиваться, встаёт вопрос выбора удобного готового решения. Чтобы меньше велосипедить, сконцентрировавшись на, собственно, идеологии.
Поскольку программирование в стиле Perl/PHP (поменял исходник, переключился в браузер, нажал F5, видишь результат) мне давно импонирует, то и к фреймворкам я присматривался «скриптовым». В первую очередь, конечно, Django и RoR.
Присматривался к ним не первый год, на Django даже один проект делал (но забросил — очень уж неэффективно писать на чистом Django). Но перейти так и не решился. По сути получается замена шила на мыло.
RoR тут мне вообще не нравится. Довольно медленный и очень, очень капризный. Ну что за проект, при постановке которого по инструкции с оф. сайта получаем на первом запуске тонну Depricated. Что за язык, в котором постоянно ломают обратную совместимости. Поддержка того же Redmine, написанного на RoR — это ад какой-то. Ну и то, что Ruby является наследником Perl тоже не улучшает отношения к нему. Конечно, тут всё не так плохо, как в Perl, но постоянно возникает желание писать в write-only стиле. В общем, не пошло.
Django гораздо приятнее. Довольно строгий Python в роли платформы. Относительно высокая производительность. Но... после практических экспериментов сделал вывод о размене шила на мыло. Не смотря на некоторый выигрыш в производительности, затраты на реализацию фреймворка на новой платформе за обозримое время не окупятся.
Так что, в итоге, смена платформы и не произошла.
Однако, в прошлом году, я столкнулся с интересным проектом — Play Framework. Это классический Web-фреймворк (MVC, роутинг, ORM и прочее) на JVM. Первая версия работала с Groovy, вторую переделали на Java и Scala. Интересен тем, что не смотря на то, что фреймворк реализован на «компилирующих» языках, работа под ним идёт в духе PHP. Поменял исходник, обновил страницу — класс автоматом перекомпилируется и обновится. Скорость разработки становится очень высокой. При этом мы имеем всю мощь JVM. От довольно высокой производительности до широчайшего спектра библиотек.
Однако, мысли о переезде на него так и оставались мыслями. Всё же, работы много, а интерес пока сугубо теоретический.
Недавно столкнулся ещё с одном весьма интересным решением — фреймворком Revel. Идея этого движка была взята с Play (на оф. сайте так и пишут), но реализован он был на платформе Go. Сперва я оценил очень высокую производительность. Позже познакомился с самим Go. Язык неплох и интересен. Хотя и своеобразен. В минусах — намного меньшее количество библиотек, чем на JVM. Даже ORM отсутствует из коробки (хотя прикручивается из сторонних библиотек). В плюсах высокая скорость компиляции (про скорость работы я уже писал), быстрый старт виртуальной машины, намного более экономное отношение к памяти, чем на JVM.
В общем, я всерьёз задумался о переходе на Go.
Но, вот ирония судьбы. Стоило вчера поднять на ЛОРе эту тему, как объявился старый знакомый с предложением возобновить работу с одним старым-старым Java-based проектом. При чём мне реально интересно им заняться. И в этом случае вариант с Play Framework получает серьёзный бонус — мне не придётся распыляться на два фронта. А идеологию свою я всё равно планирую реализовывать и в этом проекте.
Так что, видимо, всё же, Play Framework?
// Транслировано с balancer-it.blogspot.com
Я уже довольно давно морально дозрел до реализации основных концепций своего PHP-фреймворка на какой-то иной платформе, чем PHP. И, поскольку мне без особой разницы, над чем надстраиваться, встаёт вопрос выбора удобного готового решения. Чтобы меньше велосипедить, сконцентрировавшись на, собственно, идеологии.
Поскольку программирование в стиле Perl/PHP (поменял исходник, переключился в браузер, нажал F5, видишь результат) мне давно импонирует, то и к фреймворкам я присматривался «скриптовым». В первую очередь, конечно, Django и RoR.
Присматривался к ним не первый год, на Django даже один проект делал (но забросил — очень уж неэффективно писать на чистом Django). Но перейти так и не решился. По сути получается замена шила на мыло.
RoR тут мне вообще не нравится. Довольно медленный и очень, очень капризный. Ну что за проект, при постановке которого по инструкции с оф. сайта получаем на первом запуске тонну Depricated. Что за язык, в котором постоянно ломают обратную совместимости. Поддержка того же Redmine, написанного на RoR — это ад какой-то. Ну и то, что Ruby является наследником Perl тоже не улучшает отношения к нему. Конечно, тут всё не так плохо, как в Perl, но постоянно возникает желание писать в write-only стиле. В общем, не пошло.
Django гораздо приятнее. Довольно строгий Python в роли платформы. Относительно высокая производительность. Но... после практических экспериментов сделал вывод о размене шила на мыло. Не смотря на некоторый выигрыш в производительности, затраты на реализацию фреймворка на новой платформе за обозримое время не окупятся.
Так что, в итоге, смена платформы и не произошла.
Однако, в прошлом году, я столкнулся с интересным проектом — Play Framework. Это классический Web-фреймворк (MVC, роутинг, ORM и прочее) на JVM. Первая версия работала с Groovy, вторую переделали на Java и Scala. Интересен тем, что не смотря на то, что фреймворк реализован на «компилирующих» языках, работа под ним идёт в духе PHP. Поменял исходник, обновил страницу — класс автоматом перекомпилируется и обновится. Скорость разработки становится очень высокой. При этом мы имеем всю мощь JVM. От довольно высокой производительности до широчайшего спектра библиотек.
Однако, мысли о переезде на него так и оставались мыслями. Всё же, работы много, а интерес пока сугубо теоретический.
Недавно столкнулся ещё с одном весьма интересным решением — фреймворком Revel. Идея этого движка была взята с Play (на оф. сайте так и пишут), но реализован он был на платформе Go. Сперва я оценил очень высокую производительность. Позже познакомился с самим Go. Язык неплох и интересен. Хотя и своеобразен. В минусах — намного меньшее количество библиотек, чем на JVM. Даже ORM отсутствует из коробки (хотя прикручивается из сторонних библиотек). В плюсах высокая скорость компиляции (про скорость работы я уже писал), быстрый старт виртуальной машины, намного более экономное отношение к памяти, чем на JVM.
В общем, я всерьёз задумался о переходе на Go.
Но, вот ирония судьбы. Стоило вчера поднять на ЛОРе эту тему, как объявился старый знакомый с предложением возобновить работу с одним старым-старым Java-based проектом. При чём мне реально интересно им заняться. И в этом случае вариант с Play Framework получает серьёзный бонус — мне не придётся распыляться на два фронта. А идеологию свою я всё равно планирую реализовывать и в этом проекте.
Так что, видимо, всё же, Play Framework?
// Транслировано с balancer-it.blogspot.com
инфо
инструменты
Copyright © Balancer 1997..2022
Создано 12.03.2013
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
Создано 12.03.2013
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
