Вообще не паримся, делаем впервую очередь для людей. Контент решает. На коммерческих сайтах хотелось бы видеть полезные статьи, по которым можно определится что нужно именно тебе в твоей ситуации, а не купить унитаз в москве.
>в Yii насмерть, оказывается, зашит Boostrap
это не так, вы можете использовать бутстрап, можете не использовать. Boostrap используется в утилитах yii, и в некоторых виджетах.
Мои мысли:
1. Ваш подход интересный, но трейты не заменят бихейвиоры на 100%, но где то их можно потеснить.
2. Я был бы рад, если бы softdelete был реализован на уровне ActiveRecord в самом yii
Хочу сказать спасибо за ваш продукт. Хотя с некоторыми инспекциями я не согласен (но их можно отключить в настройках) =)
Не могли бы вы более подробно что подразумевает каждый из сценариев?
У меня большие вопросы как к этому бенчмарку (как можно сравнивать водпресс приложение с кодом на ноде который просто отвечает хелло ворлд), так и компетентности автора статьи по ссылке (в коментах он вообще чушь несет, про хендшейки и установление сессий на стороне ноды). Если бы я сравнивал php с нодой, то сравнивал бы с reactphp.
В одном проекте я был свидетелем того, что разработчики придерживались идеи MVC, делали тонкие контроллеры и жирные модели. В результате чего можно было наблюдать несколько моделей из 10 000 — 15 000 строк кода, которые были связанны чуть ли не с большей половиной всего проекта. Естественно настал момент, когда все крестились и просто боялись их трогать, зная что если что-то сломают может полететь весь проект. Это не критично на небольшом проекте, но если проект набирает популярность и разрастается, ждите беды.
С таким подходом независимо от фрейма и яп будет такой результат. Yii2 не навязывает вам арихитектуру, это фреймворк в первую очередь.
Если все модели наследуем от ActiveRecord, то на выходе по перспективе получаем так-же букет из проблем. Возможно будет такая ситуация, когда мы унаследуете frontend и backend модели от common моделей, которую в свою очередь от ActiveRecord. Но что будет если вдруг по мимо общей логики, нам потребуется разная логика в frontend и backend приложениях? Скорее всего начнутся перекрывания сценариев, событий таких как afterSave, beforeSave и много других интересных штук. С которыми я сталкивался почти везде.
Если грамотно наследоваться от коммон модели, то таких проблем практически не будет. Говорю с уверенностью тк сам практикую такой подход.
Если приложение со сложной бизнес логикой, то основную валидацию я рекомендую делать описывать в модели формы, а не в основной модели, и тогда у вас не будет ни жирных моделей, ни проблем с перекрытием, ни проблем с мертвым кодом, когда вы выпилите какую-то функциональность.
ActiveForm, тут просто facepalm. Это не очень гибкая штука как и 90% виджетов Yii2, они рассчитаны на быструю разработку ну скажем прототипов или максимум админку. Но использовать эти виджеты в большом и сложном проекте не очень хорошая идея. Практически не реально воплощать в жизнь извращенные задачи клиентов. Еще как претензия, это то что разработчики Yii2 прилично смешали php код с js, это можно наблюдать в валидаторах. И на послед, это то что все поголовно зависит от jQuery. Не скажу, что это плохо, но есть еще такой замечательный framework как vanilla (если вы понимаете о чем я ;)).
Тот подход который навязывают виджеты действительно тяжеловесный, в большом и сложном проекте у вас скорее всего будут самописные (или переделанные) виджеты, тк все универсальное имеет много лишнего в угоду универсальности. JS часть виджетов нужно отключить на уровне ассетов и сгруппировать и упаковать grunt`ом например. ЭктивФорм надо уметь готовить, в процессе разработки у вас должно было появится понимаение какие и как формы используются, и уже имея понимание, нужно сделать свою обертку, благодаря которой у вас описание самыех сложных форм будет укладываться в несколько строк.
Расширения. Что касается расширений Yii2 (конечно-же от сторонних разработчиков), то 99% этих расширений решают только примитивные стандартные задачи. Если возникает суровая серьезная задача, то в 99% случаях Вам придется писать все самому.
Есть довольно качественные расширения, которые реализуют достаточно сложную функциональность, которую порой сам и за неделю не реализуешь, при этом они покрыты тестами, а разработчики активно общаются на гитхабе и принимают реквесты. Но есть и куча расширений-оберток над разными js либами и виджетами. Это есть в практически любом фреймворке. Для меня выбор расширения всегда начинается с просмотра кода, потом issues, и активности автора, лояльности на гитхабе.
В то время как приведённые в таблице комет сервера это законченные готовые приложения которые не надо доделывать для того что бы начать работать.
Использовал 3 реализации из вашей таблицы, в каждом из случаев приходилось доделывать, докручивать, писать репорты и учавствовать в баг фиксах. Возможно изза схожих проблем вы и занялись реализацией своего решения.
Есть мнение что HHVM потребляет гораздо больше cpu, чем php7. С учетом того, что php7 практически сравнялся с HHVM по производительности, при этом не имеет тех ограничений, в отличие от HHVM, последний вообще не вижу целесообразным в использовании. На своих проектах при миграции на php7 получился прирост ~2 раза по скорости генерации страницы и по потреблению ОЗУ.
Карин Жан-Пьер не говорила слово "СВО"
Осветите пожалуйста NeatComet в одной из следующих статей.
это не так, вы можете использовать бутстрап, можете не использовать. Boostrap используется в утилитах yii, и в некоторых виджетах.
1. Ваш подход интересный, но трейты не заменят бихейвиоры на 100%, но где то их можно потеснить.
2. Я был бы рад, если бы softdelete был реализован на уровне ActiveRecord в самом yii
Не могли бы вы более подробно что подразумевает каждый из сценариев?
С таким подходом независимо от фрейма и яп будет такой результат. Yii2 не навязывает вам арихитектуру, это фреймворк в первую очередь.
Если грамотно наследоваться от коммон модели, то таких проблем практически не будет. Говорю с уверенностью тк сам практикую такой подход.
Если приложение со сложной бизнес логикой, то основную валидацию я рекомендую делать описывать в модели формы, а не в основной модели, и тогда у вас не будет ни жирных моделей, ни проблем с перекрытием, ни проблем с мертвым кодом, когда вы выпилите какую-то функциональность.
Тот подход который навязывают виджеты действительно тяжеловесный, в большом и сложном проекте у вас скорее всего будут самописные (или переделанные) виджеты, тк все универсальное имеет много лишнего в угоду универсальности. JS часть виджетов нужно отключить на уровне ассетов и сгруппировать и упаковать grunt`ом например. ЭктивФорм надо уметь готовить, в процессе разработки у вас должно было появится понимаение какие и как формы используются, и уже имея понимание, нужно сделать свою обертку, благодаря которой у вас описание самыех сложных форм будет укладываться в несколько строк.
Расширения. Что касается расширений Yii2 (конечно-же от сторонних разработчиков), то 99% этих расширений решают только примитивные стандартные задачи. Если возникает суровая серьезная задача, то в 99% случаях Вам придется писать все самому.
Есть довольно качественные расширения, которые реализуют достаточно сложную функциональность, которую порой сам и за неделю не реализуешь, при этом они покрыты тестами, а разработчики активно общаются на гитхабе и принимают реквесты. Но есть и куча расширений-оберток над разными js либами и виджетами. Это есть в практически любом фреймворке. Для меня выбор расширения всегда начинается с просмотра кода, потом issues, и активности автора, лояльности на гитхабе.
Использовал 3 реализации из вашей таблицы, в каждом из случаев приходилось доделывать, докручивать, писать репорты и учавствовать в баг фиксах. Возможно изза схожих проблем вы и занялись реализацией своего решения.