А зачем? Смысл писать Гмаил заново? Вы таким образом не людей научите а себя. Людям нужна теория по структурному программированию "пользовательских интерфейсов, программных интерфейсов, принципы взаимодействий интерфейсов, для чего нужны интерфейсы, почему с ними проще, и т.д.". А строить ГМаил заново не вижу смысла совершенно.

FINoM, странный вопрос. Это как на курсах по c++ удивляться, что они драйверы для микропроцессоров не пишут.

Если вам хочется написать что-то крупномасштабное - так напишите, почему вас должны этому где-то учить? Сильно сомневаюсь, что создатели gmail'a учились его писать на курсах.

devote,
Теорию нужно давать с практикой. GMail выступает здесь как практическая часть. Впрочем, альтернативные идеи - велкам!

Никто не спорит, но для этого не обязательно писать ГМаил. Думаю для людей которые пытаются внять теорию, нужно давать практические задания по проще и более предсказуемые.
Составить несколько более простых примеров, аля examples описать их принципы, для задания построить на их основе или по их принципу ту или иную задачу. При этом описать свои действия, причины таких действий и т.д.

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

В этом то и дело что нужно обучать программировать не частями а именно объединенное/взаимодействующее программирование между блоками. Тоесть все описанное вами нужно уметь объединять в одно единое целое. Именно на этом этапе у большинства возникают проблемы.

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

Я думаю скорее участники запишутся/будут появляться после того, как узнают какая будет тема семинара. Ведь в этом цель - узнать что то новое. А пока неизвестно что там будет, записываться будут только те, кто очень мало чего знает и просто нужно научиться. В итоге получится, что семинар для них слишком сложный. В общем не правильно это.

trikadin, Илья Кантор,
devote лучше меня описал то, что я, собственно, хотел бы узнать. Вопрос касается не базовых принципов, типа ООП, DOM и прочего, вопрос касается проектирования и взаимодействия частей крупномасштабного приложения. GMail был приведен лишь как пример оного.

ууу, мне кажется это большинсту PHP программистов не нужно, а как спец курс делать затратно, или я не прав
Обычно некоторые компании пытаются делать курсы-проекты для определенного круга лиц, закончишвих курс, но это по Java так делают, могут по PHP, но по JS зачем?