Архитектура клиент-серверного приложения

git как-то справляется...

http://swarmdb.net/ - случайно не подобное идешь? Тогда гугли решения под «collaborative editing», и всякую теорию которая под этим лежит https://en.wikipedia.org/wiki/Operational_transformation.

Про swarmdb авторы рассказывали много и интересно, но кажется код на гитхабе у них начал протухать так толком и не ожив :). Хотя мне не очень понятно почему - там вроде не настолько сложно, чтобы за несколько лет не найти время.

Клиент раз в период времени запрашивает https://url/state c сервера и в запросе сообщает свой state. State вот такого вида.

[0,0,0,1,0,0,1,1,0]

Там где 0 информация не изменилась там где 1 изменилась, индекс этого массива является как бы именем данных. Тоесть ты туда обратно отдаёшь состояния клиента и сервера, если индекс для клиента (или сервера) еденичка и данные эти важны происходит запрос на эти данные, если нет то в приложении например появляется алерт «юху у вас чёт новенькое, обновить?». Ну ты понял. Можно вообще ооочень сэкономить если писаь вообще биты )) в 1 инте 64 значения состояний красота, я делаю именно так.

А вообще берёшь лист бумаги и ручку и рисуешь как оно у тебя будет общаться, ведь тут главное понятность,управляемость,удобство, а оптимизации потом присобачишь. Я выше сказал как делаю я. Да топорно, но быстро,удобно,маштабируемо,универсально и своё. Удачи.

Клиент раз в период времени запрашивает https://url/state c сервера

Как там в палеолите живётся? У вас там до сих пор это(http) дерьмо не выпилил?

Там где 0 информация не изменилась там где 1 изменилась, индекс этого массива является как бы именем данных.

Какой в этом смысл? Пересылай патчи.

Ты пытаешься синхронизироваться? Да и что значит изменилась? Как ты определишь что изменилось? Ты будешь записывать единичку для всего, что изменилось с последнего запроса? Какую из единичек выберешь? Какая важнее?

Можно вообще ооочень сэкономить если писаь вообще биты )) в 1 инте 64 значения состояний красота, я делаю именно так.

Биты? В хттп?

Биты? В хттп?

А в чем проблема с битами в хттп? Или в вашей вселенной компьютеры обмениваются информацией не в двоичном виде?

(http) дерьмо не выпилил?

Лолка такие хипсторы как ты именно и сидят на рестапях, в любом случае можешь пересылать данные как угодно суть не в этом.

Какой в этом смысл? Пересылай патчи.
Да и что значит изменилась? Как ты определишь что изменилось?

Ты алло или как? Есть структуры данных которые вьюхаются на клиенте и обрабатываются сервером, не важно что это это данные, имя пользователя, его бабло на счету, аватарка иное не важно вообрази SQL табличку или json. Данные изменяютя не по волшебству, а по вызову кода его изменяющего он то и репортовать должен об обновлении общего state которое отражает состояние данных, как на сервере так и клиенте. Эта абстракция без оверхеда.

Биты? В хттп?

Ясно всё с тобой, лалка очердная. Которая без 25 фреймворков не сможет нихрена, а синхронизацию ты поди через вебсокеты бы держал постоянно да? )))))))))

Какую из единичек выберешь? Какая важнее?

А ты чё в своём же приложении не в курсе чего важно или нет?

Имя пользователя важно, почта важно, картинка аватарки не особо важно, бабло на счету критически важно. Критическое синхаем всегда, остальное в простое только или по таймеру.

И вообще, критикуешь - предлагай! Тебе за вариант ТС спасибо скажет, а с легионом анонимусов сраться как минимум бесплезно. Вон Vit предложил готовый вариант и теорию, я «ручной» способ. А ты ничего. СасиФигуСладку злой редиско )))

Уверяю тебя, те, кто знаю что такое биты - не используют подобное хттп дерьмо.

Причём тут протокол, ну давай по zeroMQ возьмём и будет тебе счастье, но только у ТС мобилогуй через ВуеЖС ты читал? У него выбора практически нет как кроме на сервер https/wss запросы слать. И вообще я выше сказал, сначала надо сделать, оптимизация в том числе смена протокола на более подходящий уже потом. Опять же критикуешь - предлагай.

Автор задал корявый вопрос. Он не пояснил - генерирует ли его офлайн-режим, ведь если генерирует - ему нужна двусторонняя синхронизация, а если нет - односторонняя.

Причём тут протокол

Я уже ответил. На у тебя, похоже, очень сложно понять хоть что-то за рамками колхозного хттп.

но только у ТС мобилогуй через ВуеЖС ты читал?

И? В жс есть блобы, есть блоб-режим у ws.

запросы слать.

Запомни раз и навсегда - запросы существует в твоём хттп.

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

Эти мазы. Во-первых автор заранее определил «оптимизация нужна», а во-вторых это не оптимизация. Это вменяемая архитектура. Разумный человек не создаёт себе проблемы.

Я уже разбирал твои рассуждения. Но давай я тебе даже предложу, как сделать одностороннюю синхронизацию.

Да аффтар жжёт задал действительно расплывчатый вопрос, ну ты бы раз ты белый человек предложил бы два варианта? Или готовый инструмент для реализации или вопрос ему уточняющий задал. Но вместо этого ты срешься со мной, а я срусь с тобой именно потому что ты исключительно критикуешь, вот взял бы и как настоящий мужикпрограммист задавил бы меня альтернативой, яб тебе ещё спасибо сказал ибо конструктивная критика в любой форме даже жёсткой будет всегда к месту. А кричать _ненужно_ и я умею. Я спать. Раз ты всё знаешь подкажи советом ТСу и делов то.

Но давай я тебе даже предложу, как сделать одностороннюю синхронизацию.

Дык ты не мне а ТСу, я то читну и если мне понравится на ус намотаю. ))

хттп дерьмо

Не считаю, что хттп так уж сильно тебе подобен.

Первое, в контексте вменяемых решений никакая синхронизация «онлайн» не нужна. В базе всё зависит от структуры твоего состояния. Давай вынесем за скобки синхронизацию структуры, а вместо этого будет использовать колхозную подписку.

Что мы синхронизируем? Множество всяких разных объектов с общей структурой. Если структура общая и ты хочешь экономить - работают патчи. Как и что собрался гонять ты/автор - мне неведомо. Ладно, мне лень это объяснять. Я тебе покажу на самом базовом примере(правда я не знаю пхп, но всё же), который проходят все хистеры ещё за партой:

Даже на жабаскрипте тебе покажу.

//есть твой сервер, в нём есть некая структура, в общем виде она выглядит она сводится к подобному:
[[id|name]: obj, [id|name]: obj, ...]
//у тебя есть какой-нибудь user
user =  {
  bablo: value,
  avatar: url,
  other: value,
  ...
}

//далее ты напрямую, либо через отображение будешь передавать эти объекты клиенту:

//user -> client_user
//user -> ({bablo, avatar}) => ({bablo, avatar}) -> client_user

//далее ты наделяешь эти объекты каким-то идентификатором.
//[id]: client_user

//далее у тебя всё есть для колхозной подписки. Работает это так:
//subscribe(id, client_user => {logics}) 

//семантика такая. Клиент говорит серверу "будешь мне для такого айдишника слать апдейты сюда" - он будет их слать.

//далее у тебя есть твой колхоз-стор

store = {
  php: {
    colhoz: {
      client_user: {
        bablo, avatar,...
      }
    }
  }
}

//client_user к тебе пришел - я думаю, что ты осилишь как-то его записать в свой стор.

Если ты хочешь частичное обновление, то и с этим никаких проблем нет. отправляй [[fiend_name]: new_value, ...]. На самом деле это в 99% случаев ненужно, т.к. ты на оверхеде на своём пхп/хттп потратишь больше.

Если ты гоняешь нормальные бинарные данные - они весят копейки. Для более тяжелых всегда можно что-то наколхозить.

Я даже не знаю как вы там что-то пилите в своём вебчике, не понимая даже элементарных «современных» подходов.

А вот и фанбои атаковали. Ты ведь сможешь назвать мне причины по которым хттп не говно? Я даже тебе заранее скажу - максимум, что ты нагуглишь - это прокси/легаси. И то и то такое же дерьмо.

Причины почему оно говно - я тебе назвал. Тормозная, убогая, односторонняя, одно"запросная" херня.

Ой, хотя я забыл. У вас же в пхп там состояние в бдешке. Просто абстрагируйся, считай сервер за такое же живое состояние, как у тебя в клиенте.

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

А я вот анонима с битами чот не пойму. Он с одной дырочки в АПИ получает эти биты, а потом ломится в другую или даже несколько других дырочек, если какие-то биты приехали не нулевые.

Нахера он делает вместо (после) одного запроса ещё несколько? Не проще ли с этой одной дырочки сразу вместо тупого массива интов получить объект (только) с теми полями, которые обновились? Они же уже и так обновились.

Тормозной, убогий, односторонний

Это из твоего резюме?

Да это же царь. Местная достопримечательность.

Как раз вчера его обсуждали в соседнем форуме: www.linux.org.ru/forum/talks/14622669

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

Анонимусу дали сокеты, но он по привычке поллит сервер рестами? Какой в этом смысл? Это какая-то религия?

В общем теперь мне нужно подружить 2 эти части.

Это надо было на этапе проектирования делать, ну да ладно, поправимо.

Как организовать правильно синхронизацию между клиентом и сервером с учетом что пользователей будет много?

Много-мало, нет никакой разницы, если их больше одного. Отправленные на каждый клиент единицы данных регистрируешь. Все изменения централизуешь (метод save(), функция propagate_changes(), etc), при изменении перепосылаешь обновления тем, кому интересно. На клиенте похожая картина - либо по кнопке save, либо по вуе-watch отправляешь изменения на сервер, сам слушаешь обновления на сокете, иногда явно отписываешься от них. Еще у тебя будут «конфликты», когда юзер начал что-то менять, а сервер прислал обновление. Порешаешь либо явными блокировками, либо придумаешь как соединять две версии.

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

Как правильно выдавать токены на обмен данными и как этот обмен организовать?
токены на обмен данными

Это как в союзе по талонам что-ли? Ты либо чего-то недоговариваешь, либо кидаешься баззвордами. И так, и так не надо.

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

Нахера он делает вместо (после) одного запроса ещё несколько? Не проще ли с этой одной дырочки сразу вместо тупого массива интов получить объект (только) с теми полями, которые обновились? Они же уже и так обновились.

Ну это пхп/хттп-головного мозга. Если проще. Вот у тебя есть хттп - как ты будешь узнавать - жив ли твой клиент или нет? Никак. Как ты вообще будешь идентифицировать клиента? Никак. Да, ты можешь какими-то адскими костылями это закостылить, но этого никто не делает.

На самом деле его история очень странная. Если он отправляет состояние обновилось/нет для каждого объекта, то как это должно происходить? Он будет запоминать время последнего запроса и обновления считать от этого времени? Слишком много дыр для «понять».

сразу

Это не про хттп/пхп.

вместо тупого массива интов получить объект (только) с теми полями, которые обновились?

Ну он писал зачем - приоритеты. Хотя непонятно - что ему мешает изначально формировать их список таким образом, чтобы первыми были наиболее приоритетные.

Ах, не признал его сразу.

Конечно клиент генерирует данные и нужна двусторонняя синхронизация

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

В общем теперь мне нужно подружить 2 эти части.

Redux и его надстройка над localStorage.

Прежде чем решать технический вопрос реши логический: два девайса с одним юзером вошли в сеть, потом на девайсах сделали разные изменения, девайсы поключаются к сети - какую версию считать правильной а какую затереть?

Как правильно выдавать токены на обмен данными и как этот обмен организовать?

Если сам будешь делать, то смотри в сторону JWT - каждому пользователю после аутентификации выдаёшь пару токенов, короткоживущий сессионный и долгоживущий рефреш. Короткоживущий живёт только в приложении, рефреш живет только в хранилище.

Да, ты меня не понял. Если будет время и я не забуду приду в этот тред и распишу всё.

Анонимусу дали сокеты, но он по привычке поллит сервер рестами? Какой в этом смысл? Это какая-то религия?

Ага, ты повесь 300000 устройств на сокеты и по посмотри что будет. Всё нужно применять к месту. Так то можно и все сайты на wss перевести,но никто в здравом уме делать этого не будет.

Если ты про нормальные сокеты Беркли или *MQ аналоги то мы вообще не о них. Протокол не имеет значения его можно сменить как перчатки.

+

сразу это не про хттп/пхп.

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

проблема синхронизации двух БД не относится к архитектуре клиент-серверного приложения. это уже кэш кохеренс.
реализация офлайн режима зависит от предметной области, (например, наличие данных которые больше никогда не изменятся), а употребление приведённое в ОП ничего не значит.

Ага, ты повесь 300000 устройств на сокеты и по посмотри что будет.

Твоё хттп уже на 300 встанет раком. Но ты не волнуйся. Ах ну и да, ничего не будет.

Всё нужно применять к месту.

Правильно, и у хттп места нигде нет.

Так то можно и все сайты на wss перевести,но никто в здравом уме делать этого не будет.

И кого это должно волновать? Такова уж реальность, что в ней много легаси и много говна. Но это не значит, что можно и нужно делать говно оправдывая это тем, что «его много - не всё же переделывать».

Если ты про нормальные сокеты Беркли или *MQ аналоги то мы вообще не о них.

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

Протокол не имеет значения его можно сменить как перчатки.

Что за маня-мирок. Сообщаю тебе новость - протокол является определяющим. Есть взаимозаменяемые протоколы, а есть дерьмо. Вот хттп - это то самое дерьмо, которое множит на ноль все возможности того, что под. ws - это лишь обёртка, которая не множит на ноль то, что было под.

У тебя явные проблемы с восприятием действительности. Ты не понимаешь что такое постоянное открытое соединения и говно. Двусторонняя связь и дерьмо. Я понимаю, что тебе нужно оправдывать «свой» «выбор», но всё же - настолько нелепую ахинею не несети.

пару токенов, короткоживущий сессионный и долгоживущий рефреш.

Зачем?

Короткоживущий живёт только в приложении, рефреш живет только в хранилище.

В каком хранилище? Приложение это не хранилище? Или как это должно работать?

Ты агрессивно настроен, наверное, диалог не получится.

Зачем?

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

В каком хранилище? Приложение это не хранилище? Или как это должно работать?

Смешались люди, кони... Хранилище - это то, что persistent для клиента - local storage, async storage, DB etc.

Ты агрессивно настроен, наверное, диалог не получится.

Агрессивно только против тех, кто пытается свой фанатизм выдавать за объективно правильные решения.

По сессионному - авторизация запросов API.

Это что-то из мира хттп/пхп?

Рефреш-токен позволяет получить новый сесионный токен

Я знаю, я не об этом спрашиваю. Я спрашиваю зачем два? Это типа что-бы не увели? У тебя есть ssl/tls для этого дела.

когда предыдущий протухает, без процедуры аутентификации.

В чём проблема подключатся при помощи рфреш-токена?

Смешались люди, кони... Хранилище - это то, что persistent для клиента - local storage, async storage, DB etc.

Правильно, и это часть приложения. Ну я примерно понял. Вы один токен суёте в своё хпх/хттп, а второй держите как нормальный, а зачем нужно два - я так и не понял.

а зачем нужно два - я так и не понял

Допустим, злоумышленник угнал сесионный, несмотря на tls или благодаря его отсутствию. Что он сможет сделать? Только воспользоваться им в короткое время жизни. Хороший клиент пересоздаст сессию со своим рефреш-токеном.

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

Т.е. вот так можно попытаться объяснить oauth с двумя токенами.

В чём проблема подключатся при помощи рфреш-токена?

Да, нет такой проблемы, есть даже такое мнение что рефреш надо отдать бэку, а клиент пусть оперирует только сессионным - вот он и единственный токен.

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

Это что-то из мира хттп/пхп?

Нет. Это когда запросы клиента к бэку авторизуются токеном. А уж как его передавать, через заголовки, сессии или куки или вставкой в запросы к API, вопрос второй.

Ты не понимаешь что такое постоянное открытое соединения и говно.

Что такое постоянно открытое соединение? Что не дерьмо конкретно и почему?

Двусторонняя связь и дерьмо.

Что такое двусторонняя связь? Что не дерьмо конкретно и почему?

Сообщаю тебе новость - протокол является определяющим.

Нет, от него нужно абстрагироваться.

У тебя явные проблемы с восприятием действительности.

В смысле? Зачем мне её воспринимать когда я могу описать свою? Если мне будет мало http возьму ws если и то и всё иное мне будет не подходящим возьму TCP и поверх него напишу свой протокол делается это элементарно не надо реальность тут приплетать. Между тем http/s был есть и будет как бы ты не ненавидел его. Тем более от него осталось используемое в реальности только коды и get/post причём зачатую вообще без тела вернее телом является сам заголовок. Для узких вещей пишется свой нормальный бинарный протокол который может работать поверх любого другого транспортного.

Допустим, злоумышленник угнал сесионный, несмотря на tls или благодаря его отсутствию. Что он сможет сделать? Только воспользоваться им в короткое время жизни. Хороший клиент пересоздаст сессию со своим рефреш-токеном.

Как клиент узнает об этом? Когда токен сдохнет? Ну за этой время можно много чего наворотить.

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

Ну тогда и первый случай теоретический. В чём разница? Типа шанс угнать меньше?

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

Как ты узнаешь, что его украли? Странная логика какая-то. Всё это работает и для случая с одним токеном.

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

Да, нет такой проблемы, есть даже такое мнение что рефреш надо отдать бэку, а клиент пусть оперирует только сессионным - вот он и единственный токен.

Тогда заставлять юзера каждый раз аутентифицироваться? И зачем токен нужен бэку мне так же неясно.

У меня такое чувство, что пацанам просто дали два токена(зачем они сами не знают), а далее уже идут попытки как-то воспользоваться этим.

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

Ладно, предположим. Хотя не понимаю причём тут JWT, если это работает без всяких JWT. Но ты можешь ссылаться на стандарты и сравнивать это с пхп-стандартами. К тому же, если ты проверяешь подпись в токенах - как ты будешь отзывать отдельные токены? Тебе нужно иметь по ключу на юзера, чтобы мочь отзывать ключ, а вместе с ним всё подписанное им. Отозвать отдельные подписи ты не можешь, но ты можешь сувать в токены какие-нибудь айдишники и записывать их чёрный список, но это полная херня.

Нет. Это когда запросы клиента к бэку авторизуются токеном. А уж как его передавать, через заголовки, сессии или куки или вставкой в запросы к API, вопрос второй.

Все эти базворды из мира пхп/хттп. В моём мире есть соединение и оно уже по умолчанию безопасено. Мне не нужно никакие запросы авторизовывать.

В моём мире есть соединение и оно уже по умолчанию безопасено. Мне не нужно никакие запросы авторизовывать.

Как так? Ладно, допустим, соединение безопасно, т.е. MITM полностью исключаешь. Как бэк может обрабатывать запросы клиента без авторизации, особенно в системе с разграничением прав по ролям, пользователям etc? У тебя таким образом валидный низкопривилегированый клиент будет иметь возможность рулить всеми доступными функциями.

Все эти базворды из мира пхп/хттп.

Ничего подобного. У тебя через ws клиент как с бэком общается, наверняка что-то типа RPC? Ну и как тут без авторизации каждого запроса-вызова? Что ты тут лучше токенов придумаешь?

У bitfinex и bitmex и побольше wss клиентов, и все нормально, ничего не тормозит и маркетдата льется по сокетам огромная. Ну это из личного опыта работы с ними, а сам естественно не юзал такого уровня uws. Но вообще мечтать о 300к не имея даже архитектуры это бред школьника. По пути к этой цифре возникнет еще миллиард проблем, как программных, так и просто делопроизводственных. Если на старте об этом думать, то никогда не запустишься. Попробуй поработать ирл, что-ли.

Так то можно и все сайты на wss перевести,но никто в здравом уме делать этого не будет.

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

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

Ох посоны и понаписали вы тут х*ливару. Я перепрочту это дело еще на 2 раза пока пойму что и кто из Вас имел ввиду и накидаю мокап того как я начал видеть решение проблемы. Одно скажу точно что локальная база у меня приоритетная. При каждом добавлении данных они сохраняются на клиенте и отправляются на сервер для хранения. Отображаются данные естественно тоже только с локальной БД. Тобишь раз в некоторый промежуток времени я должен буду «сравнивать» содержимое двух баз данных и видимо вести логи когда были добавлены сущьности и когда была последняя синхронизация. Если честно из всего выше написанного я только еще сильнее запутался)))

uws

С ним ситуация ещё лучше. Достаточно посмотреть на тот убогий треш, что предлагает упоротый буст, либо ещё какая херня. И осознать масштабы эпидемии того, насколько же люди желают производить мусорное, избыточное и тормозящее дерьмо. Хттп пробрался куда глубже вебчика.

вуе-темплейт

Земля тебе пухом.

Земля пухом тем, кто придумал браузер без биндов на живые объекты, братишка, и тебе с твоим квериселектором.

Причем тут буст, где тут хттп глубже вебчика, что с чем связано? Я не понимаю тебя. Хттп это способ «рассказать о себе» в сети, где участники не особо знают друг друга. С кучей фич уровня «отправить в окно 8», «сказать, что сегодня мы не работаем» и прочий балансинг с проксированием. И все это на спец.софте с конфигами. Если не хттп, то придется лепить хендшейки и все эти хрени самостоятельно каждый раз, и договариваться с другими, какую версию нехттп с битовыми полями будем юзать. Ирл нормальный сервер и клиент отдают заголовков не более чем на один мту а дальше идет тупо контент или дуплекс. Че ты привязался к каким-то тормозам, которых даже нет? Не смотри на этот их сракет.ио да и все.

Земля пухом тем, кто придумал браузер без биндов на живые объекты

Я не буду тебе рассказывать о том, что я от тебя слышу всё тоже, что ты критиков выше

братишка, и тебе с твоим квериселектором.

Чего? Ты мне лучше объясни - что тебя сподвигло использовать хтмл. Как это? Норм? Почему, зачем? Если бы ты даже хотел хтмл"а - есть же эмуляция хтмл"а. Поведай мне свою историю.