0,0
рейтинг
29 декабря 2013 в 21:25

Разработка → PHP фреймворк 2013

PHP*
Идея провести голосование навеяна странной статьей, результаты которой хочется поставить под сомнение. Возможно предпочтения действительно определяются регионом и маленькой выборкой автора, поэтому предлагаю провести голосование среди большого Хабрасообщества.

Извиняюсь, если не добавил какой-то фреймворк. Честно не знаю, возможно ли будет отредактировать опрос после публикации. Старался подобрать самые интересные и крупные проекты, которые видел в этом году.

Цель опроса проста: определить мнение и тенденции сообщества.

Поясню заголовки опросов.

Самый стабильный фреймворк 2013
Фреймворк с меньшим количеством эксплоитов, особенно после релизов новых версий.

Самый развивающийся фреймворк 2013
Думаю в пояснении не нуждается. Очевидно в данную категорию могут попасть молодые проекты. Все же мне лично интересно мнение, за чьей работой следит сообщество.

Ваш выбор
То, чем Вы пользовались и собираетесь пользоваться в будущем и посоветуете внукам.

По поводу ошибок, пожалуйста, пишите в личку.
Самый стабильный фреймворк 2013

Проголосовало 2375 человек. Воздержалось 3536 человек.

Самый развивающийся фреймворк 2013

Проголосовало 2326 человек. Воздержалось 3453 человека.

Ваш выбор

Проголосовало 2799 человек. Воздержалось 3126 человек.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Спартак Каграманян @Assorium
карма
37,0
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (149)

  • 0
    Почему же так мало Коханы… Она же такая замечательная!
    • +1
      На вкус и цвет… Мне вот не нравится её ORM из коробки и встроенная ACL-система. На проектах, где использовал кохану пришлось эти куски переписывать под себя, хотя в остальном она неплоха.
      По работе использую ZF1, Smarty3 и PgSQL а для себя простенький самописный MVC-фреймворк без шаблонизатора с MySQL.
      • 0
        Ну да. А, если не секрет, скажите пожалуйста, что конкретно в Кохановской ORM вам было не приятно?
        • +8
          Не секрет. Выбор «многие ко многим». Да и вообще, мне ORM неудобно. Голый SQL с биндами мне более по душе.
          • +1
            ORM на первый взгляд очень красивая и удобная штука. Но когда начинаешь работать с ORM в сложных проектах, она зачастую очень сильно снижает производительность. Для борьбы с этим приходится делать кучу ручной кастомизаций или костылей. А в итоге, зачастую оказывается что проще было изначально писать все на голом SQL, чем пытаться заставить ORM работать с приемлемой производительностью.
          • +1
            Ни кто и не запрещает вам ORM не использовать ведь, просто выключите модуль. Есть еще вполне нормальный query builder
            • +2
              Попробую вставить и свои 5 копеек. Как по мне ORM в первую очередь это удобный быстрый инструмент для CRUD. Для админки или относительно простого запроса это сэкономит кучи нервов, сил и времени. Но когда речь идет о сложных запросах или выборке больших объемов данных нужно 10 раз подумать выгодно ли использовать ORM. Во первых потребляемый объем памяти. Объекты порой занимают в разы больше памяти по сравнению если бы вы использовали чистые массивы (на одном высоко нагруженном проекте после ухода с ORM потребление памяти одного селекта к примеру вместо 90мб уменьшилось до 5мб ). Второе время выполнения и потрачено время на адаптацию запроса для ORM (пока найдешь по документации как сделать какой нибудь CONCAT('1, '2', '3')). Буду капитаном если скажу что серебряной пули не бывает. Но каждый уважающий себя разработчик должен точно знать когда и какой инструмент будет эффективнее в конкретном случае.
              P.S. Пусть на меня не обижаются yii-сты, но там ORM… как сказать помягче… есть намного лучше варианты.
              P.P.S Чуток промахнулся веткой, извините)
    • +3
      Кохане тяжело попасть в «самые стабильные» (каждый билд ломает совместимость) и в «самые развивающиеся» (скоро 3.3 перестанет поддерживаться, а 3.4 даже не альфа, вроде). Имхо, самый стабильный — yii/codeigniter, самый развивающийся — laravel, мой выбор — kohana.
      • 0
        О! Поясните пожалуйста, если не трудно, почему используете Кохану и что скажете об ОРМ Коханы (коммент выше).
        • +1
          Потому, что удобно. Я даже не знаю как это объяснить, если честно (. Наверное — минималистичность. Минимум лишнего, минимум сложностей, минимум требований. Легко выкинуть или заменить любой класс ядра, не мешая самому приложению (например, заменить mysql в приложении на… что угодно. или классы Exception_* на свои и все приложения/ядро будут использовать новый функционал). Нечто подобное испытываю с phalcon, но он еще сырой (.

          По поводу ORM — ничего не скажу. Вообще. Не использую ни под каким соусом.
        • +4
          Я тоже использую Kohana. Стабильности в ней никакой, фреймворк почти заброшен (3.3 использует устаревшее API и вызывает E_DEPRECATED на новом PHP, 3.4 есть только на Github в сыром виде), для pull request'ов принята особая процедура через багтрекер Kohana, большинство модулей необходимо не только обновлять под новый PHP и библиотеки, но ещё и допиливать.

          Но. Для меня все недостатки нивелируются структурой и архитектурой фреймворка. Вместе с Kostache получается очень чёткая и жёсткая система: Controller — Model — View — Template. Когда для логики преставления есть отдельный класс, в котором даже циклы должны вычисляться. Все реюзабельные блоки, которые в других фреймворках как только ни называются (паршиалы, кусочки, фрагменты) — это всего лишь View+Template, куда кидаются данные свыше, мало или много ли там логики. При этом фреймворк достаточно производительный и простой.
          • 0
            Между прочим, я с Лоренцо общаюсь. И он совсем не против, если любой желающий подключится к его проекту. Да, он довольно авторитарен, но кто запретит автору видеть для своего детища свое будущее.

            Тем более, решительности и настроя он не потерял, даже когда основной костяк команды от него разбежался. Так что, как говорится, хочешь сделать Кохану лучше — присоединяйся.
  • –1
    Странное голосование, если честно. Надо результаты первых голосований смотреть относительно «вашего выбора».
  • +2
    Зря вы silex и symfony разделили только, в общем то там, что авторы, что кодовая база одна и та же.
    Как минимум по первым 2м опросам они должны быть вместе, потому что одни компоненты в основе.
  • +11
    Что за форсирование yii?
    • –12
      [зануда] раз уж вы юзаете интернетовский сленг (forcить), то не форсирование, а форсинг [/зануда]
      • +2
        Если уж на то пошло, то возможно WaveCut имел в виду, что много народу бросилось изучать данный фреймворк и сравнил это с форсированием реки.
        о_О
  • +31
    Для интереса стоило добавить пункт «нативный PHP/собственный framework», чтобы охватить всю аудиторию.
    • 0
      Думаю, можно смотреть на воздержавшихся
      • +12
        Я нажал «Воздержаться», т.к. не использую пхп вообще, но узнать результаты интересно.
      • +10
        А я нажал воздержаться, т.к. вообще не понимаю как я и большинство проголосовавших могут знать ответы на вопросы а-ля «Самый развивающийся фреймворк 2013», когда пробовали то из них 3-4 от силы. А уж слежу я за развитием только одного фреймворка.
  • +2
    Я с полгода назад проводил опрос по PHP-фреймворкам habrahabr.ru/post/183290/. 5000 проголосовало, вполне репрезентативно.
  • –1
    Нет onPHP в списке тех, которые в этом году использовал.
    Хотя в будущем хотел бы попробовать поработать в полной мере с Symfony
  • 0
    Самый стабильный можно определить без голосования — достаточно посмотреть на трекеры проектов.
    Я вот не знаю сколько там багов в каком фреймворке нашли и насколько они критичны, и как быстро их закрыли.
    То же можно сказать и про скорость развития. Количество релизов, коммитов, расширений можно посчитать.

    Поэтому и воздержался.

    И остается только собственный субъективный выбор.
    Я вот работаю с Yii — но только по привычке, мне его хватает почти что полностью.
    Посмотрел на другие — ну все там, грубо говоря, так же. И зачем мне переходить на них?
    Хотя возможно они и быстрее, и где-то (в тех местах, которые я не использую) удобнее.
  • +10
    Холивар 2013!
  • +16
    Самый развивающийся фреймворк 2013
    В опросе лидирует Yii.
    Подскажите, что же в нем такого нового? Второй версии нет (dev-версия не в счет — она не выпущена), в первой только косметические фиксы.
    • +16
      Тоже мнение: какое развитие у Yii? Это самый медленно развивающийся FW в индустрии, по-моему.
      • –3
        ИМХО это одна из причин его популярности. Как и CI.
      • +3
        надо еще смотреть на количество и качество расширений.
        • +6
          С чем у yii так же плохо… Тут однозначно выигрывают zend и symfony.
      • +4
        Скорее всего многие, как и я, имели в виду yii2 — самую активно развивающуюся версию этого замечательного фреймворка.
        • +8
          ее пишут больше 2-х лет, и по своей сути она не сильно от первой версии ушла. У yii не такое большое количество контрибьютеров как у symfony к примеру. Более того, использовать готовые решения (как например поступили ребята из laravel) они не хотят ибо большая часть готовых решений не соответствует философии фреймворка и повышает порог вхождения.
    • –3
      Так ведь развивающийся, а не развившийся. Вторая версия пишется вовсю, вот и развитие.
      • +19
        я правильно понимаю, что если у symfony релиз раз в 3 месяца, а у yii раз в 3 года, то yii — это развивающийся фреймверк, а symfony — застой?
        Или вы имели ввиду, что symfony реализовала неймспейсы 3 года назад, а yii еще нет, таким образом yii, как бы есть куда развиваться, а symfony уже некуда?
    • 0
      Подскажите, что же в нем такого нового?

      Информации о нём больше :)
  • +20
    еще одна бессмысленная статистика… Как пользователи не знакомые со всеми перечисленными фреймворками могут оценить стабильность? или развитие? В любом случае голосовать будут за то что знают/используют. Смысла в такой статистике нет.
    • –6
      Стабильность можно оценить покрытием кода тестами, развитие — количеством пул-реквестов и коммитов.
      • +1
        Лучше бы проектики типа blogmvc.com развивали, толку больше чем от таких статистик…
        • 0
          Согласен, но Вы слишком серьезно воспринимаете простой опрос. Для себя я уяснил, что Хабрасообщество все еще поддерживает Yii, также не могла не порадовать поддержка новых фреймворков вроде Phalcon.
  • –3
    Как по мне, то самый стабильный это Symfony 1.4, с которым сейчас работаю :(
  • +1
    Хотелось бы посмотреть в глаза людям выбравшим phalcon и спросить — это, серьезно, «ваш выбор»? Потому, как уже больше полугода с ним боремся и всеравно не перестает удивлять своими оригиналными решениями.
    • 0
      А что с ним не так? Мне идея понравилась, но использовать так и не удалось.
      • +2
        идея мне тоже нравится, мне не нравится реализация и выбор заведомо не популярных решений.
        Например, в пагинаторе вместо обертывания, используется модификация запроса, из-за чего он работает правильно только на тривиальных запросах. ORM кеширует не только результаты выбоки из бд, но и их отсутствие. И т.д.
        Вцелом фреймверк ооочень сырой, много чего приходиться делать через костыли.
        • +1
          ORM кеширует не только результаты выбоки из бд, но и их отсутствие.

          А в чем проблема? Пустой список вполне нормальный и довольно частый результат, почему он не должен кэшироваться?
          • 0
            вот где я писал про список?
            перед тем как добавить запись в бд нужно проверить, что ее там нет. А так как орм кеширует все подрят, это выливается в дубликаты.
            • 0
              Плохая инвалидация.
              • 0
                там нет инвалидации, только lifetime
                • 0
                  Очень плохое кэширование значит. Или инвалидацией нужно управлять программисту.
            • 0
              перед тем как добавить запись в бд нужно проверить, что ее там нет

              При таком подходе вы получите race condition.

              Поставьте уникальный индекс и обрабатывайте исключение, возникающее при вставке дубликата.
              • –1
                во-первых, задача зачастую не просто добавить, а и обновить существующие.

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

                втретьих, race condition возникает только если есть несколько потоков.

                вчетвертых, почему вы меня программировать учите, вы ведь кода моего не видели?
                • +2
                  задача зачастую не просто добавить, а и обновить существующие.

                  On duplicate key update Вам в помощь.

                  ексепшены это всетаки исключительное событие

                  Исключения и ошибки — это одного поля ягоды. БД не бросит исключение — БД вернет ошибку, а бросит исключение Ваш код. Например, mysql_* не бросает исключений, а PDO бросает — суть не меняется.

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

                  Предотвратить вставку уже существующих данных — это и есть контроль целостности.

                  race condition возникает только если есть несколько потоков

                  Вы правы. Опять же, БД предоставляет Вам возможность избежать гонки.

                  почему вы меня программировать учите, вы ведь кода моего не видели?

                  1. Я вас не учу.
                  2. Комментирование создано, как раз, для обсуждения.
                  3. На мой взгляд, Вы описали «плохие» подходы. И кто-то может научиться у Вас «плохому».
                  4. Вы можете оказаться правы и, в таком случае, чему-то научусь я.

                  какой смысл в красном без короткого? это две абсолютно разные вещи

                  Having без group by — не имеет смысла, и разрешен, если я не ошибаюсь, только в MySQL — в остальных БД Вы получите ошибку.
                  • 0
                    так, уважаемый, вы вобще знакомы с phalcon?

                    Мне приятно знать, что есть люди которые хотят помочь другим, а не только раздают плюсы и минусы, но как решить задачу я и сам знаю. Мы тут обсуждаем конкретную орм и ее релизацию. Поэтому ваши коментарии, звучат как «ходи конем» при игре в преферанс.
                  • 0
                    > On duplicate key update Вам в помощь.
                    ну если вы приведете способ как это использовать в рамках фальконовской орм, то это можно будет считать помощью, а так это непонятно что…

                    >Исключения и ошибки — это одного поля ягоды. БД не бросит исключение — БД вернет ошибку, а бросит исключение Ваш код. Например, mysql_* не бросает исключений, а PDO бросает — суть не меняется.

                    вы, реально, сравниваете мягкое и теплое. Что там на уровне бд просходит, при описании бизнес логики, мне не особо важно.
                    В коде ошибки и ексепшены — это РАЗНОГО ПОЛЯ ЯГОДЫ. Ошибки — это уровень бизнес логики(орм говорит что значение в поле недопистимо), эксепшены — ошибки более низкого уровня(транзакция не прошла). Если есть возможность избежать ексепшена, то лучше это сделать, т.к. вещать бизнес логику на обработку ексепшена, не очень хорошо, всетаки их задумывали, чтоб дать возможность программисту сохранить логи и завершить приложение.

                    >1. Я вас не учу.
                    2. Комментирование создано, как раз, для обсуждения.
                    3. На мой взгляд, Вы описали «плохие» подходы. И кто-то может научиться у Вас «плохому».
                    4. Вы можете оказаться правы и, в таком случае, чему-то научусь я.

                    моя притензия была не к коментарию, а к формулировке.
                    Поставьте уникальный индекс и обрабатывайте исключение, возникающее при вставке дубликата.

                    Если бы вы разбавили ваше предложение фразами типа:
                    возможно вам поможет
                    ,
                    попробуйте
                    ,
                    может быть вас устроит данное решение
                    .

                    >Having без group by — не имеет смысла, и разрешен, если я не ошибаюсь, только в MySQL — в остальных БД Вы получите ошибку.

                    возможно это поддержывается не во всех бд. Но это поддерживают Mysql и Postgresql, а это самые популярные бесплатные бд.
    • +2
      Работаем с Phalcon больше года, проблем и сожалений о выборе нет, запущено несколько боевых проектов с разного рода нагрузкой и сложностью. Готов ответить на любые вопросы и оказать поддержку в специальной Phalcon-группе вконтакте: vk.com/phalconphp
      • 0
        неужеле и ORM и шаблонизатор используете и никаких проблем?
        • 0
          Volt стали использовать лишь последние полгода, проблем нет. С ORM вообще с самого начала нормально всё, пару раз научишь ся формировать правильно отношения и запросы — дальше уже совсем легко.
          • 0
            >Volt стали использовать лишь последние полгода, проблем нет.

            compileAlways если включить, то приложение падает с segmentation fail.
            A если шаблон не найден, то просто падает без каких либо ошибок, как при exit(0).

            >С ORM вообще с самого начала нормально всё, пару раз научишь ся формировать правильно отношения и запросы — дальше уже совсем легко.

            когда делаеш джоины нужно вставлять пробелы
            одну модель можно приджоинить только один раз
            отсутствие такой штуки как Zend\Db\Expr, как следстие все, что не понимет орм, вызывает ексепшн.
            having работает только если задан group
            валидация в моделях не отключаема и рекурсивна, если в какой-то связи есть ошибка, данные не сохранятся.

            вот, из того, что сразу вспомнилось.
            • 0
              Issue для всех описанных проблем с описанием созданы?
              • 0
                >Issue для всех описанных проблем с описанием созданы?

                Очень неожиданый вопрос от человека, который больше года работает с данным кодом.

                Вот еще вспомнил, что по-умолчанию орм делает full update, на каждый вызов метода save делается апдейт всех полей в независимости от того были ли изменения.
                Можно включить dynamic update но он кривой. При создании модели данные сохраняются в snapshotData и при сейве делается ипдаейт на измененные поля, но snapshotData инициализируется не всегда и кроме того snapshotData не обновляется после сейва, тоесть последующие сейвы работают не правильно.
                • 0
                  Вопрос про issue был к тому, что их довольно оперативно исправляют, про compileAlways помню проблема была несколько месяцев назад, но было исправлено. Остальные такие проблемы за время работы и вправду не попадались, так вот получилось.
            • 0
              having работает только если задан group

              Какой смысл в having без group?
              • –3
                >Какой смысл в having без group?

                какой смысл в красном без короткого? это две абсолютно разные вещи

                having нужен, для того, чтобы отфильтровать выборку по условиям, которые не определены на момент, когда выполняется where.
            • 0
              отсутствие такой штуки как Zend\Db\Expr, как следстие все, что не понимет орм, вызывает ексепшн

              docs.phalconphp.com/en/latest/api/Phalcon_Db_RawValue.html
              • 0
                >This class allows to insert/update raw data without quoting or formating
                есть подозрение, что QueryBuilder не схавает, но если схавает, то возьму свои слова назад.
              • 0
                как я и думал, queryBuilder'у фиолетово на этот RawValue

                timestampdiff(HOUR, from_date,to_date) Column 'HOUR' doesn't belong to any of the selected models (1)
            • 0
              одну модель можно приджоинить только один раз

              ORLY
              С использованием алиасов я лично джойнил одну и ту же модель многократно. Или имеется в виду невозможность иметь объекты одного типа в результате?
              • 0
                использование class_alias для джоинов это костыль, Или вы костыли приравниваете к функционалу фреймверка?
                • 0
                  имелось в виду указывание алиасов таблиц при джойнах. Или просто дважды одну модель не заджойнить (мол идет проверка по имени класса)?
                  • 0
                    Или просто дважды одну модель не заджойнить (мол идет проверка по имени класса)?

                    да, проверка по имени класса
    • 0
      За два месяца практически перевели на Фалкон 1 большой проект и написали проект чуть поменьше. Да, были трудности, но в целом и скорость разработки и скорость работы радуют. Разработчики после первого зенда очень рады.
      Плюс я один свой личный мини сайт перепиливаю с зенда на Фалкон. Единственное, к чему есть претензии — это механизм миграций. Тут пока приходится иметь костыли.
      • 0
        ок, Success Story засчитан.

        Если не секрет, с какого фремверка переписывали? фалькон 1,2?

        У меня после первого зенда и второй симфони, вызывает не однозначные чувства. Да, на нем можно быстро стартовать чтото, за счет очень простой MVC. Но баги лезут от куда их ждешь меньше всего. Небольшие ченджи оборачиваются костылями, которые каждый разработчик решает по своему, за отведенное время, врезультате проект обростает костылями со всех сторон.
        • +2
          Переписывали с первого зенда.

          Особых багов сейчас не заметил. Пробовал Фалкон еще примерно на версии 0.6 — тогда да, было тяжело. Согласен — есть несколько неоднозначных штук (роутинг к примеру), но привыкнуть можно, а скорость и полнота фреймворка радуют.
          А то, что проект обрастает костылями, так эта ситуация, в принципе, нормальная — периодический рефакторинг неизбежен при использовании любого фреймворка
  • +2
    Вообще использую CodeIgniter, но результаты опроса подталкивают попробовать Yii, стоит ли тратить на него время?
    • +1
      посмотрите пример приложения и сами для себя решите. там в комплекте поставляется простенький бложик.
    • +4
      Не стоит
    • 0
      Почему нет? Как видите, это самый популярный фреймворк на территории бывшего СССР. Напрасным изучение точно не будет.
  • –3
    Мой любимый Yii в лидерах. Это радует :)
  • 0
    Даешь ZF2!
  • +6
    Опросы отлично показывают кто на чем пишет, а не предмет опроса =)
    И как минимум странно видеть Zend Framework 1 в опросе
    Самый развивающийся фреймворк 2013
  • +13
    Самый стабильный — это CodeIgniter. Каким был в начале года, таким и остался.
  • 0
    плюсую KO3 и CI
  • +1
    Phalcon
  • +7
    Ребята, чем вам так нравится Yii?(указывайте какого рода проекты вы на нем делаете)
    • +2
      Нравится простотой, гибкостью, производительностью, лёгкостью в переопределении всего и вся. Отличное коммьюнити, прекрасная документация, приятный код. Мои проекты на Yii/Yii2 — новостные сайты, блоги, CRM, сервисы автоматизации. Так что область применения весьма обширна.
      • –1
        Приходилось работать с Yii, мне показалось что слишком много там накручено всего, из-за чего гибкость очень страдает.
        • 0
          там все слишком завязано на наследовании и на базовых классах… простенькими декораторами некоторый функционал по сути вообще не реализовать… хотя в коде самого фреймворка ( во всяком случае для ветки 1,1) тайп хинтинга нету, так что можно впихнуть и декоратор, но зачастую приходится из нижних уровней копипастить код.
    • +1
      Нравится всем. Делали на нём всё: сайты, блоги, CMS, CRM, тревел-сервисы, API для мобильников, логистику, магазины и т.д.
      • 0
        Что насчет виджетов? Я много раз видел что шаблоны для Yii вообще не содержат HTML кода, все делается через виджеты. Даже слышал, что требуются специальные верстальщики которые знакомы с Yii.
        • 0
          это такой же вид истерии как плагины для jquery, когда любой пук делается через плагин. Хотя я к примеру отказался и от идущего в комплекте менеджера асетов, написал свой (конкатенация и аглификация скриптов и стилей, сжатие изображений, препроцессинг less, и последующая компрессия в gzip для статической раздачи nginx-ом). Правда я еще и twig использую обычно… в последнем проекте даже от стандартного механизма маршрутизации отказался ибо он слишком примитивный и не дает без кастылей добавить префиксы с параметрами для урлов, заменил на symfony/routing.
          • +1
            Вместо геморроев с ассетами на лету, не проще ли делать это с помощью phing?
            • 0
              А с чего вы взяли что они на лету генерятся? Под phing все и собирается сейчас.
              • 0
                Ааа… тогда пардон.
        • +3
          Что насчет виджетов? Я много раз видел что шаблоны для Yii вообще не содержат HTML кода, все делается через виджеты. Даже слышал, что требуются специальные верстальщики которые знакомы с Yii.

          Совать все в виджеты — сущее баловство. Yii ничего такого не требует.
  • +1
    Мой выбор это Yii — быстро, красиво, и на достойном уровне все.

    Конечно, лучшее ООП в Symfony — но тормоза сводят красоту на нет.
    • +3
      Тормоза? Версия 2+ с вами не согласится.
    • +4
      Первое правило клуба разработчиков на Yii — расскажи всем про клуб разработчиков на Yii.
  • –3
    Почему Джумлы нет? У нее вроде есть какой-то фреймворк
    • +2
      Так и у друпала и у битрикса есть. Но зачем?)
      • 0
        Я бы его выбрал :). Ну да, такой вот я мазохист, нравится она мне.
        • 0
          А там есть полноценный фремворк, подобный упомянутым в голосовании? Я просто не знаком с устройством этой CMS.
          • 0
            Только собирались выпускать, была новость некоторое время назад.
          • 0
            Есть. Подробнее тут
  • +2
    Yii можно было разделить на 1/2 (как Zend).
    • 0
      зачем? yii 2 еще не вышел, и в продакшене не рекомендован.
      • +1
        Но при этом отлично там работает :)
        • 0
          ну как бы чему там не работать? вопрос в том что до релиза еще далеко, и до тех пор интерфейс классов и т.д. могут поменяться.
  • +2
    А популярность Zend Framework все падает и падает.
    Легковесные и простые в освоении фреймворки вытесняют монстрообразные фреймворки.
    • 0
      Symfony2 с вами не согласен. Всего то нужна удобная модульность системы.
      • 0
        Laravel основан на компонентах symfony, так же как и silex. Кучи cms-ок (в том числе Drupal) так же сейчас пишут на основе хотя бы HttpKernel и используют composer. Профит модульности в том что можно менять модули, добавлять свои, легко собирать фреймворки под свои нужды… не понятно почему минусуют.
  • 0
    Еще было бы интересно добавить в опрос, какие фичи фрейворков наиболее важны для разработчиков. Например ORM, генераторы форм, шаблонизаторы и т.п.
  • 0
    Выбор — Symfony 2. (Для мелких проектов — свой)

    С Yii работал всего на 1 проекте — не понравился. А именно: стиль кода, логика, документация. Не понимаю, что в нем нашли. Ок, 2-3 года назад выбор был бы понятен, а сейчас — нет.

    Интересно:
    — Какие плюшки вы в нем нашли?
    — Чем он лучше по сравнению с той же Симфони?
    • +2
      — Чем он лучше по сравнению с той же Симфони?
      Невысоким порогом вхождения?
      Sf2 нужно изучить, прежде чем разработка на нём станет эффективнее разработки на других фреймворках. Периодически наблюдаю людей, которые решили освоить Symfony2 в процессе работы над коммерческим продуктом — потом они либо учатся на ошибках, либо плюются желчью, обвиняя фреймворк в своих неудачах.
      • 0
        Ну а я видел как люди не знающие yii год фигачили проекты и были довольны… Как по мне лучше заставить человека месяц поизучать инструмент, прежде чем использовать. И да, если уж на коммерческом проекте и изучать, то в команде должен быть кто-то кто уже знаком с фреймворком.
        • 0
          Ну а я видел как люди не знающие yii год фигачили проекты и были довольны…
          Кажется, я мысль не совсем уловил. Если все довольны — это ведь замечательно.
          В краткосрочной перспективе может оказаться выгоднее разработать продукт подручными средствами, чем тратить время на создание лиги выдающихся джентльменов.
          • 0
            ключевое в вашей фразе — краткосрочная перспектива. Проекты развиваются, заказчики иногда присылают списки изменений… У меня сейчас на поддержке один проектик только остался на yii, который начинали еще на версии 1.0, к нему приложило руку с десяток разработчиков, и… скажем так… там такое раздолье для рефакторинга… Причем иногда такие перлы находятся. В итоге вроде бы и проект простой (интернет магазинчик со своей спецификой), но в итоге некоторые проблемы как раз таки изза ограничений фреймворка. (и да, во второй ветке часть этих ограничений уже пофиксили, специально смотрел).
            • 0
              Да, всё верно. Я невнимательно прочитал предыдущее сообщение — и теперь тема разговора уходит в сторону.
  • +1
    90% Проектов можно написать без особых проблем как на любом из Фреймворков так и на ЦМС. Тут больше всего влияет 1 момент:
    — На сколько хорошо знаешь инструмент на котором пишешь?

    • 0
      ну и еще стоимость поддержки решения, предсказуемый цикл разработки и поддержки самого фреймворка/cms, количество разработчиков которые «знают инструмент на котором пишут»… Для личных проектов разницы нету, но вот для коммерческих я сразу же использовать первое попавшееся/самое популярное решение не буду.
  • 0
    Tfw самый стабильный и самый развивающийся один и тот же. inb4 одно не отменяет другого — отменяет. Напоминает шаблон «молодая, быстро развивающаяся фирма.
  • +4
    Самый бесмысленный опрос 2013
    Наверняка никто из тех кто голосовал — не в курсе аспектов развития всех перечисленных фреймворков, в итоге каждый ставит галочку напротив своего любимого фрэймворка.
    • 0
      Не судите за всех, пожалуйста, да и не судимы будете.
      • 0
        Вы не согласны что большинство будет голосовать за свой любимый фреймворк?
        • 0
          Согласен. Но

          никто из тех кто голосовал
          !==
          большинство
          • 0
            используйте ==
            иногда нестрогое сравнение лучше :)
  • +1
    мимо
  • 0
    Рад что PHPixie собирает голоса =)
    Видимо мои статьи здесь принесли плоды ^__^
    • +5
      Без Ваших статей о нем бы и не знал =)
  • +5
    Все 3 опроса можно было бы объединить в 1: «Ваш любимый фреймворк»
    • 0
      Надеялся на адекватность отвечающих, получил по морде реальностью.
      • +5
        Ну вот на хабре много хвалят Yii, но я взглянул на код примера и по мне это полный треш из мешанины статических методов в кривом code style. Symfony по мне на порядок продуманней и как ни странно проще, если разобраться всего в двух вещах: что такое контейнер объектов и как работать с событиями. Достаточно изучить 1 презентацию и ты будешь знать симфони на 90%. Для Symfony немеренно бандлов, это самый популярный php-репозиторий на гитхабе, это самое мощное комьюнити.

        Но люди голосуют за то, что они используют, т. к. «тим лид сказал», «на хабре прочитал», «старые проекты на нем» и т. п.
        • +2
          Посмотрите лучше код Yii2. Стиль там более человечный. Похож на тот же PSR-2.

          Про комьюнити не согласен. Попробуйте задать глупый вопрос на форумах Symfony и Yii. На форумах Yii вам расскажут почему это неправильно и дадут наставления. На форумах Symfony расскажут какой вы никчёмный программист и что надо учить паттерны и контейнеры.
          • +5
            На форумах Symfony расскажут какой вы никчёмный программист и что надо учить паттерны и контейнеры.
            А вы знаете, как раздражают люди, которые позавчера купили книжку «Учим PHP5 за 6 часов», схватили Sf и задают глупые вопросы, хотя могли бы потратить чуть больше времени — и таких вопросов просто не возникло бы.

            Да, и кстати, форумы Yii — далеко не предел мечтаний, хотя вам явно так не кажется. Чего стоят посты про сравнение Kohana и других фреймворков — с кучей разных небылиц (со стороны всех лагерей, надо сказать). А если брать вообще мое ощущение от форумов указанных фреймворков, то ситуация примерно такая:
            • Yii-форумы: толпа фанбоев… даже когда вопрос касается не фреймворка, а простого php, итогом поста все равно будет «Yii — утипути, сладенький».
            • Sf-форумы: даже если нужно просто вывести три символа на страницу, все сойдутся на мысли, что надо присобачить энное количество интерфейсов, абстрактных классов и прочего, плюс пройдет пара холиваров с возможным включением в беседу людей, давно уже не пишущих на php (а возможно и вообще никогда не писавших).
            • Kohana-форумы: хладнокровное безразличие. Поначалу возможна попытка участия в той или иной проблеме, быстро сходящая на нет. Хотя иной раз не обходится и без истерик «ааа мне срочно надо, а почему мне никто не может помочь!!!»


            Прошу не обижаться на такую вот картину мира.

            К чести Yii, кстати, замечу: большинство постов про сравнение Kohana и Yii там более-менее адекватны. Проскакивают, конечно, какие-то инопланетяне, у которых Yii работает на «живом проекте» в сотни тысяч раз быстрее (тут сарказм), но в целом, оценка правильная. Kohana более опрятна с более вялым комъюнити.
            • +1
              Нормальная картина форумного мира, похожа, в общем-то :)

              Предела мечтаний нет, нам тоже есть к чему стремиться и мы будем. Сейчас форумы Yii, по крайней мере, живые и приветливые. Новых членов сообщества принимают, а не отталкивают, что идёт всем на пользу. Новички через какое-то вырастают и помогают следующей волне.

              Что до фанбоев, они есть в любом крупном сообществе, будь то фреймворк или, например, варезник.
        • +1
          Насчет Yii coding styles полностью согласен. Мне вообще странно наблюдать такую мешанину, при этом код вида
          if($error=Yii::app()->errorHandler->error)
          в моих глазах вообще слился. Честное слово, я не заметил знака равно, т.к. привык, что в большинстве (если не сказать во всех) стандартах кодирования, которые мне встречались, было принято отбивать знак равенства (сравнения) пробелами. Здесь же…
          • 0
            Да да, всё это поправили в стиле 2.0. У нас половина команды тоже страдала, пока не привыкли :)
            • 0
              И теперь они страдают, когда НЕ кодят для Yii? ))
              • 0
                Да не, стиль 1.1 приучил просто писать в том же стиле, что принят в проекте и не отвлекаться на холивары.
  • –3
    Популярность Yii предсказуема, хороший фреймворк, во время выстреливший и занявший свою нишу.

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

    Мой же выбор, чудом не Yii, ему я в своё время предпочёл Kohana, по одной простой причине — лёгкость входа с нуля, для самообучения и обучения основ веб-разработке других. Пусть они сами же оттолкнули от себя большинство фанатов отсутствием обратной совместимости, но сама идеология у них мне по душе.
    Yii тоже прост, но по опыту вышло, что с пол пинка в голове у людей он не укладывается, и я в данном случае бы назвал его скорее промышленным, профессиональным фреймворком.
    • 0
      Что такое «порог вхождения»? И там, и там php, везде примерно одно и то же.

      Yii — это неприкрытый хайп, зачастую просто незаслуженный. На виджеты и примочки от сообщества подчас без слез нельзя и взглянуть. У Kohana же есть некоторые проблемы с примочками. Тут два варианта — либо пишешь эти примочки для себя сам (интеграция визуального редактора, файлового браузера или миграций, например), либо используешь то, что дадут на форуме. Я выбрал первое. И в принципе — доволен. Даже не знаю, что лучше — отсутствие библиотек от сообщества или куча библиотек разной степени отмороженности (хотя наверное есть и достойные).
      • +1
        Что такое «порог вхождения»? И там, и там php, везде примерно одно и то же.

        Ну, в Symfony 2 высок порог вхождения по сравнению даже с 1.x. Особенно если хочется писать по фэн-шую, а не чтобы работало. Тут и сервис-ориентированная архитектура, и DataMapper вместо привычного многим ActiveRecord, и мощный DI, и мало функциональности «из коробки», и не простая для схватывания на лету система бандлов.
        • +3
          Ну да, как только речь зашла про любимый Yii, полетела моя карма в тар тарары.

          Если мы говорим о пороге вхождения в фреймворк — это одно, если мы пытаемся сразу оседлать и php, и фреймворк — тут уже совсем другое. Человек, мало-мальски знакомый с тем, зачем нужны фреймворки (и с языком в первую очередь), сможет «войти» в любой фреймворк. Было бы желание.

          По поводу DI и прочего — как по мне, так это сделано для упрощения жизни разработчикам проекта, а не для завышения порога вхождения.

          Но прошу прощения, когда сравнивают, какой порог вхождения в Yii или Kohana, честное слово — смех берет. Ни там, ни там нету ничего такого, что могло бы вызвать сложности. Оба фреймворка простые, как три копейки.
          • 0
            Про карму не ко мне. Я если и минусую её, то по этическим причинам.

            Сможет-то он сможет, но для sf ему понадобится больше времени.

            Да, как многие инструменты, они упрощают жизнь, но и требуют времени на освоение.

          • 0
            Совершенно согласен именно с данным комментарием.
            Лишь выразил своё мнение.

            Yii простой, но отсутствие в kohana тех же генераторов даёт возможность человеку «с нуля» въехать на более глубоком понимании кода.
            Yii потому и популярен, что все велосипеды изобретены и обкатаны, но как понять их работу новичку?

            Кстати kohanaframework.org попала под раздачу блокировок.
  • +1
    Возможно я ошибаюсь но мне кажется сложность вхождения в ФФ обусловлено плохим или слабыми знаниями — ООП, MVC и т. д.
    ЗЫ: Зачастую за выбором фремворка скрываться много факторов(не только предпочтение разработчика).
    • 0
      сложность вхождения в ФФ обусловлено плохим или слабыми знаниями — ООП, MVC и т. д.
      Вовсе не факт. Сложность вхождения в этом отношении у популярных фреймворков плюс-минус одинакова. У сложности, имхо, два основных фактора: простота создания типовых приложений и простота внесения изменений для нетиповой функциональности, как на фронтенде (сложные контролы, виджеты, темы и т. п), так и на на бэкенде.
      • +1
        А также документация, примеры, сообщество.
        • 0
          Это я включаю в «простота» :)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.