Фреймворки — больше минусов чем плюсов

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

Сразу оговорюсь, что с автором я полностью согласен и всего лишь хотел бы добавить свои «три копейки». Сначала думал сделать это прямо в комментах под статьей, но быстро понял, что «копейки» получаются довольно объемные. Так и родился этот текст.

Сначала немного о себе


Веб разработкой я занимаюсь года так эдак с 98-го. Работал и на компании и фрилансером. Сам набирал команды. Как в реале так и в сети. Первым языком программирования был ныне благополучно почивший perl и о его безвременной кончине жалею до сих пор. Потом пришел php. Еще чуть позже ruby и началась эра фейерверков.

Большие обещания маленькие достижения


Встретил я ее с энтузиазмом. Действительно — вроде бы появился инструмент призванный существенно облегчить разработку, способный избавить от большого количества рутины. Однако энтузиазм быстро улетучился. И вот почему.

Не знаю кто как, но я, в первую очередь, ждал избавления от большого количества однообразных действий, которые приходилось выполнять при работе над каждым новым проектом. Проектировать «костяк» базы, писать вывод по сути одинаковых текстовых страниц и т.д и т.п. Кто написал достаточное количество сайтов без труда дополнит это список многими и многими пунктами. И большинство фейерверков действительно избавляют от кучи рутины. Но какой ценой!

И это раз… и это два…

Эраст Фандорин
Моя первая претензия и к RoR, и Yii, и Symfony, и почти всем иным, с которыми пришлось познакомиться — их монстрообразность и тонны совершенно лишнего кода, который неизменно оказывается в проекте. Привыкнув за много лет работы, что код должен быть максимально чистым и лаконичным, что приложение должно быть как можно более быстрым, я в не мог согласится с тем мусором (уж извините по-другому сказать не могу), что оказывался в проектах.

Вторая претензия — попытка всех без исключения авторов фейерверков изобрести, что-то вроде своего языка программирования. Поясню о чем это я. Возьмем к примеру самую распространенную js библиотеку jQuery. При этом сразу оговорюсь, что именно ее я считаю чуть ли не единственно полезной, грамотной и еще много-много лестных эпитетов, среди подобных. Привожу jq в качестве примера только потому, что наверняка всем будет понятно о чем я. И так получить доступ к элементу по ID на нативном js можно так document.getElementById(«id»), а на jQuery так $(«#id»). То что при этом было написано на десяток символов меньше, меня не сильно впечатляет. При этом jq имеет кучу других плюсов ради которых я готов освоить новый синтаксис. Кроме того она надежна и практически никогда не конфликтует с другими библиотеками. Чего не скажешь и куче ей подобных, которые прочат на замену.

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

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

И это три…

Он же

Все выше сказанное касается не только front, но и back. Как следствие возникает вопрос — в самом начале я признал, что в ходе любой разработки приходится выполнять множество ненужных телодвижений, которые хотелось бы оптимизировать, но можно ли это делать такой ценой? А кроме того есть еще один момент, который в большей части касается разработки на Ruby.

Для реализации самых элементарных функций web приложения вам необходимо подключать отдельные gem-ы. Чтобы подкормиться к базе — mysql2, чтобы отправить mail — mail или созданный на его основе poni. И так далее и тому подобное. На первый взгляд ничего страшного в этом нет — все gem-ы в Ruby, как правило, хорошо оттестированы и проблем с ними не возникает. Но из этого правила тоже есть исключения. Например один раз целую неделю пришлось просидеть с odf-report, который никак не хотел корректно работать, а потом плюнуть и написать свой класс. Кроме того несколько напрягает, что с подключением каждого gem-a неизбежно возрастает время формирования страницы. На некоторых gem-aх совсем незначительно. А не некоторых…. Попробуйте поэкспериментировать на эту тему с уже упомянутым pony — сами убедитесь.

Извечный вопрос


И что же делать? C одной стороны разработка на «чистом» языке — однозначно не вариант, а с другой и существующие инструменты не устраивают по целому ряду причин? Выход видится в создании инструмента, который бы оптимизировал наиболее часто используемые функции и одновременно не стеснял программиста, и не навязывал ему стиль программирования который автор этого инструмента считает единственно правильным. На практике, это означает, что инструмент должен:

  1. содержать минимальный набор стандартных, максимально оптимизированных функций
  2. инструмент не должен заставлять программиста изучать что-то вроде нового «недоязыка» программирования полностью отключающего мозг
  3. и все это, в идеале, должно быть оформлено в легкую библиотеку, не пытающуюся тягаться по объему кода с операционной системой.

Может я не прав, но пока, что в обратном меня переубедить ни кто не смог. Готов выслушать любые мнения.
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

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

Комментарии 51

    +2

    Достаточно загуглить "microframework <ваш ЯП>".

      +9

      Хотелось бы узнать о вашем опыте коммерческой разработки. Размеры проектов, команд, сроки. А то создается впечатление, что неофит пытается всех учить жить...


      Про jQuery, например, вы явно не в курсе причин ее появления. Вообще-то она появилась почти 15 лет назад. Это сейчас она не нужна, но когда она появилась, она решала очень много. И потом, jQuery ­— не фреймворк, не совсем понятно, зачем ее здесь упоминать.

        +2
        Видимо автор — специалист сразу в PHP, JS и Ruby.
        +3
        Сразу оговорюсь, что сам я пока дилетант (уже не первый месяц без особых успехов грызу Vue.js).
        На практике, это означает, что инструмент должен:

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

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

        2. инструмент не должен заставлять программиста изучать что-то вроде нового «недоязыка» программирования полностью отключающего мозг

        Если бы… По моему скромному опыту, даже при использовании веб-фреймворка мозгу приходится работать, работать и работать…

        3. и все это, в идеале, должно быть оформлено в легкую библиотеку, не пытающуюся тягаться по объему кода с операционной системой.

        Приведу конкретный пример. Насколько мне известно, объем кода собственно Vue.js относительно невелик даже по сравнению с другими популярными веб-фреймворками, не говоря уже об операционных системах. Не знаю, сколько строк содержит этот код, но размер минифицированного файла vue.min.js — меньше 90 КБ. Правда, для разработки сколько-нибудь серьезного приложения могут потребоваться дополнительные библиотеки, такие как Vuex, Vue Router и иже с ними.

        Если где-то ошибся, надеюсь, меня поправят.

        P.S. Вообще говоря, эта статья выглядит как неумелый наброс…
          +1
          Да самое плохое, что подобный подход к программирование просто отучает думать и когда этот новый супер крутой фейерверкер дает сбой

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

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

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

          инструмент не должен заставлять программиста изучать что-то вроде нового «недоязыка» программирования полностью отключающего мозг

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

            Именно так мы и поступили. Написали на Си gem для Ruby в котором собрали все что используем чаше всего и теперь на нем работаем. Не уверен можно ли здесь публиковать ссылки потому если будет интересно — напишите. Пришлю где его можно посмотреть.
            +4
            Чистые, как агнец божий, программисты в современном мире не живут, их обходят более быстрые писаки на «псевдоязыках». Чистый код не интересен бизнесу. И да язык, фреймворки и библиотеки всего лишь инструменты — под задачу.
              +1
              Всему свое место и время. Если не разобраться с этим тезисом, то так и будешь всю жизнь ассемблером микроскопом забивать гвозди. И даже статьи не надо писать, всего одно предложение. Так что тут и 2й тезис подъехал — не создавай проблем там, где их нет)
                +1

                Фреймворки придуманы не сколько для ускорения работы, сколько для её удешевления. "фреймворкер" может многое не знать и не уметь и при этом выдавать работающий софт.


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


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


                Могу добавить, что изучение ФП значительно повышает качество кода, вне зависимости от языка программирования.

                  +5

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


                  В каком проекте может быть проще заново реализовывать шаблонизаторы, ORM, парсинг HTTP запросов, генерацию HTTP ответов, generic views (для CRUD компонентов), админку, роутинг, защиту от CSRF, REST API, и многое другое?


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


                  Кроме того, фреймворк — это нечто вроде DSL для какой-то области. И новому разработчику не надо изучать «гениальное» творение какого-нибудь ненавистного фреймворка, в котором не будет документации, и которое никогда не пригодится ему ни на одной другой работе. Он сможет сразу включиться в работу и ему будет намного проще понять существующий код.

                    0
                    Фреймворки колоссально облегчают разработку.

                    В каком проекте может быть проще заново реализовывать шаблонизаторы, ORM, парсинг HTTP запросов, генерацию HTTP ответов, generic views (для CRUD компонентов), админку, роутинг, защиту от CSRF, REST API, и многое другое?

                    Не использовать готовый фреймворк не значит писать ORM и прочее с нуля, для этого библиотеки есть.
                      +1
                      которых тоже когда то не было и они были написаны
                      0

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


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


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


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

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

                        Как человек, однажды переносивший значимый код из AngularJS в реакт, я вам скажу, что ваш тезис на редкость бессмысленен. Очень многое зависит от самого кода, в котором вы собрались что-то менять, и не менее многое — от того, что вы считаете «разумным» временем. С критериями такой потрясающей точности я вам любой чужой код могу подписать под «библиотеку» или же под «фреймворк», в зависимости от того, как мне захочется.
                          0

                          Работаю последние 10 лет почти исключительно с Django. Очень маленькие и очень большие проекты. Самому старому проекту более 12 лет (начинал делать его еще на бета-версии Django).


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


                          Бывает плохой код. Бывают плохие структуры данных. Из-за этого приходится часто переписывать значительную часть приложения. Но никогда из-за Django.


                          А если бы даже и пришлось. Допустим, я использую библиотеки. Собрал вместе приложения на Django ORM и шаблонах Django (можно подставить что угодно вместо Django). А затем решил перейти на ORM SqlAlchemy или шаблонизатор Jinja2. Так мне все равно придется почти весь код переписать, особенно, в случае с ORM.


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

                        +1
                        Фреймворки придуманы не сколько для ускорения работы, сколько для её удешевления.

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

                        «фреймворкер» может многое не знать и не уметь и при этом выдавать работающий софт.

                        А кто будет работать, пока вы (и все остальные) будут грызть гранит теории, чтоб знать всё?
                          0
                          «фреймворкер» может многое не знать и не уметь и при этом выдавать работающий софт.
                          А кто будет работать, пока вы (и все остальные) будут грызть гранит теории, чтоб знать всё?

                          Кроме того, это очень странная позиция. Я пользуюсь фреймворками, но при этом отлично знаю, как оно устроено под капотом по нескольким причинам:
                          1) до фреймворков я писал все это вручную
                          2) при работе с фреймворком, регулярно читаю его исходники, чтобы понять, как он устроен
                          3) просто любопытно — мне кажется, что хороший разработчик должен быть любопытным


                          И не уверен, что здесь есть связь. Человек, страдающий синдромом NIH, точно так же может многое не знать. Вообще, в современной разработке все объять невозможно.


                          В голову одного человека не могут вместиться все знания, связанные с базами данных, API, нюансами HTTP, безопасностью, и т.д. А если даже и могут, все равно таким объемом знаний эффективно оперировать мало кто может. Думаю, таких людей десятки на всей Земле.


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


                          Хотя фреймворк-фреймворку рознь, конечно. Если бы автор более конкретные примеры привел...

                            0
                            1) до фреймворков я писал все это вручную
                            2) при работе с фреймворком, регулярно читаю его исходники, чтобы понять, как он устроен
                            3) просто любопытно — мне кажется, что хороший разработчик должен быть любопытным

                            Ну да, и еще 4) надо знать как оно устроено тупо потому, что иначе можно не сойтись во взглядах с авторами фреймворка и убить всю производительность, память, и так далее (в документации не всё пишут).
                              –2
                              В голову одного человека не могут вместиться все знания, связанные с базами данных, API, нюансами HTTP, безопасностью, и т.д.

                              Очень даже ошибаетесь. Слава яйцам такие люди есть и всегда будут, но конечно по сравнению со всей массой «разработчиков» их ничтожное кол-во. И это конечно печально, но тут ничего не поделаешь, люди так устроены, не просто так есть расслоение населения по «классам». Так же и в разработке, многие считают себя хорошими специалистами, а по факту им до них ещё расти и расти.
                                –1

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


                                Так-то я знаю, что такие люди есть. Иногда можно их встретить в каких-нибудь интернет-дискуссиях. Но думаю, что их исчезающе мало. И все уже устроены где-нибудь в Яндексе, Google и т.п. Потому шанс их встретить, если не работаешь в такой компании, наверное, минимален.

                                  –1

                                  Я вот за все двадцать с лишним лет работы в отрасли ни одного такого не видел.

                                    +2
                                    В голову одного человека не могут вместиться все знания, связанные с базами данных, API, нюансами HTTP, безопасностью, и т.д.

                                    Очень даже ошибаетесь.

                                    Ощущение «всё знаю» возникает если не развиваться вширь и не развивать свой кругозор.
                                      0
                                      Слава яйцам такие люди есть и всегда будут

                                      За всю карьеру — ни одного не видел. Видел тех, кто знает что-то досконально, и плюс к этому знает все «правильные ответы» из множества других областей, так или иначе связанных с его деятельностью. То есть, спец в некоторых вещах, и знаток «по верхам» многих других вещей. И даже таких людей очень мало.

                                      Тот, кто знает всё в деталях в очень широком наборе вопросов — он, очевидно, не может работать; всё его время будет уходить на то, чтоб поддерживать свой уровень.
                                  +1
                                  Заводы придуманы не столько для ускорения, сколько для удешевления. Рабочий может многое не знать и не уметь и при этом выдавать работающий продукт.

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

                                  А что делать ремесленным командам? Пилить по 5 лет «произведения ремесленного искусства». Например инструменты, позволяющие работать ещё эффективнее (но ни в коем случае не использовать их самим, чтобы не уподобляться чернорабочим).

                                  Могу добавить, что изучение пасатижей значительно повышает качество продукции, вне зависимости от профиля работ.
                                  +2
                                  А почему ни слова про чудовищно низкую производительность Ruby on Rails и Symfony? И вообще если использовать ORM, это просто убийство производительности. Или никого не смущает когда бэкенды отвечают секундами и сотнями миллисекунд?
                                    +1

                                    Из моей практики бэкенды отвечают сотнями миллисекунд, потому что их пишут разработчики, которые ничего не понимают и не хотят понимать в ORM, O(n), SELECT n+1 problem, и других «неважных» материях.


                                    Исключений пока что не видел (хотя ни RoR, ни Symfony, не пользуюсь).


                                    Зато регулярно вижу код (этот пример из одного моего проекта, написан уволившимся коллегой): [agent.id for agent in Agent.objects.all() if agent.is_active == True]. Конечно такое никогда не будет работать быстро. Это идиотизм головного мозга, и он никак не связан ни с ORM ни с фреймворками.

                                      0
                                      Зато регулярно вижу код

                                      Это потому что при изучении фреймворка мозг не был задействован...

                                      +1
                                      А почему ни слова про чудовищно низкую производительность Ruby on Rails и Symfony?

                                      Смею предположить, что не умеете готовить


                                      И вообще если использовать ORM, это просто убийство производительности.

                                      Гидрируем в массивы и импакт от ORM становится незаметным


                                      Или никого не смущает когда бэкенды отвечают секундами и сотнями миллисекунд?

                                      Вы подтверждаете мое предположение про умение готовить

                                        +1
                                        Смею предположить, что не умеете готовить

                                        Смешно, как раз таки бэкенды написанные мной отрабатывают менее чем за 0.5ms в среднем на каждый запрос, плюс сетевой пинг до клиента. Загрузка CPU около нулевая, отжирание оперативки ни о чем. Разумеется эта скорость не доступна для популярных фреймворков особенно в связке с ORM. Я считаю если у тебя обычные CRUD операции работают дольше 2ms именно бэк + БД, то это просто не приемлемо. Кроме случаев когда у тебя сотни тысяч запросов в секунду летит на чтение и запись конечно. Но 99.9999% диванных экспертов работа в проектах где в самый самый пик будет 50-60 запросов в секунду.
                                          +1

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


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

                                            0
                                            Значит вы задизайнили БД не правильно и не пользуетесь триггерами и вспомагательными таблицами для сложных запросов, а так же может и кэш не используете
                                            0

                                            MaZaAa


                                            Разумеется эта скорость не доступна для популярных фреймворков особенно в связке с ORM

                                            Вы еще раз подтверждаете мое предположение про умение готовить. Время инициализации вполне отлично тюнится. Что касается тяжелых БД запросов, часто эта проблема решается за счет очередей. Если нужно именно за http запрос вытянуть много всякого без кэширования — пишется raw запрос с гидрацией в массив.

                                          0
                                          А почему ни слова про чудовищно низкую производительность Ruby on Rails и Symfony?

                                          Потому что не в этом их цель, да и всё нормально с производительностью у Symfony так точно. Там теперь даже ORM из коробки не идёт.

                                          вообще если использовать ORM, это просто убийство производительности.

                                          Если у вас тормозит доктрина, возможно вы её используете не по назначению и грузите из неё сущности пачками.
                                          +3
                                          Фреймворки — больше минусов чем плюсов

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

                                            DSL.

                                              +1

                                              AleksShved
                                              Ваши рассуждения могут быть вполне справедливы для мелких проектов, грубо говоря на одного/пару инженеров, но не более. Хотите вы того, или нет, но функциональность проекта должна быть написана, у вас так, или иначе получится свой "фреймворк". Разница между вашим правильным и плохим чужим в том, что чужой:


                                              1. Имеет bus-фактор на порядки больше вашего.
                                                Когда вы уходите с проекта, вы уносите с собой знания о вашем фреймворке. Это сильный удар по команде. Я лично попал в такую ситуацию, через 2 недели после моего устройства автор хорошего фреймворка уволился, bus-фактор был 1, стал 0. Было дешевле переписать, на известном фреймворке, чем поддерживать.


                                              2. На много лучше документирован.
                                                Это официальная документация, статьи, вопросы на stackoverflow, issues на github и т.д. Я очень сомневаюсь, что вы можете похвастаться чем-то подобным про свой правильный фреймворк.


                                              3. На много лучше протестирован.
                                                Я сильно сомневаюсь, что вы можете попасть хотя бы в 1% ситуаций от тех, в которые попали/попадают пользователи того, или иного фреймворка. Для популярного фреймворка с довольно большой вероятностью столкнувшись с проблемой можно быстрее найти ее решение.


                                              4. Во многом лучше реализован.
                                                Это спорное утверждение, и корректно только в частностях, по этому приведу пример: http роутер symfony — дико мощная и производительная штука, если у вас получилось лучше, я очень хотел бы взглянуть.


                                              5. Не тратит ваше время на разработку себя.
                                                Поддержка собственного правильного фреймворка — это куча времени, которого как правило нет.



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

                                                +1
                                                >> И что же делать?

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

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

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

                                                А вообще, боль разработчиков по поводу «ну почему всё так убого» — разделяю. Хотя и объяснение давно известно — таков мир, который ни разу не идеален. Общее решение скорее должно касаться нахождения вашего личного места в этом мире.
                                                  0
                                                  В более реалистичном случае нужно просто неторопливо писать «правильные» библиотеки для себя, отбирать «правильные» готовые решения. В сумме получится приятная для существования экосистема.

                                                  В более реалистичном случае эта приятная экосистема будет скорее всего никогда не создана (технологии устаревают, да и автор со временем скорее всего будет писать лучше, и на свой старый код будет смотреть искоса). И даже в том исчезающе малом количестве случаев, когда будет — остальные от неё будут шарахаться по причинам, описанным в комменте над вашим.
                                                    0
                                                    От фреймворков же не шарахаются. Так что здесь вы просто узко смотрите на мир.
                                                      0
                                                      Разумеется, вы можете работать в достаточно большой конторе, которая экономически сможет выращивать свой фреймворк.
                                                        0
                                                        Вообще, речь шла про инструменты. Про фреймворк было сказано как про «самый большой инструмент», то есть если не отказываются от самого большого, то про меньшие и говорить нечего. Поэтому экономика в данном случае точно так же корректируется на «размер» инструмента.

                                                        Ну и про фреймворки — какой-нибудь спринг выкинуть — очень даже полезно, а заменить его можно весьма скромным набором более приспособленных к задаче инструментов. Экономически это недорого, ну а по претензиям на «фреймворковость» вполне сравнимо с тем же спрингом. То есть опять всё доступно и нет серьёзных ограничений кроме лени или отсутствия вменяемых разработчиков.
                                                  +1
                                                  Ругаете фреймворки и просите универсальный инструмент.
                                                  фейерверкер фремверкеров *facepalm*
                                                    0
                                                    Моя первая претензия и к RoR, и Yii, и Symfony, и почти всем иным, с которыми пришлось познакомиться — их монстрообразность и тонны совершенно лишнего кода

                                                    Lumen, Slim, Silex, тон лишнего кода нету.
                                                      +1
                                                      Возможно. Понятно, что досконально разбираться в коде всех у меня возможности не было. Нужно еще и работать.
                                                      Но интересно. Такое впечатление что половина тех кто пытается комментировать даже не поняла о чем статья. Увидела что ругают их любимые фреймверки и понеслась в бой. Я не против «инструментов» оптимизирующих работу. Я против того какие они. Точнее большинство из них в настоящее время.
                                                        0
                                                        Ну вы же сами в конце выставили требования, они как раз подходят под 90% микрофреймворков. Вам не кто не запрещает собирать что-то свое под свои нужды. Jquery сокращает код очень существенно (до десятки тысяч строк кода в мелком/среднем проекте), приходилось писать на нем части веб-приложения, другое дело бывало встречались сайты где его использовали ради одного ScrollTop. А уж Vue/Angular/React сокращают время разработки и облегчают ее просто многократно, после Jquery прямо небо и земля.
                                                          0
                                                          Как раз про Jquery я написал что цитата " При этом jq имеет кучу других плюсов ради которых я готов освоить новый синтаксис. " ))
                                                          А вообще я уже прочитал здесь столько мнений… С какими то я согласен с какими то нет Но однозначно думаю пора бы написать еще одну статью и как то все это суммировать )
                                                          А про «ScrollTop» вы даже не представляете сколько мне приходилось встречать сайтов где ради одной элементарной функции человек подключал кучу какого то барахла про который часто даже ни кто не слышал.
                                                          Более того как то прочила в блоге у одного товарища «После этого подлючаем наш замечательный less который из одной строчки нашего кода генерит 20к строк в css фале» (как то так) и все это только ради того что бы залить окружность радиальным градиентом с переходами.
                                                      0
                                                      Разве ваши самописные инструменты не будут являться фреймворками?
                                                        +1
                                                        Далеко не все инструменты являются фреймворками. Но не в названии суть.
                                                        0
                                                        Очень не правильное рассуждение.
                                                        Понятие фреймворков сейчас изменилось, а вы продолжаете жить в древние времена, сейчас это расширенная либа с определенной структурой, подходом, правилами и кодестайлом.
                                                        Использование фреймворка позволяет сконцетрировать силы на написание важных частей приложений.
                                                        Да, постепенно от базового фреймворка остается мало, но это правильный цикл, чем изобретать велосипед.

                                                        И видно, что автор не работал с Yii2 и тем более с Yii3, также автор не знает тенденций современной разработки.

                                                        Сейчас задачи у программистов:
                                                        1. делать быстро с максимальным покрытием тестами — во многих крупных компаниях CI/CD через TDD;
                                                        2. параллельно рефакторить, профилировать, оптимизировать;
                                                        3. использовать подход DDD — очень большое кол-во кода переходит из проекта в проект, тем самым все заворачивают всё в приватные репы, которые потом подключаешь к нужным проектам.
                                                          +3
                                                          Понятие фреймворков сейчас изменилось

                                                          Framework = каркас, отличие от билиотеки в IoC.

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

                                                          Меня не интересует «структура, подходы и кодстайл» либы. Только её интерфейс. Фреймворк общего назначения не должен оказывать значительное влияние на структуру моего приложения.

                                                          И видно, что автор не работал с Yii2 и тем более с Yii3, также автор не знает тенденций современной разработки.

                                                          Yii 2 это старьё с кучей велосипедов, давно устаревшими подходами, скудным и ужасно реализованным функционалом прибитым к фреймворку. Yii 3 — попытки дожать труп.

                                                          Сейчас задачи у программистов:
                                                          1. делать быстро с максимальным покрытием тестами — во многих крупных компаниях CI/CD через TDD;

                                                          Можно примеры «многих» таких компаний? Чтобы вот прям TDD, не налепить приёмочных перед реализацией, не просто test first, а именно TDD с юнит тестами и инкрементальной разработкой. И CI/CD с частыми релизами и всем вот этим вот, а не просто cs fixer на гит хук поставили

                                                          использовать подход DDD — очень большое кол-во кода переходит из проекта в проект, тем самым все заворачивают всё в приватные репы, которые потом подключаешь к нужным проектам.

                                                          Чего чего!?
                                                          DDD про общение с бизнесом(конкретным, на конкретном проекте), перенос знаний в код, общую терминологию, ни о каких «общих библиотеках» там речи нет.
                                                          0
                                                          del(промахнулся веткой)

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

                                                          Самое читаемое