[Riim]

Если прочитать прикрепленный файл, то соотношение работы с серверной частью ко всей остальной ни как не может быть 1:5 , т. к. судя по списку:

ПОРЯДОК РАБОТЫ
1. СОЗДАЁТСЯ НАБОР ЭСКИЗОВ ФОРМ. ЭСКИЗ МОЖЕТ ПРЕДСТАВЛЯТЬ ИЗ СЕБЯ КАК СЕРИЮ КАРТИНОК, “ИЗОБРАЖАЮЩИХ” ФОРМУ, ТАК И ПОЛУГОТОВОЕ РЕШЕНИЕ В ВИДЕ HTML-ФАЙЛА, ВИЗУАЛЬНО ИДЕНТИЧНОЕ КОНЕЧНОМУ ВАРИАНТУ, НО БЕЗ ФИШЕК, НЕ ЗАТРАГИВАЮЩИХ ДИЗАЙН.
2. ВЫБИРАЕТСЯ И УТВЕРЖДАЕТСЯ 2 ЭСКИЗА.
3. ЗАПУСКАЕТСЯ РАЗРАБОТКА СКРИПТА-ОБРАБОТЧИКА И ФОРМЫ ПО ОДНОМУ ИЗ ВЫБРАННЫХ ЭСКИЗОВ.
4. СДАЁТСЯ СКРИПТ-ОБРАБОТЧИК И ФОРМА
5. РАЗРАБАТЫВАЕТСЯ И СДАЁТСЯ ВТОРАЯ ФОРМА

6. СОЗДАЁТСЯ СЛЕДУЮЩИЙ НАБОР ЭСКИЗОВ ПО ТАКИМИ ЖЕ ИЛИ ИНЫМИ ТРЕБОВАНИЯМИ К СОБИРАЕМЫМ ДАННЫМ (ИЗМЕНЕНИЕ ПОЛЕЙ ФОРМ ИТД).
7. ВЫБИРАЕТСЯ ОДИН ИЛИ НЕСКОЛЬКО ЭСКИЗОВ
8. ПОСЛЕДОВАТЕЛЬНО РАЗРАБАТЫВАЮТСЯ И СДАЮТСЯ ФОРМЫ
9. ПЕРЕХОД НА ШАГ #6

поработать над клиентской частью придется не только как js-программисту, но также как дизайнеру и юзабелисту, а их (дизайнеров/юзабелистов) работа выглядит простой лишь для тех, кто ее никогда не делал. Кроме того судя по последнему пункту этого списка:

ПЕРЕХОД НА ШАГ #6

проделать все это (вероятно включая и javascript) придется n-количество раз.


Так же написано:

8. скрипт-обработчик может располагаться на другом сервере, нежели тот, с которого был загружен код формы (требуются другие техники, нежели использующие XMLHttpRequest())!

и следующее:

7. Компактный код. Код и данные должны занимать в исходном виде как можно меньше места.

т. е. кроссдоменный ajax без готовых решений, а это серьезная тема для целой книги.

Далее написано:

1. Объявления однотипных данных, массивов итд должны минизировать избыточность и реализовываться способом (в случае наличия нескольких альтернатив), занимающим как можно меньше места в исходнике.
2. Особое внимание на code reuse. Копипаст больших кусков кода из одних частей сорса в другие категорически не приветствуется.

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

Всплывающий слой так же создает свои проблемы. Особенно если его положение и размеры зависят от размеров окна браузера.

И что остается на сервере? Выбрать данные из базы, преобразовывать в json, для чего уже у всех есть необходимые наработки (в большинстве случаев, просто выбираем данные, пропускаем их через функцию, которая уже всему научена, и можно отдавать клиенту), далее несколько регулярок для валидации и если не валидно занести что-то в базу. И все это без геморроя с кроссбраузерностью.

Я оцениваю сложность работы с серверной частью и с клиентом в соотношении 1:200 и это притом что опыт работы с клиентской частью у меня на порядок выше, чем с серверной. Может (читать: наверняка) я и ошибаюсь, но уж точно не в большей степени, чем вы, dexored, с соотношением 1:5 .

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