Это правда, я уже молчу про то, сколько времени потрачено в спорах о каждом из них.
Если у вас есть конструктивные доводы по изменению — пожалуйста укажите их в issues.
Роутинг на основании имен методов — это дико хреновая идея. Что если мне нужен экшн с GET: /user/{userName}/profile/articles/{articleId}/comments/{headCommentId} при этом выражения внутри скобок отвечают неким регуляркам, и еще один экшн POST с таким же путем ?
Юзайте суперглобальные переменные только для создания некого Request объекта в самом начале выполнения.
Ваше разбиение на модули в вендоре не имеет смысла, пример: application не может без конкретной реализации router, хотя router в другом пакете. Причем не приколочен гвоздями через автозагрузку, а наглухо приварен require.
Тут на конце 2019 есть namespace, категорически рекомендую.
Такое… взяв за основу то, что необходимо дождаться выполнения всех параллельных функций, автор усложняет целый спектр задач, когда требуется независимое выполнение. Ход конем с пробросом питомника выглядит как грязный хак.
Разумеется эта скорость не доступна для популярных фреймворков особенно в связке с ORM
Вы еще раз подтверждаете мое предположение про умение готовить. Время инициализации вполне отлично тюнится. Что касается тяжелых БД запросов, часто эта проблема решается за счет очередей. Если нужно именно за http запрос вытянуть много всякого без кэширования — пишется raw запрос с гидрацией в массив.
AleksShved
Ваши рассуждения могут быть вполне справедливы для мелких проектов, грубо говоря на одного/пару инженеров, но не более. Хотите вы того, или нет, но функциональность проекта должна быть написана, у вас так, или иначе получится свой "фреймворк". Разница между вашим правильным и плохим чужим в том, что чужой:
Имеет bus-фактор на порядки больше вашего.
Когда вы уходите с проекта, вы уносите с собой знания о вашем фреймворке. Это сильный удар по команде. Я лично попал в такую ситуацию, через 2 недели после моего устройства автор хорошего фреймворка уволился, bus-фактор был 1, стал 0. Было дешевле переписать, на известном фреймворке, чем поддерживать.
На много лучше документирован.
Это официальная документация, статьи, вопросы на stackoverflow, issues на github и т.д. Я очень сомневаюсь, что вы можете похвастаться чем-то подобным про свой правильный фреймворк.
На много лучше протестирован.
Я сильно сомневаюсь, что вы можете попасть хотя бы в 1% ситуаций от тех, в которые попали/попадают пользователи того, или иного фреймворка. Для популярного фреймворка с довольно большой вероятностью столкнувшись с проблемой можно быстрее найти ее решение.
Во многом лучше реализован.
Это спорное утверждение, и корректно только в частностях, по этому приведу пример: http роутер symfony — дико мощная и производительная штука, если у вас получилось лучше, я очень хотел бы взглянуть.
Не тратит ваше время на разработку себя.
Поддержка собственного правильного фреймворка — это куча времени, которого как правило нет.
Безусловно, бывают ситуации, когда существующие фреймворки вам ни как не помогают в решении задачи, конкретно в таких ситуациях напил своего вполне оправдан.
я не встречал ни одной реактивной CMS, полностью написанной на JS и использующей Mongo в качестве БД (напишите, пожалуйста, в комментариях, если такое есть, а я пропустил)
Почитаешь остальные комменты так приходишь к выводу, что и думать в этом направлении нельзя ни в коем случае.
Я не утверждал, что нельзя, можно, даже нужно. А вот про "но" я как раз писал, их много. Предлагаемый автором бриф требований не продуман, противоречив, категоричен и результатом его будет совок 2.0. такой же гротескный и пацаватый. Не оглядываться на историю — как минимум глупо.
Мелкие части приведенных систем вполне можно реализовать, например тема с одеждой и авто-подбором — это вполне здорово, но как обязаловка — это очень плохая идея, потому что есть целая группа людей с не стандартными мерками.
Сколько ещё должно миллионов людей пострадать, прежде чем утопичность такой системы станет общепризнанным фактом?
Ваш код печалит котейку, не надо так
Если смысла нет и вы это понимаете, зачем вы этим занимаетесь? Для самообучения?
Здорово, спасибо
Это правда, я уже молчу про то, сколько времени потрачено в спорах о каждом из них.
Если у вас есть конструктивные доводы по изменению — пожалуйста укажите их в issues.
угу
на микро шаред хостингах
Помимо PSR-ов, composer-ов, да и просто хороших практик (https://github.com/index0h/php-conventions):
Если вас устраивают действия рамблера — в чем проблема? Пройдите мимо. Если же не устраивает — вполне резонно отреагировать.
Связи с общественностью как бы предполагают что вы находитесь со стороны куда вентилятор дует.
В чем тогда проблема?))
Такое… взяв за основу то, что необходимо дождаться выполнения всех параллельных функций, автор усложняет целый спектр задач, когда требуется независимое выполнение. Ход конем с пробросом питомника выглядит как грязный хак.
MaZaAa
Вы еще раз подтверждаете мое предположение про умение готовить. Время инициализации вполне отлично тюнится. Что касается тяжелых БД запросов, часто эта проблема решается за счет очередей. Если нужно именно за http запрос вытянуть много всякого без кэширования — пишется raw запрос с гидрацией в массив.
Смею предположить, что не умеете готовить
Гидрируем в массивы и импакт от ORM становится незаметным
Вы подтверждаете мое предположение про умение готовить
AleksShved
Ваши рассуждения могут быть вполне справедливы для мелких проектов, грубо говоря на одного/пару инженеров, но не более. Хотите вы того, или нет, но функциональность проекта должна быть написана, у вас так, или иначе получится свой "фреймворк". Разница между вашим правильным и плохим чужим в том, что чужой:
Имеет bus-фактор на порядки больше вашего.
Когда вы уходите с проекта, вы уносите с собой знания о вашем фреймворке. Это сильный удар по команде. Я лично попал в такую ситуацию, через 2 недели после моего устройства автор хорошего фреймворка уволился, bus-фактор был 1, стал 0. Было дешевле переписать, на известном фреймворке, чем поддерживать.
На много лучше документирован.
Это официальная документация, статьи, вопросы на stackoverflow, issues на github и т.д. Я очень сомневаюсь, что вы можете похвастаться чем-то подобным про свой правильный фреймворк.
На много лучше протестирован.
Я сильно сомневаюсь, что вы можете попасть хотя бы в 1% ситуаций от тех, в которые попали/попадают пользователи того, или иного фреймворка. Для популярного фреймворка с довольно большой вероятностью столкнувшись с проблемой можно быстрее найти ее решение.
Во многом лучше реализован.
Это спорное утверждение, и корректно только в частностях, по этому приведу пример: http роутер symfony — дико мощная и производительная штука, если у вас получилось лучше, я очень хотел бы взглянуть.
Не тратит ваше время на разработку себя.
Поддержка собственного правильного фреймворка — это куча времени, которого как правило нет.
Безусловно, бывают ситуации, когда существующие фреймворки вам ни как не помогают в решении задачи, конкретно в таких ситуациях напил своего вполне оправдан.
При том, что у вас CMS на ноде, таких много, в чем фишка именно вашей?
вы еще про сборку и раздачу фронта забыли))
Вы видимо и не искали вовсе. Первый же результат в гугле 11 Best Node.js-based CMS as of 2019
Не понятна мотивация создания подобной cms.
Статья не стоит потраченного на нее времени
Подскажите, есть ли что-то подобное для Nautilus?
Если честно, ваши слова, ни чем не отличаются от такой же агитки и пропаганды, просто с другим вектором.
Что-то я не вижу источника приведенной вами цитаты, ни в статье, ни в камментах, ни на wiki.
Вы сейчас со своими мыслями спорите?
Я не утверждал, что нельзя, можно, даже нужно. А вот про "но" я как раз писал, их много. Предлагаемый автором бриф требований не продуман, противоречив, категоричен и результатом его будет совок 2.0. такой же гротескный и пацаватый. Не оглядываться на историю — как минимум глупо.
Мелкие части приведенных систем вполне можно реализовать, например тема с одеждой и авто-подбором — это вполне здорово, но как обязаловка — это очень плохая идея, потому что есть целая группа людей с не стандартными мерками.
https://ru.wikipedia.org/wiki/Политические_репрессии_в_СССР
https://ru.wikipedia.org/wiki/Товарный_дефицит_в_СССР
https://uk.wikipedia.org/wiki/Голодомор_вУкраїні(1932—1933)
Ага, например во время сталинской реконструкции Москвы, счастье рекой лилось.
"были частью чего-то большого и были счастливы."
Конечно не было, просто свое мнение было не принято освещать))
УРСР. Если честно не вижу в этом ничего смешного.