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

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

Итак, опрос для тех, кто использует php в своей практике.
Какой php-фреймворк вы используете? (pet-проекты не в счет. Только то, за что вы получаете деньги!)

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

На каком фреймворке вы бы начали следующий проект?

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

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

Поделиться с друзьями
-->

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


  1. Tomio
    30.03.2017 09:30
    +1

    Еще можно добавить к списку (если можно отредактировать) PHPixie.


    1. varanio
      30.03.2017 09:31
      +1

      Уже нельзя, к сожалению


      1. Voiddancer
        30.03.2017 10:33
        +3

        Плюсую за phpixie, использую везде его. И буду.

        PS: раньше вроде можно было менять опрос?


        1. Nengchak
          30.03.2017 14:47
          +1

          Какое краткое резюме про phpixie можете сказать? Я просто смотрел в его сторону, но никак не могу слезть с Silex'а


          1. Voiddancer
            30.03.2017 15:54
            +1

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


            1. Fesor
              31.03.2017 08:58
              +1

              Зенд, симфони и ларавель мне не зашли.

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


              1. Voiddancer
                01.04.2017 04:44

                Слишком нагромождено. Я раньше не пользовался фреймворками, с MVC познакомился на примере RoR, потом попробовал пхп-фреймворки. Было непонятно.


  1. Fractalzombie
    30.03.2017 09:42
    -5

    Symfony, Laravel, Vuejs


    1. witka
      30.03.2017 15:59
      +28

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


      1. Fractalzombie
        03.04.2017 03:18
        -7

        Вы такой остроумный, видимо уронили в детстве?


  1. redfs
    30.03.2017 09:49
    +2

    Кмк, не совсем корректно микрофреймворки типа Slim держать в одном списке с теми же Laravel, Yii. Все-таки у них немного разные ниши.


    1. varanio
      30.03.2017 09:52
      +2

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


  1. DeadikGudwin
    30.03.2017 09:53
    +2

    На данный момент у нас cakephp в основном используется


    1. ellrion
      30.03.2017 09:56
      +22

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


      1. gnomeby
        30.03.2017 19:03

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


      1. jhonyxakep
        31.03.2017 11:20
        +1

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


    1. malinichev
      30.03.2017 10:05
      +3

      Сейчас CakePHP вроде нормальный, косит под Laravel немного)))
      Раньше конечно был адским немного… Наверное неплохо постарались над улучшением, да и над дизайном они явно постарались)))


      1. DeadikGudwin
        30.03.2017 15:15

        У нас версия 2.X, его новым не назовать, заказчик очень консервативен и переписывание проекта не одобряет) Проект долгоиграющий, так что приходится мирится)


  1. efreeze
    30.03.2017 10:06

    у нас еще проекты на своем фреймворке остались, портируем на ларавель


  1. MetaDone
    30.03.2017 10:08

    а кто-нибудь вообще использовал Aura целиком или отдельные компоненты?


    1. DezzmonD
      30.03.2017 11:08

      Я использовал компонент i18n с Aura.


  1. malinichev
    30.03.2017 10:15
    +1

    Я использую Phalcon, Yii2. Для длительного проекта выбрал бы Yii2 из-за скорости разработки, а для простого, или с усиленной безопасностью — то выбрал бы Phalcon, чтобы всё руками сделать


  1. jtiq
    30.03.2017 10:22

    Использую Nova Framework, кто нибудь использовал его вообще?


    1. Sky4eg
      30.03.2017 11:19

      Почитал документацию, не покидает ощущение слизанности с Laravel. Многие моменты вообще идентичны. И как вам в целом данный фреймворк?


      1. jtiq
        30.03.2017 18:59

        Я посмотрел, там есть компоненты от Laravel. Мне показалось от него многое унаследовано. Простой, можно дополнять. Примеров маловато, есть видео уроки от самого создателя. Ну, а так в целом я использую не нагруженном проекте.


    1. malinichev
      30.03.2017 11:24

      Ну по первому обзору нормальный… Довольно сильно напоминает Laravel)


  1. NeoCode
    30.03.2017 10:45
    -7

    А вот на каком фреймворке например написан Вконтакте, Гугл, Ютуб, Яндекс, тот же Хабр? Мне кажется ни на каком.
    Я тут конечно не эксперт, практического опыта именно работы с фреймворками нет. Но зато есть обширный опыт программинга на С++. Пытался изучать фреймворки по книгам и видеоурокам, в результате пришел к выводу что фигня все это, огромное количество лишних абстракций которые ничего не решают вообще а только создают дополнительные прослойки и сложности.
    Может быть это полезно для тех кто штампует небольшие сайты на заказ и важнее всего скорость. А для реальных высоконагруженных проектов вообще целесообразнее написать прототип на одном из веб-языков (php, python...), а затем переходить на тот же С++ или что-то компилируемое, чтобы не занимать процессор выполнением кода интерпретатора, а память — хранением динамически типизированных объектов.


    1. daggert
      30.03.2017 10:57
      +8

      Я конечно тот еще быдлокодер, тоже не люблю фреймворки, но, когда пришлось работать в команде из 20+ разработчиков, местным аналогом тимлида, мне пришлось очень быстро склепать свой фреймворк на базе того говнокода что уже был написан годы назад, а затем 7 лет переписывать его не ломая обратную совместимость, просто по тому что командная разработка разительно отличается от одиночных проектов. Теперь да, это уже полноценный внутренний фреймворк, с весьма хорошей архитектурой целиком удовлетворяющий требования уже не первого заказчика и документированная на 150 листах мануала (не считая комментариев кода), но когда грянул гром — это была мешанина из своих мыслей, в которых черт ногу сломит и новичкам трудно было даже написать простой модуль — слишком большой объем кода нужно было перелопатить чтобы вникнуть в суть.
      Еслиб начинал сейчас, начал-бы свой проект на Yii, но тогда его еще и в помине не было.


      1. http3
        30.03.2017 14:24

        свой «фреймворк» == не использую фреймворк


        1. daggert
          30.03.2017 14:57

          Закрытый фреймворк != не использую фреймворк. Данная система используется в десятке корпоративных веб-приложений и активно развивается усилием до 40 разработчиков. То что он не выложен на гитхаб — ну уж простите, я как создатель имею право выбирать какое ПО делать.


          1. http3
            30.03.2017 15:06
            +1

            Хм, но глупо считать, что те, кто проголосовал за последний вариант копошаться в дерьме из вермишели и палок. :)


            1. daggert
              30.03.2017 15:21

              Черт его знает. Много что повидал за эти года.

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


            1. Fesor
              31.03.2017 09:01

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


              1. http3
                31.03.2017 09:21
                -1

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

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


                1. NexOtaku
                  04.04.2017 20:57
                  +2

                  Не плевать. В проект на знакомом фреймворке быстрее вникнешь и сможешь что-то сделать для заказчика.


                  1. http3
                    05.04.2017 09:27

                    А что вообще нужно от фреймворка?
                    Работа с базой и кеш? (Это 90+% разработки)

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

                    Или Вы фрилансер?
                    Ну тут да.


                1. Fesor
                  04.04.2017 22:34
                  +2

                  пишут вермишель?

                  конечно.


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

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


                  1. http3
                    05.04.2017 10:37

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

                    Довелось встречать лазанью на фреймворках:

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


                    1. Fesor
                      05.04.2017 10:47
                      +1

                      А у меня не вермишель на самописи.

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


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

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


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


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

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


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

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


                      1. http3
                        05.04.2017 13:56
                        -1

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

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

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

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

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

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


                        1. franzose
                          05.04.2017 14:03
                          +1

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


                          1. http3
                            05.04.2017 15:29
                            -3

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

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

                            Ну и оно не презентабельно пока. :)


                        1. Fesor
                          05.04.2017 14:45

                          Но есть другие причины:

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


                          Yii.

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


                          1. http3
                            05.04.2017 16:47

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

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

                            П.С.
                            Кстати, статья обновлена. :)


                          1. pbatanov
                            06.04.2017 09:01
                            +3

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


    1. ellrion
      30.03.2017 11:07
      +6

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


      1. http3
        30.03.2017 16:24
        -3

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


        1. ellrion
          30.03.2017 16:34

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


          1. http3
            30.03.2017 16:40
            -1

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

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

            Я у вас ничего и не покупаю.


            1. taral
              30.03.2017 17:46
              +4

              Вот только усомнились вы в правильности решения использовать фреймворки, приведя как аргумент их популярность.
              Как единственный аргумент это действительно выглядит пошло.


              1. http3
                31.03.2017 09:36
                -3

                1. taral
                  31.03.2017 10:00
                  +6

                  Недостатки выбраны превосходные. Чего стоят только
                  1. Плохая документация
                  2. Не самое логичное формирование путей для файлов
                  3. Дибильная работа с БД
                  4. При выпуске новых версий как правило отсутствует обратная совместимость
                  5. Неудобно создавать статические страницы
                  6. Нету возможности выполнить другой контроллер

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

                  Сложилось впечатление что автор работал с yii 1. Но назвал это всеми фреймворками. Что удивляет еще больше так это дата этой статьи 2016 год. Автор критикует yii 1 который вышел в 2008 (!) году.
                  Также судя по разделу работы с базой данных автор не разобрался как правильно делать join. Но это не помешало ему найти сообщение на форме с корявым использованием и критиковать это =)


                  1. http3
                    31.03.2017 10:28
                    -7

                    1. Она действительно плохая.
                    Расчитана на дебилов.
                    2. Ну да, там точки, там /, там \, я в этом не смог найти логику :)
                    Там включается название «модуля», там нет.
                    3. Если есть дибильный простой способ, то он и будет использоваться.
                    Законы Мерфи.
                    Ну и об этом советуют на форуме фреймворка.
                    Ну и то обсуждение вроде ж не 2008 года.
                    Ну и это значит, что фреймворки не святые, а эволюционирует.
                    Но так само может эволюционировать и самопись.
                    4. Ну да.

                    Программисты на фреймворках никогда не останутся без работы.

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

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

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

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

                    Читай внимательно:
                    Как сказано выше, это не значит, что пункт не подходит к другим фреймворкам.


                1. pudovMaxim
                  31.03.2017 11:21

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

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


                  1. ellrion
                    31.03.2017 11:39
                    +2

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


                    1. franzose
                      31.03.2017 14:20

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


                    1. codemax
                      04.04.2017 20:57
                      +1

                      Долго думал, при чем тут зая… Оказалось, что это третья :)


                1. porn
                  31.03.2017 11:37
                  +2

                  О, вы новый аккаунт завели. А старый вместе с комментариями удалили?


                1. sumanai
                  31.03.2017 16:36
                  +1

                  Откуда столько упорства в донесении своих мыслей до людей, которые сливом вашей кармы до -50 из раза в раз показывают, что вас тут слушать не хотят? Это кстати какой ваш клон по счёту?


                  1. http3
                    31.03.2017 16:54
                    -5

                    Та мне плевать на карму :)


                    1. sumanai
                      31.03.2017 16:59
                      +1

                      Да я не это спрашивал. Упорство откуда? Где источник ваших нескончаемых сил? Что поддерживает вас в вашей борьбе в плевках против ветра?


                      1. http3
                        03.04.2017 14:59

                        Может в том, что вы меня не слышите? :)

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

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

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

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

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

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

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

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


                        1. Fesor
                          03.04.2017 17:42

                          Против утверждения (явного или не явного), что фреймворк подходит всем и для решения всех задач.

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


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

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


                          1. http3
                            04.04.2017 09:42

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

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

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

                            Это.

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


                            1. Fesor
                              04.04.2017 12:28

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

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


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

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


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

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


                    1. alsii
                      31.03.2017 16:59

                      Соблюдайте правила производственной гигиены!


                      1. http3
                        01.04.2017 01:00
                        -7

                        Та тут большинство оленей :)
                        Я первый не плевал…


            1. Fesor
              31.03.2017 09:04

              Я же усомнился в ваших словах. :)

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


              1. http3
                31.03.2017 09:27
                -2

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

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

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


                1. Fesor
                  31.03.2017 10:15
                  -1

                  Просто имеющиеся переусложнены.

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


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

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


                  1. http3
                    31.03.2017 10:34
                    -1

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

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

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

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

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

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

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

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


                    1. Fesor
                      31.03.2017 11:04
                      +1

                      С самописью я понимаю. :)

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


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

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


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

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


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

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


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


                      1. http3
                        31.03.2017 14:08
                        -4

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

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

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

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

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

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

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

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


                        1. alsii
                          31.03.2017 16:51

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


    1. Djeux
      30.03.2017 11:30
      +1

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


    1. greatkir
      30.03.2017 11:43

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

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


    1. http3
      30.03.2017 13:52
      -3

      Вы правы.

      Ну кроме переписывания на С++.


    1. UnknownUser
      30.03.2017 14:02

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


      1. http3
        30.03.2017 15:14
        -2

        А сколько времени писались

        Гугла, Вконтакта или Фейсбука

        ? :)
        Годами, что ли? :)


        1. UnknownUser
          30.03.2017 20:35

          До сих пор пишутся )).
          Кроме того, это не совсем стандартные проекты, плюс работают под дикой нагрузкой.


          1. http3
            31.03.2017 09:42
            -3

            Ооо, они до сих пор не написаны?
            Откуда Вы о них узнали тогда? :)


            1. UnknownUser
              31.03.2017 10:52

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


              1. http3
                31.03.2017 11:53
                -4

                А на фреймворке раз написал и править не нужно? :)


                1. Fesor
                  31.03.2017 12:08

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


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


                  1. http3
                    31.03.2017 14:59
                    -3

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

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


                    1. porn
                      31.03.2017 16:50
                      +1

                      Вы наивно полагаете, что гугл написан один раз и сейчас он в своём первозданном виде?
                      Сегодняшний гугл писался годами и пишется прямо сейчас.


                      1. http3
                        31.03.2017 17:06
                        -4

                        гугл написан один раз и сейчас он в своём первозданном виде?

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

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

                        Где я это отрицал?


                        1. http3
                          02.04.2017 07:12
                          -4

                          В основном у комментов по одному минусу.
                          Это один имбицил тупо минусует мои комменты? :)


                          1. http3
                            02.04.2017 16:39
                            -1

                            А, сорри, 4 имбицила. :)


                    1. Fesor
                      31.03.2017 17:09

                      Гугл писался годами? :)

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


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

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


                      1. http3
                        31.03.2017 17:39
                        -3

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

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

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

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

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

                        Что за ерунда?


        1. Fesor
          31.03.2017 09:05

          Годами, что ли? :)

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


      1. gearbox
        30.03.2017 20:38
        +2

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


        1. Fesor
          31.03.2017 09:08

          ты занимаешься чем-то относительно стандартным

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


          1. gearbox
            31.03.2017 17:44

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

            Вы меня простите великодушно если я заблуждаюсь, но все же вынужден спросить — Вы разницу между фреймворком и либой понимаете?


    1. taral
      30.03.2017 18:07
      +1

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

      Ваше желание использовать C++ при веб разработке понятно. Ведь это ваш основной язык (с ваших слов). И его действительно в некоторых случаях стоит применять. Но в подавляющем большинстве случаев использование C++ как базового языка для веб приложения сродни самоубийству. Слишком увеличивается скорость и сложность разработки и поддержки такого проекта. Мы живем не в вакууме и это нельзя спускать со счетов. А вот самые высоконагруженные места можно и на C++ написать. В угоду скорости.


  1. Graid
    30.03.2017 10:59
    +2

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


  1. Pinsky
    30.03.2017 11:02

    Есть свой ADR масштабируемый микро-фреймворк.
    На работе модифицированный ZF1.

    Давно присматриваюсь к PHPixie.


    1. Fesor
      31.03.2017 09:11

      свой ADR масштабируемый микро-фреймворк.

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


  1. IvanSCM
    30.03.2017 11:05
    +2

    Использую уже два года Nette чешский. Быстро разворачивается, есть composer библиотеки.


    1. Nord001
      30.03.2017 12:17

      Вы его сами выбрали или досталось по наследству? У меня после 3 месяцев работы очень негативное к нему отношение.


      1. IvanSCM
        30.03.2017 15:38

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


        1. Nord001
          30.03.2017 15:44

          Тем что он MVP и очень мало где используется. Но это чисто субъективное мнение.
          Я с ним имел дело года 3 назад и не с нуля.


          1. Fesor
            31.03.2017 09:23
            +2

            Тем что он MVP

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



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


  1. sayber
    30.03.2017 11:15
    +3

    В основном Symfony + DDD/CQRS/CommanBus/ApiDoc.


  1. AlexLeonov
    30.03.2017 11:39
    +6

    За многие годы использования фреймворков, а были у меня в продакшне и известные, такие как Symfony, Yii, Laravel, так и свои, пришел к выводу, что монолитные фреймворки как бы не особо нужны, а иногда, как Yii, и вредны (да-да, я про $breadcrumbs в контроллере!)

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

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

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

    Резюмируя: хорошего фреймворка на PHP еще нет, у всех какие-то свои скелеты под капотами, но что-то мне подсказывает, что сообщество к нему уже готово. И, значит, он скоро появится.


    1. varanio
      30.03.2017 11:42
      +7

      Symfony можно использовать как набор слабосвязанных библиотек, не обязательно тянуть весь


      1. AlexLeonov
        30.03.2017 12:22
        +2

        Чем он выгодно и отличается от других актуальных фреймворков.


        1. Serganbus
          30.03.2017 13:18

          Собственно, вы с Zend'ом знакомы? Там куча отдельных компонентов на все случаи жизни


          1. AlexLeonov
            30.03.2017 13:50
            +1

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


        1. sumanai
          30.03.2017 17:18
          +1

          Сейчас все актуальные фреймворки перешли на компонентный подход.


          1. ghost404
            30.03.2017 20:40
            +4

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


            Сейчас все актуальные фреймворки перешли на компонентны Symfony)))


            1. AlexLeonov
              30.03.2017 21:46

              Значит не за горами появление чего-то нового. Не может Symfony быть вечным.


              1. ghost404
                30.03.2017 22:43
                +1

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


        1. riky
          30.03.2017 17:21

          на базе компонентов symfony можно свой фреймворк сделать, сам когда то делал. ну и laravel так сделан.


  1. Alexeyco
    30.03.2017 11:51

    Laravel. Т.к. он наиболее популярный (или один из). До того использовал Kohana, но позже решил, что эта мнимая легкость и простота гораздо менее важны, чем возможность располагать гигантской кодовой базой. К примеру, в Kohana не было толком даже миграций, mptt-модуль пришлось писать самому. Ужасно. Сейчас с этим гораздо проще.


  1. alexoron
    30.03.2017 11:54
    -20

    Последний раз ковырялся в вашем ПеХаПе наверное в 2004 году.
    И тогда ООП только только начинал внедряться, пятая версия тогда вышла.
    Сейчас вижу седьмая вышла.

    До чего прогресс дошел, ваш ПеХаПе показывают и тут и там


    1. vlreshet
      30.03.2017 12:20
      +7

      Держите нас в курсе.


    1. Merkat0r
      30.03.2017 12:21

      Ваше мнение очень важно для нас, пожалуйста, оставайтесь на линии :)


      1. alexoron
        30.03.2017 12:54
        -13

        Извините, в последнее время меня тянет на чистый С и ASM.
        Крис немного заразил меня Реверс инженерингом.
        Но я упорно сопротивляюсь этому.


        1. SlyChan
          30.03.2017 20:08
          +7

          А я веган


        1. Fesor
          31.03.2017 09:29

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


    1. YaakovTooth
      30.03.2017 13:08
      +2

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

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


      1. franzose
        30.03.2017 14:35

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


        1. YaakovTooth
          30.03.2017 14:36
          +3

          И хорошего вам настроения, да. Денег нет, но вы дебажьте.


  1. Sora
    30.03.2017 12:02

    Zend это не только Zend Framework но и микрофреймворк Zend Expressive. Но, судя по опросу, все равно не в тренде :)


  1. gromdron
    30.03.2017 12:12
    +9

    Хочется Laravel, Symfony, Yii, Phalcon, Zend… а на практике — Битрикс и NoNameShitFramework


    1. pudovMaxim
      30.03.2017 12:24
      +1

      по-моему zend со второй версией очень долго жевал сопли и его обскакала «Symfony-based коалиция» и начала продвигать свой путь на рынке, из-за чего zend просел еще сильнее.


      1. gromdron
        30.03.2017 13:09

        Не исключено, что ZF3 позаимствовал компонентный подход у Symfony, но это же не делает его менее привлекательным, правда?
        В конце концов, даже не особо популярный в России ZF3 иногда сделан куда лучше своих 'битриксовых' аналогов.


        1. pudovMaxim
          30.03.2017 19:53

          ой, извиняюсь, я оказывается веткой промахнулся :)
          Мое сообщение должно быть чуть выше к комментарию Sora


    1. Tomio
      31.03.2017 10:33

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


      1. porn
        31.03.2017 11:37

        В прошлом году подобное выступление было


      1. http3
        31.03.2017 13:58

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

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


  1. Nord001
    30.03.2017 12:16

    Laravel и Kohana 3.2


  1. Lachezis
    30.03.2017 12:28

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


  1. n000b
    30.03.2017 12:42

    OpenCart


  1. kot_kot9
    30.03.2017 13:06

    magento cms


  1. Akuma
    30.03.2017 13:07
    +3

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


    1. Fesor
      31.03.2017 09:31

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


      1. Akuma
        31.03.2017 11:56

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

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


    1. alsii
      31.03.2017 17:07

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


      1. SerafimArts
        31.03.2017 23:53

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


        1. Fesor
          01.04.2017 09:11

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

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


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

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


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

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


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

          скоро будут.


          1. SerafimArts
            01.04.2017 09:22

            Что есть "ленивый" автовайринг? В любом случае что-то похожее есть в 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


            1. Fesor
              01.04.2017 09:32

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

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


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

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


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

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


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

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


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


              1. SerafimArts
                01.04.2017 09:45

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

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


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

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


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


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


                1. MetaDone
                  01.04.2017 09:54

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

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


                  1. SerafimArts
                    01.04.2017 10:02
                    +1

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

                    Подсказываю решение:


                    use Illuminate\Config\Respository;
                    
                    class MyConfig extends Repository 
                    {
                        public function getSomething(): int
                        {
                            return (int)$this->get('some.value', 10);
                        }
                    }

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


                    Или при клонировании репозитория — в ларе сам читай readme и ищи какие параметры в .env нужно прописать если никто не прописал в .env.example то что нужно. А симфони сгенерит при установке пакетов parametest.yml с дефолтными значениями где останется прописать свои параметры для окружения

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


                    P.S. Всё что я нашаманил для упрощения работы с этим для лары — это простенький интрфейсик установки .env


                    1. MetaDone
                      01.04.2017 10:16

                      С другой стороны кто-нибудь может удалить бандл, а тот же самый parameters.yml так и останется висеть набитый левыми переменными

                      Это к приложению относится, настройки бандлов в config_%env%.yml обитают.
                      Сносим бандл — все, симфони будет ругаться что лишние конфиги которые не к чему применить остались.
                      А за parameters.yml.dist следить да, надо самому
                      Подсказываю решение:

                      Это конечно круто, но как-то не то. А так в нужных местах можно было бы сделать так:
                      $rootNode
                          ->children()
                              ->integerNode('positive_value')
                                  ->min(10)
                                  ->max(1000)
                              ->end()
                      

                      А в ларе придется самому за этим следить и исключениями бросаться


                      1. SerafimArts
                        01.04.2017 10:30

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


                        class MyRepo extends Repository 
                        {
                            public function __construct(array $params)
                            {
                                parent::__construct($params);
                        
                                assert($this->get('positive_value') >= 10 && $this->get('positive_value') <= 1000);
                            }
                        }

                        А если заюзать DbC (php-deal например), то вообще сказка получится (эх мечты).


                        Из минусов:


                        • Не так удобно и немного попахивает

                        Из плюсов:


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

                        Ну т.е. подводя итог — оба решения имеют право на существование, только на практике ноды почти всегда сложнее выходят, нежели простое решение "в лоб", но конечно же не всегда.


                        1. Fesor
                          01.04.2017 10:36

                          ассертинг отключается, 0-cost

                          ну как бы в symfony же все кэшируется и дампится так что тоже 0-cost.


                          Можно точно так же добавить красивый интерфейс для конфигов со сложной

                          А может не надо делать сложных конфигов?)


                          1. SerafimArts
                            01.04.2017 10:44

                            А может не надо делать сложных конфигов?)

                            А ты посмотри по ссылочкам лучше, а не вбрасывай =)


                            1. Fesor
                              01.04.2017 12:21

                              ну в симфони это был бы 1 compile pass и 1 тэг. и вместо некого RenderersRepository был бы RendererChain.


        1. alsii
          02.04.2017 21:29

          Спасибо. Пожалуй я присмотрюсь к этому внимательнее.


  1. Sky4eg
    30.03.2017 13:11

    Любителям Kohana советую обратить свой взор на fuelphp


  1. noopic
    30.03.2017 13:17

    В работе для последних двух проектов, которые пишутся уже больше года, взял Yii2. Для pet проекта написал свой микро фереймворк на PHP7.

    Свой фреймворк разделил на две части, API и web. API принимает параметры через GET или POST, валидирует их и возвращает JSON с успешным результатом или ошибкой. Web выводит HTML. Реализовал всё самое необходимое: простейший роутинг, локализацию, мирграции, подключение ассетов, вывод шаблонов, валидацию параметров. Больше пока не понадобилось. Задокументировал, покрыл тестами на 70%. Пустую страницу выводит быстрее, чем Yii2, в 5 раз. Yii2 — 2.5ms, my — 0.5ms.

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


    1. TPbIHTPABA
      30.03.2017 17:21
      +1

      Странно вы сравниваете. Говорите, что написали свой микрофреймворк и сравниваете его с yii2 в котором на данный момент нет микроядра.


  1. maxru
    30.03.2017 13:18

    Использую silex / symfony, а вот следующий проект начну на Scala+Spring )


  1. http3
    30.03.2017 13:39

    Что такое pet-проект?
    Личный проект без получения денег?

    А если личный с получением денег, то можно голосовать? :)


    1. varanio
      30.03.2017 13:50

      да


  1. ertaquo
    30.03.2017 13:50
    -1

    У меня есть нечто самописное, состоящее из роутера и своей реализации ActiveRecord (которая по функционалу пока не доходит до реализации из Yii2, но уже превосходит ту, что в первом Yii; по удобству использования имхо превосходит обе).
    Не сказать, что работает быстрее прочих, но зато писать код с его помощью довольно просто.


  1. GrigoriyGrigoriy
    30.03.2017 14:21
    +2

    Phalcon.


  1. Armleo
    30.03.2017 15:18
    +2

    Кажется я один на wordpress сижу :(.
    Хочеться взять фреймворк и сделать, что-то большое, да работы тут нету.


    1. helg1978
      30.03.2017 15:48

      Это CMS все же.
      Я на прошлой неделе в Joomla добавлял AdminLTE в качестве фронтэнд странички, тоже думал что пора б заканчивать скрещивать ужа с ежом.


    1. vlreshet
      30.03.2017 16:47

      Пфф, вордпресс. Я уже 2 месяца сижу на связке SuiteCRM + Wordpress (связаны через модуль вордпресса). Вот уж где реальная боль и изврат. Иногда я открываю старый проект на ларавеле, и просто почитываю код, чтобы хоть как-то потушить подгорания в нижней части туловища после работы над кодом crm или wp.


    1. khrnsb4y
      31.03.2017 06:37

      Можно сделать плагин, содержащий всю логику проекта, и использовать там Composer и компоненты Symfony, написать адаптеры для API Wordpress и даже что-то попробовать в дальнейшем перенести, если понадобится, на любую платформу, реализуя аналогичный подход. Минус в том, что обычные WP-разработчики попросят у клиента много денег за доработку, т.к. им будет сложно разобраться в проекте. Некоторые вещи можно и в обход движка делать для ускорения, например, AJAX запросы, загрузка ядра занимает очень много времени. Попробуйте личный кабинет пользователя так написать или систему коллективного блоггинга. Мне такие задачи на WP попадались, но тогда я сочетанием корявых плагинов обходится, не осилил сам сделать.


      1. http3
        31.03.2017 11:26

        Можно сделать плагин, содержащий всю логику проекта, и использовать там Composer и компоненты Symfony, написать адаптеры для API Wordpress

        Кто кого будет дергать?
        Wordpress Symfony
        Или
        Symfony Wordpress?


        1. franzose
          31.03.2017 14:23

          Естественно Symfony будет дёргать WordPress.


          1. http3
            31.03.2017 15:16
            -1

            Извращение. :)
            Вдруг что, я писал «кто кого» будет дергать, а не «кого кто».


  1. MisterGoodman
    30.03.2017 16:02
    -1

    Уже много лет работаю с Kohana.


    1. TPbIHTPABA
      30.03.2017 17:21

      На поддержке старых проектов или новые запускаете на Kohana? Если не ошибаюсь фреймворк мертвый уже года 3-4 как.


      1. MisterGoodman
        31.03.2017 07:33

        На кохане сделал что-то вроде простого CMS. Так что изредка пеку и новые проекты.


  1. mrOrlando
    30.03.2017 17:03
    -1

    В долгоиграющем проекте (архив документации, электронный документооборот) используем mediawiki, поддержка модульности, версионирования, интернационализации. Известно о нём только благодаря википедии.


  1. Bal
    30.03.2017 17:44
    +1

    Другой (укажу в комментариях)

    На собственном. Странно, что такого пункта нет :)


  1. de1vin
    30.03.2017 17:48

    С самого появления Yii работал с ним. Сталкивался в свое время с CI и Kohana.

    С этого года стал перебираться на Symfony в виду того, что поменялся взгляд на разработку.

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

    Лет пять назад, джаст фо фан, с другом запустили небольшой сайт для автоматизации размещения его панорам. Шло время, прикрутил rbac и регистрацию юзеров, что бы и друге могли размещать свои панорамы, потом понадобился форум, потом api понадобилось. И в итоге, все это разрослось в такого мутанта, что когда мне нужно что-то новое добавить в код, я начинаю плакать кровавыми слезами :)

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


  1. Aircodes_Raccoon
    30.03.2017 18:12

    я использую компоненты фреймворков и отдельные либы/пакеты

    • cboden/ratchet
    • react/react
    • guzzle/guzzle
    • symfony/http-foundation
    • klein/klein
    • twig/twig
    • colshrapnel/safemysql
    • monolog/monolog
    • raulfraile/ladybug
    • curl/curl
    • phpseclib/phpseclib


  1. WitER
    30.03.2017 18:12
    +2

    +FlightPHP.
    Второе голосование, на мой взгляд, не совсем верно — нельзя точно говорить о выборе фреймворка не имея информации о проекте.


  1. bossound
    30.03.2017 18:12

    Длительное время вообще не использовал фреймворки но два года назад познакомился и подсел на Phalcon и очень им доволен, сейчас постепенно перевожу рабочие проекты на Phalcon, с учетом того что специально для нас была добавлена в Phalcon поддержка twemproxy.


  1. seregagl
    30.03.2017 18:44

    Пишем все проекты на yii. Присматриваемся в сторону yii2. Перешли бы хоть завтра, но переписать за один день весь наработанный багаж не получится.


  1. WebmasterW3S
    30.03.2017 20:08
    -1

    А у Joomla тоже фреймворк есть. И далеко не самый худший.


  1. denisyukphp
    30.03.2017 20:22
    +1

    Сейчас сижу на Yii2, но больше по душе компонентный подход: Slim + пакеты сторонних разработчиков. В зависимости от задачи нужно постепенно наращивать функционал, усложнять бизнес-логику приложения. Здесь многого не надо: пакеты, которые крутятся вокруг HTTP-спецификации; работа с БД (Medoo, Eloquent ORM, Doctrine2); шаблонизатор (как по мне лучший Twig, нативный принципиально не рассматриваю). Но и вся архитектура на вас. Чаще в такие проекты порог входа выше, нежели в любой «тяжёлый» фреймворк.


    1. redfs
      30.03.2017 22:36
      +3

      Slim + пакеты сторонних разработчиков
      +1. Slim, как каркас — великолепен. Ничего лишнего и шикарная архитектура, позволяющая легко и даже элегантно наращивать «мясо».


  1. ghost404
    30.03.2017 21:11
    +2

    Работал с Zend 1, Symfony 2, Yii 1 и самописными фраймворками.


    Как-то пришлось начать проект на Yii 1 после Symfony 2.
    Год разработки я плакал горькими слезами (буквально).
    Даже если очень захотеть, не говнокодить на Yii почти невозможно.


    Смотрел Laravel. Тот же Yii вид сбоку.


    Уже несколько лет я на Symfony и счастлив как ребенок.
    DDD + CQRS + Specifications + ValueObject + Doctrine


    Даже маленькие проекты на Symfony летают.


    1. Rathil
      30.03.2017 23:48
      +1

      Ну у меня и на Yii2 проекты летают. Тут как пишешь и что используешь, мне кажется…


    1. SerafimArts
      01.04.2017 00:02
      +2

      Позвольте, не стоит сравнивать Yii и Laravel — это совершенно разные подходы для одно "целевой аудитории".


      DDD и прочее в Symfony вытекает из использования доктрины. Посмотрим как вы с Propel'ом так же развернётесь =) Берёте лару + доктрину и отличий не найдёте, ну кроме того, что не будет в проекте этой треклятой сервис-локации, а всё будет по-нормальному с чистым DI.


      1. porn
        01.04.2017 00:30

        Просто интерсено: почему по вашему мнению, DDD вытекает из использования доктрины?
        Доктрина, например, не умеет в ValueObject as identity. А собственно саму поддержку ValueObject запилили только спустя 5 лет после реквеста.
        DDD с симфони применим, потому что фреймворк очень гибкий, а не потому что какая-то либа задаёт правила.


        1. SerafimArts
          01.04.2017 01:12
          +2

          Не только доктрины. AR крайне сложно представить в виде чистых доменных сущностей из-за своей специфики прямой связанности с БД (т.е. тупого DAO). А доктрина — Data Mapper с чистыми энтитями никак не связанными со структурой БД, которая, как известно, хранит зачастую много технической информации не связанной с предметной областью. По-этому нормальную предметную область можно организовать лишь при использовании не-DAO ORM, как доктрина, к примеру. От фреймворка это уже мало зависит.


      1. ghost404
        02.04.2017 09:55

        Я сравнивал Yii 1 и Laravel 1, когда он только вышел.
        Что мне сходу не понравилось в Laravel:


        • дурацкая файловая структура. Мне на тот момент она показалась не логичной.
        • работа с базой через такой же ActiveRecord что и в Yii. Принципиальных преимуществ я не увидел, особенно если сравнивать с Doctrine.
        • мне не понравился шаблонизатор. Не да Twig, пере php как в Yii, но это субъективное. Twig мне нравится больше.

        Сейчас бегло пробежался по документации и увидел ещё проблемы:


        • роутинг через php. Тоже что и в Yii. В Symfony роутинг конечно тоже транслируется в php, но описываем мы его либо в yaml конфигах, либо в аннотациях.
        • аннотации считаю очень удобным инструментом, хоть и не всегда они к месту. В Laravel аннотаций я не увидел, возможно нужно было капнуть глубже.
        • переводы в Laravel описываются в php файлах как и в Yii. Удобно использовать формат xliff, для которого есть редакторы и можно отдавать переводы на сторону — переводчикам, не разработчикам. Также удобным является формат yaml, позволяющий построить иерархию сообщений.
        • для Doctrine есть бандл который позволяет переводить сообщения из БД
        • реализация IoC в Laravel мне показалась странной. В Yii не лучше.

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


        Laravel и так написан на компонентах Symfony, если в него перенести Doctrine, Twig и еще кое какие компоненты из Symfony, то от самого Laravel почти ничего не останется и логичнее сразу писать на Symfony.


        В результате, я не увидел никаких преимуществ Laravel и Yii перед Symfony. Если я что-то упустил, просветите меня пожалуйста.


        1. SerafimArts
          02.04.2017 10:08

          Laravel 1 вроде как никогда не выходил, а на гитхаб вылился начиная с версии 3+ (сейчас 5.4, летом 5.5 LTS), откуда такой раритет? Поделитесь?


          1. ghost404
            02.04.2017 10:16

            Таких подробностей я не помню. Смотрел на него несколько лет назад когда он только появился на хабре.


            1. SerafimArts
              02.04.2017 11:14

              На хабре он начал появляться начиная с версии 4.х, довольно паршивенькой, к слову, но довольно удобной для простых вещей. Начиная с версии 5.1+ уровень решения вполне конкурентен с симфони.


              Но это оффтоп, если по теме:


              В результате, я не увидел никаких преимуществ Laravel и Yii перед Symfony. Если я что-то упустил, просветите меня пожалуйста.

              Начнём с того, что сравнивать Laravel, Symfony и Yii некорректно, начнём с ЦА:


              • Yii — это Low и Middle решения
              • Symfony — Middle и High
              • Laravel 4.x — Low и Middle
              • Laravel 5.x — Low, Middle и High

              Я думаю рассказывать почему так не имеет смысла, а полное обсуждение вопроса потребует не один комментарий, но чуть объясню общими словами:


              Эффективнее всего стартануть типовой проект получится однозначно на Yii, с Laravel и тем более Symfony это будет сложнее, просто потому, что у в ларе круд генераторы надо доставлять, а в симфони из близких аналогов только соната, и то, там только админка без генерации. С другой стороны архитектура Yii довольно кособокая с крайне высокой связанностью, из-за чего просто не развернуться в нетривиальных условиях.


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


              Если ещё более кратко — Symony и Laravel для крупных проектов вполне сопоставимы, только в симфони изначально планка так стоит, а в Laravel надо знать все особенности фрейма.


              P.S. Все указанные особенности симфони реализуются на Laravel в пару тычков, т.к. декларативные возможности роутинга, конфигов и прочего симфони — это всего лишь надстройка над императивщиной.


            1. SerafimArts
              02.04.2017 11:31
              +1

              Теперь отдельно по пунктам:


              роутинг через php. Тоже что и в Yii. В Symfony роутинг конечно тоже транслируется в php, но описываем мы его либо в yaml конфигах, либо в аннотациях.

              Этот роутинг аналогичен именно симфонёвому, в Yii он иной, но при этом он гибче симфонёвого, но и многословнее.


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

              Аннотации — это всего лишь пакет из Doctrine или Falcon (на ваш вкус), если хотите использовать роутинг и прочее — никто вас не ограничивает в этом, можно даже не писать, а использовать готовые вещи: https://laravelcollective.com/docs/5.0/annotations Это всё же фрейм и никто ни в чём вас не ограничивает, просто они не нужны из коробки


              переводы в Laravel описываются в php файлах как и в Yii. Удобно использовать формат xliff, для которого есть редакторы и можно отдавать переводы на сторону — переводчикам, не разработчикам. Также удобным является формат yaml, позволяющий построить иерархию сообщений.

              Никто в этом не ограничивает, добавляете новый адаптер (лоадер) и всё начинает работать с чем вам угодно, думаю достаточно очевидно как его реализовывать? https://github.com/illuminate/translation/blob/master/LoaderInterface.php


              для Doctrine есть бандл который позволяет переводить сообщения из БД

              А в Laravel есть лоадеры, которые могут дёргать всё из БД, а есть и доктрина: http://www.laraveldoctrine.org/


              реализация IoC в Laravel мне показалась странной. В Yii не лучше.

              Почему же более мощный DI — это плохой вариант IoC?


              Что есть в Laravel:


              • Получить сервис по интерфейсу, а не сервис-локации
                ($container->get(SomeInterface::class);)
              • Возможность создавать объекты с инжектом из контейнера (т.е. обычный new, но с сервисами из контейнера без декларации конфигов)
              • Возможность управлять внедрением (говорить, что если контроллер или потомки запросит A — вернуть ему AA, а если этот сервис, то AB)
              • Возможность подписываться на любые события контейнера (например вызывать сеттер после резолва сервиса из контейнера)

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


              1. ghost404
                02.04.2017 15:04
                -1

                Этот роутинг аналогичен именно симфонёвому, в Yii он иной, но при этом он гибче симфонёвого, но и многословнее.

                А чем он гибче и многословней? Прочитал документацию. Абсолютно всё тоже самое, что и в Symfony. Только группировку в Symfony реализуется подругому, чуть более логчно, и ParamConvertor в Symfony удобнее. Поделитесь пожалуйста, чем роутинг в Laravel лучше чем в Symfony?


                А в Laravel есть лоадеры

                Под переводами в Doctrine я имел в виду не хранение переводов в бд, а автоподстановку переводов полей сущности:
                https://github.com/Atlantic18/DoctrineExtensions/blob/master/doc/translatable.md


                можно даже не писать, а использовать готовые вещи
                добавляете новый адаптер (лоадер)

                О чем я и говорю. Добавьте в Laravel фарша из Symfony и получите Symfony.


                Почему же более мощный DI — это плохой вариант IoC?

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


                Получить сервис по интерфейсу

                Это просто эпический ад. Интерфейсы описываю контракт, который реализует один или более классов (как правило более одного). И как же Service Locator будет резолвить разные сервисы с одним интерфейсом? Да никак. Бам. О, моя нога)))


                1. SerafimArts
                  02.04.2017 15:25

                  А чем он гибче и многословней?

                  Гибче?


                  • Префиксы в том же месте, где и роуты (не вынося в отдельный yaml)
                  • А ещё есть суффиксы (правда через ядро)
                  • Одной строкой задекларировать полный CRUD
                  • Связать с рантаймом (например выгрузить из БД, бред конечно, но мало ли)
                  • Учитывая пункт выше — можно перейти на ADR-like, а не использовать всю цепочку MVP (MVC)
                  • Объявлять паттерны для плейсхолдеров для всей группы (или вообще глобально)
                  • А можно связать плейсхолдер с любой сущностью (например выбрать из БД энтити, как в симфони в контроллерах)
                  • А ещё раньше можно было одной строкой замаппить все роуты на паблик методы контроллера (задепрекейтили в 5.1, вроде, и вырезали в 5.3)
                  • И куча чего ещё. И самое главное у роутов есть приоритет. Аннотациями приоритет не сделать, приходится гибрид фигачить.

                  Многословнее? А когда императивный php был более лакончиным, нежели декларативный yaml?


                  О чем я и говорю. Добавьте в Laravel фарша из Symfony и получите Symfony.

                  Скорее наоборот. В Laravel из коробки на несколько порядков больше возможностей. В симфони же почти всё ставится руками, всегда, начиная с flysystem, заканчивая всякими monolog, swiftmailer и проч.


                  Это просто эпический ад. Интерфейсы описываю контракт, который реализует один или более классов (как правило более одного). И как же Service Locator будет резолвить разные сервисы с одним интерфейсом? Да никак. Бам. О, моя нога)))

                  Почитайте про контекстуальный биндинг. В новом симфони (который осенью) наконец это добавят: https://github.com/symfony/symfony/pull/22187


                  1. pbatanov
                    03.04.2017 09:41

                    Скорее наоборот. В Laravel из коробки на несколько порядков больше возможностей. В симфони же почти всё ставится руками, всегда, начиная с flysystem, заканчивая всякими monolog, swiftmailer и проч.


                    А вы точно пробовали пакет symfony/symfony и symfony/framework-standard-edition? Это как раз для тех, кто хочет готовый комбайн под новый проект, если что. Потом можно ненужные вещи (твиг, например, в АПИ не пригодился) — выпилить

                    https://packagist.org/packages/symfony/symfony
                    https://packagist.org/packages/symfony/framework-standard-edition


                    1. SerafimArts
                      03.04.2017 10:08

                      Я про абстрактные билды в целом, потому что даже если брать какой-нибудь REST Edition — всё равно доставляется много чего. Ну если брать то, что есть в ларе в коробочном виде:
                      1) Очереди (redis, db, beanstalkd, rabbit, zero, etc)
                      2) Sheduler
                      3) SSH задачи (например можно задеплоиться из локалки одной консольной командой, хотя всякие Deployer и проч конечно лучше)
                      4) Абстракции над файловой системой (Flysystem)
                      5) Авторизация (в симфони 3.0+ похожее появилось, так что можно пропустить)
                      6) Броадкастинг
                      7) Почтовые драйверы и нотификации (можно сообщеньки прямо в какой-нибудь Telegram слать)
                      8) Пагинация
                      9) Сидеры (я пользовался alice фикстурами в симфони, но вроде у доктрины есть из коробки, не помню)


                      Ну и ещё огромное количество мелочей. Почти во всех проектах симфони это приходится руками доставлять.


                      1. SerafimArts
                        03.04.2017 10:18

                        P.S. Ну и ещё cross-DB миграции.


                      1. ghost404
                        03.04.2017 11:42

                        То есть, большое количество предустановленных компонентов в фраймворке которые будут не нужны большинству вы считаете плюсом?


                        Вы мне напомнили сейчас M-A-XG (нынче он http3) который хает фраймворки потому что в них нет хлебных крошек.


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


                        1. SerafimArts
                          03.04.2017 12:17

                          Прошу заметить — это всё необходимые компоненты в 99% сайтах, которые чуть сложнее бложика.


                          1. pbatanov
                            03.04.2017 15:55

                            Большинство этих вещей устанавливаются в два клика пару команд — composer require и подключение в ядро. Ну и список такой себе сомнительный.

                            1 — спорно, это все таки решение конкретных задач по управлению потоком
                            2,3 — это не задача проекта, а задача CI\CD, системы сборки (capistrano, deployer, выбирайте по вкусу). В «большинстве проектов сложней бложика», если говорить вашими терминами, эти вещи уже управляются снаружи.
                            4 — Filesystem есть изкоробки, я не зря привел вам пример пакета, в котором есть ВСЕ пакеты симфони
                            5 — Есть нормальное с версии 2.8, до 2.8 тоже можно было использвать, но чуть сложней (больше кода писать). Сейчас (с 2.8) достаточно заимплементить один интерфейс.
                            6 — не очень понял, что это именно
                            7 — есть, свифтмейлер из коробки. Телеграм из коробки — а почему не ватсап? скайп? Почему фреймворк за вас выбирает канал? Опять же — куча готовых модулей. Выбираете свой и подключаете.
                            8 — готовый бандл
                            9 — готовый бандл, но иногда действительно рекомендуют alice

                            Если доставлять приходится во всех, то вы давно могли сделать свой метапакет, типа того же symfony/framework-standard-edition и переиспользовать его. Есть, кстати и rest-edition. А так вы видимо просто делаете что-то однотипное.

                            У нас сейчас используется микросервисная архитектура и проекты на симфони и все разные. На половине из них все то, что вы написали не нужно.


                            1. SerafimArts
                              03.04.2017 17:01

                              1. А как вы почту отправляете, например после регистрации? В том же треде? Это плохо.
                              2. Это нужно для любых задач, например синхронизация данных с внешним апи раз в N часов. В кроне всегда будет одна строчка, вместо 100500. Это никак не относится к деплою.
                              3. Я уже затерялся в комментах, повторите? Я не вижу: https://github.com/symfony/symfony-standard/blob/master/composer.json#L15-L25
                              4. Неа, в 2.8 есть только аутентификация, надо ставить FOS поверх
                              5. Это фигня, забей =) Тупо возможность пушить сообщения поверх, например вебсокетов.
                              6. свифтмейлер только в стандард, в самом фрейме нету: https://github.com/symfony/symfony/blob/master/composer.json#L19-L30 По поводу остального и ватсап тоже: https://packagist.org/search/?q=laravel%20notification
                              7. в доктрине, ага
                              8. алис не такой гибкий, как доктриновский

                              Если доставлять приходится во всех, то вы давно могли сделать свой метапакет,

                              Нет конечно же, не во всех.


                              1. ghost404
                                03.04.2017 17:47
                                +1

                                2) Sheduler
                                Это нужно для любых задач, например синхронизация данных с внешним апи раз в N часов. В кроне всегда будет одна строчка, вместо 100500. Это никак не относится к деплою.

                                Планировщик это по сути тот же крон, но внутри приложения. В документации к Laravel рекомендуют запускать планировщик раз в минуту. Вы не замечаете тут проблемы?


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


                                Еще cron запускает процессы параллельно и fatal error в одной задаче никак не повлияет на другие. Возможно конечно Sheduler в Laravel как-то это учитывает, но не на столько качественно как cron.


                                Если бы Sheduler был полноценной заменой крона, то это былоб хорошим решением для хостингов на которых нет cron, но это никак не core функция.


                              1. Fesor
                                03.04.2017 18:13

                                Неа, в 2.8 есть только аутентификация, надо ставить FOS поверх

                                вообще-то нет. Обычного form login хватает. Он есть из коробки уже хз сколько.


                                1. SerafimArts
                                  03.04.2017 18:22

                                  Хм, точно, походу с 2.7 воутеры появились, что-то с сглупил =)


                                  1. SerafimArts
                                    03.04.2017 18:28

                                    Нет, даже раньше. Ну бывает. Можно вычеркнуть п.5 из списка


                                1. pbatanov
                                  03.04.2017 21:21

                                  form login хватает для классики. для внешней авторизации (хавоть чужую куку или апи какое хитрое авторизовать) этого уже мало, Guard принес много радости детишкам по поводу этого вопроса


                                  1. Fesor
                                    03.04.2017 21:42

                                    Не спорю.


                              1. Fesor
                                03.04.2017 18:59

                                свифтмейлер только в стандард, в самом фрейме нету:

                                эм… стандарт эдишен это и есть фреймворк. Для работы отдельных симфони компонентов оно не надо. А swiftmailer bundle в отдельном репозитории живет. Как никак это интеграция со сторонним сервисом. Точно так же как и Doctrine bundle.


                                1. SerafimArts
                                  03.04.2017 19:28

                                  эм… стандарт эдишен это и есть фреймворк.

                                  Всегда считал, что это сборка (одна из). А сам фрейм — тут: https://github.com/symfony/symfony


                                  1. pbatanov
                                    03.04.2017 21:20

                                    технически standard edition — это готовое boilerplate приложение на основе symfony fullstack (symfony\symfony) и доп. либ. официальное, православное. а сам фрейм отдельно, как вы указали


                                  1. Fesor
                                    03.04.2017 21:43

                                    Нет, там — только компоненты и куски из которых строятся фреймворки. Более того, вся философия симфони — вот вам сэт компонентов и делайте свои фреймворки. standard-edition это так сказать путь для ленивых. silex — пример что можно сделать свой фреймворк. Ну и т.д.


                              1. pbatanov
                                03.04.2017 21:18
                                +1

                                1. Нет, сфитмейлер умеет спулить емейлы. Либо откладывать до terminate ядра (т.е. шлет после отправки ответа пользователю, завершая коннект), либо можно спул обрабатывать внешним потоком (кроном, например). По умолчанию спул в памяти, отправка по терминейт
                                2. Деплой должен настраивать такие штуки. Потому что это вещи, зависящие от окружения. В ином окружении (дев, тест) у нас такие вещи отключены или поставлены на более щадящие таймеры. В препрод, прод — работают. В проекте есть отдельный конфиг для whenever (так сложилось), который при деплое развертывается в готовый крон файл, этим же CI\CD отключается при откате релиза и прочее. А как вы отключаете ваши кроны при откате релиза?
                                3. Filesystem — это часть пакета symfony/symfony (есть по вашей ссылки). symfony/symfony заменает filesystem. Можно установить отдельным пакетом
                                4. FoS UB, если вы про него — это готовые пользователи, которые надо отметить, опять же не всем подходят. У нас на всех проектах авторизация внешняя, юзеры вообще в битриксе живут (так сложилось). Авторизация работает, в том числе встроенная симфонёвая. Есть проект с FoS UB (точней там Sonata Admin, которая тянет FoS UB
                                5. Ок, не сталкивался, видимо
                                6. Да, потому что технически это такая же внешняя библиотека, как доктрина. Поэтому она идет изкоробки в standard (как доктрина), но это не часть проекта symfony. Сути ссылки я не понял. Вижу что можно все подключить модулями.
                                7. Не только в доктрине, есть knp pagination bundle, довольно удобная штука, умеет пагинировать не только доктрину, а много разных источников
                                8. Возможно, сам пользуюсь доктриновским


                                1. SerafimArts
                                  04.04.2017 01:31

                                  1. Кажется вы не посмотрели что я имел ввиду под шедулером. В случае ларки — крон команда только одна на всё приложение и на RC\Stage и на проде. А шедулер уже сам разруливает что и как включать, раз в 10 минут или раз в год, включая окружение, исключение перекрытий (т.е. исключение дублирования запуска) и прочее-прочее.
                                  2. Я говорил про Flysystem, а не Filesystem. Например подключение Amazon S3 или какого-нибудь WebDav, который на том конце является каким-нибудь статик-сервером для аплоадов. Это тот самый момент, когда подобное решение "из коробки" позволит в будущем переключить драйвер одним кликом.


                                  1. Fesor
                                    04.04.2017 01:43

                                    А шедулер уже сам разруливает что и как включать

                                    Что будет если я допустим в scheduler записал выполнять скрипт раз в 3 минуты и внезапно скрипт начал выполняться 10 минут? Или в документации упущен момент с костылями аля flock?


                                    Я говорил про Flysystem

                                    который интегрируется в симфони с пол пинка а по дефолту если он часто надо — ну я например просто включил его в свой скелет проекта. Точно так же как кучу других вещей которые мне надо где-то в 2/3 проектов.


                                    А вообще ждем symfony/flex.


                                    1. SerafimArts
                                      04.04.2017 07:49

                                      Что будет если я допустим в scheduler записал выполнять скрипт раз в 3 минуты и внезапно скрипт начал выполняться 10 минут? Или в документации упущен момент с костылями аля flock?

                                      Я могу дальше кидаться ссылками на документацию, но оно надо?


                                  1. pbatanov
                                    04.04.2017 08:22

                                    1. Про крон команду с вами уже обсуждают в другом треде, не буду повторяться. Не считаю удобным дергать все ядро раз в минуту вне зависимости от того, должно что-то отрабатывать или нет. Есть консольные команды, которые можно запускать хоть руками, хоть кроном
                                    2. Сорян, замыленый глаз прочитал не так :) Есть подозрение, что готовых интеграций тоже хватает https://packagist.org/packages/oneup/flysystem-bundle. Про решение «изкоробки» уже обсуждали — зачем оно всем подряд? Например при работе с сервисной архитектурой все проекты подряд скорей всего не будут грузить файлы, а будет один сервис для этого


                                    1. SerafimArts
                                      04.04.2017 08:55

                                      Я думаю, что не стоит утверждать, что два разных класса ФС в проекте — это плохо, и всегда лучше одно что-то. Всё это очевидно и симфони — хороший фрейм, я его люблю.


                                      И подытожить хочется мыслью о том, что фреймы создавались для того, чтобы облегчить жизнь. И лара — как раз то решение, когда всё всегда есть под рукой и всё удобно. Т.к. в симфони довольно часто, после ларки, не покидает ощущение что изобретаешь велосипеды. Балует фрейм.


                        1. http3
                          03.04.2017 13:56

                          Я хаю потому, что нету интерфейса для добавления ХК.
                          Я даже не говорю, что он должен быть одинаков для всех фреймворков.

                          Сам шаблон ХК — дело десятое.
                          Вот в вопросе логирования пришли же к PSR-3.

                          Хотя, я как бы и соглашусь, что данное требование более из свойств CMS.
                          Ну и я, если честно, не люблю, когда фреймворк что-то навязывает, например использовать обертки для json_encode() или для вывода элементов форм.
                          Должен быть выбор, использовать предполагаемый фреймворком функционал или реализовывать свой.
                          При этом следует различать разовую разработку и серийную разработку.
                          В разовой разработке без использования «сторонних решений, которые добавляют ХК» требование наличия интерфейса ХК в ядре не нужно.
                          В серийной разработке, когда часто используются «сторонние решения, которые добавляют ХК», наличие интерфейса ХК в ядре необходимо.

                          Поэтому можно сделать такой вывод:
                          Фреймворк все же больше подходит для разовой разработки. Или серийной закрытой
                          CMS — для серийной открытой
                          Самопись может использоваться как для разовой разработки, так и для серийной закрытой

                          Хотя это все — вопрос личных предпочтений. :)


                      1. http3
                        03.04.2017 12:39
                        -1

                        10) Хлебные крошки :)

                        Обновлено:
                        Час не мог постить, коммента не видел :)


                  1. ghost404
                    03.04.2017 11:49

                    Префиксы в том же месте, где и роуты (не вынося в отдельный yaml)

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


                    Одной строкой задекларировать полный CRUDС

                    Аналогично в Symfony. Но нормальные проекты не ограничиваются только CRUD-ом. А когда мы говорим о DDD, то CRUD, вообще перестает быть актуальным


                    вязать с рантаймом (например выгрузить из БД, бред конечно, но мало ли)

                    Это удар по производительности и нужно разьве что для CMS. В Symfony это тоже можно сделать, но зачем?


                    Объявлять паттерны для плейсхолдеров для всей группы (или вообще глобально)

                    Пожалуй согласен. В Symfony этого нет. Объявить регекспы один раз, а не в каждом роуте может быть удобно, хотя реализация в Laravel мне не нравится. Ну и можно вообще отказатся от регекспов, так как всё равно маппинг делается на сущность.


                    А можно связать плейсхолдер с любой сущностью (например выбрать из БД энтити, как в симфони в контроллерах)

                    Это ParamConvertor, о котором я уже говорил ранее. Он удобнее чем в Laravel


                    А ещё раньше можно было одной строкой замаппить все роуты на паблик методы контроллера (задепрекейтили в 5.1, вроде, и вырезали в 5.3)

                    И правильно сделали


                    И самое главное у роутов есть приоритет. Аннотациями приоритет не сделать, приходится гибрид фигачить.

                    1. Приоритет определяется порядком определегия.
                    2. А зачем вообще приоритет роутингов? Если роутинги могут конфдиктовать, то у вас серьезные проблему в проекте


                    1. SerafimArts
                      03.04.2017 12:26

                      А зачем вообще приоритет роутингов? Если роутинги могут конфдиктовать, то у вас серьезные проблему в проекте

                      Ну например на любой роут с методом OPTIONS стоит возвращать 200ый ответ, а на любой роут после всех — 404 с красивой картиночкой.


                      Это ParamConvertor, о котором я уже говорил ранее. Он удобнее чем в Laravel

                      Это не коробочный симфони, если не путаю, это SensioBundle или что-то такое.


                      По остальным пунктам — согласен. Всё это можно, но зачастую надо влезать во внутренности, что печалит.


                      1. ghost404
                        03.04.2017 13:14

                        Ну например на любой роут с методом OPTIONS стоит возвращать 200ый ответ, а на любой роут после всех — 404 с красивой картиночкой.

                        Это есть из коробки. Если роут не найден — 404. Страницу 404 можно кастомизировать. Все ответы по умолчанию отдают 200


                        Это не коробочный симфони, если не путаю, это SensioBundle или что-то такое.

                        Sensio входит в стандартную поставку Symfony. Ссылку вам давали выше.


                        1. SerafimArts
                          03.04.2017 13:41

                          Это есть из коробки. Если роут не найден — 404. Страницу 404 можно кастомизировать. Все ответы по умолчанию отдают 200

                          С 404 — это нормальный путь. Я просто привёл пример, когда приоритет важен. Могу ещё что-нибудь придумать, но надо ли? Идею я донёс.


                          Sensio входит в стандартную поставку Symfony. Ссылку вам давали выше.

                          А, ну да, я слепой, бывает =)


        1. Djeux
          02.04.2017 11:14

          Преимещуство в скорости разработки и скорости работы.


  1. Rathil
    30.03.2017 23:43

    ReactPHP


  1. ablai
    31.03.2017 06:36
    +2

    Очень хотелось бы поменьше этих самописных фремворков, на основе которых обычно гавнокод.
    Редко (скорее невозможно, не встречал, покажите) когда какая то команда способна написать нечто в общем «умнее» чем разрабы крупных фреймворков с огромным комунити.
    Когда я получаю проект, я не жду от него вашего фундаментального кода. Он не интересен, уже достаточно увидел.
    Я надеюсь получить нечто что написано пускай даже CI 2 версий. В нем будет большее мне знакомо, чем всякое написанное на отдельных компонентах Symfony какой то Петей из Комчатки.
    Любите компоненты Symfony, пишите пожалуйста на нем или возьмите тот же Laravel.
    Любите блестать умом показывая свое уникальное (никому не нужное) решение в виде своего фреймворка, идите в github.

    Осуждать Yii, за то что на нем можно гавнокодить было бы ошибкой, т.к. это возможно в разной степени в любом фреймворке. Не думаю что это некий показатель.
    Это хорошо, когда с разных частей приложения ты можешь достучаться до всего остального, некая фишка, лучше чем если бы этого не было, иначе осуждали бы а отсутствие этой фишки, почему бы и нет.
    Сам пишу в основном на Yii2 чему очень рад и редко на Laravel.
    Забавно, как бы популярны не были эти двое, я очень радуюсь когда получаю проект основанный именно на них.

    По меньше «своего» фундаментального ребята, займитесь лучше бизнес логикой.


    1. http3
      31.03.2017 09:55
      -1

      Вы, видимо, встречаете говнокод на самописи потому, что это в основном устаревший код :)


  1. Sonichka
    31.03.2017 06:36

    Используем в компании самописный фреймворк на многих проектах. Даже наверное это микро-фреймворк.


  1. Eugeny1987
    31.03.2017 07:06

    Мне нравится фреймворк в HostCMS


  1. inginer
    31.03.2017 13:09
    +1

    Yii2 и Symfony2


  1. varanio
    31.03.2017 13:13

    Интересно, что есть люди, которые минусовали опрос. Что тут могло не понравится? Сам факт опроса по php-фреймворкам?


    1. AlexLeonov
      31.03.2017 16:03
      +5

      Многим не нравится сам PHP.

      Что характерно, в топики, скажем, по brainfuck* не набигают хейтеры brainfuck* и не требуют от всех считать этот язык воплощением зла и «фракталом плохого дизайна».

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

      * тут подставьте любой не-PHP язык, претендующий быть «убийцей»


  1. uaSaint
    01.04.2017 06:43

    Laravel — нравится архитектура, программирование через интерфейсы, IoC — близко, отличное сообщество, Eloquent \ artisan -вещи… после него даже Symfony показался корявым, была бы моя воля использовал бы везде, где нужен фреймворк.


    В ближайшее время на работе скорее всего придется использовать допиленную версию Silex и думаю на долго.


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


    1. SerafimArts
      01.04.2017 09:13
      +1

      Положа руку на сердце, всё же AR у Yii 2 (главное сырцы не смотреть) местами лучше, нежели Eloquent. Да и сравнивать Symfony с Laravel стоит без учёта ORM. Всё же Doctrine местами даст фору Eloquent.


      В остальном, да, как симфонист — соглашусь. Начиная с симфони 3.0+ очень много плюшек в симфони стянуты с лары, плюс в новой LTS версии (которая осенью выходит) обещают апнуть контейнер до возможностей Laravel. Так что вполне возможно сравняются.


      1. Djeux
        01.04.2017 09:54
        +1

        Положа руку на сердце, eloquent приносит больше проблем чем пользы. Взять ту же невозможность использования композитных ключей и диктатуру тайлера.
        По работе приходиться работать с laravel-ом, в личном проекте использую yii2. Плюс laravel, в том что построен на symfony. Но так же громадный минус в корявой работе с IDE из-за магии с факадами.


        1. Lachezis
          01.04.2017 17:16

          Но так же громадный минус в корявой работе с IDE из-за магии с факадами.

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


          Из неприятных первых ощущений стандартная страница ошибки которую нужно сразу выкидывать из заменять на Whoops.


          P.S. Используем и поддерживаем несколько Laravel приложений.


          1. SerafimArts
            01.04.2017 23:44

            Решение этой проблемы простое — не используйте фасады и всё.


            *Ответ и вам и автору чуть выше


            1. Lachezis
              01.04.2017 23:51

              Как же это не использовать в легаси/чужом коде?)


              1. Fesor
                02.04.2017 00:45

                рефакторинг?) Ну если у вас это создает проблемы то имеет смысл их решать. Хотя подозреваю что на подобных проектах есть проблемы посерьезнее.


            1. Djeux
              02.04.2017 11:23

              В результате всплывает таже проблема что и в Yii. Когда сервис может использоваться в любой точке апликашки, а без толковой индексации для поиска всех use cases приходиться делать текстовой поиск по всей кодовой базе.
              К конце концов позволяет наговнокодить нехуже чем другие «entry level» фреймворки.


              1. SerafimArts
                02.04.2017 11:39

                Это как? Вот вы пишите:


                class Some 
                {
                    public function __construct(MyService $s) { ... }
                }

                Почему этот сервис MyService так сложно найти?


                1. Djeux
                  02.04.2017 12:52

                  Речь о ситуации когда факады применяются аля
                  Facade::doSomething(), в любом месте в коде.
                  IDE без хаков не понимает как нестатичный метод вызывается статически, в результате когда вам надо узнать где применяется метод doSomething, просто кликнув на Find Usages не выйдет. Приходится искать по всем файлам как строку doSomething()

                  Таких приколов в laravel-е можно избежать просто их не используя, но в таком случае встает вопрос, почему попросту не использовать сразу Symfony.

                  Yii2 многие ругают за то что из любого места в коде, будь то вьюха или контроллер есть доступ к апликахе в целом через Yii::$app, но имхо использование факадов в ларе тоже самое, только в профиль.

                  Сужу об этом исключительно после опыта работу с Zend 2, Laravel 4, Yii1/2.

                  Перейти на пятую лару пока не получается возможным, надеюсь многие косяки 4-ой версии там исправлены.


                  1. SerafimArts
                    02.04.2017 13:19
                    -1

                    Ну так L4 и L5 совершенно разные фреймворки, в L4 без фасадов вообще почти ничего нельзя.


        1. porn
          02.04.2017 01:12
          +2

          Взять ту же невозможность использования композитных ключей
          Забавно. В doctrine best practices Марко пишет: «Avoid composite primary keys».
          Any reason to not use an unique constraint instead?
          Do they make a difference in your domain?


          1. Djeux
            02.04.2017 11:19

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


  1. homjke
    01.04.2017 13:46
    -1

    Kohana


  1. SLAED_CMS
    01.04.2017 20:16
    -3

    Использую SLAED CMS.


    1. ellrion
      02.04.2017 01:21
      +4

      Вы хотели сказать "продвигаю"?)
      Даже судя по сайту редкостное....


      1. franzose
        02.04.2017 10:33
        +1

        В коде еще хуже)