Опрос. Какой php-фреймворк вы используете?

    Давно не делали опрос о популярности php-фреймворков. Это, конечно, не волшебный мир JavaScript, где всё меняется каждые полгода-год, но всё-таки и в php тоже постоянно идут изменения.

    Выпускаются новые версии, что-то устаревает, что-то входит в моду и т.д. Один фреймворк более «компонентный» и лучше следует принципам SOLID, другой удобен для быстрого старта, третий имеет хорошее комьюнити.

    Итак, опрос для тех, кто использует php в своей практике.
    Какой php-фреймворк вы используете? (pet-проекты не в счет. Только то, за что вы получаете деньги!)
    • 30%Laravel794
    • 21%Symfony544
    • 34%Yii889
    • 5%Codeigniter134
    • 7%Zend194
    • 5%Phalcon141
    • 3%Slim70
    • 3%Silex77
    • 6%Другой (укажу в комментариях)171
    • 16%Не использую фреймворки437
    На каком фреймворке вы бы начали следующий проект?
    • 35%Laravel890
    • 22%Symfony556
    • 22%Yii556
    • 1%Codeigniter27
    • 2%Zend48
    • 4%Phalcon93
    • 1%Slim25
    • 1%Silex24
    • 3%Другой (укажу в комментариях)86
    • 9%Без фреймворка224

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

    Метки:
    Поделиться публикацией
    Комментарии 255
    • +1
      Еще можно добавить к списку (если можно отредактировать) PHPixie.
      • +1
        Уже нельзя, к сожалению
        • +3
          Плюсую за phpixie, использую везде его. И буду.

          PS: раньше вроде можно было менять опрос?
          • +1
            Какое краткое резюме про phpixie можете сказать? Я просто смотрел в его сторону, но никак не могу слезть с Silex'а
            • +1
              Просто, отзывчиво, легко. Я не уверен что моей компетенции достаточно, чтобы оценивать фреймворки. Зенд, симфони и ларавель мне не зашли.
              • +1
                Зенд, симфони и ларавель мне не зашли.

                почему? что отпугнуло?

                • 0
                  Слишком нагромождено. Я раньше не пользовался фреймворками, с MVC познакомился на примере RoR, потом попробовал пхп-фреймворки. Было непонятно.
    • –5
      Symfony, Laravel, Vuejs
      • +28

        Vuejs — отличный php фреймворк

        • –7
          Вы такой остроумный, видимо уронили в детстве?
    • +2
      Кмк, не совсем корректно микрофреймворки типа Slim держать в одном списке с теми же Laravel, Yii. Все-таки у них немного разные ниши.
      • +2
        Возможно, вы правы. Но все-таки они в некоторой степени конкурируют друг с другом.
        В любом случае, лучше не усложнять опрос, а то люди будут лениться заполнять.
    • +2
      На данный момент у нас cakephp в основном используется
      • +22

        Сочувствую. Держитесь там.

        • 0
          Да, ладно. Ещё первый CakePHP был в работе в сравнении с CMS`ками просто манной небесной.
        • +1

          Сейчас используем 3 версию. От остальных не отстает, работает хорошо

      • +3
        Сейчас CakePHP вроде нормальный, косит под Laravel немного)))
        Раньше конечно был адским немного… Наверное неплохо постарались над улучшением, да и над дизайном они явно постарались)))
        • 0
          У нас версия 2.X, его новым не назовать, заказчик очень консервативен и переписывание проекта не одобряет) Проект долгоиграющий, так что приходится мирится)
    • 0
      у нас еще проекты на своем фреймворке остались, портируем на ларавель
    • 0
      а кто-нибудь вообще использовал Aura целиком или отдельные компоненты?
      • 0
        Я использовал компонент i18n с Aura.
    • +1
      Я использую Phalcon, Yii2. Для длительного проекта выбрал бы Yii2 из-за скорости разработки, а для простого, или с усиленной безопасностью — то выбрал бы Phalcon, чтобы всё руками сделать
    • 0
      Использую Nova Framework, кто нибудь использовал его вообще?
      • 0
        Почитал документацию, не покидает ощущение слизанности с Laravel. Многие моменты вообще идентичны. И как вам в целом данный фреймворк?
        • 0
          Я посмотрел, там есть компоненты от Laravel. Мне показалось от него многое унаследовано. Простой, можно дополнять. Примеров маловато, есть видео уроки от самого создателя. Ну, а так в целом я использую не нагруженном проекте.
      • 0
        Ну по первому обзору нормальный… Довольно сильно напоминает Laravel)
    • –7
      А вот на каком фреймворке например написан Вконтакте, Гугл, Ютуб, Яндекс, тот же Хабр? Мне кажется ни на каком.
      Я тут конечно не эксперт, практического опыта именно работы с фреймворками нет. Но зато есть обширный опыт программинга на С++. Пытался изучать фреймворки по книгам и видеоурокам, в результате пришел к выводу что фигня все это, огромное количество лишних абстракций которые ничего не решают вообще а только создают дополнительные прослойки и сложности.
      Может быть это полезно для тех кто штампует небольшие сайты на заказ и важнее всего скорость. А для реальных высоконагруженных проектов вообще целесообразнее написать прототип на одном из веб-языков (php, python...), а затем переходить на тот же С++ или что-то компилируемое, чтобы не занимать процессор выполнением кода интерпретатора, а память — хранением динамически типизированных объектов.
      • +8
        Я конечно тот еще быдлокодер, тоже не люблю фреймворки, но, когда пришлось работать в команде из 20+ разработчиков, местным аналогом тимлида, мне пришлось очень быстро склепать свой фреймворк на базе того говнокода что уже был написан годы назад, а затем 7 лет переписывать его не ломая обратную совместимость, просто по тому что командная разработка разительно отличается от одиночных проектов. Теперь да, это уже полноценный внутренний фреймворк, с весьма хорошей архитектурой целиком удовлетворяющий требования уже не первого заказчика и документированная на 150 листах мануала (не считая комментариев кода), но когда грянул гром — это была мешанина из своих мыслей, в которых черт ногу сломит и новичкам трудно было даже написать простой модуль — слишком большой объем кода нужно было перелопатить чтобы вникнуть в суть.
        Еслиб начинал сейчас, начал-бы свой проект на Yii, но тогда его еще и в помине не было.
        • 0
          свой «фреймворк» == не использую фреймворк
          • 0
            Закрытый фреймворк != не использую фреймворк. Данная система используется в десятке корпоративных веб-приложений и активно развивается усилием до 40 разработчиков. То что он не выложен на гитхаб — ну уж простите, я как создатель имею право выбирать какое ПО делать.
            • +1
              Хм, но глупо считать, что те, кто проголосовал за последний вариант копошаться в дерьме из вермишели и палок. :)
              • 0
                Черт его знает. Много что повидал за эти года.

                А для тех кто хочет проголосовать за свой фреймворк, есть удобный вариант «другой» и указать его в комментариях. Понятное дело что охватить голосованием все не вариант.
              • 0

                знаете, если мне предлагают проект на суппорт, я по умолчанию буду делать предположение что там лапша или лазанья. Это никак не зависит от того на чем проект делался. Зависит только эффорты на рефакторинг.

                • –1
                  Хм, то есть и на фреймворках (публичных мейнстримовых) пишут вермишель?
                  (Я как бы этого не отрицаю, просто уточняю :) )

                  Тогда не плевать ли, используется мейнстримовый фреймворк или самопись?
                  • +2
                    Не плевать. В проект на знакомом фреймворке быстрее вникнешь и сможешь что-то сделать для заказчика.
                    • 0
                      А что вообще нужно от фреймворка?
                      Работа с базой и кеш? (Это 90+% разработки)

                      Я вот быстро вник в незнакомый фреймворк. :)
                      В мои 50 кБ кода вникать не долго.

                      Или Вы фрилансер?
                      Ну тут да.
                  • +2
                    пишут вермишель?

                    конечно.


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

                    ну одно дело когда у вас вермещель размазанная по крепкому каркасу (иногда там размазана лазанья и это хуже немного) и другое дело когда крепкого каркаса нет и все просто смесь из вермишели.

                    • 0
                      А у меня не вермишель на самописи.
                      Возможно, кому-то и нужен фреймворк и батог для дисциплинирования, мне нет :)
                      Хотя, без понимания, все равно будет вермишель :)

                      Довелось встречать лазанью на фреймворках:
                      • html код выводился через echo 'some long html code'
                      • Модели наследовали ActiveRecord, но при этом его не использовали, а дергали какую-то самописную фигню, при этом в этой фигне не было конструктора запросов, каждый запрос писался вручную.
                      • +1
                        А у меня не вермишель на самописи.

                        выложите на github, сделаем ревью.


                        Довелось встречать лазанью

                        вы видимо не поняли что есть "лазанья-код". Это когда разработчики начали делать слоеную архитектуру (не mvc, это один слой где m на границе другого) и для внесения любых изменений приходится "прорезать" все слои нашей лазаньи.


                        Фреймворки — это один слой. Он не может быть лазаньей по определению. Далее уже все зависит от того как разработчик работает с фреймворком.


                        html код выводился через echo 'some long html code'

                        интересно в каких таких фреймворках вы это видели. Вы про чушь аля CHtml из yii? ну может быть. Или вы про скомпилированные шаблоны twig? Ну так там в этом и суть.


                        Модели наследовали ActiveRecord, но при этом его не использовали, а дергали какую-то самописную фигню

                        ActiveRecord — это как подразумевает название — работа с одной записью. Скорее всего "в самописной фигне" разработчики попытались реализовать что-то типа dao но судить о плохости могу только видя код.

                        • –1
                          выложите на github, сделаем ревью.

                          Лазаньи у меня нет.
                          Но есть другие причины:
                          http://blog.kpitv.net/article/когда-будет-публичный-релиз-ядра-15373/

                          И для внесения любых изменений приходится «прорезать» все слои нашей лазаньи

                          И такое было.
                          Я просто не знал как подробнее описать.
                          Реально, проще назвать лазанья :)

                          интересно в каких таких фреймворках вы это видели.

                          Yii.
                          Но вряд ли это только он виноват.
                          Скорее тупость писавших. :)
                          • +1

                            Ваше «ноу-хау» никому не нужно, кроме вас, это же очевидно. При этом вы боитесь, что вас закидают помидорами, ибо давно бы уже выложили свои «50 Кб» в общий доступ.

                            • –3
                              Ну, если никому не нужно, то зачем его и выкладывать? :)
                              Хотя постоянно просят выложить.

                              Я не хочу, чтобы свиньи не оценили бисер.

                              Ну и оно не презентабельно пока. :)
                          • 0
                            Но есть другие причины:

                            напомню что часть исходников таки у вас вытекла. И да похвастать там было нечем. А что до "ноу хау" — скорее "хау абаут ноу"


                            Yii.

                            я не воспринимаю Yii как серьезный фреймворк. Не в обиду людям которые его юзают. Что там с Yii2 понятия не имею — не слежу уже лет 7 за ним.

                            • 0
                              напомню что часть исходников таки у вас вытекла

                              То не ядро было :)
                              Да и там ничего плохого не было :)

                              П.С.
                              Кстати, статья обновлена. :)
                            • +3
                              Не воспринимаю Yii как серьезный фреймворк с тех пор как осознал, что у них все встроенные вещи построены на обязательных паблик полях. В лучшем случае на protected, в случае с AR. Вкупе со статикой люди начинают делать из этого АД. во второй версии все то же самое.
      • +6

        Очень многие большие и сложные проекты написаны на фреймворках (Рельсы, Джанго, Лара и Симфони) вполне легко найти инфу. Полемика нужны ли фреймворки гудел лет 4-5 назад. И фреймворки победили.

        • –3
          Миллионы мух не могут ошибаться :)
          • 0

            Оставьте эту пошлую риторику. Не хотите фреймворки? Так я вам их не продаю.

            • –1
              При чем пошлая?
              При чем риторика?

              Вы сказали, что была полемика и была победа. :)
              Я же усомнился в ваших словах. :)

              Я у вас ничего и не покупаю.
              • +4
                Вот только усомнились вы в правильности решения использовать фреймворки, приведя как аргумент их популярность.
                Как единственный аргумент это действительно выглядит пошло.
                • –3
                  • +6
                    Недостатки выбраны превосходные. Чего стоят только
                    1. Плохая документация
                    2. Не самое логичное формирование путей для файлов
                    3. Дибильная работа с БД
                    4. При выпуске новых версий как правило отсутствует обратная совместимость
                    5. Неудобно создавать статические страницы
                    6. Нету возможности выполнить другой контроллер

                    И теперь главное. Эти недостатки автор приписывает ВСЕМ фреймворкам. У меня это взорвало мозг.

                    Сложилось впечатление что автор работал с yii 1. Но назвал это всеми фреймворками. Что удивляет еще больше так это дата этой статьи 2016 год. Автор критикует yii 1 который вышел в 2008 (!) году.
                    Также судя по разделу работы с базой данных автор не разобрался как правильно делать join. Но это не помешало ему найти сообщение на форме с корявым использованием и критиковать это =)
                    • –7
                      1. Она действительно плохая.
                      Расчитана на дебилов.
                      2. Ну да, там точки, там /, там \, я в этом не смог найти логику :)
                      Там включается название «модуля», там нет.
                      3. Если есть дибильный простой способ, то он и будет использоваться.
                      Законы Мерфи.
                      Ну и об этом советуют на форуме фреймворка.
                      Ну и то обсуждение вроде ж не 2008 года.
                      Ну и это значит, что фреймворки не святые, а эволюционирует.
                      Но так само может эволюционировать и самопись.
                      4. Ну да.
                      Программисты на фреймворках никогда не останутся без работы.

                      5. А разве удобно?
                      6. А разве обойтись одним «контроллером» нормально?
                      Выходит потом огород из костылей.

                      Yii 1.1 вышел в 2008 году?
                      Yii 1.1.17 афаир вышел в 2016 году.

                      Ну, то есть, Вы хоть какие-то контраргументы нашли только для п. 3.

                      Эти недостатки автор приписывает ВСЕМ фреймворкам.

                      Читай внимательно:
                      Как сказано выше, это не значит, что пункт не подходит к другим фреймворкам.
                  • 0
                    Разрази меня гром!
                    Вы свое абсолютное невежество в знаниях фреймворков (да похоже и архитектуры проектов в целом) вылили в бессмысленную статью совершенно оторванную от реальности.

                    Спрячьте(-сь). Не позорьтесь. Не надо так.
                    • +2

                      Так это уже его 3ая (если не ошибаюсь) реинкарнация на Хабре. И он всё время в комментах эту статью пихает)

                      • 0

                        Видимо поэтому и ник http3 :)

                      • +1
                        Долго думал, при чем тут зая… Оказалось, что это третья :)
                  • +2
                    О, вы новый аккаунт завели. А старый вместе с комментариями удалили?
                  • +1
                    Откуда столько упорства в донесении своих мыслей до людей, которые сливом вашей кармы до -50 из раза в раз показывают, что вас тут слушать не хотят? Это кстати какой ваш клон по счёту?
                    • –5
                      Та мне плевать на карму :)
                      • +1
                        Да я не это спрашивал. Упорство откуда? Где источник ваших нескончаемых сил? Что поддерживает вас в вашей борьбе в плевках против ветра?
                        • 0
                          Может в том, что вы меня не слышите? :)

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

                          Против чего же я выступаю?
                          Против утверждения (явного или не явного), что фреймворк подходит всем и для решения всех задач.
                          Против утверждения, что все те, кто не использует фреймворк, те лохи, а использует — д'Артаньяны.
                          Я так же само выступаю против дрочки на ООП.
                          Против хайпа на Реакт / Ангуляр.

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

                          Похожая точка зрения дана тут относительно использования наследования / композиции:
                          https://habrahabr.ru/post/325478/

                          Ну и все же следует признать, что аудитория чуток потупела все же.
                          Ну и у аудитории плоховато с юмором.
                          Хз как они отнесутся к комменту, оставленному для прикола.

                          Но вот сторонника фреймворков обвинили чуть ли не в поддержке моей позиции :):

                          Получу ли я адекватный ответ на этот коммент? :)
                          Вряд ли. :)

                          П.С.
                          Перечитал еще раз Ваш ответ.
                          Вы как бы и сами констатировали, что меня не хотят слышать :)
                          Но я не говорю, чтобы меня слушались.
                          Аудитория глухая? :)
                          • 0
                            Против утверждения (явного или не явного), что фреймворк подходит всем и для решения всех задач.

                            кто-то где-то подобное утверджает?


                            Я так же само выступаю против дрочки на ООП.

                            смотря что считать ООП. Если вы про идею тотальной инкапсуляции и late binding то это одно. А если паттерны, расширение за счет наследования и AbtractFactoryFactory — это совершенно другое. Первое это развитие идей структурного программирования, а второе это рак.

                            • 0
                              кто-то где-то подобное утверджает?

                              Ну вот в этой ветке.
                              Но в соседней теме Вы дали самописи 0,1%, и на том спасибо. :)

                              паттерны, расширение за счет наследования и AbtractFactoryFactory

                              Это.

                              Паттерны я бы выделил отдельно в паттерны головного мозга, паттерны наше все. :)
                              • 0
                                Но в соседней теме Вы дали самописи 0,1%, и на том спасибо. :)

                                На сегодняшний день в 50% случаев и бэкэнд свой писать не надо. не то что фреймворки свои писать.


                                Паттерны я бы выделил отдельно в паттерны головного мозга, паттерны наше все. :)

                                обычно с паттернами разработчики переживают три стадии:


                                • паттерны это круто, они делают код лучше
                                • паттерны отстой, они делают код сложнее
                                • о, так выходит надо знать когда чего юзать...

                                Все это больше от непоследовательного изучения и культ карго.

                      • 0
                        Соблюдайте правила производственной гигиены!
                        • –7
                          Та тут большинство оленей :)
                          Я первый не плевал…
                  • –3
                    Вдруг что, статья значительно переработана и улучшена. :)
              • 0
                Я же усомнился в ваших словах. :)

                я так и не понял вашей позиции. Вы против именно full-stack фреймворков с готовый структурой но не против отдельных компонентов с помощью которых можно сделать свой фреймворк под задачу. Или вы вообще против любых third-party решений?

                • –2
                  Я не против сторонних решений вообще :)

                  И я не против full-stack фреймворков вообще.
                  Просто имеющиеся переусложнены.

                  Правда, я не особо ковырялся с минифреймворками вроде Silex/Slim.
                  Они считаются full-stack или нет?
                  • –1
                    Просто имеющиеся переусложнены.

                    потому что они хэндлят штуки о которых вы не думаете? Это не переусложнение. Ну и да, не надо сравнивать с решениями вроде yii, там действительно все плохо и да это субъективная оценка.


                    Они считаются full-stack или нет?

                    да, они проще. Они хороши когда вам нужно что-то простое сделать. Например read-only часть приложения или чего еще.

                    • –1
                      потому что они хэндлят штуки о которых вы не думаете?

                      Да.
                      Я хочу понимать всю подноготную работы приложухи.
                      С самописью я понимаю. :)

                      yii, там действительно все плохо

                      Его критикуют за более монолитность. Мне это не особо важно.

                      Но разве что-то мешает использовать сторонний код в нем?
                      Те же компоненты от Симфони? :)

                      Моя самопись, если честно, тоже местами монолитна.
                      Это как бы не совсем гибко, но эта гибкость и не нужна пока в тех местах. :)

                      Они хороши когда вам нужно что-то простое сделать.

                      Все вещи желательно делать простыми, а не сложными. :)
                      • +1
                        С самописью я понимаю. :)

                        А другие разработчики которые будут поддерживать после вас? Им же тоже придется разбираться и для них будет тоже самое что и любой другой фреймворк.


                        Я хочу понимать всю подноготную работы приложухи.

                        Вы изучали как работает Zend VM? Ибо по вашей логике для комфортной работы вам и этот уровень абстракции надо залесть. Ну и ниже, как вообще работает выполнение машинного кода, как операционная система изолирует память для процессов, как разруливает приоритизацию процессов, контекст свитчинг и т.д.


                        Но разве что-то мешает использовать сторонний код в нем?

                        Есть нюансы. Многие вещи там тупо нельзя заменить не перелопатив половину всего.


                        Все вещи желательно делать простыми, а не сложными. :)

                        KISS и все такое? Обычно в качестве примера предлагают историю из 60-х когда главный инженер потребовал спроектировать сверхзвуковой истребитель который пилот может починить обычными инструментами в поле.


                        Другими словами вещи должны быть простыми в использовании и обслуживании, но это не означает что внутри все будет просто и уж тем более сделать так бывает крайне сложно. Можете просто почитать про трудности которые пришлось решать когда делали usb type-c. Его легко юзать, но там были интересные задачи.

                        • –4
                          А другие разработчики которые будут поддерживать после вас?

                          Почему я не использую в личных проектах PHP фреймворки

                          Им же тоже придется разбираться и для них будет тоже самое что и любой другой фреймворк

                          Там всего 50 килобайт :)

                          Ибо по вашей логике для комфортной работы вам и этот уровень абстракции надо залесть.

                          На этот не нужно.
                          Только *.php код. То, с чем я работаю.

                          сделать так бывает крайне сложно

                          Просто сделать сложно.
                          Сложно сделать просто.
                          :)
                          • 0

                            Иная простота...

      • +1
        Когда надо в кратчайшие сроки запустить проект чтобы начал приносить деньги, особо нет времени заниматься велосипедо-строением дабы избежать фатального недостатка.
      • 0
        Позвольте слегка не согласиться.
        Да, фреймворки содержат огромное количество абстракций, но никто не заставляет использовать все возможности конкретного фреймворка. Пишите свой, более быстрый код, который не «создаёт дополнительные прослойки и сложности». Вот только зачастую, чтобы добиться такой же гибкости и стабильности, придется написать как бы не более сложную и запутанную структуру. Всё же код фреймворков оптимизируется постоянно.

        Что касается интерпретатора — нагрузка на процессор значительно снижается путем использования того же OPCache, благодаря сохранению однажды использованных структур и данных в памяти. Очень приближенно можно сказать, что в результате процессор будет выполнять только полезную работу, не повторяя раз за разом те же расчеты.
      • –3
        Вы правы.

        Ну кроме переписывания на С++.
      • 0
        Кроме всего перечисленного, задам вопрос, а какой процент разработчиков пишет крутые проекты типа Гугла, Вконтакта или Фейсбука?
        С нуля писать конечно очень увлекательно, но пока вы это делаете, конкурент уже забацает двадцать штук интернет магазинов на одном из перечисленных фреймворков.
        • –2
          А сколько времени писались
          Гугла, Вконтакта или Фейсбука

          ? :)
          Годами, что ли? :)
          • 0
            До сих пор пишутся )).
            Кроме того, это не совсем стандартные проекты, плюс работают под дикой нагрузкой.
            • –3
              Ооо, они до сих пор не написаны?
              Откуда Вы о них узнали тогда? :)
              • 0
                Вообще то код этих проектов постоянно правят. Вот что я имел в виду.
                Как, собственно, и большинство остальных проектов ).
                • –4
                  А на фреймворке раз написал и править не нужно? :)
                  • 0

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


                    Если без фреймворка мы будем делать ровно то же самое только сами и в своем. И тут не надо много ума что бы понимать что это не так эффективно.

                    • –3
                      Возвращаемся назад.

                      Гугл писался годами? :)
                      Повторное использование кода в самописи тоже запрещено? :)
                      • +1
                        Вы наивно полагаете, что гугл написан один раз и сейчас он в своём первозданном виде?
                        Сегодняшний гугл писался годами и пишется прямо сейчас.
                        • –4
                          гугл написан один раз и сейчас он в своём первозданном виде?

                          Где я такое писал?

                          Сегодняшний гугл писался годами и пишется прямо сейчас.

                          Где я это отрицал?
                          • –4
                            В основном у комментов по одному минусу.
                            Это один имбицил тупо минусует мои комменты? :)
                            • –1
                              А, сорри, 4 имбицила. :)
                      • 0
                        Гугл писался годами? :)

                        инкрементами и по чуть чуть уже десятилетиями. Что до "использует ли гугл фреймворки" — точно использовали django лет так 8 назад, используют разные ангуляры и и т.д. До этого тоже были продукты от них. И до этого…


                        Повторное использование кода в самописи тоже запрещено? :)

                        Код нельзя реюзать. Если вы видите в коде общие вещи вы должны выделить из этого абстракцию и вот уже абстракции реюзать можно.

                        • –3
                          инкрементами и по чуть чуть уже десятилетиями

                          А самопись не может так же писаться? :)

                          точно использовали django лет так 8 назад

                          Ого.
                          Ангуляр — это js и их же разработка…

                          Код нельзя реюзать. Если вы видите в коде общие вещи вы должны выделить из этого абстракцию и вот уже абстракции реюзать можно.

                          Что за ерунда?
          • 0
            Годами, что ли? :)

            Ну какбы да. В целом если разработчики больше не коммитит код в проект то велика вероятность что проект мертв. А значит если вашему продукту лет 10 и более то его продолжают писать.

        • +2
          интернет не ограничен одними интернет-магазинами. Фреймворки хороши когда a. ты их знаешь b. ты занимаешься чем-то относительно стандартным и это стандартное ложится на логику фреймворка.
          Шаг в сторону от мейнстрима — и добро пожаловать в клуб велосипедостроителей! Только я не понимаю когда говорят от построении «с нуля». Нет никакого нуля, просто переходим на более низкий уровень — берем либы и компонуем. Нормальный такой процесс, почему нет.
          • 0
            ты занимаешься чем-то относительно стандартным

            аля "пишу http-based апы?" В любом нестандартном проекте есть "стандартные" части. Вроде "а как логи писат" или "а как хэндлить master/slave коннекшены к базе" или "а как зависимостями управлять в проекте". И в итоге мы берем любой фреймворк, возможно выкидываем отдельные компоненты и живем.

            • 0
              >В любом нестандартном проекте есть «стандартные» части. Вроде «а как логи писат» или «а как хэндлить master/slave коннекшены к базе» или «а как зависимостями управлять в проекте».

              Вы меня простите великодушно если я заблуждаюсь, но все же вынужден спросить — Вы разницу между фреймворком и либой понимаете?
      • +1
        Вы разумно рассуждаете. Наводите хорошие примеры. А вот вывод не корректный.
        Действительно если вы пишете гигантский сервис при разработке которого участвуют сотни человек. И работа идет годами. Тогда важность использования фреймворка опускается до 0. Вот только с этого утверждения вы делаете (не корректный) вывод что сфера применения фреймворков — маленькие сайты. Yahoo! и BlaBlaCar используют symfony. 2gis.ru использует yii.
        «Маленькими сайтами» назвать их язык не повернется.

        Ваше желание использовать C++ при веб разработке понятно. Ведь это ваш основной язык (с ваших слов). И его действительно в некоторых случаях стоит применять. Но в подавляющем большинстве случаев использование C++ как базового языка для веб приложения сродни самоубийству. Слишком увеличивается скорость и сложность разработки и поддержки такого проекта. Мы живем не в вакууме и это нельзя спускать со счетов. А вот самые высоконагруженные места можно и на C++ написать. В угоду скорости.
    • +2
      По второму вопросу воздержался, фреймворк нужно выбирать по ситуации.
    • 0
      Есть свой ADR масштабируемый микро-фреймворк.
      На работе модифицированный ZF1.

      Давно присматриваюсь к PHPixie.
      • 0
        свой ADR масштабируемый микро-фреймворк.

        Вот вы юзаете ADR. Расскажите как. Правильно ли я понимаю что ADR у вас сводится к тому что формирование респонсов и запросы на чтение вынесены в респондеры? Бывает ли так что "экшен" занимается лишь инвоуком респондера? У вас апишки или сервер плюется html-ем (что бы примерно прикинуть что внутри респондера). Ну и в целом какие ограничения вы накладываете на эту троицу? Чего там быть например не должно, какие взаимоотношения и уровень знаний у action к resonder и т.д.

    • +2
      Использую уже два года Nette чешский. Быстро разворачивается, есть composer библиотеки.
      • 0
        Вы его сами выбрали или досталось по наследству? У меня после 3 месяцев работы очень негативное к нему отношение.
        • 0
          Выбрал сам, подкупил документацией и легкостью. А в чем причина негативного отношения?
          • 0
            Тем что он MVP и очень мало где используется. Но это чисто субъективное мнение.
            Я с ним имел дело года 3 назад и не с нуля.
            • +2
              Тем что он MVP

              давайте разбираться в разнице между mvp и mvc:



              То есть сугубо говоря mvc в трактовке php фреймворков ничем не отличается от mvp.

    • +3
      В основном Symfony + DDD/CQRS/CommanBus/ApiDoc.
    • +6
      За многие годы использования фреймворков, а были у меня в продакшне и известные, такие как Symfony, Yii, Laravel, так и свои, пришел к выводу, что монолитные фреймворки как бы не особо нужны, а иногда, как Yii, и вредны (да-да, я про $breadcrumbs в контроллере!)

      В результате сейчас имею десяток своих слабосвязанных библиотек для разных случаев жизни, написанных в одном стиле и общий для них MVC-каркас (если вдруг он нужен).

      Всё это активно используется как в собственных проектах, так и профессионально (за деньги), развивается и адаптируется под новые версии PHP. Заодно на тех же библиотеках студенты у меня учатся участвовать в командной разработке, использовать TDD и вообще прикасаются немного к «взрослому» программированию в плане огранизации своего труда.

      Планирую этому хозяйству однажды дать звучное имя и выложить в публичный доступ, как очередной мега-фреймворк-убийца-всех-остальных :)) Но врожденная скромность и вечная прокрастинация всё как-то мешают…

      Резюмируя: хорошего фреймворка на PHP еще нет, у всех какие-то свои скелеты под капотами, но что-то мне подсказывает, что сообщество к нему уже готово. И, значит, он скоро появится.
      • +7
        Symfony можно использовать как набор слабосвязанных библиотек, не обязательно тянуть весь
        • +2
          Чем он выгодно и отличается от других актуальных фреймворков.
          • 0
            Собственно, вы с Zend'ом знакомы? Там куча отдельных компонентов на все случаи жизни
            • +1
              Собственно да.
              Но всё равно берусь утверждать, что это сильно связанный фреймворк. Несмотря на наличие компонентов на все случаи жизни.
              Одно другое не исключает.
          • +1
            Сейчас все актуальные фреймворки перешли на компонентный подход.
            • +4

              Правильней говорить:


              Сейчас все актуальные фреймворки перешли на компонентны Symfony)))
              • 0
                Значит не за горами появление чего-то нового. Не может Symfony быть вечным.
                • +1

                  Согласен. Было бы интересно посмотреть на что-то лучше Symfony)))

          • 0
            на базе компонентов symfony можно свой фреймворк сделать, сам когда то делал. ну и laravel так сделан.
    • 0
      Laravel. Т.к. он наиболее популярный (или один из). До того использовал Kohana, но позже решил, что эта мнимая легкость и простота гораздо менее важны, чем возможность располагать гигантской кодовой базой. К примеру, в Kohana не было толком даже миграций, mptt-модуль пришлось писать самому. Ужасно. Сейчас с этим гораздо проще.
    • –20
      Последний раз ковырялся в вашем ПеХаПе наверное в 2004 году.
      И тогда ООП только только начинал внедряться, пятая версия тогда вышла.
      Сейчас вижу седьмая вышла.
      До чего прогресс дошел, ваш ПеХаПе показывают и тут и там

      • +7
        Держите нас в курсе.
      • 0
        Ваше мнение очень важно для нас, пожалуйста, оставайтесь на линии :)
        • –13
          Извините, в последнее время меня тянет на чистый С и ASM.
          Крис немного заразил меня Реверс инженерингом.
          Но я упорно сопротивляюсь этому.
          • +7

            А я веган

          • 0

            попробуйте rust.

      • +2
        При всей моей нелюбви к PHP — вы держите, пожалуйста, в курсе. Это очень важно.

        Update: пока писал комментарий — уже за меня выше ответили. :3
        • 0

          Я б сказал, «вы держитесь там, счастья вам, здоровья» :)

          • +3
            И хорошего вам настроения, да. Денег нет, но вы дебажьте.
    • 0
      Zend это не только Zend Framework но и микрофреймворк Zend Expressive. Но, судя по опросу, все равно не в тренде :)
    • +9
      Хочется Laravel, Symfony, Yii, Phalcon, Zend… а на практике — Битрикс и NoNameShitFramework
      • +1
        по-моему zend со второй версией очень долго жевал сопли и его обскакала «Symfony-based коалиция» и начала продвигать свой путь на рынке, из-за чего zend просел еще сильнее.
        • 0
          Не исключено, что ZF3 позаимствовал компонентный подход у Symfony, но это же не делает его менее привлекательным, правда?
          В конце концов, даже не особо популярный в России ZF3 иногда сделан куда лучше своих 'битриксовых' аналогов.
          • 0
            ой, извиняюсь, я оказывается веткой промахнулся :)
            Мое сообщение должно быть чуть выше к комментарию Sora
      • 0
        Буквально вчера видел тему на форуме пхпклаб, как один человек хотел внедрить Laravel в Битрикс, так как ему не хватало доступного функционала админки битрикса))
        Лично я сам уже переборол себя и потихоньку с Битрикса перехожу на Лару (по крайней мере перевожу свои проекты). Надоело вариться в этом котле безрассудства и похоти)
        • 0
          В прошлом году подобное выступление было

        • 0
          внедрить Laravel в Битрикс, так как ему не хватало доступного функционала админки битрикса

          Упс. :)
          Скрещивание ежа с ужом :)
          Админка нормально кастомизируется стандартными средствами.
          Можно добавлять пользовательские типы данных.
    • 0
      Laravel и Kohana 3.2
    • 0

      Spiral, внутренняя разработка, используем последние 5 лет.

    • 0
      OpenCart
    • 0
      magento cms
    • +3
      Перешел с Symfony на Silex, как ни странно. Из Silex по сути используется роутинг и контейнер, остальное либо добивается компонентами той же Симфонии, либо самописными компонентами.
      • 0

        А как же MicroKernelTrait? С появлением оного у silex-а вообще не осталось смысла в существовании. Его и сделали исключительно как пример как можно собрать по быстрому фреймворк на компонентах симфони.

        • 0
          Честно сказать, не слышал и не пробовал. Возможно когда я ставил Силекс, его еще просто небыло.

          Он и так «микро». Работает шустро, все что мне нужно предоставляет — что еще нужно то? :)
      • 0

        А чем плох контейнер от Symfony? Вопрос без сарказма

        • 0

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

          • 0
            Нет двойной диспатчеризации

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


            нет ленивого автовайринга

            Что есть "ленивый" автовайринг? В любом случае что-то похожее есть в 3.3 через setters/getters injection.


            фриз после билда

            мы уже обсуждали это, для test энвайрмента доступен ContainerBuilder со всеми возможностями для замены сервисов в рантайме.


            нет контекстуального биндинга

            скоро будут.

            • 0
              Что есть "ленивый" автовайринг? В любом случае что-то похожее есть в 3.3 через setters/getters injection.

              Тот, который не надо объявлять, оно само находит декларации. Ну я просто хз как ещё назвать такую штуку (которой можно что-нибудь когда-нибудь себе отстрелить) =)


              мы уже обсуждали это, для test энвайрмента доступен ContainerBuilder со всеми возможностями для замены сервисов в рантайме.

              А я ещё раз повторюсь, припекло мне вот Request засунуть в контейнер, чтобы он нормально приходил в методы контроллера из контейнера и в любом сервисе можно было получить. И всё тут. А ещё чтобы по интерфейсу Authenticatable мне прилетала энтити юзера. А ещё хочется писать что-то такое, чтобы и репозиторий автоматом подсовывался и сервис пагинации для одного экшенеа был только в этом экшене:


              public function someAction(
                  RequestInerface $request, 
                  UsersRepositoryInterface $repo, 
                  PaginatoInterface $paginator
              ): JsonResponse
              {
              
                  return $paginator->from($repo)->paginateRequest($request);
              }

              А вот нельзя в симфони. Всё в сервисы и строй лапшу в контроллерах, а я против лапши. Вот и получаются тучи сервисов для сервисов для фектори, который возвращает фектори. Или методы контроллеров в сотню строк.


              скоро будут.

              Знаю, уже снизу отписался: https://habrahabr.ru/post/325234/#comment_10148430

              • 0
                Тот, который не надо объявлять, оно само находит декларации.

                то если "ленивый" не в плане как оно работает в рантайме а "ленивый" в плане что ничего делать не надо? Ну нет, настолько опасных вещей в симфони не будет. Для ленивых там есть defaults для сервисов с 3.3 версии которые решают эти проблемы.


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

                Этим ты сделаешь свои сервисы stateful и отслеживать это будет просто ад. Request вообще входящие данные, им не место в контейнере. Ну либо опять же тогда на каждый реквест надо делать свой контейнер который вытягивает вещи из основного зафриженого. Это позволит сделать много прикольных вещей.


                Authenticatable мне прилетала энтити юзера.

                У меня это не сущность (не люблю юзеров по контроллерам размазывать), а просто какой-то объект. Ну и пишется он у меня в атрибуты запроса. И в целом это очень и очень удобно.


                А ещё хочется писать что-то такое, чтобы и репозиторий автоматом подсовывался и сервис пагинации

                Я пихаю туда кусочек entity manager который для query builder-ов и query. Ну мол у меня за операции чтения отдельные штуки отвечают, репозитории должны возвращать одну и только одну сущность. И никогда не null и не массив сущностей. Возможно это излишние загоны, но так контроля больше и возможностей.


                К примеру я сейчас эксперементирую с кастомными гидраторами для доктрины и с ними можно делать очень много интересного. В частности мне все больше нравится идея не пускать сущности на view и использовать штуки вроде модифицированных array hydrator и т.д. или мэпить на dto сразу из dql.

                • 0
                  то если "ленивый" не в плане как оно работает в рантайме а "ленивый" в плане что ничего делать не надо? Ну нет, настолько опасных вещей в симфони не будет. Для ленивых там есть defaults для сервисов с 3.3 версии которые решают эти проблемы.

                  Конечно не будет, по-этому вместо таких штук:


                  $container->factory(FactoryItem::class, ['a' => 23]);
                  $container->factory(FactoryItem::class, ['b' => 42]);

                  Приходится писать отдельный фектори, внутри которого придётся руками проставлять все аргументы из контейнера через сервис локацию (потому что симфонийский контейнер, вспоминаем, фризится).


                  Ну и т.д. Все ниже приведённые тобою отговорки имеют право на жизнь, более того — это вполне грамотные решения проблем. Только этих проблем в Laravel не возникает — отличие в этом.


                  <irony>
                  А давай вспомним бандлы? Моя любимая часть симфони. Начнётся всё с построения дерева конфигов. Примерно там же и будет похоронен юный падаван. "Зато никаких ошибок в конфигах" — говорили они =)
                  </irony>

                  • 0
                    Начнётся всё с построения дерева конфигов. Примерно там же и будет похоронен юный падаван. «Зато никаких ошибок в конфигах» — говорили они =)

                    а мне в ларе этого иногда не хватает, особенно если кто-нибудь альтернативно одаренный без чтения документации будет писать в конфигах какую-то дичь (строки вместо чисел например). Или снесет пакет, а конфиги останутся. Или при клонировании репозитория — в ларе сам читай readme и ищи какие параметры в .env нужно прописать если никто не прописал в .env.example то что нужно. А симфони сгенерит при установке пакетов parametest.yml с дефолтными значениями где останется прописать свои параметры для окружения