> Во вторых тогда уж лучше нативный js использовать
*facepalm*
Нет бы сделать вывод, что раз все так плохо, то стоит написать свою библиотеку, имеющую преимущества jQuery (а заодно и других библиотек) и не имеющую их недостатков (в частности, имеющую более гибкое деление на модули в целях оптимизации)
Такие слова, как архитектура, абстракция, вам незнакомы?
Или вы тупо кодер?
Dark Hole: > нагрузка раза в 2 больше
Нагрузка на что, простите? На ОЗУ?
А почему не на шурупы, которые держат материнскую плату в корпусе моего планшета?
Мда, веб-девелоперы все-таки ипанутый народ))
> Представь себе, если будут бомбардировать Ajaxсом все время
"Все время" - это как, например, в случае с чатом, когда надо каждую секунду проверять новые сообщения?
Для таких случаев существует TCP.
В упрощенческом высокоуровневом HTTP если клиент не отсылает TCP-пакет с запросом, то и пакета с ответом не получает.
А на уровне TCP все проще. Открываем вкладочку, подключение с серваком установлено. Появилось новое сообщение, сервак шлет пакет, клиент его получает, что-то делает. Также и наоборот, клиент может пакеты серваку слать.
Технически TCP реализуется на NodeJS (сервер) и socket.io (клиент)
По этому же принципу мессенджеры работают
Для HTTP-запросов нужно HTTP-сниффер юзать. Лучший вариант - Fiddler. Для HTTP/HTTPS он во всех отношениях удобнее, чем Wireshark.
Wireshark приходится юзать для TCP и пр.
Вы серьезно думаете, что аналогов этому нет?
Вы серьезно думаете, что свиньям нужен ваш бисер?
Я бы скорее робота для расклейки объявлений (рекламы) построил. В крайнем случае, свою рекламу и расклеивать. Это на случай ФГМ-апокалипсиса, если все совсем ипанутся и сотрудничать вообще не с кем будет нельзя.
Ruby, Python, JS, PHP? Ну так это другой случай. Там IDE сама на одной платформе, а целевая платформа - совсем другая.
До абсурда-то доводить не надо.
Или вы про Clion? И где же она топовая? Где-то там в далекой банановой республике под названием Линуксляндия? Или на острове Мажоров имени С. Джобса?
Да и не назвал бы я эти IDE хорошими.
Держатся они на тех самых алгоритмах разбора кода, которые в них реализованы реально на высоте.
Все остальное убого, капризно и при этом еще и платно.
Владимир Мартьянов: > у него там в потрохах виртуальная машина, исполняющая байт-код
> Производительность, соответственно, будет никакая.
Ну, виртуальные машины очень разные бывают.
И интерпретируемый ли язык или JIT-компилируемый, здесь не так уж и важно, как кажется.
JIT-компилируемая Java на уровне хелловорлда раз этак в 10 медленнее (вернее сказать: "тяжелее"), чем интерпретируемый Python.
Но JIT-компилируемый C# и вправду полегче питона будет.
Так что это не показатель.
А вот то, что Java очень тяжела и вообще из рук вон плохо подходит под винду, и тем не менее куча дилетантов всерьез сравнивает ее с C#, в упор не видя этой особенности, и пишет на ней гуй под винду, - это факт.
> Что вы знаете о вызове произвольной функции произвольной DLL из PHP?
Этого не приходилось делать. На досуге как-нибудь попробую.
Владимир Мартьянов: > рекомендую получить лет этак пять опыта в программировании.
Здесь я вас поддерживаю.
> Идея плоха по части "делать GUI на PHP" как минимум
А вот это уже интересно.
Чем именно плоха? Лично я не вижу никаких проблем, кроме неудобств синтаксиса. Все необходимые библиотеки пишутся либо "велосипедно", либо оборачивая стандартные функции (зависит от наличия и качества последних). И надо сказать, что писать GUI-фреймворк, даже с отличной архитектурой, это раз в 100 проще, чем писать алгоритмы разбора кода для самой IDE, пусть даже паршивенькие алгоритмы.
Хотя, в самом деле, стоит сперва хорошо подумать, что это будет за IDE, для кого (для чего) она будет designed (есть такое хорошее английское слово), сопоставить это со своими скиллами в соответствующих областях, и в зависимости от этого выбрать ЯП.
Идей не будет, а реализовать - сможете? 0_o Ахаха))
Ну, как мы видим на вашем примере, годы практики еще ничего не значат.
Не понимаю, чем вам не нравится идея ТСа. У него не с идеей проблемы, а с реализацией, он не понимает, насколько это сложно, не понимает элементарных правил методологии, вроде "начинай с простого и переходи к сложному".
Практику такого не имею. Но первое, что приходит в голову, это для каждого фото при его загрузке делать ухудшенную или уменьшенную версию (Thumbnail). И сохранять.
Она будет весить гораздо меньше, и сперва будет загружаться она, а уже по требованию полная версия.
Смотря на каком языке.
У SpeechKit есть HTTP API, с ним почти на чем угодно работать можно.
Разбивка текста - тоже самое.
А вот для работы с wav нужны спец библиотеки, там уже от языка зависит, какие библиотеки доступны. Рекомендую C#. Для него доступно так или иначе максимум библиотек.
svd71: > А приколы начинаются на этапе "смены морды".
Ну что ты будешь делать...
Я вам говорю, что мой подход с многослойной архитектурой логики никак не исключает использование MV*.
А вы мне тут же пишете коммент, где противопоставляете MV* и многослойную логику, как будто та же Model в MV* не может быть многослойной.
> виртуальная машинга явы уже является некоторым врэппером над функциями ОС
Угу, а WinAPI тогда враппер над функциями ядра NT.
Но что-то не видно приложений, написанных минуя WinAPI.
Также и приложений, написанных под Android минуя джаву, тоже что-то не видно.
> вы в приложениях для Android используете один обработчик OnClickListener на все элементы активити или каждому элементу прикручиваете свой отдельный анонимный обработчик
Использую один обработчик, зачем мне лишняя вложенность, зачем мне загромождать onCreate.
А в крупном серьезном проекте мне было бы не лень сделать и такое:
void button1_Click(View v) {
//...
}
void button2_Click(View v) {
//...
}
void onClick(View v) {
switch (v.getId()) {
case R.id.button1:
button1_Click(v);
break;
case R.id.button2:
button2_Click(v);
break;
}
}
То есть обработчики - отдельные, но не анонимные и потому не засоряют onCreate.
Ага, снова привет винде. Кстати, Borland/MS тоже прошли через этот switch, это как раз уровень WinAPI. Но MS еще долго не останавливался, а экспериментировал, и в итоге обе корпорации единовременно пришли к этим самым button_Click. Думаете, дураки?
Правда, в джаве-то с этим есть проблема: если все эти обработчики писать вручную, то риск прилепить не тот обработчик к какой-то ветке switch'а, забыв изменить название. Но если проект реально крупный, то почему бы не написать плагинов к IDE, которые бы это могли автоматизировать, и не только это?
Cosmos: для вайбера? Ну я бы на данный момент начальную цену назвал не меньше 50-100 т.р., а там видно будет, даже в тривиальных заказах плюс-минус 5 тыров вполне реально, здесь плюс-минус 50 тыров наверно будет.
Cosmos: WhatsApp вроде по протоколу, основанному на XMPP, работает, XMPP - протокол открытый и точно на базе TCP = все в разы проще.
А со Skype все еще проще, есть web.skype.com, у него обычно HTTPшное REST API.
Я не понимаю, что вы мне доказать хотите? Что все просто, взял и написал? Ну так возьмите, напишите, я не против, может даже деньги буду готов заплатить, если что стоящее напишете и все исходники мне дадите.
Виталий Инчин ☢: ну, если настолько извратиться, что с в jQuery использовать функцию setRequestHeader, когда там часто используемые заголовки HTTP-запроса гораздо легче задаются, то действительно буковок много будет :)
Относительно чего?
Еще раз, не фантазируйте. Я исследовал этот вопрос и описал его в статье, сразу для всех, так сказать:
codeproject.com/Tips/1065669/How-To-Build-Web-Site...
> Во вторых тогда уж лучше нативный js использовать
*facepalm*
Нет бы сделать вывод, что раз все так плохо, то стоит написать свою библиотеку, имеющую преимущества jQuery (а заодно и других библиотек) и не имеющую их недостатков (в частности, имеющую более гибкое деление на модули в целях оптимизации)
Такие слова, как архитектура, абстракция, вам незнакомы?
Или вы тупо кодер?