pletinsky

На мой взгляд базисные знания следующие:

1) Клиентская верстка и стили (html, css). Можно пробежаться глазами хотя бы по теме. Почитать про правила верстки.
2) Клиентская логика, работа с DOM (Javascript, Jquery). Важная тема — стоит уделить ей время.
3) Теория распределенных приложений. — Веб приложения чаще всего являются распределенными. Поэтому стоит изучить архитектурные принципы распределенных приложений. API и т.д.
4) Базы данных (SQL, etc.) — Конечно начать стоит с классического сиквела — но стоит посмотреть и шире — например на nosql решения.

Далее стоит выбрать технологическую платформу. С вашим бэграундом вероятно стоит посмотреть в сторону Microsoft ASP.NET MVC. Это великолепное решение и погружение в обширный мир разработки в рамках решений MS. У них сейчас самые развитые языки программирования (C# 5.0), самые развитые инструментальные среды (MS Visual Studio), одна из самых совершенных виртуальных машин (.Net).
Решение удобнее всего для серьезных и масштабных проектов, хотя и для небольших вполне подойдет.
Следующий кандидат — Ruby on Rails. Это развитое решение с замечательным языком программирования и отличными каркасными решениями, заточенное именно под веб. Возможно лучше подойдет для небольших приложений — но и промышленные продукты без проблем потянет.
Он также очень распространен.
Ну и конечно PHP. Язык программирования данной технологической платформы отстает от требований к разработке больших решений — он скорее подходит для написания скриптов. Однако существует колоссальное количество каркасных решений для данной платформы, которые позволяют реализовывать даже приличного объема продукты. Кроме того данное решение наверное самое распространенное из всех.
И оно потихоньку подтягивается до уровня платформ для разработки промышленных продуктов.
Существует также множество других решений. Например огромный мир Java и решения на базе серверного Javascript.

Скоп работ будет состоять из следующих частей:

1) Клиентская часть (html, css, javascript). Тут вам понадобятся знания по верстке как раз и жаваскрипту. Также следует использовать различные базовые решения и фреймворки. Эта как раз та часть, где слишком глубокие знания (например использование чистого некроссбраузерного javascript) могут быть вредны и лучше все базировать на готовых платформах.
Часто эта часть в web приложениях бывает больше чем хотелось бы.

2) Серверная часть. Тут все определяется технологической платформой описанной в предыдущем абзаце. В веб приложениях как правило немного серверной логики — почти все можно заменить на внешние библиотеки. Но у разработчиков десктопных приложений всегда есть соблазн развивать именно эту часть потому что она им знакома — не поддавайтесь. Специфическая для проекта серверная логика нужна не очень часто. Если ее много — значить кто то увлекся велосипедами. Тоже касается разработок API и систем взаимодействия с внешними сервисами.

3) Базы данных. Конечно обязательно! стоит использовать развитые ORM системы. То есть нужно их изучить под выбранную вами технологическую платформу. Ну и конечно базовые знания баз данных тут тоже очень понадобятся — сиквел, реляционная модель и все остальное.

Дерзайте. Я за вас болею.

Выхода 3 на мой взгляд.

1) Маскимально детализировать требования, разрабатывая ТЗ до начала разработки проводя масшабную работу с заказчиком.
Тогда риски пролета будут зависеь прежде всего от того, как вы проведете работу по тому, чтобы заказчик подписался на составленные вами требования и от того, насколько детально и точно вы их опишите.
Достоинства: хорошо работает для небольших проектов, для конкурсных проектов, работа по ТЗ может в идеале стать чисто технологической и идти как по маслу.
Недостатки: огромная работа по формированию требований, высокие риски того, что по дороге выясниться, что все надо было делать не так, необходимость продавать заказчику данный цикл работы.

2) Провести высокоуровневую планнинг сессию оценивая не только обьем работ, но и предполагаемые риски опираясь на опыт предыдущих оценок проектов.
Тогда риски пролета будут зависеть от того, насколько совершенные технологии для оценок вы используете.
Достоинства: хорошо работает если есть большой опыт ведения проектов и с них снимались метрики.
Недостатки: требует определенного уровня профессионализма в менеджменте проектов.

3) Работать итеративно выпуская короткие релизы с кусочками функциональности с оплатой за каждый релиз.
(Итеративность — это не обязательно эджайл).
Риски пролета будут зависить прежде всего от того, сумеете ли вы сформировать требования так, чтобы выпускать приложение такими релизами. Это как правило возможно, но получается не у всех.
Достоинства: риски провалится с пониманием требований сведены к минимуму, так как мы их формируем по мере работы, заказчик доволен видя постоянный прогресс, можно на основании предыдущих итераций корректировать дальнейшие прогнозы оставшевося времени.
Недостатки: требует серьезной обработки заказчика для работы в таком ключе, особенно для тех, у кого уже выделен бюджет на реализацию и на конкурсе.

Мне показалось эффективным использования 80%-90% практики на 10%-20% теории.

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

Смотрите профильные статьи уважаемых профессионалов и сразу применяйте их на практике.

Вообще техника предоставления информации и обучения очень важна. Используйте эффективные механизмы.

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

Относитесь более скептически к разговорам о том, что обучение человеком-преподавателем ничего не заменит. При грамотном подходе автоматические курсы часто эффективнее и быстрее, чем обучение человеком.

Бегите немедленно от любых лекций, курсов, обучающих материалов, если слушая первые 5 минут — вы понимаете, что тратите время впустую.

Мне кажется этого достаточно чтобы эффективно обучаться и поиск каких сверхъестственных методик, которые могут научить супербыстро и суперкачественно совершенно ни к чему.

пробовали в разметке использовать для этого конвертеры?

Все верно. В случае WinForms мы управляем общей схемой расположения элементов и свойств их, но рисует злементы сам виндовс и многими вещами мы не можем управлять. И разные виндовсы могут рисовать их по разному.

Приложение заточенное под Windows XP (классический стиль) будет выглядеть убого в Windows 7 с аеро стилем. Так же и аеро стилю (Windows 7) нечего делать в метро стиле (Windows 8). Именно это и круто, что нам не приходится явно затачивать каждое приложение на специфический юай операционной системы.

WPF приложения тоже могу выглядеть по разному в разных операционных системах, но предоставляют больше возможностей управления стилями.

По второму вопросу InitializeComponent это часть работы по инициализации окна в WindowsForms. Отключат ее нельзя — иначе контролы в окне не будут проинициализированы.

Непонятно зачем вы хотите привести к одному внешнему виду. В двух разных виндовсах совершенно разные внешние стили. Они зачены под весь остальной дизайн операционной системы. Если даже это и можно как сделать (хотя врятли), делать этого не следует. Вам же под Android не придет в голову пытаться сделать точно такой же календарь. Выкиньте из головы эту ересь.

Разница между разработкой десктопных приложений и приложений под веб на практике очень велика.
Там нужно совсем другое мышление. Там другие науки (верстка, адаптивность, кроссбраузерность, скриптовые языки, которые труднее тестировать, протоколы веб сервисов и др.). Распространены другие архитектурные принципы (распределенные приложения, API, Rest сервисы и др.).

Если вы раньше разрабатывали коробочные решения, то вы в любом случае при переходе упадете на несколько позиций вниз (даже если и не джуниор девелопер). Это по факту. Работодатель конечно может вас на приличной позиции держать. Но если вы не будете это понимать и не найдете себе ментора, то горе тем, кто будет поддерживать ваши решения.

Это понятия из разных сфер.

1) Есть модель клиент — сервер. Смысл что клиент может делать запосы серверу, а сервер на них отвечать.
Приложение, которое использует какой то сервис в интернете является клиентом этого сервиса. И в каком то контексте является клиентским приложением.

2) Есть модель браузерных приложений. С этой точки зрения «десктопное» приложение — это приложение, которое разворачивается как бы на рабочий стол. То есть является полноценным приложением операционной системы.
Наобором браузерное приложение — приложение, которое запускается в рамках браузера, а операционная система о нем не знает.

3) Есть модель мобильных приложений. Это приложения, которые создаются под мобильные платформы и обладают определенными особенностями для удобной работы на телефонах, планшетах и т.д.
Соответственно немобильные приложения — для немобильных платформ.

Фактически вы можете использовать хоть все три модели одновременно. Единственное — понятие «десктопное» приложение может не очень вязаться с «мобильными» приложениями, но просто потому что первое понятие стало ассоциироваться со стационарными компьютерами, которые тоже иногда называют десктопами.

То есть может быть клиентское мобильное браузерное приложение или даже клиентское мобильное десктопное приложение.