Реализовывать сайт на готовом движке или писать с нуля?

А чем вообще отличается все это? Просто, если дизайн я могу сравнить, то как я могу ощутить программирование сайта? Вот в чем главный вопрос. На каких-то движках он будет тормозить или что? В чем суть всех этих разных методов? В чем выгода писать с нуля и так далее? Можете, пожалуйста, подробно объяснить?

natoster: выгоды писать с 0 нет никакой - никто ведь не пишет для каждого сайта свой язык программирования

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

Сравнить ты сможешь по способу реализации и прозрачности

Давно уже нет проблем с таким понятием как "тормозит" - нужно очень постараться, чтобы что-то тормозило

sim3x: Смотрите, покупать сайт с нуля сейчас не стоит, по этому лучше обратить внимание на программистов, которые предлагают решения на готовых движках (кто-то предлагает друпал, кто-то shop script 6). Но, если я правильно понял, на выходе я получу с точки зрения сайта одно и тоже и единственная разница между всеми фрилансерами будет лишь в цене и внутренностях (коде, так скажем)?

natoster: да
Только от внутренностей зависит все

sim3x: Честно говоря, я совсем запутался)) Вчера я примерное ТЗ (вы видели его в прошлой теме, ее удалили) разослал фрилансерам с fl.ru (у которых много отзывов), многие хотят не меньше 50к за проект и сроки 1-3 месяца. Кто использует битрикс, вообще за 200к просят. Сейчас создал проект, чтобы фрилансеры писали сами. Полно людей, которые готовы взяться через безопасную сделку за 20-25к и сроками всего 10-14 дней) это развод?)

natoster: демпинг и надежда сделать копипастом из похожего проекта

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

natoster: попробуй

Цена не есть отражением "качества", тк само "качество" без наличия метрик не существует
А для того чтоб получить метрики тебе нужно четко понимать, что ты хочешь получить

natoster:
тормозить - это понятие условное.
мы не заем какая у вас нагрузка, какой объем данных, как сложен поиск по сайту и т.п, сколько вы можете ежемесячно тратить на хостинг, какая квалификация исполнителя - поэтому нельзя сказать будет ли тормозить. мы даже не знаем, что такое тормозить в вашем понимании.
sim3x:
зависит от степени индивидуальности задачи.
в данном случае задачу, возможно, целесообразно решать с нуля.
все зависит от того откуда они будут брать данные и как будут их представлять.
если это автоматическая закачка товаров с 1000 магазинов, то на фоне объемности парсеров, задача написать представления страничек будет стоить немного денег.
natoster:
у вас не типичный интернет-магазин, поэтому типовые решения вряд ли подойдут. нужно уточнение постановки задачи, чтобы сказать точнее.
natoster:
Разбег 20-50 и до 200 - это вполне нормально.
все дело в плохой формализованности вашей задачи.
каждый исполнитель понимает вашу задачу по своему.
если это действительно ввод адреса, определение индекса и вывод списка заранее загруженных (через файл например) магазинов, то задача довольно простая. И 20 тыс. рублей и неделя - вполне нормально.
и по постановке задачи именно в такой формулировке вообще не понятно зачем тут нужен Shop Script или даже Drupal.
для именно такой постановки задачи как сейчас будет дешевле будет написать небольшой кусочек кода и сделать сайт с нуля.
постарайтесь описать более внятно. что нужно делать и что НЕ нужно делать - чтобы исполнители точно знали, а фантазировали.
natoster:
вы не можете знать является ли человек новичком, может у него 10 лет на других сайтах или в офф-лайне, просто нет истории на fl.ru
если финансы позволяют и задача такая простая, то лучше больше заплатить, чем тот минимум в 20. но обложить исполнителя подробнейшими требованиями.
sim3x:
про метрики отлично сказано.
natoster:
в том то и дело, что работа программиста плохо формализуема. можно одно и то же получить и в раза дешевле и в 2 раза дороже. и даже в 2 раза дороже, но хуже.
и именно поэтому чем более подробно и формально вы опишете свою задачу тем лучше.

abcyu: парсер также пишется на фреймворке

sim3x: если он 1.

abcyu: ?

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

Описание задачи слишком поверхностное.
Под описание задачи подходит и такое:

1. Есть некий файл с данными, содержащий список интернет-магазинов и адресных индексов.
2. Делаем одну страничку, которая введенную строку адреса отправляет в DaData.
3. Получаем индекс, отображаем магазины на второй страничке.

Тут вообще не нужны фреймворки никакие.

Видимо, часть исполнителей, поняла задачу как то так, иначе непонятна цена в 20 тыс. рублей и неделя времени (10 дней там для подстраховки).

abcyu: фреймворк не нужен только в случае статического сайта из html

sim3x:
пишу на Go. там для реализации функционала отображения страниц сайта вообще не нужны frameworkи.

abcyu: орм, валидация форм, рест апи из орм, оптимизация картинок и тп видимо тоже встроено

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

abcyu: а теперь найдем в пхп стд либ с таким же качеством исполнения как и в го

sim3x:
спрашивается, зачем фреймворки?

abcyu: орм, валидация форм, рест апи из орм, оптимизация картинок и тп

sim3x:
это просто библиотеки.

abcyu: не всегда

sim3x: не всегда, но зачем фреймворки?
ОРМ прекрасно строится на библиотеках и не требует интеграции с другими компонентами.
Так же как и валидация форм.

Админка типа как у DJango это круто, тут понятно зачем нужна интеграция.
Но иногда это мешает. Фреймворк становится по управлению из админки близок к CMS. Слишком много возможностей.

abcyu: когда столкнешся с большим проектом на сильносвязанных компонентах - поймешь

sim3x:
да, выводы были такими: следующий проект делать без фреймворка. не прогадал. ))

abcyu: значит после тебя люди будут плеваться и вспоминать твоих родственников до четвертого колена :)

sim3x:
это нескромно, но после меня - точно не будут плеваться.

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

abcyu:
ниразу не слышал других слов от уходящего "гуру"

sim3x:
не забывайте, что мы имеем дело с весьма амбициозным проектом и небольшой суммой денег.
а также отсутствием технической компетенции заказчика.

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

abcyu: чаще всего, гибкость нужна на етапе прототипирования, тк качество кода неважно - поддерживать прототип никто не будет

В продакшен коде гибкость не нужна, желательно вообще иметь на большую часть случаев, только один шаблон

Если про "в данном конкретном случае" говорить как про прототип, который потом будет выброшен, то согласен

sim3x:
на таком тех задании как мы имеем это будет прототип.
только вот выброшен он не будет. будет в эксплуатации некоторое время, пока заказчик поймет что ему на самом деле нужно да и окупается ли это.