Григорий Дидус

$('form').bind('submit', function(e){
e.preventDefault();
form = $(this);
$.ajax({
            url: handler.php,
            data: form.serialize(),
            type: "post",
            success: function (data) {
            },
            error: function () {}
        });
});

data - html код сгенерированный с помощью php.
js => jQuery => $.ajax

Тут для начала нужно прочитать про тег form htmlbook.ru/html/form
а потом про то как получать в php значения от клиента: php.net/manual/ru/reserved.variables.get.php
как дело пойдёт, прочитайте и про фильтрацию пользовательских значений.

Как разберётесь с этим, можно будет переходить к JS.

Не везде и не всегда нужны классы. Вы верно заметили. НО! Прежде чем принять решение о том, что в конкретном месте кода класс только вредит, нужен профайлер или другие инструменты позволяющие принять такое решение. К примеру в Python словарь значительно выигрывает по скорости чем класс с методами.

Фишка ООП в том, что человек уже думает классами! Поднимаем голову к небу и видим "Птица летит", другими словами "У объекта "Птица" был вызван метод "Лететь"", но мы так сложно не думаем и для нас это просто "Летящая птица".
Вспомните детство и моменты когда родители посылали за хлебом. Как это происходило? Возможно это было так: "Объект сын в твое поле ложу объект "Задача" с полями "хлеб", "комод" и "100 рублей", в поле "результат" ложу "Хлеб". Объект сын вызываю метод "Купить"". Не думаю что это было так, мне кажется это было так: "Сын возьми 100 рублей и купи хлеба". В неявном виде обратились к объекту "Сын", вызвали метод "Взять" и передали аргумент "100 рублей" и ожидаем результат вызова в виде значения "Хлеб".

Попробуйте процедурный подход переложить в нашу естественную жизнь? ;) Попробуйте так общаться, процедурно. Это очень сложно. Потому что человек привык думать объектами! Самолет, кошка, лошадь, дерево и др. Для нас вроде есть концепция "кошка", но конкретная кошка "Масяня" сильно отличается от другой конкретной кошки "Машка".

Изучая задачу мы прежде всего должны задать вопрос : "Что является условием завершения задачи?" и вторым не менее важным "Что используется при достижении результата?". Вот это "что используется" как правило и есть объекты.

От многого зависит. Если человек гуманитарий, то тяжко придется)
Если нет багажа знаний по программированию в принципе (какие-то базовые понятия, паттерны, ООП и т.д.), то изучить-то ты изучишь, но толку с этого будет мало.
Нужно еще понимать, что с созданием сайтов/web-приложений связано еще очень многое помимо знания непосредственно языка программирования: SQL, конфигурация сервера, права на файлы, сессии, HTTP заголовки... Дальше - больше: ORM, CMS/CMF какая-нибудь (а лучше какие-нибудь).
В общем, PHP сам по себе - всего лишь язык, и нужно знать инфраструктуру этого языка.
В итоге, отвечая на твои вопросы:
1) От недели до бесконечности.
2) Любым доступным. Вышка укажет (но не научит сама по себе), с чего начать. Книги дают основы. Гугл (в частности документация в его выдаче) дает все остальное. Видеоуроками, кстати, ни разу не пользовался, так как по мне быстрее прочитать. А, ну и практикуйся, без практики обучение - бесполезная трата времени.

Идите в том порядке изучения, который написали.
После изучения 1, 2, 3 попробуйте сделать что-то свое, а потом устройтесь юниором на работу.
Работа с более опытными разработчиками даст вам хороший толчок в развитии, а так же опыт работы в команде и умение разбираться в чужом коде.

Контейнеры #right и #center местами поменяйте.

Вот в такую последовательность:

<div id="left"></div>
<div id="right"></div>
<div id="center"></div>

Имеет ли смысл рассчитывать на работу js-специалиста (т.е. в случае если навыки js используются значительно интенсивнее других)?

Безусловно

Возможно ли это на фрилансе?

Безусловно

Что лучше учить в связке с js?

Учить CSS, HTML, SVG, фреймворки, и разного рода интерпретаторы (HAML etc.), препроцессоры (SASS, Stylus etc.).

Имея базовые знания по CSS, HTML стоит ли нацелится на них и периодически использовать js?

Без этих знаний никуда.
Пример: анимация в CSS быстрее, используем её. Для старья используем таймеры.
Пример: для хорошего соответсвия UX используем элементы формы, из состояния, события.

Или лучшем будет изучение frontend фреймворков? Необходимы ли при этом будет в дальнейшем много верстать? Насколько перспективна эта сфера деятельности?

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

Если использовать github-аккаунт как часть портфолио, что наиболее привлекательно будет в нем для работодателя?

Примеры решения конкретных задач. А разве в гит можно выложить что-то неконкретное?))

Имеет ли смысл довести какие-то свои задумки до конца перед началом поиска работы, или лучше начать сразу а уже стабильно оплачиваемые заказы могут пойти в портфолио?

Нет предела совершенству. Продавать нужно начинать до окончания работ. Так же и в работе — не нужно откладывать поиск вакансии до момента, когда вы постигнете вселенную.
Во-первых, такого никогда не случится.
Во-вторых, ваши знания могут быть уже достаточны для части работодателей.

Возможно ли получить помощь\поддержку в начале пути фрилансера от человека активно этим занимающемся?

Возможно. Но на условиях подмастерья. Будьте готовы к этому.

Ну и напоследок чисто-субъективные вопросы на которые я не жду аргументированного ответа, а просто совета, основанного на жизненном опыте:
Стоит ли нацеливаться на javascript или лучше менять акцент (или вовсе бросать js) на другой язык?

Ваще непонятный вопрос. Если вы категорически не согласны с концепцией JS — бегите прочь от него. Если всё понятно — зачем спрашивать?

Стоит ли уповать на фриланс или лучше искать обычную работу?

Фриланс и есть обычная работа. Вопрос абсолютно не связан с программированием или языком программирования.

Действительно, уважаемый. Это слишком. Вряд ли я затрону все тонкости, но попробую наметить примерный путь:

0) Пользователь вбивает в адресную строку браузера адрес сайта (нажимая клавиши на клавиатуре, которые замыкают определённую дорожку в матрице, по которой происходит определение нажатой клавиши, что через шину USB в какой-то момент передастся OS, где это поймает HID-драйвер и вызовет определённое прерывание, что OS передаст как событие/или_ещё_как в программу, которая вызовет соотвествующую функцию из API менеджера окон, которая изменит содержимое строки и в результате когда-то будет перерисован UI-элемент, а если нажат был Enter, то начнётся следующее).
1) Браузер вытащит из input'а строку с запросом и посмотрит, похоже ли это на адрес. Если да, то добавит недостающие уточнения (например, http или file протокол, порт и подобные довольно стандартные вещи). Если нет - то скорее всего создаст запрос в поисковую систему, установленную по умолчанию (я более не буду опускаться до таких бессмысленных деталей, как вызовы API-функций, иначе я буду набирать это сообщение ОЧЕНЬ долго). В любом случае на выходе мы по сути получим URL, который надо загрузить. Протокол file:// мы рассматривать не будем, ftp далеко не везде есть, https:// на не хватит вечности, так что остановимся на http, который по сути есть tcp/ip по умолчанию на 80 порту с определённым форматом общения.
2) Окей, url есть. Теперь нам нужен адрес, к которому обращаться. Так как http это tcp/ip - нам нужен ip адрес. Здесь нам помогают dns-сервера. Обычно, нормальный провайдер устанавливает у себя кэш-сервера dns, которые не обращаются по стопицот раз за vk.com к ответственному серверу com-зоны. Давайте не будем отвлекаться на то, как происходит там общение, если что - вот (вики тем хороша, что часто содержит внизу релевантные ссылки). Скажу лишь то, что на выходе мы получаем ip адрес(а).
3) Имея адрес мы можем запросить страницу. Собственно, всё что после первого слэша - это как-бы параметры для http-сервера: какую именно страницу запрашивать, он всё же не телепат. Конечно, можно было бы немного схитрить и отправить читать про tcp/ip, но ведь существует и shared-hosting. Ограничемся лишь его упоминанием. Собственно, по полученному адресу отправляется GET запрос, который и обрабатывает сервер, находящийся по полученному IP-адресу.
4) Сервер же, получив адрес, начинает распарсивать строку, медленно вытягивая нужные данные из баз-данных и настроек, выполняются сотни скриптов, иногда делается ещё не одна сотня различных запросов на другие сервера (здесь и разного вида метрики и разного вида HADOOP и т.д.). Пройдя сквозь скрипты и темплейторы в самом конце мы получаем html-страницу, готовую к употреблению. Её-то сервер и отправит в ответе (после заголовков, конечно).
5) Вот и началось самое интересное. Получив html страницу браузер начинает жутко надругаться над CPU, HDD и GPU, попутно сжирая тонны RAM и мусоря в swap. Виной всему нереальные для полного соблюдения стандарты от небезызвестной w3c.org. Для облегчения многие делают костыли, вроде webkit, а некоторые и вовсе забивают на него и пилят свой стандарт с преферансом и картёжницами (впрочем, в последнее время становиться лучше). Здесь снова начинаются сотни вызовов API ОС, windows manager'а и прочих библиотек, вроде boost, qt или libpng. В ходе работы в RAM строится макет, по которому потом строится нечто вроде PDF (тоже сильно векторный), что, потом, обрабатываясь быстрыми шейдерами на GPU, выдаётся на экран. Опять же, многое пропущено, но вряд ли кому-либо, кроме парня в свитере с оленями, действительно интересно, как работает GDI, DirectX или OpenGL.
6) Ах да, мы же забыли про тысячи js-скриптов, миллионы картинок и анимации с котиками, а также о таких дополнительных плюшках, как flash-player или java-weblets. В кратце, что js, то и flash и java - это виртуалка, со специальной архитектурой. Они, виртуалки, конечно разные (хотя flash и js довольно похожи, ещё бы - ECMAScript один и тот же). JS - самый интегрированный внутрь браузера, он же и самый медленный чисто визуально (ибо последние два имеют доступ к быстрому GPU), хотя самый быстрый в попугаях. Второй постепенно вымирает и представляет из себя, так же как и третий специальную shared-библиотеку, о которой браузер как-нибудь узнал и которой скармливает специальное содержимое помечанное специальным тегом html. Третий уже почти умер и встречается лишь изредка или в каком-нибудь энтерпрайзед со страшным legacy-базой. Ну здесь из сылок разве только гугл. Ибо сколько всего - даже не сообразишь. Да и вообще, эта тема ещё скучнее GDI, DirectX и OpenGL и к свитеру с оленями требуются ещё очки с толстенными стёклами, дающие стопицот к терпению и задроству над матаном. Если в кратце, то в случае JS, всё что было загружено в память и не думает выгружаться и формирует этакое дерево - DOM, над которым с помощью специального API и происходят модификации. При этом, перед тем как исполниться, весь JS-код компилируется, в нативный для VM байт-код. То же самое в общем-то и со вторым и третьим, разве только они не имеют доступа к DOM и организовать его - дело тех ещё костылей. Ах да, забыл ещё про Silverlight (или как оно там пишется), который сдох, не успев родиться. Так же как и Java, жив в серьёзном энтерпрайзе, не поскупившийся не "дешёвую" поддержку MS.
7) Ну... А дальше пользователь нажимает на нужную гиперссылку и всё по новой.

За кадром остались такие костыли, как ajax, websockets и прочая асинхронная ересь. С ней всё в миллионы раз сложнее. И к очкам со свитером потребуется ещё и... а чёрт их знает, что они там ещё носят. Ну да ладно, я искренне завидую тем парням (и девушкам), которые разбираются во всей этой машине. Целиком. Ибо это лишь верхушка айсберга. Разбавленная не лучшей памятью и ужасным гуглом.

P.S. Не бейте сильно за грамматические и синтаксические ошибки. Спеллчекер приказал долго жить, да и 5 утра как никак.

UPDATE
На хабр выложили неплохой перевод дающий некоторое представление, как браузер ругается над памятью и процессором. Хотя и весьма поверхностное,