> Когда фронтендеры наконец откажутся от джиквэри?
Инструмент решает бизнес-задачи, зачем от него отказываться?
jQuery может умереть только если умрут множество плагинов написанных на нём типа selectric, selectize, slick и прочих популярных. Сейчас, конечно, понимаешь что можно писать код спокойно без jQuery, но всё-равно придётся его подключать из-за какого-нибудь плагина. А если он есть, зачем писать `forEach(item => { item.addEventListener(); })` если можно тоже самое писать существенно короче?
А если он есть, зачем писать forEach(item => { item.addEventListener(); }) если можно тоже самое писать существенно короче?

Так писать и не надо. Надо писать примерно так:


document.getElementById('elem-id').addEventListener('click', (event) => {
    if (event.target.classList.contains('js-item-class')) {
        // здесь как-то обрабатываем
    }
});
Во-первых, зачем проверку на класс делать внутри, если есть document.querySelector и document.querySelectorAll.

Во-вторых, document.getElementById вернёт всего один элемент — конечно forEach не нужен. Плюс jQuery в том, что позволяет подписаться сразу на всё без foreach.

Тем не менее я согласен с тем, что ценность jquery падает и всё чаще от него можно отказаться или найти более специализированную замену.

Если у вас будет 20 элементов с классом .js-item на странице, то в обычном случае мы добавим 20 обработчиков событий. А я привёл фрагмент, в котором обработчик клика добавляется на контейнер, а внутри уже проверяется, по какому элементу произошел клик. Как итог, обработчик всего один. Прошу прощения, если сразу недоступно объяснил намерения)

Собственно, суть была именно в том, что в jQuery удобно работать с коллекциями, хотя бы тот же toggleClass() применить.

всё это упаковывается в Android WebView, правильно я понимаю?
> Бесконечная прокрутка — главное свойство любого современного веб-приложения

Как же мы вас ненавидим…
А чем столь ужасна бесконечная прокрутка, если её не прокручивать далеко в дебри?
Сложности с предоставлением ссылки на определенную страницу, например.
Ссылки на определенную страницу и раньше были местами проблематичны.
Смотрите, я создал сайт с первой страницей, там 10 новостей. Я даю ссылку на первую новость, и выглядит она как mysite.com/page1/
Я добавляю еще одну новость (11-ую) и первая новость из первой десятки съезжает на mysite.com/page2/
Эта проблема решается ссылками не «открыть страницу Х от начала» а «показать новости начиная с Х и старше».

проблему с "бесконечной прокруткой" тоже можно аналогичным образом

Добавлю еще.
Вечная прокрутка, это 100% гарантия тормозов на сайте.
Не у всех на компах стоят хотябы 8гб памяти(да да).

Нет, не 100%, если сделана нормально через виртуальный скроллинг.

Ну расскажите что-ли, что не так?

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

Как бы виртуальный скроллинг именно так и работает, не путайте с бесконечной прокруткой. Из 10 тысяч строк вы рендерите 50, которые попадают в окно, все остальное вычищается из памяти, даже то, что уже было отрендерено. А не бездумно выжираете память по мере прокрутки.


А что у вас там на диск пишется в такой ситуации, я вообще не представляю.

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

Если система уходит в своп, то тормозить будет любой процесс, требующий еще памяти сверх.
А зачем она нужна, если её «не прокручивать далеко в дебри»?
И потом. Листаю, эээ, прокручиваю я новости. Август, июль, июль, июль… мне нужен февраль месяц, я точно помню, что это было в феврале.

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

И ее бесконечно сложно сделать в отличии от простой пагинации одним плагином.

Ну тут уж выбор за вами — UX vs DX

Фильтр по дате — не панацея. Вы никогда не листали бумажную книгу в поисках «где-то здесь»? «Примерно на середине» — открываем на середине. Читаем две строчки — «ага, сильно раньше». Отлистываем три десятка страниц, читаем две строчки — «чуть позже».

Короче говоря. Трёхкилометровые свитки — бесконечно удобная вещь, все эти ваши страницы в книгах — пережиток доинтернетных времён.

Ну вы же явно что-то конкретное ищите "где-то здесь". Что-то такое альфанумерик. Ну так вот вам текстовое поле для поиска того, что вы ищите, вместо того, чтобы тыкаться по страницам туда-сюда.

Да, я ищу что-то такое, что я узнаю с первого взгляда.
Вы никогда не искали книжку в синей обложке? Никогда не находили её — в коричневой?

Эмм… знаете, если у вас 100 страниц по 20 одинаковых синих книг на каждой, то как вы посередине их отличите друг от друга? Есть еще какой-то критерий поиска?

Я описал три не совсем идентичных кейса. Все они противоречат бесконечной прокрутке.
Какой кейс решает прокрутка, кроме "останься здесь ещё на пять минут, посмотри котиков, посмотри рекламу, останься ещё на пять минут, посмотри..."?

Вы пока не описали, что пользователь будет делать посреди выдачи с синими книгами. Бесцельно щелкать по страницам? Если ему надо найти в магазине Марка Твена — пожалуйста, вот поиск или оглавление на худой конец. Не представляю, что он забыл именно на 30ой странице этой выдачи. Интересно полистать, что есть — ну вот, листай с самого начала, еще и по популярности отсортировано.


"останься здесь ещё на пять минут, посмотри котиков, посмотри рекламу, останься ещё на пять минут, посмотри..."

А вот такие рассуждения не несут полезной нагрузки.

Читаю я, например, Пикабу на мобильном устройстве. Беру самое популярное за месяц. Там десятки страниц. Стоит случайно перейти по ссылке куда-то (или переключиться на другие задачи) и вернуться назад — всё сбросилось, читай крути сначала. А там ещё и подгрузка тормозная. И это ещё оптимизировали, раньше вообще тормозило на сотне постов.

И эту проблему с перезагрузками на сайте не решить вообще никак. Проще бросить это бесполезное дело.
Я точно видел рабочий пример, где бесконечный скролл, но при «уйти, затем вернуться», адресовало точно туда же, откуда ушел.
Не сомневаюсь, что это можно сделать. Но это должен делать сайт, и это требует немалых усилий. Я же как посетитель ничего сделать не могу. (Пилить свой браузер требует гораздо больше усилий.)
Не-не-не, не думайте пожалуйста, что я предлагаю вам что-то пилить, разумеется это должен делать сайт. Я имел в виду то, что это «физически» возможно, т.е. это не миф.
Жаль не могу влепить Вам плюсик. Бесконечная прокрутка это бич современных веб-приложений
Бич веб-приложений (да и просто приложений) — это разработчики, которые не могут сделать бесконечный скролл без тормозов, и UI/UX специалисты, которые не могут сделать дополнительные способы навигации (быстрый переход к февралю например, как в примере с новостями выше). Как видите, проблема не в инструменте отображения информации, проблема в неграмотном его использовании.

О, опередили меня :)

Бич современного веба — это веб-приложения где не надо. Дожили, с noscript почту в браузере иной раз не посмотреть.

За вами видимо гугл следит через js?

Ох если бы он следил только через JS…

А по сути — носкрипт приходится использовать чтобы банально было меньше тормозов, хотя у меня процессор под 4 ГГц и 32 гб RAM. У вашего провайдера/на работе заблокирован какой-то CDN или сайт типа facebook/vk/linkedin, которые много кто использует для авторизации на своих сайтов — можете ждать загрузки даже самого простого сайта очень долго.

Особенно когда там есть футер :D по-моему у вебгуёвого инстаграмма так

Я не понял из статьи, зачем нужен React, котгда все это можно сделать с помощью JQuery.
Кто-нибудь может подробнее объяснить?
Может дело вкуса?

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


Ну не делать же всего день в одиночку на JQuery то, что можно сделать командой за месяц!

Эх, сейчас бы все на моду списать. Посмотрю я на вас, когда вы со своим макаронным кодом на jQuery познаете всю боль поддержки сайтов с более-менее замороченной логикой на клиенте. Тесты и документация нужны в любом более-менее крупном проекте, кстати, безотносительно того, на чем он написан.

С другой стороны, если вы занимаетесь фронтом и так и не поняли, для чего нужны фреймворки – вам они и не нужны, наверное (и до кучи вас дальше галер и лендосов никогда не пускали).
Макаронный код на JQuery никто писать не заставлет.

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

Почему нельзя вынести «тяжелую» часть на сервер?

С другой стороны, если вы занимаетесь фронтом и так и не поняли, для чего нужны фреймворки – вам они и не нужны, наверное (и до кучи вас дальше галер и лендосов никогда не пускали).

Я, в основном, занимаюсь backend'ом, но периодически приходится делать и frontend. И вот работал я и CRM-системами и немаленькими, и с backoffice'ами заковыристыми, и с интернет-магазинами и просто со сложными сайтами-каталогами, но так и ни разу и не почувствовал, что на клиенте мне не хватает инструментария Bootstrap+JQuery. Если не сложно, разъясните, что я упускаю и в каких случаях время, потраченное на освоение framework'а типа React/Vue/Angular мне удастся сэкономить при дальнейшей разработке с его помощью?

Попробуйте напишите что-нибудь больше похожее на приложение. Лучше даже backendless, чисто in-memory. Вы офигеете делать это на jquery, а если и не офигеете сразу, то офигеете через пол года на поддержке.


Вся эта "ненужная возьня" с ангулярами и реактами предоставляет должный уровень абстракции для создания приложений. Так-то вы на голом бэкендом языке (любом) руками слушать 80-ку и руками писать туда html строкой. Но вы же явно этого не делаете.

А еще больше офигеет другой разработчик, к которому этот код перейдет по наследству. Одним из главных достоинств фрэймворков считаю хоть какую-то, но все таки стандартизацию — открывая любой новый проект на React/Angular сразу понятно, что там происходит.
Одни пишут чистые компоненты, другие классы, третий все старается писать иммутабельно и функциями. Кто-то использует redux, еще кто-нибудь предпочитает MobX или что еще там.
Угу. Очень стандартно и понятно.

Что-то я еще не проснулся… Правильно будет:


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

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

Зачем раздувать код на бэке, когда можно все сделать на фронте?

Если делать все на фронте, то веб будет не нужон.

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

SPA с бесконечной прокруткой?

А как же, все как вы любите

Сначала вы говорите «всё», потом оказывается, что это «весь UI».

Так а это ответ на


Зачем раздувать код на фронте, когда можно все сделать на бэке?

такой вот


Зачем раздувать код на бэке, когда можно все сделать на фронте?
Как сделать «всё на бэке» я ещё представляю, хотяб тот же голый html отдавать, без JS вообще, если уж спорить. А вот как сделать «всё на фронте»?

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

Странное у вас понимание «всего».

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

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

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

Вы прямым текстом заявили: «можно все сделать на фронте».
Никакой прозы, 100% холивара (=
Чтобы снизить нагрузку на клиентские устройства.
Чтобы уменьшить количество потенциальных дыр в безопасности.
Чтобы у клиента не возникло проблем с актуальностью данных.
Попробуйте напишите что-нибудь больше похожее на приложение.

Пробовал. JS в таком приложении сводится к тому, чтобы при определенных действиях пользователя запросить у сервера обновленный кусок данных страницы. Ну и эффектов немного. Так зачем фрэймворки-то нужны?

Лучше даже backendless

Зачем?
С одной стороны хочется сказать «да не зачем, просто жутко модно забивать на бекенд, все пихать в клиент, потом делать вид, что не слышим жалоб пользователей о страничках с 50Мб».
С другой, ну вот таки да — если юзер может как-то более продвинуто работать с веб-приложением, тогда просто заморочаемся все описывать именно на беке. Ибо когда мы можем что-то просто отrhыть/сабмитнуть, тогда да, как бы бекенд справится. При ajax даже сможем отобразить изменения без ребута страницы.
Однако когда у нас идет строжайшее разделение, тогда html только каркасом, все без исключений стили и практически все до единого вопросы анимации/стилей на css (preprocessing only), RESTful API — передача только самих данных, тогда как раз и наступает время реактивизации фронтенда. И там уже по полной прут локальные хранилища для сохранения всевозможного состояния GUI, как раз пример с прокруткой бесконечной (возврат после кнопки «назад» куда надо), drag&drop, современные модальные окна, вебсокеты… все это без реактивизации почти на порядок сложней.
До слована «однако» я прекрасно понимаю ваш комментарий, однако далее для меня как будто теряется нить повестования :)

Однако когда у нас идет строжайшее разделение

Разделение чего с чем?

тогда html только каркасом, все без исключений стили и практически все до единого вопросы анимации/стилей на css (preprocessing only)

Это какие-то вопросы разметки. HTML — каркас, в CSS — стили и анимация. И?

RESTful API — передача только самих данных, тогда как раз и наступает время реактивизации фронтенда.

Почему только для передачи данных? Даже RESTful API можно использовать для получения частей страницы, а не только данных.

И там уже по полной прут локальные хранилища для сохранения всевозможного состояния GUI

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

прокруткой бесконечной (возврат после кнопки «назад» куда надо), drag&drop,
современные модальные окна

Это вопрос подключения библиотеки и 10 строк инициализации+конфига.

вебсокеты

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

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

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

Вы на каждый чих на бэк лазите

Ну и что? С точки зрения пользователя что-то меняется?

Вопрос не в том, нужны толстые клиенты или нет.

Да нет, это как раз основной мой вопрос. Какие плюсы от толстых клиентов в web'е?
С точки зрения пользователя что-то меняется?

Отзывчивость, притом, достаточно серьезно.
Ну да, при толстом клиенте она будет хуже.

Любое действие пользователя все равно спровоцирует запрос на сервер (данные получить/сохранить — тут без сервера никак). С точки зрения отзывчивости отрендерить данные на клиенте будет ничуть не быстрее чем вставить предварительно отрендеренные на сервере данные. Скорее всего даже медленне.
Также JS на клиенте ухудшит отзывчивость.
С точки зрения отзывчивости отрендерить данные на клиенте будет ничуть не быстрее чем вставить предварительно отрендеренные на сервере данные. Скорее всего даже медленне.
Также JS на клиенте ухудшит отзывчивость.

Что за ахинея.

Обоснуйте.

PS
Также JS на клиенте ухудшит отзывчивость.

Следует читать как
Также большой объем JS на клиенте ухудшит отзывчивость.

Вроде базовые вещи… ну да ладно.


Чтобы запросить новую разметку нужно время, чтобы отрендерить ее нужно время, чтобы передать обратно на клиент нужно время, чтобы распарсить html и вставить в dom нужно время. Учитывая в каком плачевном состоянии может находиться соединение с интернетом, все это будет яно дольше, чем точечная работа с DOM и запросы данных небольшими порциями тогда, когда нужно.


У вас видимо свое понятие отзывчивости, так как на отзывчивость размер js не влияет. К тому же все толстые скрипты прекрасно кэшируются, а парсятся только один раз на старте приложения.

Чтобы запросить новую разметку нужно время,
распарсить html и вставить в dom нужно время

Так на запрос/получение данных столько же времени уходит.
Также толстому клиенту часто требуется несколько запросов для получения данных. Более того — несколько зависимых друг от друга (то есть синхронных) запросов. Что будет в разы дольше, чем получить сразу отрендеренный кусок страницы от сервера.

чтобы отрендерить ее нужно время

Ну так и на клиенте нужно это время. Только мощный сервер справится с этим в разы быстрее, чем слабенькое устройство клиента.

распарсить html и вставить в dom нужно время

А сгенерировать html и вставить его быстрее? В любом случае, не припомню, чтобы я видел затруднения именно в этом месте. Это какие-то миллисекунды.

У вас видимо свое понятие отзывчивости, так как на отзывчивость размер js не влияет. К тому же все толстые скрипты прекрасно кэшируются, а парсятся только один раз на старте приложения.

Дело не только в объеме кода, но в том, сколько этот объемный код потом выжрет памяти и процессорной мощности для своей работы.
Так на запрос/получение данных столько же времени уходит.
Также толстому клиенту часто требуется несколько запросов для получения данных. Более того — несколько зависимых друг от друга (то есть синхронных) запросов. Что будет в разы дольше, чем получить сразу отрендеренный кусок страницы от сервера.

Но объем данных меньше, чем объем верстки. Если еще и пожать как-нибудь, через protobuf тот же.
Но не дай бог, если вы еще и всю страницу целиком перерендериваете.
А для тяжелых запросов выделяется отдельный ендпоинт в апишке.


Ну так и на клиенте нужно это время. Только мощный сервер справится с этим в разы быстрее, чем слабенькое устройство клиента.

Замеры, пожалуйста. Я уверен на 146%, что даже самый мощный сервер не спасет от latency. А при загрузке данных я прямо на клиенте мгновенно покажу спиннер и буду себе дожидаться ответа. Сохраняя при этом ту самую отзывчивость, так как пользователь может вообще свалить в другой раздел.


А сгенерировать html и вставить его быстрее?

Но зачем, если можно напрямую работать с DOM?


Дело не только в объеме кода, но в том, сколько этот объемный код потом выжрет памяти и процессорной мощности для своей работы.

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


Что тут обсуждать вообще, все более-менее сложные веб-приложения сделаны именно как SPA. Office online, google docs, inbox, telegram, whatsapp… Не потому что разрабы хипстеры, а потому что это другой уровень как раз-таки той самой отзывчивости. Противиться этому по меньшей мере странно.

Но объем данных меньше, чем объем верстки.

Но запросов-то больше. И в ответах сервера могут быть данные, которые не нужны для текущего действия. Если все это происходит асинхронно, то я могу понять выгоду от этого подхода, но если же где-то образуется очередь синхронных запросов — это будет 100% медленне, чем получить готовый кусок верстки за раз.

Но не дай бог, если вы еще и всю страницу целиком перерендериваете.

Зачем? Получаю кусок (или несколько) html от сервера — расставляю все по местам.

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

Спиннер во время загрузки я тоже покажу. Какая разница, во время загруки данных или во время загрузки отрендеренного html?
Пользовтель в это время также может продолжать перемещаться по странице.

Office online, google docs, inbox, telegram, whatsapp

Whtasapp? Telelgram? У них вообще нет онлайн-версии, только нативные приложения.
Думаю, что приложения подобного уровня добиваются макимальной отзывчивости и реалтайма с помощью вебсокетов. Я с этой технологией как программист знаком слабо, так что не могу сказать, можно ли обойтись без framework'а или нет. Но а рамках данной дискуссии я бы хотел обсудить обычное клиент-серверное взаимодействие с AJAX-запросами.

А сгенерировать html и вставить его быстрее?
Но зачем, если можно напрямую работать с DOM?

Не представляю, как это делать. Да и в примере в статье вроде html подготавливают.

У Телеграма есть веб-версия. https://web.telegram.org/

Видимо я что-то пропустил.
Спасибо.
AJAX-запросами


Если говорить открыто, то на хоть сколько-нибудь значимом проекте это уже «лишняя» технология. Там поднимается полноценный websocket. По нему туда-сюда гоняются json с данными. По которым уже идет вся работа на клиенте.

Аякс по сути на сегодня — удел хобби/микро проектов.

P.S. И да, тот же клиент whatsapp — это «хромиум» с веб-гуем внутри, если мне память не изменяет. Такое назвать «нативным» язык не повернется. Это SPA.
Вы сейчас говорите про SPA или вообще про интернет-порталы?
Если все это происходит асинхронно, то я могу понять выгоду от этого подхода

Все запросы с клиента асинхронны.


Зачем? Получаю кусок (или несколько) html от сервера — расставляю все по местам.

То есть вы размазываете UI-логику, часть на клиенте, часть на сервере.


Спиннер во время загрузки я тоже покажу.

Предыдущий пункт.


Whtasapp? Telelgram? У них вообще нет онлайн-версии, только нативные приложения.

Выше уже ответили. Есть веб версии, а те, что десктопные — это электрон. (хотя насчет телеги не уверен).


Думаю, что приложения подобного уровня добиваются макимальной отзывчивости и реалтайма с помощью вебсокетов. Я с этой технологией как программист знаком слабо, так что не могу сказать, можно ли обойтись без framework'а или нет. Но а рамках данной дискуссии я бы хотел обсудить обычное клиент-серверное взаимодействие с AJAX-запросами.

Обойтись-то можно, это ж транспортный слой.
Но не очень понятно, что вы имеете в виду здесь под фреймворком, клиентский или клиент-серверный?
Ну и про AJAX уже тоже сказали.


Кроме того, все больше набирают популярность не классические (устаревающие?) запрос-ответ подходы (REST, RPC), а вещи из разряда graphql или даже pouchdb.


Не представляю, как это делать. Да и в примере в статье вроде html подготавливают.

Ну так это уже совсем другая история. Это не HTML, это JSX — описание маркапа на js. Потом там работает virtual dom рендерер.

Все запросы с клиента асинхронны.

Разве? Я частенько при интеграции API сталкиваюсь с тем, что для достижения результата мне необходимо отправить сериию последовательных запросов.
Вот, к примеру серия запросов к Fundamerica API для создания инвестиции:
1. Создать предложение.
2. Создать пользователя/компанию.
3. Получить авторизацию.
4. Создать инвестицию.
И эти запросы невозможно отправить асинхронно — для отправки каждого следующего запроса мне необходимы данные из предыдущего.
Вы не сталкиваетесь с такими ситуациями?

То есть вы размазываете UI-логику, часть на клиенте, часть на сервере.

Не совсем понимаю, что вы имеете ввиду под названием «UI-логика».
Видимо, да, разделяю эту логику. И?

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

Я имею ввиду, что я не разрабатывал клиентскую часть с использованием Websocket'ов и не могу сказать, есть ли реальная возможность не использовать клиентские framework'и при организации передачи данных через подобный канал. Подозреваю, что можно просто задействовать какую-то библиотеку и продолжать следовать описанным мною путем, но не могу утверждать этого точно.

кроме того, все больше набирают популярность не классические (устаревающие?) запрос-ответ подходы (REST, RPC), а вещи из разряда graphql или даже pouchdb.

А GraphQL — это не запрос-ответ по-вашему?
Что касается pouchdb — я не знаком с этой технологией. Если я правильно понял, то данная технология позволяет писать данные в локальную ДБ, а потом синхронизировать данные с сервером, когда тот выходит онлайн.
Если мое понимание верно, то такая технология породит целую тучу проблем, связанных с безопасностью и с ошибками синхронизации.

Ну так это уже совсем другая история. Это не HTML, это JSX — описание маркапа на js. Потом там работает virtual dom рендерер.

М, хорошо. Как я описал выше — проблем со скоростью в момент вставки подготовленного html я никогда не имел даже на самых слабых устройствах. Кроме увеличенной сложности есть какие-то плюcы у данного подхода?
И эти запросы невозможно отправить асинхронно — для отправки каждого следующего запроса мне необходимы данные из предыдущего.
Вы не сталкиваетесь с такими ситуациями?

Все запросы асинхронны. То, что вы их выполняете "последовательно", еще не значит что синхронно.
Вот вам пример:


async function transaction() {
  const result1 = await getResult1();
  const result2 = await getResult2(result1);
  //... etc
  return await getResultN(lastResult);
}

или по стариночке


function transaction() {
  return getResult1()
    .then(getResult2)
    .then(getResult3)
    //... etc
    .then(getResultN)
}

Не совсем понимаю, что вы имеете ввиду под названием «UI-логика».
Видимо, да, разделяю эту логику. И?

Ну у вас бэк знает как рендерить одни куски UI, а клиент — другие (спиннеры и т.п.). В идеале я стремлюсь к тому, чтобы избавить бэк от ненужной работы и оставить ему те вещи, которые он действительно должен решать — сложную бизнес-логику. А симпотишную отзывчивую мордашку пусть рисует сам клиент, благо и возможностей, и ресурсов для этого 2017 году предостаточно.


вебсокеты

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


GraphQL

Да, я так и думал, что возникнут вопросы, но было уже поздно. Я имел в виду конкретный клиент и конкретный ui-кит под это дело — apollo и react. Вы можете декларативно объявить какие именно данные и какие поля вам нужны в заранее подготовленной схеме (модели). В качестве запросов остаются только мутации, которые тоже достаточно неплохо контролируются. При этом аполло кеширует запросы (когда нужно), батчит их, а графкл позволяет выбирать из сущностей только те поля, которые нужны.


pouchdb

Никаких проблем с безопасностью нет, если правильно настроить, как собственно нужно настраивать все. Вы выдаете пользователю конкретные сущности-коллекции с нужными правами, и возможность как-то их менять с нужными правами. И больше вообще не паритесь по поводу транспорта. Но нужно держать в уме синхронизацию. Она, естественно, есть, но немного не в том привычном виде. Представьте, что у вас мобильный гуглдок, а связь постоянно куда-то проваливается. Существуют алгоритмы синхронизации для таких ситуаций: OT, CRDT и компания. Да, это отдельная песня, но это не значит, что это нереализуемо. Кроме того, есть мнение, что синхронизация оплогов — как раз то, что нужно для такой работы, причем с поддержкой оффлайна. То есть вы не сущности синхронизируете, а операции над ними.


М, хорошо. Как я описал выше — проблем со скоростью в момент вставки подготовленного html я никогда не имел даже на самых слабых устройствах. Кроме увеличенной сложности есть какие-то плюcы у данного подхода?

Плюс в том (окей, сознаюсь, сейчас буду про react), что вы один раз декларативно объявляете зависимость вашего внешнего вида от ваших данных и все. Все остальное, генерация vdom, точечные оптимизированные апдейты реального dom за вас делает библиотека.


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


Плюс virtual dom в том, что вы не меняете своей "схемы ui", вы просто "засовываете" в нее новые данные, а vdom уже сам решает, какие узлы dom должны быть изменены.


Дальше. Используя популярный нынче компонентый подход на клиенте, вы получаете адекватный граф зависимостей для этих самых компонентов. Каждый компонент импортирует в себя все что нужно. Попробуйте вспомнить, сколько раз вы перескакивали из одной ветки проекта в другую, только чтобы синхронизировать разметку и стили? И картинки? И svg-иконки? И скрипты под это дело?

Все запросы асинхронны. То, что вы их выполняете «последовательно», еще не значит что синхронно.

Именно это оно и значит. Если я выполняю свои запросы последовательно — значит синхронно.
Другое дело, что независимые друг от друга запросы я могу выполнять параллельно, то есть асинхронно. Но в данном примере таких запросов нет.

Ну у вас бэк знает как рендерить одни куски UI, а клиент — другие (спиннеры и т.п.).

Нет, клиент ничего не умеет рендерить вообще. Он умеет только показывать отрендеренные заранее куски, анимировать их или заменять их полученными от сервера другими кусками.

Огромное спасибо за разъяснение про схемы работы различных компонентов и технологий с подробными примерами.
У меня появилось понимание, в каких случаях использование JS Framework'ов может быть востребовано.
Именно это оно и значит.

Ну нет же. Синхронно/асинхронно — это не последовательно/конкурентно (в js нет параллельных вызовов, если только не через воркер, но мы сейчас не об этом). Вызовы (если мы про xhr/fetch) могут быть асинхронными последовательными и асинхронными конкурентными.


//асинхронный последовательный
call1().then(call2).then(call3).then(::console.log);
//так как сначала выведется '1' а затем цепочка
console.log('1)';

//асинхронный конкурентный
Promise.all([call1(), call2(), call3()]).then(::console.log);
//сначала '2', а заетм коллы, но в неупорядоченном виде
console.log('2');

Нет, клиент ничего не умеет рендерить вообще.

Я даже не знаю, что на это ответить… innerHTML, document.createElement, appendChild и компания?


const html = (name) => `
  <div>
    OMG ${name} I'm rendered on client side!
  </div>
`;
const element = document.createElement('div');
element.innerHTML = html('Carl');
document.body.appendChild(element);

Это самый простой случай, что скажете?

Синхронно/асинхронно — это не последовательно/конкурентно

Это именно последовательно/конкурентно, когда мы говорим про запросы относительно друг друга, а не отсноительно остального кода.


call1().then(call2).then(call3).then(::console.log); // цепочка синхронных (последовательных относительно друга друга) вызовов

Дополню цитатой из словаря:


In computer science, especially parallel computing, synchronization means the coordination of simultaneous threads or processes to complete a task in order to get correct runtime order and avoid unexpected race conditions.

Я даже не знаю, что на это ответить… innerHTML, document.createElement, appendChild и компания?

Я теряю нить диалога, кажется. Я не утверждаю, что с помощью JS нельзя что-то рендерить, я говорю, что в схеме взаимодействия клиента и сервера, описанной мной, все рендерится на стороне сервера. И нет никакой необходимости писать эту логику на клиенте.

Не забудьте все это в Kubernetes запаковать, а то масштабировать будет неудобно!))


Вообще вы правы в том, что эти технологии нужны, но неправы в том, что считаете из нужными независимо от масштаба.


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

Какой из вас программист, если вы используя библиотеку, пишите «макаронный код», да ещё и обвиняете в этом саму библиотеку?

Поэтому на проектах я против таких людей, как вы: сторонников фреймворков, псевдобиблиотек (ангуляров, реактов) и прочей чепухи, дальше которой вы ничего не видите, вплоть до возможностей применения элементарных парадигм программирования с целью ухода от «макаронного кода».
<p className="user-email"> <SvgMail />&nbsp;&nbsp;{user.email}</p>

Вы серьезно?


var xmlHttp = new XMLHttpRequest();

  • window.fetch?
  • Не, не слышал.

И такого у вас вся статья. Вам бы самому получиться где-то. Там, глядишь, и что такое REST поймете. И только уж после этого начинайте туториалы публиковать. Статье жирный минус.


Предупреждение начинающим: в статье говнокод и бессмыслица. Не используйте для обучения

Запрос к серверу на каждую иконку?
Пардон, неправильно понял. Цитаты не разделены были.

window.fetch?
Не, не слышал.


Вот тут необоснованно. Технология в некоторых браузерах появилась только в этом году.

А полифилу уже много лет.

Да, но ни тот, ни другой все еще не поддерживают отмену запроса. Мелочь, но из за этого пришлось отказаться от fetch в пользу axios.

Ну кстати много споров по этому вопросу (отмене). Я как-то до сих пор метаюсь, но последнее время стал-таки склоняться, что запрос, эм… нельзя отменить, он же уже ушел. Можно отменить реакцию на него (как это в rxjs делается), но это уже доп. обертка над этим фетчем.

Ни разу не сталкивался с необходимостью отмены запроса. Или отмены реакции. По-моему, идемпотентность решает эту проблему.

Если перестал быть нужен результат, то зачем передавать его по сети? Особенно для мобильного сайта или PWA.
Отмена запроса нужна постольку, поскольку браузеры не отменили ограничение на количество одновременных запросов. Если у вас очередь запросов, то без отмены вам придётся ждать завершения предыдущего прежде чем пройдёт следующий. Это может быть критично в зависимости от скорости и времени ответа.

Cancellation token пробовали?

Поддерживаю. Тем более XMLHttpRequest не поддерживается в ServiceWorker и значит не для «прогрессивного web-приложения» о котором пишется статье.
А что вы еще ожидали от мылосру? Амиго, мылоспутник, мылогвард и прочие говноподелки ясно дают понять об уровне компании и сидящих там работниках

Что за бред? У мыла все сервисы работают в 100500 раз быстрее того же гугла, зайдите на те же вопросы и поклацайте на вкладки.

Сравниваем сервера в России с серверами на другом конце земного шара, ага? У гугла даже в СНГ ДЦ нет, насколько я знаю.

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


Серьезно? Прямо таки без замедлений? Ушёл майнить биткоины Аяксом. Или сразу запрошу готовых, из нескольких мест, раз можно.


Слушайте, ну нельзя так, столько косяков в одной фразе.

Есть мнение, что фраза была употреблена в контексте «AJAX не фризит страницу на размер лага от запроса, не считая издержек на вызов и все эти подкапотные операции». Не?

"Разрабатывать… может быть пугающим занятием, если не сказать больше. "


На скрижаль, однозначно.

НЛО прилетело и оставило эту надпись здесь.
self.addEventListener('fetch', function(e) {
  e.respondWith(caches.match(e.request)
    .then(function(response) {
      return response || fetch(e.request)
        .then(function (resp){
          return caches.open(cacheName)
            .then(function(cache){
              cache.put(e.request, resp.clone());
              return resp;
          })
        }).catch(function(event){
          console.log('Error fetching data!');
        })
      })
  );
});


Промисы спасут нас от callback hell говорили они…
Ничто не спасет от криворукости. Этот код без проблем переписывается в плоскую последовательность .then(...), а с async/await вообще красота получится. Но не в случае с «прогрессивным веб-приложением» от mail.ru, конечно.
Не поверил своим глазам, когда увидел inline svg код для иконок. Мой дилетантский опыт подсказывает, что такое делают через кастомные шрифты, тем более, что автор делает в material-design стиле.

В inline SVG в общем-то нет ничего страшного. Немного засоряется вёрстка, конечно, но стилить всякие ховеры и разные состояние становится немного проще. Хотя я в основном пользуюсь defs > symbol > use для этого.

Если не затруднит, поясните, а в чем профит от инлайн svg? По мне, инлайн svg — это как вставить картинку через data/image. Да, уменьшается кол-во запросов к бекенду и для небольших изображений браузер скорее всего быстрее отрисует область… Но вместе с этим уменьшается гибкость решения, и при желании изменить иконку во всех местах проекта, придется немало покопаться…

Проще стилизация состояний. Но не скажу, что я сторонник inline svg. Если иконка присутствует один раз на странице, то еще можно подумать. Использовать svg-спрайты не умею, поэтому вручную делаю defs > symbol + use.

От кастомных шрифтов потихоньку отказываются.

Забавляют комментаторы про "мылору" и говнопрогрессивное приложение, которые даже не успевают заметить плашку "Перевод" в стремлении написать сообщение

Если кто-то потратил на перевод своё время (время компании, судя по размещению в её блоге) значит кто-то считает это полезным.

Но это не отменяет того факта, что глупо спускать всех собак с формулировкой "это же мылору, опять говно впаривают". Стоило сделать комментарии от переводчика, согласен. Если он понимает косяки, допущеные в оригинале, конечно же.

Если бы он понимал косяки — этого перевода бы не было. Зачем переводить материал с косяками когда без косяков полный интернет контента? Так что это взаимоисключающие параграфы.

Ну да это перевод. Разве это отменяет претензии к смыслу?

Вся суть реакта — это возможность писать кашу из html и js при том, что html без кавычек? :)
Вы из-за этого его используете?

Помнится, кстати, тоже такая мысль проскакивала. Но потом я React+Redux попробовал и могу сказать что на самом деле это действительно удобно: компоненты должны быть маленькими и глупыми (то есть не содержать какого-то сложного JS-кода, не знать ничего про вышестоящий код), так что в них в основном остаётся этот самый HTML и самую чуточку JS. А так как по отдельности этот JS и HTML смысла не имеют, то и лежат они вместе, в одном файле.
Ну и кроме того JSX использовать не обязательно, это лишь небольшой синтаксический сахар над вызовом одной функции.

лишь небольшой синтаксический сахар

скорее "синтаксическая кинза". Очень на любителя.

У вас, кажется, ПОДГОРАЕТ

Не, мне просто интересно, какие задачи React решает на самом деле :)
Из-за чего такой хайп.
К чему были разделы про REST и AJAX? Существуют frontend-разработчики, которые могут это не знать? За речью капитана очевидности так и не удалось понять, в чём же отличие Progressive Wep Apps от того, как было принято делать приложения последние годы.
В том, что кто-то в Гугле придумал новую ПАРАДИГМУ и теперь пиарит на каждом углу.

PWA можно установить на телефон и запускать как обычные мобильные приложения.

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