Да не спорил я ни с кем. Просто не знал и давно интересно было. Тут я имел в виду, что технологии которые используются в вк для перехода по страницам - как раз то, что ищет автор.
Буквально в июне 2016 был на своей родине, у черта на рогах на дальнем востоке. Скорости ниже 16 килобит - обыденная реальность. Мобильный интернет - только через GPRS. Лимит на DSL - 300 мегабайт. Сверхлимит - 3 рубля за мегебайт. Это когда ты нажимаешь "обновить страницу", экран белеет, а ты ждешь с полминуты, порой, ответ сервера. Даже если ответ сервера - это "304 Not Modified". Вот тебе цифры: 1) Загрузить эту страницу там стоит примерно 4 рубля. 2) Обновить - примерно 60 копеек, спасибо кэшу браузера. 3) Обновить 10 раз - примерно 6 рублей. За день ты этоделаешь гораздо больше раз. 4) Ничего не обновлять, а просто ждать, пока xenforo сам проверит наличие сообщений и предложит их показать, переслав считанные байты - меньше одной копейки. 5) По времени, на 50кбитах эта страница грузится 3.8 минуты(!!!). 6) 50 килобит - это недостижимая роскошь в таких местах. AJAX-обновляшки и динамическая подгрузка контента в данном случае это манна небесная. А теперь я готов выслушать твои аргументы в пользу того, почему AJAX - это плохо. P.S. Хоспаде, просто признай, что ты ретроград. Это то же, что у тебя с любовью к старой Opera, которая песком пердит уже лет 5 как. А еще, скорее всего, просто вызвано незнанием JS и нежеланием его учить.
>> Буквально... 1) Ты не понял. Я просил сравнить объём данных, получаемых клиентом при открытии страницы без AJAX и с AJAX, в т.ч. листание страниц и т.п.. Насколько помню (когда сравнивал, несколько лет назад) разница была в пару-другую сотен байт. По сути, всё определяется разницей между размером HTML страницы и реально изменёнными данными (т.е. данными, которые получит AJAX, чтобы сформировать страницу). Эмпирически, если разница меньше 10-20 килобайт, то AJAX не надо использовать, если >50К, то надо, между - предпочтительно не использовать. 2) > пока xenforo сам проверит наличие сообщений Не путай мягкое с тёплым. Мы говорим о страницах сайта. 3) Я не говорил, что AJAX это плохо. Я говорил, "всё хорошо, что в норму". Ладно, не будем спорить. Тем более, прочитал ещё раз твою заметку и беру свои слова обратно. "Всплывающая инфа, фильтры по характеристикам, подгрузка комментариев и обзоров на товар - это вот все можно и нужно делать аяксом. " Про "подгрузка комментариев и обзоров" можно поспорить, а в остальном ты прав. При желании можно добавить ещё пару-другую случаев, где явно нужен AJAX. 4) > А еще, скорее всего, просто вызвано незнанием JS... Серьёзно?
при чем тут сервер апи? во-первых, ты сам можешь поглядеть во вкладке network что и как он шлет. На каждую композицию миниум два запроса приходится. во-вторых, я говорил про то, что у браузера есть пара-тройка функций, чтобы создать видимость хистори. Для этого запросы никакие не нужны. Там просто ты можешь браузеру сказать, что мол вот ща нужно создать "хистори" запись с таким вот хтмл (при чем не обязательно всей страницы) и таким вот адресом. И он сделает. И появится возможность нажать назад или вперед. И вешаешься на эвент навигации по хистори, когда юзер тыкает кнопки назад и вперед. И тогда ты когда юзер ползает по своей хистори можешь менять содержимое страницы или её части сообразно тому, что ты там сам насохранял. --- Добавлено --- @Nikdssl читай про SPA и такие приблуды как react, angular и конечно же vuejs созданные специально для таких случаев. Однако, для магазина это может быть не супер удобно на текущий момент, т.к. поисковики пока туговаты на индексирование SPA. --- Добавлено --- всё, закончилось это время. Настало время SPA. и слава богу.
Друзья, благодарю за ваше неравнодушие к теме, правда из обсуждения на мой гуманитарный ум прояснились только три вещи: 1. Нельзя обновлять страницу в ВК при прослушивании музыки 2. На нашей планете почти у всех есть JS 3. Жить на дальнем востоке плохо Все же хотелось узнать можно ли запилить ИМ, когда человек попал на любую страницу сайта (даже в карточку товара) и куда бы ни пошел - везде ему аджакс подтянет нужную информацию. Технология работает очень быстро, и почему ее не используют я не могу понять.
SPA ради SPA везде городить не здорово, как по мне. SPA это очень удобно для веб-приложений, типа того же веб-скайпа, или какого-нибудь гуглдрайва. И для любого другого приложения, которое можно на мобилке обернуть в webView и продавать как аппликуху полноценную, и никто не заметит подвоха. Для сайта же обычного, это больше фича ради фичи. Прям вот в каждом первом случае я бы не стал советовать это делать. Всему свое место, каждому подходу свой кейс, определяющий приемлемость.
Если ставить вопрос "Можно или нет?", то ответ "можно". Если ставить вопрос "Стоит или нет?", то ответ "Скорее всего не стоит". Если технологию не используют, значит есть на то причина. Самая серьезная причина - поисковая индексация. Этой одной причины достаточно для того, чтобы отложить эту идею до лучших времен. Если сайты Ваших конкурентов будут индексироваться лучше, чем Ваш сайт, то это может существенно повлиять (и скорее всего повлияет) на продажи. Поэтому, выбирая между технологичностью и продажами - выбирают продажи.
капец рулю, SPA идеально ложатся везде на все кейсы, если проц позволяет. А он уже позволяет даже нетормозящий Андроид. Поэтому SPA через несколько лет будут везде
А с чего SPA более требователен к процу, чем многостраничное приложение по идее, наоборот. И да, вот тебе кейс - форум. Я хочу открыть с два десятка вкладок, в каждой своя страница. В SPA ты так не сделаешь, это будет уже не SPA.
да ну брось. SPA это дебильный термин. по факту я говорю о переносе отрисовки в браузер целиком. Так что мою концепцию в моей голове это не нарушает. Ещё на эту концепцию хорошо ложится RPC, который позволяет множественные вызовы за один запрос, в отличие от CRUD и говноапи на урлах.
Ну вот тебя поди пойми, то SPA, то не SPA. Если не SPA, то не называй его так, чтобы ложных ассоциаций не было. А насчет реактов всяких, я на это дело поглядываю время от времени, и основное место, где я вижу реакт - это NodeJS, где он используется для сборки страниц на стороне сервера.
согласен. давайте выработаем термин, которым будем пользоваться на нашем форуме, и установим свой собственный индустриальный стандарт на шесть человек. =) как быть? ты мыслишь по-старинке
"где я вижу реакт" - это не в переносном смысле, мол "где мне кажется, он наиболее применим", а в прямом, где я его реально вижу, где он наиболее часто юзается. И это забавно, потому что делался он для клиентсайда. Но я тебя понимаю. У самого есть аппликуха, которая получает от сервера не разметку, а данные, на основании которых потом добавляет нужные сущности. Но, опять же, не сказал бы, что это нужно прямо везде, а не на интерактивных моментах. Тот же фейсбук придумал реакт от безысходности. Им тупо технически проще собирать страницу клиентом, слишком там много динамики, и она слишком часто дергается, в следствие чего генерация разметки - нерациональное использование ресурсов сервера. Вот они и перенесли генерацию в клиентсайд. Лепить же везде такой подход просто ради самого подхода я бы не рекомендовал. Я вообще не люблю фичи, добавляемые ради наличия фич, без логического обоснования. Это такая же крайность как и ретроградство, но с другого конца. Если технического обоснования такого подхода нет, и любой сраный лендинг будет собираться на клиенте, то это неоправданное усложнение и удорожание проекта.
Скажите, а можно каким-то образом открывать на моем сайте страницу с другого сайта? Например, покупатель хочет почитать о товаре, кликает на "подробнее" и ему открывается страница с официального сайта товара со всеми подробностями, и он может там делать переходы, но реально с моего сайта не уходит. Возможно ли такое в наше время?
Тот же яндекс маркет, если мне память не изменяет, имеет публичное API и позволяет на любой товар тянуть хоть характеристики, хоть цены, хоть отзывы.
Все же нужно было мне уточнить, здесь я имел в виду партнерский сайт с выгрузками товаров. Там если клиент кликает по товару, то улетает оформлять его на официальном сайте и скорее всего это увеличит отказы от моей страницы в Метрике. Мне хотелось сделать, чтобы сайт партнера открывался в окне моего сайта и клиент там оформлял заказ. Технология фрейма есть, но она требует размещение на чужом сайте кода - что невозможно.
Так и есть. Даже если вы открываете во фрейме другой сайт на своей странице, то этот фрейм - закрытая "песочница". Все, что там происходит, происходит уже на другом сайте. Хотя надо почитать на тему того, считается ли это отказом для Метрики. Как альтернативный вариант - договоритесь с партнерским сайтом, что вы будете проксировать к ним запросы на покупку. То есть, оформление по факту будет у вас, но проксироваться к ним. Деталей я подсказать не могу, понятия не имею, какая там возможна степень интеграции.