Ну Вы же не будете спорить, что используете ресурсы Мэйл.Ру на свой страх и риск и никаких претензий к Мэйл.Ру за это не имеете. И что если какие-то продукты Мэйл.Ру не соответствуют Вашим ожиданиям, претензий тоже не будет? :)
Вся прелесть Вашего способа — в перекладывании своих проблем от кривого проектирования системы на nginx. Действительно, способ рабочий, но эт не значит, что он оптимальный.
Не будет 100 лишних запросов к вебсерверу в случае с предварительной проверкой одного бита в php. В вашем случае — эти запросы будут. А работа с TCP затратнее, чем одно сравнение регистров процессором.
Я к тому, что часть данных, необходимых для вывода комментариев (ник + id, больше ничего не надо), может хранится на одном сервере, а более полные данные о юзере (включая аватар) — на другом. И зачастую на этот другой у проекта-сателлита доступа нет.
Может у Вас какой-то неправильный PHP?
На каких нагрузках PHP начинает тормозить на битовых операциях?
Расскажите поподробнее, если владеете сокровенными знаниями.
Хорошая у Вас трава, забористая. Поделитесь?
Вас, кстати, не напрягает, что при ответе на этот вопрос без явного Вашего указания на этом сайте запустилось минимум четыре программы, которые
Вы не хотите, кстати, оплатить процессорное время этого, которое тратите на всякую фигню?
И кстати, ирафик почтовый, опять же, всяких там кармадрочеров, кто оплачивать будет? :)
Камаз не является специализацией технологии генерации крутящего момента
Именно. Так же как AJAX не является транспортным протоколом. Но в предыдущих сообщениях Вы неоднократно писали фразы, которые именно это и подразумевали своим некорректным сравнением мягкого с кислым. Учитесь правильно формулировать свои мысли.
Я не сравниваю TCP и TCP
Да сравниваете, сравниваете. Вы ж прямо написали, что TCP быстрее, чем ответы от веб-сервера. Но при этом не сказали, что подразумеваете, что TCP соединение с Вашим сервером уже установлено, а в случае использования Вами AJAX оно фактически устанавливается каждый раз заново. Иначе собственно непонятно за счет чего быстрота. И так, и так браузеру придется соединиться с TCP-сокетом сервера. Веб-сервер это или же ваш демон — какая разница? Накладные расходы на вызов XMLHttpRequest не дадут существенного увеличения времени установки TCP-соединения.
Поэтому AJAX не гарантирует порядка запросов и ответов
Гм. Не совсем так. Я не зря упоминал про синхронные запросы в JS. Другое дело, что текущие реализации XHR, насколько мне известно, не поддерживают полноценный pipelining, а поддержка браузером persistent connection с сервером зависят больше от принимающего сервера, нежели от умения XHR отправлять заголовок Keep-Alive. Ну то есть, определенный смысл в Ваших действиях есть, но вопрос невозможности отказаться от прямого соединения (Java, кстати, или Flash?) в пользу дееспособной конфигурации веб-сервера остается открытым.
Теперь снова Ваш ход — чем это характеризует систему с нелучшей стороны?
Пальцем в небо. Я писал не про FastCGI, посмотрите внимательно на цитату, которую я там выделил.
А я и не говорил ничего противоречащего. Я говорил про обмен данными по соединению, а не про его установку.
А ну надо же. Оказывается, у нас уже что-то там с чем-то соединено, и сервер просто использует это соединение. Ну-ка ткните-ка меня в цитатку из предыдущих сообщений, где Вы говорили, что соединение состоялось. Без этой цитаты из Ваших фраз следует как раз то, о чем я писал выше — в предыдущих комментариях Вы фактически говорите, что инициатором передачи файла клиенту является сервер. Что полностью противоречит принципам TCP. Учитесь правильно формулировать свои мысли.
Вы говорили, что, имея возможность используя AJAX, я могу использовать TCP.
Не говорил. Не путайте причину и следствие. Я говорил, что AJAX в принципе невозможен без TCP: «Работа аякса невозможна без использования ТСР-сокетов». Про то, что AJAX предоставляет все возможности TCP я не упоминал. Цитату в студию, если таки упоминал.
А конкретней?
Расслабьтесь. После Вашего последнего поста стало очевидно, что Вы просто не умеете правильно формулировать свои мысли, чтобы собеседнику не пришлось домысливать за Вас вещи, которые следуют из Ваших фраз, но как оказалось, которые Вы совсем не имели в виду. Перечитайте. И попробуйте представить наиболее очевидные вещи, которые следуют из Ваших фраз без полных формулировок, с многочисленными допущениями и умолчаниями с Вашей стороны. И поймете, что очень часто Ваши фразы — полная ахинея с точки зрения действительного положения вещей.
Эт не сугубо мое мнение, данную беседу читало уже много людей, разбирающихся в сетях, и у всех одно мнение — у Вас каша в голове. А похоже, все проблемы — от неправильного выражения мыслей или излишней торопливости при их переносе в текст. В общем, учитесь правильно формулировать свои мысли. Из-за того, что они у Вас скачут с пятого на десятое; из-за того, что Вы многое пропускаете, считая, что мысли собеседника пойдут ровно так же как и Ваши и обязательно поймут что Вы недосказали, получается, что Вы мешаете в кучу разные понятия и это сразу цепляет взгляд знающего человека.
Темы тормозов _из-за высокой нагрузки на сервер_ мы в нашем обсуждании не касались.
И всё-таки у меня стойкая мысль, что проблемы производительности Вашего продукта — не в AJAX'е. Тут нужно глубже копать, у меня нет достаточной информации. Но интуиция пока утверждает, что Ваших костылей можно было бы избежать. Но эт уже отдельный разговор.
В отношении меня вы это пока не обосновали
Считайте, что под недостаточной квалификацией я имел в виду, что Вы не умеете полно и точно излагать свои мысли. Вам повезло, что я терпелив и подвел Вас к точной формулировке того, что Вы имели в виду в предыдущих постах ;)
AJAX… обладает ограничениями и недостатками, которых лишён TCP
Вы опять мешаете в кучу разные вещи. Фактически, пишете «Камаз обладает ограничениями и недостатками, которых лишен двигатель внутреннего сгорания». Так понятнее, почему Вас забавно читать?
На AJAX накладываются ограничения HTTP-протокола, который по историческим причинам разрабатывали именно с существующими ограничениями. Хотя я слабо представляю веб-приложение на основе браузера, где это было бы критично. Просветите, пожалуйста. Мне, правда, очень интересно.
Где именно я это хочу сказать?
Вот здесь:
«AJAX запросы архитектурно асинхронные, это означает возможное несовпадение порядка запросов и ответов от сервера… в TCP такого нет»
Действительно, TCP гарантирует, что пакеты соберутся в нужном порядке. В отличие от UDP, который этого не гарантирует, как не гарантирует доставку вообще. Логично предположить, что если Вы пишете, про несовпадение порядка запросов и противопоставляете ajax работе с tcp-сокетом («мы используем… TCP-сокет… вместо AJAX-запросов»), то легко можете иметь ввиду, что AJAX — суть надстройка над UDP, а не над TCP.
TCP быстрее.
Блин, ну вот опять Вы жжоте. Не может быть TCP быстрее TCP. Может быть, что самописное-приложение-сервер, обслуживающее несколько десятков соединений напрямую, быстрее по каким-то причинам, чем стандартное-приложение-веб-сервер, обслуживающие пул из нескольких сотен или тысяч соединений. Хотя это кажется крайне сомнительным, с учетом современных методов мультиплексирования. И если у вас там в приложении еще и FastCGI, то вообще крайне сомнительно, что нечто самописное Вам так сильно поможет. Как бы Вы хитро не обращались к сокетам.
то — дань модульности и универсальности решения
Эта фраза характеризует вашу систему с нелучшей стороны. Я действительно начинаю убеждаться, что дело не в AJAX. А как обычно.
Возможность передачи данных сервером без запроса клиентом — удобно… для чата или другой передачи данных между пользователями
Ууу, как всё запущено. Вы о тройном рукопожатии что-нибудь слышали? TCP не возможен без установки соединения, которое инициализируется клиентом. Клиент всегда есть. И сервер тоже. Только они могут местами меняться. Похоже, пора давать ссылки на RFC. Я не люблю тыкать в мануал незнакомых людей, но Вы всячески к этому меня подводите. У меня сложилось впечатление, что Вы явно знаете о многих кусочках теории работы сетей, но цельной картины у Вас в голове нет.
Вы же в рассуждениях, видимо, считаете, что возможность использования технологии и возможность её _ограниченного_ использования — это одно и то же.
Не приписывайте мне то, о чем я не говорил. Я лишь пытаюсь донести до Вас, что Вы или не представляете до конца, о чём пытаетесь спорить, или не можете это нормально выразить словами. Или и то, и то.
Было бы весьма неплохо, если бы вы указали на конкретные пробелы в моих знаниях
Хорошо. Пока у меня сложилось представление, что Вы слабо разбираетесь в нюансах протоколов TCP и HTTP, слабо понимаете как реализована AJAX-технология и не имеете достаточного опыта в работе с высокими нагрузками и различными веб-серверами. Мне давать ссылки на конкретную документацию или найдете сами?
работать старшим разработчиком в области создания серверных компонент как-то тяжеловато, будучи таким недалёким.
Я уже смирился, что мир несовершенен, и многие люди занимают должности, не имея на то достаточной квалификации.
Смотря в каких случаях… количество запросов для обоих случаях не изменится
Не совсем так. Как показывает практика, когда внедряешь для какого-нибудь функционала работу без перезагрузки страницы, им гораздо чаще начинают пользоваться. Иногда на порядок или два. И получается, что время ответа бекенда почти одинаково (напомню, что время рендеринга шаблонов должно быть минимальным в нормальном случае), а число запросов к бекенду сильно возрастает. Я именно это имею ввиду, когда пишу, что в общем случае использование ajax увеличивает нагрузку на бекенд.
К тому же перезагрузка страницы вызывает как минимум проверку на обновление некоторых статических данных — скриптов, картинок, стилей
C чего бы, если веб-сервер, их отдающий, обычно сообщает браузеру, что эта информация должна кешироваться и ее не надо каждый раз загружать снова? Зачастую, как раз проблема — обновить закешированную статику в браузере пользователя.
достаточно неплохо владею теорией по сетям
Читая Ваши реплики, склонен считать, что эта фраза означает скорее «я знаю много умных слов из теории сетей».
Вы действительно считаете, что в случае аякс-запроса не используются TCP-сокеты? :))
TCP и AJAX — это разные уровни сетевых технологий
Ну да, я же написал, что Вы путаете мягкое с кислым. Работа аякса невозможна без использования ТСР-сокетов. Потому что аякс по сути — это ХТТП-запрос к серверу, использующему TCP-сокеты для работы с клиентом. И ему совсем необязательно передавать в одностороннем порядке данные от сервера к клиенту.
не будем забывать, что в AJAX запросы архитектурно асинхронные
Не будем забывать, что JS поддерживает и синхронный обмен запросами. Почему об этом мало кто знает, я не в курсе.
Я не говорю, что проблема нерешаемая — но в TCP такого нет
Я рыдаю под столом, честно. Вы сейчас хотите сказать, что HTTP работает через UDP-сокеты? Блин, ну правда, не отжигайте у всех на виду.
Есть более серьёзный проект, в котором задержки из-за периодического открытия TCP-соединений для AJAX-запросов — это плохо
. Нормальный веб-сервер не пробовали использовать?
Поскольку почти во всех браузерах существует способ в некоторых случаях открыть TCP-соединение
Ну да, HTTP работает по TCP. Покажите мне хоть один браузер, который не умеет работать с ним :)
мы предпочитаем использовать его
Ой, освежите всё же свои знания. Ну правда. У вас така-а-а-я каша в голове…
сайт должен быть доступен в любом случае, все его функции
Нет. Большинство функций — да. Все — нет.
Есть функции, которые ненавязчиво снижают уровень информационного шума (читай «спама») на проекте. И если они отсекают большую часть ботов (а использование JS для форм действительно отсекает большинство ботов на текущий момент времени), мне будет реально пофиг, что они отсекут 0.6% пользователей-параноиков, которые отключают JS и не могут написать сообщение. Хотя таких я предупрежу, что JS надо включить. Или дам капчу.
В целом AJAX даёт меньшую нагрузку на сервер, чем генерация полноценных страниц хотя бы за счёт отсутствия необходимости применения шаблонизатора
Вы, видимо, используете какой-то неправильный шаблонизатор.
Время работы правильного не должно быть больше времени получения параметров для него. А шаблоны для использования ajax-приложениями не такие тяжелые. Пример не засчитан.
А я вот скажу, что когда AJAX-запросов становится очень много, они существенно снижают число свободных процессов сервера-бекенда, что никак не улучшает производительность системы в целом. И поэтому AJAX-запросами проще «уложить сервак». Парируйте :)
мы используем даже передачу данных через TCP-сокет в веб-страницах нашего приложения вместо AJAX-запросов
Вы явно путаетесь в терминологии, потому что в этой фразе мешаете мягкое с кислым. Что такое, по-вашему, ajax-запрос, как не соединение браузера с TCP-сокетом веб-сервера? Не заставляйте меня Вас прилюдно позорить :)
По поводу цифр о 90% времени — я уже привёл их для себя. Включил голову и дописал 6 строчек кода. Что я делаю неправильно?
Если для Вас в рабочих js-фреймворках нашлась нужная функциональность — Вам повезло. Не у всех такие простые решения возможны в силу ряда причин.
Простой пример (правда, мало кому приходящий в голову в силу отсутствия необходимого опыта): аякс-запросы, написанные в 6 строчек, могут никак не сказаться на нагрузке сервера, на котором крутится Ваш хомячок, и дать очень большую нагрузку на сайте с несколькими сотнями тысяч хитов в час. И там уже придется подумать и реализовать схему кеширования, подходящую для такого случая. И 6 строчками вызова функций стандартного js-фреймворка не обойтись, к сожалению. И несколькими минутами времени тоже. И вполне возможно, что проще не реализовывать на первом этапе разработки проекта функциональность, которая требует существенного времени на программирование. Как бы красиво это бы не было.
Пока Вы делаете говнофункционал для 10% юзеров, тратя на него 90% времени разработки, Ваши конкуренты тратят 10% времени и выпускают бету, удовлетворяющую 90% пользователей. И завоевывают рынок. А Вы делайте, делайте.
Ничего личного, просто бизнес.
Когда Вы будете делать свой сотый сайт, Вы возможно придете к такой же мысли.
Увы, но делая сайты с миллионной посещаемостью, достаточно быстро понимаешь, что всех пользователей всё равно никогда не удовлетворить и какой-то процент так и так уйдет обиженным. Другое дело, что можно стараться минимизировать этот процент. Носкрипт — как раз попытка его минимизировать.
Это суровая реальность, как бы Вы к этому не относились.
Вам на пхп всего один бит проверять-то в данном случае.
Никаких операций с файлами.
Я к тому, что часть данных, необходимых для вывода комментариев (ник + id, больше ничего не надо), может хранится на одном сервере, а более полные данные о юзере (включая аватар) — на другом. И зачастую на этот другой у проекта-сателлита доступа нет.
Регистрационные данные юзера (ник, аватар, что-то еще) на одном сервере баз данных, комменты к статьям — на другом. Физически другом.
Ваши действия по оптимизации?
Файловую систему тоже не дураки пишут.
Если nginx пока ничего не кеширует, это не означает, что совсем ничего нигде не кешируется.
В стандарте SQL есть coalesce. Что за страсть пользоваться говнофункциями, делающими то же самое?
Чем лучше? По-моему ничем.
На каких нагрузках PHP начинает тормозить на битовых операциях?
Расскажите поподробнее, если владеете сокровенными знаниями.
Вас, кстати, не напрягает, что при ответе на этот вопрос без явного Вашего указания на этом сайте запустилось минимум четыре программы, которые
а) нарушают Ваше прайвеси
б) насильно запихивают Вам килобайты трафика?
Вы не хотите, кстати, оплатить процессорное время этого, которое тратите на всякую фигню?
И кстати, ирафик почтовый, опять же, всяких там кармадрочеров, кто оплачивать будет? :)
Агент уже почти год, как перешел на Юникод, он же поддерживает сейчас некириллические языки стран СНГ.
Именно. Так же как AJAX не является транспортным протоколом. Но в предыдущих сообщениях Вы неоднократно писали фразы, которые именно это и подразумевали своим некорректным сравнением мягкого с кислым. Учитесь правильно формулировать свои мысли.
Да сравниваете, сравниваете. Вы ж прямо написали, что TCP быстрее, чем ответы от веб-сервера. Но при этом не сказали, что подразумеваете, что TCP соединение с Вашим сервером уже установлено, а в случае использования Вами AJAX оно фактически устанавливается каждый раз заново. Иначе собственно непонятно за счет чего быстрота. И так, и так браузеру придется соединиться с TCP-сокетом сервера. Веб-сервер это или же ваш демон — какая разница? Накладные расходы на вызов XMLHttpRequest не дадут существенного увеличения времени установки TCP-соединения.
Гм. Не совсем так. Я не зря упоминал про синхронные запросы в JS. Другое дело, что текущие реализации XHR, насколько мне известно, не поддерживают полноценный pipelining, а поддержка браузером persistent connection с сервером зависят больше от принимающего сервера, нежели от умения XHR отправлять заголовок Keep-Alive. Ну то есть, определенный смысл в Ваших действиях есть, но вопрос невозможности отказаться от прямого соединения (Java, кстати, или Flash?) в пользу дееспособной конфигурации веб-сервера остается открытым.
Пальцем в небо. Я писал не про FastCGI, посмотрите внимательно на цитату, которую я там выделил.
А ну надо же. Оказывается, у нас уже что-то там с чем-то соединено, и сервер просто использует это соединение. Ну-ка ткните-ка меня в цитатку из предыдущих сообщений, где Вы говорили, что соединение состоялось. Без этой цитаты из Ваших фраз следует как раз то, о чем я писал выше — в предыдущих комментариях Вы фактически говорите, что инициатором передачи файла клиенту является сервер. Что полностью противоречит принципам TCP. Учитесь правильно формулировать свои мысли.
Не говорил. Не путайте причину и следствие. Я говорил, что AJAX в принципе невозможен без TCP: «Работа аякса невозможна без использования ТСР-сокетов». Про то, что AJAX предоставляет все возможности TCP я не упоминал. Цитату в студию, если таки упоминал.
Расслабьтесь. После Вашего последнего поста стало очевидно, что Вы просто не умеете правильно формулировать свои мысли, чтобы собеседнику не пришлось домысливать за Вас вещи, которые следуют из Ваших фраз, но как оказалось, которые Вы совсем не имели в виду. Перечитайте. И попробуйте представить наиболее очевидные вещи, которые следуют из Ваших фраз без полных формулировок, с многочисленными допущениями и умолчаниями с Вашей стороны. И поймете, что очень часто Ваши фразы — полная ахинея с точки зрения действительного положения вещей.
Эт не сугубо мое мнение, данную беседу читало уже много людей, разбирающихся в сетях, и у всех одно мнение — у Вас каша в голове. А похоже, все проблемы — от неправильного выражения мыслей или излишней торопливости при их переносе в текст. В общем, учитесь правильно формулировать свои мысли. Из-за того, что они у Вас скачут с пятого на десятое; из-за того, что Вы многое пропускаете, считая, что мысли собеседника пойдут ровно так же как и Ваши и обязательно поймут что Вы недосказали, получается, что Вы мешаете в кучу разные понятия и это сразу цепляет взгляд знающего человека.
И всё-таки у меня стойкая мысль, что проблемы производительности Вашего продукта — не в AJAX'е. Тут нужно глубже копать, у меня нет достаточной информации. Но интуиция пока утверждает, что Ваших костылей можно было бы избежать. Но эт уже отдельный разговор.
Считайте, что под недостаточной квалификацией я имел в виду, что Вы не умеете полно и точно излагать свои мысли. Вам повезло, что я терпелив и подвел Вас к точной формулировке того, что Вы имели в виду в предыдущих постах ;)
Вы опять мешаете в кучу разные вещи. Фактически, пишете «Камаз обладает ограничениями и недостатками, которых лишен двигатель внутреннего сгорания». Так понятнее, почему Вас забавно читать?
На AJAX накладываются ограничения HTTP-протокола, который по историческим причинам разрабатывали именно с существующими ограничениями. Хотя я слабо представляю веб-приложение на основе браузера, где это было бы критично. Просветите, пожалуйста. Мне, правда, очень интересно.
Вот здесь:
«AJAX запросы архитектурно асинхронные, это означает возможное несовпадение порядка запросов и ответов от сервера… в TCP такого нет»
Действительно, TCP гарантирует, что пакеты соберутся в нужном порядке. В отличие от UDP, который этого не гарантирует, как не гарантирует доставку вообще. Логично предположить, что если Вы пишете, про несовпадение порядка запросов и противопоставляете ajax работе с tcp-сокетом («мы используем… TCP-сокет… вместо AJAX-запросов»), то легко можете иметь ввиду, что AJAX — суть надстройка над UDP, а не над TCP.
Блин, ну вот опять Вы жжоте. Не может быть TCP быстрее TCP. Может быть, что самописное-приложение-сервер, обслуживающее несколько десятков соединений напрямую, быстрее по каким-то причинам, чем стандартное-приложение-веб-сервер, обслуживающие пул из нескольких сотен или тысяч соединений. Хотя это кажется крайне сомнительным, с учетом современных методов мультиплексирования. И если у вас там в приложении еще и FastCGI, то вообще крайне сомнительно, что нечто самописное Вам так сильно поможет. Как бы Вы хитро не обращались к сокетам.
Эта фраза характеризует вашу систему с нелучшей стороны. Я действительно начинаю убеждаться, что дело не в AJAX. А как обычно.
Ууу, как всё запущено. Вы о тройном рукопожатии что-нибудь слышали? TCP не возможен без установки соединения, которое инициализируется клиентом. Клиент всегда есть. И сервер тоже. Только они могут местами меняться. Похоже, пора давать ссылки на RFC. Я не люблю тыкать в мануал незнакомых людей, но Вы всячески к этому меня подводите. У меня сложилось впечатление, что Вы явно знаете о многих кусочках теории работы сетей, но цельной картины у Вас в голове нет.
Не приписывайте мне то, о чем я не говорил. Я лишь пытаюсь донести до Вас, что Вы или не представляете до конца, о чём пытаетесь спорить, или не можете это нормально выразить словами. Или и то, и то.
Хорошо. Пока у меня сложилось представление, что Вы слабо разбираетесь в нюансах протоколов TCP и HTTP, слабо понимаете как реализована AJAX-технология и не имеете достаточного опыта в работе с высокими нагрузками и различными веб-серверами. Мне давать ссылки на конкретную документацию или найдете сами?
Я уже смирился, что мир несовершенен, и многие люди занимают должности, не имея на то достаточной квалификации.
C чего бы, если веб-сервер, их отдающий, обычно сообщает браузеру, что эта информация должна кешироваться и ее не надо каждый раз загружать снова? Зачастую, как раз проблема — обновить закешированную статику в браузере пользователя.
Читая Ваши реплики, склонен считать, что эта фраза означает скорее «я знаю много умных слов из теории сетей».
Вы действительно считаете, что в случае аякс-запроса не используются TCP-сокеты? :))
Ну да, я же написал, что Вы путаете мягкое с кислым. Работа аякса невозможна без использования ТСР-сокетов. Потому что аякс по сути — это ХТТП-запрос к серверу, использующему TCP-сокеты для работы с клиентом. И ему совсем необязательно передавать в одностороннем порядке данные от сервера к клиенту.
Не будем забывать, что JS поддерживает и синхронный обмен запросами. Почему об этом мало кто знает, я не в курсе.
Я рыдаю под столом, честно. Вы сейчас хотите сказать, что HTTP работает через UDP-сокеты? Блин, ну правда, не отжигайте у всех на виду.
. Нормальный веб-сервер не пробовали использовать?
Ну да, HTTP работает по TCP. Покажите мне хоть один браузер, который не умеет работать с ним :)
Ой, освежите всё же свои знания. Ну правда. У вас така-а-а-я каша в голове…
Есть функции, которые ненавязчиво снижают уровень информационного шума (читай «спама») на проекте. И если они отсекают большую часть ботов (а использование JS для форм действительно отсекает большинство ботов на текущий момент времени), мне будет реально пофиг, что они отсекут 0.6% пользователей-параноиков, которые отключают JS и не могут написать сообщение. Хотя таких я предупрежу, что JS надо включить. Или дам капчу.
Время работы правильного не должно быть больше времени получения параметров для него. А шаблоны для использования ajax-приложениями не такие тяжелые. Пример не засчитан.
А я вот скажу, что когда AJAX-запросов становится очень много, они существенно снижают число свободных процессов сервера-бекенда, что никак не улучшает производительность системы в целом. И поэтому AJAX-запросами проще «уложить сервак». Парируйте :)
Вы явно путаетесь в терминологии, потому что в этой фразе мешаете мягкое с кислым. Что такое, по-вашему, ajax-запрос, как не соединение браузера с TCP-сокетом веб-сервера? Не заставляйте меня Вас прилюдно позорить :)
Скорее, на Ваш. Эт именно то, о чём я написал.
Если для Вас в рабочих js-фреймворках нашлась нужная функциональность — Вам повезло. Не у всех такие простые решения возможны в силу ряда причин.
Простой пример (правда, мало кому приходящий в голову в силу отсутствия необходимого опыта): аякс-запросы, написанные в 6 строчек, могут никак не сказаться на нагрузке сервера, на котором крутится Ваш хомячок, и дать очень большую нагрузку на сайте с несколькими сотнями тысяч хитов в час. И там уже придется подумать и реализовать схему кеширования, подходящую для такого случая. И 6 строчками вызова функций стандартного js-фреймворка не обойтись, к сожалению. И несколькими минутами времени тоже. И вполне возможно, что проще не реализовывать на первом этапе разработки проекта функциональность, которая требует существенного времени на программирование. Как бы красиво это бы не было.
Ничего личного, просто бизнес.
Когда Вы будете делать свой сотый сайт, Вы возможно придете к такой же мысли.
Это суровая реальность, как бы Вы к этому не относились.