Иван Сушков

Факторов может быть настолько много, что даже страшно представить. Может быть задержка ответа (если сайт, к примеру, американский), перебои в интернет соединении, загруженность сайта (это из явных технических задержек). Программных задержек ещё больше: валидация модели, поиск по базе, да и банальное кэширование данных для дальнейшей быстрой работы с сайтом: вы же не знаете какие именно процессы происходят во время выполнения кода, может там куча разных статических данных запрашиваются, забиваются в кэш/сессию. может там ещё какие данные подтягиваются со сторонних сервисов и т.д. Я к чему веду: бекэнд (да и фронт тоже, просто его легче отследить) порой настолько загадочная вещь, что лучше даже не задумываться - если грузится значит так нужно, значит не просто так. Ну я просто сомневаюсь, что люди, которые разрабатывали эти сайты намеренно поставили небольшую задержку скажем в 2-3 секунды (да и не слишком большая это задержка), чтобы вы чувствовали, что там выполняются какие-то массивные процессы. =)

Скрипач не нужен, родной (с)
Аргументы против jq:
- современные браузеры достаточно хорошо поддерживают единый синтаксис современного екмаскрипт(native js)(на самом деле нет).
- сторонняя библиотека, работает медленнее чем натив и в основном состоит из с-сахара (тоже не совсем правда)
- тащить еще один ресурс весом от 64 кб до 200 кб, еще и со сторонних ресурсов замедляет загрузку( правда, но бред)
Аргументы за:
- Современные браузеры как и всегда один другого "ровнее", всегда есть косяки и "нюансы", на которые еще и попадаешь обычно в самый неподходящий момент, в жк обычно все работает одинаково везде, ну или лучше чем в нативе.
- В жк реализована куча плюшек в 1 функцию которые в нативе занимают "многабукав", не каждый начинающий напишет их правильно, да и профи не все напишут оптимально, уверен что в большинстве случаев написанный нативом функционал будет хуже аналога из жк.
- размер мин пакета жк 64 кб, и все они лежат на быстрых цдн серверах. Думаю это последнее что может повлиять на скорость загрузки страницы.
- есть ОГРОМНОЕ количество скриптов написанных с учетом жк, не использовать их глупо, писать свой велосипед - вообще только в целях обучения(не берем крайние случаи когда плагин писал упоротый пингвин).
- Синтаксис и краткость записи - вообще вне конкуренции.
- Старые браузеры никто не отменял, часто заказчик требует чтобы работало в ие8, натив не канает или доставляет море анального удовольствия.
Вывод: Если ты крут в жс, еще и работаешь в ангуларе/ещечетамдляфронта и тебе нужно сделать 2 действия в очень современных браузерах - jquery не нужен, и ты это сам знаешь. Если слова ангулар, вуе и проч для тебя не больше чем шум листвы за окном, а навесить плагинов и эффектов нужно - jquery наше все.

UPD: для всех кто там отписался а ля "в связи (...), исчезновением проблемы совместимости со старыми IE (что и было основным назначением jQuery)." - свежачок

jQuery был хорош, но ничто не стоит на месте. Раньше фронтенд никто особо не воспринимал всерьез. Все считали, что фронтенд - это несколько скриптов, которые принципиально погоды не делают. Все изменилось с ростом популярность SPA, в т.ч. и благодаря бурному развитию JS.

В любом приложении очень важно прозрачно и понятно управлять состоянием, очень желательно делать это централизованно. Былой подход с участием jQuery делает это невозможным. Кто угодно может менять что угодно на странице, когда угодно, и приложение об этом ничего не знает без очень хитровыдуманных методов. Например в первом ангуляре для этого постоянно бегал по элементам и проверял что там изменилось, это называется "грязные проверки" (dirty checking). Мягко говоря это ни разу не оптимальный способ контроля состояния, но, на тот момент, вариантов особо не было.

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

В каких-то простых страничках с парой-тройкой функций jQuery даже сегодня может быть актуален, особенно если приложить усилия и делать грамотно.

Но что-то чуть более сложное уже требует совершенно иного подхода.

Для соединения кабелей.

Если просто для "показать", то хоть блог - классическое тестовое задание.

Потому что функция getJSON ничего и не возвращает, вы получаете значение через callback, чтобы ваш код работал, нужно сделать так:

var JSONexternal = getJSON('/php/vesettingsforclient.php', function(response) {

   // response доступен только тут, эта функция вызывется асинхронно 
    console.log( JSON.parse(response));
});

function getJSON(url, callback) {
    var xhr = new getXmlHttpInstance();
    xhr.open("GET", url, true);
    xhr.send();
    xhr.onreadystatechange = function() {
        if (this.readyState == 4 && this.status == 200) {
            if (typeof callback === 'function') {
                callback.call(this, this.responseText); // как отсюда вытащить ответ во внешний скрипт?
            }
        }
    };
}

во первых в Вашем случае это не один запрос, а все равно два которые Вы просто сразу хотите отправить в базу
во вторых запросы пишутся через точку с запятой, а у Вас после INSERT запроса точки с запятой нет
в третьих раз уж Вы хотите сразу отправлять в базу несколько запросов используйте multi-query т.к. mysql_query не поддерживает множественных запросов
в четвертых функционал который Вы пытаетесь реализовать нуждается в транзакции, поэтому я бы рекомендовал их реализовать
в пятых помоему Вам давно пора перейти на PDO ...

airmail работает стабильно. Проблем не было.
В день по 3-5к писем приходит.
Единственная альтернатива для меня, это базовый клиент.

Arch Linux https://wiki.archlinux.org/index.php/Installation_guide