Rou1997

Одной страницы вряд ли... Если смотреть на уровне TCP, то как вы будете с одним сокетом из разных потоков работать...
А вот, скажем, если там пагинация - то можно.
Но и сайт обрушить таким способом тоже можно.
Самолично делал. На одном довольно популярном сайте был огромный ТОП - страниц в 40 тыс., и я хотел его весь полностью получить, да не за полдня, а минут за 30. Не смог. Сайт тупо падает и вообще перестает где-либо открываться :D Это уже второй такой сайт.

https://www.google.ru/search?newwindow=1&q=css+sho...
Но лучше JS.

elFinder, но хорошим тоже не назвать, все это творения линуксоидов, которые, как и поклонники OS X, мало понимают в удобстве GUI.

Правда ли, что на android без крупной финансовой поддержки не выйти из этих трущоб?

Нет, но результат не берется ниоткуда, либо финансы, либо собственное развитие и труд.

, игра еще может взлететь, но с приложениями куда сложнее, рынок перенасыщен.

Перенасыщен всякой гадостью, игры ничем не лучше, встречал такие, в которые при желании не смог играть.

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

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

Может стоит перейти снова на web ?
Я и то, и то. Можно в одном и том же проекте.

Никакой, там и дизайна никакого нет, сделали "из того, что было", верхняя панель навигации в стиле Flat, почти Google Material, а кнопки - переходные между Rich и Flat, примерно года 2010.

То, что некоторые сервера на Linux и нельзя ничего с этим поделать, а нередко удобно что-то делать прямо на сервере, приходится знать Linux, а также цена ниже так как в нее не входит лицензия, в остальном недостатки, тот же удаленный рабочий стол на Windows по RDP гораздо лучше, чем по VNC.

Возможно, двумя основными способами - на уровне HTTP или полная имитация браузера - Selenium, Phantom.js, headless-браузеры.

А если кнопка вызывает какую либо функцию и не перезагружает страницу. Или это вообще Single page application. Например сайт магазина одежды

В браузере все взаимодействие с сервером в конечном итоге основано на XMLHttpRequest, гораздо реже WebSocket или такие протоколы, как RTMP (во Flash), на более низком уровне любое сетевое взаимодействие основано на TCP или гораздо реже UDP и другие протоколы для особых случаев, в общем среда является недоверенной, все что отправляется на сервер или поступает с него можно перехватить при анализе и после этого симитировать своим приложением, есть несколько уровней и способов, которыми это можно сделать.

Нужно поговорить с ними, чтобы не делали без вашего ведома, или перейти к другим и оставить плохой отзыв, сегодня они внедряют HTTPS, завтра заставят вас делать 5-факторную авторизацию клиентов по ксерокопии паспорта, SMS, отпечатку пальца, паролю и капче.
А уж если возникут проблемы, то это точно их проблемы.

тут выбираем между асинхронной nodejs (говорят, что нода в API хорошо себя чувствует) и обычным php.

А что из этого вам лучше знакомо?
Ваша основная цель - реализовать проект, а если будете использовать незнакомое то будет еще и цель изучить незнакомое. Тем самым, вы будете тратить гораздо больше энергии и времени.

Тоже самое на вопросы вроде "готовый фреймворк vs самописный фреймворк vs китайский код без фреймворка" - самописный фреймворк это самый заманчивый вариант на будущее, но он же и самый энергоемкий.

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

Так же в перспективе планируется ввести систему коммуникации между пользователями, пока сходимся на real-time чате.

Насчет real-time, есть один момент: с WebSocket лучше работать на Node.js.
А если у вас клиентом служит браузер, то вам желателен WebSocket, потому что иного доступа к сокетам в современных браузерах нет (Flash считаем устаревшим), а сами сокеты желательны для real-time.
Но это не самый важный момент.

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

В стандартном сниффере искать неудобно, нелогично, для реверс-инжиниринга HTTP он подходит плохо, лучше Fiddler, даже не знаю есть ли в нем встроенный поиск, я просто копирую содержимое ответов, запросов в Блокнот (в режиме Raw это делается в один клик) и там ищу.

Full-stack-специалист. CMS плохо структурированы, отделением представления от бизнес-логики их авторы себя не утруждали.

Если проект серьезный, то только "самописный".
Если на сайт нет "глобальных" планов и это будет лишь место для обсуждений неких тем в достаточно узком кругу, где само содержание гораздо важнее "обертки", то любой "движок" для форума, какой для вас проще тот и используйте.
Если студенческая курсовая работа, то вы сами вольны выбирать что и на чем делать, кто-то просто "бросает жребий", кто-то следует субъективному мнению своего наставника, а у кого-то есть собственные планы и он в зависимости от них выбирает чтобы время тратить максимально эффективно.

либо с неизвестными пока уязвимостями

Что значит "неизвестными"? Какой вообще смысл имеет это слово, если мы говорим о реверс-инженерах, а первыми об уязвимостях зачастую узнают они?

плюс плагины типа java или flash можно просто не использовать

Но на JavaScript с обилием API тоже нельзя полагаться, в его реализациях в разных браузерах могут быть уязвимости и "баги", вероятность стремится к 0 но не 0, я открывал crashchrome.com полгода назад, сейчас открыл в одной из новейших версий и он все еще работает.

Если это вирус а не троян, то кроссбраузерность ему не нужна.
Но я сейчас работаю именно над трояном, возможность заражения файлов не планируется так как на Android с этим само собой сложно, однако по словам заказчика данный троян устанавливается именно через remote code execution и этого будет достаточно для его популярности, то есть на Android эту уязвимость закрыли достаточно поздно.

Попробуйте с помощью Fiddler, а если отправляется с помощью AJAX то есть еще один способ связанный с рефлексией в JavaScript.

Если это ваш сайт или вы с ним связаны, то в чем проблема, обеспечьте все на сервере.
Если нет, то выше ясно написано, "неподдерживаемый", используйте для этой цели браузер постарше, поищите где поддерживается, наконец можно свой написать, если уметь писать настольные приложения.