Готовая CMS vs система "под себя" (холивар)

Если клепать говносателиты, чем тут 99% занимается, то коробочная рулит, а под нормальный проект в 90% случаях готовое говно-решение врятли подойдет.

аплодисменты товарищу!

Партбилет на стол и на выход. Дорогу показать?

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

Если сказать нечего то не стоит нести бред.

Ух ты! Воскликнул я по нескольким причинам.

1. Илья вернулся и сразу замутил воду :).

2. Неожиданно общественное мнение судя по текущим комментам больше ЗА коробочные решения чем ПРОТИВ как было раньше. Наелись или повзрослело общество? Хм.

3. В голову лезут неожиданные выводы. Как один из создателей коммерческого коробочного продукта я должен был бы агитировать за коробочный продукт. Но вообще то мы его делали для себя, получается что с этой позиции он вообще-то для нас "самописный" :).

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

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

Самописные решения для сайтов не нужны вовсе. Все "сайтовые задачи" давно решены по стотыщмильенов раз. Самопись нужна там, где лежат обычные задачи автоматизации процессов, благо это поле намного шире чем "какой-то там" веб. Еще пара лет и CMS вырастут в нормальные отлаженные системы, которые наконец-то не будет никакого смысла писать с нуля или пытаться повторить своими силами.

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

А разве нет? Сапу в подписе пиаришь для заработка, ну не вешать же ее на белые сайты, значит ты подстрикаешь делать говносайты (логично?)

Согласен...

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

CMS хороши если сайт нужен уже завтра, для своих проектов выбрал drupal

Есть один нюанс: а правильно ли CMS (будь это коробка или самопись) допиливать/выпиливать под требования заказчика? Не проще ли вначале разобраться с самими "хотелками" клиента? В подавляющем (не, не так: В ПОДАВЛЯЮЩЕМ) большинстве случаев, если заказчику, увлеченно и в красках описывающего разработчику задуманный "прибамбас", задать вопрос "а зачем это?", он не сможет и внятно ответить... Ну признайтесь, господа сайтостроители, как часто клиенты просили у вас, чтобы у них на сайте "был чат", типа "для общения с нашими менеджерами". Было ведь, и не раз :).

Между разработчиком двига и заказчиком-владельцем сайта обязательно должен быть жирный такой слой услуг, именуемый консалтингом. Это их задача - проанализировать потребности клиента и с точки зрения необходимости, и с точки зрения реализации. И дать вердикт "однозначно, только кастомизированное решение" или наоборот...

Если сайт будет развиваться, то программист в штате/фриланс необходим по любому. Так как если заказчик не знает пхп и прочего, то даже техподдержка ему не поможет. Нужно ещё учитывать, что тех поддержка иногда обещает решение только после выхода новой версии через несколько месяцев. Для того чтобы найти временное решение, опять таки нужен местный программист. А раз он есть, то можно и заказать ему СМС с нуля.

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

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

Конечно, в теории, программер берет коробку и строго по АПИ, документируя свои действия, пишет культурный и оптимальный код. Который потом легко кому угодно передается. К сожалению в большинстве случаев, программер который достаточно умен и профессионален, не сильно заинтересован в клепании однотипных сайтов на потоке, ему это будет просто скучно. И вот тут-то и выходит на первое место практика. Неслабое количество сайтов "на коробке" это именно "куча своего кода", убивающая все те теоретические преимущества. Если конечно речь идет о проекте чуть более индивидуальном и крупном, чем очередной каталог.

Второй интересный минус коробок, это заказчики любящие что бы все было с точностью до запятой выверено как им хочется. Такой заказчик потратит 2 недели времени что бы меню было именно таким как он хотел, при этом забьет и отложит внедрение нужной платежной системы. Немного утрируем что бы показать суть. Кстати на западе таких въедливых заказчиков еще больше чем тут, поэтому и коробки там на фрилансе не так популярны. "Своя" цмс позволяет выполнять мелкие прихоти заказчика более быстро и оптимально. И опять же, можно работать и заниматься делом, а не объяснять заказчику почему для реализации его прихоти, такой мелочи, нужно 2 недели, вместо 1 дня.

Минусы "своих" цмс достаточно очевидны, так что даже останавливаться на них не видим особого смысла.

А глобально всё банально. Типовой проект - типовой движок. Много особенностей проекта, требующих солидной доработки типового движка - уже есть смысл задуматься об индивидуальном движке. Потому что когда количество доработок становится таким, что "типичности" в движке остается очень мало, то и смысл в коробке теряется, ибо коробка как раз индивидуальным движком и становится уже... только не сильно приспособленным под нужды, в меру своей изначальной "универсальности".

Ну, еще конечно коробки бесценны для быстрого старта. Когда рекламу уже запустили, а сайта еще нет:)

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