VZVZ

> сделать проксирование через django тоесть все запросы будут уходить через python (не очень хороший вариант).
Почему не очень хороший?
Если там MVC, то просто в контроллере создаете новый Action, внутри которого делаете запрос, и возвращает ответ на этот запрос. Всё.

> Либо добивать js какой то библиотекой для таких запросов
Где вы такое видели?
Библиотеки - это всего лишь обертки для чистого JS, которые упрощают с ним работу, но не привносят никакого нового функционала.
Что нельзя на raw JS, для того нет и библиотек

Вариант с HTML быстрее работает и быстрее реализуется, особенно если имеете сайт без AJAX и вам нужно за день добавить AJAX.
Реально очень быстро можно сделать.
Почитайте, в этой статье все с этого начинается:
codeproject.com/Tips/1065669/How-To-Build-Web-Site...

Но в том случае, если соберетесь также писать мобильный/десктопный клиент для своего сайта, то из какой-нибудь Java работать с HTML (мучительно парсить его через регулярки или DOM-модель), будет неудобно.
Также не очень удобно будет делать рестайлинг подобного сайта, придется копать и бек-енд.
Из рассчета на такие случаи, лучше сделать удобное стройное REST API, которое возвращает только данные (т.е. JSON), а обработкой занят уже чисто клиент.

Кстати, "компиляцию" в HTML помогают упростить библиотеки типа ReactJS. Сам пока не пробовал, но говорят, что да, причем это не то, что jQuery, а нечто другое.

Это архитектура, а не стиль написания кода. Стиль - это где ставить {, }, какие делать табы и т.д.

Пример 1:
лучше класс с main все-таки развязать от класса MainTest, по отдельным файлам.
В C# недаром по дефолту Main всегда идет в отдельном файле Program.cs
Это реально облегчает раскопки чужого кода - знаешь, откуда начать.

Пример 2:
в случае с GUI - тем более.

Я верно понимаю, что nw.js - это всего лишь одна из библиотек для node.js?
Если да, то открою вам тайну.
Что бы вы ни писали, вы всегда работаете с какими-то библиотеками.
Абсолютно любые так называемые "стандартные", "встроенные" средства языка (от стандартный функций до типов данных) - можно представить как элементы его "стандартной библиотеки". В некоторых языках это де-юре (как в C#), и абсолютно во всех языках это де-факто, ибо в работе "стандартная библиотека" - это такая же библиотека, как и сторонние. Неважно, работаете вы со встроенным типом string (который в данном языке физически не реализован как библиотечный класс) или с классом String из какой-то реальной библиотеки.
Сторонние библиотеки бывают разные. Одни нужны для очень широкого круга задач (как jQuery), другие - для более узкого. Какая библиотека нужна для данной задачи, ту и используют.
Стандартная библиотека - нужна для широкого круга задач, и необходима, поэтому решая любую задачу, вы будете учиться работать и с ней тоже.

Добавлю к Станиславу:
помимо умений и рук, еще так или иначе нужен бюджет и сроки. А они определяются тем, реально ли в данном проекте нужна уникальная "техническая часть" или нет. Если да - фреймворки (а то и вообще голые HTML+JS+CSS+серверный ЯП+БД). Если нет - CMS.
Это от проекта зависит.

Есть средства типа jsbeautifier.org но они ж тупые, с шаблонными решениями. Это только для деобфускации/деминификации. Там хоть какое-то форматирование уже хорошо.

А если свой код писать, то надо просто пользоваться IDE, которая делает табы и пр. форматирование, хотя бы Notepad++.
А эти средства - если и применять, то осторожно.
Иногда лучше написать так:
if (условие) { команда(); }
if (условие) { команда(); }
Нежели вот так (как сделает такое средство):
if (условие) {
команда();
}
if (условие) {
команда();
}

> хотел бы найти кого-либо готовых участвовать в проекте на добровольных началах
А зачем работать бесплатно, когда можно работать за деньги?
Я еще школьником и то уже на фрилансе за деньги работал. Пусть копейки, пусть нестабильно, но хоть на мороженое и джинсы новые?

Из личного опыта:
те, кто работает бесплатно, делятся на 2 категории:
1) те, кто быстро бросит работать бесплатно, поймет, что это можно делать за деньги, и бросит вас
2) те, кто просто бросит вас

Короче, это как соседский вайфай: слетает, тормозит, периодически меняется пароль, зато 5 копеек сэкономили.

> Существует некое множество библиотек, например Awesomium, Juce
Вы что, нарочно выбираете самые бесполезные библиотеки?

Juce - это вообще УГ, какое и даром не надо.

Awesomium - еще так-сяк, но он же вроде и не запрещен для коммерческого ПО, а лишь для такого, где прибыль огромная.
Или коммерческая версия содержит какие-то дополнительные фичи (чего я не знаю)?
И такой вопрос: а зачем вам вообще браузерный движок? Вот я понял, что они практически не нужны, и Awesomium уж год как лежит пылится.

С авторизацией уже разобрались? Значит, смотрите в доках:
https://apiok.ru/
Если есть такой метод - юзайте.
Если нет - значит, придется обходиться без API и осваивать реверс-инжиниринг сниффером. Сперва сложно, зато потом ни разу не пожалеете. Я вообще без API почти все писать могу. Использую API только тогда, когда бюджет и сроки ограничены заказчиком, или другие причины.

Как связаны какие-то семинары и мотивация?
Мотивация - когда человеку НУЖНО что-то сделать, он САМ ставит перед собой ЦЕЛЬ и готов ее добиваться. А когда из-под палки - это полная противоположность мотивации.
Мотивация - обеспечивается прежде всего наличием высокооплачиваемой работы с новыми для них требованиями, по новым для них направлениям. Слышали поговорку "Летела ракета, упала в болото"?
А выбор СРЕДСТВ для достижения ЦЕЛЕЙ, лучше предоставить им САМИМ, это уже ИХ дело.

99.99% это AJAX, т.е. JavaScript делает HTTP-запросы.
Их можно перехватить сниффером, например, Fiddler. И сделать такие же запросы на своем ЯП.

P.S.
В 00.01% случаев это не HTTP/HTTPS, а другой протокол. Например, на сокетах возможно. Тогда HTTP-сниффер не годен.
Но это КРАЙНЕ редко бывает.

> Или может кто-то с опытом может написать?
Ну, за деньги может и напишут, на фрилансе.

А так, история - не больно интересная штука для большинства. А у спецов не хватает времени на все, поэтому пишут статьи, полезные на практике для большинства, а не те, какие паре студентов понравятся, а зато десяток троллей их обминусует и обжалует модерам, ибо не понравится твое мнение (например, некоторые старпёры бредят low-level'ом и обсирают вообще любые фреймворки по определению) или просто лично ты им рылом не выйдешь.

Но кое-что все-таки есть. Вот, например, моя статья, которая, помимо прочего, демонстрирует преимущество jQuery (да и вообще фреймворков) над чистым JS, в плане работы с DOM и HTTP (AJAX):
codeproject.com/Tips/1065669/How-To-Build-Web-Site...
Читать раздел Simplifying Our JS Via jQuery.

> Значит возможен ли UI с помощью html, css и js?
Теоретически - возможен.
Практически - для десктопа нет ничего более высокоуровневого, чем браузерные движки (в которых очень многого не хватает, поэтому многое придется сделать самому), вот обзор нескольких движков:
www.codeproject.com/Tips/825526/Csharp-WebBrowser-...
Еще один серьезный минус - тяжеловесность (несколько десятков мегабайт будет весить движок).
Правда, еще можете HTMLayout/Scite глянуть, я их особо не видел, из преимуществ - легкий вес, нужно будет и мне их глянуть, но видимо вменяемых оберток под .NET для них нет, а это плохо.

На мобильниках есть PhoneGap и React Native (благо в Android 4.x из коробки уже входит нормальный браузерный движок, а не такой, как IE - WebBrowser на винде), но они сыроваты, толком не документированы, малоизвестны.
Скорее это не для "великолепного" интерфейса, а для интерфейса быстросоздаваемого, когда есть наработки на HTML+CSS+JS и надо на них построить GUI в мобильном приложении. И кроме этих HTML+CSS+JS, в приложении особо ничего больше и не планируется.
Скажем, есть некий сайт, и нужно напилить для него мобильный клиент (типа как для VK, Facebook и т.д.) Так как сайт, слава Богу, имеет стройное RESTful API, то проще не писать нативный GUI, а взять ту же веб-морду на HTML+CSS+JS, прилепить ее к PhoneGap и с помощью какой-то матери сбилдить все это.

В Atom и VS Code, возможно, дело было отчасти в том, что именно те алгоритмы, в которых было автодополнение, подсветка синтаксиса для HTML, CSS, JS (и прочие основные возможности любой IDE), - именно те алгоритмы были только на JS (или готовые контролы для этого были на HTML+CSS+JS). А так как - еще раз - это основа любой IDE, то ничего удивительного.
Ну и да, VS Code и Atom - в основном рассчитаны на Web-разработчиков, среди которых есть и линуксоиды и маководы, и немало, поэтому в данном случае имеет хоть какой-то смысл кроссплатформенность - которая в иных случаях не дает ничего, кроме затруднения разработки и падения ее качества.

> Ходят слухи что WPF, помирает
Запомните раз и навсегда - никакой инструмент просто так не помирает.
Паровозы не исчезнут, пока не появятся тепловозы и электровозы.
Где альтернатива для WPF?
MS напилил новую платформу Windows Universal Apps (ранее - Metro), и усиленно проталкивает ее в массы, называя эти приложения "Windows Apps", ясно намекая, что якобы это и есть полноценные приложения для винды.
Но дерьмо не станет конфеткой от того, что его завернут в фантик. WUP - по-прежнему сырое УГ, да и в будущем конфеткой не станет - кадры в MS давно уже не те, чтобы писать хорошие, гибкие, удобные фреймворки без избыточности во всех ее 50 оттенках.
WPF и WinPhone уже были сыроваты - а еще более новый WUP еще хуже.
Ну и да, замечу, что WUP далеко не принципиально новый, и во многом основан на том же WPF (поэтому не так и сложно перейти с одного на другое). WUP - это такой же "не WPF", как и Spartan - "не IE", и примерно как Bolgenos - не "Ubuntu".

> Может ли это быть защитой от автоматического чтения страниц? И как такое можно обойти?
Может. Обойти можно, если с помощью сниффера (например, Fiddler) посмотреть запросы от браузера и 100% имитировать их на C# (учесть все заголовки, куки и т.д.)
Также в самом Fiddler можно и поэкспериментировать с заголовками и куками (вкладка Composer)

> ChromeDevTools
Можно самому напилить подобное, интегрировав браузерный движок (на основе CEF или WebKite) в свое приложение. В нем будут и ChromeDevTools.
Получится приложение, в котором нет ничего лишнего, только 1 страница браузера (а можно и несколько) и эти самые ChromeDevTools.
Причем JS там будет полноценный, с поддержкой DOM, т.к. есть реальная страница.

Для C# есть библиотеки CefSharp и OpenWebKitSharp, которые оборачивают движки CEF и WebKit соответственно.

> Можно ли через web.skype.com отправлять сообщения? Есть какие-нибудь идеи?
Еще как можно, и еще как есть.
web.skype.com - обычный сайт. Сайт состоит из фронт-енда и бек-енда. Фронт-енд шлет бек-енду запросы по протоколу HTTP/HTTPS.
Берем HTTP-сниффер (например, Fiddler), перехватываем эти запросы - и имитируем их отправку на любом ЯП, так, чтобы полностью совпадало. И все - мы имеем свой клиент для тамошнего бек-енда, т.е. свой бот.
Обычно так боты и пишут для тех сайтов, у которых нет вменяемого API (а это почти 100% всех сайтов инета).

Все то же, что делается в виде "жестких" электронных схем, но программируемо и разбираемо-пересобираемо.
Можно даже ЧПУ и АСУ ТП строить, хотя в этой области наверно сименсы все же лучше.