VZVZ

Почему бы вообще не отказаться от HTTP в пользу голого TCP (или WebSockets - тогда для сервака идеален NodeJS)?
Клиент подключается к серваку - и соединение просто остается открытым. Сервак через xxx времени отправляет пакет - клиент его тут же получает, при этом соединение по-прежнему открыто. Также и наоборот (клиент - серваку).

Сомневаюсь, что можно придумать для сетевого обмена что-то лучшее по производительности, чем голый TCP.
Если кто-то знает вариант лучше - внимательно выслушаю и буду благодарен.

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

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

Про "защиту" вообще бредовые какие-то рассуждения. Вы о чем?

Зависит от протокола. Не все на свете работает по HTTP/HTTPS, хотя он самый простой для начинающего.

Для HTTP/HTTPS юзайте сниффер Fiddler, насколько знаю - самый удобный для этого.

А вот если не получается, то варианта 2: либо запросы обходят Fiddlerовский прокси (тогда надо принудительно пустить трафик через прокси, например вроде Proxifier умеет), либо это вообще не HTTP/HTTPS.
Тогда WireShark, но это уже тяжело, требует опыта в TCP (голые сокеты - ниже уровнем, чем HTTP/HTTPS; бывают разные протоколы на базе TCP, но не HTTP/HTTPS, к примеру это XMPP)...

Начинать всегда надо с HTTP/HTTPS.

> если я поймаю запрос, как можно его повторить более 20 раз в течении минуты?
Для HTTP/HTTPS запросов есть какие-то средства почти во всех языках, и стандартные, и сторонние.
Но они имеют несколько ограниченный функционал. Если хочется полного - то делаем велосипед: сами составляем пакет и отправляем опять же по TCP, затем также принимаем пакет с ответом - получается HTTP-запрос. Для TCP тоже много где средства есть.
Насчет "20 раз в минуту" - хз, не приходилось.

> потому что есть WPF. Изучайте его. Он быстрее, лучше, мощнее
Горе-преподаватель сморозил лажу.
Быстрее - это смотря что писать.
На уровне простого дефолтного GUI без весьма активной перерисовки местами - явно быстрее Winforms, а WPF будет медленно грузиться и жрать ОЗУ.
Если куча свистоперделок, анимаций, или 3D - то WPF.

Мощнее (гибче в плане свистоперделок и прочих нестандартных возможностей) - да.
Но Winforms попроще, поудобнее будет. Попроще - особенно для новичка. Поудобнее - особенно на слабых компах, где WPFовский WYSIWYG тоже будет тормозить.

> WinForms не развивается дальше, в отличии от WPF
WPF развивается дальше? Это параллельно UWP что ли?
А сторонние решения для Winforms - Telerik, DevExpress, тоже не развиваются?

> Насколько похожи языки?
Совсем разные инструменты, для разных задач.
JS на фронт-енде.
Java вообще под Android в основном, а на бек-енде применяется только в крупном Enterprise.

Вывод: хотите веб и в формате Indie - значит JS вам нужен.
Хотите веб в формате Enterprise (это особое направление в крупных, но не софтверных фирмах - внутреннее ПО) - значит JS + Java под Web.
Хотите Android - значит Java под Android.

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

Не совсем понятно, что именно хотите заменить и почему тупо вставить целиком через innerHTML не устраивает.
А вообще для клиентской "шаблонизации" юзают Angular, React и подобное.
jQuery также несколько облегчает задачу вставки элементов, но не более того, насколько я знаю, это не "шаблонизатор" как тот же Angular.

> вообщем,чтобы можно было делать GUI на PHP
Об этом можно много писать. Это как раз-таки достаточно просто.
1. Пишем на PHP свой фреймворк со средствами для GUI и т.д., просто чтобы можно было написать скрипт, который бы скажем открывал окошко, копировал файл и т.д., если его запустить с помощью php.exe
В принципе, для довольно-таки многого в PHP уже есть средства, остается только написать для них удобные обертки, т.е. собственно фреймворк.
2. Пишем упаковщик этого дела в exe: скрипт упаковывается вместе с php.exe, или еще как-то так.
3. Пишем IDE с WYSIWYG и прочими фичами, для того, чтобы удобнее было писать код под этот фреймворк.
Собственно, всё.

> со своими возможностями,плюсами сделать.
Ага, я уже представляю, какие это плюсы получатся, с вашим "вообщем", с вашими запятыми без пробелов, а то и вовсе грубо пропущенными запятыми...
"Ты родной язык не знаешь, как тебе освоить язык программирования?" (c) Я
Вы как хотите, а нам - не надо таких плюсов больше:
demotivation.me.prxs.ru/images/20130408/kjzco6f2cy...
Devel Studio - это полное УГ, поэтому надо делать не "что-то типа Devel Studio", а скорее что-то типа Visual Studio. Но, во-первых, VS тоже нужно копировать не целиком и полностью, а только удачные из нее решения, а некоторые другие решения взять из других продуктов, которые сперва надо освоить на особом уровне. Во-вторых, чтобы взять удачные решения даже из той же VS, все равно нужно сравнить ее хоть с чем-то, иначе вы многого просто не увидите и не поймете.
Ибо большинство уникальных решений остается не сплагиаченным не потому что патент, а потому что нубы просто не осознают всю их уникальность и даже не пытаются подражать. Вот тупые люди даже не понимают, что если в винде кнопки "OK - Cancel" везде располагаются именно в таком порядке, то и у себя надо делать "OK - Cancel", а не "Cancel - OK" или еще как-то через задницу.
Говорю как реверс-инженер - специалист по промышленному шпионажу.

Ну да ладно, это все цветочки.
Вы главное подумайте: а как вы сделаете подобие того, что в VS называется IntelliSense?
Ну там всплывающие подсказки, или скажем чтобы скобочки подсвечивались: подводишь курсор к закрывающей скобке - умный алгоритм ищет открывающую и подсвечивает, или наоборот.
Вот интересно, а как вы собираетесь это делать?
Надеетесь на готовые решения? Или вы считаете, что нужно писать свой алгоритм разбора кода? А вы пробовали написать такой алгоритм хотя бы для какого-нибудь JSON или еще чего-то примитивного?
Или вы не согласитесь со мной, что это основа любой IDE, и без WYSIWYG еще возможно что-то путное сделать (пример: JetBrains), а вот без умного разбора кода - вообще ничего, и даже VS без этого уже была бы не VS?

> Я знаю C#
Пардон, какой C#, когда PHP?
Вы видели хоть одну удачную IDE, которая была бы написана не на том языке, не на том фреймворке, для которого она предназначена?
Вот и я что-то не припомню. Кстати, даже автор Devel Studio вроде бы понял это.

И еще, а почему именно PHP?
Что в нем хорошего?
Я бы еще подумал, что выбрать - PHP, или NodeJS (у JS-то синтаксис поудобнее будет), а может Ruby, а может для Python наконец написать что-то нормальное, а может еще что.
Много экспериментировал бы. А не то что - от балды: в моей новой IDE будет PHP и точка.

КОРОЧЕ, вывод такой:
- если вам нужны плюшки в виде библиотек - возьмите нормальную платформу (такую, как .NET) и пишите для нее свои плюшки в виде библиотек;
- если вам нужны плюшки именно в виде фич IDE - возьмите нормальную IDE (такую, как VS) и пишите для нее свои плагины (создавая плагины, вы заодно изучите чужие IDE изнутри);
Этим может и будет кто-то пользоваться. Хотя,воооооообщем-то,тоже вряд ли.
А вашей принципиально новой IDE, которую вы напишете сами, без команды спецов и без учета всех вышеупомянутых замечаний, 99,(9)% никто не будет пользоваться всерьез.
Нужно же все-таки как-то понимать, что чем крупнее, масштабнее и ответственнее проект, тем больше надо скиллов. И осознавать свои скиллы в соответствии с реальными достижениями - т.е. не завышать и не занижать ЧСВ.

P.S. Ну или я м***к. Извините, если обидел. Просто делюсь своим опытом.

Долго рассказывать -токены, куки и т.д. Да и зачем? Берем сниффер Fiddler и смотрим как на других сайтах сделано.
Золотое правило: не делай нового, не освоив старое. Не делай своего, не освоив чужое.

Отрытое? Оговорочка по Фрейду)
Вы что, не видели приложений с открытым исходным кодом? Попробуйте исходники Chromium скачать и собрать, и поймете, что если приложение простое (а не как Chromium), то легче и проще написать самому, чем заниматься раскопкой исходников, которая обычно по сложности являет собой почти что реверс-инжиниринг.

А избегать изучения HTTP - это, помимо прочего, еще и очень глупо.
На фрилансе за создание HTTP-клиента (бота) для чужого сайта просят пятизначные суммы.
Да и вообще сейчас не Web 1.0 давно уже, и самые разные HTTP-запросы в том или ином виде нужны практически в любом крупном проекте, особенно что касается веба.
И учтите, что на свете есть вещи в сто раз сложнее чем HTTP, так что если вы даже HTTP осилить не можете, то каково будет во многих других случаях?

Сперва освойте HTTP в браузере (AJAX), вот гайд для начала:
codeproject.com/Tips/1065669/How-To-Build-Web-Site...
Уже после этого реализовать то же самое со стороны десктопного/мобильного приложения, неважно под какую платформу, будет гораздо легче. Общая логика везде одна, т.к. протокол один и тот же - HTTP.

Когда как.

В самом простом случае - общий бек-енд для всех, с RESTful API (т.е. БД скажем на MySQL, и обработчики HTTP-запросов на PHP, яркий пример - API VK), через него и веб-морда работает, и официальные моб. приложения, и сторонние приложения могут работать.

Иногда делают иначе, вот у VK для веб-морды бек-енд один (недокументированный, не RESTful), для сторонних приложений - другой (RESTful API с OAuth), а насчет официальных моб. приложений - не знаю, наверно тоже RESTful API. У гугла, твиттера - тоже примерно так же.

Иногда используют протоколы, отличные от HTTP.
Обычно это мессенджеры, чаты (протоколы - TCP, XMPP, иногда свои какие-то протоколы).
Но то, что моб. приложения работают по такому протоколу, еще не означает отсутствие RESTful API, и веб-морды на базе этого API.
Пример - Skype, протокол свой у него, но есть web.skype.com - веб-морда с закрытым, но HTTPшным бек-ендом.

Рекомендую взять сниффер Fiddler и самому посмотреть, что где и как.

Что я делаю не так?

Нахватались вершков и думаете, что теперь любой бот написать можете.
Хрен.
HTTP осваивайте и Fiddler, это универсальный вариант (кроме редких случаев, когда на сайте используются сокеты TCP, или какой-нибудь RTMP от Adobe - тогда еще глубже копать надо, хотя и это еще далеко не самое глубокое), хотя и очень геморный.
Практика в разработке сайтов (как фронт-енда, так и бек-енда) тоже нужна большая и на разных языках. Глупо надеяться стать ботоводом, реверс-инженером, хакером, при этом не умея в совершенстве создавать то, что хотите хакать.
Только тогда можно браться за высокоуровневые штуки вроде Selenium, PhantomJS, и то использовать их далеко не всегда, иногда HTTP-запросы лучше.

> каждую вкладку через отдельный поток пускают
Какие еще потоки в браузерном JS? Не слышал о таком.
И что они там "пускают"?
И прямой связи с вкладками тут нет, мы что, в Web 1.0 живем, когда 1 вкладка = 1 запрос, а ни аяксов, ни даже фреймов и тэга img (что вообще невозможно представить - фреймы и img уже и в Web 1.0 были) - еще не изобрели?
А вот в API браузера средства для перехвата всех запросов кое-какие есть, вполне может быть возможность определить и характер запроса (frame, img, XmlHttpRequest(AJAX), а может это вовсе запрос от другого расширения), и какая вкладка так или иначе его породила.
Особенно в Firefox должно быть богато.

> как работают такие расширения
Хреново они работают.
Может они и захватывать могут все что надо, но отображается захваченное очень неудобно, черт ногу сломит, ничего не разберешь.
А если вам запросы вообще не от сайта надо отсниффить, а от приложения Android, скажем?
С появлением Fiddler во всем этом пропала надобность.

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

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