Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 238
Интересна текущая расстановка сил на рынке веб-фреймворков на PHP. Опрос решил сделать после прочтения вот этого топика. Хотелось бы узнать пристрастия хабрасообщества, и их причины. Если варианта нет, пишите в комментах — добавлю. Если остановитесь на пункте «CMS-CMF», было бы интересно узнать, почему не юзаете «полноценный» фреймворк. Прошу не разводить холиваров, выбор рабочего инструмента — личное дело каждого, было бы интересно узнать причины этого выбора.
расстановка сил не свяана с количеством пользующихся фреймворком. Допустим, у Symfony один из самых высоких порогов входа, соответственно пользуются меньше, но он пожалуй, самый сильный из представленных. В то же время части из Zend Framework применяются совместно с Symfony.
p.s. Кстати, есть ещё огромная библиотека PEAR, которую тоже бы следовало включить в список.
p.s. Кстати, есть ещё огромная библиотека PEAR, которую тоже бы следовало включить в список.
полагаю, что фреймворки более популярны в сравнительно узком сегменте коммерческого коммандного программирования.
для php в целом, как основного языка веб-разработки-- больше доля фрилансеров-одиночек, чаще выбирающих «чистый php» плюс «свои наработки», (которые, как правило, не хочется определять столь громким термином, как «фреймворк»))
для php в целом, как основного языка веб-разработки-- больше доля фрилансеров-одиночек, чаще выбирающих «чистый php» плюс «свои наработки», (которые, как правило, не хочется определять столь громким термином, как «фреймворк»))
По-моему наоборот, крупные (и не очень) коммерческие разработчики используют готовые фреймворки как таковые (каркасы приложений, где, грубо говоря, код пишется где-то между точкой входа и ядром, а не набор полезных компонентов) реже, чем фрилансеры-одиночки, не ограниченные в выборе средств ни корпоративными политиками, ни лицензионными ограничениями, но ограниченные временем на разработку. Другое дело, что часто и фрилансеров ограничивают (банальный пример — заказчик не может понять зачем ему 10 Мб кода на обработку формы и админку к ней, по крайней мере пока не покажешь ему админку и форму, созданные скаффолдингом буквально за 5 минут), или они ограничивают себя сами из-за плохой лени.
Ой вы не правы.
Работаю в СЕО компании. Через меня проходят дюжины сайтов.
И как вы думаете что доминирует?
Ага CMS: Joomla, WordPress (и сайты на нем делают), WebAssyst, Netcat, Modx
Самописок мало (3 сайта, если отбросить html сайты), на фреймровках еще меньше. За 8 месяцев работы пришел 1н на смарти, 1н на код-игнайтере.
Работаю в СЕО компании. Через меня проходят дюжины сайтов.
И как вы думаете что доминирует?
Ага CMS: Joomla, WordPress (и сайты на нем делают), WebAssyst, Netcat, Modx
Самописок мало (3 сайта, если отбросить html сайты), на фреймровках еще меньше. За 8 месяцев работы пришел 1н на смарти, 1н на код-игнайтере.
«Полноценный» в моем понимании — чистый CMF, Drupal это всё-таки больше CMS система.
Ряд CMS, предоставляющих API для расширения своей функциональности, претендуют на звание CMF, хотя провести чёткую границу между CMS и CMF порой сложно. К примерам CMF, также являющимися готовыми CMS, можно отнести такие системы, как Plone, MODx, Drupal, eZ publish или TYPO3.Wikipedia
Долго ждал такого опроса. Так как встала проблема выбора фреймворка для изучения и дальнейшей работы с ней.
Предварительно уже выбрал Yii и начал изучать документацию, надеюсь не ошибся. В любом случае очень интересно посмотреть на чем люди пишут.
Предварительно уже выбрал Yii и начал изучать документацию, надеюсь не ошибся. В любом случае очень интересно посмотреть на чем люди пишут.
Не ошиблись, скорость разработки на Yii очень высокая и он динамично развивается + хорошее русскоязычное сообщество.
Только вот плохо уроков мало. Одного примера с созданием блога на их сайте явно мало. Скринкасты выглядят суховато. Но я надеюсь все это придет со временем.
Да и с опытом думаю все это придет, главное начать что-то делать.
Да и с опытом думаю все это придет, главное начать что-то делать.
Мне кажется полное руководство, достаточно объемлющее + на англоязычном форуме можно много интересного найти.
Что-нибудь слышно, когда в YII на PHP 5.3 namespace нормальный перейдут? А то CClassName утомляет…
Чем? Были реальные случаи конфликтов? Разве не будет больше утомлять писать каждый раз yii/base/ClassName?
На сайте написано, что возможно, альфа выйдет в декабре.
А так, префикс С меня не напрягает, для своего кода можно без проблем использовать неймспейсы. Анонимные функции для событий реализованы, не хватает только Late Static Bindings для моделей, но это не критично.
А так, префикс С меня не напрягает, для своего кода можно без проблем использовать неймспейсы. Анонимные функции для событий реализованы, не хватает только Late Static Bindings для моделей, но это не критично.
Yii очень хорош.
Основной функционал при MVC подходе развит (Авторизация, пользовательские настрйки, права)
+ он не тащит груза php 4той версии.
У него одно плохо. Клиентсайд ужасный. Лучше его не использовать.
Эвенты навешиваются отвратительно. Все что подгружается с помощью аякса, глючит, если использовать с вложением друг в друга.
Основной функционал при MVC подходе развит (Авторизация, пользовательские настрйки, права)
+ он не тащит груза php 4той версии.
У него одно плохо. Клиентсайд ужасный. Лучше его не использовать.
Эвенты навешиваются отвратительно. Все что подгружается с помощью аякса, глючит, если использовать с вложением друг в друга.
А как оно правильно читается?
-на чем пишешь?
-на «иайай»
или так
— на «иеее»
а может так
— на «иии»
в общем название любопытное
-на чем пишешь?
-на «иайай»
или так
— на «иеее»
а может так
— на «иии»
в общем название любопытное
Может, отдельно еще вынести Bitrix?
На пхп в основном использую cmf drupal, что то больше предпочитаю написать на Python&Django.
Не использую фреймверки.
Для небольший сайтов с парой, тройкой функций не вижу смысла тянуть целый фреймвёрк.
Для игрового проекта также решил не использовать фреймвёрк. Я сделал свою простую архитектуру, без излишеств.
Я за индивидуальный подход в собственных проектах и разработке простых сайтов. Фреймвёрк лишь усложняет структуру, порой приходится натыкаться на чужое слабоумие (лучше дело иметь со своим).
ИМХО, чем больше проект завязан на структуру стороннего разработчика, тем сложнее делать в нём изменения. Для многих вещей приходится писать свои адаптеры и прокси. Что касается библиотек — их нужно использовать по мере возможности, так как они не задают общей структуры и их легко заменить.
Для небольший сайтов с парой, тройкой функций не вижу смысла тянуть целый фреймвёрк.
Для игрового проекта также решил не использовать фреймвёрк. Я сделал свою простую архитектуру, без излишеств.
Я за индивидуальный подход в собственных проектах и разработке простых сайтов. Фреймвёрк лишь усложняет структуру, порой приходится натыкаться на чужое слабоумие (лучше дело иметь со своим).
ИМХО, чем больше проект завязан на структуру стороннего разработчика, тем сложнее делать в нём изменения. Для многих вещей приходится писать свои адаптеры и прокси. Что касается библиотек — их нужно использовать по мере возможности, так как они не задают общей структуры и их легко заменить.
Вот как раз для небольших сайтов фреймворки использовать удобнее, имхо. Для них количество «инфраструктурного» кода (роутинг, работа с формами, валидация, кэширование, шаблонизация, доступ к БД, админка и прочая) велико по сравнению с собственно логикой сайта. Фреймворк всё это предоставляет, зачастую абсолютно прозрачно и с минимальной привязкой к фреймворку, например только в коде контроллера, где происходит связка модели и вида/шаблона.
Если по мере развития проекта излишняя универсальность (а значит и неизбежный оверхид)фреймворка становится проблемой, то заменяются отдельные компоненты на самописные. Первый кандидат обычно DBAL/ORM — универсальные механизмы заменяются на СУБД- и схемоспецифичные, но эти изменения строго локализованы, а не размазаны по всему проекту. И особой привязки к «навязанной» схеме нет — модели и контроллеры обычные «plain old PHP objects» ни к чему не привязанные, ни от чего не наследуемые, сам фреймворк работает с ними интроспекцией и рефлексией, но вам никто не мешает реализовать более эффективные способы, пускай и более привязанные к вашей задаче.
Не использовать фреймворки, по-моему, имеет смысл как раз на крупных проектах, где инфраструктурного кода заведомо много меньше основного и при использовании фреймворка его всё равно придётся менять на более эффективный в конкретных условиях, оставив от оригинального фреймворка по сути только каркас :) и, может быть, незначительные по оверхиду компоненты типа валидации форм и интернационализации. И то, возможно, имеет смысл использовать готовый фреймворк, предложив (если речь об open source) свои реализации критичных компонентов с теми же интерфейсами сообществу, не затрагивая другие. Или предложить расширить интерфейсы, если вам кажется, что существующие уж очень сильно вас связывают или дают значительный оверхид.
Если по мере развития проекта излишняя универсальность (а значит и неизбежный оверхид)фреймворка становится проблемой, то заменяются отдельные компоненты на самописные. Первый кандидат обычно DBAL/ORM — универсальные механизмы заменяются на СУБД- и схемоспецифичные, но эти изменения строго локализованы, а не размазаны по всему проекту. И особой привязки к «навязанной» схеме нет — модели и контроллеры обычные «plain old PHP objects» ни к чему не привязанные, ни от чего не наследуемые, сам фреймворк работает с ними интроспекцией и рефлексией, но вам никто не мешает реализовать более эффективные способы, пускай и более привязанные к вашей задаче.
Не использовать фреймворки, по-моему, имеет смысл как раз на крупных проектах, где инфраструктурного кода заведомо много меньше основного и при использовании фреймворка его всё равно придётся менять на более эффективный в конкретных условиях, оставив от оригинального фреймворка по сути только каркас :) и, может быть, незначительные по оверхиду компоненты типа валидации форм и интернационализации. И то, возможно, имеет смысл использовать готовый фреймворк, предложив (если речь об open source) свои реализации критичных компонентов с теми же интерфейсами сообществу, не затрагивая другие. Или предложить расширить интерфейсы, если вам кажется, что существующие уж очень сильно вас связывают или дают значительный оверхид.
Как раз переферийный код в небольших проектах сводится лишь к DAO/ORM. Остальной код затачивается под конкретную задачу, ибо универсальность не нужна.
Например нужно написать магазин для цветочной лавки. Нужно:
1. Список букетов (изображение, цена, кнопка купить)
2. Форма отправить заказ (простая мейл форма со списком покупок)
3. Форма отслеживания заказа
4. Форма редактирования списка
Список товара делается одним SQL запросом и for(), который формирует страницу
Текущий список заказа хранится в сессии
Адресс, телефон, имя передаются через форму и сохраняются одним SQL запросом.
В три строчки отправляется письмо.
Еще один SQL запрос формирует запись о заказе. ID используется для получения статуса.
Зачем тут фреймвёрк? Что бы «шкурки» менять для разных магазинов? Проще сделать пару функций с общей структурой и параметром "$cssClasses", и потом просто добавить в новый дизайн.
ORM тут вообще не нужен. Максимум DAO, что бы перекрутить на другу бд. Капча, отправка письма — используем пару библиотек. Редактор списка тоже форма с двумя запросами (удалить, сохранить).
Проверку логина, пароля можно вообще средствами httpd сделать, но и свой написать не сложно (я про логин в «админку»)
Захотели добавить поле описание к товару: поправили запорос, поправили функцию отображения.
Используя фреймвёрк мы получим лишний «жир» в виде ненужного функционала + баги в нём.
Фреймвёрк нужно использовать при поточном производстве схожих проектов, и лучше написать свой — который будет максимально подходить именно под этот тип проектов, а не иметь встроенный блог, чат, голосование, RSS для корпоративного сайта с документацией.
Например нужно написать магазин для цветочной лавки. Нужно:
1. Список букетов (изображение, цена, кнопка купить)
2. Форма отправить заказ (простая мейл форма со списком покупок)
3. Форма отслеживания заказа
4. Форма редактирования списка
Список товара делается одним SQL запросом и for(), который формирует страницу
Текущий список заказа хранится в сессии
Адресс, телефон, имя передаются через форму и сохраняются одним SQL запросом.
В три строчки отправляется письмо.
Еще один SQL запрос формирует запись о заказе. ID используется для получения статуса.
Зачем тут фреймвёрк? Что бы «шкурки» менять для разных магазинов? Проще сделать пару функций с общей структурой и параметром "$cssClasses", и потом просто добавить в новый дизайн.
ORM тут вообще не нужен. Максимум DAO, что бы перекрутить на другу бд. Капча, отправка письма — используем пару библиотек. Редактор списка тоже форма с двумя запросами (удалить, сохранить).
Проверку логина, пароля можно вообще средствами httpd сделать, но и свой написать не сложно (я про логин в «админку»)
Захотели добавить поле описание к товару: поправили запорос, поправили функцию отображения.
Используя фреймвёрк мы получим лишний «жир» в виде ненужного функционала + баги в нём.
Фреймвёрк нужно использовать при поточном производстве схожих проектов, и лучше написать свой — который будет максимально подходить именно под этот тип проектов, а не иметь встроенный блог, чат, голосование, RSS для корпоративного сайта с документацией.
Список товара делается одним SQL запросом и for(), который формирует страницу… В три строчки отправляется письмо.
Еще один SQL запрос формирует запись о заказе. ID используется для получения статуса.
Да, это прекрасно, пока вам не выкатят кучу требований на изменение проекта. Тогда для изменения одной финтифлюшке в виде, вам придётся перелопатить кучу кода.
Захотели добавить поле описание к товару: поправили запорос, поправили функцию отображения.
А теперь представьте, что вам надо переименовать столбец в БД, если у вас куча таких запросов.
Зачем тут фреймвёрк?
Для увеличения гибкости веб-приложения, для открытости изменениям, для лучшего контроля управления в программе и возможности не писать велосипеды, а использовать готовые, которые оттестированы и оптимизированы.
Зачем цветочной лавке гибкость? Она предполагает торговать вооружением разных типов и разных сборок?
В ТЗ есть «написать простой магазин», так зачем писать его расширяемым? Нужно решать конкретную задачу.
Когда встанет задача расширения (не единоразового добавления поля), тогда и надо думать про фреймвёрк, движок и рефакторинг. Пока требуется делать просто, надо делать просто.
Из задачи видно, что кучи полей не предполагается.
Но подходы безусловно разные могут быть, даже и в простецких задачах. Но всё же советую вдумываться в поставленную задачу и её перспективы =)
В ТЗ есть «написать простой магазин», так зачем писать его расширяемым? Нужно решать конкретную задачу.
Когда встанет задача расширения (не единоразового добавления поля), тогда и надо думать про фреймвёрк, движок и рефакторинг. Пока требуется делать просто, надо делать просто.
Из задачи видно, что кучи полей не предполагается.
Но подходы безусловно разные могут быть, даже и в простецких задачах. Но всё же советую вдумываться в поставленную задачу и её перспективы =)
А зачем вы данные от логики будете отделять? Разве в ТЗ сказано, что вёрстка будет изменяться? Но вы вводите функции отображения, а не пишете всё в одном файле в глобальной области видимости, хотя так будет эффективнее.
Если фреймворк позволяет при тех же или меньших трудозатратах по сравнению с разработкой с нуля сделать приложение расширяемым и более поддерживаемым, то почему бы это не сделать?
Если фреймворк позволяет при тех же или меньших трудозатратах по сравнению с разработкой с нуля сделать приложение расширяемым и более поддерживаемым, то почему бы это не сделать?
когда вам нужна кофемолка — вы же не покупаете кухонный камбаин? Хотя он тоже умеет молоть кофе.
Так и тут — зачем мне тянуть фреймвёрк, настраивать его, отключать ненужный функционал, что бы потом может быть когда нибудь его включить?
Так и тут — зачем мне тянуть фреймвёрк, настраивать его, отключать ненужный функционал, что бы потом может быть когда нибудь его включить?
Если кофемолка стоит столько же, а то и дороже, то почему нет? И уж точно я вручную не молю кофе :)
Исхожу из того, что даже для такой фигни как в примере, не дольше создать приложение под фреймворком (если не в первый раз его используешь, конечно), чем с нуля. Зато потом, если понадобится, что-то что отключили, то достаточно будет только включить, а не писать опять с нуля или переводить на тот же фреймворк.
Исхожу из того, что даже для такой фигни как в примере, не дольше создать приложение под фреймворком (если не в первый раз его используешь, конечно), чем с нуля. Зато потом, если понадобится, что-то что отключили, то достаточно будет только включить, а не писать опять с нуля или переводить на тот же фреймворк.
когда вам нужна кофемолка — вы же не покупаете кухонный камбаин? Хотя он тоже умеет молоть кофе.
Суть именно в том, что вы можете взять кухонный комбайн и сделать из него кофемолку или что-то другое — неважно. Использовать фрейм — хорошо, тут и спорить не о чем. Вопрос в другом, один кодер хорошо разобрался в фрейме и будет использовать его возможности по полной, а другой — потратил 10 минут лишь на беглое прочтение quick start guide и сел кодить с полной уверенностью что он все знает. Тут то и начинаются разногласия. Первый кодер осознал архитектуру фрейма, второй — нет. Первый будет по полной использовать возможности фрейма, второй поймет, что затраты на изучение фрейма того не стоят и выбросит его, свалив все на его «дурацкую и запутанную архитектуру».
Сравнение фреймворка с готовым комбайном — неверно. Я бы скорее сравнил его с набором инструментов. Наглядный пример: есть задача смастерить тот же кухонный комбайн, есть набор качественных, проверенных многими инструментов, есть желание. Я думаю лишь о решении задачи, более мне ничего не мешает, пользуюсь инструментами которые у меня имеются, все чисто и гладко. Теперь проведем аналогию, когда мы пишем с нуля (и\или имеем никем не проверенную, «мощную» (с нашей точки зрения) архитектуру). Пример с тем же комбайном: есть задача смастерить кухонный комбайн, есть набор инструментов сделанный собственными руками, но еще ни разу не проверенный на деле, сомнительного качества, мы точно не знаем какие инструменты нам понадобятся, но думаем что для решения задачи хватит того что есть. Начинаем созидать и понимаем, что многого не знали и наши инструменты нужно допиливать и допиливать. Время идет, а мы все дорабатываем свои инструменты, вместо того чтобы решать поставленную задачу. Жена все время пилит: «Вася мне нужен кухонный комбайн!!! >_<», а вы все ломаете голову как сделать ключ на 8 :)
А зачем ездить на машине ведь есть велосипед?)
Вы сейчас ООП описали
>Зачем тут фреймвёрк?
Чтобы написать всё это быстрее, чем с нуля :)
Чтобы написать всё это быстрее, чем с нуля :)
Для такой фигни как в примере фреймвёрк займёт больше времени.
Don't shave that yakk:
sethgodin.typepad.com/seths_blog/2005/03/dont_shave_that.html
Статья на английском, но вкратце: занимайтесь решением своей задачи, не тратя времени на детали и мелочи, которые эта задача порождает.
А по большому счету — используйте опыт тех, кто уже наступал на грабли и проложил дорожку вокруг них в виде фреймворка… и даже заборчик поставил.
sethgodin.typepad.com/seths_blog/2005/03/dont_shave_that.html
Статья на английском, но вкратце: занимайтесь решением своей задачи, не тратя времени на детали и мелочи, которые эта задача порождает.
А по большому счету — используйте опыт тех, кто уже наступал на грабли и проложил дорожку вокруг них в виде фреймворка… и даже заборчик поставил.
>Для такой фигни как в примере фреймвёрк займёт больше времени.
Складывается впечатление, что вы просто не работали (основательно) ни с одним фреймворком или просто путаете его с CMS
Складывается впечатление, что вы просто не работали (основательно) ни с одним фреймворком или просто путаете его с CMS
Фреймвёрк нужно использовать при поточном производстве схожих проектов, и лучше написать свой — который будет максимально подходить именно под этот тип проектов, а не иметь встроенный блог, чат, голосование, RSS для корпоративного сайта с документацией.
Уважаемый, Вы уверены, что знаете что такое фреймворк? Вы не путаете его в CMS?
имеет смысл использовать готовый фреймворк, предложив (если речь об open source) свои реализации критичных компонентов с теми же интерфейсами сообществу, не затрагивая другие. Или предложить расширить интерфейсы, если вам кажется, что существующие уж очень сильно вас связывают или дают значительный оверхид.
Вот это называется ZF-way (говорю безотносительно к фреймворку, в Ruby on Rails, Symfony и т.д. пропагандируется тот же принцип, этакое всеобщее благо и совместная community-разработка). Почему программисты не идут по этому способу, а в большинстве своем хардкодят?
>Фреймвёрк лишь усложняет структуру
Фреймворк скорее предоставляет «инструмент», а структуру вы строите сами.
Фреймворк скорее предоставляет «инструмент», а структуру вы строите сами.
Блин, я конечно хотел написать ответ на коммент chernser (но промахнулся).
ИМХО, фреймворк — гибкий каркас, чтобы не делать спагетти-кода, и чтобы он не скатывался в пластилин.
В большенстве случаев приходится подстраиваться под этот «интсрумент».
Например, нет смысла писать свой DAO, когда уже есть слой доступа к БД во фреймвёрке, но иногда этот слой не соответствует извращенным требованиям проекта и пишется свой костыль, всё равно.
Например, нет смысла писать свой DAO, когда уже есть слой доступа к БД во фреймвёрке, но иногда этот слой не соответствует извращенным требованиям проекта и пишется свой костыль, всё равно.
Фреймворк предоставляет инструмент и задает типовой каркас приложения. Наличие типового каркаса снижает стоимость вхождения в проект.
Исторически сложилось, что выбирать в 2001-2003 годах особо было нечего.
Был mamba (сейчас joomla), появился первый Drupal
Изучал их для создания собственного фреймворка.
Был mamba (сейчас joomla), появился первый Drupal
Изучал их для создания собственного фреймворка.
Я не знал о фреймворках, когда начинал изучать php и со временем наработал свой фреймворк (если конечно его можно так назвать). Сторонние фреймворки не люблю по причине того, что больше нравится писать на «чистом» php. Фреймворки делают почти всю интересную работу, но интересную лишь в целях образования (лично для меня), бывают случаи, когда нужно здесь и сейчас получить определенный результат, тут конечно единственный выход использовать фреймворк.
Еще заметил что в некоторых компаниях используется фреймворк, чтобы в команде не было недопонимания кода других участников.
Еще заметил что в некоторых компаниях используется фреймворк, чтобы в команде не было недопонимания кода других участников.
Codeigniter. Низкий порог вхождения. Все основные функции имеются, небольшой размер.
тоже с него начинал, переползаю потихоньку на Kohana…
Я взялся за PHP, имея за спиной приличный опыт разработки на Java. Codeigniter расстроил наличием костылей в объектной модели. А вот Kohana 3 особых нареканий не вызвала. Использую в связке с Twig.
Гляньте ещё на symfony2 — знакомый джавист, глянув на мой код, сказал, что это практически Java, только $ в глаза бросается :)
На работе достался проект на CI. Не понравился. Слишком тоненький, примитивный. Да и PHP4 чувствуется.
выбрали Yii
пока всем довольны, правда, он немного сыроват
пока всем довольны, правда, он немного сыроват
Давно все проекты делаем на Yii.
Гибкость, легкость, скорость разработки возросла в разы. «сырость» в самой первой версии. сейчас, после нескольких апдейтов уже все починили и с ним нет никаких проблем.
Гибкость, легкость, скорость разработки возросла в разы. «сырость» в самой первой версии. сейчас, после нескольких апдейтов уже все починили и с ним нет никаких проблем.
Не использую фреймворки.
Раньше работал с CodeIgniter, но со временем, когда набрался опыта, отказался от использования фрейморков.
Фреймворки хороши на начальном этапе, когда опыт не позволяет писать сложные вещи. А потом, когда знания накопятся, лучше перейти на свои наработки.
Раньше работал с CodeIgniter, но со временем, когда набрался опыта, отказался от использования фрейморков.
Фреймворки хороши на начальном этапе, когда опыт не позволяет писать сложные вещи. А потом, когда знания накопятся, лучше перейти на свои наработки.
Что вы думаете насчет, реализации своих знаний и опыта в расширения фреймворков (доп. библиотеки, модули, бандлы и т.д.)? Это позволяет делиться опытом.
> Фреймворки хороши на начальном этапе, когда опыт не позволяет писать сложные вещи.
А по-моему это всё равно что сказать PHP/Ruby/Pyton хороши на начальном этапе, а сложные вещи нужно писать на С++. Существует НЕ так много проектов, которым нужен нестандартный каркас, 99% из них используют сразу всё из DB/ЧПУ/Logins/MVC/ORM/Cache (некоторые еще i18n/Forms), и фреймворки предоставляют всё это, плюс полезные вещи как дебаг панели и т.п. Работаю с Symfony и считаю архинеэффективным если бы я все эти стандартные вещи находил (писал?) и интегрировал/связывал сам.
А по-моему это всё равно что сказать PHP/Ruby/Pyton хороши на начальном этапе, а сложные вещи нужно писать на С++. Существует НЕ так много проектов, которым нужен нестандартный каркас, 99% из них используют сразу всё из DB/ЧПУ/Logins/MVC/ORM/Cache (некоторые еще i18n/Forms), и фреймворки предоставляют всё это, плюс полезные вещи как дебаг панели и т.п. Работаю с Symfony и считаю архинеэффективным если бы я все эти стандартные вещи находил (писал?) и интегрировал/связывал сам.
CodeIgniter очень слабый фреймворк, решает проблем меньше, чем создает, из-за поддержки php4 много костылей, ORM нет(даже обертка для базы без нормального построителя запросов), хелперы недоделанные, автолоада нет, модульности нет, вывод вьюшки неоправданно усложнен… Я мы тоже забил на фреймворки, если бы не знал про Zend, Symfony, Yii.
Можно про костыли CodeIgniter с примерами и чем он вас так тяготит с поддержкой php4?
А то все говорят такое, а примеров привести не могут, словно им запертили __constuct писать или свои паттерны фабрик использовать, перегружать классы и использовать кучу библиотек не тянущих php4.
А то все говорят такое, а примеров привести не могут, словно им запертили __constuct писать или свои паттерны фабрик использовать, перегружать классы и использовать кучу библиотек не тянущих php4.
Как минимум повсеместное использование глобальных фукций, можно было избежать извращений вроде «if (! function_exists('form_open')) {...}» используя статичные методы.
В коде куча полуоберток:
function view($view, $vars = array(), $return = FALSE)
{
return $this->_ci_load(array('_ci_view' => $view, '_ci_vars' => $this->_ci_object_to_array($vars), '_ci_return' => $return));
}
Если посмотреть как работают вьюшки, становится понятно, что сделать что-то аля yii/renderPartial можно только через костыль вроде «load_class('Loader', 'core')->view(...)», а из контента в layout нельзя нормально передать данные, кстати, работу с layout еще нужно написать.
> А то все говорят такое, а примеров привести не могут, словно им запертили __constuct писать или свои паттерны фабрик использовать, перегружать классы и использовать кучу библиотек не тянущих php4.
Чтобы привести хорошие примеры надо с _этим_ работать, осмотор кода показал что с _этим_ работать нельзя. Ничего не запретили, но сами использовать не стали, отсюда и вывод, написать хороший код на CI можно, но это займет не месяц, а год и от CI ничего не останется, проще сразу писать с нуля.
З. Ы. пробовал писать на CI года 3 назад, отказался в пользу Kohana и я смотрю не зря, с того времени CI не изменился.
В коде куча полуоберток:
function view($view, $vars = array(), $return = FALSE)
{
return $this->_ci_load(array('_ci_view' => $view, '_ci_vars' => $this->_ci_object_to_array($vars), '_ci_return' => $return));
}
Если посмотреть как работают вьюшки, становится понятно, что сделать что-то аля yii/renderPartial можно только через костыль вроде «load_class('Loader', 'core')->view(...)», а из контента в layout нельзя нормально передать данные, кстати, работу с layout еще нужно написать.
> А то все говорят такое, а примеров привести не могут, словно им запертили __constuct писать или свои паттерны фабрик использовать, перегружать классы и использовать кучу библиотек не тянущих php4.
Чтобы привести хорошие примеры надо с _этим_ работать, осмотор кода показал что с _этим_ работать нельзя. Ничего не запретили, но сами использовать не стали, отсюда и вывод, написать хороший код на CI можно, но это займет не месяц, а год и от CI ничего не останется, проще сразу писать с нуля.
З. Ы. пробовал писать на CI года 3 назад, отказался в пользу Kohana и я смотрю не зря, с того времени CI не изменился.
Вас это напрягает? А то что использовать ООП лишь для namespace нет? :)
Ничто не мешает вам перегрузить эти стандартные функции.
Хотите вьюшек в Wiki лежит уже давно парочка библиотек для Twig, включайте. К чему идут все фрэймворки как к заменяемости желаемых компонент другими у CI есть.
Ничто не мешает вам перегрузить эти стандартные функции.
Хотите вьюшек в Wiki лежит уже давно парочка библиотек для Twig, включайте. К чему идут все фрэймворки как к заменяемости желаемых компонент другими у CI есть.
Без ооп для неймспейса ломается ооп впринципе, т. к. из объекта нельзя без костылей создать глобальную функцию.
Зачем Twig, php сам по себе шаблонизатор. Все сводится к тому, что если писать на CI не хелло ворлд, надо менять большую часть компонентов фреймворка, шикарно, еще и без нормального ооп.
Зачем Twig, php сам по себе шаблонизатор. Все сводится к тому, что если писать на CI не хелло ворлд, надо менять большую часть компонентов фреймворка, шикарно, еще и без нормального ооп.
Ну и как все живут до 5.3 версии PHP пока namespace не было. Но обертывать кучу функций внутрь объекта это извращение всё же, чтобы потом юзать их статикой. Словно всё ПО на ООП пишется, нет, спокойно люди пишут и на СИ без ООП на PHP тоже можно без объектов писать, тем более где это не надо.
Ну вопрос по тому какой из PHP шаблонизатор с его дозволенностью во view использовать код это еще можно долго обсуждать. Добавить, а не заменить если так хочется вам partial шаблонизатора, вот выход с Twig.
У вас большой опыт CI? У меня более 3х лет, но я не меняю в нём большую часть компонент, а расширил его один раз закинув файлы в library — HMVС, MY_Model, MY_Router, ApplicationController, BackendController и работаю, пишу проекты больше че «хэлло ворлд», что я делаю не так?
Фрэймворк не панацея, он даже может быть не модным, иметь внутри не красивые кишки, но если он в ваших руках решает поставленные задачи быстро и с нужным результатом — он ваш. Нет ищите другой, ни один фрэймворк не панацея от кривых рук.
Ну вопрос по тому какой из PHP шаблонизатор с его дозволенностью во view использовать код это еще можно долго обсуждать. Добавить, а не заменить если так хочется вам partial шаблонизатора, вот выход с Twig.
У вас большой опыт CI? У меня более 3х лет, но я не меняю в нём большую часть компонент, а расширил его один раз закинув файлы в library — HMVС, MY_Model, MY_Router, ApplicationController, BackendController и работаю, пишу проекты больше че «хэлло ворлд», что я делаю не так?
Фрэймворк не панацея, он даже может быть не модным, иметь внутри не красивые кишки, но если он в ваших руках решает поставленные задачи быстро и с нужным результатом — он ваш. Нет ищите другой, ни один фрэймворк не панацея от кривых рук.
Zend и Fat-Free
Drupal
Пробовал Cake, CI, ZF — остановился на symfony2. Правда показал свой код знакомому джависту, который когда-то писал на PHP3 и он спросил «а что тут от PHP осталось кроме $ перед переменными? Даже XML конфиги почти такие же портянки!» :)
Yes it is — Я думаю этим все сказано.
Kohana. Мне, по большому счету, от фреймворка нужна скорость, модульность, удобная структура для MVC и не нужны в базе всякие ORM-ы, генераторы HTML и прочее и прочее. Все это я получил.
можете еще пару слов о Kohana3 написать? Я вот просто посмотрел код одного проекта — вроде все понятно и ничего лишнего. Какие слабые места при разработке? (скорость работы, я так понял, нормальная).
Как там дела с namespace и прочими плюшками PHP 5.3? Просто ZF2 и Symfony2 сейчас еще в разработке, а Kohana подкупает что у нее стабильные релизы.
Как там дела с namespace и прочими плюшками PHP 5.3? Просто ZF2 и Symfony2 сейчас еще в разработке, а Kohana подкупает что у нее стабильные релизы.
Плюшки PHP 5.3 вообще не используются и вроде бы как даже не планируются. Но вроде бы как на 5.3 работает нормально и не выкидывает DEPRECATED ошибки.
Kohana хороша, если вы хотите иметь полный контроль над фреймворком и готовы за это платить удобством. Тут нету из коробки кодогенератов, орм слабенький, нету миграций. Но вы взамен получаете очень быстрый и управляемый код. Переопределяется все — любой класс фреймворка, класс модуля, конфигурационный файл. Ничего не скажу по поводе генерации форм, валидации, работы с HTML, так как у меня все данные в json гоняются и я не сталкиваюсь с такими вещами.
Еще я бы хотел отметить высокое качество исходного кода. Если какого-то момента нет в документации — можно смело смотреть исходники и все очень быстро становится понятным.
Kohana хороша, если вы хотите иметь полный контроль над фреймворком и готовы за это платить удобством. Тут нету из коробки кодогенератов, орм слабенький, нету миграций. Но вы взамен получаете очень быстрый и управляемый код. Переопределяется все — любой класс фреймворка, класс модуля, конфигурационный файл. Ничего не скажу по поводе генерации форм, валидации, работы с HTML, так как у меня все данные в json гоняются и я не сталкиваюсь с такими вещами.
Еще я бы хотел отметить высокое качество исходного кода. Если какого-то момента нет в документации — можно смело смотреть исходники и все очень быстро становится понятным.
Вы говорите что все данный в json гоняете — как же в итоге формируется UI у вас? Меня этот вопрос недавно интересовал, но глубоко зарыться времени нет :(
Можете поведать парой предложений? Ну или статьей (заметкой) на хабре или еще где :)
Можете поведать парой предложений? Ну или статьей (заметкой) на хабре или еще где :)
Поддерживаю во всёми сказанном. Добавлю, что использую его именно с php5.3, полёт отличный.
Начинал с CodeIgniter, потом по работе пришлось изучить Zend Framework. Привык к нему, полюбил… Немного толстенький он, некоторые моменты можно было бы сделать лучше, но в целом очень нравится. Думаю ещё в ближайшее время Yii посмотреть.
На новой работе пишу сайты на каком-то движке фирмы, писаном без фреймворка, без паттернов, видимо без рефакторинга. И это ад. У меня есть 20 сайтов на ZF — дай мне любой и я сходу скажу какой файл надо править, чтобы сделать нужный фикс. На сайтах без фреймворка(а соответсвтенно и без единой структуры, с отличающимся поведением классов ядра если такое имеется) приходится каждый раз вспоминать где, что, как работает.
На новой работе пишу сайты на каком-то движке фирмы, писаном без фреймворка, без паттернов, видимо без рефакторинга. И это ад. У меня есть 20 сайтов на ZF — дай мне любой и я сходу скажу какой файл надо править, чтобы сделать нужный фикс. На сайтах без фреймворка(а соответсвтенно и без единой структуры, с отличающимся поведением классов ядра если такое имеется) приходится каждый раз вспоминать где, что, как работает.
Я долго присматривался к ZF, считая его главным претендентом на промышленный стандарт. Но в конце-концов симпатии склонились в сторону Kohana 3. ZF действительно какой-то толстенький. Ko3 в общих чертах реализует тот же подход. Все то же самое, но проще. Как результат, более высокая производительность и низкий уровень вхождения.
Полность согласен с тем, что навязываемая фреймворком структура проекта — великое благо. В чужой отсебятине ох как нелегко концы найти.
Полность согласен с тем, что навязываемая фреймворком структура проекта — великое благо. В чужой отсебятине ох как нелегко концы найти.
Cascade framework. Он пока ещё находится в активной разработки, документации по нему практически нет, но фреймворк с большим потенциалом. Если кому интересно — github.com/gorbunov/cascade/
Зависит от задачи.
Если что-то простое (скрипт) — не использую
Посложнее — свой мини-фреймворк
Ещё сложнее — мне проще подобрать готовое решение (CMS/CMF), которое иногда скрещиваю со своими наработками.
Если что-то простое (скрипт) — не использую
Посложнее — свой мини-фреймворк
Ещё сложнее — мне проще подобрать готовое решение (CMS/CMF), которое иногда скрещиваю со своими наработками.
Yii + Zend
Yii — когда надо быстро и без заморочек
Zend — когда надо гибко, плюс довольно часто использую его по-частям, а не всем фреймворком целиком, например, Zend_Mail
Yii — когда надо быстро и без заморочек
Zend — когда надо гибко, плюс довольно часто использую его по-частям, а не всем фреймворком целиком, например, Zend_Mail
Для диплома пишу на YII
По работе так сложилось что пишем без фреймворка, потому что ни разу еще не участвовал в проекте с 0, что на прошлой, что на текущей работе присоединялся к разработке уже работающего проекта.
На прошлой работе был Битрикс, на новой — все полностью самописное.
По работе так сложилось что пишем без фреймворка, потому что ни разу еще не участвовал в проекте с 0, что на прошлой, что на текущей работе присоединялся к разработке уже работающего проекта.
На прошлой работе был Битрикс, на новой — все полностью самописное.
Yii. Потому что он легкий, быстрый и очень хорошо документирован. И очень отзывчивое и компетентное русскоязычное сообщество. До этого использовала только голый PHP без фреймворков (поэтому этот вариант тоже отметила) и готовые CMS. Завершу перевод на Yii самого большого своего сайта, и начну изучать ZF — для начала с целью подключения отдельных модулей к Yii.
На работе — «голый» PHP, без всяких фреймворков. Да что там PHP, jQuery даже не используется нигде, так как проекты очень древние, а в большой фирме очень сложно ввести инновации какие-либо.
На подработке использую: обычно Joomla (так как веб-студия, с которой работаю, предочла иммено ее, даже для сайтов с 5 страницами :( ) и Opencart для магазинов.
Для своих проектов хочу YII ипользовать, очень уж понравился.
На подработке использую: обычно Joomla (так как веб-студия, с которой работаю, предочла иммено ее, даже для сайтов с 5 страницами :( ) и Opencart для магазинов.
Для своих проектов хочу YII ипользовать, очень уж понравился.
Если разработка коммерческая, то в основном CMS, т. к. это ощутимо ускоряет процесс, да и админский пользовательский интерфейс в CMS как правило целиком готов.
Если для себя, то либо самописный фреймворк, либо вообще без фреймворка. Хоть времени на разработку уйдёт больше, работать оно будет на порядок быстрей. Да и с точки зрения безопасности такой подход мне нравится больше.
Если для себя, то либо самописный фреймворк, либо вообще без фреймворка. Хоть времени на разработку уйдёт больше, работать оно будет на порядок быстрей. Да и с точки зрения безопасности такой подход мне нравится больше.
Не то, чтобы это чистой воды фреймворк, но платформа неплохая — использую MODx. Для совсем простеньких сайтов есть свое легковесное рукоделие.
Я использую Drupal и некий Spiral, мало кому известный :)
Yii + старые проекты на Zend'е. Отметил только Yii. Активный участник русскоязычного сообщества Yii.
Вот минусуйте меня, но не понимаю я тех людей которые не используют готовый фрейморк, а пишут свой. Работаю я с проектом на самописном фреймворке, хм по меньшей мере это убогое подобие фреймворка, которое кое как работает. Ну вот что такого в вашем самописном, чего не умеет ZF, CakePHP, Symfony и так далее? Вы в состоянии написать по нему разборчивую документацию с примерами и пояснениями? Как насчёт всяких там исправлений в безопасности и прочем? Сколько строк кода вы покрыли тестами? Сколько плагинов и сторонних библиотек интегрируются в ваш продукт? Сколько человек кроме Вас самого в состоянии, что то пояснить и дать разборчивый ответ? Всё равно наступит момент, когда станет ясно что самописный фреймворк больше не справляется с поставленными задачами.
>Ну вот что такого в вашем самописном, чего не умеет ZF, CakePHP, Symfony и так далее?
Частая причина — они умеют слишком много, мне столько не нужно и никто кроме меня этот код не увидит, а с фреймворком неизбежно будет оверхид и надо тратить время на изучение, а результат нужен вчера. А когда в ТЗ появляются новые фичи, которые свой фреймворк пока не умеет, проще уже реализовать её у себя, чем переводить проект на фреймворк, который уже давно умеет, поскольку это потребует переработки чуть более чем полностью даже при приличной архитектуре, не говоря о спагетти.
Частая причина — они умеют слишком много, мне столько не нужно и никто кроме меня этот код не увидит, а с фреймворком неизбежно будет оверхид и надо тратить время на изучение, а результат нужен вчера. А когда в ТЗ появляются новые фичи, которые свой фреймворк пока не умеет, проще уже реализовать её у себя, чем переводить проект на фреймворк, который уже давно умеет, поскольку это потребует переработки чуть более чем полностью даже при приличной архитектуре, не говоря о спагетти.
Да бросьте, полно легковесных фреймворков. Потом например в том же ZF и СakePHP есть возможность отключить не нужные компоненты.
> мне столько не нужно и никто кроме меня этот код не увидит
Парень который писал до меня этот проект, тоже наверное так думал
> А когда в ТЗ появляются новые фичи, которые свой фреймворк пока не умеет, проще уже реализовать её у себя
Хм то есть если сначала взять ZF, CakePHP, Symfony и так далее, то нужно только «подключить» понадобившийся функционал.
> мне столько не нужно и никто кроме меня этот код не увидит
Парень который писал до меня этот проект, тоже наверное так думал
> А когда в ТЗ появляются новые фичи, которые свой фреймворк пока не умеет, проще уже реализовать её у себя
Хм то есть если сначала взять ZF, CakePHP, Symfony и так далее, то нужно только «подключить» понадобившийся функционал.
Меня уже несколько лет в пользе популярных фреймворков убеждать не надо :) Понял на практике, что пускай лучше будет неиспользуемая пока функциольность, чем потом писать её с нуля, вместо того, чтобы «поставить галочку».
Исключения, пожалуй, ситуации когда ресурсоемкость кода важнее его трудоемкости и универсальности, гибкости и прочей поддержки, то есть либо хайлоад проекты, где важна каждая микросекунда (но тут целесообразность использование PHP под вопросом), либо одноразовая работа в условиях крайне ограниченных и не контролируемых ресурсов (бесплатные хостинги, например).
Есть ещё вариант, когда использование популярных open source фреймворков/библиотек по каким-то причинам недопустимо или нежелательно. NIH и всё такое. Некоторые заказчики/работодатели настаивают на том, чтобы все права на код принадлежали им. И что уж греха таить, иногда они начинают настаивать на этом после парочки вопросов от исполнителя, заданных с целью увеличения трудоемкости, а значит и бюджета.
Исключения, пожалуй, ситуации когда ресурсоемкость кода важнее его трудоемкости и универсальности, гибкости и прочей поддержки, то есть либо хайлоад проекты, где важна каждая микросекунда (но тут целесообразность использование PHP под вопросом), либо одноразовая работа в условиях крайне ограниченных и не контролируемых ресурсов (бесплатные хостинги, например).
Есть ещё вариант, когда использование популярных open source фреймворков/библиотек по каким-то причинам недопустимо или нежелательно. NIH и всё такое. Некоторые заказчики/работодатели настаивают на том, чтобы все права на код принадлежали им. И что уж греха таить, иногда они начинают настаивать на этом после парочки вопросов от исполнителя, заданных с целью увеличения трудоемкости, а значит и бюджета.
Ну вот что такого в вашем самописном, чего не умеет ZF, CakePHP, Symfony и так далее?
Они не всегда умеют быть достаточно простыми, и не всегда умеют быть совместимыми от версии к версии, а так же хуже заточены под конкретные задачи.
Со вторым понятно, последнее очевидно, а по поводу первого есть простой критерий. Если на фреймворке, его правильными и штатными средствами, какая-то задача выполняется более долго и решение выглядит более объемным чем на чистом пхп, то это как говорится «оверкилл» по сложности. Немного неточный пример, но очень хороший и показательный если посмотреть на него достаточно абстрактно был тут habrahabr.ru/blogs/programming/113128/
> Они не всегда умеют быть достаточно простыми
смотря какой критерий простоты. CakePHP «проще» ZF, Kohana «проще» Symfony и так далее. Yii в обще простенький.
> не всегда умеют быть совместимыми от версии к версии
всегда есть migration guide, хм ну некоторые версии php «несовместимы» deprecated функции и всё такое
> а так же хуже заточены под конкретные задачи.
Так это же фреймворк — ИНСТРУМЕНТ, а не РЕШЕНИЕ. В том то и дело, что мы с вами должны взять этот инструмент и заточить его под конкретные задачи, для этого они и разрабатывались.
смотря какой критерий простоты. CakePHP «проще» ZF, Kohana «проще» Symfony и так далее. Yii в обще простенький.
> не всегда умеют быть совместимыми от версии к версии
всегда есть migration guide, хм ну некоторые версии php «несовместимы» deprecated функции и всё такое
> а так же хуже заточены под конкретные задачи.
Так это же фреймворк — ИНСТРУМЕНТ, а не РЕШЕНИЕ. В том то и дело, что мы с вами должны взять этот инструмент и заточить его под конкретные задачи, для этого они и разрабатывались.
>В том то и дело, что мы с вами должны взять этот инструмент и заточить его под конкретные задачи, для этого они и разрабатывались.
Наверное имелось в виду, что заточка может обойтись дороже изготовления своего инструмента.
Наверное имелось в виду, что заточка может обойтись дороже изготовления своего инструмента.
я могу вам возразить, что изготовление своего инструмента с нуля и изготовление на основе каркаса ( фреймворка) будет дороже. Но кажется это уже попахивает холиваром :)
Если речь о построении одного сайта — Вы однозначно и 100% правы, лучше использовать распространённый фреймворк, чем писать свой велосипед.
Но когда появляется много сайтов, встает необходимость поддерживать старых клиентов, нужен слегка разный функционал и единая среда разработки, то приходишь к тому, что у тебя 50 сайтов на 10 разных фреймворках в 5 разных версиях, с кучей хаков и несовместимых доработок. И этот зоопарк просто убивает время и не дает возможности качественной поддержки.
Если же есть свой фреймворк, то все эти проблемы уходят. Простота его — первого сорта, нужный круг задач он решает, проблемы с обновлением нет. А если еще и на документацию время есть, то и других разработчиков несложно подключать.
Но когда появляется много сайтов, встает необходимость поддерживать старых клиентов, нужен слегка разный функционал и единая среда разработки, то приходишь к тому, что у тебя 50 сайтов на 10 разных фреймворках в 5 разных версиях, с кучей хаков и несовместимых доработок. И этот зоопарк просто убивает время и не дает возможности качественной поддержки.
Если же есть свой фреймворк, то все эти проблемы уходят. Простота его — первого сорта, нужный круг задач он решает, проблемы с обновлением нет. А если еще и на документацию время есть, то и других разработчиков несложно подключать.
Вот минусуйте меня, но не понимаю я тех людей которые не используют готовый фрейморк, а пишут свой…
Минусовать не собираюсь, но предлагаю взглянуть на проблему с другой стороны. Было бы такое многообразие фреймворков (причём у каждого со своими плюшками, каждый новый ещё красивее и лучше) если бы не создатели велосипедов, те которые пишут свои фреймворки? Symfony, Yii и прочия были не всегда, просто появились люди, которых не устроили существующие фреймворки. И они написали свои. У них получилось лучше (или им повезло).
Причины у людей использующих самопальные фреймворки могут быть совершенно различны:
1) нежелание/отсутствие времени разбираться в готовых фреймворках.
2) понимание, что стандартный фреймворк не способен эффективно решить поставленную задачу. Это может быть из-за недопонимания фреймворка, или наоборот очень глубокого его понимания
3) «Собственнические» взгляды:
— это написал я и я полностью понимаю происходящее и полностью представляю систему!
— стандартные фреймворки имеют кучу багов, а я пишу код лучше!
— стандартные фреймворки уязвимы!
и т.п.
Может что-то ещё.
Как погляжу, комментирующие этот опрос очень не любят любят велосипедистов. А зря. Среди тысячи говновелосипедов, возможно прямо сейчас растёт грядущая звезда, идёт конкурентная борьба и естественный отбор. А вы их всех скопом и в урну. Нехорошо.
Вспомните развитие многих громких проектов. Сколько гляжу, многие начинались с идеи «хочу свой лунапарк, с блекджеком и шлюхами!» и авторы садились писать их. А вокруг все твердили: «ну нафига тебе этот велосипед, ведь есть же обычная и простая телега. На ней и в соседнюю деревню можно съездить, и навоз привезти! А твой велосипед это фигня, да и непонятно, куда тут лошадь запрягать»
Как-то так.
Yii, ибо гибкий, отличное сообщество и впитал в себя много положительного от различных фреймворков.
Используется самописный, но не потому что есть желание изобретать велосипед, а потому что
1) Поддерживаются даже очень старые клиенты (в смысле люди), некоторые с сайтами сделанными еще на 1 версии 5 летней давности. Обновить свой фреймворк намного проще, чем чужой.
2) Поддержка намного упрощается, т.к. есть возможность использовать везде один и тот же фреймворк, дорабатывая его по мере надобности. А иначе пришлось бы использовать разные и постоянно тратить время что бы быть в курсе событий всех фреймворков.
3) Легко вносить свои изменения, четко зная что со следующей версией они не станут несовместимыми в чем-то или будут конфликтовать. И что эти изменения именно будут постоянно включены во фреймворк, не надо просить авторов фреймворка их включить с риском нарваться на отказ.
4) Есть своя любимая ЦА клиентов с определёнными типами сайтов, с которыми идет работа. Фреймворк со временем стал весьма заточен под них, нет ничего лишнего, есть почти все необходимое, а то чего нет — просто добавляется.
1) Поддерживаются даже очень старые клиенты (в смысле люди), некоторые с сайтами сделанными еще на 1 версии 5 летней давности. Обновить свой фреймворк намного проще, чем чужой.
2) Поддержка намного упрощается, т.к. есть возможность использовать везде один и тот же фреймворк, дорабатывая его по мере надобности. А иначе пришлось бы использовать разные и постоянно тратить время что бы быть в курсе событий всех фреймворков.
3) Легко вносить свои изменения, четко зная что со следующей версией они не станут несовместимыми в чем-то или будут конфликтовать. И что эти изменения именно будут постоянно включены во фреймворк, не надо просить авторов фреймворка их включить с риском нарваться на отказ.
4) Есть своя любимая ЦА клиентов с определёнными типами сайтов, с которыми идет работа. Фреймворк со временем стал весьма заточен под них, нет ничего лишнего, есть почти все необходимое, а то чего нет — просто добавляется.
Конечно понятен кайф от написания чего-то своего и использования его :)
2 — не согласен
3 — до тех пор, пока вы его развиваете.
Представим, что вы работаете по найму с фреймворком скажем AAA, и изредка поддерживаете те сайты. Вы постепенно забудете свой, это неизбежно. Вы увидите что обновлять его все сложнее и сложнее, что вы пишите велосипед, т.е. в итоге — больше работы чем использовать распространненый фреймворк — мое мнение.
2 — не согласен
3 — до тех пор, пока вы его развиваете.
Представим, что вы работаете по найму с фреймворком скажем AAA, и изредка поддерживаете те сайты. Вы постепенно забудете свой, это неизбежно. Вы увидите что обновлять его все сложнее и сложнее, что вы пишите велосипед, т.е. в итоге — больше работы чем использовать распространненый фреймворк — мое мнение.
Конечно понятен кайф от написания чего-то своего и использования его :)Кайф был первые пару лет:) Сейчас просто прагматичный подход.
3 — до тех пор, пока вы его развиваете.Не вполне понятна аргументация. Речь в посте на который Вы отвечали шла о том, что никакой фреймворк «ААА» и даже «БББ» не используется, а развивается свой. Вы же контр-аргументируете тем, что на самом деле-то используется фреймворк «ААА», а свой забывается.
Представим, что вы работаете по найму с фреймворком скажем AAA, и изредка поддерживаете те сайты. Вы постепенно забудете свой
Yii для среднекрупного
А мелкий бложек или визитку можно и на голом php собрать.
А мелкий бложек или визитку можно и на голом php собрать.
Удивлен какое кол-во людей не используют фреймворки, или что хуже — используют свои
Для коммерческой разработки однозначно стоит использовать самые распространенные фреймворки, или, в случае front-end сайтов — движки типа Drupal.
Поддержка проекта на custom framework — это очень трудно и не очень полезно :( как раз этим и занимаемся щас.
Мой Test Case: ухожу на другую работу. текущий проект на custom framework, проект был начат аусторсом в другой конторе.
1. Мой опыт поддержки этого framework практически можно выкинуть в корзину. Был бы Zend Framework, я бы получил полезный опыт и нашел работу с выше оплатой, т.к. работодатели в основном выбирают ZF.
2. Проблемы и баги этого framework нигде не описаны. Практик реализации той или иной задачи нет. Гугл не помощник.
3. Человек, что придет заменять меня, этот framework конечно не знает и знать не может, потратит кучу времени как сделать то и это.
Для коммерческой разработки однозначно стоит использовать самые распространенные фреймворки, или, в случае front-end сайтов — движки типа Drupal.
Поддержка проекта на custom framework — это очень трудно и не очень полезно :( как раз этим и занимаемся щас.
Мой Test Case: ухожу на другую работу. текущий проект на custom framework, проект был начат аусторсом в другой конторе.
1. Мой опыт поддержки этого framework практически можно выкинуть в корзину. Был бы Zend Framework, я бы получил полезный опыт и нашел работу с выше оплатой, т.к. работодатели в основном выбирают ZF.
2. Проблемы и баги этого framework нигде не описаны. Практик реализации той или иной задачи нет. Гугл не помощник.
3. Человек, что придет заменять меня, этот framework конечно не знает и знать не может, потратит кучу времени как сделать то и это.
Использую свой собственный фреймворк, в основном из-за своей лени и нежеления что-либо ещё изучать. Постепенно переползаю на grails с php вообще.
Конечно же, самый правильный фрэймворк от создателей PHP — Zend Framework :)
Плюс самописные компоненты на его основе.
Плюс самописные компоненты на его основе.
«самый правильный» для определенного перечна задач. далеко не всегда можно удовлетворится чужим фреймворком ввиду того, что он может не поддерживать необходимый функционал на уровне архитектуры)
Там смайлик в конце :)
Не подскажете, для каких задач не подходит ZF?
Не подскажете, для каких задач не подходит ZF?
в моем комментарии ниже писал небольшой перечень задач, которые приходилось решать — после оценки того, что надо реализовывать решили писать свою систему, а не использовать готовые)
Хочу добавить — решить, может, и можно. но вопрос в том насколько это будет эффективно сделано. в нашем случае мы посчитали, что эффективнее будет сделать свое.
См. также wiki4tech.ru/Сравнение_PHP-фреймворков
На работе написали фреймворк с нуля. так как не нашли ничего подходящего для наших целей — штамповка большого кол-ва сайтов — информационных порталов (на данный момент уже 17 штук, будет больше в разы), создавать сайтам группы — у каждой группы идет наследие настроек, шаблонов, триггеров у главного сайта (а она наследует базовые настройки системы в общем) в группе, так же можно для каждого сайта индивидуально создать свой шаблон для любого модуля, изменить любой конфиг и прочее.
работа с сайтами (админ. работа над контентом) происходит централизовано на одном хостинге, потом сайты кешируются целиком (с добавлением минимальной динамики, вроде комментариев, поиска, контакт формы — все запросы идут нацентральный хостинг и он возвращает ответ на сайт, а там происходит вывод информации) и заливаются уже на свои хостинги.
еще очень много инфраструктурных нюансов, которые необходимо было решать и поэтому пришлось писать систему с нуля)
работа с сайтами (админ. работа над контентом) происходит централизовано на одном хостинге, потом сайты кешируются целиком (с добавлением минимальной динамики, вроде комментариев, поиска, контакт формы — все запросы идут нацентральный хостинг и он возвращает ответ на сайт, а там происходит вывод информации) и заливаются уже на свои хостинги.
еще очень много инфраструктурных нюансов, которые необходимо было решать и поэтому пришлось писать систему с нуля)
Kohana вполне устраивает
Использовали CakePHP раньше. Когда стала задача разнести ГУИ и бизнес-логику с БД на разные серверы, то ГУИ написали на CodeIgnitor (выбрали потому что слышали, что он самый быстрый и довольно простой), а все остальное уже самописное.
Начал с Drupal, потом шли Wordpress, Joomla и вернулся к начальной точке. Drupal.
Из фрэимворков начал с ZF потом CI, Fat-Free, Yii. Сейчас юзаю ZF, Yii.
Из фрэимворков начал с ZF потом CI, Fat-Free, Yii. Сейчас юзаю ZF, Yii.
CodeIgniter — простой и понятный. Не хватает некоторых плюшек, как у Коханы, но после некоторых прыжков от одного фреймворка к другому все равно вернулся на CodeIgniter. Например в Kohana не очень понравилось то, что в минорных релизах отличия могут быть разительными по части обратной совместимости.
Я за простоту. Фреймворки усложняют. Не только в веб-разработках.
Знакомый гейм-девелопер, который в этой сфере уже много лет, не использует фреймворки, либо использует свои. Даже больше, не использует движки сторонние, только свои.
На самом деле проще исправлять свои ошибки, чем чужие :)
Знакомый гейм-девелопер, который в этой сфере уже много лет, не использует фреймворки, либо использует свои. Даже больше, не использует движки сторонние, только свои.
На самом деле проще исправлять свои ошибки, чем чужие :)
Вы меня поняли.
Фреймворкость бывает лишней.
Фреймворкость бывает лишней.
Бывает, но, по-моему, это касается либо hello world, либо каких-то уникальных требований. Во многих случаях писать с нуля не оправдано. Есть, конечно, компромисс — использовать библиотеки и/или компоненты фреймворков, основную структуру и интеграцию реализуя самостоятельно.
В общем, по-моему, в современных условиях надо найти достойную причину не использовать фреймворк, а не причину его использовать :) Выбор фреймворка — отдельный вопрос.
В общем, по-моему, в современных условиях надо найти достойную причину не использовать фреймворк, а не причину его использовать :) Выбор фреймворка — отдельный вопрос.
Вы не путайте игры и сложные порталы. Я немного знаком с игровой архитектурой, она совсем другие проблемы решает.
Популярные ныне игры для социальных сетей представляют не-вполне-тонкий клиент на Флеше, с достаточно простым бекэндом на сервере. От последнего требуется в основном а) сохрание/загрузка состояния клиента из БД; б) кеширование этого самого состояния для пущего ускорения в) запуск периодических задач. Усе. Сиди да решай проблемы производительности.
Бекэнд же любого приличного портала на порядок сложнее и больше.
Популярные ныне игры для социальных сетей представляют не-вполне-тонкий клиент на Флеше, с достаточно простым бекэндом на сервере. От последнего требуется в основном а) сохрание/загрузка состояния клиента из БД; б) кеширование этого самого состояния для пущего ускорения в) запуск периодических задач. Усе. Сиди да решай проблемы производительности.
Бекэнд же любого приличного портала на порядок сложнее и больше.
По вашему велосипедизм это хорошо? Фреймворки по вашему пишут просто ради прикола, чтобы утяжелить код?
Я не про велосипедизм.
Просто я о том, что не нужно использовать фреймворк ради фреймворка.
И смотрите на результаты, четверть почти за вариант:
«Пишу на PHP, но не использую фреймворки.»
PHP это не значит все с нуля писать. Есть свои же наработки, чужие наработки. Мне так действительно проще.
Фреймворки нужно использовать по мере надобности. Правда даже в более-менее крупных проектах их не использовал. Не знаю, кому как удобнее. Если бы видел необходимость — использовал бы.
Просто я о том, что не нужно использовать фреймворк ради фреймворка.
И смотрите на результаты, четверть почти за вариант:
«Пишу на PHP, но не использую фреймворки.»
PHP это не значит все с нуля писать. Есть свои же наработки, чужие наработки. Мне так действительно проще.
Фреймворки нужно использовать по мере надобности. Правда даже в более-менее крупных проектах их не использовал. Не знаю, кому как удобнее. Если бы видел необходимость — использовал бы.
Ну так фреймворк и есть такая наработка, где решена бОльшая часть рутинных задач, стоящая перед современным веб-приложением, остаётся писать только бизнес-логику и шаблоны не заботясь о роутинге, валидации, экранировании, аутентификации и авторизации, кэшировании и т. д., и т. п., а главное их взаимодействии между собой.
Понравился тут вступление к туториалу по symfony2, где пошагово показано как, а главное зачем перейти от спаггети-кода к использованию фреймворков. Ну и плюс никто не загоняет в каркас, можно использовать одни компоненты, без ядра, просто все они будут написаны в одном стиле, с одной идеей интерфейсов и т. п. Zend Framework по-моему рекордсмен по такому использованию. А с другой стороны, если используешь 90% функциональности фреймворка, вызывая его компоненты, то почему бы не начать использовать 100%, позволив ему вызывать твои компоненты.
Понравился тут вступление к туториалу по symfony2, где пошагово показано как, а главное зачем перейти от спаггети-кода к использованию фреймворков. Ну и плюс никто не загоняет в каркас, можно использовать одни компоненты, без ядра, просто все они будут написаны в одном стиле, с одной идеей интерфейсов и т. п. Zend Framework по-моему рекордсмен по такому использованию. А с другой стороны, если используешь 90% функциональности фреймворка, вызывая его компоненты, то почему бы не начать использовать 100%, позволив ему вызывать твои компоненты.
В гейм-деве («самостоятельных» браузерках) вообще фреймворки не очень часто используются. Хотя широко известный Travian, например, написан на Zend.
В этом гейм-деве, афаик, довольно остро строит проблема нагрузки на сервер, ввиду частого отсутствия ресурсов на масштабирование. Разработчики даже видя легкость разработки с использованием какого-то фреймворка «вынуждены» отказываться от его плюшек из-за быстродействия. Иной раз вполне обоснованно, иной — не желая, например, отказаться от тяжелых ORM/DBAL (или озаботиться их кэшированием) без отказа от всего фреймворка, воспринимая его как нечто целостное и монолитное.
Переписывал один проект с plain-php на php+kohana (orm и все прелести). Производительность повысилась в разы. Генерация страницы упала с 0.3 секунды до 0.05 секунд на моём компе.
Хм… это что же там так надо было накрутить. Или у вас кэширование активно использовалось?
Это с отключённым кешированием) Около 6-10 запросов на страницу, половина из них — «SHOW FULL COLUMNS», которые можно убрать. Просто правильно используется ORM, никаких запросов в цикле, всё вытягивается заранее через
Справедливости ради стоит заметить, что первый запрос обрабатывается за 0.07 секунды, а дальше уменьшается до 0.4-0.6. Вполне возможно, кстати, что ещё влияет то, что я использую последний php5.3 под linux, который бегает довольно шустренько.
До перевода кода на Kohana на этой же странице выполнялось больше двадцати запросов(писал не я, переводил я).
with и pull, при этом я пользуюсь всеми преимуществами фреймворка на полную — ORM, Query Builder, (нативный) View и так далее.Справедливости ради стоит заметить, что первый запрос обрабатывается за 0.07 секунды, а дальше уменьшается до 0.4-0.6. Вполне возможно, кстати, что ещё влияет то, что я использую последний php5.3 под linux, который бегает довольно шустренько.
До перевода кода на Kohana на этой же странице выполнялось больше двадцати запросов(писал не я, переводил я).
Обилие разнородных фреймворков, страсть к самописной каше кода либо каждый-раз-под-сайт инструментов…
Не причины ли это общей неприязни к языку в мире разработчиков?
Не причины ли это общей неприязни к языку в мире разработчиков?
Обилие фреймворков подчеркивает популярность языка. Страть к самописной каше — это признак новичка, либо это бывает в несофтверных компаниях.
С точки зрения разработчика обилие фреймворков подчеркивает проблему выбора инструмента и проблему освоения новых в той же области, того явно не требующей.
Можно привести примеры популярнейших языков, где 1-2 ключевых фреймворка в целевой области задают дефакто стандарт, а менее популярные отвечают за эксперименты и пробы. Скажем JQuery в js, Django в Python, RoR для Ruby, Spring для Java (как традиционный выбор для некорпоративных решений) и так далее.
Можно привести примеры популярнейших языков, где 1-2 ключевых фреймворка в целевой области задают дефакто стандарт, а менее популярные отвечают за эксперименты и пробы. Скажем JQuery в js, Django в Python, RoR для Ruby, Spring для Java (как традиционный выбор для некорпоративных решений) и так далее.
Да ну на… А теперь сравните долю проектов для веба написанных на Ruby или Java и PHP, ничего удивительного что для рельс есть один фреймворк а для PHP десяток.
Вы замолчали упомянутый выше для js для JQuery. Да и… Java — первый по популярности ныне язык, как в корпоративном секторе, так и во многих других. Всего на ступеньку ниже Php стоит Python.
Тут надо не на популярность ссылаться, а на историю языков, а она очень и очень разниться.
Тут надо не на популярность ссылаться, а на историю языков, а она очень и очень разниться.
Причем здесь история, причем здесь корпоративный сектор? Я говорил об инструментах для разработки веб приложений.
а когда это корпоративный сектор перестал делать веб-приложения?
Я разве говорил что перестал? Я рассуждаю лишь об инструментах, судя по вашему комменту весь корпоративный сектор штампует свои веб приложения на Java поверьте это не так.
Подавляющая часть этого здоровенного куска рынка веб-приложений работает именно на Java.
Собственно говоря, про целиком никто и не говорит, так не бывает. Я сам на Питоне писал большие приложения именно в этой сфере; и писал модули интеграции с решениями на Java — мы практически всегда были белой вороной.
Но мы не об этом! Мы о том, что нынешний разношерстный раскад в мире Php — проблема.
Собственно говоря, про целиком никто и не говорит, так не бывает. Я сам на Питоне писал большие приложения именно в этой сфере; и писал модули интеграции с решениями на Java — мы практически всегда были белой вороной.
Но мы не об этом! Мы о том, что нынешний разношерстный раскад в мире Php — проблема.
>Мы о том, что нынешний разношерстный раскад в мире Php — проблема.
Проблема прежде всего, по-моему, в первых двух лидерах опроса. То что среди «несамописных» веб-фреймворков нет явного лидера, не так плохо, что 40% php-разработчиков на хабре (боюсь предположить результаты всего рынка) их вообще не используют. В конце-концов фреймворки развиваются, в том числе беря друг у друга (а также у конкурентов на других ЯП) лучшее и объективных причин для отдачи предпочтения одному перед другим может и не быть.
Проблема прежде всего, по-моему, в первых двух лидерах опроса. То что среди «несамописных» веб-фреймворков нет явного лидера, не так плохо, что 40% php-разработчиков на хабре (боюсь предположить результаты всего рынка) их вообще не используют. В конце-концов фреймворки развиваются, в том числе беря друг у друга (а также у конкурентов на других ЯП) лучшее и объективных причин для отдачи предпочтения одному перед другим может и не быть.
«ничего удивительного что для рельс есть один фреймворк а для PHP десяток. „
Ничего не путаете, хотели сказать для Ruby?
Но и тут вас разочарую: Sinatra, Merb, Padrino, Ramaze, Nitro и это только, что я знаю.
А вот для PHP есть что-нибудь подобное фрэймворку для мобильных приложений Rhode? Или версии веб-серверов? Или игровые фрэймворки? :)
Ничего не путаете, хотели сказать для Ruby?
Но и тут вас разочарую: Sinatra, Merb, Padrino, Ramaze, Nitro и это только, что я знаю.
А вот для PHP есть что-нибудь подобное фрэймворку для мобильных приложений Rhode? Или версии веб-серверов? Или игровые фрэймворки? :)
Признаю половину из перечисленных фреймворков для Ruby вижу впервые, просто всегда считал что в ruby самый популярный один фреймворк — rails в то время как в PHP первое место делят сразу несколько кандидатов. Вам не кажется что спрашивать есть ли в php что-то подобное Rhode немного не правильно? Ruby как и python занимают немного другую нишу нежели php. Я же акцентировал свое внимание именно на веб.
Я вас понимаю, вы просто не пишете на Ruby, потому для вас это неизвестный мир, это всегда так, потому и кажется, что Rails это единственный фрэймворк, хотя на самом деле это не так.
Про нишу не понял, понятно, что на C++ MFC сайт писать сейчас это другая ниша, но почему Python и Django, c Perl'ом не в нише?
Про нишу не понял, понятно, что на C++ MFC сайт писать сейчас это другая ниша, но почему Python и Django, c Perl'ом не в нише?
Мы говорим «руби» — подразумеваем «рельсы»… :) Но оговорка, имхо, не случайна, она хорошо показывает, что веб-фреймворки под python/ruby имеют ярко выраженных лидеров. Думаю результаты аналогичного опроса для этих языков были бы легко предсказуемыми, интересны бы были места после первого. Плюс для этих языков начинать разработку веб-приложения вообще без какого-либо фреймворка весьма опрометчиво, придётся реализовывать то, что в PHP входит в сам язык, а значит выбирать фреймворк нужно на стадии принятия решения сделать сайт на python или ruby, в PHP, как показывают результаты, использование фреймворков, тем более не своих, это не необходимость, а «блажь» :)
Что имеете в виду под «версиями веб-серверов»?
Что имеете в виду под «версиями веб-серверов»?
Это плохо, узколобо, да и суть была, что человек не знает других фрэймворков, а они есть и вполне себе живут хорошо, причем тут лидеры, да не причем :)
«Плюс для этих языков начинать разработку веб-приложения вообще без какого-либо фреймворка весьма опрометчиво, придётся реализовывать то, что в PHP входит в сам язык»
И знаете ли потом все начинают за это PHP и ругать, то именование функций различается, то весь нэймспэйс засрат, функции не перееопределить, чтобы подключить целая история, бинарники, PEAR почти мёртв. Чем тут хвастать?
зы. c PHP сам работаю, но вижу все его недостатки и есть с чем сравнивать.
«Плюс для этих языков начинать разработку веб-приложения вообще без какого-либо фреймворка весьма опрометчиво, придётся реализовывать то, что в PHP входит в сам язык»
И знаете ли потом все начинают за это PHP и ругать, то именование функций различается, то весь нэймспэйс засрат, функции не перееопределить, чтобы подключить целая история, бинарники, PEAR почти мёртв. Чем тут хвастать?
зы. c PHP сам работаю, но вижу все его недостатки и есть с чем сравнивать.
Низким порогом вхождения? :) А так меня ругали за то, что начал разработку «сайта-визитки» на ruby с прослушивания сокетов, т. к. не нашёл стандартных способов работать с fastcgi (с cgi нашёл, но не юзабельно). Но это же не ruby виноват? :)
Не понял про «низкий порог вхождения», вы про что это и где это у меня вычитали??? o_O
Для сайта визитки решили использовать ruby и не знали, что есть другие способы передать управление от веб-сервера к приложению? Язык тут не причем, безграмотность ваша
Если желаете библиотеки для Ruby для работы с FastCGI
gem install fcgi
благо ставить и искать библиотеки одно удовольствие.
Для сайта визитки решили использовать ruby и не знали, что есть другие способы передать управление от веб-сервера к приложению? Язык тут не причем, безграмотность ваша
Если желаете библиотеки для Ruby для работы с FastCGI
gem install fcgi
благо ставить и искать библиотеки одно удовольствие.
Это вариант ответа на вопрос: «Чем тут хвастать?» :)
В официальной документации языка и стандартных библиотек других способов не нашёл, кроме тормозного CGI. В Python есть хотя бы WSGI, в Ruby ничего похожего не нашёл, ткните ссылкой на www.ruby-doc.org/ пожалуйста. Только на сторонние проекты типа fcgi или Rack не нужно, их я и сам нагуглить могу. WEBrick тоже несколько не то (да ещё не документирован толком, потому может и то, и может служить обёрткой для Ruby приложения через какой-нибудь *GI, а не просто запросы к нему проксировать или standalone запускать, но вроде всё же полноценный веб-сервер). Что ещё язык Ruby и его стандартные библиотеки предлагают для передачи управления от веб-сервера к приложению? PHP вон для Apache предлагает минимум 3 способа из коробки (модуль, cgi, fastcgi), все описаны в официальной документации и не требуют каких-то сторонних модулей.
В официальной документации языка и стандартных библиотек других способов не нашёл, кроме тормозного CGI. В Python есть хотя бы WSGI, в Ruby ничего похожего не нашёл, ткните ссылкой на www.ruby-doc.org/ пожалуйста. Только на сторонние проекты типа fcgi или Rack не нужно, их я и сам нагуглить могу. WEBrick тоже несколько не то (да ещё не документирован толком, потому может и то, и может служить обёрткой для Ruby приложения через какой-нибудь *GI, а не просто запросы к нему проксировать или standalone запускать, но вроде всё же полноценный веб-сервер). Что ещё язык Ruby и его стандартные библиотеки предлагают для передачи управления от веб-сервера к приложению? PHP вон для Apache предлагает минимум 3 способа из коробки (модуль, cgi, fastcgi), все описаны в официальной документации и не требуют каких-то сторонних модулей.
Вы бредите, во-первых язык не обязан содержать в себе реализации протоколов, чего нет и в PHP на самом-то деле тоже, реализуется это уже не языком. Во-вторых ruby-doc не обязан содержать модули, он описывает язык.
Модули для Ruby если не знаете это gem'ы.
А в вашем случае не надо мешать мягкое с теплым и уметь пользоваться нативными и хорошими интерфейсами под язык, для Ruby это шикарный Rack. А запускать как CGI Ruby вообще проблем нет, благо в окружение вам всё отдадут.
Ну и стоит заметить раз телега о PHP, что реализация mod_php, FastCGI так и хромает. В первом случае мы видим постоянную загрузку в Апаче интерпретатора PHP и не более, сравните с нормальной Perl (Apache::Registry например реализацией, кто у нас в памяти так и остается работать). FastCGI у PHP до недавнего времени вообще был своеобразный так же поддерживая интерпретатор в активном состоянии, хотя должно крутить FastCGI сервер приложения.
Вот вам и извращенные понятия и откуда ноги растут.
Модули для Ruby если не знаете это gem'ы.
А в вашем случае не надо мешать мягкое с теплым и уметь пользоваться нативными и хорошими интерфейсами под язык, для Ruby это шикарный Rack. А запускать как CGI Ruby вообще проблем нет, благо в окружение вам всё отдадут.
Ну и стоит заметить раз телега о PHP, что реализация mod_php, FastCGI так и хромает. В первом случае мы видим постоянную загрузку в Апаче интерпретатора PHP и не более, сравните с нормальной Perl (Apache::Registry например реализацией, кто у нас в памяти так и остается работать). FastCGI у PHP до недавнего времени вообще был своеобразный так же поддерживая интерпретатор в активном состоянии, хотя должно крутить FastCGI сервер приложения.
Вот вам и извращенные понятия и откуда ноги растут.
Во-первых, я не спорю о том, что язык должен или не должен, я констатирую факт. А насчёт ruby-doc посморить можно как раз:
Насколько я знаю (и даже видно по цитатам выше), модули — это модули, сущность языка, способ группировки классов, функций и т. п., а gem'ы — это способ управления нестандартными модулями, библиотеками и программами. Утверждать, что модули это gem'ы это, по-моему, утверждать, что программа для Linux это deb- или rpm-пакет.
Вот не поворачивается у меня язык назвать Rack для Ruby нативным, как не поворачивается язык назвать нативным для PHP phpdaemon и как до недавних пор не поворачивался назвать нативным php-fpm и пока не поворачивается назвать нативным APC :) Реализованы на этих языках — да, хорошие — да, но не нативные.
Вероятней всего, освоить ruby для веб-дева мне мешает моя привычка изучать всё «снизу-вверх» — сначала реализовать что-то самому стандартными средствами, в данном случае языка, убедиться в кривости и неуниверсальности, а затем искать (если всё ещё нужно) более грамотное решение. Для ruby (да и многих других ЯП в вебе) я не смог преодолеть барьер между CGI приложением и высокоуровневыми фреймворками, отсутствует стандартная ступенька уровня mod_php или mod_wsgi, пускай сырой http-запрос, но без необходимости слушать сокеты.
Core API
These are the API documents for the base classes and modules in the current stable release, 1.9.2.
Standard Library API
These are the API documents for the standard library classes and modules in the current stable release, 1.9.2.
Насколько я знаю (и даже видно по цитатам выше), модули — это модули, сущность языка, способ группировки классов, функций и т. п., а gem'ы — это способ управления нестандартными модулями, библиотеками и программами. Утверждать, что модули это gem'ы это, по-моему, утверждать, что программа для Linux это deb- или rpm-пакет.
Вот не поворачивается у меня язык назвать Rack для Ruby нативным, как не поворачивается язык назвать нативным для PHP phpdaemon и как до недавних пор не поворачивался назвать нативным php-fpm и пока не поворачивается назвать нативным APC :) Реализованы на этих языках — да, хорошие — да, но не нативные.
Вероятней всего, освоить ruby для веб-дева мне мешает моя привычка изучать всё «снизу-вверх» — сначала реализовать что-то самому стандартными средствами, в данном случае языка, убедиться в кривости и неуниверсальности, а затем искать (если всё ещё нужно) более грамотное решение. Для ruby (да и многих других ЯП в вебе) я не смог преодолеть барьер между CGI приложением и высокоуровневыми фреймворками, отсутствует стандартная ступенька уровня mod_php или mod_wsgi, пускай сырой http-запрос, но без необходимости слушать сокеты.
Прошел долгий путь от самописных, то контрибовых фреймворков, CMS, CMF и обратно и вот что скажу…
писать свой фреймворк в современном мире, когда мощности серверов и БД достаточно гибки я считаю достаточно глупо. Конечно каждый пых-кодер любит козырьнуть наличием своего фреймворка, но, извините, когда он делает проект, потом сваливает, а потом этот проект доделывает другой кодер, для которого дни становятся адом в попытках разобраться в этой мешанине.
Современных мощностей вполне достаточно чтобы использовать готовый фреймворк, в котором дырок напорядок меньше чем в чьем-то велосипеде. Пусть он работает на 1% медленнее, но это учит людей единому стандарту. И когда потом кто-то открывает ваш код, то для быстрого старта работы не нужно практически ничего. Плюс скорость разработки на фреймворках намного выше, а это в соверменном мире намного более важный показатель, чем скорость загрузки страницы (в разумных пределах, конечно)
Я сам много использую Drupal и считаю его молодцом для небольших и средних проектов, где 99% посетителей анонимны. Системы кеширования позволяют грузить сайт очень быстро. А времени на разработку тратится в разы меньше.
Но для средних и больших проектов я бы выбрал Yii (хотя писал на CI, Cake), так где важно контролировать каждый запрос к базе, но при всем этом держать код в полном порядке.
Сейчас за мной тянется большой проект на чистом php (так уж вышло) и мне сложно преставить, что его кто-то будет поддерживать (хотя, кажется что все элементарно)
писать свой фреймворк в современном мире, когда мощности серверов и БД достаточно гибки я считаю достаточно глупо. Конечно каждый пых-кодер любит козырьнуть наличием своего фреймворка, но, извините, когда он делает проект, потом сваливает, а потом этот проект доделывает другой кодер, для которого дни становятся адом в попытках разобраться в этой мешанине.
Современных мощностей вполне достаточно чтобы использовать готовый фреймворк, в котором дырок напорядок меньше чем в чьем-то велосипеде. Пусть он работает на 1% медленнее, но это учит людей единому стандарту. И когда потом кто-то открывает ваш код, то для быстрого старта работы не нужно практически ничего. Плюс скорость разработки на фреймворках намного выше, а это в соверменном мире намного более важный показатель, чем скорость загрузки страницы (в разумных пределах, конечно)
Я сам много использую Drupal и считаю его молодцом для небольших и средних проектов, где 99% посетителей анонимны. Системы кеширования позволяют грузить сайт очень быстро. А времени на разработку тратится в разы меньше.
Но для средних и больших проектов я бы выбрал Yii (хотя писал на CI, Cake), так где важно контролировать каждый запрос к базе, но при всем этом держать код в полном порядке.
Сейчас за мной тянется большой проект на чистом php (так уж вышло) и мне сложно преставить, что его кто-то будет поддерживать (хотя, кажется что все элементарно)
CI+Doctrine (-:
Плюс к этому jQuery и как бы всё.
Ну и /dev/hands в связке с /dev/brain
P.S. RoR! (-:
Плюс к этому jQuery и как бы всё.
Ну и /dev/hands в связке с /dev/brain
P.S. RoR! (-:
А что такое фреймворк? *trollface*
Если писать что-то, что потом должно развиваться, то ZF. Если какой-то несерьёзный временный вброс или то, что планируется как-то развивать/поддерживать в отдалённом будущем, то можно и на коленке собрать (но потом придётся переписывать, разумеется).
CodeIgniter — всё просто, знаю его от и до, куча уже к нему расширений собою написано и модулей, удобный HMVC модуль.
Сделал один проект на YII — тоже не плохо, но стиль не нравится мне его, а возможности в целом могу это и на CI сделать.
Symfony2 — вот присматриваюсь, bundle и namespace архитектура очень нравятся, гибкость вижу и приятно, пока только ORM и валидация форм смущает.
Kohana — смотрел, пытался пописать, да времени копаться в исходниках не было, так как документации хорошей по 3ке нет, приходится дёргать из разных мест.
Но в целом последнее время больше на Ruby on Rails и по мелочи если на Sinatra сижу, потому как всё идеально как я хочу и люблю.
А вообще у всех php фрэймворков глобальная проблема с документацией, хорошей, понятной, лаконичной и удобной как у CodeIgniter и RoR.
Сделал один проект на YII — тоже не плохо, но стиль не нравится мне его, а возможности в целом могу это и на CI сделать.
Symfony2 — вот присматриваюсь, bundle и namespace архитектура очень нравятся, гибкость вижу и приятно, пока только ORM и валидация форм смущает.
Kohana — смотрел, пытался пописать, да времени копаться в исходниках не было, так как документации хорошей по 3ке нет, приходится дёргать из разных мест.
Но в целом последнее время больше на Ruby on Rails и по мелочи если на Sinatra сижу, потому как всё идеально как я хочу и люблю.
А вообще у всех php фрэймворков глобальная проблема с документацией, хорошей, понятной, лаконичной и удобной как у CodeIgniter и RoR.
После освоения основ PHP, решил изучать какой нибудь ооп фреймворк, чтобы глубже проникнуться объектным программированием (до этого про ооп только читал). После прочтения статей на хабре, выбор был сделан в пользу Zend Framework. По началу показался сложным, но после нескольких дней сверления кода взглядом, сакральный смысл конструкций стал открываться передо мной ). Потом повезло найти работу, где как раз во всю использовали данный фреймворк. Сейчас участвую в переносе проекта на Symfony 2.0, с парралельным изучением оной. Подходы у Zend'a и Symfony конечно сильно различаются, но второй фреймворк изучать оказалось гораздо проще. Для личных же проектов использую Kohana, за ее легковестность и простоту, после вышеназванных фреймворков ощущения от работы с ней как будто пересел на велосипед с 20-ти тонной фуры )
По-моему на Хабре что-то сломалось, если я правильно понимаю и в скобках — количество голосов. Я имею в виду вот это:
0.76% (175) Yii
6.45% (105) Symfony
Писал на ZF, потом на Yii. ZF более «академичный» и правильный, тогда как Yii более «гуманный» и быстрый (в плане разработки, имхо).
Уверен, что людям, которые рекомендуют не пользоваться фреймворками в «маленьких» проектах, просто лень было изучать фреймворк.
Уверен, что людям, которые рекомендуют не пользоваться фреймворками в «маленьких» проектах, просто лень было изучать фреймворк.
Не ожидал что Yii на столько распространен.
Использую для крупных проектов ZF, для мелких начал изучать Yii. Но серьезные вещи буду продолжать делать на ZF, т. к. он меня устраивает полностью, кроме скорости :) Но это также вопрос решаемый.
Использую CI. Правда в моей версии уже все переписано и доделано, от исходного фв осталось только лишь 20%
На работе — Drupal, дома — Wordpress
<ирония>Я прям удивляюсь, что в теме нет маркетолога Битрикса, что бы убедить всех, что он кошернее всех + интеграция с 1С. А потом они бы подрались с маркетологом UMI</ирония>
Если делать то, что в итоге будет похожим на имеющийся фреймворк, то это будет велосипедостроение, в этом случае лучше изучить какой-либо фреймворк, и использовать в работе его.
Я предпочитаю программировать либо на чистом PHP, если задача не сложная, и не требуются шаблоны для формирования HTML, либо использовать свой маленький фреймворк, который по сути является небольшим набором функций в одном файле (меньше 20 Кб), и реализует немного другой подход к созданию сайтов, чем как это принято у всех. Кода при этом получается очень мало, и работает этот код максимально быстро (быстрее любого обычного ОО фреймворка раз в 10 как минимум).
Я предпочитаю программировать либо на чистом PHP, если задача не сложная, и не требуются шаблоны для формирования HTML, либо использовать свой маленький фреймворк, который по сути является небольшим набором функций в одном файле (меньше 20 Кб), и реализует немного другой подход к созданию сайтов, чем как это принято у всех. Кода при этом получается очень мало, и работает этот код максимально быстро (быстрее любого обычного ОО фреймворка раз в 10 как минимум).
Работаю с CI, Yii, просто с php, а также один проект разрабатываю на FuelPHP
Использую Yii, но все больше посматриваю в сторону Python/Django
MZZ — очень удобный фрэймверк!!!
Mage (он же Zend Framework от Magento), но в опросе выбрал ZF.
CodeIgniter 2, выпущенный в этом 2011 году — changelog. Критически настроенных разработчиков, высказавшимся ранее в этой теме, приятно удивит отказ от поддержки PHP4 в пользу PHP5.
На мой выбор в пользу CI2 повлияло три наблюдения.
1. Хорошо организованная документация с человеческим языком, плавно вводящая новые термины и предугадывающая вопросы, начиная прямо с интерпретации парадигмы MV. Это важно, когда сам не являешься in-depth разработчиком, но нутром чуешь, что в мире существуют более оптимальные способы поддерживать растущий сайт, не прибегая к СMS и outsource. Под хорошей организацией я понимаю отдельно User's guide (читай основы), Wiki (закрепляй best practices) и Forum (спрашивай и отвечай, а что-то потом перекочует в Wiki) — всё связанное между собой, не оставляющее пользователя в состоянии «бросили в воду, плыви как знаешь».
2. Накопленная база штепселей, позволяющая быстро подключить шаблонизатор или генератор карты сайта.
3. Сообщество, то самое community. Именно оно принимает на себя «удар», когда что-то непонятно. Фасады многих фреймворков заявляют о дружелюбии своего сообщества, но то, из моего опыта, в миг улетучивается, когда речь заходит не о помощи с парой строчек кода, а об идейном дискурсе. Скажем, об организации документации Kohana (местные гики не видят проблемы в децентрализованности и несвязанности её частей, тем паче бьющихся между второй и третьей версией продукта, а иные и вовсе призывают вести документацию с помощью Git — «прощай все, кто не в теме»). Или когда просишь объяснить что-то на пальцах с помощью метафор из реальной жизни (файлы — листья на дереве, папки — ветки дерева и т.п.), те же админы CakePHP могут просто забанить. В этом плане самое взрослое сообщество я встретил в стане Symfony2. Судите сами: ребята терпимы к огрехам сообщений, возникающим вследствие уровня образования и языкового барьера, задают уточняющие вопросы вместо сиюминутных отписок или оценок, в ответах звучит фундаментальность, не требующая десяти дополнений «я имел в виду, что…». Читаешь и чувствуешь, что ребята гордятся своим детищем, и вместо того, чтобы защищать его от всех и вся, проводя линию «мы умные, а ты нуб», наоборот посильно стремятся перекинуть эволюционный мост, если угодно, прививая вкус к хорошей жизни. Прямо ностальгия по этикету old-school эх Фидо и групп Usenet.
Как видите, я обхожу здесь и скорость, и безопасность фреймворка, но это действительно не первые приоритеты, когда переходишь от плоской иерархии «один файл — одна страница» к разделенному хранению разметки и обслуживающего её программного кода.
На мой выбор в пользу CI2 повлияло три наблюдения.
1. Хорошо организованная документация с человеческим языком, плавно вводящая новые термины и предугадывающая вопросы, начиная прямо с интерпретации парадигмы MV. Это важно, когда сам не являешься in-depth разработчиком, но нутром чуешь, что в мире существуют более оптимальные способы поддерживать растущий сайт, не прибегая к СMS и outsource. Под хорошей организацией я понимаю отдельно User's guide (читай основы), Wiki (закрепляй best practices) и Forum (спрашивай и отвечай, а что-то потом перекочует в Wiki) — всё связанное между собой, не оставляющее пользователя в состоянии «бросили в воду, плыви как знаешь».
2. Накопленная база штепселей, позволяющая быстро подключить шаблонизатор или генератор карты сайта.
3. Сообщество, то самое community. Именно оно принимает на себя «удар», когда что-то непонятно. Фасады многих фреймворков заявляют о дружелюбии своего сообщества, но то, из моего опыта, в миг улетучивается, когда речь заходит не о помощи с парой строчек кода, а об идейном дискурсе. Скажем, об организации документации Kohana (местные гики не видят проблемы в децентрализованности и несвязанности её частей, тем паче бьющихся между второй и третьей версией продукта, а иные и вовсе призывают вести документацию с помощью Git — «прощай все, кто не в теме»). Или когда просишь объяснить что-то на пальцах с помощью метафор из реальной жизни (файлы — листья на дереве, папки — ветки дерева и т.п.), те же админы CakePHP могут просто забанить. В этом плане самое взрослое сообщество я встретил в стане Symfony2. Судите сами: ребята терпимы к огрехам сообщений, возникающим вследствие уровня образования и языкового барьера, задают уточняющие вопросы вместо сиюминутных отписок или оценок, в ответах звучит фундаментальность, не требующая десяти дополнений «я имел в виду, что…». Читаешь и чувствуешь, что ребята гордятся своим детищем, и вместо того, чтобы защищать его от всех и вся, проводя линию «мы умные, а ты нуб», наоборот посильно стремятся перекинуть эволюционный мост, если угодно, прививая вкус к хорошей жизни. Прямо ностальгия по этикету old-school эх Фидо и групп Usenet.
Как видите, я обхожу здесь и скорость, и безопасность фреймворка, но это действительно не первые приоритеты, когда переходишь от плоской иерархии «один файл — одна страница» к разделенному хранению разметки и обслуживающего её программного кода.
Использую Limp PHP Framework. Полюбил его за великолепнейший шаблонизатор (Macro), мощную реализацию ActiveRecord, пакетную структуру (базовый набор пакетов позволяет реализовать практически любые нужды), безграничные возможности расширения, грамотную структуру и эффективный внутренний код.
Разработчики фреймворка помешаны на Agile-подходе, так что большая часть кода покрыта модульными тестами. И конечно же контроль версий, баг-трекер, документация на Wiki, дружественный форум — куда ж без этого :) В общем, доволен и рекомендую.
Разработчики фреймворка помешаны на Agile-подходе, так что большая часть кода покрыта модульными тестами. И конечно же контроль версий, баг-трекер, документация на Wiki, дружественный форум — куда ж без этого :) В общем, доволен и рекомендую.
Сейчас использую kohana, до него Zend.
имхо zend очень большой, а в kohana всё только нужное :)
А кто работал с kohana и yii, что лучше?
имхо zend очень большой, а в kohana всё только нужное :)
А кто работал с kohana и yii, что лучше?
MODx Revo для того, что попроще. И Django для того, что посерьезнее и посложнее.
Изучаю на работе Symfony2 и убеждаюсь, что насколько он гибкий, настолько у него высокий порог вхождения.
Использую чистый PHP / свой framework. Причина — предсказуемое поведение до уровня электронов.
Использую самописную CMS на основе ZF, или «чистый» ZF, или его фрагменты — в зависимости от задач.
MODx Revo для простых и средней сложности сайтов.
А для сложных проектов, которые как раз намечаются, пока стою перед выбором.
Надеюсь его сделать в том числе и при помощи не малого количества полезных комментариев к этому опросу.
А для сложных проектов, которые как раз намечаются, пока стою перед выбором.
Надеюсь его сделать в том числе и при помощи не малого количества полезных комментариев к этому опросу.
Начинал со своего фреймворка, потом перешёл на wordpress (версия где-то 2.1).
Сидел на WP довольно долго, т.к. почти всё что требовалось решалось очередным плагином из офф.репозитория или быстрого допиливания, да и сейчас использую там, где нужно просто сайт с бекендом для страничек.
Потом наступило время CI и осознания что такое MVC. Прямо скажем, не слишком хорошо он для этого дела подходил, но благодаря качественной документации (в том числе и русской) все проблемы решались, хоть порой и криво.
Сейчас пользуюсь Symfony 1.4 и поглядываю в сторону второй версии. Так как параллельно приходится писать на Java (Spring+MVC/Hibernate/ZK/Tapestry), получаю истинное удовольствие от изучения, ибо перекликаются очень многие паттерны и подходы (DI, ORM, namespaces). Ну да про это уже писали выше.
И таки да, порог вхождения в Symfony довольно высокий, но зато когда разберёшься… ууух.
Сидел на WP довольно долго, т.к. почти всё что требовалось решалось очередным плагином из офф.репозитория или быстрого допиливания, да и сейчас использую там, где нужно просто сайт с бекендом для страничек.
Потом наступило время CI и осознания что такое MVC. Прямо скажем, не слишком хорошо он для этого дела подходил, но благодаря качественной документации (в том числе и русской) все проблемы решались, хоть порой и криво.
Сейчас пользуюсь Symfony 1.4 и поглядываю в сторону второй версии. Так как параллельно приходится писать на Java (Spring+MVC/Hibernate/ZK/Tapestry), получаю истинное удовольствие от изучения, ибо перекликаются очень многие паттерны и подходы (DI, ORM, namespaces). Ну да про это уже писали выше.
И таки да, порог вхождения в Symfony довольно высокий, но зато когда разберёшься… ууух.
Использую CakePHP уже 1,5 года. Собственно выбрал его в свое время, на основе нескольких прочитанных статей о его крутости. За всё время ни разу не пожалел о выборе. Скорость разработки увеличилась в разы. Жалею что еще раньше не применял фреймворки. Писать на чистом РНР, это всё равно что писать на ASM под винду.
Работаю с CMF Cotonti ( cotonti.com ), нравится в силу своей простоты и надёжности. да ещё и разработчики по-русски шпрехают :)
Пишу на PHP и не использую фрэймворки и CMS, т.к. они замедляют скорость работы сайтов. Хотя конечно обладают неплохой расширяемостью, но это легко компенсировать, в инете есть куча сайтов типа phpclasses.org где есть все необходимые скрипты.
Не буду очередной раз повторять всё, что говорят в пользу сторонних и самописных фреймворков. Рассмотрю лишь один аргумент в пользу сторонних фреймворков, который я часто слышу. Он звучит, примерно, так:
— Сторонний фреймворк 'X' хорош, потому что если меняется разработчик (или нужен ещё один), то легче найти специалиста, который знает этот фреймворк и время его входа в систему будет минимальным.
Или в другой вариации:
— Я разрабатываю сайты под заказ и намного лечге использовать сторнний фреймворк 'X', который реализовал 99% возможных потребностей, чем постоянно дописывать свой велосипед.
Но здесь не учитывается случай, когда программист написал свой фреймворк под конкретный класс задач. И этот фреймворк решает только эту задачу. Например, известный мне реальный случай, когда у программиста свой фреймворк для написания так называемых веб 2.0 приложений, где должен быть профиль, рейтинг, блоги, геотаргетинг и т.д. Такая мини социальная сеть. И ситуация такова, что он работает только с одним заказчиком, у которого все новые проекты именно такие.
А теперь вопрос вхождения новых разработчиков. Да тут всё просто, если даже не учитывать, что отношения заказчика и программиста таковы, что их долгосрочность не вызывает никаких сомнений, то с чего вы взяли, что программисту выгодно использовать сторонний фреймворк? Ведь в таком случае, его будет довольно легко заменить. А если будет фреймворк самописный, то заказчик становится отчасти зависим от программиста. При реальной необходимости, этот программист сможет легко обучить нового программиста фреймворку, который сам же и написал. Для этого, конечно, он должен обладать определённой структурностью. Но мы тут с вами ведь все программисты, что надо? :)
Отсюда вывод, что использование сторонних фреймворков выгодно для заказчика и уменьшает его риски, но не выгодно для разработчика, так как его услуги становятся значительно менее ценными.
А вы тут всё «технологии», «оттестированно», «опробированно», «велосипед». А это всё чисто экономический интерес.
С этой точки зрения, использовать сторонний фреймворк выгодно в собственных проектах, потому что для программиста это легче. Или в случае, если у вас софтверная компания, которая делает сайты под ключ — для скорости выполнения заказов и репутации.
Просто рассазал про случай, когда самописный фреймворк может использоваться. Может уберегу какого-нибудь заказчика от ошибки.
— Сторонний фреймворк 'X' хорош, потому что если меняется разработчик (или нужен ещё один), то легче найти специалиста, который знает этот фреймворк и время его входа в систему будет минимальным.
Или в другой вариации:
— Я разрабатываю сайты под заказ и намного лечге использовать сторнний фреймворк 'X', который реализовал 99% возможных потребностей, чем постоянно дописывать свой велосипед.
Но здесь не учитывается случай, когда программист написал свой фреймворк под конкретный класс задач. И этот фреймворк решает только эту задачу. Например, известный мне реальный случай, когда у программиста свой фреймворк для написания так называемых веб 2.0 приложений, где должен быть профиль, рейтинг, блоги, геотаргетинг и т.д. Такая мини социальная сеть. И ситуация такова, что он работает только с одним заказчиком, у которого все новые проекты именно такие.
А теперь вопрос вхождения новых разработчиков. Да тут всё просто, если даже не учитывать, что отношения заказчика и программиста таковы, что их долгосрочность не вызывает никаких сомнений, то с чего вы взяли, что программисту выгодно использовать сторонний фреймворк? Ведь в таком случае, его будет довольно легко заменить. А если будет фреймворк самописный, то заказчик становится отчасти зависим от программиста. При реальной необходимости, этот программист сможет легко обучить нового программиста фреймворку, который сам же и написал. Для этого, конечно, он должен обладать определённой структурностью. Но мы тут с вами ведь все программисты, что надо? :)
Отсюда вывод, что использование сторонних фреймворков выгодно для заказчика и уменьшает его риски, но не выгодно для разработчика, так как его услуги становятся значительно менее ценными.
А вы тут всё «технологии», «оттестированно», «опробированно», «велосипед». А это всё чисто экономический интерес.
С этой точки зрения, использовать сторонний фреймворк выгодно в собственных проектах, потому что для программиста это легче. Или в случае, если у вас софтверная компания, которая делает сайты под ключ — для скорости выполнения заказов и репутации.
Просто рассазал про случай, когда самописный фреймворк может использоваться. Может уберегу какого-нибудь заказчика от ошибки.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Какой PHP фреймворк вы используете? И почему?