исходя из получаемых данных, да

Все, что рендерится на сервере, уже обладает лучшем сео чем спа

Вот аксиома

Она не оспорима еще несколько лет.

до 2квартала 2018=)

если верно помню

потом гугл начнет нормально индексировать спашки

Гугл вроде бы уже пару лет типо поддерживает спа, но как-то им это не помогает.

потом гугл начнет нормально индексировать спашки

И в ру секторе все же яндекс король.

И наверно лучше на него ориентироваться. Если конечно у тебя не ру

у меня сектор то юа проект по европе тут вроде как хроми ведет

в общем если клиентский роутинг то пока пишем костыли для индексации

т.к. еще гугл не ввела свои правки и хз как они работать будут)

Парни, что бы юзать Вью - нужно перед этим учить вебпак? ;)

В плане, обязалова? ;)

Я учил, потом забыл, потом взял vue-cli, но ничего не вспоминал

Короче стандартный сборщик справлялся с поставленно задачей))

Не нужно Разбирайся поэтапно)

Борисов Дмитрий, фрилансер, занимаюсь VoIP, сообщество интересно тем, что на Vue пишу интерфейсы для АТС, активно использую Quasar-framework, Москва, устная рекомендация

Если кому нужны вебсоскеты, то вот https://www.npmjs.com/package/wspromisify

const data = await socket.send(response)

и куча плюшек

@houd1n1 какое то отношение имеешь?)

посмотри на ник

тут и там

)

а

ок

попробуй 1метр данных отправить

и принять

туда сюда

ну даже 500кб

надо кое что проверить

@houd1n1 я не ради настроение испортить

просто полтора года назад тоже в сокеты пришлось закопаться

в итоге нашел так сказать границы у браузеров

ну я прилично гонял по этой схеме, щас ток рассекретить решил на днях

большие джейсоны?

@houd1n1 https://github.com/astr0junk/backbone.WSR/blob/master/backbone-wsr.js

просто вот к чему пришел

и строчки

чанкинг и бафферинг

исключает лимиты по буферу в браузере на сокете

это покусочные данные

стрим

угу

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

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

почему?

ну у меня куча кучная кейсов с небольшими чанками а-ля одновременное редактирование

погляди код

суть та же

каждое сообщение имеет промис колбэк

просто транспорт другой

по поводу апи у меня ожидание await пока не придёт фрейм

в целом понятно, но это разбиение

?

всмысле?

как обход для больших месседжей ок

но есть у тебя, допустим, картинка

давай иначе - ты как хочешь что бы вело себя?

так

и ты хочешь по мере получения её частей отрисовывать

оч грубо, т.к. эт овряд ли быа бы картинка)

а почему не получить всю быстро?

без блокирования следующей?

т.е. если мы ждём конца потока в простом виде промисов, то утрачиваем возможность обрабатывать его кусочки

надо как-то совмесить

а и будет без блокирования как утебя

просто если мы разбили на N частей

то приходит сначала 1, потом 2 ... N

то пока у нас грузятся 2 до N

мы могли бы как-то поработать с 1

ммм

ну да в стриме куски не подпишешь

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

да подписать-то изи

ну вот там преобразовалка чанков туда сюда и есть

а вот красивый апи сделать как щас чтобы куски юзать

ab2str